[ebBP] 8/4/2004: Update on NOF Questions and Summary [RSD]

[Monica Martin <Monica.Martin@Sun.COM>]

Discussion|OASIS.ebBP.WI36-39-52-60-NOF and General Exceptions;
Topic|;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00123.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00035.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00137.html;
Point|Updated scope of Notification of Failure;

mm1@
In Monday's call (2 August 2004), we briefly discussed the NOF message and general exceptions, and questions from Hima
Mukkamala, the signals author.  I indicated I'd provide some additional background on the request for a general
exception signal from Martin Roberts, BT and our recent team discussions:.

In the editors' and previous team F2F meetings, we discussed NOF, general exception signals and signals in general (no pun intended) at length. In line with the team's input and editors here were the original parameters set for NOF (Notification of Failure):

   * Separate NOF 'BUSINESS MESSAGE' from general exception 'SIGNAL'.
   * A technical failure can bubble up to a sufficient business state resolution via a signal or a timeout.
   * Specify a NOF could occur only if a timeout occurs for failure to
     receive a requesting or responding business document. In the case
     when there is reliable messaging which shows the receipt of
     request or response,the party should not be capable of sending
     NOF. If for example, a response is sent then a NOF by a responder.
     That is an anomaly; this is to be handled by the business
     agreement (UBAC).
   * Separate and differentiate NOF message, general exception signal (if accepted and developed) and Neg AA.
         o Negative Acceptance Acknowledgment: You recognize you have a problem.
         o NOF: Allows us to clear the slate when the normal exception methods do not apply.
   * Add: Specify a NOF as a new BT pattern.

Mukkamala and Roberts have asked about what should happen if:

   * Extraneous conditions cause the responder or requestor to send
     NOF to invalidate the existing transaction or collaboration (Mukkamala).

       e.g. If a requestor sends a purchase order and responder sends
       an AA, requestor may want to invalidate the current transaction
       because some condition in his system caused the invalidation of
       the PO. This is not part of the reqular business process, however.

   * Could NOF be used as a general purpose exception handling
     mechanism or do we restrict it to conveying expiration of TTP? (Mukkamala)

   * Cannot send an AA if the appropriate flag isn't set and the pattern is complete (Roberts). Is allowing that via
     an extension of the BT pattern acceptable? Can we send AnyProtocolFailure outside of a transaction?

More about NOF and general exception, industry business requirements:
1. RosettaNet: General failure notification applies. This typically is used after a ReceiptAcknowledgement [1]. Implies, for example, something is wrong with order.
2. UBAC: Per Tell, need to provide notification a message was expected not received. This equates to asking for information not
just non-receipt indicator.
3. CPPA: Handling of exceptions are not part of CPPA.
4. Amazon: Has seen different expected and unexpected failures. Don't want to handle unexpected failures; expected failures need to translate to a business result.
Example, expecting a quote, but never received. Another transaction must occur. This doesn't mean abandonment with the
protocol.
5. British Telecom: When a collaboration or collaboration is replayed, which one is failed?  This could be defined or left
to local practice. Determine if exception handling is in another reusable step.  Handle in WI-2 in v3.0.

Note on 5: David W., I am not certain the criteria for a general exception signal had to do with changing roles as you indicated.
Thanks.
=============================
[1] 
Reference: ebXML BPSS v1.1, Section 5.14.2.3
isNonRepudiationOfReceiptRequired.
Both partners agree to mutually verify receipt of a requesting business document and that the receipt must be non-
repudiable. A requesting partner must initiate a notification of failure business transaction business (possibly revoking a contractual offer) if a responding partner has not properly delivered signed their receipt. For a further discussion of
nonrepudiation of receipt, see also the ebXML E-Commerce and Simple Negotiation Patterns.
=============================

Thanks.

@mm1