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.

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.  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.  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.

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.

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.

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.

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.

(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.

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.

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" 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
>