Re: Another go at lc75 and lc88 language (correction)

Again, whether [reply endpoint] is anonymous and whether [message id] is
needed are completely separate.  The client needs [message id] for
correlation when it cares about correlation and there is no other means
of correlation (see here
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0170.html>
for a slightly dated case analysis, reading "some means of correlation"
for "in-reply-to").  Because of the mechanics of [reference parameters],
this turns out to be never, strictly speaking.

I don't believe multiple-hop routing changes this, but if someone can
demonstrate a solid counterexample I'd be very interested to see it.

Tom Rutt wrote:

>
> Based on this discussion, is see wsa:MessageId as an element designed
> soley for use with ws addressing.
>
> Since WS addressing does not need the concept of a sequence ID or a
> sequence number for its purposes, I no longer am pushing
> for having wsa:MessageId be a complex type.
>
>
> wsa:MessageID is required for correlation purposes, only when a "ws
> addressing reply" is expected
> (and  the wsa:reply to property is not anonymous, ).
> We need to realize that a "reply"  to another ws-xxx spec's header in
> the form of
> another soap header in a future message may not be considered a
> ws-addressing reply.
> For example, if a one way message (which by  wsadd essing sematics
> expects no "application level" reply), is sent with a
> ws-Reliability (or ws reliable messageing) header, then the
> reliability spec will include a soap header in a future message which
> carries acknolowedgment of receipt or delivery of that message to
> the sending reliable messaging processor.  However this is not a ws
> addresssing reply
>
> In fact, both ws-reliability and ws-reliabile messaging specs have
> their own reliability:messageId (they both use a uid, integer pair)
> and both specs have their own "reliability:AckTo" address, which is
> distinct from any ws-addressing Reply To.
>
> I think this "orthogonality" is good for independence of ws-xxx
> processing semantics.
>
> But, at the same time, we must not confuse this "reliability
> acnowledgement" as a ws addressing reply.
>
> Tom Rutt
>
>
>
> Doug Davis wrote:
>
>>
>> Robert,
>>   I get worried when some WS-* spec wants to set some other WS-*
>> spec's data.  What would do you if WS-AAA has one algorithm, WS-BBB
>> has another and both specs are used at the same time?  If some other
>> WS-* spec wants some unique ID for its own purposes its safer if it
>> just defines its own header and not try to overload or change WS-A's.
>> thanks,
>> -Doug
>>
>>
>>
>> *"Robert Freund" <bob.freund@hitachisoftware.com>*
>> Sent by: public-ws-addressing-request@w3.org
>>
>> 06/08/2005 06:11 AM
>>
>>
>> To
>>     <paul.downey@bt.com>, <tom@coastin.com>, <mark.little@arjuna.com>
>> cc
>>     <rsalz@datapower.com>, <public-ws-addressing@w3.org>
>> Subject
>>     RE: Another go at lc75 and lc88 language (correction)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> If we specify that the message id must be unique, but do not specify the
>> algorithm, does that not permit other protocols to define a specific
>> algorithm more to their liking as long as the result remains an IRI?
>> Would that not supply adequate flexibility?
>> -bob
>>
>> -----Original Message-----
>> From: public-ws-addressing-request@w3.org
>> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
>> paul.downey@bt.com
>> Sent: Tuesday, June 07, 2005 9:12 AM
>> To: tom@coastin.com; mark.little@arjuna.com
>> Cc: rsalz@datapower.com; public-ws-addressing@w3.org
>> Subject: RE: Another go at lc75 and lc88 language (correction)
>>
>>
>> Tom
>>
>> > I guess what I am seeing in this discussion is that the
>> requirements for
>> > wsa:messageId are not clear.
>>
>> I don't see that at all. I see we have messageId for correlation,
>> though I heard during the discussion in Berlin several potential
>> use-cases enabled by having a mandatory messageId. These included,
>> but were by no means limited to, transport independent message
>> correlation, logging and auditing by a transparent proxy observing
>> messages being exchanged, and elimination of duplicate messages.
>>
>> > If it is intended to be a general purpose message id for use in wsa
>> > message correlation as well as for other uses, then
>> > we might want to include the uid,integer pair.
>>
>> I don't see how that follows at all. The introduction of integers
>> implies to me you are thinking about some kind of windowing protocol
>> where messages may be collated, missing messages may be identified
>> and requested to be retransmitted within a range of messages. Possibly
>> even that the sequence number will roll-over and be reused.
>>
>> That goes way, way beyond addressing, and isn't something we should
>> be following at all. From a procedural POV, i'm puzzled as to
>> what LC issue introducing such complexity and restriction
>> on the format of messageId would resolve.
>>
>> > However, if it is just for use in ws addressing correlation, then
>> > a URI would suffice, with no semantics on its contents.
>>
>> I'm OK with a URI, but don't follow the reasoning.
>>
>> > With a clarification on such a restricted use, it should only be
>> > required when the reply to is present with a non anonymous value.
>>
>> No. I disagree. That's making matters more complex and dependent
>> upon the binding for a single hop, rendering messagId less useful in
>> end to end message passing scenarios where the message passes over
>> HTTP and then another transport such as Email/MQ.
>>
>> > Other ws specs which need further semantics would be required to
>> define
>> > their own identity elements.
>> Possibly, possibly not. It seems to me that making messageId
>> mandatory and unique will make it more attractive for other
>> specs to layer upon it for identifying a unique message.
>>
>> > This has the advantage of allowing their
>> > use when ws addressing is not being used.
>>
>> That's their business.
>>
>> Paul
>>
>>
>>
>>
>>
>>
>