iCAP, OPES and the IETF

Please let me address one or two issues which have arisen recently on this 
list and others with regards iCAP.
We came up with iCAP almost 2 years ago as a way of allowing us to perform 
very simple vectoring from an "edge device" (usually, but not always a 
proxy or a surrogate), to a (usually local) application server.  At the 
time it looked like a good idea. It was very simple, based on HTTP and 
easily implemented. Since then it has developed, improved dramatically and 
made real due to the hard work of a large number of people. In fact, it has 
already been implemented by a number of vendors. It was originally based on 
HTTP but that has been superceded, mainly for performance and expandability 
reasons. (See ietf-openproxy and other archives for discussions).
At the moment, however, we have a specification which is still fluid and 
for coding purposes, this is not acceptable. For this reason, a few of us 
got together in order to go over the existing document and produce 
something we could nail down and publish. The current plan is to submit 
this to the RFC editor for publication as Informational.  The reason for 
this is that it is a documentation of something that is already in 
existence, has not been developed within the IETF WG structure and we want 
somewhere to document it formally for those that want to write code.
Note that this does not preclude further development of iCAP. In fact, I 
would argue that setting a 1.0 in stone as an Informational (or 
Experimental) RFC gives us a clean slate from which to continue rather than 
falling into the creeping featurism trap. I would hope that this 
development will take place within the *standards process* of the IETF but 
since there is no appropriate working group there at the moment, I cannot 
predict what will happen.
With regards iCAP and OPES, I think there is a lot of confusion. I have 
never seen anyone mandate iCAP as some sort of base protocol for future 
OPES work and yet I have seen recent messages which gave me the feeling 
that some felt this was the case. As far as I am concerned, it is not. Were 
it to become chartered as an IETF working group, it would be very normal 
for OPES - like *any* new IETF WG - to examine existing complementary 
technologies in order to determine their relevance to future protocol 
development. iCAP is certainly one such technology as is SOAP and the 
others mentioned. It is my understanding that this is what the substance of 
OPES discussions are right now (as well as getting a charter together, of 
course).
With regards iCAP and ECMA it is very simple. We will also submit iCAP to 
ECMA. The version submitted will be identical to that finally published by 
the RFC editor (i.e. after integrating corrections from either the RFC 
editor or the IESG, to whom the RFC editor may defer).
I hope this clears some things up.

Regards,
John
---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------