Re: An analysis of mustUnderstand and related issues

Noah,

Thanks for putting this together. Although long, it is exceptionally
easy to read and understand. A few small comments:

> The Body is somewhat special in that, in the common case where a
> message carries one principle request, that SHOULD BE encoded in
> the Body, with other headers intended to provide supporting or
> extension function.  

s/one principle request/data or a particular payload/ 

To me, this aspect of body has always overshadowed the anonymous
actor nature of it. Without a body, we'd need a means of nominiating
a block for all of the other blocks to perform their functions on, by
default. While a means of specifying this might still be necessary
(i.e., 'encrypt all blocks'), it's nice to have a default, and it
makes it easier for developers to understand the SOAP model.


> "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. 

I like this turn of phrase. I'd like to see an effort to identify a
few message exchange patterns, and map them onto transport bindings,
when we get to an appropriate point.


> SOAP transport bindings are responsible for supporting the
> request/response abstraction (always?  optionally?).  

Optionally, I'd think. Some bindings may be inherently one-way, where
correlation needs to be supplied by a module. Or are you suggesting
that correlation be supplied in the binding definition in these
cases?


> Response messages can be assumed to 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.

This is where I think it would be useful to have a separation of
transport message exchange pattern and application message exchange
pattern. For example, with SMTP, the transport intermediaries
may very well not be the same on the way back as they were on the way
out...


> Better yet, I just had another idea regarding attributes.  What if
> we have a new mustUnderstand header that lists the global
> attributes you must understand:
[...]

I like this.


> Here is one possible design, consistent with the above requirements
> and assumptions. In general, it provides for specifying a partial
> order which must be observed in processing headers whether or not
> those headers are destined for distinct actors.
[...]

I like this as well.


> If nothing else, we should be reluctant to make changes that break
> compatibility with SOAP version 1.1.

While I understand the motivation here, I don't agree with it. These
changes will not force implementors to completely rewrite their SOAP
processors (and we *should* try to avoid changes that do that). They
are easy to implement, address significant problems with the SOAP
model, and offer real functionality.


> In any case, I think a detailed clarification of SOAP V1 .1, such
> as the one I attempted in the first section would be very useful. 
> Perhaps this manifests itself in the abstract model, but I think it
> is ultimately the SOAP (or XMLP) specification that should be made
> crisp and unambiguous.  That is the document that most of our users
> will read.

I agree wholeheartedly.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Saturday, 12 May 2001 00:36:05 UTC