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

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

>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.
>>