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

Re: TIBCO objects to last call (resend)

From: David Hull <dmh@tibco.com>
Date: Thu, 24 Mar 2005 15:58:25 -0500
To: David Orchard <dorchard@bea.com>
Cc: public-ws-addressing@w3.org, Mark Nottingham <markn@bea.com>
Message-id: <424329F1.5010706@tibco.com>
David Orchard wrote:

> I'm not sure that there is a single correct way to specify new MEPs. 
>
Thus the existence of standards.  A standard that talks about composing 
interactions from basic one-way messaging is explicitly playing in this 
space.

> 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.
>
At this point there's a very obvious issue:  Despite repeated calls over 
a period of weeks, no one has been able to produce a concrete 
description of how to handle any MEP other than those described in the 
WSDL binding document.  If you can't do it, I understand, not a 
problem.  If no one else in the group can do it either, I'm more 
concerned.  I still find it hard to believe that no one here is able to 
produce such a description, but the clear evidence of the last few weeks 
is that it's not actually as easy as asserted.  Why else would no one 
have done it by now?

>   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.
>
If you're comfortable with leaving questions like "How does this spec 
relate to other specs?", "How would extensibility work?" and "What does 
the charter require?" open after last call, I don't suppose I can stop you.

I'll repeat that if we do go directly to Last Call, TIBCO Software, Inc 
will formally object on the basis of i054, inviting other participants 
to join in the objection. TIBCO Software, Inc may also file objections 
on other grounds.  We would prefer not to see this specification in last 
call multiple times, and so would prefer to see issues addressed before 
it enters last call the first time.  Moving to Last Call with serious 
open issues raised by members of the working group seems, to us, 
pointless and contrary to the intent of Last Call.

>  
>
> 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 
>> <mailto: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> 
>> [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 <mailto: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.
>>
>>  
>>
>  
>
Received on Thursday, 24 March 2005 21:45:22 GMT

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