Thank you. I am happy with the answers. Balazs -----Original Message----- From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> Sent: 2020. március 22., vasárnap 22:12 To: Balázs Lengyel <balazs.leng...@ericsson.com> Cc: 'netmod@ietf.org' <netmod@ietf.org> Subject: Re: [netmod] Simple date in 6991bis-02
On Thu, Mar 19, 2020 at 11:30:17AM +0000, Balázs Lengyel wrote:
> Hello,
>
> This might have been discussed earlier, but I still find it strange
> that the
>
>
> typedef date {
>
> has the timezone as a mandatory part. While I understand the issue
> that when a day starts/ends is uncertain without the timezone, in real
> life people practically never add the timezone to a date, and it does
> not cause major problems. So IMHO following life we should have a
> simple-date datatype that does not include any timezone. Actually we
> do have that datatype just we called it revision-identifier. Really
strange.
>
I checked RFC 3339 again and it defines full-date without a timezone.
On the other hand, XML schema's definition of date seems to have an optional
timezone offset. I think following XML schema by making the timezone offset
optional is the right approach.
It might also be usefult to define time as a typedef. RFC 3339 defines
full-time with a mandatory timezone while XML schema defines time with
optional timezone. Again, I would follow XML schema here, making the
timezone offset optional for the time type as well.
> I would also consider to tighten up the pattern for
> revision-identifier/date/date-and-time.
>
> pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
>
> This would prohibit 2020-16-67 : months > 12 or days > 31
If we tighten the pattern, we should do this for date, date-and-time, and
revision. And then we should also tighten the revision offset, which
currently is \d{2}:\d{2}. And here things get interesting again.
RFC 3339 restricts the offset to 00-23 (hour) and 00-59 (minute). XML schema
says the hour is in 00-14 and the minute in 00-59. The spec says:
Based on timezones currently in use, (c) could vary from
2000-01-20T12:00:00+12:00 to 2000-01-20T12:00:00-13:00. It is,
however, possible for this range to expand or contract in the
future, based on local laws. Because of this, the following
definition uses a somewhat broader range of indeterminate values:
+14:00..-14:00.
Perhaps we should follow that approach. This would mean we have:
typedef date {
type string {
pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
}
}
Looking at the description and RFC 3339 again, I noticed a real problem or
bug in our definition: RFC 6991 says:
[...] The canonical format for
date values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00.
This is not consistent with what RFC 3339 says in section 4.3:
If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00".
RFC 3339 seems to be silent about the situation where neither the offset to
UTC is unknown and I strongly dislike that the two specs differ in the
definition of the -00:00 semantics. I would call this a bug and fix it but
then others may claim this is an non-backwards compatible change...
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
