20 messages in org.oasis-open.lists.ebxml-bpRE: [ebxml-bp] 1/27/2004: BPSS Signal...| From | Sent On | Attachments |
|---|---|---|
| Lars...@teliasonera.com | Dec 12, 2003 10:32 am | |
| Monica J. Martin | Dec 14, 2003 10:51 am | |
| Boonserm (Serm) Kulvatunyou | Dec 28, 2003 6:23 pm | |
| Monica J. Martin | Dec 29, 2003 6:37 am | |
| Boonserm (Serm) Kulvatunyou | Dec 29, 2003 7:23 am | |
| David RR Webber | Dec 29, 2003 8:55 am | |
| Monica J. Martin | Dec 29, 2003 10:30 am | |
| Lars...@teliasonera.com | Jan 2, 2004 4:18 am | |
| David RR Webber | Jan 2, 2004 9:47 am | |
| Yunker, John | Jan 5, 2004 8:45 am | |
| Monica J. Martin | Jan 27, 2004 5:21 pm | |
| Yunker, John | Jan 27, 2004 5:33 pm | |
| Yunker, John | Jan 27, 2004 5:45 pm | |
| Monica J. Martin | Jan 27, 2004 5:45 pm | |
| David RR Webber | Jan 27, 2004 9:23 pm | |
| mart...@bt.com | Jan 29, 2004 1:35 am | |
| Yunker, John | Jan 29, 2004 8:20 am | |
| Hima...@sybase.com | Jan 29, 2004 8:56 am | |
| Duane Nickull | Jan 29, 2004 11:11 am | |
| Monica J. Martin | Jan 29, 2004 5:30 pm |
| Subject: | RE: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59) | |
|---|---|---|
| From: | Yunker, John (yun...@amazon.com) | |
| Date: | Jan 27, 2004 5:33:03 pm | |
| List: | org.oasis-open.lists.ebxml-bp | |
I suppose you could put the receipt ack information into the response and not need a response, however JUST HAVING a response does NOT satisfy legal requirements on the content of the request nor proof of receipt of the request. Most legal disputes that attempt to say "specific action should have been taken" MUST show that the request (and its content) is exactly what was received.
The question is not timing, not "did they get a request", but more EXACTLY WHAT was received and EXACTLY WHEN was it received and with proof.
John
-----Original Message----- From: Monica J. Martin [mailto:Moni...@Sun.COM] Sent: Tuesday, January 27, 2004 5:32 PM To: Yunker, John Cc: ebxm...@lists.oasis-open.org; hima...@sybase.com Subject: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59)
Yunker: The problem with implicit positive signals is that they are used for more than moving the state of the collaboration forward.
A [signed] positive receipt is used for non-repudiation of receipt. At the business layer (e.g. BPSS) this is may be referenced in legal agreements regardless of transport protocol used, and can also start SLA requirements that do not assume perfectly functioning transport architecture. Placing the non-repudiation requirement on the response makes it difficult to standardize monitoring and management of these important signals.
I suppose that a collaboration that does not want to use a legal non-repudiation framework could make these positive signals optional.
mm1: John, would there be an option to delineate that a signal actually is a combination of several signals to meet the non-repudiation requirements [1]. This is not a recommendation but a question.
Lars (and Hima), this was your original issue. Any comments? Thanks.
[1] We have seen related recommendations in the messaging arena.
-----Original Message----- From: Lars...@teliasonera.com [mailto:Lars...@teliasonera.com] Sent: Friday, January 02, 2004 4:27 AM To: ebxm...@lists.oasis-open.org Subject: RE: [ebxml-bp] [12/12/03]: BPSS Signals
Happy New Year to you all
I think the issue regarding the BPSS Signals needs to be split in two parts. a) Explicit negative signals In the learning session about signals Hima told us that it is always OK to send exeptions (i.e. negative Receipt or Acceptance Exception) and one should always be prepared to receive these signals even though (positive) signals are not enabled by setting a value > 0 in the timeToAcknowledgeReceipt and/or the timeToAcknowledgeAcceptance attributes. This is not clear from the current spec especially when looking at Figure 17.
b) Implicit positive signals I believe that if an Acceptance Acknowledgment signal or a substantive business Response is received before the expiration of the timeToAcknowledgeReceipt a Receipt Acknowledgment signal can be implied if not already explicitly received. Also that if a substantive business Response is received before the expiration of the timeToAcknowledgeAcceptance an Acceptance Acknowledgment signal can be implied if not already explicitly received.
* Lars...@TeliaSonera.com * +46 (0) 705 619080 * Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden
-----Original Message----- From: Monica J. Martin [mailto:Moni...@Sun.COM] Sent: Monday, December 29, 2003 7:49 PM To: David RR Webber Cc: Boonserm (Serm) Kulvatunyou; ebxm...@lists.oasis-open.org Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals
Serm, +1.
It's crazy to have three or four messages exchanged here. The answer would appear to be - that one message can indicate multiple things - I would suggest:
1) Acceptance Acknowledgement is also implied Receipt Ack so no need to send RecAck if you send an AccAck (timing is something you need to determine -if your business process may mean a time-out could occur between receipt and calculating the acceptance - then you will need to send both).
mm1: You cannot imply Receipt Ack is successful unless the business rules allow for that. As you point out there is an inherent chance of failure any assumptions that are made (and timeouts could apply as well). This should be discussed by the team.
2) Negative Receipt and Acceptence Exception - clearly these are different - so you need to be able to handle both these conditions - and you should only get one of these at a time.
mm1: As you have indicated they have different meanings. We need to investigate the tradeoffs between what is declaratively defined and possible (at design time) and be at least conscious of what can happen later. I am certain the team will have further discussion on this topic as we go into the new year and plan for the F2F. Thanks.
DW.