[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of ICAP discussion
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@xxxxxxxx]
> 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
>
>