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

[Kurt Zeilenga <[e-mail]>]

> On Oct 26, 2014, at 8:18 AM, Sean Leonard <[e-mail]> wrote:
> 
> On 10/26/2014 6:03 AM, Kurt Zeilenga wrote:
>> 
>>> On Oct 5, 2014, at 2:52 PM, Sean Leonard <[e-mail]> 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