SOAP protocol review

A while back, I made some detailed comments about design issues
in SOAP and in the SOAP 1.1 specification, sent to the
soap@discuss.develop.com
mailing list. These comments were based on SOAP 1.1 as published at
http://www.w3.org/TR/SOAP/.

While there were responses to some of the details of my arguments,
I don't think the main points have been addressed; I would hope that
doing so would improve SOAP substantially, and increase its
interoperability,
robustness, and applicability.

This message is a summary of points made in more detail before; I
hope it isn't necessary to repeat all of the details. In the interest
of keeping track of topics, it might be better to discuss these one
at a time.

SOAP protocol design issues:

*  use of port 80 by default, and "http" URL scheme

   SOAP will be more reliable and work in more situations and not interfere
   with standard firewall configuration policies were it to use a new port
   allocated for SOAP explicitly, and to denote that port by using a
different
   URL scheme.

   This wouldn't disallow using port 80 and "http" in situations where
   such use were mandated, but it would avoid interference with interception
   proxies and discourage protocol masquerading.

   (There was a disturbing report that one of the released software tools
   might *only* works on port 80; is this true?)

   (Following the same lines of reasoning, it might be advantageous to use
   application/soap-request and application/soap-response instead of
   text/xml for the SOAP bodies. In particular, since many of the normal
   conventions of XML (PIs, DTDs, etc.) are disallowed in soap messages,
   the message bodies shouldn't be treated as if they were arbitrary XML.)


*  use of 500 Server Error instead of 200 for application level errors.

   As has been noted in other messages to the list, SOAP would be more
   reliable and have fewer cases of interference by proxies if it used
   normal HTTP "200 OK" success returns for SOAP methods that were
successfully
   interpreted and parsed but which had application errors.

   You may believe that such interference will be rare, but so far there
   has been no satisfactory justification given for incurring the
possibility.

*  The versioning mechanism (using URIs for) is fragile, since there
   is no default behavior that an old SOAP interpreter can perform
   (other than simple failure or 'discarding') that would allow useful
   interoperability with a new SOAP message generator.

   (Admittedly, designing protocol versioning mechanisms is hard, but it's
    important to get right early, since it can't be added later.)

SOAP 1.1 specification issues (these may be protocol issues, but the
specification is unclear enough to tell):

*  including implementation details as "MUST"-level requirements:

   Some of the protocol requirements labeled as "MUST" in the SOAP 1.1
   specification seem to require implementation details that have no
   explicit interoperability requirements. These requirements are likely
   'sound implementation advice' which are miscast.

   In general, the "MUST" and "SHOULD" requirements in the SOAP 1.1 document
   are unjustified (that is, the document gives no justification).

*  under specified behavior when SOAP messages are received with
   DTDs or PI. (Not something that can be "fixed in a later version").

*  Unclear specification of the use of encodingStyle. This is similar
   to the versioning issue; the failure/fallback protocol isn't clear.

*  No clear use for the 'SOAPAction' HTTP header (not recognized by any
known
   proxy, or useful in any kind of serious firewall configuration, no rules
   for dealing with mismatch of SOAPAction with actual action, for example.)

Received on Sunday, 11 June 2000 05:04:13 UTC