Subject: RFC 4141 errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 22 Nov 2005 14:50:18 +0100 (MEZ)

Hello,

I'd like to report a couple of flaws I found reading the
recently published RFC 4141, "SMTP and MIME Extensions for
Content Conversion", authored by you.

I propose to post an errata note for this RFC according to the
subsequently listed items (presented in text order).
[Casually, I place change bars ('|') in column 1 to emphasize
the location of the proposed correction.]

(1)

In Section 1.2, the last paragraph at the bottom of page 4 says:

     *  three MIME Content header fields (Content-Convert, Content-
        Previous and *  Content-Features) that specify appropriate
        content header fields and record conversions that have been
        performed.

It should say:

     *  three MIME Content header fields (Content-Convert, Content-
|       Previous and Content-Features) that specify appropriate
        content header fields and record conversions that have been
        performed.

(2)

In Section 3, the fourth paragraph on page 6 says:

   When CONPERM is used, conversions are performed by the first ESMTP
   host that can obtain both the originator's permission and information
   about the capabilities supported by the recipient.  If a relay or
   client is unable to transmit the message to a next-hop that supports
   CONPERM or to perform appropriate conversion, then it terminates
   message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the
   originator, with status code 5.6.3 (Conversion required but not
   supported).

It should say:

   When CONPERM is used, conversions are performed by the first ESMTP
   host that can obtain both the originator's permission and information
   about the capabilities supported by the recipient.  If a relay or
   client is unable to transmit the message to a next-hop that supports
   CONPERM or to perform appropriate conversion, then it terminates
|  message transmission and returns a Delivery Status Notification (DSN)
   [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3
   (Conversion required but not supported).

Rationale:  Probably, that triple of RFCs should not be sent  :-)
The proposed text change conforms to the current authoring style
guides for I-Ds / RFCs, spelling out the abbreviation 'MDN' at its
first occurrance in the text.

(3)

Similarly, the final NOTE in Section 3, on page 9, says:

         NOTE: An originator MAY validate any conversions that are made
         by requesting a positive [DSNSMTP].  ...

where it should better say:

         NOTE: An originator MAY validate any conversions that are made
|        by requesting a positive DSN [DSNSMTP].  ...

(4)

The second item of the first enumerated list in Section 3.3,
on page 12, contains a (visually hidden) word replication.
The text says:

      2) MUST return a DSN notification to the originator, with status
         code 5.6.3 (Conversion required but not supported).  [DSNSMTP,
         DSNFMT, SYSCOD]

It should say:

|     2) MUST return a DSN to the originator, with status code 5.6.3
         (Conversion required but not supported).  [DSNSMTP, DSNFMT,
         SYSCOD]

Rationale: The trailing "N" of "DSN" already stands for "notification".

(5)

To make the spelling of [E]SMTP keywords and verbs consistent within
the text, the headline of Section 4.2 (on page 13),

  4.2.  CONPERM Parameter to Mail-From

should better use uppercaes spelling as well, to read:

  4.2.  CONPERM Parameter to MAIL-FROM

(6)

The ABNF given in Section 7, on page 16, and Section 8, on page 17,
does not fully conform to the contemporary (RFC 2822) style.
The ABNF in Section 7 omits the explicit specification of white
space usage that presumably has been intended.
The ABNF in Section 8 inserts a paramount of CFWS.

NOTE:
- RFC 2822 has deprecated the use of white space between header
  field names and the subsequent ":" and, as far as I can see,
  comments have not been allowed at such places by RFC 822,
  and aren't by the "obsolete syntax" in RFC 2822.
- RFC 2822 has carefully made [C]FWS an intrinsic part of many
  low-level syntactic constructs to improve readability of the
  high-level ABNF productions. Thus, CFWS should not be inserted
  again where it is (logically) already present.

Furthermore, the spelling of ABNF production names should be
self-consistent within a certain field. RFC 2822 makes use of
lowercase production (rule) names for teh syntactic description
of the Internet Message Format; therefore it seems preferrable
to follow this style when defining IMF extensions.

In the light of these explanations (and detailed inspection of
RFC 2822), the ABNF productions in Section 7 :

      Convert =                "Content-convert" ":"
                               permitted

      Permitted =              "ANY" / "NONE" / permitted-list

should perhaps be re-written as :

      convert =           "Content-convert:" [CFWS] permitted

      permitted =         "ANY" / "NONE" / permitted-list

and the ABNF productions in Section 8 :

      previous =          "Content-Previous" [CFWS] ":"
                          [CFWS]
                          date by type

      date =              "Date " [CFWS] date-time [CFWS] ";"
                          [CFWS]

      by =                "By " [CFWS] domain [CFWS] ";"
                          [CFWS]

should perhaps be re-written as :

      previous =          "Content-Previous:" date by type

      date =              "Date " [CFWS] date-time ";" [CFWS]

      by =                "By " domain ";" [CFWS]

or even (disallowing comments after "Date " - like RFC 2822 does):

      previous =          "Content-Previous:" date by type

      date =              "Date " date-time ";" [CFWS]

      by =                "By " domain ";" [CFWS]

(7)

The examples in Section 9 contain improperly truncated references
to MIME Content-Types.
The following line that appears
  -  in Section 9.1 in the 3rd text line on page 18,
and
  -  in Section 9.2 in the 10th text line :

   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX

should, in both cases, read:

   C: <<RFC 2822 message with MIME Content-Type: image/TIFF-FX

(8)

In Appendix C, the headline:

  Appendix C.  MIME Content-Type Registrations

should say:

  Appendix C.  MIME Header Field Registrations

(9)

Perhaps, in Appendix C, the IANA should have been directed to
add to the MIME Header Registration for "Content-Features:"
an additional reference to RFC 4141.
E.g., add on page 25, before the "Authors' Addresses":

  C.3.  Content-Features

    This memo substantially amends the specification of the
    MIME Header Field "Content-Features:" registered by [[FEAT].
    The IANA should include into the 'Specification document(s)'
    clause of that registration a pointer to RFC 4141.

Best 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]                     |
+------------------------+--------------------------------------------+