Issue 50 and points west

I've just been through the core spec and the issues list from top to 
bottom.  From this, I believe that there is a significant issue related 
to the anonymous endpoint and also to issues 6, 29, 38, 40, 44 and 50 
(and their various duplicates), which is not quite captured in any issue 
on the list.

At the top of section 3, we say:

    Message addressing properties provide references for the endpoints
    involved in an interaction. The use of these properties to support
    specific interaction is in general defined by both the semantics of
    the properties themselves and the implicit or explicit contract that
    governs the message exchange. If explicitly available, this contract
    can take different forms including but not being limited to WSDL
    MEPs and interfaces; business processes and e-commerce
    specifications, among others, can also be used to define explicit
    contracts between the parties.

This pushes most discussion of what MAPs "mean" into the relevant 
binding documents, but not all.  In particular, we cater specifically to 
the existing SOAP request/reply MEP by providing reply and fault 
properties, along with a predefined "reply" relationship.  This much 
seems fine to me, since the SOAP request/reply MEP is a useful fact of life.

However, it seems somewhat dangerous to say too much about the semantics 
of these within the core spec, as opposed to in the binding specs (which 
are on a somewhat later schedule :-).  I'm thinking in particular of the 
questions of anonymous destinations and what reply and fault endpoints 
may default to.  Note again that these are really only relevant to one 
family of MEPs.  Replies are not relevant to one-way messages (which we 
take to be fundamental), and faults are not relevant to pure one-way 
messages, though they do appear in the context of robust one-way 
messages.   This strongly suggests that reply and fault semantics are 
not core WS-Addressing concepts, as opposed to endpoints, EPRs and MAPs 
in general, which clearly are.

Therefore I propose the following edits relative to the current editor's 
draft of the core document.  The list may look long, but it's all minor 
variations on a theme, and all the edits are deletions.  In the 
following, please read "strike" as "strike from the core and move to the 
appropriate binding document (where we may further debate it)."  I would 
not be opposed to a bit of text pointing at the appropriate binding 
spec, as for example "the semantics of these properties in the context 
of WSDL and SOAP are further defined in the WSDL and SOAP binding 
documents".  I realize we are chartered to deal with existing WSDL and 
SOAP MEPs and I am in no way suggesting not dealing with them, nor do I 
mean to imply that the thought and discussion behind the text to be 
stricken was misdirected.  I am suggesting providing the minimum hooks 
needed in the core and providing the actual semantics in the bindings.
------------------------------------------------------------------------

   1. Amend the sentence in section 3 reading, "The use of these
      properties to support specific interaction is in general defined
      by both the semantics of the properties themselves and the
      implicit or explicit contract that governs the message exchange."
      to read "The use of these properties to support specific
      interaction is defined by the implicit or explicit contract that
      governs the message exchange."
   2. In the description of [reply endpoint] in section 3, strike all
      but the first sentence, so that the description reads "An endpoint
      reference for the intended receiver for replies to this message."
   3. In the description of [fault endpoint] in section 3, strike all
      but the first sentence, so that the description reads "An endpoint
      reference for the intended receiver for faults related to this
      message."
   4. In the description of [action] in section 3, strike all but the
      first sentence, so the the description reads "An identifier that
      uniquely (and opaquely) identifies the semantics implied by this
      message."
   5. In the description of [relationship] in section 3, strike the last
      sentence ("A reply message MUST contain a [relationship] property
      consisting of the predefined reply IRI and the message id property
      of the request message.").
   6. Strike the paragraph beginning "Due to the range of network
      technologies currently in wide-spread use ..." and the following
      paragraph beginning "Requests whose [reply endpoint] ..."
   7. In the description of /wsa:MessageID in section 3.1, strike all
      but the first sentence, so that the description reads "This
      OPTIONAL element (of type xs:anyURI) conveys the [message id]
      property."
   8. In the description of /wsa:RelatesTo in section 3.1, strike the
      last sentence, reading "This element MUST be present if the
      message is a reply."
   9. In the description of /wsa:ReplyTo in section 3.1, strike all but
      the first sentence, so that the description reads "This OPTIONAL
      element (of type wsa:EndpointReferenceType) provides the value for
      the [reply endpoint] property."
  10. In the description of /wsa:FaultTo in section 3.1, strike all but
      the first sentence, so that the description reads "This OPTIONAL
      element (of type wsa:EndpointReferenceType) provides the value for
      the [fault endpoint] property."
  11. In the description of /wsa:To in section 3.1, strike all but the
      first sentence, so that the description reads "This OPTIONAL
      element (of type xs:anyURI) provides the value for the
      [destination] property."
  12. Strike section 3.2