[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 3/28/2004: WI-26-36-52 Control Flow - Notification of Failure[RSD]
Discussion|OASIS.ebBP.WI-26 Control flow and NOF; Topic; Point|Combination with WI 36 and 52; mm1@ This email is two-fold: (1) to further the discussion on Work Items 26-36 and 52 (all related) and (2) understand how or if to accommodate NOF (notification of failure) for v2.0. Work Item 26: What interactions are handled out of band - address notification of failure specifically at a minimum. Work Item 36: Clarify (if any) differences between NOF and AcceptAcknowledgement. Address if so in the specification. Do we need to be able to generate NOF Work Item 52: How will NOF affect TTP? May also relate to WI 2 (CPPA Negotiation). Key points: * Understand what happens if a NOF occurs. Do we replay collaboration or the transaction, and understand which one is failed. * Define what state is returned in BPSS when an NOF occurs. * Differentiate NOF and Negative Acceptance Acknowledgement * How to align when the NOF is out of band [1]. * Refine the enumerations expressed for the simpleTypes of Success and Failure conditions so you don't have a success under a failure [2]. [1] RosettaNet defines NOF that is handled out of band (via an alternate channel or transfer protocol). This is used for: 1. Timeouts when waiting for a specific response on a request. 2. Responder is unable to acknowledge, accept or process request. Note, that the RosettaNet picture is only an example. [2] Action as a result of February F2F (Dale Moberg). @mm1 Point|Author to champion and v2.0 boundaries; mm1@ I would like to ask for a champion or small team of volunteers to address NOF. I will help coordinate. I would ask Dale to follow-up on the simpleTypes item above. Others, please let me know. Thanks. @mm1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]