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

Michael Ströder <michael@stroeder.com> Sun, 14 December 2014 20:20 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 0DD541A0181 for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 12:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y7WmBnZn8v5h for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 12:20:05 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDD01A0172 for <ldapext@ietf.org>; Sun, 14 Dec 2014 12:20:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5994660349; Sun, 14 Dec 2014 21:20:02 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjNLqYVWRaF6; Sun, 14 Dec 2014 21:19:54 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 1FB3D602E8; Sun, 14 Dec 2014 20:19:54 +0000 (UTC)
Message-ID: <548DF0E9.6080405@stroeder.com>
Date: Sun, 14 Dec 2014 21:19:53 +0100
From: Michael Ströder <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
To: Kurt Zeilenga <kurt.zeilenga@isode.com>
References: <548DB67C.5060009@stroeder.com> <CF47C8D4-038D-4232-96F8-5EDE3A62C7D2@isode.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com>
In-Reply-To: <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms000909070106010105000408"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/kNiYyqfJAw_a5NR5CaO5t515_eo
Cc: 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: Sun, 14 Dec 2014 20:20:14 -0000

Kurt Zeilenga wrote:
> 
>> On Dec 14, 2014, at 11:42 AM, Michael Ströder <michael@stroeder.com> wrote:
>>
>> Kurt Zeilenga wrote:
>>>
>>>> On Dec 14, 2014, at 9:35 AM, Michael Ströder <michael@stroeder.com> wrote:
>>>>
>>>> Kurt Zeilenga wrote:
>>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis.
>>>>>
>>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing previously published schema definitions.
>>>>
>>>> Yes, but RFC2307bis also changes posixGroup schema.
>>>
>>> Don’t expect I-Ds which violate BCPs to become RFCs.
>>
>> Are you saying that draft-howard-rfc2307bis will never become an RFC because
>> it changes the declaration of 'posixGroup' ('member' instead of 'memberUID')
>> defined in the experimental RFC 2307?
> 
> I won’t say “never” as well BCPs themselves are subject today…   but I can
> tell you that I, as the IESG’s appointed LDAP registries expert to IANA,
> have and will reject requests to register LDAP parameters which purport to
> modify previously published LDAP schema definitions.  Of course, such
> actions are appealable.

So RFC2307bis must start over with completely new NAMEs
for e.g. posixGroup?

(Personally I don't care about assigning a new OID because most LDAP client
implementations don't handle OIDs anyway.)

Ciao, Michael.