May 11 conference call minutes

["William Z Pope" <zpope@pobox.com>]

* 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