Re: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59)

[Duane Nickull <dnickull@adobe.com>]

Are we addressing the tie in between the CPA value of "mustPersist" and 
the business audit trail requirements that a Business Process execution 
engine may have to keep that information in a persistent store (or 
access it from another persistent storage container) for a certian 
period of time?  It seems to me that these items may have to be 
recallable for certain industries.  In Justice, a judge who signs a 
wiretap order may have to be able to say he did so by seeing a certain 
document (exactly as is) on a previous date.

Duane

Yunker, John wrote:

>Yes, the receipt contains the signiture and your assertion that you checked the signiture against the content, verifying the message content has arrived exactly as sent.  This allows your trading partner to take business action due to shared understanding (possibly contractual) of the agreed commitment for completing the associated business action.
>
>I know that is a mouthful, but it is all about taking friction out of the supply chain, and optimizing the execution of the collaborative process.  
>
>John
>
>-----Original Message-----
>From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com] 
>Sent: Thursday, January 29, 2004 1:47 AM
>To: Yunker, John; Monica.Martin@Sun.COM
>Cc: ebxml-bp@lists.oasis-open.org; himagiri@sybase.com
>Subject: RE: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59)
>
>
>Does this mean a receipt could contain the MD5 signiture of the message to prove we got what was sent?
> 
>Martin
>
>	-----Original Message----- 
>	From: Yunker, John [mailto:yunker@amazon.com] 
>	Sent: Wed 28/01/2004 01:44 
>	To: Monica J. Martin 
>	Cc: ebxml-bp@lists.oasis-open.org; himagiri@sybase.com 
>	Subject: RE: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59)
>	
>	
>
>	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:Monica.Martin@Sun.COM]
>	Sent: Tuesday, January 27, 2004 5:32 PM
>	To: Yunker, John
>	Cc: ebxml-bp@lists.oasis-open.org; himagiri@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.Abrell@teliasonera.com [mailto:Lars.Abrell@teliasonera.com]
>	>Sent: Friday, January 02, 2004 4:27 AM
>	>To: ebxml-bp@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.Abrell@TeliaSonera.com * +46 (0) 705 619080
>	>* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden
>	>
>	>-----Original Message-----
>	>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
>	>Sent: Monday, December 29, 2003 7:49 PM
>	>To: David RR Webber
>	>Cc: Boonserm (Serm) Kulvatunyou; ebxml-bp@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.
>	>>
>	
>	
>
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com