Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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