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 Thursday, 24 March 2005 18:36:23 UTC