Found 3 records.

Status: Verified (3)

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: 2282
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 7.4.4 says:

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.

It should 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.

Notes:

The ABNF given in Section 7.4.3, on page 25,

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

explicitely excludes "other" disposition types.


Source: apps

Errata ID: 2284
Status: Verified
Type: Technical
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 [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)

Notes:

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.

Errata ID: 6234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-07-23
Verifier Name: Barry Leiba
Date Verified: 2020-08-04

Section 6.1 says:

   the AUTH command described within [4].  While any authentication
   mechanism based upon [4] MAY be utilized, AUTH TLS (as described in
   [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0
   [13], not Version 1.1 [23].)

It should say:

   the AUTH command described within [4].  While any authentication
   mechanism based upon [4] MAY be utilized, AUTH TLS (as described in
   [18]) MUST be supported. (Note that TLS Version 1.1 [23] is the current
   version of TLS, though [18] references the older Version 1.0 [13].)

Notes:

RFC 4217 (reference [18]) does not specifically require TLS version 1.0. It references RFC 2246 (TLS 1.0) solely because that was the only version of TLS specified at the time of its publication. Securing FTP with TLS merely requires a version of TLS, not a specific version of TLS, so this document should refer to the current version of TLS at the time of its own publication.

Note that [13] is listed as a normative reference and [23] an informative reference; in light of the above correction the normative/informative statuses should be swapped.

Report New Errata