W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

RE: TIBCO objects to last call (resend)

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Thu, 24 Mar 2005 07:36:39 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B6338053075B8@RED-MSG-43.redmond.corp.microsoft.com>
To: "David Hull" <dmh@tibco.com>, <public-ws-addressing@w3.org>
Cc: "Mark Nottingham" <mark.nottingham@bea.com>


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
> Sent: 24 March 2005 00:52
> To: public-ws-addressing@w3.org
> Cc: Mark Nottingham
> Subject: TIBCO objects to last call (resend)
> This message details TIBCO's reasons for objecting to the 
> WS-Addressing core and SOAP binding documents going to last 
> call.  There are several specific reasons, all of which 
> center around the Message Addressing Properties (hereafter 
> referred to as MAPs), and particularly around issues i050 and 
> i054, which we consider to have been closed hastily.  We have 
> no objection to the current formulation of EPRs and indeed 
> believe that WS-Addressing would provide considerable value 
> on the basis of EPRs alone.
> We have made our opposition to the current resolution of i054 
> known and have formally voted against this resolution.  We 
> are prepared to formally object to the core and SOAP binding 
> specifications as they currently stand on the basis of this 
> issue.  We also note that a new proposed resolution for this 
> putatively closed issue has appeared since the vote 
> concerning last call was taken.  
> Whatever the final resolution of i050 and i054, there 
> currently remain significant questions as to the meaning of 
> MAPs in the specification.  Many such questions, including 
> those relating to the objections above, have been raised in 
> public discussion over the past two weeks but have so far 
> gone unanswered.  It is our opinion that several of these 
> questions are of such a nature that if there is any 
> significant doubt concerning them the specification is not 
> sufficiently well-defined to be useful.  We do not claim that 
> none of them can be answered, and in fact we hope that many 
> of them can be answered quickly.  However, until they are, we 
> cannot consider the discussion of the specification to be 
> materially complete and cannot recommend putting the document 
> out for public comment.
> These questions include
> *	Whether the MAPs are considered to contain only those 
> properties defined in the WS-Addressing specifications or 
> whether other specifications may amend them 

I don't really understand why this question is relevant. Consider two

1.	WS-Addressing defines a set of properties and explicitly states
that the set is extensible. A subsequent specification defines a set of
extra properties that augment the set in WS-Addressing.

2.	WS-Addressing defines a set of properties and explicitly states
that the set is not extensible. A subsequent specification defines a set
of extra properties for SOAP messages. 

What is the practical, technical difference between the two approaches?
In both cases a SOAP message can contain headers from the WS-Addressing
spec and the subsequent spec. And be processed accordingly. 

> *	If other specifications can amend this set, in what 
> sense may it be said to be specified by WS-Addressing 

Any additional properties are defined by those other specifications, not

> *	Exactly how a future specification requiring endpoints 
> beyond the presently defined reply and fault endpoints should 
> define these 

A future specification can define things however they like. I don't
understand how we can even constrain how people would write such specs (
or why we would want to ).

> *	In particular whether such a specification would have 
> to define a new SOAP module to hold properties parallel to 
> those defined in the MAPs 

I don't see much value in *requiring* people to do such a thing, but I
concede that approach is one way to write such a specification.

> *	How the current definition of MAPs as mandatory 
> properties would apply to existing SOAP/HTTP interactions 
> which have no notion of such properties 

I take it by 'existing SOAP/HTTP interactions' you mean interactions
that don't use WS-Addressing. Such interactions don't have any
WS-Addressing defined message properties. The message properties only
apply if you're actually using WS-Addressing, which in practical terms
means you have at least one header in the WS-Addressing namespace in
your messages.

> *	Whether existing specifications would need to be 
> amended to mention MAPs and/or their corresponding headers in 
> order to leverage the asynchronous request/reply pattern to 
> which the MAPs are evidently tailored, as suggested by the 
> explicit mention of ReplyTo and other headers in 
> specifications such as WS-Transfer and WS-Enumeration 

I would think that such amendments are up to the authors of those specs.
Why is it our concern in this WG?

> *	What level of MAP extensibility is actually required by 
> the WS-Addressing charter. 

It doesn't seem like the charter requires that the set of message
properties be extensible, but it also doesn't preclude such extension.
As I have stated before, I don't really see how a spec can make it self
completely non-extensible, especially given the way SOAP works; any
header can modify the behaviour of any other header. 

Our current spec acknowledges that the set of properties it defines is
not exhaustive. Anyone can write a spec to supply properties that they
consider useful over and above those defined by WS-Addressing.


> Please consider this listing as a request to open these 
> outstanding questions as formal issues.
> While we understand and indeed share the desire of the group 
> to get to last call as quickly as reasonably possible, given 
> the current state of the specification and the discussion 
> around it, we regret to say that we cannot support the 
> documents going to last call at this point, and so must object.
Received on Thursday, 24 March 2005 15:36:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:24 UTC