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.
> 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.
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
> (5),(7),(8),(10)
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