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

Sean Leonard <[email protected]> Sun, 26 Oct 2014 08:18:33 -0700
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
On 10/26/2014 6:03 AM, Kurt Zeilenga wrote:
>
>> On Oct 5, 2014, at 2:52 PM, Sean Leonard <[email protected] 
>> <mailto:[email protected]>> 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.

Sean

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext