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

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

Ok, got it. I will notify the RFC 3739 authors (which I am doing now).

As for my own ldap-pkcs9 draft, I will add clarifying text on the matter.

(I would be fine with making dateofBirth a CHOICE between 
GeneralizedTime and another type such as the ones mentioned above. 
However, there would be interoperability issues.)

Sean

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