RE: [business-transaction] btp maintenance issues maint-1, 2, 3, 4, 5, 6, 7

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

Actually, 1-6 aren't simple typos - I've kept such trivia to myself and
have a corrected copy of the text on my own machine. The issues below
are just fairly straight-forward.

Peter

> -----Original Message-----
> From: Furniss, Peter 
> Sent: 14 October 2003 14:41
> To: business-transaction@lists.oasis-open.org
> Subject: [business-transaction] 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_mai
> ntenance_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
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/business-transact
ion/members/leave_workgroup.php.