Re: What does core section 3 actually require?

Sorry.  I had been undecided as to whether to file this as an LC comment 
or just send it to the list, and forgot to change the recipient list 
before sending.

We will be filing actual LC comments imminently.  I've been trying to 
avoid thrash on the LC comments list that would come of filing an issue, 
clarifying it, reformulating it and probably refiling it etc., as with 
the recent issue against the WSDL binding.  In this case, it's not 
(quite) clear whether to comment that

    * The core is essentially "message-oriented" but some
      "endpoint-oriented" statements appear to conflict.
    * The other way around.
    * The core is needlessly convoluted but actually defines reasonable
      rules.
    * The core is needlessly convoluted and, what's worse, defines
      unreasonable rules.
    * The core is just unclear and no one can really say for sure what
      it means (popular opinions notwithstanding).
    * Some linear combination of the above.

I'll spare you a lengthy dissertation on the merits of achieving a clear 
shared  understanding of the meaning of a spec before proceeding to LC ...

Mark Nottingham wrote:

> David / Everyone --
>
> Please do not cross-post between the comments and the public list; the 
> comments list is only for collecting comments, and for the WG's 
> responses. Discussion of David's issue should take place on the 
> public-ws-addressing list.
>
> Thanks,
>
>
> On May 3, 2005, at 11:56 AM, David Hull wrote:
>
>>  Following on to yesterday's conversation ...
>>
>>  There appear to be (at least) two different ways to parse the 
>> requirements in section 3 of the core, though evidently only the 
>> first was intended.  I'll call one "message-based" and the other 
>> "endpoint-based".  While neither term is completely apt, I hope that 
>> they're suggestive and reasonably clear.  I'm going to sidestep the 
>> issue of non-SOAP bindings for the nonce.
>>
>>  In the message-based view, the requirements mainly pertain to what 
>> it means for a message to be WSA compliant, with a bit about what a 
>> WSA compliant endpoint should do with a complaint message, with no 
>> restrictions on what a compliant endpoint may do with a non-compliant 
>> message.
>>
>>  In this view
>>     •     A message for which no reply is expected is compliant if it 
>> has a wsa:Action header element in its SOAP envelope and  
>> non-compliant otherwise.
>>     •     A message for which a reply is expected is compliant if it 
>> has wsa:Action, wsa:ReplyTo and wsa:MessageID header elements in its 
>> SOAP envelope and non-compliant otherwise.
>>     •     A receiver which, through whatever means, understands that 
>> a reply is expected for a message must follow these rules:
>>     ◦     If the message contains wsa:Action, wsa:ReplyTo and 
>> wsa:MessageID elements, then the reply MUST contain
>>     ▪     An appropriate wsa:Action.
>>     ▪     A wsa:To header containing the [address] of the wsa:ReplyTo 
>> or wsa:FaultTo header as appropriate (unless that [address] was 
>> anonymous, in which case the header may be omitted).
>>     ▪     Additional headers for the [reference parameters] as per 
>> the SOAP binding.
>>     ▪     A wsa:RelatesTo header, optionally with @RelationshipType 
>> set to http://.../reply
>>     ◦     Otherwise, the message is not compliant, and the endpoint 
>> may do anything it pleases.
>>     •     A receiver which, through whatever means, understands that 
>> no reply is expected for a message may do anything it pleases whether 
>> the message is compliant or not.
>>  Evidence for this view in the text of the core spec includes:
>>     •     The phrase "reply to a WS-Addressing compliant request" 
>> (emphasis added) at the beginning of section 3.2
>>     •     The phrase "when formulating a fault message as defined in 
>> 3.2 Formulating a Reply Message" in the description of the [fault 
>> endpoint] abstract property.
>>     •     The absence of any other rules directly constraining 
>> endpoint behavior.
>>  In the endpoint-based view, the requirements mainly pertain to the 
>> behavior of compliant endpoints, with the message form constrained by 
>> these requirements.
>>
>>  In this view
>>     •     An endpoint which does not expect to give a reply expects a 
>> wsa:Action header to be present in incoming messages.  If there is 
>> none, it should send a fault if it can figure out how to.  Similarly, 
>> it should fault if there is a wsa:ReplyTo or a wsa:FaultTo and no 
>> wsa:MessageID.
>>     •     An endpoint which expects to give a reply
>>     ◦     MUST fault if there is no wsa:ReplyTo header.
>>     ◦     also should fault if there is no wsa:Action, or a 
>> wsa:ReplyTo or wsa:FaultTo but no wsa:MessageID
>>     ◦     MUST formulate a reply message as described above.
>>  Evidence for this view in the text of the core spec includes:
>>     •     The phrase "If none [i.e., no [reply endpoint], which must 
>> appear as wsa:ReplyTo] is present, the processor MUST fault." in list 
>> item 1 ("Select the appropriate EPR") in section 3.2
>>     •     The phrase "The sender MUST use the contents of the [reply 
>> endpoint] to formulate the reply message as defined in 3.2 ..." in 
>> the description of the [reply endpoint] abstract property.
>>     •     The phrase "If this property is present the [message id] 
>> property is REQUIRED" in the same description and in the description 
>> of [fault endpoint] (together with the requirement that [message id] 
>> be realized as wsa:MessageID).
>>     •     The presence of a "Message Addressing Property Required" 
>> fault in section 5.2 of the SOAP binding.
>>
>
> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>
>