W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

Re: Closure of LC86

From: David Hull <dmh@tibco.com>
Date: Thu, 21 Jul 2005 15:25:53 -0400
To: "Winkler, Steve" <steve.winkler@sap.com>
Cc: public-ws-addressing@w3.org, Mark Nottingham <mark.nottingham@bea.com>
Message-id: <42DFF6C1.1030209@tibco.com>
I think we've pretty much covered all the ground we can for now.

I'll be happy to support the additional wording to strengthen [message
id] for messages in general.  As for the rest, I'll be happy to discuss
it further if a good opportunity arises.

So at least everyone knows I'll be happy :-)

Winkler, Steve wrote:

> Hi David,
> <snip>If the idea is to have [message id] OPTIONAL but RECOMMENDED
> everywhere, I'm all for it.</snip>
> Yes, that is more or less what I'm advocating.  Less so because you
> make the leap that the message id would even be optional in requests
> where responses are expected, which goes against the the working
> group's current thinking.  All that I would like to do is strengthen
> (or add) the wording around strongly recommending (i.e. SHOULD) the
> use of message id in all messages.  I think that this is something
> that most, if not all, working group members would be comfortable with
> (informal conversations with other members have so far indicated
> this), but any proposal beyond that will require much more
> discussion.  You may have good arguments for going beyond that and
> making the id optional in cases where it is currently required, but I
> think this will be much more contentious and I don't want to go down
> that road at this point in time.
> Cheers,
> Steve
>     ------------------------------------------------------------------------
>     *From:* David Hull [mailto:dmh@tibco.com]
>     *Sent:* Thursday, Jul 21, 2005 11:30 AM
>     *To:* Winkler, Steve
>     *Cc:* public-ws-addressing@w3.org; Mark Nottingham
>     *Subject:* Re: Closure of LC86
>     Winkler, Steve wrote:
>>     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.
>     Would that include changing the MUST to SHOULD for replies?  I
>     gather from the discussion below that it wouldn't.  If that's the
>     case, I'm not against adding such a sentence, but I don't think it
>     changes anything materially.
>     If the idea is to have [message id] OPTIONAL but RECOMMENDED
>     everywhere, I'm all for it.
>     I think I may just be more comfortable with the a la carte
>     approach than much of the group is.  In my view, we're providing a
>     collection of very useful utilities.  The way to get them used is
>     to make them useful (which they are).  Requiring a facility
>     whether or not it's of use in a particular situation seems likely
>     to raise the bar for adoption.  I can actually see someone wanting
>     to be "lighter weight" and defining <NewmansOwn:{Reply,Fault}To>
>     with the same meaning as <wsa:{Reply,Fault}To> except that you
>     don't have to include <wsa:Action> and <wsa:MessageId> in order to
>     use it.  Or worse, quietly just not conforming and only paying
>     attention to <wsa:{Reply,Fault}To>.  I don't endorse either
>     approach, but I wouldn't be surprised if someone decided to take
>     one of them.
>     Now I can hear the reply coming from somewhere in the ether: "But
>     that's the beauty of the SOAP processing model:  You can define
>     your own headers if you don't like ours."  I think that's fine
>     when my headers don't overlap significantly with existing
>     standards, but it's not fine at all when my headers are playing in
>     essentially the same space as what's already there.
>     Is it more important to allow senders who don't need [message id]
>     for correlation to get replies even if they don't include [message
>     id], or for senders that do need [message id] to be warned that
>     some message they sent (they won't always know which one since
>     there's no [message id]) didn't include one?
>     I think the realistic answer is "it depends," and a receiver
>     should be able to behave either way (and advertise that behavior)
>     without breaking conformance.  That's why I'm much more
>     comfortable with "SHOULD fault" than "MUST fault" in section 3.3. 
>     I would prefer to see this handled by leaving the core flexible
>     but biased toward stricter behavior (i.e., faulting in this
>     case).  Bindings like the WSDL binding can then make strict
>     behavior the default while allowing loopholes for more lax
>     behavior.  Of course, they can do this anyway (this flavor of
>     endpoint is WSA conformant except ...), but it seems better to add
>     constraints to the core rather than to selectively override ones
>     that are already there.
>>     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" 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
Received on Thursday, 21 July 2005 19:26:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:10 UTC