W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

RE: CR 20: amalgamated proposal

From: Francisco Curbera <curbera@us.ibm.com>
Date: Fri, 17 Feb 2006 09:50:01 -0500
To: "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF5BC6B483.41DB1EFD-ON85257118.001899E4-85257118.00517BCD@us.ibm.com>

If we leave CR4 aside, the only thing the proposal says is that for r/r

1. messages sent on the "reply channel" of a SOAP r/r have an anonymous To,
which is also the default value.
2. this spec does not define any other use of anonymous (or other default).

So WSA would not define additional defaults or other use cases of the
anonymous URI for more specific situations, but does not prevent anyone
from doing so either.

My understanding is that the TCP binding keeps a connection open after the
first message is transmitted and messages are then exchanged in both
directions over the open channel. As you say, you may want to optimize by
defaulting To in all those messages. I don't see how the text would prevent
you from doing so except that you need to explicitly state that you are
adding an additional convention to the WSA defaulting rules. With the
current text you would need to extend the interpretation of anonymous:
"when using the TCP transport binding, anonymous (also) means using the
already open TCP connection", which simply adds to what WSA says now. With
this proposal you would say "when using the TCP transport, default To to
anonymous and interpret anonymous to mean using the already open TCP
connection". Not a big difference, I think.

As for the CR4 text, I think it can easily accommodate the TCP binding use


                      "Jonathan Marsh"                                                                                                   
                      <jmarsh@microsoft.com>          To:       "Jonathan Marsh" <jmarsh@microsoft.com>, "Anish Karmarkar"               
                      Sent by:                         <Anish.Karmarkar@oracle.com>, <public-ws-addressing@w3.org>                       
                      public-ws-addressing-req        cc:                                                                                
                      uest@w3.org                     Subject:  RE: CR 20: amalgamated proposal                                          
                      02/16/2006 05:59 PM                                                                                                

And another reason for retaining the current spec from our engineers.
We have bindings under development such as a binding to TCP where the
anonymous wsa:To makes perfect sense in request messages (I don't
understand the details of TCP well enough to describe how that's
possible).  For such a binding, we would take advantage of the nice
optimization of defaulting of wsa:To to anonymous in request messages.
Building the defaulting at the SOAP level rather than again and again at
the level of underlying transports is more efficient.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Thursday, February 16, 2006 1:16 PM
> To: Anish Karmarkar; public-ws-addressing@w3.org
> Subject: RE: CR 20: amalgamated proposal
> My 2c - this change isn't cost-effective.
> The proposal is apparently motivated by cleaning up the so-called
> problem of specifying a default that might not make sense in some
> situations (but that's why it's a default that can be overridden
> of a constant!)  It's not clear that abstracting out defaulting from
> infoset representation (which is already confusingly abstracted from
> properties on the one side, and from SOAP headers on the other) makes
> whole lot of sense.  Why pick defaulting to move from one level of
> abstraction to another and not, say, the optionality of the elements?
> The previous proposal to make [destination] optional shows how
> this "solution" is.
> The shifting sands of these abstractions could be subject to lots more
> discussion, ref my proposal to roll the specs together and collapse
> of these abstractions (XML infoset and SOAP headers would become one)
> was not accepted by the group.  I can live with the WG's will, grumble
> grumble, but IMO further twiddling adds unnecessary complication to
> already complicated set of abstractions and editorially obscures the
> defaulting mechanism by moving it to an unexpected location in another
> spec.
> I'm worried about any change to the specs at this stage because of the
> general concern of unintended side-effects as we're trying to lock
> interop results.  This change isn't directly motivated by results of
> interop work, so it's not essential to address.  The status quo
> functions perfectly well, despite the aesthetic concerns which appear
> be addressable only at the expense of whatever simplicity we have
> Therefore my preference is to close CR20 with no action.
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-
> > request@w3.org] On Behalf Of Anish Karmarkar
> > Sent: Thursday, February 16, 2006 11:02 AM
> > To: public-ws-addressing@w3.org
> > Subject: CR 20: amalgamated proposal
> >
> >
> > Here is a joint proposal to resolve issue 20.
> >
> > The proposal does the following:
> >
> > a) Gets rid of defaulting in the Core, but allow bindings to specify
> > defaults.
> > b) Does not change the cardinality of [destination] or wsa:To in the
> Core
> > c) specifies that messages on the "back channel" must have the value
> of
> > 'anon' for the [destination] property.
> > d) specifies 'anon' as the default for messages on the back channel.
> > e) incorporates wordings similar to Paul Downey's which say that
> outside
> > of this particular scope this spec does not define any particular
> > semantics for the 'anon' URI.
> >
> > Please note that this proposal keeps the resolution text of CR4,
> > either got removed as a result of resolution of CR15 or was an
> editorial
> > oversight (I have already sent a separate email for this). If we do
> not
> > keep the resolution of CR4 then the editors will have to change the
> > wordings to make it fit better.
> >
> > Proposal:
> > --------
> >
> > 1) In the Core spec [1], section 3.2, change:
> > -----
> >    /wsa:To
> >       This OPTIONAL element (whose content is of type xs:anyURI)
> provides
> > the value for the [destination] property. If this element is NOT
> present
> > then the value of the [destination] property is
> > "http://www.w3.org/2005/08/addressing/anonymous".
> > -----
> >
> > to:
> > -----
> >    /wsa:To
> >       This OPTIONAL element (whose content is of type xs:anyURI)
> provides
> > the value for the [destination] property. A binding of Addressing to
> > specific protocol may define a default value for wsa:To. In the
> absence
> > of such a default, a value for wsa:To MUST be specified.
> > -----
> >
> > 2) In the SOAP binding spec [2], in section 5.1 add:
> > -----
> > {The para below is the resolution text for CR4 and included here for
> flow}
> > When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified
> > the address of an EPR, such as the ReplyTo or FaultTo 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
> > response messages. For instance, the SOAP 1.2 HTTP binding [SOAP 1.2
> > Part 2: Adjuncts] puts the reply message in the HTTP response.
> >
> > {The next 2 paras below are new}
> > Messages on such a channel must have a [destination] property value
> > "http://www.w3.org/@@@@/@@/addressing/anonymous". Additionally, this
> is
> > the default value of such responses if the [destination] value is
> > specified.
> >
> > Outside of this usage, this specification assigns no particular
> > semantics to the use of
> "http://www.w3.org/@@@@/@@/addressing/anonymous"
> > for the [destination] property in this binding.
> >
> >
> > -Paco & Anish
> > --
> >
> >
Received on Friday, 17 February 2006 14:50:18 UTC

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