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

Kurt Zeilenga <kurt.zeilenga@isode.com> Sun, 14 December 2014 20:05 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 04D8C1A0183 for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 12:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.71
X-Spam-Level:
X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 GVRhVKHqiFNo for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 12:05:18 -0800 (PST)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A21A017E for <ldapext@ietf.org>; Sun, 14 Dec 2014 12:05:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418587516; d=isode.com; s=selector; i=@isode.com; bh=WjlF5pilRbA10Dhuopr+YqiLUyITd/bQwzo/v99e4Uw=; 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=t6PGTHaWT+28+2aEFedz6TFAHM4v4qM4t8eXlRiaPmIP6VMwfwaLCkK7iJVBi7G69uKGA/ 2qEFKKZGxiOyEGT8nOyKsRcZ4R2/QKRLBl918RHk0CdOra5TAof/fOisp+QtLtWsG1loeu qMunwKjX4BuCDkCZkR1J40y3vL0Rjx8=;
Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VI3tewBCkz76@waldorf.isode.com>; Sun, 14 Dec 2014 20:05:16 +0000
X-SMTP-Protocol-Errors: NORDNS PIPELINING
From: Kurt Zeilenga <kurt.zeilenga@isode.com>
In-Reply-To: <548DE82E.3010103@stroeder.com>
Date: Sun, 14 Dec 2014 12:05:11 -0800
Message-Id: <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@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>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>
X-Mailer: Apple Mail (2.1993)
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/yOquMpXI0PQQ0Gg__cquWDZfUNw
Cc: ldapext@ietf.org, Kurt Zeilenga <kurt.zeilenga@isode.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: Sun, 14 Dec 2014 20:05:19 -0000

> 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.

— Kurt