Hi,
re (3): This is true but I like to add again that having the ability to have
even more decision points would be even more useful, i.e. ICAP server could
request a second (or third) preview if the data in the first preview was not
sufficient but it still doubts that it needs the complete data.
re (4): Most implementations support the X-Client-IP header. I don't know any
implementation supporting X-Subscriber-ID.
There are also other headers in use like X-Authenticated-User and
X-Authenticated-Group.
We should collect them and put them in a compagnon document. It makes no sense
to put them in the ICAP specs directly because they are all X-Headers which
would probably not be appropriate. But changing the header names would create a
new protocol version which all existing implementations are not longer
compatible to.
re (5): Should be worthwile to explore on this but I don't see this to be an
urgent task. Today ICAP solutions are often deployed in a way that makes
authentication obsolete (special interface card and private ICAP network).
Reasons to update the existing draft are (7) and (8) and maybe another point I
found recently:
(10) The specs could be more specific about the list of allowed response codes
other than given in the specs today rather than just refering to the HTTP
protocol semantics.
I think these reasons (7), (8) and (10) are not strong enough to motiviate for
a new draft now. Point (1) is the most important one.
Therefore I vote for this procedure:
1. Name draft-elson-icap-01.txt THE ICAP/1.0 protocol specification and let it
become an RFC as is.
2. Work on a compagnon document that considers (4) and maybe also
(5),(7),(8),(10)
3. Start with the work on a new protocol that considers all OPES requirements
and my comment to (3) above and is more flexible regarding other application
protocols (6) and also includes (9). Whether that new protocol is then called
ICAP/1.x, ICAP/2.0 or totally different is not important right now.
Martin
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Friday, October 18, 2002 5:37 AM
To: OPES Group
Subject: Summary of ICAP discussion
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