Martin, I'm sorry if my somewhat flippant imagery offends in some way,
that's not my intent. Nor was my intent to portray an industry divided
although it's clear there are some tensions. My intent was merely to
characterize the situation as I see it. So, without the imagery....
1. I would have preferred to have 1 industry standard for calling web
services from an intermediary. Hence, I joined with others to try to
dissuade you and others in ECMA from forming the iCAP TG18; OPES is being
chartered to do a similar protocol. The IETF has change control on any and
all of its documents.
2. ECMA and the iCAP Forum have agreed to work on dotting the i's and
crossing the t's for iCAP. So be it. You have defined the table at which
you want to bring people together to work on iCAP: the ECMA/iCAP Forum
table.
3. Given these facts, I think OPES should get on with the agreed mission of
developing and evaluating our alternatives. I have argued that using SOAP as
a foundation for the callout protocol to be compatible with the wider
industry usage is one of the alternatives. If ECMA had not created TG18, I
would still want us to work on a SOAP-based solution. I just prefer 1
standard instead of 2. But I know how to explain this to people and can
even position the potentially different solutions.
The trade-off I think you and Network Appliance have made is that you can
have a quick iCAP standard (via ECMA) or you can have a more thoughtfully
developed standard that may not be iCAP (via IETF). You chose quick. And I
don't mean to juxtapose "quick" and "thoughtful" in a pejorative way, I
simply mean that in the IETF context, alternatives should be considered. I
disagree with the trade-off you made and we tried to dissuade you, but so be
it.
My goal is the success of the industry not the success of iCAP. IMHO
integrating with the wider industry investments in Web Services (SOAP, WSDL,
UDDI) is a better path for industry success. But we'll see how the IETF
deliberations play out. IHTH, Lee
----- Original Message -----
From: "Martin Stecher" <martin(_dot_)stecher(_at_)webwasher(_dot_)com>
To: "Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>
Cc: "van den Beld Jan" <jan(_at_)ecma(_dot_)ch>
Sent: Friday, June 29, 2001 12:52 PM
Subject: RE: OPES claim on iCAP
I don't like the picture of the ECMA/iCAP forum alliance, the "happy
couple" that shares all interests and is in oposite to everybody else.
At least this is the picture Lee's mail draws in my head.
Two weeks ago this was the situation for me:
- Some companies wanted all technical iCAP work to be done by OPES
(maybe allow ECMA to use the OPES output for their standardization
process)
- Some wanted OPES to concentrate on other things but iCAP
- At least one company that used to be very important for iCAP wanted
all technical work to be done within ECMA
This situation seems to be a very limiting factor for the success of
iCAP.
What I want all the time is to bring everybody who is interested at one
table, to concentrate the technical work in one group with the
leadership to those that give their best to help iCAP forward, to allow
everybody to participate to give input and to form liaisons to groups
that will standardize the protocol that is created at this large table
within their organisations.
We currently have a big gap between members of OPES and members of ECMA.
On both sides of this canyon there are big and important players. So it
is simply not possible to have the long table within OPES nor whithin
ECMA! A bridge is needed to overcome the gap.
All companies interested in iCAP (or at least most of those interested
today) are members of the iCAP forum. That is why I think that this
forum could deal as that bridge. That is why I suggested to use this
forum during that long discussion on the ECMA meeting.
For sure the iCAP forum was very silent during the last months.
I would like to reanimate the forum to become the long table with all
its consequences, like creating a board with representatives of more
than just two companies to give control to a more common base.
Of course this scenario is not the 100% solution for both sides, but
this is the nature of a compromise.
I think it is a good solution for all interested parties:
One group (the iCAP forum) to work on the iCAP protocol. Still enough to
do for the two other groups to deal with iCAP. If wanted by those that
like to be active in more than one group: Joined meetings or meetings at
the same place to reduce travelling efforts.
Martin
-----Original Message-----
From: Lee Rafalow [mailto:rafalow(_at_)raleigh(_dot_)ibm(_dot_)com]
Sent: Friday, June 29, 2001 2:50 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Cc: van den Beld Jan
Subject: Re: OPES claim on iCAP
I'm confused by all of this discussion about ownership and
joint development
work. As I understand the situation, the iCAP Forum and ECMA
have found a
marriage. We stood up and made our objections known and, although I
disagree with their decision, so be it. The IETF owns the
copyright and
change control on any and all IETF documents. Unless the happy couple
agrees to take anything we do (and they say they don't), then
the discussion
is over.
So, if you want to work on iCAP, go to the iCAP Forum and/or
ECMA. Simple,
yes? If you want to work on the OPES framework, callout
protocol, security
& policy models, this is the place. This seems the only
logical conclusion.
If the OPES callout protocol ends up looking similar to iCAP,
so be it.
Another alternative is for OPES to accept whatever the Forum
and ECMA come
up with and reference it. Bottom line, it's silly to have
three groups
working on 1 protocol when we've all got more than enough to
do already.
What am I missing here?
----- Original Message -----
From: "Michael W. Condry" <condry(_at_)intel(_dot_)com>
To: "Ian Cooper" <icooper(_at_)equinix(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>
Cc: "van den Beld Jan" <jan(_at_)ecma(_dot_)ch>
Sent: Thursday, June 28, 2001 3:44 PM
Subject: Re: OPES claim on iCAP
The question is one of process for consensus documents. NOT
does OPES or
any other
working group OWN iCAP.
If iCAP is submitted to the IETF (OPES, WEBI, anywhere) then is a
consensus
process to agree to its contents, agree? Of course an
individual I-D has
no
consensus, that is not the discussion.
If an IETF finds issues to be resolved (AD, WG, whatever)
then these must
be resolved. Resolution is not the authors saying "we submitted it
elsewhere
and they accepted it" agree?
If the authors of the document, members of iCAP-form or
not, agree to
make all changes requested in a timely manner as IETF participants
then there I do not see an issue. But this is the concern. Do you
remember the Pittsburgh BOF? That certainly did not
imply this kind of cooperation. agree?
So the issue is NOT if the authors of a document also submit it to
another organization like ECMA, that can be ok! The issue is
for the IETF members to work on a document and not have
the IETF process followed. Does everyone agree?
At 11:24 AM 6/28/2001 -0700, Ian Cooper wrote:
I' confused. In trying to respond to another message I
finding myself
asking why OPES seems to need total control of iCAP.
If it's published as an Informational RFC (with the
current nits fixed)
what problem does that actually present?
Is it the job of a proposed working group to worry about
the interaction
of standards bodies on a protocol that they themselves say they may
choose
not to use? (And that if they do, may end up being something so
different
that it's not the iCAP that's been examined by those other
standards
bodies.)
Michael W. Condry
Director, Network Edge Technology