RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005

Source of RFC: ediint (app)

Errata ID: 3055
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: JP McCrory
Date Reported: 2011-12-20
Rejected by: Pete Resnick
Date Rejected: 2011-12-29

Throughout the document, when it says:

      Disposition: automatic-action/MDN-sent-automatically;
      processed/warning: duplicate-document

      Disposition: automatic-action/MDN-sent-automatically;
        processed/warning: duplicate-document
      Warning: An identical message already exists at the
        destination server.

      Disposition: automatic-action/MDN-sent-automatically;
      Warning: duplicate-document

It should say:

(Remove/replace warning examples from section '7.5.6.  Backward Compatibility with Disposition Type, Modifier, and Extension' - see notes)

9.3.  Replay Remark

   Because business data documents normally contain transaction ids,
   replays (such as resends of not-yet-acknowledged messages) are
   discarded as part of the normal process of duplicate detection.
   Detection of duplicates by Message-Id or by business transaction
   identifiers is recommended.

(Add following comment to above section.)
   If duplicate is detected the disposition should be returned with 
   'processed' and without an error or warning status unless other
   errors occurred. Sending an error or warning on a duplicate can
   result in an endless communication loop between retransmissions
   and resulting error/warnings.


Endless communication loops are a problem with AS2 and this is only supported by the RFC and its multiple examples of 'duplicate-document'. What most commonly happens is a file is sent synchronously to one of our partners but our two minute timeout in holding the connection for an MDN is reached. The recipients AS2 software generated the MDN but doesn't recognize the connection is no longer available for MDN return and as a result non-repudiation of receipt has not occurred. The file is later resent to the partner who then promptly sends an MDN with a processed/warning condition again not meeting our threshold of non-repudiation of receipt.

We have three or four occurrences of this exact scenario occur every week and because the RFC undercuts our ability to get AS2 software clients to address this issue at all many of our supplier are forced to manually mark their files as transmitted manually through a mailbox UI we have online.

We understand the need for duplicate detection and have our own in place but implemented in a way that endless communication loops cannot occur. Balanced duplicate detection is advised because to stringent of duplicate detection especially done within the communication protocol itself if problematic. An example of this would be partner who receive a file but then have issues in processing the data and did not take an archive of their data before processing as many do. These partners have requested our system to resend their data AS2 only to find the data is rejected before the file is received because it has the same 'message-id' as it did the first time it was sent and their AS2 software still have the message-id stored in their software's receiving records.

Again I support duplicate checking but it needs to be better defined for AS2 especially the elimination of the duplicate warning with the understanding of the unending communication loops that it can create through no fault of anyone just a missed MDN on the initial communication is all it takes.
Aside from this being a poorly formatted report (it does not give proper original/change text and should probably have been split into multiple errata), none of this is at all appropriate for an erratum. This is a change to the examples and to add an additional warning given operational experience. This needs to be done via a document update, not an erratum.

Report New Errata