What does core section 3 actually require?

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:
          o 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
          o 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
          o MUST fault if there is no wsa:ReplyTo header.
          o also should fault if there is no wsa:Action, or a
            wsa:ReplyTo or wsa:FaultTo but no wsa:MessageID
          o 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.