RFC Errata
RFC 4521, "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", June 2006
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 69
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-22
Held for Document Update by: Peter Saint-Andre
(1) Section 2.5 (page 5) -- Ref. tags
The text,
vvvvvvvv
Numerous elements of LDAP are described using ASN.1 [X.680] and are
| encoded using a particular subset [Protocol, Section 5.2] of the
Basic Encoding Rules (BER) [X.690]. To allow reuse of
parsers/generators used in implementing the LDAP "core" technical
specification [RFC4510], it is RECOMMENDED that extension elements
(e.g., extension specific contents of controlValue, requestValue,
responseValue fields) described by ASN.1 and encoded using BER be
| subjected to the restrictions of [Protocol, Section 5.2].
^^^^^^^^
should say:
Numerous elements of LDAP are described using ASN.1 [X.680] and are
| encoded using a particular subset [RFC4511, Section 5.1] of the
Basic Encoding Rules (BER) [X.690]. To allow reuse of
parsers/generators used in implementing the LDAP "core" technical
specification [RFC4510], it is RECOMMENDED that extension elements
(e.g., extension specific contents of controlValue, requestValue,
responseValue fields) described by ASN.1 and encoded using BER be
| subjected to the restrictions of [RFC4511, Section 5.1].
[ Note: the tags *and* the section numbers need correction! ]
(2) Section 3.1 (page 6), 3rd and 4th paragraph -- Ref. tags
The text:
An existing operation MAY be extended to return IntermediateResponse
| messages [Protocol, Section 4.13].
^^^^^^^^ vvvvvvvv
Specifications of controls SHALL NOT attach additional semantics to
| the criticality of controls beyond those defined in [Protocol,
Section 4.1.11]. A specification MAY mandate the criticality take on
a particular value (e.g., TRUE or FALSE), where appropriate.
should say:
An existing operation MAY be extended to return IntermediateResponse
| messages [RFC4511, Section 4.13].
Specifications of controls SHALL NOT attach additional semantics to
| the criticality of controls beyond those defined in [RFC4511, Section
4.1.11]. A specification MAY mandate the criticality take on a
particular value (e.g., TRUE or FALSE), where appropriate.
(3) Section 3.1.2 (page 7), 3rd paragraph -- typo
The text:
It is RECOMMENDED that designers consider alternative mechanisms for
providing the function. For example, an extended operation issued
subsequent to the Start TLS operation (hence, protected by the
security layers negotiated by the Start TLS operation) might be used
| to provided the desired function.
^
should say:
It is RECOMMENDED that designers consider alternative mechanisms for
providing the function. For example, an extended operation issued
subsequent to the Start TLS operation (hence, protected by the
security layers negotiated by the Start TLS operation) might be used
| to provide the desired function.
(4) Section 3.1.4 (page 8), 2nd bullet -- typo
The text:
vvvv
| - consistency: The resulting DIT state must be conform to schema
and other constraints.
should say:
| - consistency: The resulting DIT state must conform to schema and
other constraints.
(5) Section 3.2 (page 8) -- Ref. tag
The text:
vvvvvvvv
| Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
mechanism for defining new operations. [...]
should say:
| Extended Operations [RFC4511, Section 4.12] are the RECOMMENDED
mechanism for defining new operations. [...]
(6) Section 3.4 (page 9), 1st paragraph -- Ref. tag
The text:
vvvvvvvv
| Unsolicited notifications [Protocol, Section 4.4] offer a capability
for the server to notify the client of events not associated with the
operation currently being processed.
should say:
| Unsolicited notifications [RFC4511, Section 4.4] offer a capability
for the server to notify the client of events not associated with the
operation currently being processed.
(7) Section 4 (page 9) -- Ref. tags
The text:
vvvvvvvv
| LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
| definition [Protocol, Appendix B] to be made.
^^^^^^^^
should say:
| LDAP allows limited extension [RFC4511, Section 4] of the LDAP ASN.1
| definition [RFC4511, Appendix B] to be made.
(8) Section 5 (page 10), 1st paragraph -- Ref. tag
The text:
Extensions defining LDAP schema elements SHALL provide schema
| definitions conforming with syntaxes defined in [Models, Section
4.1]. [...]
^^^^^^
should say:
Extensions defining LDAP schema elements SHALL provide schema
| definitions conforming with syntaxes defined in [RFC4512, Section
4.1]. [...]
(9) Section 9.1 (page 13) -- duplicate entry
The entry at the bottom of page 13,
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
should be deleted.
This entry is a duplicate, and it recurs on page 14, at the proper
place according to the collation order (by ascending RFC#).
Notes:
Most important issue:
Apparently, the update of the Reference tags within the text has
been performed incompletely after the assignment of RFC numbers
to those many LDAP I-Ds, leaving 'unsatisfied' tags in the text
(not listed in the References Sections), wherever these tags give
detailed citations, specifying a section or an Appendix there.
The errata detail items below are listed in textual order.
I use change bars and tag lines to emphasize the corrections
proposed and/or the issues in the original text.
Changed text is re-adjusted to conform to RFC formatting rules.
from pending