- 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