RE: TIBCO objects to last call (resend)

David,

 

I am sympathetic to your concerns.  I have a particular interest in
ensuring that extensibility by 3rd parties is enabled for a large
variety of scenarios.  I respect the amount of work that you have done
in articulating the concerns you have.

 

However, I think that you have not done the right work in this regard.
To me, the "smoking gun" for not going to last call is a scenario where
the MAPs are not extensible.  You have listed a variety of scenarios,
but you haven't proven that a single one of those cannot be covered with
WS-A + extensibility.  As you are a smart fellow, this seems surprising
to me.  

 

I don't think that the burden of proof should be upon people like myself
to prove that the MAPs are extensible.  I'm pretty convinced they are,
as we have used these in other specifications like WS-ReliableMessaging
and WS-Eventing, and I'm sure you have in WS-Notification.  Given that
there is existent use of WS-A in broader MEPs, I really do think that a
"smoking gun" is required to hold up last call.  

 

If you had provided a concrete scenario that extends the MAPs and showed
how the spec was not extensible/broken, I would be totally with you in
not going to LC.  

 

As it stands, your comments are specific and worthy questions, but do
not show to me anything that should prevent us from saying "Dear Larger
Community (pun on LC), we think we are done, did we goof up anywhere?".

 

Cheers,

Dave

 

  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, March 23, 2005 4:52 PM
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.