So Ian, you are basically saying that you
do not want to follow the IETF procress?
At 11:27 AM 6/28/2001 -0700, Ian Cooper wrote:
At 10:01 6/28/2001 -0700, Michael W. Condry wrote:
Many of the WEBI/WREC folks remember what happened when
the iCAP forum came to Pittsburgh. Consequently I felt this thread
would be interested to them. Please include "ietf-openproxy(_at_)imc(_dot_)org"
if you choose to reply.
This discussion has nothing to do with either the deceased WREC or WEBI as
either stand, so I'd urge folks to move the discussion over to the
ietf-openproxy(_at_)imc(_dot_)org list. There was a speakers slot at the Pittsburgh
IETF (unincorporated minutes are at
<URL:http://www.wrec.org/IETF48/ietf-48-wrec-minutes.txt>) but that's all.
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.
What working group?
The rough minutes I see make no mention of an iCAP presentation, though
that may be in error. Certainly I recall someone (Paul Eastham or Jeremy
Elson? apologies if neither) mentioning that they would help folks get on
the iCAP mailing list to participate.
But I do *not* recall any mention of this being IETF work or related to an
IETF working group at that time. In fact, that would have been rather
hard, given that this was the first time Gary had presented any of the
extproxy stuff.
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.
No working group has ever taken iCAP on as a work item.
Period.
End of discussion.
OPES says that if chartered it will look at it, may ignore it, throw it
away, change it so much it bears no resemblance to what it looks like
today (let's call that "v2").
While it may be bad social protocol to ignore comments after they've been
requested, at the end of the day there is nothing to stop the iCAP folks
from specifying and implementing whatever they want.
My reading of the archives doesn't actually identify *why* discussion of
iCAP was moved to this list, or with what permission, just the fact that
it was moved here. In other words, I can't find any mail that documents
why this proposed working group says it has a claim to iCAP other than
that it made the claim itself.
The iCAP folks can request publication of the specification as an
Informational RFC. As Martin has said, it *is* useful. And it's obvious
we need a reference available.
That is *NOT* saying OPES shouldn't look at iCAP for ideas or for a fit as
its callout protocol. I just think that the way iCAP is introduced in the
proposed charter is really really bad.
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
Michael W. Condry
Director, Network Edge Technology