RE: Proposal for lc75/lc88

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

Received on Tuesday, 14 June 2005 17:20:55 UTC