[ldapext] Schema for posixGroup successor (RFC 2307 bis)

Michael Ströder <michael@stroeder.com> Wed, 11 February 2015 09:58 UTC

Return-Path: <michael@stroeder.com>
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 E539E1A87B1 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 01:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.388
X-Spam-Level:
X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 gYDUJxu3CXy5 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 01:58:48 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974551A87BE for <ldapext@ietf.org>; Wed, 11 Feb 2015 01:58:47 -0800 (PST)
Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id BBEED1D80F for <ldapext@ietf.org>; Wed, 11 Feb 2015 09:58:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id EEC831ECB5 for <ldapext@ietf.org>; Wed, 11 Feb 2015 09:58:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at stroeder.local
Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_ySlcF1B6um for <ldapext@ietf.org>; Wed, 11 Feb 2015 09:58:33 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id D64AA1CFAE for <ldapext@ietf.org>; Wed, 11 Feb 2015 09:58:32 +0000 (UTC)
Message-ID: <54DB27C7.3060409@stroeder.com>
Date: Wed, 11 Feb 2015 10:58:31 +0100
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32.1
MIME-Version: 1.0
To: ldapext <ldapext@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040005030701040104080507"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/9Us0BWJUbGRMugJlNWoYYqUzjJo>
Subject: [ldapext] Schema for posixGroup successor (RFC 2307 bis)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 09:58:50 -0000

HI!

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?

Ciao, Michael.