RE: [ebxml-bp] [12/12/03]: BPSS Signals

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

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.

Thanks!
John

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


David RR Webber wrote:

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