Re: [HTTPSubstrate-16] Propoposed criticsm of RFC3205

Mark Baker and I were discussing this a bit off-line;
one of the messages made it to www-archive
http://lists.w3.org/Archives/Public/www-archive/2003Feb/0042.html
but I thought I would re-cast for TAG consumption:


Asking the IESG about whether RFC 3205 applies to web services
isn't very productive: "If the shoe fits, wear it."

RFC 3205 gives general advice about (re)using HTTP, and
if the considerations apply to Web Services and XML
protocol, then the RFC applies.

Rather than trying to analyze applicability in the
abstract by dissecting the words "substrate", consider
examples of XML protocol use, and ask whether the
considerations in the RFC apply to those examples.
I picked three examples: two from
  http://www.w3.org/2002/10/XML-Protocol-Charter 
    "getStockQuote"
    "validateCreditCard"
and one from
    http://www.w3.org/TR/soap12-part0/
that I will call
    "travelReservation"

I think these are good examples; surely the examples
upon which the group was chartered (and which the W3C
membership voted), and the example that the group has
producted (and put in the protocol tutorial) can be
considered "typical" or "representative" of what
XML Protocol and SOAP are intended to be used for.

Now, go through the considerations of RFC 3205
   http://www.ietf.org/rfc/rfc3205.txt
and ask the question "how does this consideration apply
to the three examples?". I think this is a useful
exercise, because it grounds the abstract discussion
in some real examples where the engineering tradeoffs
of one protocol design over another can be examined.


Section 2.1: Complexity ("HTTP adds unnecessary complexity")

Yes, HTTP adds unnecessary complexity for those three
examples: chunked encoding for responses, 3xx error messages,
byte ranges are unnecessary for all three. One might
think cache support would be interesting for getStockQuote
but in practice the cache validation reply is longer
and harder to generate than just the reply itself.
Requiring a client that wants to 'getStockQuote' to
deal with all of the HTTP error returns and conditions
adds 'unnecessary complexity'.

Section 2.2: Overhead
Yes, HTTP adds protocol overhead to these examples,
although the mitigations in section 2.2 also apply.
I wonder about the "travelReservation" example; I
believe real 'travel reservation' services would
have a more finer-grained interactions; initially expanding
the available airports for a given city in one transaction,
getting travel dates & airplane reservations settled
before selecting hotels, etc.
However, the XML protocol wrapping itself adds so much
overhead that the HTTP overhead isn't as significant,
even for what would otherwise be very short transactions.

Section 2.3: Security
HTTP security is unfortunately useless for most
SOAP applications; on the other hand, SOAP needs
(and doesn't seem to yet have) a standard security
mechanism that is useful for the example applications.
The HTTP mechanisms (digest authentication nad
TLS security) are inadequate for validateCreditCard
and for travelReservation; perhaps getStockQuote
has weak requirements for security, 
(where digest authentication might be sufficient
for allowing authenticated access to real time stock
quotes).

Section 2.4: Compatibility with Proxies, Firewalls and NATs

This is oft-discussed and perhaps a religious
argument, but the considerations apply to all
three examples:  firewall administrators should
be able to decide whether to allow getStockQuote
and travelReservation and validateCreditCard
independently of allowing use of web browsing.

Section 2.5: Questions
All of these questions are legitimate and have
interesting answers when applied to SOAP:

*  When considering payload size and traffic patterns, is HTTP an
   appropriate transport for the anticipated use of this protocol?

  perhaps the mitigations (persistent connections) overcome
  the costs, although there are still some questions about
  it in my mind. Part of the reason why it is still open
  is that it is unclear how the security context setup will
  be handled; e.g., security context of independent requests
  in a persistent HTTP connection are assumed to be independent;
  without a security design, it's hard to evaluate whether the
  HTTP overhead is burdensome.

* Is this new protocol usable by existing web browsers without
  modification?

  No, not at all. 

* Are the existing HTTP security mechanisms appropriate for the new
  application?

  No, generally not (as discussed).

* Are HTTP status codes and the HTTP status code paradigm suitable
  for this application?

  No, not at all (see below).

* Does the server for this application need to support HTTP anyway?

  Often not. While getStockQuote and travelReservation might be offered
  by sites that also offer HTTP access, it is unlikely that a server
offering
  validateCreditCard would also have a general web browser interface.

Section 3: Reuse of port 80

Certainly the considerations in this section apply to SOAP and
should be answered:

   o  The "new service" and traditional HTTP service are likely to
      reference different sets of data, even when they both operate on
      the same host.

   probably not; that is, if the same host offers SOAP and
   ordinary web access, it is likely that they will reference
   the same sets of data

   o  There is a good reason for the "new service" to be implemented by
      a separate server process, or separate code, than traditional HTTP
      service on the same host, at least on some platforms.

   Usually yes! In practice, on many platforms, SOAP processing
   has different enough performance, security and scalability
considerations
   to require that code base for SOAP services is disjoint from the
   code base for HTTP web browsing. This is the strongest argument for
   allocating a separate port.

   o  There is a good reason to want to easily distinguish the traffic
      of the "new service" from traditional HTTP, e.g., for the purposes
      of firewall access control or traffic analysis.

   Often! Both firewall access control and traffic analysis might well
   want to treat SOAP services separately from web browsing.

Section 4. Issues Regarding Reuse of the http: Scheme in URLs

These considerations apply to web services. The URL scheme for
web services is very likely to become widely used; I think the
arguments are strong for a new default port; setup and protocol
interaction are likely to be substantially different from those
of an ordinary HTTP server, and user interfaces might well be
able to exploit the difference between a URL prefix for
"soap" vs. "http".

Section 5: Use of MIME media types

This section's considerations apply to the discussion in SOAP
about use of application/xml vs. text/xml and the charset
parameter for SOAP messages.

Section 6. Issues Regarding Existing vs.  New HTTP Methods

This section applies to the discussion of XML protocol's use
of GET vs. POST vs. some other method.

Section 7. Issues regarding reuse of HTTP client, server, and proxy code

This section applies to the question of whether SOAP services
can reuse existing HTTP libraries and proxies.

Section 8.  Issues regarding use of HTTP status codes

This is a very important section which generally hasn't been
addressed by XML protocol and Web Services. While there has
been a lengthy discussion about the appropriateness of using
"500 Server Error" as a wrapper for ordinary SOAP-level protocol
failures, the other issues seem unaddressed: How should an
ordinary SOAP client react to "301 Moved Permanently" or
"303 See Other"? 

Section 9: Summary of recommendations regarding reuse of HTTP

I think all of these recommendations apply to SOAP:

   1. All protocols should provide adequate security

Surely this applies to SOAP and XML protocol. Surely
it is not part of the W3C Architecture that "some protocols
need not provide adequate security."


2. All protocols - including but not limited to those using HTTP -
      should not attempt to circumvent users' firewall policies,
      particularly by masquerading as existing protocols.
      "Substantially new services" should not reuse existing ports.

Surely the W3C is not in favor of the negative: "in some
circumstances, it is OK to circumvent users' firewall
policies.

3. In general, new protocols or services should not reuse http: or
   other URL schemes.

Surely this is a good policy for the Web Architecture; the only
question is whether "web services" is or isn't a new protocol
or service. Surely it isn't the W3C policy that only W3C-endorsed
protocols
should re-use HTTP, but not the protocols of any other organization?
Or that "any new protocol may use 'http' to designate any service
that bears any vague resemblance to HTTP".

4. Each new protocol specification that uses HTTP as a substrate
   should describe the specific way that HTTP is to be used by that
   protocol, including how the client and server interact with
   proxies.

Surely this is a good idea: if web services use HTTP, then analyzing
how it interacts with proxies and caching is crucial. The negative
"Some new protocols that use HTTP need not describe how they
interact with HTTP features, or how they interact with proxies"
shouldn't be W3C policy.

5. New services should follow the guidelines in section 8 regarding
   use of HTTP status codes.

The '500 server error' discussion on XML protocol was a long one,
and I don't want to repeat it here. However, having guidelines for
reuse of HTTP error messages in the face of other protocols is
crucial.

In summary: every topic in RFC 3205 seems to be applicable to
XML protocol and web services, in the question of 'use of HTTP'.
So asking the IESG 'did you really mean it' isn't very productive.
The shoe fits. 

Larry
-- 
http://larry.masinter.net

Received on Thursday, 13 February 2003 13:51:15 UTC