[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt
I would rather not see these aliases added to the user schema draft.
I've seen LDAP servers that recognize commonName as an alias of cn, and was
tempted to say that we ought to list this as optional aliases. But I've
also seen the headaches that result when applications mix cn and commonName
(or other aliases), particularly when one application is either unaware of
the alias, or unaware of aliases in general.
I don't recall seeing a standard that says commonName is an alias for cn,
just that cn is the LDAP equivalent to X.500 commonName.
John McMeeking
"Kurt D. Zeilenga"
<Kurt@OpenLDAP.org> To: Michael Ströder <michael@stroeder.com>
Sent by: cc: Norbert Klasen <norbert+lists.ietf-ldapbis@burgundy.dyndns.org>,
owner-ietf-ldapbis@O ietf-ldapbis@OpenLDAP.org
penLDAP.org Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt
05/19/2003 02:56 PM
At 12:45 PM 5/19/2003, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>At 11:39 AM 5/19/2003, Norbert Klasen wrote:
>>
>>>the schema in many LDAP servers contains an alternate name for those
>>>attributes, whose name is an abbreviation from the name of the
>>>respective X.500 attribute type, e.g. 'cn' and 'commonName' or 'st' and
>>>'stateOrProvinceName'. Should this be reflected in the user-schema
>>>document?
>>Personally, I think they should not be listed as that would
>>require implementations to recognize additional names.
>
>Why would that "require" to recognize additional names?
Because its expected that all implementations recognize the
attribute types and other elements by the names listed.
>Maybe one could come up with a wording listing the mandantory attribute
type names and the optional aliases?
Maybe, but why? Adding additional names only leads to interoperability
problems. It is far better to have one and only name per schema element.
>> Multiple
>>names leads to interoperability problems as it is inevitable
>>that some implementations will not recognize all of them.
>
>But there are already multiple names out there in the wild.
There are also many implementations which don't recognize the
various names one might find in use in the wild.
>And sure there are already interoperability problems with that.
Well, there are always problems when implementations using names
other than those which the standard track specifications say to
use. This problem cannot be solved by adding more names. Instead
we should clarify the specifications that use of other names will
lead to interoperability.
>My point is that listing the aliases would make implementors aware of it.
Implementors shouldn't have to be aware of non-standard names.
>>Certainly LDAP implementations are allowed to recognize
>>additional names... but they should not assume others do.
>
>IMHO either we'd be able to disallow use of aliases or we have to make
implementors aware of them.
I think it unwise to disallow implementations from being
"liberal in what they accept". However, implementations
should be "strict in what they produce".
Kurt