Errata

Verified (6)

RFC 4519 inline-errata

Source of RFC: ldapbis (app)

Errata-ID: 6974

Status:
Verified
Type:
Technical
Reported By:
Jesse Coretta
Date Reported:
2022-05-17
Verified by:
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
Reported By:
Ivan Panchenko
Date Reported:
2022-10-31
Verified by:
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
Reported By:
Ivan Panchenko
Date Reported:
2022-10-31
Verified by:
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
Reported By:
Ivan Panchenko
Date Reported:
2022-10-31
Verified by:
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
Reported By:
Ivan Panchenko
Date Reported:
2022-10-31
Verified by:
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
Reported By:
Ivan Panchenko
Date Reported:
2022-10-31
Verified by:
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.

Held for Document Update (1)

RFC 4519 inline-errata

Source of RFC: ldapbis (app)

Errata-ID: 70

Status:
Held for Document Update
Type:
Editorial
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.

Rejected (1)

RFC 4519 inline-errata

Source of RFC: ldapbis (app)

Errata-ID: 1761

Status:
Rejected
Type:
Technical
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 Erratum