RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (6)

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

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

Reported By: Jesse Coretta
Date Reported: 2022-05-17
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 3.13 says:

3.13.  'residentialPerson'

   The 'residentialPerson' object class is the basis of an entry that
   includes a person's residence in the representation of the person.
   (Source: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st $ l ) )

It should say:

3.13.  'residentialPerson'

   The 'residentialPerson' object class is the basis of an entry that
   includes a person's residence in the representation of the person.
   (Source: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st ) )

Notes:

The "l" attributeType (a.k.a "localityName", as defined in section 2.16 of this same document) is defined in this class in ambiguous fashion. "l" is declared as both required (MUST) and permitted (MAY). It should be removed from the MAY clause.

It is also worth pointing out this flaw is limited solely to this RFC, as the original residentialPerson definition defined within the ITU-T X.521 document (section 6.10) is indeed correct. The "localityName" attribute type is not listed in ambiguous fashion.

Errata ID: 7208
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.3 says:

   The 'dcObject' object class permits an entry to contains domain

It should say:

   The 'dcObject' object class permits an entry to contain domain

Notes:

Wrong verb form.

Errata ID: 7209
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.14 says:

   The 'uidObject' object class permits an entry to contains user

It should say:

   The 'uidObject' object class permits an entry to contain user

Notes:

Wrong verb form.

Errata ID: 7210
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 2.21 says:

            mailing list object, would be the DN of the director (role):

It should say:

            mailing list object would be the DN of the director (role):

Notes:

Unnecessary comma.

Errata ID: 7211
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 2.19 says:

   Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".

It should say:

   Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated".

Notes:

The name "Widget, Incorporated" should be written without a period.

Errata ID: 7212
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 2.5 says:

             1pm.", and "distribution list for all technical staff".

It should say:

             1 p.m.", and "distribution list for all technical staff".

Notes:

Missing space and period.

Status: Held for Document Update (1)

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

Errata ID: 70
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

Appendix A says:

      18. Removed Section 2.4 (Source).  Replaced the source table with
          explicit references for each definition.

It should say:

      18. Removed Section 4 (Source).  Replaced the source table with
          explicit references for each definition.

Status: Rejected (1)

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

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

Reported By: Fotis Georgatos
Date Reported: 2009-04-10
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02

Section 3.10 says:

3.10.  'organizationalRole'

   The 'organizationalRole' object class is the basis of an entry that
   represents a job, function, or position in an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

It should say:

3.10.  'organizationalRole'

   The 'organizationalRole' object class is the basis of an entry that
   represents a job, function, or position in an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ 
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

Notes:

Any object classes that include the preferredDeliveryMethod twice should be either redefined, by including it only once, OR provide an explicit reference about how it should be interpreted by the implementations; such examples are:
organizationalRole (3.10)
residentialPerson (3.13)

Note that this error has been affecting OpenLDAP implementations at least
since year 2002; with the side-effect that imported ldif data would disappear:
http://www.openldap.org/lists/ietf-ldapbis/200207/msg00002.html
It is surprising that it has remained unaddressed during so many years.

Also, Kurt Zeilinga has proposed to adopt the following (sufficient) rule:
"that implementations SHOULD be (and are) ignoring the redundant listing".
--VERIFIER NOTES--
Kurt Zeilenga said:

This issue was raised to the LDAPbis WG at the time it was working on the I-D which became RFC 4519 yet RFC 4519 did not include the suggested change. Simply put, there was insufficient support of the suggested change at that time.

The change is also bad in that in removes one of the examples of multiple listed attributes, a rarely used but still valid (for historical reasons) of X.500/LDAP schema descriptions, and hence may lead to implementations not supporting this feature and by doing so causing interop problems.

Report New Errata



Advanced Search