IPP Mail Archive: RE: IPP> IPP document set - naming convention(s)

RE: IPP> IPP document set - naming convention(s)

Tom Hastings (hastings@cp10.es.xerox.com)
Fri, 13 Mar 1998 15:08:34 PST

At 13:01 03/13/1998 PST, Robert Herriot wrote:
>The current binary encoding assumes that chunking occurs at a lower layer.
>IPP
>could work without chunking, but we thought it was important to avoid the=
LPD
>problem where the length of a document must be know before sending it.
>
>If I were writing a server for receiving IPP over a raw socket, I would
prefer
>not to have chunking at a lower layer because I would have to implement a
>lower
>layer to put the chunks back together for the upper layer. I would prefer=
to
>read the encoded attributes directly off the socket and chunk only the
>document
>data. =20
>
>Therefore I would end up with a slightly difference encoding for raw=
sockets
>than for HTTP.

In reviewing the various host-to-device protocols at the meeting,
TIPSI and CPAP both have a separate channel for the data. So the
control stuff goes over and comes back over a bi-directional
control TCP/IP channel and the data goes over the separate data channel.

The control channel would NOT need to be chunked, I would think.

The data channel could just be a simple TCP/IP socket, so it wouldn't need
chunking either. For example, in CPAP, the device returns the port for
the data channel, and the host opens it and send raw data without headers
of any kind and then closes the channel at the end of the document
(which corresponds to the end of the data for a Print-Job or=20
Send-Document IPP operation).

Comments?

Tom

>
>Bob Herriot
>
>At 12:11 PM 3/13/98 , Turner, Randy wrote:
>>
>>I'm curious why the existing binary encoding is inherently dependent on
>>chunking?....I thought chunking was a part of the transport of the
>>encoding. I don't think there is anything inherent (or explicitly
>>referenced) by the current encoding that involves chunking. You're right
>>that another transport would have to solve the chunking problem, but
>>it's a TRANSPORT issue, so this would naturally fall into a transport
>>mapping document. If there was a bit or byte that specified HTTP
>>chunking within the binary encoding, then this is a different story.
>>
>>Randy
>>
>>
>> -----Original Message-----
>> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
>> Sent: Friday, March 13, 1998 12:06 PM
>> To: Turner, Randy; 'ipp@pwg.org'
>> Subject: Re: IPP> IPP document set - naming convention(s)
>>
>> I think we had this discussion in Austin as part of Tom's
>>proposal.=A0 We=20
>> decided to change the name of the protocol document. Its new
>>name is=20
>> "Internet Printing Protocol/1.0: Encoding and Transport".=A0 We
>>decided not to=20
>> split the two documents.
>>
>> Although the IPP encoding is, in theory, transport independent.
>>In fact, it=20
>> depends on HTTP chunking. With an alternate transport, we would
>>have to=20
>> solve the chunking problem.=A0 It would be more efficient if the
>>document data=20
>> were the only part chunked, but that would require a change to
>>the encoding=20
>> layer.
>>
>> So, at this point, I don't endorse separating the two documents.
>>
>> Bob Herriot
>>
>> At 03:36 PM 3/12/98 , Turner, Randy wrote:
>> >
>> >Would anyone have any problem(s) splitting the protocol (not
>>model)
>> >document into two documents?
>> >
>> >Document 1 would be an encoding document
>> >Document 2 would describe how to transport the encoding over
>>HTTP 1.1
>> >
>> >?
>> >
>> >Randy
>> >=20
>>=20
>
>
>