Randy et al.,
Here is my take on the use of chunking for IPP:
1) Each HTTP 1.1 implementation is mandated to support chunking.
2) All POSTs are initiated by the client, which I assume also means that
the client determines whether to use chunking for a particular HTTP request.
3) The only situation where chunking is absolutely necessary for IPP, is
the case where the client does not know the document length when it starts
sending the document.
4) With the exception of the situation in 3) the client can always decide
not to use chunking, but send even long documents in one request. The
downside of doing that is that if something goes wrong on the lower
protocol layers, the client has to start over and send the whole document
again from the beginning. The main advantage of using chunking is that if
you get an error on the lower layers, you only have to resend the latest
chunk, not the whole document.
5) Again, with the exception of the case in 3), you can in practise
actually use HTTP 1.0, which does not support chunking, for most of your
IPP transfers.
Did I get this right?
Carl-Uno
At 09:08 PM 4/15/98 PDT, Turner, Randy wrote:
>>There is nothing in the existing encoding that allows a particular IPP
>message to be "fragmented" across multiple transport "packets". The
>encoding requires that a transport protocol provide some way to
>logically "connect" one message to another contiguously received
>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With
>another transport, there would have to some equivalent capability. I'm
>not sure if I've adequately described the situation. Anything further I
>think would require me to draw a picture.
>>Randy
>>> -----Original Message-----
> From: Carl Kugler [SMTP:kugler at us.ibm.com]
> Sent: Wednesday, April 15, 1998 9:22 AM
> To: ipp at pwg.org> Subject: IPP> IPP, independently of HTTP, Requires
>Chunking ? Was: Mi
>> > The concrete transport/encoding IPP protocol document is VERY
>dependent
> > on HTTP chunking.
>> I still don't get it. Could you please explain?
>> The original statement is:
> > Encoding is HTTP independent except for chinking.
>> This sentence, to me, implies that there is some aspect of the
>IPP encoding,
> apart from HTTP, that depends on chunking. This is suprising
>news to me.
>> The only chunking-related requirements I've found in the
>Protocol document are:
> 1) the Server must support "chunked" Transfer-Encoding of
>Requests
> 2) the Client must support "chunked" Responses.
> These requirements derive directly from RFC 2068: "All HTTP/1.1
>applications
> MUST be able to receive and decode the "chunked" transfer
>coding..."
>>> Confused in Boulder,
>> Carl-III
>>>>ipp-owner at pwg.org on 04/14/98 05:34:03 PM
> Please respond to ipp-owner at pwg.org> To: ipp at pwg.org> cc:
> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR -
>Apri
>>>> The abstract IPP described in the model document is not
>dependent on
> HTTP chunking.
>> The concrete transport/encoding IPP protocol document is VERY
>dependent
> on HTTP chunking.
>> Randy
>> -----Original Message-----
> From: Carl Kugler [SMTP:kugler at us.ibm.com]
> Sent: Tuesday, April 14, 1998 4:25 PM
> To: ipp at pwg.org> Subject: Re: IPP> Minutes from PWG IPP Meeting in
> Portland, OR - Apri
>> > IPP is not transport neutral. Encoding is HTTP independent
> except for
> > chinking.
>> I assume you mean "chunking". In what way is IPP dependent on
> HTTP chunking?
>> -Carl
>>>>>Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com