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

Kurt Zeilenga <kurt.zeilenga@isode.com> Tue, 16 December 2014 18:10 UTC

Return-Path: <kurt.zeilenga@isode.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 BF0341A86DF for <ldapext@ietfa.amsl.com>; Tue, 16 Dec 2014 10:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Level:
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 sgodEMeR8PJt for <ldapext@ietfa.amsl.com>; Tue, 16 Dec 2014 10:10:20 -0800 (PST)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBF11A7028 for <ldapext@ietf.org>; Tue, 16 Dec 2014 10:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418753414; d=isode.com; s=selector; i=@isode.com; bh=gt4dr4/9QzjHZc9JNIfaNvEut62Bra4J7oIrasJkaCQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gr1fRw5ICbL1AK8pHvJUjCNgPil9CGSHvOUV7y4wzmyC1BvR134RIv9HBq9T8EbtlheyCG XnUS0Ya5q8eYdF4n6N9fbHuexpWhhOmknrq11wl2FoImgo6SBCo1RT+tqureYsdx3sKosz 9nBACSEpm72yJqDhQ/AUINB+2pgshrM=;
Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VJB1ewAKaMS8@waldorf.isode.com>; Tue, 16 Dec 2014 18:10:13 +0000
X-SMTP-Protocol-Errors: NORDNS PIPELINING
From: Kurt Zeilenga <kurt.zeilenga@isode.com>
In-Reply-To: <548F5AE8.4050701@proseconsulting.co.uk>
Date: Tue, 16 Dec 2014 10:09:53 -0800
Message-Id: <7001CBE1-8A2C-47CF-81A2-58F0CA403CA0@isode.com>
References: <548DB67C.5060009@stroeder.com> <548E2898.7020808@usit.uio.no> <CAB3ntOuAsgo9g-tckCe56_Q-X4jOie+HF2zDQj5ukJmTDBAcsQ@mail.gmail.com> <548F5AE8.4050701@proseconsulting.co.uk>
To: Mark R Bannister <dbis@proseconsulting.co.uk>
X-Mailer: Apple Mail (2.1993)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="Apple-Mail=_E965BF33-CCE5-4E2F-A46F-CC2B22626A0E"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/UxdXuKLZhavljQRIiFeNi8SoUP4
Cc: ldapext <ldapext@ietf.org>, Kurt Zeilenga <kurt.zeilenga@isode.com>, Michael Ströder <michael@stroeder.com>, Jim Willeke <jim@willeke.com>
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: Tue, 16 Dec 2014 18:10:24 -0000

> On Dec 15, 2014, at 2:04 PM, Mark R Bannister <dbis@proseconsulting.co.uk> wrote:
> 
> On 15/12/2014 12:03, Jim Willeke wrote:
>> And then there is also...
>> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html <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 <https://www.ietf.org/mailman/listinfo/ldapext>
>> 
>> 
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org <mailto:Ldapext@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ldapext <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?

Mark,

As far as next steps, depends on whether you intend to pursue publication through the IETF or through the Independent Submission Editor (ISE).  The former is appropriate for all standard track document or any non-standard track document for which you want to publish community consensus.  If however you want to publish your own personal views, then ISE is more appropriate.

If the latter, the next step would be to submit the I-Ds to the ISE. The process is roughly outlined at <https://www.rfc-editor.org/indsubs.html <https://www.rfc-editor.org/indsubs.html>>.

If the former, the next step would be to contact an App Area AD <app-ads@tools.ietf.org <mailto:apps-ad@tools.ietf.org>> and ask for guidance.

Lastly, I note that intend to continue reducing my IETF activities around LDAP as I no longer work day-to-day with LDAP.  So I’m saying “no” to requests to get involved beyond my current very limited role as the LDAP registries expert.

— Kurt


> 
> 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.
> 
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext