Re: [ldapext] why posixAccount MUST contain 'cn'?

Mark R Bannister <dbis@proseconsulting.co.uk> Mon, 15 December 2014 22:04 UTC

Return-Path: <dbis@proseconsulting.co.uk>
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 3A3701A00CF for <ldapext@ietfa.amsl.com>; Mon, 15 Dec 2014 14:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 9daSjeRgbKgX for <ldapext@ietfa.amsl.com>; Mon, 15 Dec 2014 14:04:44 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96B1A008C for <ldapext@ietf.org>; Mon, 15 Dec 2014 14:04:44 -0800 (PST)
Received: from host31-49-172-136.range31-49.btcentralplus.com ([31.49.172.136] helo=[192.168.1.67]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1Y0dkv-00032d-3y; Mon, 15 Dec 2014 22:04:43 +0000
Message-ID: <548F5AE8.4050701@proseconsulting.co.uk>
Date: Mon, 15 Dec 2014 22:04:24 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Jim Willeke <jim@willeke.com>, =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>, kurt.zeilenga@isode.com
References: <548DB67C.5060009@stroeder.com> <548E2898.7020808@usit.uio.no> <CAB3ntOuAsgo9g-tckCe56_Q-X4jOie+HF2zDQj5ukJmTDBAcsQ@mail.gmail.com>
In-Reply-To: <CAB3ntOuAsgo9g-tckCe56_Q-X4jOie+HF2zDQj5ukJmTDBAcsQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030103040409010806070803"
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/c_oXDBlhXdVeHz2EPH4mpI0qHDU
Cc: ldapext <ldapext@ietf.org>
Subject: Re: [ldapext] why posixAccount MUST contain 'cn'?
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: Mon, 15 Dec 2014 22:04:48 -0000

On 15/12/2014 12:03, Jim Willeke wrote:
> And then there is also...
> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html
> ?
>
> --
> -jim
> Jim Willeke
>
> On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth 
> <h.b.furuseth@usit.uio.no <mailto:h.b.furuseth@usit.uio.no>> wrote:
>
>     On 14/12/14 17:10, Michael Ströder wrote:
>
>         (...)
>         Also what's the distinction of 'cn' and 'gecos' in
>         'posixAccount'. It seems
>         most NSS LDAP clients use attribute 'cn' as gecos field today.
>
>
>     cn is UTF-8.  The gecos attribute is IA5 String - i.e. ASCII.
>     One of many ways rfc2307 does not fit the real world too well.
>     memberUid is another IA5 too, both it and uid are case-insensitive
>     even though rfc2307 is for case-sensitive Unix, etc.
>
>
>     _______________________________________________
>     Ldapext mailing list
>     Ldapext@ietf.org <mailto:Ldapext@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ldapext
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

Indeed, as Jim pointed out, I have been working on a replacement for 
RFC2307 and RFC2307bis in my
spare time for over 18 months now.  I first released some new IETF 
drafts in August last year, and I've
just published the first working reference implementation this month.

Kurt - as LDAP registries expert would you help to shepherd these 
internet drafts through the IANA
publication process, as I'm not sure what my next step should be now?

In DBIS I have fixed the case insensitivity issues that were present in 
RFC2307, and I believe it is compliant
with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any 
attributes or object classes
that I needed to change.  I've introduced 'posixUserAccount' to replace 
'posixAccount' which does not
use 'cn', the gecos field can be set to point to any attribute you like, 
I've introduced 'posixGroupAccount'
to replace 'posixGroup', as well as a host of other improvements.

The drafts are:

draft-bannister-dbis-mapping 
<http://www.ietf.org/id/draft-bannister-dbis-mapping.txt> (DBIS Mapping 
Objects)
draft-bannister-dbis-netgroup 
<http://www.ietf.org/id/draft-bannister-dbis-netgroup.txt> (DBIS 
Netgroups and Netservices)
draft-bannister-dbis-passwd 
<http://www.ietf.org/id/draft-bannister-dbis-passwd.txt> (DBIS Users and 
Groups)
draft-bannister-dbis-hosts 
<http://www.ietf.org/id/draft-bannister-dbis-hosts.txt> (DBIS Hosts, 
Networks and Services)
draft-bannister-dbis-devices 
<http://www.ietf.org/id/draft-bannister-dbis-devices.txt> (DBIS Devices)
draft-bannister-dbis-automounter 
<http://www.ietf.org/id/draft-bannister-dbis-automounter.txt> (DBIS 
Automounter)
draft-bannister-dbis-custom 
<http://www.ietf.org/id/draft-bannister-dbis-custom.txt> (DBIS Custom Maps)

The intention is for these to obsolete RFC2307 and RFC2307bis.

Also of interest:

    * DBIS Reference Implementation on SourceForge <http://dbis.sf.net> 
(dbis.sf.net)
    * Three articles about DBIS from last year on my blog 
<http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html> 
(technicalprose.blogspot.co.uk)

The reference implementation works fine with Python 2.7 (tested on 
OpenSuSE 12.x), and I hope
to get it working on Python 2.6 this week or next (for RHEL 6 and 
Solaris 11 users).

Best regards,
Mark.