Michael,
This email you sent and your response to Ian's reasoned reply are very
misleading and, in many cases, factually incorrect.
I suggest you read up and learn the differences between the functions of
the IETF, physical meetings of the IETF, the RFC Editor and the IESG.
[Note: this is the very least you should do if you are still proposing
yourself as co-chair of an IETF WG].
Here are a few FACTS related to iCAP and the IETF for those that might be
interested:
1. iCAP is not nor now never has been a work-item of ANY IETF
Working Group. Period.
2. iCAP has been published a number of times as an internet draft.
3. iCAP has been "presented" as work in progress at a number of
meetings of the IETF WREC WG (which I co-chaired) along with
other protocols of interest such as WCCP, WPAD and some content
distribution work. These protocols were "presented" because of
their
relevance to the work items on documenting a taxonomy and known
problems.
4. To my knowledge, a Mr. iCAP Forum never "came to the IETF asking
for help on the protocol in Pittsburgh". I believe you are
confused.
See 3 above. I do recall iCAP being presented at the disasterous
first OPES IETF BoF - is that what you mean? If so, it was presented
by Mr. Don Gillies (not Mr. iCAP Forum) who, as Ian pointed out,
offered to help those implementing iCAP servers (i.e. the opposite
of what you say).
5. As for "...BUT they were unwilling to follow the IETF process.",
can you be more specific? Given 1-3, I don't see what process was
not followed.
6. iCAP development has been discussed in a number of places
including, more recently, the ietf-openproxy list.
7. ...I could go on but hopefully you get my drift.
Rgds,
John
At 12:46 PM 28/06/01 -0700, Michael W. Condry wrote:
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
---------------------------------------------------------------
Network Appliance Direct / Voicemail: +31 23 567 9615
Scorpius 2 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp Main Office: +31 23 567 9600
---------------------------------------------------------------