Subject: RE: ICAP suggested changes/ call for comments

From: LOVRIC Ivan FTRD/DMI/CAE <[email-masked]>
Date: Wed, 11 Oct 2000 09:19:02 +0200

Hi,

As implementors of the iCAP protocol, we also noticed several ways to
improve it.

1) Some kind of a negotiation between the ICAP client and the ICAP server
should occur during activation of the system.
The purpose here is to take the server capabilities into account, for
example if the iCAP server modifies only text files, there is no use to
transmit image files to that server.

2)The current specification doesn't deal with any error or status messages.
This leads to misunderstandings between implementors about the way to
process iCAP requests and responses according to status codes.
If we want to have compliant implementations whatever the clients and
servers are, the issue of status codes should also be solved within the
specification.

Regards,
___________________
Ivan Lovric
E-mail: [email-masked]
tel. office: (+33) 2 31 75 91 25
tel. home:(+33) 2 31 97 38 70

France Telecom R&D
42, rue des Coutures - BP 6243 - 14066 Caen Cédex 4 - France

-----Message d'origine-----
De: Jeremy Elson [mailto:[email-masked]]
Date: mercredi 4 octobre 2000 11:15
À: [email-masked]; [email-masked]
Cc: [email-masked]
Objet: ICAP suggested changes/ call for comments

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 [email-masked], or
join our teleconf on Thursdays.

Regards,
Jeremy