RE: [i95, i22] - Proposal for clarifying use of SOAPAction

Excellent summary and I think very much to the point. There is one
dimension that I would like to add which has an impact on B and that is
the granularity if the SOAPAction header field value.

At one end of the scale, it is possible to have a distinct SOAPAction
header field value per SOAP message type and at the other end, the
SOAPAction header field can be used to indicate a more abstract service
which covers a potentially open-ended set of message types.

During the discussion on this list and on the soapbuilders list, it has
become clear that both extremes are in use as well as several middle
positions. ebXML for example has a more generic value saying that "this
is ebXML stuff" whereas other services has a specific value per method
invocation. To some degree, this was not difficult to anticipate - the
SOAP/1.1 definition enables both cases and says nothing about the
granularity of the SOAPAction header field value.

Personally I think stability is the more important part of SOAPAction
values and that the values should not change simply because new message
types are supported unless we expect applications using the SOAPAction
header field to be updated at the same rate as message types. From an
administration point of view, I don't think that is feasible.

Regarding C, because SOAPAction is an RFC 822 header field and these
header fields live in a single namespace (partially managed by IANA), it
is possible for header fields to "float" between various protocols that
support RFC 822 header fields. Note here that I am careful to
distinguish between RFC 822 and MIME as the MIME relationship to HTTP is
slightly more complex.

This doesn't mean that the header field has any meaning in any other
protocol than HTTP and it is definitely possible to ignore or define
alternative solutions. What would be unfortunate is if it ended up
having *different* meanings depending of the protocol. 

Of course, if one goes outside the RFC 822/MIME based protocols then the
parameter may (if so decided) have to be carried within the envelope.

If we start to look at what SOAP bindings to other protocols like for
example TCP would look like, then it is not unlikely that SOAP processor
would like to see a hint of what is going on in the message before
having parsed all the way down to the body. At least in the simple case
of a SOAP Fault, it is likely to have an impact on how SOAP processor
would likely treat the message. That is, SOAPAction might have a useful
purpose even if having to be carried within the SOAP envelope.

Henrik

>B. As Doug and others have pointed out, having a fixed mapping 
>from the contents to the SOAPAction ensures that (a) 
>SOAPActions can be generated automatically and therefore (b) 
>can be automatically provided when an SMTP
>message transitions to HTTP.   Lacking such a standard mapping 
>means that
>any description of a SOAP service (e.g. WSDL) must include not 
>just a description of the envelope, but also mechanisms for 
>managing SOAPAction. It also suggests a lack of ability to 
>share code at the receiving end to do the check of #3.  On the 
>other hand, Henrik is right that particularly in the non-RPC 
>case, we lack a fixed convention for mapping an envelope into 
>an action---maybe I'm sending you a purchase order because I 
>want you to order something, or maybe I'm sending it to a 
>filesystem for filing.  So, I see this as a tradeoff that 
>requires a bit more discussion.
>
>C.  I think it's useful to view SOAPAction as an artifact of a 
>particular binding, in this case HTTP.  Other bindings, 
>including others running over HTTP, might or might not use 
>similar mechanisms.

Received on Tuesday, 1 May 2001 23:55:53 UTC