RFC Errata
Found 9 records.
Status: Verified (6)
RFC 4512, "Lightweight Directory Access Protocol (LDAP): Directory Information Models", June 2006
Source of RFC: ldapbis (app)
Errata ID: 5261
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Giddy
Date Reported: 2018-02-12
Verifier Name: Orie Steele
Date Verified: 2024-03-29
Section 6.1 says:
And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned.
It should say:
And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.2) is returned.
Notes:
The concept of equivalent values is defined in Section 2.2 of RFC 4512. Section 2.3 does not mention equivalent values.
Errata ID: 7224
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 2.3.3 says:
An alias, or alias name, is "an name for an object, provided by the
It should say:
An alias, or alias name, is a "name for an object, provided by the
Notes:
Wrong form of the indefinite article (the cited source has "an alternative name").
Errata ID: 7225
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 5.1.3/5.1.4/5.1.5 says:
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
It should say:
Procedures for registering object identifiers used for discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
Notes:
Either "used for discovery of protocol mechanisms" or "used to discover protocol mechanisms" would be correct.
Errata ID: 7226
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.1.4 says:
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 where incorporated into this document.
It should say:
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 were incorporated into this document.
Notes:
Misspelling.
Errata ID: 7227
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.2 says:
Definitions of operational attributes provided in Section 5 of RFC 2252 where incorporated into this document.
It should say:
Definitions of operational attributes provided in Section 5 of RFC 2252 were incorporated into this document.
Notes:
Misspelling.
Errata ID: 7228
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:
'extensibleObject' object classes. These definitions where integrated into Section 4.2 and Section 4.3 of this document,
It should say:
'extensibleObject' object classes. These definitions were integrated into Section 4.2 and Section 4.3 of this document,
Notes:
Misspelling.
Status: Reported (1)
RFC 4512, "Lightweight Directory Access Protocol (LDAP): Directory Information Models", June 2006
Source of RFC: ldapbis (app)
Errata ID: 7896
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesse Coretta
Date Reported: 2024-04-17
Section 4.1.7.1 says:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
It should say:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" SP ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
Notes:
The SP token between "SUP" and "ruleids" is missing. The SP token is not optional, unlike WSP.
Status: Held for Document Update (2)
RFC 4512, "Lightweight Directory Access Protocol (LDAP): Directory Information Models", June 2006
Source of RFC: ldapbis (app)
Errata ID: 74
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
(E1) text truncation (?)
Apparently, the text of the first paragraph of Section 3.2,
on page 18 of RFC 4512, has been truncated inadvertently.
The RFC text says:
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
| [X.501]. Subentries are used in Directory to hold for administrative
| and operational purposes as defined in [X.501]. Their use in LDAP is
detailed in [RFC3672].
I suspect that it should in fact say:
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
| [X.501]. Subentries are used in the Directory to hold attributes for
| administrative and operational purposes as defined in [X.501]. Their
use in LDAP is detailed in [RFC3672].
(E2) typo
In Section 4.1.7.1, near the bottom of page 30, the explanation,
FORM is specifies the name form associated with this DIT structure
rule;
should say:
| FORM specifies the name form associated with this DIT structure
rule;
(E3) typo
The first paragraph of Section 5.1, on page 36, says:
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
| the DN with zero RDNs (whose [RFC4514] representation is as the
zero-length string).
It should say:
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
| the DN with zero RDNs (whose [RFC4514] representation is the zero-
length string).
(E4) word omission
The second paragraph of Section A.2.1, on page 49, says:
The <descr> syntax was changed to disallow semicolon (U+003B)
characters in order to appear to be consistent its natural language
specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a
letter". In a related change, the statement "an AttributeDescription
can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no
specification of the semantics of attribute options appearing in NAME
fields.
It should say:
The <descr> syntax was changed to disallow semicolon (U+003B)
| characters in order to appear to be consistent with its natural
language specification "descr is the syntactic representation of an
object descriptor, which consists of letters and digits, starting
with a letter".
In a related change, the statement "an AttributeDescription can be
used as the value in a NAME part of an AttributeTypeDescription" was
deleted. RFC 2252 provided no specification of the semantics of
attribute options appearing in NAME fields.
And these are my side notes for future consideration.
There are a couple of missing articles in the RFC text.
I have noted the following places:
(N1)
In Section 4.1.1, on page 24, the explanation,
where:
<numericoid> is object identifier assigned to this object class;
[...]
should better say:
where:
| <numericoid> is the object identifier assigned to this object
class;
[...]
(N2)
In Section 4.1.2,
a) on page 25, the literally same correction as (N1) applies, and
b) the explanation:
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
should better say:
| SYNTAX identifies the value syntax by its object identifier and may
suggest a minimum upper bound;
c) Finally, on top of page 26, the paragraph,
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype.
should better say:
| If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype.
(N3)
In Section 4.1.3, on page 27, -- similarly to (N1) --
the explanation,
where:
<numericoid> is object identifier assigned to this matching rule;
[...]
should better say:
where:
<numericoid> is the object identifier assigned to this matching
rule;
[...]
(N4)
In Section 4.1.7.2, on page 31, -- again like in (N1) --
the explanation,
where:
<numericoid> is object identifier that identifies this name form;
[...]
should better say:
where:
<numericoid> is the object identifier that identifies this name
form;
[...]
(N5)
The final sentence of Section 4.2, i.e. the 3rd paragraph on page 33,
says:
The following subsections provide attribute type definitions for each
of schema definition attribute types.
It should say:
The following subsections provide attribute type definitions for each
| of the schema definition attribute types.
Notes:
Source: apps
Errata ID: 2281
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-05-21
Section A.3 says:
The second paragraph of Section A.3, at the bottom of page 50, says: Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
It should say:
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' | attribute type. This was integrated into Section 3.3 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
Notes:
Apparently, 'Section 3.3' would have been much more appropriate than
'Section 2.4.1'.
Source: apps