RE: CR 20: amalgamated proposal

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
[mailto:public-ws-addressing-
> 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
instead
> of a constant!)  It's not clear that abstracting out defaulting from
XML
> infoset representation (which is already confusingly abstracted from
the
> properties on the one side, and from SOAP headers on the other) makes
a
> 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
arbitrary
> 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
some
> 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
the
> 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
down
> interop results.  This change isn't directly motivated by results of
the
> interop work, so it's not essential to address.  The status quo
> functions perfectly well, despite the aesthetic concerns which appear
to
> be addressable only at the expense of whatever simplicity we have
left.
> 
> 
> 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,
which
> > 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
a
> > 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
as
> > 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
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.
> >
> > {The next 2 paras below are new}
> > Messages on such a channel must have a [destination] property value
of
> > "http://www.w3.org/@@@@/@@/addressing/anonymous". Additionally, this
> is
> > the default value of such responses if the [destination] value is
not
> > 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 Thursday, 16 February 2006 23:00:28 UTC