Hi Martin,
Thanks for your valuable feedback. Some comments interspersed
below...
On Tue, 19 Jun 2001, Martin Stecher wrote:
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.
That's the idea :)
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).
We could do that if you think this flexibility could be useful.
- 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).
We'll fix that.
- In 6.3 you may want to clarify that "ICAP messages MUST use the "chunked"
transfer-encoding" within the encapsulated body section.
You are right... we meant to clarify this but somehow never did.
- 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.)
Well, it *may* be if the ICAP client sends the headers and the body in
one big chunk for example.
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.
If we include the headers and the body as part of the ICAP payload to
be chunked, then there is nothing to preclude sending part of a header
in one chunk and part in another one. This is why in earlier versions
of the draft we mandated chunk boundaries not to come within headers
(after we were informed by ICAP implementors of the limitations of
some HTTP header-parsers). We are just trying in this section to
explain the reader some of our motivations in doing things the way we
did.
- 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.
We could certainly add it in the example, since it is one of the
headers described in section 4.3.2.
ISTAG
Please read my other message about this subject.
Thanks for your input.
Regards,
-Al
Best regards
Martin