[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] groupOfEntries object class proposal
This approach gets my vote. Is it practical?
-----Original Message-----
From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
Sent: Monday, September 17, 2007 10:45 PM
To: Andrew Findlay
Cc: ldapext@ietf.org
Subject: RE: [ldapext] groupOfEntries object class proposal
Why not try to get the appropriate RFC revised to make 'member'
optional?
Even simply making 'member' optional in your own implementations, though
inviting interoperability problems, would seem to have fewer issues than
introducing a new object class. In fact, I think it is common to find
that 'member' is optional inthe field.
-----Original Message-----
From: Neal-Joslin, Robert (HP-UX Lab R&D) [mailto:bob.joslin@hp.com]
Sent: Tuesday, 18 September 2007 9:22 AM
To: Luke Howard; Andrew Findlay
Cc: ldapext@ietf.org
Subject: RE: [ldapext] groupOfEntries object class proposal
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? 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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext