Subject: RE: Summary of ICAP discussion

From: "Martin Stecher" <[email-masked]>
Date: Fri, 18 Oct 2002 14:01:09 +0200

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:[email-masked]]
> 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
> 
>

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 18 Oct 2002 17:00:01 -0400

Martin,

 > 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.

As Jeff mentioned in an earlier email, isn't an ICAP server allowed by 
the ICAP internet draft to reply to an ICAP client before the ICAP 
server has received the entire encapsulated body? As such, rather than 
requesting a second preview, the ICAP server can request to send the 
entire message, and than simply reply once it has received enough data 
to make an informed decision. Might even be the prefered way, since it 
might not be the case very often that the second and thrd preview ize 
will be static and know a-priori? Or do you have a specific 
scenario/application in mind?

 > 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.

A compagnon document summarizing the common usage of such headers 
would be very helpful and, IMHO, important.

 > and let it become an RFC as is.

This would be an individual RFC, and not the result of the WG.

 > 2. Work on a compagnon document that considers (4) and maybe also

I would *not* merge 5,7,8,10 in there, but rather have a compagnon 
document only on 4 (and related, commonly used (X-)headers).

 > 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.

Sounds reasonable.

Note however, that the decision on how to proceed with the ICAP draft, 
is with our ADs and the IESG, and not a WG issue. The WG is just 
expected to "... SUPPORT development of an analysis that explains the 
limitations of ICAP...".

Thanks,
-Markus

---

From: Andre Beck <[email-masked]>
Date: Fri, 18 Oct 2002 17:49:28 -0400

Martin Stecher wrote:
 > re (4): Most implementations support the X-Client-IP header. I don't
 > know any implementation supporting X-Subscriber-ID.

The Bell Labs ISE (ICAP server) as well as our ICAP client library 
support both headers. Applications incorporating our ICAP client library 
can set the X-Client-IP and X-Subscriber-ID headers when sending ICAP 
requests and service modules for the ISE have access to the values of 
these headers (if present).

-Andre