Semantics of AS4 Receipt

Hello,

 

I was working on an 
AS4-related topic over the weekend and have some questions on AS4 non 
repudiation receipts.

 

The AS4 profile is 
presented as designed to meet EDIINT requirements.  

 

According to section 
3.7 of http://tools.ietf.org/id/draft-ietf-ediint-req-09.txt EDIINT 
defines the requirements for non repudiation 
as:

 

"Receipt by the 
sender of a signed receipt, is an implicit
   acknowledgment of 
successful mailbox delivery. It is also an
   explicit 
acknowledgment that the Interchange was retrieved from
   the 
mailbox - pick-up notification. By having the receiver sign
   the 
receipt, it authenticates that the intended receiver picked up
   
the EDI Interchange -- mailbox authentication -- and that the
   
intended receiver verified the integrity of the EDI Interchange,
   
and the identity of the sender. By returning the original 
message
   id and the one-way hash value of the received contents 
back in the
   signed receipt, the sender can reconcile the 
acknowledged EDI
   Interchange with what was 
sent."

 

According to section 
8 of http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.odt the 
ebMS 3.0 Core Specification distinguishes between RM-Delivery and 
MSH-Delivery. 

Case 2: The acknowledgment is "on MSH-delivery" 
(supported in WS-Reliability). In that case, notification option 1 can be 
supported as well as option 2. In order for option 1 to be supported, an RMP 
must implement RM-Deliver operation so that it is only considered successful 
(worthy of sending an acknowledgment) if the Deliver operation from MSH to 
Consumer also succeeds. It is RECOMMENDED that an implementation support this 
acknowledgment semantics.

In http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/44888/AS4-profile-v1.0-wd22.odt 
section 3.4, the following is stated about 
AS4:

 

"The Receiving MSH 
is taking responsibility for processing this user message. However, no guarantee 
can be made that this user message will be ultimately delivered to its Consumer 
application (this responsibility lays however now on the Receiver 
side)."

 

Now this seems to be 
more like the RM-Delivery (only option supported in WS-ReliableMessaging) than 
MSH-Delivery ?   

 

The EDIINT definition of "non repudiation of receipt" seems to 
require MSH-Delivery rather than RM-Delivery.  If we're claiming that 
AS4 meets EDIINT requirements, is this enough ?

 

I'm not saying that 
AS4 products should support a VAN mailbox interface based on pickup of a 
message, and should delay sending a receipt until such a pick-up happened 
(possibly hours or days later).   Drawbacks of this have been 
discussed in the past when we looked at multi-hop reliability models. 

 

But in the AS4 
context, it could be defined as:  the MSH successfully passed 
responsibility for delivering the message to some third entity (system, program, 
user).

 

Examples of succesful or unsuccessful delivery could 
depend on implementation:

-   
Delivery to a mailbox:  

    
Succes:  message was added to mailbox.  

    
Failure:  quota exceeded, mailbox full.

    
(No guarantee that any user or system actually processes the 
message)

-   
Delivery to a file system:    

    
Success:  the MSH successfully created, wrote data to, and closed 
a file representation of the message metadata and contents.  

    
Failure:  Permission denied,  I/O errors

    
(There is no guarantee that any user or program actually processes the created 
file)

-   Delivery to a 
message queing system

    
Success:  successful enqueue()

    
Failure:  enqueuing failed 

    
(There is no guarentee that any other application dequeue the 
item)

-   
Delivery to another B2B messaging system:

    
Success:  the Submit() operation was invoked 
successfully

    
Failure:  Submit() operation failed

    
(No dependency on any downstream receipts)

 

In the case of 
failure, which the AS4 MSH can detect immediately after receiving a 
message,  I would prefer the AS4 to not send a Receipt but to send an Error 
instead. 

 

An alternative idea 
is discussed in section 8.2.4 of the ebMS 3.0 Core Specification, which has 
a discussion on false delivery failures:

 

"False DF - which 
can never be completely eliminated - can always be detected outside the reliable 
messaging (RM) layer, in a tractable and less urgent way - e.g. the sending 
party may synchronize on a daily basis by communicating its list of assumed 
delivery failures, for confirmation by receiver. The Status Request feature 
(which may be described in a forthcoming Part 2 of the ebMS specification) could 
facilitate this function."

 

Pim