Re: [ldapext] groupOfEntries object class proposal

[Howard Chu <hyc@highlandsun.com>]

Ramsay, Ron wrote:
> 1) The ambiguity is a result of converting the concept to LDAP.

Granted, but the fact remains that it is unusable in LDAP.

> 2) I don't think you can use nameAndOptionalUID for naming, certainly
> not in the 93 standard. So your comments about children are not really
> appropriate. It's sole use may be in the groupOfUniqueNames object where
> the UID is acting as a generational qualifier. To fully support it,
> though, I think would require a UID attribute in the entry having that
> DN. Oh yes, access control is supposed to use it, too. But the qualifier
> applies to the DN itself and is making a statement about when THIS DN
> was relevant.

It would require the entry to have an x500UniqueIdentifier attribute, yes. So 
far the only standards track schema that uses it is inetOrgPerson.

But you're pointing out a distinction without a difference. If the 
generational qualifier is significant, then it is significant in every context 
where that DN is referenced. E.g.
	cn=bob,o=foo#1 exists
create  cn=my stuff,cn=bob,o=foo

references to "cn=my stuff,cn=bob,o=foo" (and all children of cn=bob,o=foo) 
now depend on that qualifier. If we remove cn=bob,o=foo and come back at a 
later time and create him again, with his child entry
	cn=bob,o=foo#10
	cn=my stuff,cn=bob,o=foo

then there is no way to uniquely reference the "cn=my stuff" child object or 
distinguish it from the previous generation. You cannot separate the relevance 
of "THIS DN" from the uniqueness of its children. If the parent is unique then 
necessarily all of its children are also, but using the nameAndOptionalUID 
syntax doesn't allow this uniqueness to be expressed. The core concept here is 
flawed (yes, in the original X.500 usage as well).

The correct way to handle this is by including the generational qualifier in 
the entry's RDN (making it multivalued), and then you can reference it 
consistently no matter where you need to use it. There is no legitimate use 
for the nameAndOptionalUID syntax at all, in LDAP or X.500.

It's sad, really. They go to the trouble of designing a nice data model with 
consistent naming, then they go and intentionally break it...

> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com] 
> Sent: Tuesday, 18 September 2007 9:59 AM
> To: Neal-Joslin, Robert (HP-UX Lab R&D)
> Cc: ldapext@ietf.org; Luke Howard; Andrew Findlay
> Subject: Re: [ldapext] groupOfEntries object class proposal
>
> Neal-Joslin, Robert (HP-UX Lab R&D) wrote:
> > Hi,
> >
> > I'm almost always in favor of new and better ways to do things.  And I
> > agree with the statements submitted.  But I can see a need to play
> > devil's advocate for this one.  Is there really enough justification
> to
> > warrant this proposal?  What is the likelihood of its success, given
> how
> > entrenched groupOfNames and groupOfUniqueNames is embedded in the
> > existing LDAP application/server security space? 
>
> Ah, you've just hit another hot-button - groupOfUniqueNames is utterly 
> pointless. I'm all for eradicating the old stuff and pushing
> groupOfEntries as 
> a standard.
>
> nameAndOptionalUID syntax is inherently broken, it cannot be parsed
> reliably. 
> e.g. - "cn=foo#101" could legitimately be a cn with value "foo#101",
> there's 
> no way to disambiguate it from "cn=foo" with UID "101".
>
> The entire concept behind this syntax is flawed. What do you do if you
> have a 
> "unique" named object with children? What if the children have unique
> names 
> too? There's only provision for one unique ID in the DN, but
> fundamentally 
> there should be the possibility of a unique ID for every RDN in the DN.
> I.e., 
> if this is really what you want, you should have been using multivalued
> RDNs 
> from the get-go.
>
> Probably 99% of LDAP applications never even use the UID portion of a 
> nameAndOptionalUID attribute, and the other 1% that use it are broken
> since 
> the syntax is inherently broken.
>
> I'll happily write up a standards track document to deprecate 
> groupOfUniqueNames and nameAndOptionalUID syntax.

--
  -- 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