RE: Closure of LC86

 
Hi David,

 

Since I was probably the most vocal opponent of making wsa:MessageId
optional, I feel a response is probably warranted.  I think that some of
the ideas in your proposal could make the status quo better, but I don't
agree with all of it.  

 

As you'll remember from the Berlin F2F, I was arguing against making
message id optional.  I actually went the other way and advocated the
utility of an ever-present message id, and I used the auditing scenario
as an illustrative use case.  This was just one use case, but I do think
that message ids are generally useful, for responses as well as all
requests, and not just in the case of a request where reply message is
expected.  

 

The main objection to this that I saw would be the performance hit that
the sender of a message would incur when ensuring the uniqueness of the
message id.  This makes sense to me, and I would be willing to relax my
original standpoint from a REQUIRES to a SHOULD contain a unique id,
which would still allow performance conscious senders to omit the id
while encouraging the use of the message id in all normal cases. 

 

I would prefer, however, to stop there.  I have not yet seen a
convincing use case where including a message id would be prohibitive
for correlation.  In fact, I think it's obvious that being able to
uniquely identify a message is of paramount importance in correlation.
If you choose to use an out of band correlation mechanism and have it
supersede what is defined here, then so be it.  The WS-A charter
requires us to specify properties which allow for the correlation of
messages, and I think that a message id should still be REQUIRED when a
response is expected.  

 

It seems that the two people with the most opposite opinions have come
quite a bit closer, but what should we do about it now?  

 

The issue was closed in Berlin, perhaps a bit hastily at the end of a
long meeting where people were jetlagged, but it was still closed.  Are
you just registering your dissatisfaction, or do you have a course of
action you would like to propose?  

 

 

Cheers, 

Steve

 

 

---------------------------

Steve Winkler

SAP AG 

 

 

 

 

 
 


________________________________

	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
	Sent: Tuesday, Jul 19, 2005 7:17 AM
	To: public-ws-addressing@w3.org; Mark Nottingham
	Subject: 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"
<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.ht
ml and following thread