W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2005

RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 12 Jan 2005 18:52:11 -0500
To: <paul.downey@bt.com>
Cc: public-ws-addressing@w3.org
Message-ID: <OF5D9D81D1.17691300-ON85256F87.0082027E@lotus.com>

Paul Downey writes:

> I'm assuming that a similar processing model also
> applies to SOAP 1.1, though i couldn't find that
> explicitly stated in the note or the WS-I Basic
> Profile.

Be a bit careful in what you assume :-), and also in equating SOAP 1.1 
with the WS-I BP.  One of the main reasons for having a SOAP 1.2 was that 
SOAP 1.1 was inappropriately (IMO) vague on such questions.  SOAP 1.2 
provides explicit rules on the order of mU checking where SOAP 1.1 did 

I was not specifically involved in the development of the WS-I BP, but in 
many cases it applies to SOAP 1.1 clarifications that in fact were 
inspired by the SOAP 1.2 rules.  In this case, the WS-I basic profile says 

 R1025   A RECEIVER MUST handle messages in such a way that it appears 
that all checking of mandatory header blocks is performed before any 
actual processing. [SOAP12]

Which seems to clearly indicate that the rule is enforced, and is indeed 
inspired by SOAP 1.2.  FWIW, I would prefer that SOAP 1.2 and the BP were 
a bit clearer on what I know was intended:  "For a node to 'understand' a 
header block that node must be prepared to process the header in a manner 
that fully conforms to whatever specifications were provided by the 
'owner' of the QName identifying the block.  Furthermore, where multiple 
header blocks appear in a single SOAP envelope, a node may be said to 
understand any subset of them if and only if their specifications, taken 
together provide for their correct processing in combination (and, as 
already stated, if the node is prepared to implement those 

It is already clearly stated in SOAP 1.2, and I think implied in the BP, 
that header blocks can interact and affect each others' semantics and 
processing rules.  Taking all this together, you get what I said in my 
earlier note:

* You can invent header blocks that control order of processing for other 
header blocks
* You can include ordering semantics in the specification of header blocks 
that have other useful semantics (e.g. process all "BeginTransaction"s 
before the body, and process all "EndTransactions" after the body; process 
all wsa:ReplyTo's in document order, acting on the semantics of the first, 
and treating the others as no-ops."

Again, I'm not recommending an approach for wsa, but these are the 
building blocks given to you by SOAP, as I understand them.



Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 12 January 2005 23:53:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC