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

Michael Ströder <michael@stroeder.com> Mon, 27 October 2014 09:55 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 C54CE1A8AEC for <ldapext@ietfa.amsl.com>; Mon, 27 Oct 2014 02:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 9M1orDgmY5RL for <ldapext@ietfa.amsl.com>; Mon, 27 Oct 2014 02:55:53 -0700 (PDT)
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 CD19A1A8BBE for <ldapext@ietf.org>; Mon, 27 Oct 2014 02:55:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 58991602C6; Mon, 27 Oct 2014 10:55:46 +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 kg-018bCk6se; Mon, 27 Oct 2014 10:55:38 +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 938DF60041; Mon, 27 Oct 2014 09:55:37 +0000 (UTC)
Message-ID: <544E1697.3050308@stroeder.com>
Date: Mon, 27 Oct 2014 10:55:35 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <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>, Sean Leonard <dev+ietf@seantek.com>
References: <20140926115934.25447.2865.idtracker@ietfa.amsl.com> <542558EB.4000709@stroeder.com> <5425848B.3040504@seantek.com> <54258E77.4010004@stroeder.com> <54258F68.7010109@stroeder.com> <54314F09.6080408@seantek.com> <5431B5BE.9030103@stroeder.com> <5431BDBA.70506@seantek.com> <387EEAAE-4396-465B-B1E6-540FB9D785D9@isode.com> <544D10C9.9050705@seantek.com> <76480709-D5AC-47EE-849A-DCB2A26A2F6B@isode.com>
In-Reply-To: <76480709-D5AC-47EE-849A-DCB2A26A2F6B@isode.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040705040002040807000506"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/EfGM8nMsrRuR67OPoxqzCIrWE6I
Cc: ldapext@ietf.org
Subject: Re: [ldapext] New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
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: Mon, 27 Oct 2014 09:55:56 -0000

Kurt Zeilenga wrote:
> 
>> On Oct 26, 2014, at 8:18 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
>>
>> On 10/26/2014 6:03 AM, Kurt Zeilenga wrote:
>>>
>>>> On Oct 5, 2014, at 2:52 PM, Sean Leonard <dev+ietf@seantek.com> 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.
>>
>> Ok...so 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.

To clarify: Implementations calculating the age of a person must entirely
ignore the time part and simply compare to the local date. At least that't
current practice when calculating the age based on date of birth  in a passport.

Ciao, Michael.