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@us.ibm.com]
>>> Sent: Wednesday, April 15, 1998 9:22 AM
>>> To: ipp@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@pwg.org on 04/14/98 05:34:03 PM
>>> Please respond to ipp-owner@pwg.org
>>> To: ipp@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@us.ibm.com]
>>> Sent: Tuesday, April 14, 1998 4:25 PM
>>> To: ipp@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@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@cp10.es.xerox.com