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

Re: Proposal for lc75/lc88

From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Date: Fri, 17 Jun 2005 09:28:17 -0700
Message-Id: <f5e860c1a1979a2447a9ea3c93ce0d53@oracle.com>
Cc: <mark.nottingham@bea.com>, <public-ws-addressing@w3.org>, <Marc.Hadley@Sun.COM>
To: <paul.downey@bt.com>

Hi,
   I would say the correct interpretation id (iv) -- all or some or none 
of the above.

   The reason for sticking in the MAY sentence is not to mandate any 
particular behavior but to clarify and emphasize the point that what a 
receiver chooses to do when receiving a message with a previously 
received message_id is not defined by the WSA spec. This was the best 
wording Bob and I could come up with when trying to translate the 
concept into W3C specese.


On Jun 15, 2005, at 5:50 AM, <paul.downey@bt.com> wrote:

>
> Marc wrote:
>
>> 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
  yes if the app has  requirement/policy that duplicates are 
"eliminated" and ignored
>> (ii) generates a fault when it receives a second message with the
>> same [message id] as a previously received one
yes if the app has a requirement/policy that receipt of a duplicate 
should never happen and is considered to be an error
>> (iii) processes a second message with the same [message id] as a
>> previously received one
yes if the app has no requirement/policy wrt duplicate elimination and 
is perfectly happy to process "duplicates"
>> (iv) all of the above or some other combination
that's the point -- "higher level" specifications/protocols may choose 
to impose more restrictive behavior

>>
>> 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.
>
> +1 defining the behaviour in terms of how a receiver treats a duplicate
> messageId seems more useful than trying to constrain what a sender,
> intermediaries, or the message path may do. I tried to make this exact
> point verbally at the F2F.
>
> For WS-Addressing, my preference is to allow a receiver to ignore
> duplicate messages (i) or explcitly state the behaviour is undefined 
> (v).

I guess it comes down to how you interpret the MAY.

Because I suspect the most common use of messageid is to identify 
duplicates and do something appropriate it, a note explaining the above 
would be fine with me too. My interpretation of the MAY is that it is 
just a way of signaling that the behavior that is the object of the MAY 
is not illegal wrt to the spec containing the MAY. I.e. you could 
choose to throw a fault in this case, or not, but the justification is 
not because of something the spec mandates.

jeff

>
> Paul
>
>
>
>
>
--
Jeff Mischkinsky					jeff.mischkinsky@oracle.com
Director, Web Services Standards		+1(650)506-1975
Consulting Member Technical Staff           500 Oracle Parkway, M/S 4OP9
Oracle                                                              
Redwood Shores, CA 94065
Received on Monday, 20 June 2005 08:01:09 GMT

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