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

Kurt Zeilenga <kurt.zeilenga@isode.com> Sun, 26 October 2014 15:41 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 1442B1A8977 for <ldapext@ietfa.amsl.com>; Sun, 26 Oct 2014 08:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6FaaqereSEG7 for <ldapext@ietfa.amsl.com>; Sun, 26 Oct 2014 08:41:35 -0700 (PDT)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2831A00F5 for <ldapext@ietf.org>; Sun, 26 Oct 2014 08:41:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1414338094; d=isode.com; s=selector; i=@isode.com; bh=Hll8kZTf1l5M54+1MSU8iq5wBgZ1EFQz4YXYLlrj/Ic=; 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=sv0WxBZ/QDQccC3fn8+P5l5rbNBLGT7rY5Z2ovhhn6zIMgRnuBW5ilq8Tg/wJ+jGNlaMYD OR4986LdG+ChZrSkHgO1u1lyxde3kmJGTdvzRJe/Ra5hzEDfCL+0TOySTI61jQgOtByp+R Cr3emVRGfwAOuIvThTe7WkFxsDeqysk=;
Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VE0WLQBhOVE0@waldorf.isode.com>; Sun, 26 Oct 2014 15:41:34 +0000
X-SMTP-Protocol-Errors: NORDNS PIPELINING
From: Kurt Zeilenga <kurt.zeilenga@isode.com>
In-Reply-To: <544D10C9.9050705@seantek.com>
Date: Sun, 26 Oct 2014 08:41:29 -0700
Message-Id: <76480709-D5AC-47EE-849A-DCB2A26A2F6B@isode.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>
To: Sean Leonard <dev+ietf@seantek.com>
X-Mailer: Apple Mail (2.1990.1)
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/FsWj-_A1XSXoyYlLwDJBMiFOiVU
Cc: ldapext@ietf.org, =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>
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: Sun, 26 Oct 2014 15:41:37 -0000

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

-- Kurt