[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] 1/27/2004: BPSS Signals (Work Item 59)
If requested by the presence of nonRepudiationOfReceipt in the bpss,
signal can include the signature of the requesting document and its parts
as identified by the references in the signature.
I think it needs to be clarified in the specification that references can
be included
without producing signature using the "NonRepudiationInformation" which
has "ds:Reference" as child element. This will only have the digests
of the message parts.
-thanks
Type of ReceiptAcknowledgment
<xsd:complexType>
<xsd:complexContent>
<xsd:extension
base="bpssignal:SignalIdentificationInformation">
<xsd:sequence>
<xsd:element
ref="bpssignal:NonRepudiationInformation" minOccurs="0"/>
<xsd:element ref="ds:Signature"
minOccurs="0"/>
<xsd:any namespace="##other"
minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<martin.me.robert
s@bt.com>
To
01/29/2004 01:46 <yunker@amazon.com>,
AM <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.
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]