RE: Proposal for new last call issue: Some unprocessed headers should stay

Following up on Henrik's point about the contract between a sender and the "next" recipient, I notice that SOAP 1.1 had said something explicit about the notion of the contract not extending beyond the first player of a particular role. Specifically, section 4.1.6 [1] there states:

"Not all parts of a SOAP message may be intended for the ultimate destination of the SOAP message but, instead, may be intended for one or more of the intermediaries on the message path. The role of a recipient of a header element is similar to that of accepting a contract in that it cannot be extended beyond the recipient. That is, a recipient receiving a header element MUST NOT forward that header element to the next application in the SOAP message path. The recipient MAY insert a similar header element but in that case, the contract is between that application and the recipient of that header element."


> I respectfully disagree with this interpretation. Look for example at
> the description of "next" and "ultimateReceiver". The "next" role
> doesn't say "anybody who can play next is it". It says the 
> first "next"
> is it. We say something similar for the ultimate receiver: it's the
> first ultimate receiver, not some other ultimate receiver after that.
> 
> The notion of a contract has been in SOAP for a long time and was very
> much behind the introduction of the "role" concept. If we 
> went with the
> interpretation above then I think it would not only erode the 
> concept of
> a contract but also of the mU flag: If a role is only sometimes the
> first recipient, then why should it honor the mU flag if that can be
> fulfilled by some other node acting in that role?
> 
>

Perhaps some text along these lines could be restored in the main spec. if not, I'll try to wpork it into the Primer.
Thanks
Nilo
[1] http://www.w3.org/TR/SOAP/#_Toc478383499