Thanks for the update -
I think the chunking description as it relates to headers is still a bit
confusing.
The text says that header sections must not be split into multiple chunks, but
the examples go beyond this by not chunking headers at all. The text makes it
sound as if I should see something like
encapsulated: res-hdr=0, res-body=256
100
<256 bytes of header>
100
<256 bytes of response body>
I have a slight preference for no chunks at all since the chunksizes are i
implied in the encapsulatedheader anyway, but we should clear up the
ambiguity one way or the other in the text.
Thanks,
Craig
...
Alberto Cerpa <cerpa(_at_)ISI(_dot_)EDU> 02/07/01 08:44PM >>>
Hi all,
It seems that the imc mailer is not accepting attachments, because the
email didn't go through yesterday.
Please take a look at the draft located at:
http://lecs.cs.ucla.edu/~cerpa/icap/draft-elson-opes-icap-00.txt
Regards,
-Alberto.
On Tue, 6 Feb 2001, Alberto Cerpa wrote:
Hi all,
I am attaching the new updated draft based on some comments we received
from Nov 17 till present.
They basically consist of the following:
- Added the default port number 1344 assigned by IANA instead of
PORT-TBD (several parts of the document).
- Changed the grammar to allow ONLY one body in the ICAP message; a
Request body in REQMOD and the Response body in RESPMOD. I also added
an explicit statement saying this in the text (section 5.4).
- Forced the final CLRF at the end of the message with a MUST instead of
a SHOULD (section 5.4).
- Added a note that chunking MUST NOT break headers sets into multiple
chunks (sections 5.7 & 5.8).
- Changed all the examples accordingly, based on the previous
modifications (sections 5.7 & 5.8).
- Changed the header "Allow:" to "Feature:" in the OPTIONS mode. This
is to avoid overloading "Allow:" with different semantics based on the
ICAP message's mode (Allow meaning on thing in REQMOD/RESPMOD and a
different thing in OPTIONS). Nevertheless, please note that the
examples in OPTIONS are just examples (Section 5.9).
As usual, comments are welcome.
Regards,
Alberto & Jeremy.