btp maintenance issues maint-1, 2, 3, 4, 5, 6, 7

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Some of the issues raised against the BTP Committee Spec are simple
typos. I'd like to propose the following resolutions. According to the
earlier practice of the TC, these detailed discussions took place on the
bt-spec sublist. However, I'm not sure that list has survived the
kavi-strophe and I'm even less sure it has the currently interested on
it.

All these issues are in the current version of the issues list at
http://www.oasis-open.org/committees/download.php/3511/btp_maintenance_i
ssues_list.html

The most up-to-date version of the list is always the working copy at
http://www.choreology.com/external/BTP_extra_issues_list.html

at the moment they are identical - when there are updates, I'll do an
upload to the tc pages on a regular basis, but not every time as it gets
a new uri each time.

If there are follow-ups on a single issue, then changing the title to
start "Issue - maint-# - " with the appropriate number will make it easy
for the issue list building script to link the message in.
        -------------

Issue maint-1: HAZARD after receiving CANCEL
Proposed solution:	Allow an inferior to send HAZARD after receiving
CANCEL - change the inferior state table to have "p1" in "detect
problem/n1"

     

Issue maint-2: CONFIRMED element should be confirm-received
Proposed solution:	Change the schema and specification XML to align
with the main text, making the element "confirm-received" not
"confirmed-received".


Issue maint-3: CONFIRM_ONE_PHASE against autonomous confirm
Proposed solution:	Add a transition to "S1" in the "decide to
confirm one-phase / H1" cell of the superior table



Issue maint-4: reply to CANCEL_INFERIORS
Proposed solution: Add the following paragraph after the explanation of
the parameters of CANCEL_INFERIORS

For all Inferiors identified in the inferiors-list parameter, from which
neither CANCELLED or RESIGNED has been received, the Decider shall issue
CANCEL. It will reply to the Terminator, using the "reply-address" on
the CANCEL_INFERIORS message, sending an INFERIOR_STATUSES message
giving the status of the Inferiors identified on the inferiors-list
parameter.


Issue maint-5: Superior identifier needed before sending
INFERIOR_STATE/unknown Proposed solution: Add superior-identifier as a
parameter on PREPARE, CONFIRM, CANCEL and CONFIRM_ONE_PHASE, in the
tables of parameters, the explanations and the XML.  For consistency
with the superior-to-inferior messages, make it the first parameter.


Issue maint-6: "confirming" status should include auto-confirming
Proposed solution: in the table in 7.6.4, change the "Meaning from
Inferior" entry for Confirming to:

CONFIRM has been received or an auto-confirm has been decided
(CONFIRMED/auto may or may not have been sent); CONFIRMED/response has
not been sent

Issues maint-7, 8 ,9 may invoke some discussion, so are covered in
separate messages.


Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 870 739 0066
mobile: +44 7951 536168