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

Sean Leonard <> Sun, 26 October 2014 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A2581A8916 for <>; Sun, 26 Oct 2014 08:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jopvUWwrn57L for <>; Sun, 26 Oct 2014 08:46:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A2801A00EA for <>; Sun, 26 Oct 2014 08:46:05 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1702A50A85; Sun, 26 Oct 2014 11:46:02 -0400 (EDT)
Message-ID: <>
Date: Sun, 26 Oct 2014 08:44:49 -0700
From: Sean Leonard <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Kurt Zeilenga <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000502070808010003090104"
Cc: Stefan Santesson <>, Magnus Nystrom <>, Tim Polk <>,, =?windows-1252?Q?Michael_Str=F6der?= <>
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: Sun, 26 Oct 2014 15:46:07 -0000

On 10/26/2014 8:41 AM, Kurt Zeilenga wrote:
>> On Oct 26, 2014, at 8:18 AM, Sean Leonard <> wrote:
>> On 10/26/2014 6:03 AM, Kurt Zeilenga wrote:
>>>> On Oct 5, 2014, at 2:52 PM, Sean Leonard <> wrote:
>>>> This seems like a reasonable compromise under the circumstances and is not "arbitrary" since regardless of the time zone of the receiver, it would be interpreted as the same date anyway.
>>> I note it would surely represent the wrong date in +13 and +14 timezones.   To be safe, one has to extract the date using the UTC (Z) timezone.
>> is the point that "dateOfBirth" should have been constrained or encoded differently, such as:
>> #1 a string with the pattern YYYY-MM-DD (i.e., not GeneralizedTime, since GeneralizedTime apparently requires a time spec, X.680:2008 Clause 46), or
>> #2 some structured data, such as a SEQUENCE of three integers for year, month, and date, or a NumericString using spaces as delimiters?
>> I note that the new TIME type (X.680:2008 Clause 38) allows for arbitrary time specifications, including YEAR-MONTH-DAY (X.680:2008 Annex B). And that TIME was not invented at the time when dateOfBirth came out.
>> If that is the point, I see the objection. I also find it difficult to accept that "dateOfBirth" was defined incorrectly, given the state of the technology at the time. It could have been a lot worse.
> My point is that a minor clarification to RFC 3739 would be appropriate, if and when its updated, to note that parsers MUST also decode the date in the UTC timezone to avoid shifting of the date due to timezone differences (such as in +14).  Or, if this approach was used in LDAP (which is what I recommend), a comment in the LDAP spec would be appropriate at this time.

Ok, got it. I will notify the RFC 3739 authors (which I am doing now).

As for my own ldap-pkcs9 draft, I will add clarifying text on the matter.

(I would be fine with making dateofBirth a CHOICE between 
GeneralizedTime and another type such as the ones mentioned above. 
However, there would be interoperability issues.)