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

[Mark R Bannister <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ldapext
>
>
>
> _______________________________________________
> Ldapext mailing list
> [e-mail]
> 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.