Hi again,
> 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.
I fully agree. Anybody who likes to help to create that document?
> 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.
Yes, of course; it has been published nearly a year ago.
Why do you use "would"?
Do you suggest to create a WG version of that draft? Maybe with some additions
that consider points (4) to (10)?
> 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).
Agreed.
> 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...".
And I hope that this WG task can finally be finished now so that the ADs and
IESG can continue.
Regards
Martin