Subject: RFC 4823 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 14 May 2007 19:46:26 +0200 (MESZ)

Hello,
after studying the recently published RFC 4823 (EDIINT AS3)
authored by you, I would like to submit a few comments, pointing
out some issues I found with the RFC text, and supplying material
for an appropriate RFC Errata Note.

(A)

First of all, it is annoying to find this RFC notoriously neglecting
contemporary standard IETF terminology, using the sluggish and
confusing "header" where in fact "header field" should be used.

Please refer to RFC 2822, RFC 3864, RFC 4021, and RFC 4249
for the proper definitions of the established IETF terminology.

To quote from page 3 of RFC 4249:

3.1.1.  Standard Terminology

   Terms related to the Internet Message Format are defined in
   [N2.RFC2822].  Authors specifying extension header fields should use
   the same terms in the same manner in order to provide clarity and
   avoid confusion.  For example, a "header" [I1.FYI18], [N2.RFC2822] is
   comprised of "header fields", each of which has a "field name" and
   usually has a "field body".  Each message may have multiple
   "headers", viz. a message header and MIME-part [N4.RFC2046] headers.

   A message header has a Date header field (i.e., a field with field
   name "Date").  However, there is no "Date header"; use of such non-
   standard terms is likely to lead to confusion, possibly resulting in
   interoperability failures of implementations.

There's only a single place in the RFC where the correct term,
"header field" is used!

There are much too many instances of this primary issue to mention
in detail -- there are roughly 60 instances of this flaw, starting
with the title of Section 5, in the ToC, "AS3-Specific Headers".

(B)

Further textual flaws are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 2.3.1  -- indentation

In Section 2.3.1, the second-to-last list item on page 5 says:

                      vv
|  Non-repudiation of NRR is a "legal event" that occurs when the
   receipt (NRR)        original sender of an EDI/EC interchange has
                        verified the signed receipt coming back from the
                        receiver.  NRR IS NOT a functional or a
                        technical message.

It should say:
                      vv
|  Non-repudiation of   NRR is a "legal event" that occurs when the
   receipt (NRR)        original sender of an EDI/EC interchange has
                        verified the signed receipt coming back from the
                        receiver.  NRR IS NOT a functional or a
                        technical message.

(2)  Section 3.7

The RFC says:

   This Internet RFC defines how a Message Disposition Notification
|  (MDN)is requested, as well as the format and syntax of the MDN.  [..]

It should say:

   This Internet RFC defines how a Message Disposition Notification
|  (MDN) is requested, as well as the format and syntax of the MDN.  [..]
        ^

(3)  Section 6.3.2

Beyond issue (A), there are multiple other flaws in the text of
Section 6.3.2; the RFC says (on page 16):

                          [...].  The Content-Transfer-Encoding header
   SHOULD NOT be used; if the header is present, it SHOULD have a value
   of binary or 8-bit.  The absence of this header or the use of
   alternate values such as "base64" or "quoted-printable" MUST NOT
   result in transaction failure.  Content transfer encoding of MIME
   parts within the AS3 message are similarly constrained.

It should say:

                          [...].  The Content-Transfer-Encoding header
|  field SHOULD NOT be used; if this header field is present anyway, it
|  SHOULD have a value of binary or 8-bit.  The absence of this header
|  field or the use of alternate field values such as "base64" or
|  "quoted-printable" MUST NOT result in transaction failure.  The
|  Content-Transfer-Encoding of MIME bodies within the AS3 message is
|  similarly constrained.

Note:
Usually, only the *body* of a MIME entity (a RFC 2822 message or a MIME
body part) is subject to transfer encoding -- cf. RFC 2045, Section 2;
the MIME header (yes, in this case it's the `header`!) is subject to
encoding according to RFC 2047 and RFC 2231.  Thus, it is essential
here to distinguish precisely between these terms.

(4)  Section 7.4.1

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.

Section 7.4.1 of RFC 4823 says:

   The AS3-MDN follows the MDN specification [6] 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 [6] 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)

Note:
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.

(5)  Section 7.4.4

Item 8 in Section 7.4.4, on page 27 says:

   8.  The "failed" disposition type MAY NOT be used for the situation
       in which there is some problem in processing the message other
|      than interpreting the request for an MDN.  The "processed" or
|      other disposition type with appropriate disposition modifiers is
       to be used in such situations.

The ABNF given in Section 7.4.3, on page 25,

     AS3-disposition-type = "processed" / "failed"

explicitely excludes `other` disposition types.

Therefore, the above bullet should be corrected to say:

   8.  The "failed" disposition type MAY NOT be used for the situation
       in which there is some problem in processing the message other
|      than interpreting the request for an MDN.  The "processed"
|      disposition type with appropriate disposition modifiers MUST be
       used in such situations.

Note:
I also have balanced the use of RFC 2119 formal specification language
in the modified text.
Note to the RFC-Editor/bb:  cf. your note on RFC 4866   :-)

(6)  Section 9

Quoting S/MIME Version 2 for encryption strength and 40-bit encryption
is ridiculously outdated, IMHO !
Unfortunately, it is still necessary to remind readers that 56-bit
strength (DES) is much too weak today!

(7)  Appendix A.2

Near the bottom of page 38, there's a typo in the Note #1.
The RFC says:
                     v
|     1. The lines proceeded with "&" are what the signature is
         calculated over.

It shoud say:
                     v
|     1. The lines preceeded with "&" are what the signature is
         calculated over.

Please comment.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+