Re: Proposal for lc75/lc88

+1 to leaving the behavior "undefined" for duplicate [message id].

How to handle messages with duplicate [message id] is very context 
(application / other protocols involved) sensitive. For example in 
reliable messaging (over unreliable transfer) reliability is typically 
achieved by sending the *same* message again (and over) until an ack 
message is received and hence a receiver should expect to receive 
duplicate (or a message with the same [message id]) and be prepared to 
eliminate duplicates without returning an error or faulting. Whereas in 
other situations a duplicate message could in fact be treated as an error.

Regards, Prasad

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