[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] NameAndOptionalUID, uniqueMember, RFC4517, RFC4519
- To: Ldapext <ldapext@ietf.org>
- Subject: [ldapext] NameAndOptionalUID, uniqueMember, RFC4517, RFC4519
- From: Howard Chu <hyc@highlandsun.com>
- Date: Thu, 08 Feb 2007 17:32:12 -0800
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a
Probably a little late for this... It seems to me that the description
of this syntax and attribute are deficient because they make no direct
reference to the x500UniqueIdentifier attribute, which is an inherent
component of this type. I.e., the syntax definition offers no
description of where the unique identifier came from, it's described as
if it is just an arbitrary bitstring that came out of the blue. But in
fact it is specifically the content of the x500UniqueIdentifier
attribute of the named entry.
Likewise, the example for uniqueMember in RFC4519 is deficient. It says
"a new battalion with the "same" name would have a unique identifier
value added" but this fails to note that the identifier must live
somewhere, not just in the uniqueMember attribute itself. That is, it
should explicitly say that an x500UniqueIdentifier is added to the
target entry, and its value gets used in the uniqueMember attribute
value. Overall the example leaves a lot to be desired; an object named
by an "ou" attribute is most likely an organizationalUnit, but
x500UniqueIdentifier is not a valid attribute of that object class. In
fact the only object class in any published RFC that uses
x500UniqueIdentifier is inetOrgPerson, in RFC2798.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext