i051: Binding of message addressing properties in the SOAP underlying protocol [i051]

I see no interop benefits from defining SOAP features and properties.  I
see no benefits in writing other specs.

Which is easier to read:
  "http://www.w3.org/YYYY/MM/addressing/soap12/feature/Destination"
or
  the WS-Addressing [destination] property?

It just complicates the spec and makes it and dependent specs less human
readable.  We've been successfully using the latter model for infoset
references in specs for some time and it seems to work very well.

As far as your proposal that we make general statements about whether:
> >   - the value should be duplicated, i.e. expressed both at the
> >     underlying binding level and in the envelope;

I don't think there are general rules we can apply. [action] needs to be
consistent with SOAP Action, [destination] doesn't need to be duplicated
in the protocol.  We've documented the special cases where we want
consistency or duplication.  We're done.

> >   - the SOAP header doesn't need to be serialized in the envelope as
> >     it's expressed at the underlying binding level.

This complicates life immensely for end-to-end scenarios and is a much
bigger issue than whether or not we define some (worthless IMO) property
URIs.

I say a big fat NO to the whole proposal except exploring whether we
should note that [action] is the same (rather than obviously similar) to
the SOAP Action property.  To that part I say a little NO, because I
still just don't think that's very interesting.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Mark Nottingham
> Sent: Tuesday, February 22, 2005 1:46 PM
> To: Hugo Haas
> Cc: public-ws-addressing@w3.org
> Subject: Re: NEW ISSUE: Binding of message addressing properties in
> the SOAP underlying protocol [i051]
> 
> 
> This is now issue 051;
>    http://www.w3.org/2002/ws/addr/wd-issues/#i051
> 
> 
> On Feb 18, 2005, at 7:43 AM, Hugo Haas wrote:
> 
> >
> > -=- Description -=-
> >
> > We define as message addressing properties concepts that happen to
> > exist in certain SOAP underlying protocols. A good example is the
> > [action] message addressing property and the action parameter of the
> > application/soap+xml media type carried by HTTP's Content-Type
> header.
> >
> > We need to clearly define the relationship for this information when
> > it appears in different places, i.e. whether they are independent,
> > equal, or related another way.
> >
> > -=- Justification -=-
> >
> > Questions arose about the relationship of this similar information
> > appearing in different places[3]. Core hints that [action] and SOAP
> > Action are similar for example[4] though the description provided is
> > SOAP 1.1 specific.
> >
> > We should provide a basis for such equivalence rules for a variety
> of
> > message addressing properties and bindings.
> >
> > -=- Target -=-
> >
> > SOAP binding
> >
> > -=- Proposal -=-
> >
> > SOAP features were created in part to deal with the fact that
> > different bindings provide different (lowercase f) features, and
> that
> > certain things will sometime need to be expressed as SOAP headers,
> > whereas sometimes they will be able to travel in the underlying
> > protocol outside of the envelope.
> >
> > As we have a set of such information, I believe that we should use
> the
> > SOAP features and properties framework to deal with them.
> >
> > That will allow bindings to clearly express whether they have some
> > built-in mechanisms for some of this information. In particular,
> this
> > will clarify the relationship between these built-in mechanisms and
> > our message addressing properties.
> >
> > To refer to an earlier email about action and message-id[2], I
> believe
> > that a SOAP Action should be equivalent to an [action] message
> > addressing property, and an message id in an email binding should be
> > equivalent to our [message id] property. As an additional foreword,
> > this looks like but is different from an F&P proposal that I made
> > earlier[5]; the WG felt at the time[6] that SOAP F&P were a more
> > appropriate way to do what I was trying to achieve, so here it is.
> >
> > I propose the following changes, all in the SOAP binding:
> >
> > 1. Define a SOAP 1.2 feature, the SOAP Addressing 1.0 Feature. The
> >   SOAP Addressing 1.0 module that we are defining (see my other
> email
> >   about defining modules) is implementing the SOAP Addressing 1.0
> >   Feature, identified by the URI:
> >   http://www.w3.org/YYYY/MM/addressing/soap12/feature
> >
> > 2. Define each message addressing property as being a SOAP property
> of
> >   the SOAP Addressing 1.0 Feature, using the following pattern:
> >   http://www.w3.org/YYYY/MM/addressing/soap12/feature/{PROPERTY}
> >   where property is:
> >   - [destination]		->	Destination
> >   - [source endpoint]		->	SourceEndpoint
> >   - [reply endpoint]		->	ReplyEndpoint
> >   - [fault endpoint]		->	FaultEndpoint
> >   - [message id]		->	MessageId
> >   - [relationship]		->	Relationship
> >   - [reference parameters]	->	ReferenceParameters
> >
> >   You will have noted that [action] is missing from this list; I
> >   believe that [action] should be the property
> >   http://www.w3.org/2003/05/soap/features/action/Action as they are
> >   identical.
> >
> >   As an example of this benefit, suppose that somebody defines an
> >   SMTP binding for SOAP 1.2 with support for the Internet Message
> >   Format (RFC2822) which would provide the Message-Id header, and
> >   MIME (RFC 2045) which provide the Content-Type header; this
> binding
> >   would support:
> >   - the SOAP Action feature
> >   - expressing
> >     http://www.w3.org/YYYY/MM/addressing/soap12/feature/MessageId
> >     as an mid: URI.
> >
> > 3. We should make a statement, if an underlying protocol binding
> >   supports carrying one of the properties from the SOAP Addressing
> >   1.0 Feature, whether:
> >   - the value should be duplicated, i.e. expressed both at the
> >     underlying binding level and in the envelope;
> >   - the SOAP header doesn't need to be serialized in the envelope as
> >     it's expressed at the underlying binding level.
> >
> > Comments?
> >
> > Cheers,
> >
> > Hugo
> >
> >  1.
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/
> > 0067.html
> >  2.
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/
> > 0112.html
> >  3.
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/
> > 0109.html
> >  4. http://www.w3.org/TR/2005/WD-ws-addr-core-20050215/#_Toc77464322
> >  5.
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/
> > 0067.html
> >  6. http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item12
> > --
> > Hugo Haas - W3C
> > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
> >
> >
> 
> --
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>

Received on Thursday, 24 February 2005 00:45:19 UTC