RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4009
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Giovanni Cannata
Date Reported: 2014-06-09
Verifier Name: Barry Leiba
Date Verified: 2014-06-11

Section LDIF Syntax says:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

It should say:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP [8]
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

Note 8: If deleteoldrdn is "0" the old rdn will be kept; if it is "1"
the old rdn will be deleted.

Notes:

There is no formal specification of the meaning of the "deleteoldrdn" value 0 or 1. 1 stands for deletion, 0 stands for keeping the old rdn. Add a note to explain the value meaning.

-----
Verifier note:
It is correct that the meaning of "deleteoldrdn" is never explained in the document. The proposed resolution is a reasonable fix for that, and such an explanation is needed.

Errata ID: 4377
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Keita Kondou
Date Reported: 2015-05-28
Verifier Name: Barry Leiba
Date Verified: 2015-05-28

Section LDIF Syntax says:

ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

It should say:

ldap-oid                 = 1*DIGIT 0*("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

Notes:

ldap-oid syntax on RFC2849 allow only ONE dot.
But it should allow decimal string separated by multi dots.

RFC2251 LDAPOID definition:
The LDAPOID is a notational convenience to indicate that the
permitted value of this string is a (UTF-8 encoded) dotted-decimal
representation of an OBJECT IDENTIFIER.

LDAPOID ::= OCTET STRING

For example,

1.3.6.1.4.1.1466.1.2.3

Status: Held for Document Update (2)

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2258
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Flavio Poletti
Date Reported: 2010-05-13
Held for Document Update by: Peter Saint-Andre

Throughout the document, when it says:

Example 3: A file containing a base-64-encoded value

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
b3V0IG1vcmUu

It should say:

Example 3: A file containing a base-64-encoded value

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
 b3V0IG1vcmUu

Notes:

There is no section numbering in this RFC, hence the "GLOBAL".

Note 10 in "Notes on LDIF Syntax" says that base64-encoded values are subject to the same folding rules explained in Note 2. Note 2 requires folded lines to begin with a space character.

This modification was introduced passing from draft-good-ldap-ldif to RFC 2849.

Errata ID: 3646
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Boris Kleint
Date Reported: 2013-06-11
Held for Document Update by: Barry Leiba
Date Held: 2013-08-21

Section Note 4 says:

Any dn or rdn that contains characters other than those
defined as "SAFE-UTF8-CHAR", or begins with a character other
than those defined as "SAFE-INIT-UTF8-CHAR",

It should say:

Any dn or rdn that contains characters other than those
defined as "SAFE-CHAR", or begins with a character other
than those defined as "SAFE-INIT-CHAR",

Notes:

This appears in note 4 of "Notes on LDIF Syntax".

---- Verifier notes ----
Note 4 has double text, one of which allows more than the other. But the ABNF
doesn't have that ambiguity. This is really something that can only be fixed by
revising the spec. It's simply not clear what the intent was.

Status: Rejected (1)

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4355
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Andrey Repin
Date Reported: 2015-05-05
Rejected by: Barry Leiba
Date Rejected: 2015-05-05

Throughout the document, when it says:

In the section "Formal Syntax Definition of LDIF", Notes 2 and 8 
indirectly imply, that folded lines may contain leading whitespaces(1) 
and not allowed trailing whitespaces(2).
Or, in other words, a fold must occur before a whitespace, or entire 
value must be base64-encoded before folding.
However, the understanding is implied, rather than clearly stated.

It should say:

I suggest to clarify the folding rules to include a reference to 
trailing whitespaces in this specific case.
Something as simple as "in case of folding a line containing 
whitespaces, the fold MUST NOT occur after a whitespace character" will 
go a long way towards clearing the confusion.
Or, in ABNF syntax,
folding-sequence = (SAFE-INIT-CHAR / ":" / "<") FILL SEP SPACE SAFE-CHAR
(That is, symbols ":" and "<" may safely appear at the end of a value 
string, given it is not the first character of attribute value...)

Notes:

The implication is drawn from the
(1): Note 2, "When joining folded lines, exactly one space character at the beginning of each continued line must be discarded." (Emphasis on "exactly one".)
(2): Note 8, "Values … that end with SPACE SHOULD be base-64 encoded.", implied premise of the format that each single line read from the file must be "basically correct", means, follow generic rule of (<empty line> / <comment> / <name:value pair> / <continuation line>) and the generic experience that trailing whitespaces are not apparently visible in text files without the use of special tools.
--VERIFIER NOTES--

Except that it's an incorrect implication. The space at the beginning of the continued line is discarded simply because it's the space that was added to fold the line, so it has to be removed when you unfold. There is no restriction on where the folding is done other than what Note 2 says (MUST NOT fold before the first character of the line, and SHOULD NOT fold in the middle of a multi-byte UTF-8 character).

In particular, a line can be folded in the middle of a FILL sequence, in the middle of a sequence of SPACE characters in a string, or in the middle of a sequence of SPACE characters in a comment line. It is perfectly valid to have SPACE characters both before and after the <SEP SPACE> sequence that folding adds.

Report New Errata



Advanced Search