[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Summary of group discussion
Howard Chu wrote:
> The other alternative is to fix the LDAP definition of the
> NameAndOptionalUID syntax, so that it's actually usable in LDAP.
>
> Given the bass-ackward RDN ordering that was chosen for the string
> representation of DNs in LDAP, the only unambiguous thing to do with
> these is to put the x500uniqueIdentifier *first* in the string. So
> revise RFC4517's definition 3.3.21
>
> NameAndOptionalUID = [BitString] distinguishedName
>
> The SHARP character in the current definition is extraneous since the
> BitString definition is already fully delimited.
>
> If we fix this syntax then I would drop all objections relating to its use.
1. I don't any deployment which uses the optional BitString part. The
deployments I know just use the distinguishedName.
2. The implementations I know which might make use of the optional UID part
did not use a BitString there. They messed it up with attribute 'uid' (which
is of DirectoryString).
3. Changing declaration in RFC 4517 would potentially break things.
=> My suggestion would be to add an applicability note to section 3.3.21 which
states that either distinguishedName MUST NOT contain SHARP. Or maybe it would
be possible to mandate that SHARP MUST be escaped like described in RFC 4514.
Ciao, Michael.
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext