Re: NOT RFC1777 compliant

Tim Howes (tim@umich.edu)
Wed, 13 Dec 1995 21:29:01 -0500

> From: Michael Gsandtner <gsa@adv.magwien.gv.at>
> To: ldap@umich.edu (LDAP )

> We just switched from UMICHs ldapd to DIGITALs Infobroker ldap server.
> It had the effect, that our web500gw returned some strange results. The reason
> Most of the ldap servers around are not strictly RFC1777 compliant
> (including ours, UMICHs implementation using the schema files of free QUIPU).
> The AttributeTypes returned should be (from RFC1777):
>
> 'An AttributeType value takes on as its value the textual string
> associated with that AttributeType in the X.500 Directory standards.
> For example, the AttributeType 'organizationName' with object
> identifier 2.5.4.10 is represented as an AttributeType in this
> protocol by the string "organizationName".'
>
> But the "QUIPU ldap servers" return "o" (similar sn, cn, ...).
> DIGITALs Infobroker returns the correct RFC1777 string "organizationName".
> web500gw expects the uncompliant short names ("sn"), thus works correct
> with QUIPU schema, and strange with RFC1777 Infobroker.
>
> I modified web500gw to expect both short and long names ("sn" and "surname").
> But I would prefer, that I can use both names in search filters, and in result
> only the "X.500 Directory standards" formal name.

Hmm...RFC 1777 seems ambiguous at best here to me, since X.500
"associates" as many as two textual strings with most attribute types
(a short one such as "o" is used many places, the longer
"organizationName" is used others). The example in that paragraph would
lead one to believe the interpretation you suggest, but it is just an
example, and I think a case could be made the other way. Anyway, looks
like it needs clarifying.

I will add this as the second item on the list of things to check and
fix in LDAP before it progresses. Thanks! -- Tim