Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)
Simo Sorce <idra@samba.org> Wed, 11 February 2015 11:29 UTC
Return-Path: <idra@samba.org>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988291A1B80 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNKlopFuqDP8 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:29:32 -0800 (PST)
Received: from mail.samba.org (fn.samba.org [IPv6:2001:470:1f05:1a07::1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E888D1A1B4A for <ldapext@ietf.org>; Wed, 11 Feb 2015 03:29:31 -0800 (PST)
Received: from mail.samba.org (localhost [127.0.0.1]) by mail.samba.org (Postfix) with ESMTP id 7E291AC0BB; Wed, 11 Feb 2015 04:29:31 -0700 (MST)
Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.samba.org (Postfix) with ESMTP id 2FA2FAC0B7; Wed, 11 Feb 2015 04:29:31 -0700 (MST)
Message-ID: <1423654170.11010.63.camel@samba.org>
From: Simo Sorce <idra@samba.org>
To: Michael Ströder <michael@stroeder.com>
Date: Wed, 11 Feb 2015 06:29:30 -0500
In-Reply-To: <54DB3BF8.7000909@stroeder.com>
References: <54DB27C7.3060409@stroeder.com> <1423653002.11010.62.camel@ssimo.org> <54DB3BF8.7000909@stroeder.com>
Organization: Samba Team
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.9 (3.12.9-1.fc21)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/pifbNzwVWYQ5s9X2Z-pU-hKj6_w>
Cc: ldapext <ldapext@ietf.org>
Subject: Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: simo@samba.org
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 11:29:33 -0000
On Wed, 2015-02-11 at 12:24 +0100, Michael Ströder wrote: > Simo wrote: > > On Wed, 2015-02-11 at 10:58 +0100, Michael Ströder wrote: > >> Since Kurt expressed to follow very strict guide lines forbidding altering > >> existing NAMEs and OIDs of schema descriptions especially in RFC 2307 the > >> question is how to define a new object class for POSIX groups in RFC 2307bis > >> > >> To preserve backwards compability I'd like to propose the following: > >> > >> ( <OID TBD> > >> NAME 'posixGroup2' > >> DESC '<TBD>' > >> SUP ( groupOfEntries $ posixGroup ) > >> STRUCTURAL ) > >> > >> With this definition.. > >> > >> 1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes, > >> > >> 2. the object class still can be found with (objectClass=posixGroup) and > >> > >> 3. the object class is STRUCTURAL and therefore one can assign a specific DIT > >> content rule to it allowing to preclude either 'member' or 'memberUID' with > >> NOT to meet local system requirements. > >> > >> 4. there's no conflict on LDAP servers with the old RFC 2307 schema already added. > >> > >> What do others think about this approach? > > > > I'd call it posixGroupBis, but otherwise sounds like a good idea. > > I have no strong opinion on the NAME. > > > Does it have to be structural though ? > > I expected this question. ;-) > > Yes, it has to be STRUCTURAL and I already gave one rational with 3. Note > that DIT content rules, which are very helpful for defining local profiles of > standard object classes, can only be assigned to STRUCTURAL object classes. > Also DIT structure rules and name forms only work with this kind of object > class. And yes, I'm using all these schema elements. ;-) > > > If it were an auxiliary I might be able to add it to a groupOfEntries > > object to turn it into a posix group at a later time, that would be > > nice. > > Yes, I know. But please take note of Kurt's recent statements about IANA > considerations for NAME 'posixGroup' etc. > => when using NAME posixGroup anywhere the object class must be STRUCTURAL Understood, all makes sense. Simo.
- [ldapext] Schema for posixGroup successor (RFC 23… Michael Ströder
- Re: [ldapext] Schema for posixGroup successor (RF… Michael Ströder
- Re: [ldapext] Schema for posixGroup successor (RF… Simo Sorce
- Re: [ldapext] Schema for posixGroup successor (RF… Andrew Findlay
- Re: [ldapext] Schema for posixGroup successor (RF… Michael Ströder
- Re: [ldapext] Schema for posixGroup successor (RF… Andrew Findlay
- Re: [ldapext] Schema for posixGroup successor (RF… Michael Ströder
- Re: [ldapext] Schema for posixGroup successor (RF… Ludovic Poitou
- Re: [ldapext] Schema for posixGroup successor (RF… Michael Ströder
- Re: [ldapext] Schema for posixGroup successor (RF… Ludovic Poitou
- Re: [ldapext] Schema for posixGroup successor (RF… Andrew Findlay