Questions about the current draft.

    *   In section 3 in the text "The basic interaction pattern from
      which all others are composed is "one way". In this pattern a
      source sends a message to a destination without any further
      definition of the interaction." what does "without any further
      definition of the interaction" mean?  In many cases, notably
      request/reply, the message sent will contain information further
      defining the interaction, but I doubt this is what the text was
      meant to refer to.  I would prefer to replace "without any further
      definition of the interaction" with something more like "with any
      further interaction determined by the message content and by
      context", or better yet, strike both sentences.  I don't mind
      saying that we support one-way operations, but if we start to talk
      about composing them, we'll need to say quite a bit more than we
      do about how to do it.
    * In the text "More advanced MEPs may require additional message
      addressing properties [...]"  As Jonathan points out, "You can add
      new properties to your messaging property bucket but since they
      aren't defined in the spec it would be incorrect to call them
      WS-Addressing 1.0 properties."  Since we use the term "message
      addressing properties" to refer specifically to the list in
      section 3, should we just say "may require additional properties"
      or otherwise use a different term?
    * As I've said, it's not clear from the description given /how/ one
      would provide additional properties.  Shall we adopt Gudge's
      suggestion (as I understand it) that any SOAP header with an EPR
      value be regarded as a Message Addressing Property?
    * Given a SOAP message and armed only with the current specs, can
      one work out the exact values of all MAPs or not?
    * If reply or fault endpoints are defined, we say message id is
      required.  Why? (see [1])
    * We motivate the "anonymous" endpoint with "Due to the range of
      network technologies currently in wide-spread use (e.g., NAT,
      DHCP, firewalls), many deployments cannot assign a meaningful
      global IRI to a given endpoint."  In point of fact, /any/ use of
      SOAP/HTTP in the usual synchronous request/reply (and other cases
      besides) would require an anonymous reply address, as the
      reply/fault response always goes back over the back channel. 
      Could we just say this instead of talking about firewalls?
    * Do we in fact require a wsa:replyTo header element to be sent in a
      plain vanilla synchronous request?  This is basically the same
      question as in [2].  The only answer I got for that was Jonathan
      saying, "yes, we do require it".  I wanted to double-check that
      this is the case.  If it is, is it correct to infer that MAPs just
      do not apply to synchronous SOAP/HTTP request/reply as currently
      practiced?
    * Could we simplify the treatment of [relationship] by replacing the
      current bag with a single [in reply to] property, leaving further
      extensibility to the same approach we're proposing for
      endpoints?   We don't even try to address any relationships other
      than reply, so why complicate treatment of the simple case?


[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0170.html 
(read "in-reply-to" as "in-reply-to and message id", or just as "message 
correlation".  Also, the requirement that "the request address is not a 
multicast" is too strong -- you can get by without message correlation 
in certain multicast cases as well)
[2] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0190.html