W3C home > Mailing lists > Public > www-archive@w3.org > February 2003

RE: [HTTPSubstrate-16] Propoposed criticsm of RFC3205

From: Larry Masinter <LMM@acm.org>
Date: Mon, 10 Feb 2003 20:42:02 -0800
To: "'Mark Baker'" <distobj@acm.org>
Cc: <www-archive@w3.org>
Message-ID: <000e01c2d187$ec3b61e0$6ace8642@MASINTER>

> It appears to be there now.  lists.w3.org was down for a 
> while earlier, which probably explains it.

There are a couple of messages missing from

> > Every section in RFC 3205 seems to apply directly
> > to SOAP. Rather than trying to avoid discussion
> > by claiming that "they didn't really mean SOAP",
> > why not consider what it says?
> I have, believe me. 8-/
> > Section 2.1: Yes, HTTP adds unnecessary complexity
> > to SOAP.
> Again, it depends how you're using SOAP.  If you're using it 
> as an HTTP extension, then I'd say it does not.  If you're 
> using it by tunneling a new protocol over it, then I would 
> agree with you.


lists two example applications: "getStockQuote" and
"validateCreditCard". HTTP adds unnecessary complexity
for those two example applications.

It also adds unnecessary complexity for the examples
in the Soap 1.2 primer. There's no need for '100 continue'
or chunked encoding or content negotiation or '3xx moved'
error messages to handle travel reservations. Yet any
SOAP requestor that wants to make a travel reservation
has to deal with all of the HTTP error messages that
might come back. That's "unnecessary complexity".

> > Section 2.2: Yes, HTTP adds unnecessary processing
> > and bandwidth overhead to SOAP.
> Ditto.

Well, for getStockQuote it is clear that HTTP adds
unnecessary processing and bandwidth over a simpler
RPC. For the examples in the Soap 1.2 primer, the
bandwidth is swamped by the verbosity of the 'travel
reservation' request, but I wonder if that's a realistic
example; most of the travel reservation examples I've
seen have had finer granularity on the conversation,
e.g., discovery of valid airports before requesting
reservation dates, discovery of airline availability
before asking about hotels, etc. I think real travel reservation
systems operate with more shorter requests & responses,
to the point where the unnecessary processing and
bandwidth overhead might actually be significant.

> > Section 2.3: Yes, HTTP security is useless for
> > most SOAP applications, and SOAP needs (and doesn't
> > have) some other standard security mechanism.
> Ditto.

Well, getStockQuote doesn't need security, but
HTTP has nothing useful for validateCreditCard,
since you want privacy and mutual authentication.

Similarly, HTTP has inadequate security for a real
travel reservation system. The example is unrealistic
because there's no identity -- who is making the
reservation? Who is paying? Is there a credit card
for holding the hotel reservation? 

> > Section 2.4: Yes, compatibility with Proxies
> > and firewalls is an issue, and SOAP attempts
> > to circumvent sites' security policies.
> Ditto.

This one is a little harder to judge, but you
might imagine sites wanting to control automatic
service invocation differently than web browsing,
if only for performance sake.
> > Section 2.5: 
> >   - HTTP is not an appropriate transport for
> >     many anticipated SOAP traffic patterns.
> >     HTTP is not an appropriate transport for
> >     very small SOAP requests
> Ditto.

Normally, 'getStockQuote' would be very small.

> >   - No, SOAP is not usable by existing web browsers
> >     without modification
> Right.  And many other HTTP agents.

The fact that there are other services which
also use HTTP even though it isn't compatible
with existing web browsers doesn't remove
the value of this factor as an element of
> >   - No, existing HTTP security mechanisms are not
> >     appropriate for most SOAP applications
> See 2.3 response above.

> >   - No, existing HTTP status codes and the HTTP
> >     status code paradigm is not suitable for
> >     reporting SOAP status
> Same answer as above; depends how you use it.

HTTP status codes are useless for 'validateCreditCard'
and for the examples in the Soap 1.2 primer,
although you might be able to use them for

> >   - No, many SOAP clients and SOAP servers have
> >     no other need to support HTTP
> Ditto.

The service which offers 'validateCreditCard' is
unlikely to want to offer web browsing at the
same host.
> > Section 3:
> >    - Yes, SOAP services and traditional HTTP
> >    services are likely to reference different
> >    sets of data
> Ditto.

Travel reservations might have both a web site and
a SOAP service, but validateCreditCard is unlikely
to have a HTML web interface.
> Ok, I'll stop there, as hopefully you get my point.  Thanks 
> for taking the time to go through the RFC point-by-point 
> though; that's very
> thoughtful.   You should archive this somewhere, it seems a shame to
> lose in our private mailboxes.

> BTW, FWIW, going through this exercise, I didn't think that 
> I'd be responding "ditto" to as many points as I did.  Interesting.

I think you should go back again through the issues with
the examples in mind and give realistic assessments of
their applicability for those examples, rather than trying
to make a 'first principles' argument that 'it depends'.
Of course it depends on how you use HTTP with SOAP,
but the applications actually given in the Soap 1.2 primer
and the original charter don't support the case that
RFC 3205 doesn't apply.

> > Whether or not Keith was thinking of SOAP's usage
> > of HTTP or not, the shoe fits.
> Did you see the just-posted TAG ftf minutes?  They had a 
> great idea for checking with the IESG;
> "Action RF: Write a response to IESG asking whether the Web 
> services example in the SOAP 1.2 primer is intended to be 
> excluded from RFC 3205."

This is argument by authority. Whether or not the IESG
intended it doesn't matter (I think they did, but it's
irrelevant). The question is, as a principle of good
engineering design, do the design considerations in RFC
3205 apply for the applications for which SOAP is actually
being used. I claim yes. This doesn't require appealing
to any authority to determine.
> Those examples, if you haven't seen them, are what I would 
> consider as SOAP-as-an-HTTP-extension.  I don't believe that 
> 3205 has much relevance to that use of SOAP and HTTP.

RFC 3205 lists a set of considerations. I think they're
all applicable. In some cases, in balance, the case for
using HTTP might be mildly supported, but for the most
part, it isn't. In any case, it isn't because RFC 3205
isn't applicable.

Received on Monday, 10 February 2003 23:42:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:19 UTC