RE: TIBCO objects to last call (resend)

Gudge,
 
same here.
 
I suggest that the feedback be changed to remarks during last call.
 
abbie
 
 
--This is the Way --> This is Nortel" hspace=0
src="file:///D:/Abbie-new/work/nortel_email_sig_blue.gif" align=baseline
border=0 NOSEND="1">

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Martin Gudgin
Sent: Thursday, March 24, 2005 5:42 AM
To: David Hull; public-ws-addressing@w3.org
Cc: Mark Nottingham
Subject: RE: TIBCO objects to last call (resend)


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.