ietf-openproxy
[Top] [All Lists]

Web Services (was: iCAP Issues at OPES Workshop)

2001-06-01 05:52:09
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


<Prev in Thread] Current Thread [Next in Thread>