Closure of LC86

This message records my dissatisfaction with the closure of Last Call
issue 86, entitled "[message id] should be optional." [1] and proposes a
novel resolution that would resolve LC86.  This proposal should also be
an improvement on the status quo regarding the concerns that caused LC86
to be closed with no action originally.

Issue LC86 was closed with no action at the Berlin face to face.  TIBCO
and others voted against this closure.  Since then, there has been
further discussion of the use cases that [message id] might or might not
support, and the notion of [message id] uniqueness has been clarified in
the resolution of LC75.  Both of these events, together with the
proposal below, introduce new information relevant to the resolution of
LC86.

In the discussion of use cases for [message id], several possible uses
were proposed.  In my understanding, only two held up to closer
scrutiny, namely

    * The original use case of message correlation.
    * The use of a standard, transport-independent [message id] on all
      messages for various auditing purposes.

Neither of these is grounds for making [message id] a REQUIRED
property.  The original issue description argues that [message id] need
not be REQUIRED on all messages in order to support message correlation,
both because message correlation may not always be necessary, even when
the receiver is acting in a request-response fashion, and because
correlation can and in some cases likely ought to be accomplished by
other means.  I also argue that producing a [message id] and checking
for its presence and uniqueness consumes resources that may be scarce in
some scenarios.  In any case, I do not believe that the correlation case
was a major factor in closing LC86 with no action.

I have argued separately [2] against the second case, both on the
grounds that the status quo does not effectively support it, and on the
grounds that it is out of scope for the core of addressing, is not
needed in all WSA deployments and so should not be REQUIRED. 
Deployments that require a universal unique [message id] can mandate it
separately without contradicting anything in the core, even if [message
id] is made OPTIONAL in the core.

My understanding is that LC86 was closed because it was felt that
requiring [message id] would promote the auditing use cases and making
it optional would weaken this.  However, the status quo only requires
[message id] in the case of request messages.  Further, it effectively
discourages it in other cases.  The behavior of a node receiving a
message with a duplicate [message id] is unconstrained.  There is thus
no point in including a [message id] anywhere it is not mandated, as
there is always the risk of accidental collision for any of various
reasons.  While this risk may not be large, it is easily eliminated by
omitting [message id] altogether.  The status quo thus supports auditing
of requests while undermining auditing of everything else.  Further, it
is difficult to see how to fix this.  The receiver of a reply or a
fire-and-forget one-way message does not have the option of throwing a
fault on receiving a message with a missing [message id].

I believe that the auditing use cases can be better supported while
allowing flexibility for deployments that do not want [message id], with
small changes to the existing text.  Namely

    * Amend the description of the [message id] property to add the
      italicized text:

        An absolute IRI that uniquely identifies the message. When
        present, it is the responsibility of the sender to ensure that
        each message is uniquely identified. The behavior of a receiver
        when receiving a message /that lacks a [message id] or /that
        contains the same [message id] as a previously received message
        is unconstrained by this specification.

    * Change MUST to SHOULD in the paragraph in section 3.3 reading

        In either of the above cases, if the related message lacks a
        [message id] property, the processor MUST fault.

    * Add the italicized text to the following paragraph in the same
      section:

        [relationship]: this property MUST include a pair of IRIs as
        follows; the relationship type is the predefined reply URI
        "http://www.w3.org/@@@@/@@/addressing/reply" and the related
        message's identifier is the [message id] property value from the
        message being replied to, /if it is present/; other
        relationships MAY be expressed in this property

This strongly encourages the presence and uniqueness of  [message id] in
/all/ messages in just the same way the the present text strongly
encourages its uniqueness alone.  However, the softening of MUST to
SHOULD allows flexibility in situations where [message id] is not
wanted.  In such cases, receivers may advertise, or it may otherwise be
made known, that messages lacking a [message id] will be processed
normally.  Then, and only then, do senders know that it is safe to omit
the [message id].

This proposal provides the desired ubiquitous unique id by default while
allowing deployments to explicitly waive the requirement when
appropriate.  It is thus an improvement on the status quo in both
flexibility and in support for auditing.

References:

[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc86
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0054.html
and following thread