[message id] should be optional

  Currently the [message id] property is required whenever [reply 
endpoint] or [fault endpoint] is present.  While correlating messages 
via [message id] is useful, it is not necessary in several plausible cases:

    * Correlation is handled at the transport level.  In such a case a
      sender may still wish to include a [reply endpoint] with an
      anonymous address, in order to ensure that a particular reference
      parameter appears in the reply, but there is no need for a message
      id per se.
    * Correlation context is provided at the SOAP level by other means,
      for example via a header containing a context or transaction ID. 
      In such a case, the receiver of a reply may already be tracking
      which messages arrive with which [action] properties in a
      particular context, and have no need to look at a message id.
    * Correlation is handled at the application level.  The body of a
      request may contain a transaction id or other correlating token,
      with this token echoed in the response, or the application
      semantics may otherwise make message ids unnecessary.
    * Correlation doesn't matter because there is no meaningful reply. 
      This basically means a "void" operation with no application-level
      faults defined.
    * Correlation doesn't matter for other reasons.  For example, if
      several requesters send requests, all of which are directed to the
      same [reply endpoint], whose job is simply to accumulate some
      aspect of the messages received without regard to what produced
      them.  The server has no need to know it is being used in this
      way, and there is no reason to require message ids.

In general, the receiver or a request has no way of knowing how the 
sender may or may not be correlating replies, and has no reason to care.

Even if an identifying token is needed for message correlation, there is 
no need to define a [message id] property.  The [reply endpoint] may 
contain any identifying token at all, for example <me:myRelationship 
type="me:InReplyTo">0xdeadbeef</me:myRelationship>.  By the existing 
rules, this will be echoed into any replies sent to the reply endpoint.  
Indeed, this is one way of handling correlation by context or 
transaction id as well.  The main value added by the [message id] 
property is that there is no need to duplicate this information in the 
[fault endpoint], in the case where both [reply endpoint] and [fault 
endpoint] are defined.  This is potentially useful, but clearly not 
essential.

Making [message id] mandatory has at least these moderate but definite 
drawbacks:

    * In cases where correlation is already being done by other means,
      carrying a redundant [message id] provides needless opportunity
      for error and confusion.
    * Producing a globally unique id for each message takes time, which
      may matter in high-volume or resource-constrained environments.
    * Similarly, requiring recipients to needlessly check for [message
      id] and echo it back also takes time.
    * In practice, client implementations are liable to produce
      non-unique IDs on the assumption that it doesn't matter anyway. 
      This misbehavior is generally not worth detecting, as it would
      require servers to remember IDs of incoming messages, but if
      undetected it can lead to mysterious behavior if that assumption
      becomes false, as correlating by a non-unique ID may well work by
      accident, most of the time.

In general, the receiver of a message should be liberal in what it 
accepts and not go out of its way to prohibit behavior that may be 
useful to the rest of the system.  Requiring [message id] without being 
able to know whether or not it is actually needed runs counter to this 
principle.