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