RFC Errata
Found 9 records.
Status: Verified (7)
RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006
Source of RFC: ldapbis (app)
Errata ID: 7216
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section 4.1.6 says:
the value syntax. See objectIdentiferFirstComponentMatch in
It should say:
the value syntax. See objectIdentifierFirstComponentMatch in
Notes:
Typo.
Errata ID: 7217
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section 4.1.11 says:
- direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's specification),
It should say:
- direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field defined above should not be altered by the control's specification),
Notes:
Erroneous "are".
Errata ID: 7218
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section 4.4 says:
choice using the ExtendedResponse type (See Section 4.12). The
It should say:
choice using the ExtendedResponse type (see Section 4.12). The
Notes:
The word "see" should not be capitalized here.
Errata ID: 7219
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section 4.4 says:
- the OBJECT IDENTIFIER assigned to the notification (to be specified in the responseName,
It should say:
- the OBJECT IDENTIFIER assigned to the notification (to be specified in the responseName),
Notes:
Missing parenthesis.
Errata ID: 7220
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section 8 says:
[RFC4512] Zeilenga, K., Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
It should say:
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
Notes:
Missing quotation mark.
Errata ID: 7221
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section A.2 says:
the code may used to indicate an alias has been dereferenced that names no object.
It should say:
the code may be used to indicate an alias has been dereferenced that names no object.
Notes:
Missing "be".
Errata ID: 7222
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01
Section C.1.17 says:
- The SubstringFilter substrings 'initial, 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added
It should say:
- The SubstringFilter substrings 'initial', 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added
Notes:
Missing quotation mark.
Status: Reported (1)
RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006
Source of RFC: ldapbis (app)
Errata ID: 5292
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Ansmann
Date Reported: 2018-03-21
Section 4.5.1/Appx.B says:
Filter ::= CHOICE { and [0] SET SIZE (1..MAX) OF filter Filter, or [1] SET SIZE (1..MAX) OF filter Filter, not [2] Filter,
It should say:
Filter ::= CHOICE { and [0] SET SIZE (1..MAX) OF filter Filter, or [1] SET SIZE (1..MAX) OF filter Filter, not [2] EXPLICIT Filter,
Notes:
As currently written, the specification requires IMPLICIT tagging for the not-filter. This, according to ITU-T X.690, Section 8.14.3, Example "Type5", requires the [2]-tag of the not-filter to overwrite the tag of the negated filter, making reliable identification of the type of the negated filter impossible. Thus, the definition of the not-filter needs to specify EXPLICIT tagging. Alternatively, the filter could be specified as
not [2] SEQUENCE { filter Filter },
or (to match the definition of "and" and "or")
not [2] SET SIZE (1..1) OF filter Filter,
This applies to both, Section 4.5.1 and Appendix B.
Status: Rejected (1)
RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006
Source of RFC: ldapbis (app)
Errata ID: 75
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Rejected by: Jim Sermersheim
Date Rejected: 2006-07-03
(2) Typo Section 2, on page 4, contains the paragraph: v | The term "SASL layer" refers to Simply Authentication and Security Layer (SASL) services used in providing security services, as well as associations established by these services. It should say: v | The term "SASL layer" refers to Simple Authentication and Security Layer (SASL) services used in providing security services, as well as associations established by these services. (3) Misrepresented relationship between ISO 10646 and Unicode Section 4.1.2 unfortunately has not corrected a misconception initially spelled out in RFC 2251. The first paragraph of Section 4.1.2, on page 7, says: The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as ASN.1 OCTET STRING types, the | [ISO10646] character set (a superset of [Unicode]) is used, encoded following the UTF-8 [RFC3629] algorithm. [...] The (..) enclosed note on the relationship of ISO 10646 and Unicode is *not* appropriate, as far as I know: Unicode covers exactly the same character repertoire as ISO 10646, but it *adds* a lot of *semantics* to ISO 10646. The character repertoire synchronization between ISO 10646 and Unicode is said to hold since 1993, and it is promised for all future updates. (Details can be found in Section 1.4 and Appendix C of The Unicode Standard (book and online version), verbatim identical in the Unicode 3.0 and Unicode 4.0 versions.) In particular, this congruence holds for Unicode 3.2.0 (and the coordinated edition of ISO 10646) that has been made the invariable base for the new LDAP specs. Therefore, the above sentence should perhaps better be corrected to say: The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as ASN.1 OCTET STRING types, the | [ISO10646] character set (as detailed in [Unicode]) is used, encoded following the UTF-8 [RFC3629] algorithm. [...] (or similar). (4) Typo (word omission) The 3rd paragraph of Section 4.2.2, on page 18, says: If the client receives a BindResponse where the resultCode is set to protocolError, it is to assume that the server does not support this | version of LDAP. While the client may be able proceed with another version of this protocol (which may or may not require closing and re-establishing the transport connection), how to proceed with another version of this protocol is beyond the scope of this document. Clients that are unable or unwilling to proceed SHOULD terminate the LDAP session. It should say: vvvv | [...]. While the client may be able to proceed with another version of this protocol (which may or may not require closing and re-establishing the transport connection), how to proceed with another version of this protocol is beyond the scope of this document. [...] Items (2)..(4) above might be considered for an Errata Note to be posted to the RFC Editor's "RFC Errata" web pages. I propose that you submit an Author's Errata Note, based on the material presented above, and/or choosing alternate text for (3).
Notes:
In any case, these items should be noted for future reference,
whenever once another revision of these RFCs is to be produced,
e.g., for advancement on the Standards Track.
[note: (1) contained general comments and has been removed.]
Author saving on file for possible revision.
from pending