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@imc.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@imc.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
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:22:57 MST