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 02:41:46 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B633805307510@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>
I wasn't aware that 'I don't like the resolution to an issue' was
grounds for objecting to last call. The WG *has* closed all outstanding
issues.
 
My understanding of the vote we took on Monday was that we were allowing
people time to check that the resolutions entered into the documents by
the editors matched the resolutions made by the WG. I have not seen any
mail indicating that the editors have made any errors in this regard.
 
Gudge


________________________________

	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 
	*	If other specifications can amend this set, in what
sense may it be said to be specified by WS-Addressing 
	*	Exactly how a future specification requiring endpoints
beyond the presently defined reply and fault endpoints should define
these 
	*	In particular whether such a specification would have to
define a new SOAP module to hold properties parallel to those defined in
the MAPs 
	*	How the current definition of MAPs as mandatory
properties would apply to existing SOAP/HTTP interactions which have no
notion of such properties 
	*	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 
	*	What level of MAP extensibility is actually required by
the WS-Addressing charter. 

	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 11:32:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT