RE: [ebxml-bp] ebBP 7/20/2005: Timing Parameters - wd-r07 Agreed 19 July 2005

["Yunker, John" <yunker@amazon.com>]

Hmmmm...  I'm starting to see why "plus" was used previously in the well-formed description.

(Note that in my proposed text below, the tortured language may suggest that this is just an area where well-formed rules are not necessary.  So what if the time to perform timeout fires before the receipt ack timeout fires?  They are both well defined and accessible. )

re: 
TimeToPerform that is equal to or greater to the 
timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance on the 
Response (given which, if any, are used).

should be:
TimeToPerform that is equal to or greater than the larger of
timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance on the 
Request plus the larger of timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance on the 
Response (given which, if any, are used).

John

-----Original Message-----
From: Monica J Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Wednesday, July 20, 2005 12:14 PM
To: ebXML BP
Subject: [ebxml-bp] ebBP 7/20/2005: Timing Parameters - wd-r07 Agreed 19 July 2005


Changes agreed to in 19 July 2005 call on timing parameters, that will 
be included in wd-r07 for Committee Draft vote and review. Please advise 
if any changes are required. Thanks.

===============
Section 3.4.9.3.3
Change from:
Based on any agreement between the parties, the requesting party 
typically MAY recognize that the Business Document had been successfully 
received and processed. Where applicable and used, the logical sequence 
of the Receipt Acknowledgement, Acceptance Acknowledgement and Response 
are based on the timing expectations defined. For example, in 
implementation, if an Acceptance Acknowledgement is received prior to a 
Receipt Acknowledgement, the requesting party may wait (if no timeout), 
for the Receipt Acknowledgement because the two Business Signals are 
handled by different systems.

Change to:
Based on any agreement between the parties, the requesting party 
typically MAY recognize that the Business Document had been successfully 
received and processed. Where applicable and used, the logical sequence 
of the Receipt Acknowledgement, Acceptance Acknowledgement and Response 
are based on the timing expectations defined. For example, in 
implementation, if an Acceptance Acknowledgement is received prior to a 
Receipt Acknowledgement, the requesting party may wait (if no timeout), 
for the Receipt Acknowledgement because the two Business Signals are 
handled by different systems. Occurrence of Business Signals and their 
receipt are not dependent. Occurrence is summarized in Section 3.5.1.

Section 3.5.1
Change from:
* Control will be returned back to the Requesting Activity if either a 
ReceiptAcknowledgement and/or AcceptanceAcknowledgement and/or a 
Response are specified as required. A ReceiptAcknowledgement (if 
required) MUST always occur before an AcceptanceAcknowledgement (if 
required), and an AcceptanceAcknowledgement MUST always occur before a 
Response (if required). Control is returned to the Requesting Activity 
based on the last required of these three (if any). If none required, 
control stays with the Responding Activity.

Change to:
* Control will be returned back to the Requesting Activity if either a 
ReceiptAcknowledgement and/or AcceptanceAcknowledgement and/or a 
Response are specified as required. A ReceiptAcknowledgement (if 
required) MUST always occur before an AcceptanceAcknowledgement (if 
required), and an AcceptanceAcknowledgement MUST always occur before a 
Response (if required). Control is returned to the Requesting Activity 
based on the last required of these three (if any). If none required, 
control stays with the Responding Activity. Occurrence of Business 
Signals and their receipt are not dependent. Receipt is summarized in 
Section 3.4.9.3.3.

Section 3.6.1:
[Add descriptive text to this section due to deletion on Section 
3.6.2.3. Note this change also reflects other decisions made 19 July 2005] Change from: The timeout value for each of the timeout parameters is absolute i.e. 
not relative to each other. All timers start when the initial Requesting 
Business Document is sent. The timer values MUST conform to the 
well-formedness rules for timer values. Refer to Section 3.8. ...... The 
total time allowed for a BTA to complete is therefore, TimeToPerform 
that is equal to or greater to the timeToAcknowledgeReceipt and the 
timeToAcknowledgeAcceptance on the Response (given which, if any, are 
used). Additionally, TimeToPerform for that BTA MUST be greater than the 
sum of timeAcknowledgeReceipt and timeToAcknowledgeAcceptance and the 
Request.

Change to:
The timeout value for each of the timeout parameters is absolute i.e. 
not relative to each other. All timers start when the initial Requesting 
Business Document is sent. Correlating timeouts is partner-specific. All 
timeouts typically SHOULD be reported independent of their priority. The 
timer values MUST conform to the well-formedness rules for timer values. 
Refer to Section 3.8......The total time allowed for a BTA to complete 
is therefore, TimeToPerform that is equal to or greater to the 
timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance on the 
Response (given which, if any, are used).

Section 3.6.2.3:
[Delete sentence as agreed 19 July 2005]
Change from: Typically, the TimeToPerform is a higher priority than 
Acceptance Acknowledgement, which is a higher priority than Receipt 
Acknowledgement. Process (signal) timeouts are recoverable within retry 
parameters and not recoverable outside of the retry parameters. Change to: Process (signal) timeouts are recoverable within retry 
parameters and not recoverable outside of the retry parameters. ===============