XML Protocols List of Proposed Clarifications

Latest revision: 5/29/2001      Last revised by: Noah Mendelsohn

 

 

Proposed Clarification: Special status of body

Number:  1             Identifier:  ClarifyBody
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:
SOAP implies that Body is just syntactic sugar for a header entry with no actor, but there is some implication that Body is the preferred way of carrying whichever request represents the primary function of the message. Some clarification may be useful. For example, if multiple headers are sent to the default actor, is there any defined processing order relative to the body? If a header calls for "logging", for example, can it be processed after the body itself?

Proposed Clarification: Clarify rules for delivering fault messages.

Number:  2             Identifier:  FaultDelivery
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:
SOAP very clearly indicates situations in which a fault must be generated, but only sometimes is it clear whether and how and to whom to deliver the fault. Some of that looseness is intentional, but more clarity is needed in the explanation. (see fuller analysis in the document attached to the referenced e-mail.)

Proposed Clarification: Precisely describe message path semantics

Number:  3             Identifier:  MessagePath
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:
The SOAP specification says: "Regardless of the protocol to which SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination." As discussed in the referenced e-mail, "SOAP does refer to a message path, which appears to be post facto the ordered locations and processing (there is vagueness here) that actually were visited in processing the message. There is at least an attempt to associate special behavior with the "end" of the path, where header entries with no actor are processed. The details of all this need to be stated more precisely." This is related to the suggestion that the notion of message pattern (e.g. request/response) also be clarified.

Proposed Clarification: Use Infoset to define messages?

Number:  4             Identifier:  UseInfoset
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:
(this may be a bit more than a clarification) The SOAP specification currently says that "A SOAP message is an XML document that consists of a mandatory SOAP envelope...". There may be advantages to a formulation along the lines of: "Each SOAP message is defined as an XML document Infoset. Although many bindings, such as the HTTP binding provided herein, will use the serialized form of XML provided by the XML 1.0 Recommendations as augmented by the Namespaces recommendation, other bindings can adopt other serializations. In other words: this specification describes each message in the form of abstract XML Element and Attribute information items. Many protocol bindings will transmit this information in the form of the corresponding XML 1.0 documents, but other on-the-wire representations can be used by particular bindings if desired. For example, some bindings may use compressed representations."

Proposed Clarification: Clarify message patterns (e.g. Request/Response)

Number:  5             Identifier:  MessagePattern
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:

(this description is taken from the cited e-mail message) Although SOAP messages are fundamentally one-way, the HTTP binding serves as an example of the possibility for transport bindings to introduce higher level message patterns such as request/response. Presumably, other bindings could also support a request response model, but the SOAP specification does not mandate any particular relation between request/responses implemented by HTTP for example and SMTP (I think it should).

Interestingly, the request/response model is explicitly exploited in a transport independent way by the RPC specification in chapter 7. The specification does not state, but strongly implies that RPC responses will indeed be returned to the originator of the request, and that the transport binding will be responsible for doing the necessary addressing. Certainly the HTTP binding does this.

The relationship of faults to message patterns is even more subtle, and perhaps will need improvement or clarification. Specifically, section 4.4 of the SOAP specification gives information about what must be in a fault message. However, since messages are fundamentally one-way, and since there is no general-purpose notion of a request/response or other higher level pattern, nothing is stated in general as to where if at all faults are delivered. In this respect, the specification is nearly vacuous: it mandates that a fault message be constructed in certain manner, but it allows it to be dropped on the floor before anyone sees it.

That's what the spec says. Reading between the lines, here's what I think it is really trying to say:

"Although SOAP messages are fundamentally one-way, SOAP supports the construction of higher level message patterns on top of that. In addition to one-way, this specification includes a well architected notion of request/response, which certain applications and SOAP processors may choose to use when sending SOAP messages. SOAP transport bindings are responsible for supporting the request/response abstraction (always? optionally?). Transport bindings that support request/response are responsible for providing the ability for an intermediary or SOAP end point to return response or fault messages back to the originator of a request. Response messages can be assumed to take the exact reverse path of requests; so response and fault messages can be inspected if desired by the same actors the processed the outbound request {not sure about that..maybe we should make request/resp apply only to the endpoints?}. SOAP RPC uses the request/response message pattern, and is therefore usable only on with transport bindings that support request/response.

The delivery rules for Fault messages are message pattern specific. The rules for the two message patterns supported by this version of the SOAP specification are:

  • For one way messages, no mandatory behavior is given for generating or routing fault messages, except that if delivered they must be in the form of section 4.4.
  • Faults generated during the transmission and processing of a request message in a request/response pattern are delivered on a best-effort basis to the originator of the entire message sequence (which may or may not be the insertion point of the header that caused the fault), passing as for all responses along the reverse of the same path as the request. Transport bindings that implement the request/response pattern are responsible for either eventually delivering the response or fault, or else eventually reporting a broken connection to the requester. No specific time limit for such reporting is given. The faults generated by problems with the response message itself are treated in the same manner as faults in a one-way message: no mandatory behavior is given for generating or routing fault messages generated by such failed response.

Proposed Clarification: Check all must understands first & process atomically?

Number:  6             Identifier:  AtomicMustUnderstand
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:
Various readers of the SOAP specification have interpreted it to say either (1) a given actor must check that it understands all mustUnderstand headers before attempting any processing and must roll back any side effects of early MU headers if later ones fail due to application level problems or (2) that MU headers can be discovered, processed, and checked individually. Not only does this require clarification, it seems to affect the suitability of MU as the basis for certain extension features (i.e. those which must be noticed before other features are used).

Proposed Clarification: Clarify the terms application, actor & related notions of identity.

Number:  7             Identifier:  ActorIdentity
Proposed by:  Noah Mendelsohn

Soap specification reference(s):

Email reference(s):

Description:

The SOAP specification contains statements such as "A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below: ... Identify all parts of the SOAP message intended for that application (see section 4.2.2)", etc. and also "The SOAP actor global attribute can be used to indicate the recipient of a header element. The value of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next" indicates that the header element is intended for the very first SOAP application that processes the message. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP. Omitting the SOAP actor attribute indicates that the recipient is the ultimate destination of the SOAP message"

SOAP thus makes clear that in certain circumstances, the same actor can have more than one URI identifier (e.g. as "next" and also something explicit). The SOAP specification should be clarified to remove all ambiguities relating to such aliases. For example, the specification should be unambiguous regarding the processing of mustUnderstand headers, generation of faults, etc. Furthermore, the specification should make clear whether users can or cannot choose to create their own aliases, and if so what processing rules apply.

A special case of this issue arises at the end of the message path. It seems that this point can be addressed by at least two means, an explicit "next" and the more common absence of an actor. Can there be other user supplied names that also are acted upon by the end point?