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