At 08:26 PM 4/16/98 PDT, you wrote:
>Are you sure about #4 below? It doesn't sound right at all. My=20
>understanding of chunking is that it allows the sender to omit=20
>Content-Length and to instead supply length one chunk at a time. At
>the HTTP layer, the document is a series of chunks terminated by a zero=20
>length chunk.
>>>Bob Herriot
>
And how is that in conflict with what I stated in 4)?
Carl-Uno
>At 12:31 PM 4/16/98 , Carl-Uno Manros wrote:
>>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".=A0 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.=A0 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.=A0 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:=A0 "All HTTP/1.1
>>>applications
>>> MUST be able to receive and decode the "chunked" transfer
>>>coding..."
>>>>>>>>> Confused in Boulder,
>>>>>> =A0 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".=A0 In what way is IPP dependent on
>>> HTTP chunking?
>>>>>> =A0 -Carl
>>>>>>>>>=20
>>>>>>>>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>>=20
>>>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