RFC 4823, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", April 2007

Note: This RFC has been updated by RFC 8996

Errata ID: 955
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

(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)  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 should say:
                     v
|     1. The lines preceeded with "&" are what the signature is
         calculated over.

It should say:

[see above]

Notes:

Source: apps

Report New Errata