W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: Proposal for lc75/lc88

From: Mark Little <mark.little@arjuna.com>
Date: Tue, 21 Jun 2005 12:11:12 +0100
Message-ID: <42B7F5D0.9060302@arjuna.com>
To: Prasad Yendluri <pyendluri@webmethods.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, Marc Hadley <Marc.Hadley@Sun.COM>, Mark Nottingham <mark.nottingham@bea.com>, public-ws-addressing@w3.org

+1

Prasad Yendluri wrote:

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

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com
Received on Tuesday, 21 June 2005 11:12:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT