RE: CR 23 omnibus

for some reason, my mail filter marked this message as "Junk"
and my "brainsian" filter is also having trouble disputing
that statement.

Could you please rephrase this more succinctly, ideally in terms 
of proposed changes to our CANDIDATE RECOMMENDATION and LAST CALL 
documents?

thank-you,
Paul


-----Original Message-----
From: public-ws-addressing-request@w3.org on behalf of David Hull
Sent: Thu 2/23/2006 6:29 AM
To: public-ws-addressing@w3.org
Subject: CR 23 omnibus
 
Both Chris and Umit raise valid points.  I'm afraid that if I try to reply to both Chris and Umit inline, it'll just end up confusing matters more, so I'm going to try to reset and summarize.  If in the process I miss any major points, I'm sure Chris and Umit, if not others, will be kind enough to point this out.  But please check carefully.  Given the length this message has grown to, what you're looking for is likely to be in there somewhere.

Chris expresses discomfort with expressing anonymous in terms of messages and not in terms of channels.  I agree that this is not what one might expect at first, but it's the result of much discussion and IMHO it's the right call.

If you want to be really strongly-typed formal-methods pedantic about it, the type of [destination] and of the [address] property of an EPR is not really IRI.  It's really "real address" | none | anonymous.  None and anonymous are represented as IRI, but they're not meant to be directly dereferenceable.  This is obvious in the case of none. It's slightly less obviously built in to anonymous's DNA;  Anonymous is meant specifically for cases where there is no dereferenceable URL.

The WG has (wisely, IMHO) sidestepped the issue of "logical" vs. "physical" addresses, but none and anonymous are not really either.  They're more like behavioral cues.  If you see "none", don't send anything.  If you see anonymous, use a binding-specified facility instead of generically dereferencing a URL.

Because of this, anonymous doesn't quite behave like the other children.  If I send several messages to mailto:dmh@tibco.com, I can assume that they all arrive at the same place.  There may be various tomfoolery going on to negate this, and we can get into logical/physical arguments over what happens if I forward my email elsewhere, but we've agreed to sweep this under the rug.  Anonymous won't fit under that rug because it's clear that, even as we currently narrowly define it, it can refer to two indisputably different recipients in two different messages.  This is the "don't do that then" case for AcksTo, where we know full well that sending A's acks in response to a message from B is not guaranteed to do what we want, but the question is how to capture this intuition rigorously.

At the least it seems useful to note, somewhere, that if you intend to send multiple messages to anonymous it's up to you to either make sure that they all end up in the same place or that you don't care if they don't.  This applies directly to the AcksTo case, but very likely applies elsewhere as well.

Because of this difference in behavior, and because of the inherently binding-dependent nature of anonymous, and because we have only so far rigorously defined the behavior of anonymous within a very narrowly delimited scope, I don't believe that there is any realistic chance that it can be defined generically in such a way that it can be used like any other IRI in [address] or [destination].  We certainly haven't had much luck with such a project since I've been involved in the group and it seems a little late for it now.  If anything, WS-RX's requirement to piggyback headers on to other messages may complicate matters further and we haven't even gone near that, dealing instead in entire messages.

Three recent attempts have been:


1.	The original resolution to CR4:

	When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address of an EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP request-response message exchange pattern provides such a channel for response messages. For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: Adjuncts <> ] puts the reply message in the HTTP response.
	

2.	Katy's text:

	The "http://www.w3.org/@@@@/@@/addressing/anonymous" <http://www.w3.org/@@@@/@@/addressing/anonymous>  URI MAY be specified as the [address] of an EPR to designate that the target endpoint is reached by a channel of the underlying SOAP protocol binding.  The specification of the channel to which the "http://www.w3.org/@@@@/@@/addressing/anonymous" <http://www.w3.org/@@@@/@@/addressing/anonymous>  URI refers depends on the Message Exchange Pattern (MEP) and on the defined semantics of the EPR in question.  Any underlying protocol binding supporting the SOAP request-response MEP provides such a channel for response messages.

3.	Chris's text:

	{The "http://www.w3.org/@@@@/@@/addressing/anonymous" <http://www.w3.org/@@@@/@@/addressing/anonymous>  URI MAY be specified as the [address] of an EPR to designate that the target endpoint is reached via a contextualized channel of the underlying SOAP protocol binding. The specification of the relevant context is provided by the definition of the EPR element itself as it relates to the underlying SOAP protocol binding and/or SOAP Message Exchange Pattern definitions.
	

I don't see how any of these tells me what using anonymous means.  Indeed, this was the basis for CR 15.  They all basically say that the underlying SOAP binding should provide a channel for anonymous (actually they assert that it does provide such a channel, which will likely prove problematic for several potential underlying protocols).  The first two then hint that one such channel is provided by any realization of SOAP request-response, but without quite saying just what that channel is and how to use it.

When, in the resolution of CR15, we drilled down on that we determined that using anonymous meant using the response message of a request-response message exchange, and in our cases all messages involved were in the same message exchange.  Again, I deliberately phrase this in terms of what using anonymous means instead of  what kind of "channel" might be provided, because accurately describing such a channel means describing what happens when you use it (that is, where messages go).  Given this, talking about channels just gets in the way.  We never define the term anyway, and we can say what we mean by talking directly about behavior, so why introduce it?

Chris points out that this resolution has both a SOAP1.1/HTTP flavor and a SOAP 1.2 flavor.  I may have left out SOAP 1.1 in my last message, but only from laziness.  Chris also points out that it would be better to talk about the OutboundMessage in the context of SOAP 1.2 and I agree.  There is a comment to this effect, coming soon to a CR issues list near you.

In the course of resolving CR15, we also decided to limit scope to what we understood, namely the behavior of response endpoints and [destination] in the basic request-response scenario.  This, unfortunately, dislodged the resolution of CR4, putting us in the present quandary.  In resolving CR4, we agreed to define anonymous generically.  In resolving CR15, we agreed to define it narrowly.  This belies a certain lack of consensus.

I believe understand Umit's concern about restricting scope.  In my view, the point is to say "this is all we really know" but not to insist that everyone else stay within the same limits if in fact they know more.  In other words, say "anonymous means this in these circumstances" but not "anonymous can only mean this and only in these circumstances".  It's the first reading I always intended and want to preserve.  If the current wording suggests the second reading, I would like to fix that.  I have certainly never intended to restrict use of anonymous, only our claims of knowledge about it.

So rather than go procedural and insist that CR15 stand right down to the letter, I would like to retain the rigor of that text -- namely that in two sentences it says who sends what where -- but try also to support the needs of WS-RX.  To that end, I've tried to understand the actual use case and requirements, particularly by asking what WS-RX expects anonymous to mean, and I've tried to capture what's generic about the behavior WSA specifies.  I've also tried to keep CR18 in mind, since it clearly ties in.

The common ground in the cases we actually define is the use of the response message.  For response endpoints, an EPR in the request message refers to the response.  For [destination] an EPR in the response message refers to the response.  I can see at least this generalizing:  If you use anonymous in the context of request-response, you're talking about the response.

In order to avoid saying "HTTP response in the case of SOAP 1.1/HTTP and response message (i.e., OutboundMessage) in the case of SOAP 1.2 request-response" repeatedly, I've floated the term "underlying response message."  For reasons that remain beyond me, both this and the use of "OutboundMessage" have been regarded as introducing new semantics, so I've backed away from those in the interest of just getting the behavior nailed down as well as can be.

There are a couple of by now familiar issues to call out here: One is that in the case of AcksTo, you're referring to response messages in some set of future exchanges, caveat emptor.  The other is that, even in the context of request-response, we may also want to allow anonymous to refer to request messages.  This is the "open TCP connection" case, and might also apply for virtual-circuit protocols like BEEP.  This is why I say MUST [or MAY] in several cases.  If we want to try to generalize in this direction, we need to make a call on this one way or the other.  MUST means restrict anonymous to responses, MAY means allow but don't restrict (e.g., allow anonymous [destination] in a request).

Outside the context of request-response, I haven't seen any actual definition of anonymous beyond saying that it's a channel provided by the SOAP binding in question.  If, in addition to what we've said for SOAP 1.1/HTTP and SOAP 1.2 request-response -- which, for obvious reasons say nothing at all about anonymous -- we want to allow future SOAP bindings to say "this binding defines anonymous thusly: ...", that seems harmless enough and if it restores the resolution of CR4 then I'm all for it.  I would prefer wording along the lines of "Future SOAP bindings may define meanings for anonymous beyond those described here" instead of talking about channels of the underlying protocol, but if that's the extent of our differences we're in good shape.

In conclusion (likely the only applause line in this megillah) I would like to resolve both CR4 and CR15 harmoniously, I would like to retain the level of explicit detail introduced in CR 15, but I don't mind trying to generalize, at least as far as request-response is concerned.  As far as I can tell, the three solutions listed above provide a hook for defining semantics rather than actually defining semantics and I'm fine with that as long as we keep the semantics we have defined (i.e., the specifics of the CR 15 text but possibly not its restricted scope),  all agree that that's what we're doing and say so clearly and explicitly.  I also agree this seems much ado over something that's currently expressed in two sentences, but these things happen.  Let's keep moving and get this puppy put to bed.

Received on Thursday, 2 March 2006 08:41:23 UTC