OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

All these issues are in the current version of the issues list at

The most up-to-date version of the list is always the working copy at

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


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

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

Issue maint-5: Superior identifier needed before sending
INFERIOR_STATE/unknown Proposed solution: Add superior-identifier as a
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 Furniss
Chief Scientist, Choreology Ltd

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]