Re: [Sedate] Éric Vyncke's No Objection on draft-ietf-sedate-datetime-extended-10: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Éric,

thank you for this review.
The changes mentioned below are in

https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/59

Grüße, Carsten


> On 2023-10-17, at 14:15, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-sedate-datetime-extended-10: No Objection
> […]
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # COMMENTS
> 
> ## Section 1.2 (mostly nits)
> 
> The example of New York time would benefit of adding "in the USA" and "in 2023"
> (the latter would allow a better aging -- who knows ?).

Added.


> Should ICAO be expanded ?

This is a quotation from RFC 3339.
I added a reference after it, which carries the expansion.
(The referenced document is unfortunately behind an ICAO paywall — trying to avoid the obvious NATO reference [1] here.)

[1]: https://www.nato.int/nato_static_fl2014/assets/pdf/pdf_2018_01/20180111_nato-alphabet-sign-signal.pdf

> Should "San Francisco" be qualified as in "San Francisco, California" ?

The sentence would actually be true for San Francisco, Antioquia, which has not observed DST since 1993 (or any other San Francisco), because the politicians can still change the time zone, but I added this.

> ## Backward compatibility
> 
> As I am not familiar with RFC 3339, I wonder whether the new syntax could break
> some legacy RFC 3339 implementations (including parsing libraries).

Any use of the new features in IXDTF *must* cause RFC 3339 implementations worth their salt to reject the string.
IXDTF is not in general forward compatible(*) with respect to RFC 3339 implementations (RFC 3339, as updated, is a proper subset of IXDTF).

* Backward compatibility = old data, new system.
* Forward compatibility = new data, old system.

>  Were there
> some tests ?

There is an implementer community that is watching, but I can’t point to any specific tests.  Do you think we need any?

Grüße, Carsten