RE: Closure of LC86

Hi David,
 
I'll take the time to make it shorter:
 
What I'm advocating is adding a sentence that basically recommends that
a message id SHOULD be present in all WS-A messages (both requests and
responses).  The message id would still be, strictly speaking, optional.
As far as I understand you, we are in agreement on this point, so I
would like to limit any discussion for proposals to this scope at this
point.
 
See below for some curt (in the interest of brevity, not insolence)
retorts to the points I found the most salient. 
 
Cheers,
Steve
 
--------------------------
Steve Winkler
SAP AG
 
 


________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: Wednesday, Jul 20, 2005 2:22 PM
	To: Winkler, Steve
	Cc: public-ws-addressing@w3.org; Mark Nottingham
	Subject: Re: Closure of LC86
	
	
	Apologies that this is so long.  As Blaise Pascal once said, I
didn't have time to make it shorter.
	
	Winkler, Steve wrote: 

		 
		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.  

	First, I'm not comfortable with the notion that [message id]
should be REQUIRED so long as it doesn't impede correlation use cases.
Just going by that, I could require that every request include
<wsa:Please/> and every response include <wsa:HereYouGo/> and
<wsa:HaveANiceDay>.  These don't impede correlation, or anything else
for that matter, and they might improve the civility of network
commerce, so why not require them?  The only difference with [message
id] is that we can identify particular cases where [message id]
certainly does help, namely auditing and cases where correlation is
needed and no other mechanism is available.  But by that reasoning we
should require that WSS or WS-Trust or whatever be used everywhere WSA
is because they are certainly useful in some cases where WSA will be
used. 
	 
	<SW>
	<wsa:HaveANiceDay> and your other examples provide no value.
MessageId provides great value.  We are writing a core spec here on
which other specs will hope to compose.  If they can be relatively sure
that most default implementations of WS-A will have a message id, they
will be more likely to reuse rather than roll their own.
	 </SW> 
	
	In this context, the performance hit is a symptom, not a central
factor.  I'm more concerned that we are making a sweeping requirement
(but one that presently only sweeps over requests and leaves other
messages unswept) without a convincing case that the thing to be
required is always needed, and indeed with definite evidence to the
contrary.   
	 
	<SW>I have yet to see such evidence.</SW>
	 
	 This seems wrong from the beginning, but I respect that others
may view the burden of proof differently.  In any case, I'm more
interested in reaching consensus (see below) than arguing over the
burden of proof (and thence over the burden of proof in the argument
over the burden of proof ... :-).
	

		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.


	In a broad sense, being able to uniquely identify a message is
essential to correlation.  However, this doesn't have to be done by a
message id.  In the well-known case of SOAP/HTTP, we identify the
message, even in the presence of pipelining, by when it comes back over
the response channel.   
	 
	<SW>This is transport specific.  WS-A core concepts are, per our
charter, to be transport agnostic.</SW>
	 
	 There are other cases where an endpoint will effectively be
created for the purposes of one message only, so identifying the message
is trivial.  I've also mentioned the case where the application-level
payload carries a transaction id or something similar and correlation is
effectively handled at the application layer.  In these cases, the
[message id] handshake is not adding any value.
	 
	<SW> By this rationale, we might as well just all go home.
Everything can be done in the application payload, and everyone can roll
their own systems.  We're shooting for interop here.  If you want to do
something extra, fine, go ahead, but don't expect it to work with my
systems out of the box.</SW>
	 
	I'm more interested, though, in cases where correlation is or
can be done by other SOAP-visible means.  For example, suppose I have
defined a choreography such that for any given instance, there will be
exactly one message for each [action].  Each instance has its own
context ID header.  Suppose that one piece of this happens to be a
request/response, but the request/response endpoint naturally doesn't
know that it's participating in the choreography.  In a nutshell, when
the receiver of the response sees [action]=..../fooResponse, it knows
that that's the one and only fooResponse message for that instance of
the choreography.  It doesn't need a message id.
	 
	<SW>True, but only because the choreography spec can depend on
the presence of Action to make it's determination.  I would argue that
other specs could rely on message id to do other interesting things in
the same manner.</SW>
	 
	Or, on a completely different tack, suppose I know that
reliability is in play.  The reliability layers that we know of use a
(sequence id, sequence number) pair to uniquely identify each message.
Rather than create another id on top of that, why not just tell the
receiver "put the sequence id, sequence number" of the request in the
reply and I'll know what to do.  Let me be clear that I think this would
be completely out of scope for us.  But I'm not sure we want to actively
discourage it, either.
	 
	<SW>There is nothing to stop the writers of that spec from
creating a URI encoding scheme to include the sequence id and sequence
number in the WS-A message id URI.  Reuse achieved.</SW>
	 
	I would like for clients to be able to use whatever's handy for
correlation, or not correlate at all.  In this view, [message id] is our
standard header element for identifying messages -- which I think is
pretty close to the charter -- and the rule in section 3.3 is a way of
leveraging this as one way of providing correlation, if it's needed.
The obvious concern here is that it might hurt interoperability if the
client can correlate any way it wants.  But I think this misrepresents
what's going on.  Interoperability comes from the server being able to
advertise exactly what it does and does not guarantee with respect to
the MAPs, not from the server refusing to accept request messages that
may work perfectly well for the client.  As long as the client knows
that the server will always reflect the [message id] of the request in
the [relationship] of the reply, provided [message id] is present in the
request, the client always knows enough to interoperate.  The server has
told the client the rules unambiguously, and it can assume the client
knows what it's doing. 
	 
	<SW>No real disagreement here.  I'll reiterate that there will
be less chance of a problem if the client is encouraged to always send a
message id.  I personally still feel that a WS-A request message that
expects a response should still be required to contain a message id.  If
you don't want this, maybe WS-A isn't the right choice for you.</SW>
	
	Suppose some later server advertises "I will reflect [message
id] if it's present in the request.  I will also reflect (sequence
number, sequence id) if they're present."  Is this any less
interoperable than what we have now?  I would argue that if anything,
it's more interoperable.  It will provide correlation for a client that
includes [message id], and it will also provide correlation for a client
that's using a reliable connection.  The only argument that I can see
here is that this might undermine the universal use of [message id].
Personally I'm uneasy with trying to use a correlation facility as a
lever to try to get people to support auditing, and I also feel that the
proposal I made is a better lever anyway.
	
	<SW>I was never attempting to use correlation to support
auditing.  I simply used auditing as a single use case (there are more)
to show that having message ids generally be contained in WS-A messages
is useful.  I don't even really want to get into the correlation
discussion at all if I don't have to.</SW>
	 
	(I note in passing that the charter itself refers to the
definition of Identifier given in the Web Services Architecture.  This
reads "Identifiers are used to identify resources. In the architecture
we use Uniform Resource Identifiers [RFC 2396]
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#RFC2396>  to identify
resources."  The second sentence is disputed.  In short, there's not a
lot of guidance offered here as to what we're trying to accomplish.)
	
	

		  

		

		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?  
		

	Indeed.  I believe we're not too far from agreement, if not on
underlying philosophy, at least on the end result.
	

		 

		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? 
		

	Well, I do have a concrete proposal that might be worth
considering at some point.  I don't think this is the right point -- if
I did, I would have pushed for consideration at the meeting.  Right now,
I would rather go for CR and see what the director makes of all this,
realizing there may never be another opportune moment.  Them's the
breaks.  This was never a deal-breaker for me.  I do strongly feel that
the spec could be better in this regard, but I don't feel that the
current handling of [message id] is  irreparably broken.  And to be
honest, plenty of specs have made it out the door with bigger flaws.
	 
	<SW>It's not a deal breaker for me either, but I think the spec
would be better off with the guidance that a message id SHOULD be
present in WS-A messages, unless a particular implementation has a good
reason not to include it.</SW>
	 
	However, I would like people to consider the current proposal
and in particular consider whether it supports universal unique ids for
messages better than the status quo.  As far as I can see, it does, by
tilting the landscape heavily in favor of ids on all messages, not just
requests.  
	
	<SW>+1 with the focus, though I think your proposal is too broad
to gain widespread support. I would rather focus on the focus, so to
speak.</SW> 
	 
	If there's a general agreement that it does, then we can
consider whether to try to bring it in at some point.  Since the
proposal is a response to the group's closing of an LC issue, the
director will be aware of it and may also weigh in on whether it's worth
considering.  Beyond that, it's up to the group to decide whether
there's a strong agreement that it's an improvement (there may not be)
and if so, whether there's a good way to bring it in without wrecking
the schedule.
	
	In any case, I couldn't let an idea that seemed worthy of
consideration and might make life better for everyone just lie.  So
there it is.
	
	Hope this helps.
	

		

		 

		 

		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