RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 4529, "Requesting Attributes by Object Class in the Lightweight Directory Access Protocol", June 2006

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

Errata ID: 7199
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says: 

   object class identifier from an attribute descriptions.

It should say:

   object class identifier from an attribute description.

Notes:

Erroneous "descriptions".

Status: Held for Document Update (2)

RFC 4529, "Requesting Attributes by Object Class in the Lightweight Directory Access Protocol", June 2006

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

Errata ID: 66
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov

Section 1 says: 

   The control may be attached to any update operation to support
   conditional addition, deletion, modification, and renaming of the
   target object.  The asserted condition is evaluated as an integral
   part the operation.

It should say:

   The control may be attached to any update operation to support
   conditional addition, deletion, modification, and renaming of the
   target object.  The asserted condition is evaluated as an integral
|  part of the operation.
       ^^^^

Notes:

from pending

Errata ID: 853
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02

Section 3 says: 

   When the control is attached to an LDAP request, the processing of
   the request is conditional on the evaluation of the Filter as applied
   against the target of the operation.  If the Filter evaluates to
   TRUE, then the request is processed normally.  If the Filter
   evaluates to FALSE or Undefined, then assertionFailed (122)
   resultCode is returned, and no further processing is performed.

It should say:

   When the control is attached to an LDAP request, the processing of
   the request is conditional on the evaluation of the Filter as applied
   against the target of the operation.  If the Filter evaluates to
   TRUE, then the request is processed normally.  If the Filter
|  evaluates to FALSE or Undefined, then the assertionFailed (122)
   resultCode is returned, and no further processing is performed.

Notes:

Missing an article.

Report New Errata



Advanced Search