[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: May 11 conference call minutes
* Agenda: Minute taker Call roll Vote on previous minutes Vote on extra issue 3 proposed resolution Vote on maint issue 3 proposed resolution Vote on maint issue 7 proposed resolution Vote on maint issue 11 proposed resolution See email titled "[business-transaction] BTP issue maint-11 - proposed resolution" * Attendees Mark Little no Bill Pope yes Sazi Temel yes Tony Fletcher leave of absence Martin Chapman no Robert Haugen no Alastair Green yes Peter Furniss yes Alex Ceponkus no - regrets Doug Bunting yes * Vote to accept previous minutes passed unopposed * General ** Next con call Tuesday May 25th, at noon US eastern time. Choreology will host the next call ** Forward movement There are proposals for all outstanding issues, except the two latest issues put up by Alex. Let's try to move this to resolution and production of the 1.1 specification either via email, Kavi ballots, or at the next phone call. * Issues Two new issues 12. Address priority attribute not in the XML. 13. Editorial change: move the XML from the specification into a separate file. ** Ex Issue 7 & 3 The proposal encompasses solutions to both these issues. Proposed: Peter Furniss; Seconded: Alastair Green Passed without objection I propose we accept issue ex-3 as outlined in the documents Alex and I submitted (well Bill Pope actually put them up, but I've changed the apparent submitter to the respective authors) - see http://www.oasis-open.org/committees/download.php/6154/WSfriendly_bindings.p rf.2004-03-30.doc or follow links in the issues list at http://www.choreology.com/external/BTP_extra_issues_list.html#Issueex-7 ** Maint Issue 7: March 30th text from Alex Ceponkus Proposed: Peter Furniss; Seconded: Alastair Green Passed without objection ** Maint Issue 11: Allowing repeat cancel *** Proposal: Allow repetition of CANCELLED, using solution I proposed when submitting this: Add additional state z2, entered on sending CANCELLED where this currently transits to z. If an imbound message is received, transit to a new query state (y3), which is exitted by resending CANCELLED, reverting to z2. Disruption (loss of volatile information) should cause a transition to existing z. (Thus the current behaviour can be treated as a disruption I.) Proposed: Peter Furniss; Seconded: Alastair Green Deferred pending more discussion. *** Discussion: Sazi, Doug, Peter, Alastair Question the state transitions. Terminology problem, the CANCELED comes after the removal of persistent information, logically. The persistent information may have been removed, must have been according to the current state tables, thus making it logically impossible for the second cancel to occur. Is this an implementation detail or a requirement of the specification? The current spec disallows transmission of information that is available and that may be used by the other side. Should this be mandatory? No it must be permissive, not required. Sazi expressed a concern that this does not have any further or unexpected effects on other parts of the state table. ** Issue Maint-12 - Address priority attribute Ran out of time ** Issue - maint-13 - CONFIRM_ONE_PHASE report-hazard default Ran out of time
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]