Hi Alberto,
the new draft is a great step forward. Although I am still not a fan of the
Encapsulated header encoding thing, the new draft is at least clear how to
implement it and it will work.
So I suggest to stick with this scheme for version 1.0 and think about it
again for a later version.
I hope that everybody agrees on the "null-body" element, so that I can
delete the line-by-line parser code from my implementation and get back to
the preread-complete-header code.
After this positive feedback, now the list of my ideas what still should be
fixed or could be changed ;-)
- In 4.4.1 the BNF for optbody prints the digit 0 as a direct value for
opt-body and null-body. Why not also writing (decimal integer)? Yes,
currently it's always zero but maybe another encapsulated header will be
defined in the future. And "req-hdr" is also always zero at the moment
because it's always the first item if given and there the draft says
(decimal integer).
- In 4.5 the samples sending 1024 bytes preview still have a wrong chunk
size. It should give hex 200 in front of a 512 byte chunk. (The 100 instead
of 200 is given four times).
- In 6.3 you may want to clarify that "ICAP messages MUST use the "chunked"
transfer-encoding" within the encapsulated body section.
- In 8.2 the second paragraph tries to give a motivation for not chunking
the encapsulated headers. I think the first sentence is just wrong (there
would be no need to rechunk the message body.) The second sentence sounds a
little silly to me. I suggest to just delete that second paragraph. But in
this case you will need to delete the references to this paragraph from
sections 4.4 and 8.3 as well.
- 4.10.x
Thank you for specifying some parts of the OPTIONS now. But since there are
still things open and undefined we will see different implementations.
Especially for Opt-body-type I guess that different iCAP clients will
understand different types of information for the response body of the
OPTIONS request. If I want to write a server that is working with different
clients with different expections, it would be very useful if I know which
kind of iCAP client is sending the OPTIONS request.
Could you please encourage everybody in section 4.10.1 to add the User-Agent
header to the OPTIONS request and also show it in the example? This will
probably help me a lot in the future.
ISTAG
Please read my other message about this subject.
Best regards
Martin
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alberto
Cerpa
Sent: Friday, June 15, 2001 4:48 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: New ICAP draft
Hi all,
Here is the draft we promised to deliver by the end of this week. The
draft can be found at:
http://www.circlemud.org/~jelson/icap-1.72.txt
We think it is pretty well polish and a cleaner version. We have tried
to incorporate in it all the comments we received from the list the last
couple of weeks. We hope to receive further comments form the group in
the following weeks. Let us reemphasize that this is just a draft, and
we will probably update it as we receive feedback from the group.
The plan is to submit another draft to the list after we receive some
comments, then generate a new updated draft and submit it as an I-D.
After a couple of weeks for yet another round of comments and
suggestions we would like to finally submit it as an RFC Informational.
Comments are very welcome.
Regards,
Jer & Al.