RE: TIBCO objects to last call (resend)

I'm not sure that there is a single correct way to specify new MEPs.
Why would I want to prevent nodes from doing a variety of options isn't
clear to me.

 

I'm not prepared to go to more effort to prove something that I believe
in.  You think I (or somebody else) should prove the extensibility
works.  I think it's up to any issue raiser to prove there's an issue.
I don't think there is an issue.

 

I do think we now understand each other, and given that I'm not prepared
to do the work you want me to do, and you're not prepared to do the work
I want you to do, we're probably done.

 

I'm comfortable in taking a vote on going to LC next week.

 

Cheers,

Dave

 

  _____  

From: David Hull [mailto:dmh@tibco.com] 
Sent: Thursday, March 24, 2005 11:59 AM
To: David Orchard
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: TIBCO objects to last call (resend)

 

David Orchard wrote: 

David,

 

I really do think we are coming at this from different points of view.  

 

I assert that extensibility exists with the existing MAPs.  I assert
this understanding the SOAP extensibility model and the lack of
constraints on re-using MAPs.

This is actually part of the problem, not the solution.

Spec A needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use <ourns:MepEndpoint> as a header for EPRs active
in our MEPs and an ourns:MepEndpoint@role attribute on the header to say
what role it's playing"

Spec B needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use <ourns:MepEndpoint> as a header for EPRs active
in our MEPs and an @role attribute in the EPR to say what role it's
playing"

Spec C needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use whatever header names we like for EPRs active in
our MEPs and use an @ourns:isMepEndpoint attribute on the header to say
that it belongs to us"

Spec D needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's just assume that every header that's an EPR is an
endpoint active in our MEPs."

This is just the kind of interoperability nightmare that standards are
meant to prevent.  A, B, and C might play together, at the expense of
bespoke logic for each of their schemes, but D won't play nicely with
anyone.  By refusing to take on extensibility and actively inviting
people to roll their own, we invite just this sort of  scenario.




You are effectively demanding that I prove something that I believe in, 

I sure am.  I'm not inclined to share your your belief otherwise.



and you are not offering any proof that my belief is mistaken.

 

Do you agree with my rough assessment of the points of view and
expectations we have on burden of proof?   

 

Can you see why I think that you need to provide some proof that the
extensible assertion is invalid, especially given that I know you are
intimately familiar with WS-A extensibility and other forms of MEPs?

	 

	Cheers,

	Dave

	 

	
  _____  


	From: David Hull [mailto:dmh@tibco.com] 
	Sent: Thursday, March 24, 2005 11:06 AM
	To: David Orchard
	Cc: public-ws-addressing@w3.org; Mark Nottingham
	Subject: Re: TIBCO objects to last call (resend)

	 

	There is a basic and somewhat long-standing disconnect here that
I'm still trying to understand.
	
	To me, and I suspect you may agree, WSN and WSE are not
extending MAPs in any way.  They are simply using EPRs.  They would work
equally well if section 3 were deleted from WSA entirely.  "You can
build things with EPRs" -- a true and useful statement as far as I can
tell -- is not the same as "you can extend MAPs".  Neither is the same
as the pertinent question of "can we support MEPs beyond request/reply
as easily as we support request/reply?"
	
	Section 3 contains specific support for request/reply and we
reference this directly in the WSDL binding document.  This creates a
presumption that specific support for MEPs is required in the MAPs.
There are several ways to get beyond this:

	1.	Remove special mention of reply and fault from the MAPs
and re-do the WSDL document accordingly.  This would show that no
specific support is needed, request/reply serving as an example.  I'm
currently leaning toward this, provided that someone will sign up to
helping re-do the WSDL binding.  I'm told -- and I'm not being facetious
here -- that it wouldn't be hard.
	2.	Provide general support in the MAPs for all kinds of
endpoints and re-do the WSDL document accordingly.  The proposals 1 and
4 we voted on, along with a couple of others that have appeared, are
aimed at this.  This would also show that no specific support is needed,
request/reply again serving as an example.
	3.	Keep the status quo, but provide specific examples of
MEPs that do not rely on the pre-defined reply and fault endpoints, then
verify that these are no harder to produce or use than the current
request/reply.  I don't think this would be optimal, but it would be
good enough.  If we want to keep the status quo, there is a burden to
prove that it will work in cases other than those it is specifically
tailored to.
	4.	Remove MAPs from WSA entirely in favor of discussing
MEPs directly in terms of EPRs, message IDs and such.  No MAPs, no MAP
extensibility issue.  Extensibility comes directly from SOAP, which we
all agree to be extensible.  Once again, request/reply serves as an
example.
	5.	Keep the status quo and make it as explicit as possible
that we have not really addressed how to cover non request/reply MEPs,
and hope no one minds.  Proposals 2 and 3 that we voted on are steps in
this direction.

	
	I'm frankly puzzled by the notion -- as I understand it -- that
it's enough to simply assert extensibility without providing any example
of how it would work.
	
	David Orchard wrote: 

	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.