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

I guess what I am seeing in this discussion is that the requirements for 
wsa:messageId are not clear.

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.

However, if it is just for use in ws addressing correlation, then a URI 
would suffice, with no semantics on its contents.

With a clarification on such a restricted use, it should only be 
required when the reply to is present with a non anonymous value.

Other ws specs which need further semantics would be required to define 
their own identity elements.  This has the advantage of allowing their 
use when ws addressing is not being used.

Tom Rutt
Mark Little wrote:

>
> Tom, I understand where you're coming from, but are we not in danger 
> of widening the scope of WS-Addressing in this case, to the point 
> where it may be argued that "we" need a basic (core) addressing spec, 
> which says *where* things are, and then a message-interaction spec. 
> that describes individual message exchanges, including items such as 
> sequence ids, sliding window size etc? (To be honest, I think that 
> argument could be made today as-is, but I'm worried that we might 
> exhaserbate things.)
>
> Mark.
>
>
> Tom Rutt wrote:
>
>>
>> Perhaps index is the incorrect work,  but the foo 0 is different from 
>> foo 1 in my proposal.
>>
>> This scheme allows more scalable implementations (e.g, get uri at 
>> bootup, use system time when message composed cast as unsigned long 
>> for the integer portion of the message Id.
>>
>> If we did this change, the relibility specs might utilize ws 
>> addressing message Id when present in a message.
>>
>> Tom Rutt
>>
>> Rich Salz wrote:
>>
>>>
>>>> A [message id] value comprises a globalID part, and an optional 
>>>> index, which together uniquely identify the message.”
>>>
>>>
>>>
>>>
>>> So {foo}0 is different from {foo}1?
>>>
>>> If it's part of the identifier, why is it an index?
>>>
>>> I think this is confusing, and would like to see a stronger 
>>> justification for making *part* of the [message id] be non-opaque.
>>>
>>>     /r$
>>>
>>
>

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

Received on Monday, 6 June 2005 18:07:45 UTC