[Date Prev][Date Next]
Re: [Kurt@OpenLDAP.org: Re: [email@example.com: bug/typo in RFC2256?]]
At 07:13 AM 2002-07-04, Fotis Georgatos wrote:
>At 03:54 AM 2002-07-04, Fotis Georgatos wrote:
>>This is only FYI.
>>I have the impression that some LDAP implementations can get confused
>>and "hide" data within the double-defined preferredDeliveryMethod attribute.
No implementor has reported a problem caused by the multiple
inclusion of same attribute in a MUST or MAY list, such as
those occurring in RFC 2256.
The multiple listing found in RFC 2256 likely resulted
during conversion from X.500 attribute sets to the
expanded list of attribute types.
Personally, I think the definitions should not be altered as
I believe that implementations should be (and are) ignoring
the redundant listing. I suggest a clarification be made in
[models] which states that if an attribute description is
provided multiple times in a list, it is treated as if it were
provided once. That is,
( 1.1.1 MUST ( CN $ CN ) )
is equivalent to:
( 1.1.1 MUST CN )
and represents an object class requiring the CN (commonName)
>>BTW. The same attribute is also double in objectclass "residentialPerson"
>>----- Forwarded message from Fotis Georgatos <firstname.lastname@example.org> -----
>>Date: Wed, 3 Jul 2002 17:41:57 +0200
>>From: Fotis Georgatos <email@example.com>
>>Subject: bug/typo in RFC2256?
>>Dear Mark et al,
>>while investigating the organizationalRole objectclass,
>>through the nice web interface at http://ldap.akbkhome.com,
>>I found, to my surprise, "preferredDeliveryMethod" being defined twice.
>>I traced it back and saw that it is defined in RFC2256, exactly as such.
>>It is even a SINGLE-VALUE field, which means that it has to be corrected.
>>Even the default OpenLDAP's schemas have it like this,
>>so I presume the rest of the LDAP world has now to fix this minor typo...
>>----- End forwarded message -----