[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: more schema-08 notes



At 09:53 PM 3/28/2005, Andrew Sciberras wrote:
>Hi Hallvard,
>
>>Section 2.34, street, could use an example with ", " between components,
>>to distinguish it from attrs with Postal Address syntax.  I've seen
>>these syntaxes being confused in both directions.
>
>Not a problem.
>
>>Section 2.39, uid, needs to mention that the X.500 name is userid.
>
>At the moment this is mentioned in the Acknowledgments. I will make it explicit in section 2.39.
>
>>Also I suggest to clarify the distinction between LDAP vs. X.500 names.
>>E.g.
>>
>>>2.34  street
>>>
>>> The street (streetAddress) attribute type (...)
>>> ( 2.5.4.9 NAME 'street'
>>> (...)
>>
>>What does that mean - is 'streetAddress' a name for 2.5.4.9 or not?
>>I expect it's too much of a change now to change it to
>>    ( 2.5.4.9 NAME ('street' 'streetAddress')
>>so I suggest:
>>    The street (streetAddress in X.500) attribute type (...)
>>and then note in Section 2 that implementations MAY recognize the
>>X.500 names as alternate names for these attributes.

It's already said elsewhere that servers can recognize attribute
types by additional names.  However, I do not think we should
provide additional names, as that will just lead to their
use, use that will lead to interoperability problems.



>I think that the former suggestion could be the most appropriate.
>Since 'streetAddress' is already registered with IANA as a name of the 2.5.4.9 attribute,

Well, its registered to keep it from be used for some other
attribute type, which would be problematic.  However, 'street'
should be used in LDAP as this is the only name which
implementations which support this attribute are required to
recognized.

>it would only make sense to include it within the definition.

Please do not add the X.500 attribute type name to the NAME
parameter.   Just s/streetAddress/streetAdddress in X.500/,
please.

>This will also result in me updating the IANA Considerations section to include all of the 'alternate' names.

That's fine.

>>Editorial nitpick for Section 2.39:
>>
>>> ( 0.9.2342.19200300.100.1.1
>>>    NAME 'uid'
>>all other NAMEs are on same line as the OID, including 'dc' which also
>>has a long OID.
>
>Thanks.
>
>>And as briefly noted previously: In the table in 1.4, the source for
>>section 2.41 (userPassword) is X.509, not X.520.
>
>No problems.
>
>
>Andrew Sciberras.
>