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

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

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Wednesday, 8 June 2005 16:28:59 UTC