Hi,
going over the emails that have recently been posted as comments on
the latest ICAP specification (draft-elson-icap-01.txt), the issues
raised can be summarized as follows:
(1) The latest ICAP specification as described in Internet Draft
draft-elson-icap-01.txt is clear and helps in building
interoperable servers/clients implementations.
(2) Implementation experience shows that ICAP is a relative light
weight protocol, both in terms of protocol overhead and code
complexity.
(3) The PREVIEW feature specified in ICAP is considered useful and
important for real life deployment.
(4) It would be useful to add a standardized mechanism in ICAP that
allows to convey additional metadata (e.g. client and subscriber
information), maybe along the lines of the now expired draft on
"Transmitting Subscriber Identification in iCAP"
(draft-beck-opes-icap-subid-00.txt). In particular, a mechanism
for transmitting subscriber information is essential for certain
services.
(5) Minimum support for security may be provided in ICAP by just
supporting an additional header similar to WWW-authenticate.
(6) ICAP is specifically designed for HTTP, but attempts have been
made to encapsulate FTP and even SMTP into ICAP.
(7) The ICAP draft should mention that a single client
request-response flow could include both reqmod and
respmod modifications.
(8) It might be helpful to explicitely mention in the draft that ICAP
clients should be written to check for an ICAP server's response
while the ICAP client is sending out an encapsulated body.
Although not directly a protocol issue, this is important to
speed-up scenarios in which the server can provide a final
response before receiving the entire message.
Let me further add
(8) the curent ICAP specification doesn't include a mechanism for
tracing/notification.
(A more detailed discussion of ICAP with respect to the OPES protocol
requirements can be found in draft-stecher-opes-icap-eval-00.txt)
In the OPES context, does anybody have any more comments on the
existing ICAP specification. Does anyone have any comments/feelings on
the above points, or can they be considered a collective view of this
WG on the existing ICAP specification? In particular:
With respect to point (1), it would be interesting to learn about
existing implementations that implement the latest ICAP spec and whose
interoperability has already been tested (well, at least to some extend).
With respect to point (4), would it be helpful to either integrate the
mechanim proposed in the expired ID
draft-beck-opes-icap-subid-00.txt into the ICAP spec, or to publish
this mechanism in a separate compagnon document? Is this mechanism
supported in any existing ICAP implementation? If not, how do existing
ICAP implementations convey subscriber information to services that
require such information?
With respect to point (5), would it be worthwhile to further explore
this issue and maybe come up with a proposal for such addition? Or
would it be better to leave it alone and to refer to Section 7 of the
ICAP draft, which states the security limitations of the current spec.
With respect to point (6) - Is there a need for a more flexible
callout protocol that can encapsulate different protocols as well
(e.g. FTP, SMTP, or maybe even SIP)? Be careful, though - the current
OPES charter is limited to HTTP (and RTP/RTSP)!!!
Considering the collection of comments, one might state that the
current draft is pretty stable and describes existing and implemented
practice, although it has some limitations with respect to the OPES
architecture and OPES protocl requirements.
Cheers,
Markus