I think it would be wrong to ignore iCAP when this group tries to come
up with a standardized remote callout potocol. There is obviously a
pressing need for a callout protocol among caching vendors as well as
among service providers and if the IETF takes years to standardize a new
callout protocol, iCAP will probably become a de-facto industry standard
in the meantime. Or even worse, we may end up having two competing
callout standards: an ECMA callout protocol and an IETF callout
protocol.
Also, the already existing implementations of iCAP suggest that iCAP
can't be a completetly useless approach to remote callout. Now whether
the protocol that ends up being standardized by the IETF will look at
all like the current iCAP spec or maybe more like XMLP or a mixture of
both, is not really relevant at this time, as long as we carefully
consider all existing alternatives and iCAP is certainly one of them.
-Andre
"Michael W. Condry" wrote:
Well does the group want to pass iCAP to another organization,
like ECMA, for standardization evaluation OR we wish to
evaluate it first and decide if OPES positions iCAP?
At 08:47 AM 6/1/2001 -0400, Lee Rafalow wrote:
Actually, I understood Lily's question. I took exception to one word,
"standardized," and was trying to make a simple point: we have a submission
and charter that suggests we would evaluate ICAP with no obligation to
approve it. Nothing in our work scope is a standard as yet. (I'm not sure
I've seen the final draft of the charter, there was some discussion about
whether those 4 letters would appear in the charter at all but I'm assuming
the charter submitted to the IESG is close to what I have seen.)
For those not already familiar with it, I'd suggest taking a look at the W3C
web services (UDDI, WSDL, SOAP/XMLP). Edge services (at least the ones
covered by the ICAP proposal) are just a special case of web services; and
it's not at all clear to me that they're a special case. Maybe we don't
need all of the function right now, but it sure seems like the right
approach to me: service descriptions, dynamic service bindings and an
XML-based transport protocol...all with significant support from the
industry. Further, XMLP is not tightly bound to an HTTP transport; a
BEEP transport might slide in underneath it if appropriate.
I'm not sure why we would invest in something that doesn't fit into this
framework. What am I missing here?
Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: rafalow(_at_)us(_dot_)ibm(_dot_)com
Home email: rafalow(_at_)mindspring(_dot_)com
----- Original Message -----
From: "Jeremy Elson" <jelson(_at_)lecs(_dot_)cs(_dot_)ucla(_dot_)edu>
To: "Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com>
Cc: <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Thursday, May 31, 2001 5:34 PM
Subject: Re: iCAP Issues at OPES Workshop
"Lee Rafalow" writes:
I hate to have to play this role, but I don't understand the phrase: "the
not-yet-standardized OPTIONS method." None of this is standardized as
yet.
Or did something happen that I missed?
Lily meant that the document as it stands does not specify any form or
recommended content for the OPTIONS method. That is, if you implement
the protocol as specified in the current draft, there is no
recommendation on how to use OPTIONS.
Right now we're working in advance of the midterm OPES meeting to get
a new draft out based on feedback we've gotten, and it has some
recommendations for OPTIONS. But, I suspect that many options will be
service-specific and defined by the application.
-Jer
Michael W. Condry
Director, Network Edge Technology