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