RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Report New Errata



Advanced Search