Alberto, et. al.,
I noticed a typo in my mail below. In the first paragraph, I meant to say that
we "should explicitly state that encapsulated are not chunked". Sorry for
the garbled message and the additional noise.
Craig
--- Begin Message ---
In addition to my earlier comment (that we should explicitly state
that encapsulated chunked rather than saying they should not be
broken into multiple chunks if thats what we mean), I have a couple
more questions.
1. Does the chunk inidcator ieof only apply to preview? That is how
the examples read. So a non-previewed message will be terminated
by a 0\r\n rather than by 0; ieof. I think this is right, but the text
can be clearer,
2. HTTP allows for trailing headers when chunking. Do we want to as
well? If so, do we want a mechanism like the TE and TRAILER header
fields?
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.
--- End Message ---