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

RE: [ldapext] groupOfEntries object class proposal

1) The ambiguity is a result of converting the concept to 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.

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

> 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


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