[no subject]

See RNIF v2.0:
Section 2.6.4 Handling Failures
Failures can occur at any point in PIP execution, as discussed in the following
subsections. Two methods of handling failure are provided in RNIF 2.0:
sending an exception signal or initiating a Notification of Failure (NoF) PIP.
To determine whether an exception signal should be sent or whether to
initiate a NoF, the following guidance may be useful. In general, send an exception
signal if it is the case that the trading partner should still be executing the PIP in
question; initiate a NoF if it is possible that the other trading partner is not executing
the PIP (e.g., has not yet begun processing or has completed processing already).

Mukkamala: I see this as outside of timeout question.
I assumed that NOF and exceptions were there to provide better control outside of the process description.
Martin: We have two business requirements that should be met: One-way RN conditions and greater flexibility of business control.
Note the UMM reference specific to the timeouts referenced in my summary.

UMM R10, Chapter 8

Section 8.3.1 Business Action
===========
isNonRepudiationRequired. If non-repudiation of origin and content is required then the business activity must store the business document
in its original form for the duration mutually agreed to in a trading partner agreement. A responding partner must signal a business control exception if the sending
partner role has not properly delivered their business document. A requesting partner must send notification of failed 
business control if a responding partner has not properly delivered their business document. 
===========
timeToPerform. Both partners agree to perform a business transaction within a specific duration. A responding partner must exit
the transaction if they are not able to respond to a business document request within the agreed timeout period. A 
sending partner must retry a business transaction if necessary or must send notification of failed business control 
(possibly revoking a contractual offer) if a responding partner does not deliver their business document within the agreed time
period.
===========
TimeToAcknowlegeReceipt. Both partners agree to mutually verify receipt of a requesting business document within specific time
duration. A responding partner must exit the transaction if they are not able to verify the proper receipt of a business document
request within the agree timeout period. A sending partner must retry a business transaction if necessary or must send 
notification of failed business control (possibly revoking a contractual offer) if a responding partner does not verify 
properly receipt of a business document request within the agreed time period.
===========
timeToAcknowledgeAcceptance. Both partners agree to the need for a business acceptance document to be returned by a responding
partner after the requesting business document passes a set of business rules. The time to acknowledge business acceptance of a requesting business 
document is the duration from the time a requesting partner sends a business document until the time an acknowledgement of acceptance is 
“properly received” by the requesting partner. A responding partner must exit the transaction if they are not able to acknowledge business acceptance of a 
business document request within the agreed timeout period. A sending partner must retry a business transaction if necessary or must send notification of
failed business control (possibly revoking a contractual offer) if a responding partner does not acknowledge acceptance of a business document within the agreed time
period.
===========

<<<Note: In these references, the offer revocations imply legal aspects so only part of that is accommodated in ebBP
until a later version (looking to UBAC for guidance on metadata requirements/references).>>>

Moberg: We are specifying behavior not features like in UMM. We have to be more concrete to allow use of signals.
See Figure 20 in RNIF v2.0.
Mukkamala: NOF, exception and transitions included.
Moberg: This relates to Serm's question.
Martin: AIAG and IV&I folks see these challenges with underlying infrastructures and their monitoring process (NIST capability).
Moberg: Roberts included this in his business activity diagram.
Need to compare RNIF v2.0 Figure 20 <<<or Figure 21>>> to Roberts' diagram and then we have a basis
for addressing NOF.
Mukkamala: It is confusing when NOF can be sent and what happens in BSI and application.
Moberg: We need to straighten out as Cyclone will have to address the same question.
Webber: Can I fail or give more explicit detail about what failed?
Can we resolve, for example, where a CAM application can be more aware of what's going on?
See same issues with integrating Hermes ebMS to CAM engine.
Moberg: Where does error information go - error message, payload, signal or other? This is v3.0 issue.
Martin: We can handle definition to clarify the NOF, pattern and use in v2.0; address error handling in v3.0.
Moberg: Agreed.
Nagahashi: The RN usage is not a signal. IT impacts transactions that our product engine handles not the applications
(Fujitsu Interstage product). The NOF has to be delivered up to the application and has to revoke transaction completed.
It's like a transaction level control message.
Webber: In modeling arena this is not clear. You can use of diff signal mechanisms.
Moberg: Model driven exceptions are hard for implementations. We don't have a fully configurable way to use
signals, some static.
Mukkamala: Agreed. Allowing different signal mechanisms is too much for v2.0.
Moberg: I will volunteer to do an evaluation - 
Martin: Ask Mukkamala and Nagahashi, and others, to provide more feedback.
Schlegel: Given this, do we have an interest to organize interop days?
Martin: There is an OASIS Symposium in April 2005.
Moberg: When schema is finalized or almost there, we can discuss interop.
Webber: Offer from model view - work with implementers to harmonize implementations through the model in the interim.

RNIF v2.0 and ebBP references:
Figure 20 reference: http://www.oasis-open.org/archives/ebxml-bp/200409/msg00062.html (RN single action)
Figure 21 reference: http://www.oasis-open.org/archives/ebxml-bp/200409/msg00064.html (RN double action)
Roberts' business activity diagram: http://www.oasis-open.org/archives/ebxml-bp/200409/msg00063.html

ACTIONS:
Martin: Distribute minutes with diagrams and actions. Communicate decisions to TC on 13 Sept call.
Moberg: 
A. Send diagrams to group. DONE 10 SEPT 2004
B. Evaluate RN figures and Roberts' process diagram.







--Boundary_(ID_8YorhLgy3T3K8/NcaqrRGA)--