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

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.

This is a very
low-level concept to LDAP, and thus convincing all application/server
developers to revolutionize seems a unlikely scenario.  And I would
argue that it would take a sea-change before it would be successful.
I.E. would this proposal be successful if only 50% or even 75% of
applications/servers support it?

Bob


-----Original Message-----
From: Luke Howard [mailto:lukeh@padl.com] Sent: Monday, September 17, 2007 4:03 PM
To: Andrew Findlay
Cc: ldapext@ietf.org
Subject: Re: [ldapext] groupOfEntries object class proposal

Another thing that would be useful might be to define the behaviour of nested groups, eg. should the client expand them?

It would make sense to use this object class for rfc2307bis too (whenever that is completed :-))

-- Luke

Andrew Findlay wrote:
At the recent LDAP conference in Cologne there was wide
support for an
effort to improve some of the commonly-used schema definitions. In
particular, the fact that groupOfNames does not permit an
empty group 
was felt to be a significant problem.

To address this problem, I have published an I-D proposing a new
objectclass called groupOfEntries. The I-D is appended and is also
available at:


http://www.ietf.org/internet-drafts/draft-findlay-ldap-groupof
entries-00.txt 
To make adoption as easy as possible, the new object class is
identical to groupOfNames except that it has the ability to
describe empty groups without resorting to tricks and workarounds.

I would like to see this new class used in place of groupOfNames in
new designs, so I propose to ask IETF to consider the draft for the
Standards Track.

Comments and suggestions for improvement are welcome, and should be
sent to the ldapext@ietf.org mailing list.

Andrew

--
www.padl.com | www.lukehoward.com


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext



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