Regardless of the indicated number of companies, the iCAP-forum is
NOT a recognized consensus group such as the IETF. In fact,
they came to the IETF asking for help on the protocol in
Pittsburgh BUT they were unwilling to follow the
IETF process.
They were happy to let IETF members work and listen to consensus changes
in the specification but their inclusion in the specification
was their decision, NOT CONCENSUS. Thus, they could
choose to ignore any recommendations of the IETF working group.
Has this changed? If a working group (OPES OR WHATEVER) of the
IETF is working with a document they expect that their efforts
are not ignored.
IMHO ISO should not accept a fast track from any group were the document
results from a small group that ignores a industry consensus process such
as the IETF.
At 09:27 AM 6/28/2001 +0200, Martin Stecher wrote:
I got a very positive impression of the work in OPES when I joined the
interium meeting in Santa Clara. There was a high interest in iCAP and
very good technical ideas and feedback.
--------
Side note:
On the ECMA meeting last week we had a long discussion how to get
everybody who is interested into the same boat to develop a single iCAP
standard. Since there are people that feel not comfortable with a
technical iCAP leadership of an ECMA group and others not feeling
comfortable with everything to be done by OPES, we tried to find a third
way that can work as a compromise. I hope to see the letter that was
written on the last day soon in this mailing list that will propose all
the technical work to be done within the iCAP forum (with its 120
members that are claiming to be interested in iCAP) and have strong
liaisons to OPES/IETF and ECMA to go for a RFC and an ISO norm.
--------
The more I read in this mailing list the more I am disappointed what
OPES will do with iCAP. It seems to me that it more and more disappears
from the charter and from your minds.
The sentence: "It may decide to extend or even not use the iCAP protocol
without being obliged to retain any level of compatibility with the
current iCAP proposal." is just great.
Tell me: Why should a company that wants to make business with iCAP
wants that OPES is the group that is responsable for the iCAP
development? With this charter I am afraid that this "iCAP leader" will
just stop the development and any time or will change the complete
concept of the protocol from one day to the other. Now it is this group
that just creates the danger to end up with multiple wanna-be-standards,
a matter you all were most concerned about on the workshop!
You know from my messages to this group that I do not think either that
the current iCAP version is the best protocol on earth but it works
quite well and has really a big chance in the market!!! And the current
draft (btw it's at http://www.circlemud.org/~jelson/icap-1.72.txt and
not longer draft-elson-opes-icap-01.txt as in the charter) is at least
good enough that people have a chance to write applications that work
together.
Don't misunderstand me: It's great if people are doing the research for
long-term solutions and will create an even better callout-protocol for
the future. I will carefully follow these developments and try to help
where I can but my company cannot yet effort a large research group that
just cares about the great future. We are thankful that iCAP exists
TODAY and works.
For the last couple of months, this mailing list was the discussion
forum for iCAP. I am somehow disappointed that 90% of the discussion was
only political and only a few messages dealed with the technology.
That's why I propose to create a mailing list within the iCAP forum and
to continue discussion about the real iCAP work there.
I still hope that OPES will commit to iCAP at least as a first possible
callout protocol that deserves to get standardized and will help to do
this within IETF. Then go and develop the better next protocol or
version of the protocol.
OPES may disregard iCAP because it does not solve enough of the
callout problem OR, even though it could be useful, it is disregard
because it breaks the fundamental consensus theory of the IETF.
Martin Stecher
Michael W. Condry
Director, Network Edge Technology