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

Re: Why is [message id] required for requests but not for other messages?

From: Mark Little <mark.little@arjuna.com>
Date: Tue, 21 Jun 2005 12:10:40 +0100
Message-ID: <42B7F5B0.7060000@arjuna.com>
To: David Hull <dmh@tibco.com>
CC: Prasad Yendluri <pyendluri@webmethods.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>


David Hull wrote:

> Prasad Yendluri wrote:
>> That was one of the issues that was raised in 
>> http://www.w3.org/2002/ws/addr/lc-issues/#lc1 also.
>> TC was not prepared to make it even a SHOULD requirement in the 
>> context of  discussion of that issue :)
>> Now that 86 is closed with no action also, I am not holding up hopes 
>> but I think having [message id] in all messages is very useful.
> I'm sympathetic, in that the current semantics provides neither the 
> benefit of having [message id] everywhere nor the flexibility of 
> having it truly optional.
> On the other hand, I've always seen "very useful" as OPTIONAL, with 
> REQUIRED meaning "base functionality just won't work without it".
> So properly echoing [message id] /if it's there/ should be REQUIRED.  
> Including it in the first place should be OPTIONAL.  Or more 
> precisely, it should be OPTIONAL by default.  If an endpoint wants to 
> require [message id] on every message, it should be able to advertise 
> this and still conform, but the default assumption should be that a 
> missing [message id] is a non-event.
>> David Hull wrote:
>>> If [message id] is to be leveraged for uses other than correlation,
>>> particularly duplicate elimination and security, wouldn't those
>>> considerations apply at least equally well to non request/reply
>>> interactions?  If not, what is the basis for requiring [message id] for
>>> requests but not for other types of message?

Mark Little
Chief Architect
Arjuna Technologies Ltd
Received on Tuesday, 21 June 2005 11:11:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC