RE: TIBCO objects to last call

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.

> -----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 15:53:30 UTC