Re: Clarification for WS-RX

First, the proposal I put up was just meant to point out that, taken at
face value, the stuff about "nothing more, nothing less" doesn't
automatically lead to useful results.  Would that it did, but it doesn't.

BTW, "response endpoint" is currently only defined in the WSDL doc (as
Umit helpfully points out).  It means "[reply endpoint] or [fault
endpoint] as the case may be".  Without it, we would have to say things
like "[reply endpoint] in case of a reply or [fault endpoint] in case of
a fault" in a few places.  As such, it's useful both there and here, and
would probably be best defined somewhere in section 3 of the core.  I'm
hoping we can do this as part of this or some other issue and not have
to define a separate issue.

Now to the interesting part:


> [snip]


> The key phrase here IMO is "context". You are defining the semantics
> of the anonymous [address] property
> for the [reply endpoint] in the context of a SOAP MEP. In the case of
> the WS-RX AcksTo EPR, we define its
> context to an MEP + Sequence Identifier. That is to say that if a SOAP
> message is received that carries the
> same Sequence Identifier as was created in response to the
> CreateSequence that carried the anon AcksTo,
> that the ack may be sent using the channel provided by the MEP/binding
> on which the received
> SOAP message arrived.

If I understand this correctly, the MEP binding provides part of the
definition and the definition of whatever EPR-valued property we're
talking about further refines this.  For example, we could say "in the
context of SOAP 1.2 request-response, anonymous MUST /[or MAY]/  refer
to the response message." and then when talking about  response
endpoints (see above) say that  the response message has to be the
response part of the same message exchange,  but when talking about
AcksTo, say that  the response message may be part of any message
exchange  for which the request is a message belonging to the sequence
in question.

This allows anonymous to mean something else with some other MEP (or in
the absence of a MEP :-).  We can also talk about anonymous
[destination], in which case the context is the message itself.  I'm not
sure how it squares with using anonymous [destination] on requests on an
already-open channel.

If this is all accurate, then I think that this description is helpful
in understanding the problem.  However, I think the text I gave
previously captures all we need to capture:

    When "http://www.w3.org/@@@@/@@/addressing/anonymous" is used in the
    context of  a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts
    <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>],
    then it MUST /[or MAY]/ refer to the use of the response message of
    the exchange.  When in particular it is used in a response endpoint
    in a request message, any response MUST be the response part of the
    same SOAP request-response message exchange [SOAP 1.2 Part 2:
    Adjuncts
    <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>].

Note how the first sentence talks about anonymous generically (albeit in
the context of a particular MEP) and the second narrows down the
behavior of response endpoints in particular.  I believe this is in line
with the two-level approach that Umit is advocating.  That was certainly
my intent in bringing the new text into the already agreed text from the
Editors' draft.

If we take this approach, we still have to decide whether we mean MUST
or MAY in the above, but I hope at least the question is phrased clearly
enough we can decide.

>
> I would offer up the following definition of the semantics of the anon
> URI for your amusement:
>
> 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 think that this permits the definition of the semantics of the anon
> URI for the [reply endpoint] and [fault endpoint]
> by specifying that the context of that EPR is defined by virtue of the
> SOAP MEP, as I have suggested
> above.
>
> [1]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0175.html
>
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> public-ws-addressing-request@w3.org wrote on 02/22/2006 02:45:46 PM:
>
> > Here, then, are two simple resolutions
> > 1. Close with no action.  Simple.  Done.
> > 2. Section 5 to read as below.  The rules now apply to any endpoint.
> > Simple.  Done.
> > 5.1.1 SOAP 1.1/HTTP
> > When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified
> > for an endpoint in a request message then there is no change to the
> > SOAP 1.1/ HTTP binding.
> > 5.1.2 SOAP 1.2
> > When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified
> > for an endpoint in the request part of a SOAP request-response
> > message exchange [SOAP 1.2 Part 2: Adjuncts], then any message sent
> > to that endpoint MUST be the response part of the same SOAP request-
> > response message exchange [SOAP 1.2 Part 2: Adjuncts].
> >
> > Yalcinalp, Umit wrote:
> > It seems to me we are just making a big deal out of an issue which is
> > easily fixed here in WS-A.
> >
> > We separate the problem into two separate issues:
> >
> > --define the anonymous URI's semantics
> > --define the WS-A MAP semantics for reply endpoint/fault endpoint with
> > anonymous value. This wg can provide specific semantics for these two
> > MAPs we define which builds on anonymous URI and their relationship to
> > MEPs.
> >
> > Nothing more, nothing less.
> >
> > Katy's proposal for CR23 [1] is definitely in the right direction and we
> > should fix this problem in this manner, by careful decomposition of the
> > problem.
> >
> > Intermixing the solution of these two issues and thinking in a very
> > restricted sense for the semantics of anonymous is not a good approach.
> > As a matter of fact, fusing the two solutions breaks composition for
> > other groups. The semantics of Anonymous should not be restricted to
> > specific MEPs, but can be further used to define the semantics in
> > certain MEPs and WS-A MAPs. Fusing the two prevents the composition, IMO
> > and I am weary of the tendency here.
> >
> > WS-RX can define the semantics of acksTo (which it owns) based on the
> > anonymous URI only. It can crisply define how acksTo can be used in its
> > own context and in conjunction with its own protocol exchanges/when it
> > is allowed, etc.
> >
> > It seems to me that resolving CR23 in this manner, we do not hinder any
> > composition, not the other way around.
> >
> > --umit
> >
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0167.ht
> > ml
> >
> >  
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > David Orchard
> > Sent: Wednesday, Feb 22, 2006 8:27 AM
> > To: paul.downey@bt.com; dmh@tibco.com; public-ws-addressing@w3.org
> > Subject: RE: Clarification for WS-RX
> >
> >
> > OTOH, the last thing I want is some profile to crop up that
> > "fixes" for
> > WS-RX how "broken" WS-A is.  At the end of the day, the stuff is
> > supposed to be composable, etc.
> >
> > Cheers,
> > Dave
> >
> >    
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > paul.downey@bt.com
> > Sent: Wednesday, February 22, 2006 6:09 AM
> > To: dmh@tibco.com; public-ws-addressing@w3.org
> > Subject: RE: Clarification for WS-RX
> >
> >
> >
> >
> >      
> > I'm a bit loath to send this to the whole WS-RX list, and I think
> > there are enough WS-RXperts here to answer, so ...
> >        
> > but this is Web service addressing and I'm bothered that we
> > do seem to keep descending into glorious detail on how WS-RX
> > may or may not work, rather than answering tractable LC and
> > CR comments from that WG wrt our specifications.
> >
> > Paul
> >
> >
> >      
> > ______________________________________________________________
> > _________
> > Notice:  This email message, together with any attachments,
> > may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> > affiliated
> > entities,  that may be confidential,  proprietary,  
> > copyrighted  and/or
> > legally privileged, and is intended solely for the use of the
> > individual
> > or entity named in this message. If you are not the intended
> > recipient,
> > and have received this message in error, please immediately
> > return this
> > by email and then delete it.
> >
> >
> >    
> >
> >