Re: [Kurt@OpenLDAP.org: Re: [fotis@xos.nl: bug/typo inRFC2256?]]

[Kathy Dally <kdally@mitre.org>]

Hi All!

The multiple presence of the preferredDeliveryMethod attribute comes
from X.521.  I think Kurt's proposal is definitely a good idea.

Thanks,
Kathy Dally


"Kurt D. Zeilenga" wrote:
> 
> 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)
> attribute.
> 
> Kurt
> 
> >>BTW. The same attribute is also double in objectclass "residentialPerson"
> >>
> >>cheers,
> >>Fotis
> >>
> >>----- Forwarded message from Fotis Georgatos <fotis@xos.nl> -----
> >>
> >>Date: Wed, 3 Jul 2002 17:41:57 +0200
> >>From: Fotis Georgatos <fotis@xos.nl>
> >>To: M.Wahl@critical-angle.com
> >>Cc: openldap-its@OpenLDAP.org
> >>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...
> >>
> >>cheers,
> >>Fotis
> >>
> >>----- End forwarded message -----