Hi,
I strongly echo the points made by Markus. I believe the lack of an approval
of ICAP by any standards body - a temporary issue that will change soon - at
this point does NOT hurt ICAP efforts *as long as* there is the higher goal
of making a true standard work with a variety of products from different
vendors.
There are any number of examples of cross-industry efforts (Bluetooth, PCI,
USB, ...) that didn't have any standards body blessing as a starting point
to be successful; so, let's co-operate, make iCAP even stronger and get it
through the normal standards process in IETF, the way communication
protocols are standardized.
Thanks!
- Rama
*******
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Tuesday, June 05, 2001 7:51 AM
To: John Martin
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: iCAP, OPES and the IETF
John,
At the moment, however, we have a specification which is still fluid and
for coding purposes, this is not acceptable.
Agreed. So let's work together - within the IETF - to make sure that
we quickly get a stable and well-accepted iCAP version, which will NOT
be a standalone protocol approach, but will also integrate into a more
complete protocol framework.
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.
Did you attach a version of or include a pointer to the updated
document? I would expect that you solicit comments and feedback from
the networking community before even considering submission as RFC -
that would not only be fair to the "large number of people" that
"developed, improved dramatically and made [iCAP] real due to the
hard", but would allow anybody in helping to make the specification
even better and stronger.
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.
I completely agree with you on the following issues:
(a) iCAP should be further developed and get set in stone within
the IETF - this ensures that it will NOt be a standalone
aprroch, but will fit into an overall protocol framework.
(b) Further development and standardization of iCAP should take
place within an IETF WG, and NOT aside as submission from
a few individuals.
(c) We need to get the appropriate WG that covers iCAP official.
iCAP perfectly fits into the OPES framework, iCAP is on the
OPES charter, so let's work together to make it happen and
get OPES official (together with the IESG, our ADs, etc, of
course). We would then have the appropriate WG to take on
the iCAP issue.
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).
What's the reason for submitting to two different standards bodies? I
cannot see how this should benefit the networking community. I'm
mostly concerned that - although starting as identical - both versions
will evolve into different flavors of iCAP. How do you want to make
sure that the iCAP versions of both standards bodies will stay
identical? To which version should a vendor implement? Vendors would
probably end up with havinf to implement both flavors - and that's
exactly what we want to avoid by standardizing protocols (well, one
might argue that the nice thing about standards is the "s" :) But,
having two different "standardized" versions of iCAP is certainly not
of interest to the networking community!
So, I'm looking forward to your contributions to the IETF/OPES effort
and to seeing you at the OPES Workshop this Wednesday. I'm sure you'll
provide some valuable input.
Thanks,
Markus