[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]