Semantics of AS4 Receipt

["Pim van der Eijk" <pvde@sonnenglanz.net>]

 

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