I agree that your point is othogonal.
The technical point that I'd like to make is that for performance
reasons, something that is lightweight both in terms of protocol
and encoding is desirable. I think ICAP has a good approach,
and I'd like to see that continued in developing an offbox
protocol for streaming media.
Hilarie
"Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com> 06/01/01 10:57AM
I don't understand your response Michael.
As I understand it, we'll discuss Network Appliance's submissions to two
standards bodies next week. My point, which I think is orthogonal, is that
during the evaluation of the requirements and proposals for a remote
procedure call mechanism for edge services, we need to evaluate using web
services as well.
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: "Michael W. Condry" <condry(_at_)intel(_dot_)com>
To: "Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>
Sent: Friday, June 01, 2001 11:28 AM
Subject: Re: Web Services (was: iCAP Issues at OPES Workshop)
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