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 09:57:13 -0500
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: public-ws-addressing@w3.org, Mark Nottingham <mark.nottingham@bea.com>
Message-id: <4242D549.9000004@tibco.com>
Martin Gudgin wrote:

> I wasn't aware that 'I don't like the resolution to an issue' was 
> grounds for objecting to last call.

Was there something unclear about "Whatever the final resolution of i050 
and i054, there currently remain significant questions as to the meaning 
of MAPs in the specification." followed by a list of specific questions 
which have been raised but gone unanswered?

Section 7.4.2 of the process document is silent as to members' desire to 
meet a particular deadline as a criterion for Last Call.  It does, 
however, state

    Purpose: A Working Group's Last Call announcement is a signal that:

        * the Working Group believes that it has satisfied its relevant
          technical requirements (e.g., of the charter or requirements
          document) in the Working Draft;

  Given the lack of substantive answers to the questions posed and to 
others, we don't see how we can even remotely make that statement.  It 
further states

    Ideally, after a Last Call announcement, a Working Group receives
    only indications of support for the document, with no proposals for
    substantive change.

Clearly, this is not going to be the case should we go to LC now.

We strongly believe that going to LC at this point would be a misuse of 
the LC designation, and would be counterproductive in that issues which 
we ought to be able to resolve amongst ourselves will end up raised to 
the level of formal objections.  In short, we will get done sooner with 
a better end result if we do not go to LC now.  By "better end result" I 
mean technically stronger and more likely to be widely adopted, 
regardless of whether particular decisions fall the way any particular 
party would like.

We also don't like the resolution of i054, but we can talk about that if 
the group is willing to back away from the "Last Call at all costs" 
mentality and the associated procedural battles, which I for one would 
very much wish to avoid.  We have not yet exhausted the possibilities 
for resolving the various MAP-related issues (and by resolving I mean 
actually resolving to the satisfaction of all, as opposed to having a 
20-minute discussion and taking a stab so we can mark an issue closed).  
Let's focus on that instead.

> The WG *has* closed all outstanding issues.
>  
> My understanding of the vote we took on Monday was that we were 
> allowing people time to check that the resolutions entered into the 
> documents by the editors matched the resolutions made by the WG. I 
> have not seen any mail indicating that the editors have made any 
> errors in this regard.
>  
> Gudge
>
>     ------------------------------------------------------------------------
>     *From:* public-ws-addressing-request@w3.org
>     [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
>     *Sent:* 24 March 2005 00:52
>     *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.
>
Received on Thursday, 24 March 2005 14:57:53 GMT

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