Re: What does core section 3 actually require?

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

Received on Tuesday, 3 May 2005 19:17:23 UTC