RFC Errata
Found 5 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
Source of RFC: ediint (app)
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.
Status: Held for Document Update (2)
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
Source of RFC: ediint (app)
Errata ID: 2283
Status: Held for Document Update
Type: Technical
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
Section 9 says:
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!
Notes:
Source: apps
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