RFC 4823, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", April 2007Source of RFC: ediint (app)
Errata ID: 2284
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-15
Section 7.4.1 says:
The AS3-MDN follows the MDN specification  except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message- headers. The format of the AS3-MDN is MDN, no signature -RFC822/2045 -RFC3798 (message/disposition-notification) <<page break>> MDN, signature -RFC822/2045 -RFC1847 (multipart/signed) -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature)
It should say:
The AS3-MDN follows the MDN specification  except where noted in | this section. Refer to RFC 2045 for the format of MIME headers. | The format of the AS3-MDN is MDN, no signature | -RFC2822/2045 | -RFC3462 (multipart/report; | report-type=disposition-notification) | -RFC2046 (text/plain) | -RFC3798 (message/disposition-notification, | as modified by Section 7.4.2) MDN, signature | -RFC2822/2045 -RFC1847 (multipart/signed) | -RFC3462 (multipart/report; | report-type=disposition-notification) | -RFC2046 (text/plain) | -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature)
Unlike, e.g., Section 4.2, the message structures depicted in
Section 7.4.1, on pages 23/24, are imprecise and misleading;
'message/disposition-notification' is *not* the atomic MIME entity
shown in the text; according to RFC 3798, the MDN is encapsulated
in a 'multipart/report', which has a mandatory first body part
of type 'text/plain', not shown in the current text.
Because RFC 4823 explicitely quotes RFC 822 (should better be 2822!),
RFC 2045, and RFC 3798, I strongly suspect that the specification
indeed wanted to re-use the MDN structure specified in RFC 3798.
This is supported by subsequent details exposed in Section 7.4.2.
Furthermore, the RFC text there introduces a notation that is not
made use of anywhere in the RFC. That sentence is to be deleted.
I have omitted the third, optional body part of the 'multipart/report'
-- cf. the final remark (#4) at the end of Appendix A.2 of RFC 4823,
which recommends against making use of it.