Hi,
Some of the early implementors of the new ICAP protocol have been
meeting over the past couple of weeks to discuss how the protocol is
broken based on recent implementation experience.
Based on these discussions we would like to change the protocol in
certain ways that we think will make it better but will break
interoperability with existing implementations (hey, it was just a
draft, right? :-) )
The purpose of this message is to ask any other implementors of ICAP
to please join us in our current discussions. In particular, if you
have any proposed changes that you think would make the protocol
better but would break interoperability, this is a good time to speak
up since we're breaking it anyway (and only want to break it once).
Please let me know if you'd like to be included in our teleconferences
that are Thursday mornings at 9AM Pacific time.
The current (proposed) changes that break interoperability are:
1- Chunked encoding will be required, instead of optional (this only
affects clients since servers need to understand chunking anyway)
2- Encapsulation Forwarded HTTP requests and responses will be
changing. Both forwarded bodies *and* forwarded headers will be
contained completely in the body of ICAP message instead of
encapsulating the (inner) forwarded headers in the (outer) headers of
the ICAP message.
3- We want to make the simplifying assumption that the ICAP server is
in the same admin domain as ICAP client. Parts of the protocol had
already made this assumption (e.g. for configuration and
authentication purposes) but it would make things easier if this was
assumed throughout.
Also, at the suggestion of some within IETF we will most likely define
ICAP to use a port other than 80. (No one on our side of the fence
feels strongly at all about this issue; we're just doing what we're
told :-))
If you have feedback please let us know at pwg@catarina.usc.edu, or
join our teleconf on Thursdays.
Regards,
Jeremy
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST