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

Re: TIBCO objects to last call

From: David Hull <dmh@tibco.com>
Date: Fri, 25 Mar 2005 12:23:13 -0500
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: Mark Nottingham <mark.nottingham@bea.com>, public-ws-addressing@w3.org
Message-id: <42444901.1080506@tibco.com>
Jonathan Marsh wrote:

>I request that we have the opportunity to vote to go to Last Call on Monday.
>
>I recognized David's point of view as a legitimate design option for WS-Addressing, but don't see that the existence of another viewpoint invalidates the utility of the current point of view that WS-Addressing has.
>  
>
First, as I hope I've made clear, my concerns about last call go beyond 
the resolution of any particular issue.  Among other things, I'm also 
concerned as to whether we have a clear picture of our relationships 
with other specs, particularly other W3 specs.  Not only is this an 
entry requirement for LC, it would also help to clarify the trade-offs 
to be made in the specs themselves.

Second, my understanding of the W3 process is that it's better to have a 
solution that everyone can live with, even if they don't like it or see 
it as an absolute necessity, than one with strong objections, even if 
only from a few parties.  In the case of i054, TIBCO has stated that we 
cannot live with the current treatment of endpoints.  There are two 
major alternatives we /can/ live with: remove the reply and fault 
endpoints from the core description of MAPs and rely on existing SOAP 
extensibility, or make the MAPs themselves explicitly extensible as per 
any of several proposals.

In our vote last Monday, we as a group put forth two particular 
proposals for the second alternative against two for annotating the 
status quo semantics.  I don't believe we asked our usual question of 
who could /live with/ either of the extensibility proposals, and I don't 
believe we took even an informal vote on who could live with removing 
fault and reply from the core.  I know that many people believe they do 
no harm there, but that's a different question.  I believe that before 
we declare an impasse and go to LC with formal objections imminent, we 
need to make very sure that there is no other alternative that the group 
as a whole can live with.  In particular, if you can live with any of 
the various alternatives concerning extensibility, that's important new 
information.  If the chair wishes, and possibly with the chair's 
assistance, I would be glad to draft this as a more formal proposal.

I want to be very clear here that I don't see the sort of revisiting of 
a formally closed issue that I'm proposing as a license to lie down in 
the road any time a result  proves unsatisfying.  I have tried and will 
continue to try to be sparing in voting no to "can we live with this?".  
I would liken our objection to LC with pulling the emergency brake 
handle on a moving train.  It's not something done lightly (indeed, this 
is the main reason the objection did not appear until Wednesday), and 
it's sure to incur the displeasure of one's fellow passengers.  I'll 
repeat that we at TIBCO are just as keen to get the train moving again 
and get to our ultimate destination as anyone else.

>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org [mailto:public-ws-
>>addressing-request@w3.org] On Behalf Of Mark Nottingham
>>Sent: Thursday, March 24, 2005 10:36 AM
>>To: David Hull; public-ws-addressing@w3.org
>>Subject: Re: TIBCO objects to last call
>>
>>
>>As we agreed that any objection from a Member in Good Standing would
>>prevent publication, we will not go to Last Call at this time.
>>
>>There are two paths forward; we can either re-open the issue(s), or we
>>can vote again to go to Last Call based upon the current documents.
>>After a short discussion on Monday, I'll take a straw poll to help us
>>determine how to proceed.
>>
>>David -- since re-opening issues requires that new information be
>>available, I would strongly encourage you to phrase your arguments in
>>those terms. If you believe that there is an alternate solution which
>>we have not yet discussed, having a complete and concrete proposal on
>>the table may qualify as such. Be aware, however, that having one does
>>not guarantee that we will reopen an issue.
>>
>>Regards,
>>
>>
>>On Mar 23, 2005, at 3:15 PM, David Hull wrote:
>>
>>    
>>
>>> 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.
>>>
>>>
>>>      
>>>
>>--
>>Mark Nottingham   Principal Technologist
>>Office of the CTO   BEA Systems
>>
>>    
>>
>
>  
>
Received on Friday, 25 March 2005 17:23:54 GMT

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