Re: Proposal for lc75/lc88

If all that is required is that the messageId be unique enough for 
correlation purposes, then we can get rid
of the requirement for global uniquness over space and time.

I draw the following carefully crafted text from ITU-T X.733 (1991) on a 
NotificationID for correlation, to show a minimal requirement adopted by 
an earlier standard, on uniqueness required for correlation:

"
8.1.2.8    Notification identifier
This parameter, when present, provides an identifier for the 
notification, which may be carried in the Correlated notifications 
parameter (see below) of future notifications.  Notification identifiers 
must be chosen to be unique across all notifications of a particular 
managed object throughout the time that correlation is significant. A 
Notification identifier may be reused if there is no requirement that 
the previous notification using that Notification identifier be 
correlated with future notifications.  Generally, Notification 
identifiers should be chosen to ensure uniqueness over as long a time as 
is feasible for the managed system.
"

If I just change "notification" to "message" , "managed object" to 
"endpoint", and "correlated notifications" to "reply" throughout the 
above text, we arrive at the following as a starting point for 
discussion of a minimal requirement for correlation
 (it scopes uniqueness to the sending endpoint.):

"
8.1.2.8    MessageId
This parameter, when present, provides an identifier for the message, 
which may be carried in the relatesTo parameter (see below) of replies 
to that message.  Message identifiers must be chosen to be unique across 
all messages sent by an endpoint throughout the time that correlation is 
significant. A MessageId may be reused if there is no requirement that 
the previous message using that MessageId be correlated with future 
replies.  Generally, MessageIds should be chosen to ensure uniqueness 
over as long a time as is feasible.
"

Tom Rutt

Jonathan Marsh wrote:

>+1 to an explicit disclaimer such as:
>
>"The value of [message id] uniquely identifies the message. When
>present, it is the responsibility of the sender to insure that each
>message is uniquely identified. The behavior of a receiver when
>receiving a message that contains the same [message id] as a previously
>received message is undefined. No specific algorithm for the generation
>of unique values of [message id] is given, however methods such as the
>use of an IRI that exists within a domain owned by the sender combined
>with a sequence number satisfies the uniqueness criteria but may not be
>the best practice from a security perspective."
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org [mailto:public-ws-
>>addressing-request@w3.org] On Behalf Of David Hull
>>Sent: Tuesday, June 14, 2005 8:32 AM
>>To: Marc Hadley
>>Cc: Mark Nottingham; public-ws-addressing@w3.org
>>Subject: Re: Proposal for lc75/lc88
>>
>>
>>Marc Hadley wrote:
>>
>>    
>>
>>>On Jun 13, 2005, at 5:56 PM, Mark Nottingham wrote:
>>>
>>>      
>>>
>>>>The value of [message id] uniquely identifies the message. When
>>>>present, it is the responsibility of the sender to insure that each
>>>>message is uniquely identified. A receiver MAY treat all messages
>>>>that contain the same [message id] as the same message. No specific
>>>>algorithm for the generation of unique values of [message id] is
>>>>given, however methods such as the use of an IRI that exists within
>>>>a domain owned by the sender combined with a sequence satisfies the
>>>>uniqueness criteria but may not be the best practice from a
>>>>        
>>>>
>>security
>>    
>>
>>>>perspective.
>>>>
>>>>        
>>>>
>>>As discussed on yesterdays telcon, the problem I have with the above
>>>language is that its not clear what behavior we are allowing when we
>>>say: "a receiver MAY treat all messages that contain the same
>>>[message id] as the same message". Is my receiver compliant with WS-
>>>Addr if it:
>>>
>>>(i) silently ignores a second message with the same [message id] as
>>>      
>>>
>>a
>>    
>>
>>>previously received one
>>>(ii) generates a fault when it receives a second message with the
>>>same [message id] as a previously received one
>>>(iii) processes a second message with the same [message id] as a
>>>previously received one
>>>(iv) all of the above or some other combination
>>>
>>>I would prefer that we spell out the allowed behavior or, if we
>>>      
>>>
>>don't
>>    
>>
>>>constrain it any way, be explicit that the behavior is undefined.
>>>      
>>>
>>I'm would be happy with an explicit disclaimer.  We have a couple
>>already (e.g., about EPR comparison and lifecycle), which are entirely
>>appropriate.
>>
>>    
>>
>>>Marc.
>>>
>>>---
>>>Marc Hadley <marc.hadley at sun.com>
>>>Business Alliances, CTO Office, Sun Microsystems.
>>>
>>>
>>>      
>>>
>
>
>  
>

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

Received on Tuesday, 14 June 2005 19:05:50 UTC