Ok, maybe I was abusing the word of "standard". Let me clearify what I meant
here -- the OPTIONS method is not even specified in the ICAP spec. We need
to specify it to support important (must-have) feature discovery (or
negotiation) between the ICAP client and ICAP server for ineroperability. We
are discussing the technical detail of the spec just so client and server
can understand and talk to each other effectively. Standard or not for ICAP
as a whole is a totally different issue.
Lily
-----Original Message-----
From: Ian Cooper [mailto:icooper(_at_)equinix(_dot_)com]
Sent: Thursday, May 31, 2001 12:58 PM
To: Merrick, Jeffrey; 'Lee Rafalow'; ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: iCAP Issues at OPES Workshop
At 12:29 5/31/2001 -0700, Merrick, Jeffrey wrote:
I hate to have to play this role, but I don't understand
the phrase:
"the not-yet-standardized OPTIONS method." None of this
is standardized
as yet. Or did something happen that I missed?
No, the OPTIONS response headers aren't standardized as yet.
But they
probably need to be standardized soon, for issues such as
the one Lily
brought up are real and we want to avoid divergent
implementations for
such fundamental things.
I'd strongly suggest against using the word "standardize"
around iCAP. To
my knowledge there's no suggestion on the table to make this
an Internet
standard at present. (I've only seen suggestions to go
Informational or
Experimental.)