- From: Mark Little <mark.little@arjuna.com>
- Date: Tue, 21 Jun 2005 12:10:40 +0100
- To: David Hull <dmh@tibco.com>
- CC: Prasad Yendluri <pyendluri@webmethods.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
+1 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 www.arjuna.com
Received on Tuesday, 21 June 2005 11:11:31 UTC