Re: [ldapext] New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt

Kurt Zeilenga <> Fri, 26 September 2014 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 190CE1A6FAC for <>; Fri, 26 Sep 2014 11:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Status: No, score=-2.486 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, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7THUUKxSVQb for <>; Fri, 26 Sep 2014 11:57:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B471D1A6FAB for <>; Fri, 26 Sep 2014 11:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1411757829;; s=selector;; bh=ZAml9pUQU/El/wsbxcfD81Mreo5Rcx/Usgx6SubndAg=; 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=FjOv+1SBPIHbcmhSTlIpO2BBdBksvg0/A9SCWXL9O1RAF5Zy+BZVuDlRLw5ftJAU37fw3x dt53ZosniLEfLqcOltK/fn2BjOGvqYYElAk5eFwBDRMdawPiiCaiNZENfx5VYl9iyq6nS2 bnpEFQn+f5iKSuHaJ2AeurCgNa9jY54=;
Received: from ((unknown) []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 26 Sep 2014 19:57:09 +0100
From: Kurt Zeilenga <>
In-Reply-To: <>
Date: Fri, 26 Sep 2014 11:56:53 -0700
Message-Id: <>
References: <> <>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <>
X-Mailer: Apple Mail (2.1878.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: ldapext <>
Subject: Re: [ldapext] New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Sep 2014 18:57:14 -0000

Just for the record, the Independent Submission Editor contacted me regarding this draft.  As I'm not terribly active in the LDAP community these days, I suggested he seek review elsewhere such as on this list.

I also noted a couple of things which the IESG might want to consider when the I-D comes before them as an independent submission.
a) Defining an auxiliary object class simply allows 'mail' to be present on entries belong to that class would likely be non-contentious and not terribly likely to create inter-op issues with use of 'mail' as described in standard track documents.

b) How to deal with Internationalized email address in LDAP however is likely far more contentious and far more likely to create inter-op issues with use of 'mail' as described in standard track documents.

That is, I basically hinted that the progressing an independent submission for a simple aux class that allowed for 'mail', and only 'mail', to be present in entries of the class is likely not something that would step on IETF toes... but that doing anything with Internationalized Email Addresses likely would.   However, as I don't have an iron in this fire, I suggested ISE ask an Apps AD early as to what parts of this I-D do step on the IETF toes (one could argue that as there's little LDAP activity in the IETF that none of this does).

Michael, I note that while independent submission is restricted to Informational and Experimental, one doesn't need a WG to pursue standard track.  The IETF processes does allow for individual submissions to be considered for standards track.  (note: independent submission != individual submission). 

Regarding Directory String, I note that while can transfer a BER encoded DirectoryString value, and that would indicate a CHOICE, aside from more commonly transferred using the LDAP syntax (1*UTF8), transfer of BER doesn't imply preservation of the CHOICE.   The general LDAP value preservation rules allows, for instance, a server to return Universal String (in ;binary transfer if they support it for the attribute) even though the value added was a Printable String (when added using ;binary).

Lastly, regarding standardizing Password Policy...  at one time the IETF had before multiple I-Ds here and no clear consensus on which to pursue.  Now there's multiple flavors of password policy in the wild... as well as an X.500 specific password policy spec.    Maybe with different players consensus can be achieved... but I suspect that if the IETF were to pursue this again, especially by forming a WG, that it would likely flounder again due to lack of consensus on various issues.   One might get further by writing an informational RFC which simply documented what some set of implementations do.

-- Kurt