On 2024-03-22 19:45, Marc Blanchet via Datatracker wrote:
Comment 1)
quoting Sec 3.2 time zone designations: "The character encoding of time zone
designation strings is not specified; however, see Section 4 of this document."
quoting Section 4.: "Time zone designations SHOULD consist of at least three
(3) and no more than six (6) ASCII characters from the set of alphanumerics,
'-', and '+'. This is for compatibility with POSIX requirements for time zone
abbreviations."
I think this text shall be improved, as the 3.2 text says no encoding
specified, while section 4 defines clearly a character encoding that is the
current usage. Moreover, it should use MUST since nothing is described for
implementations that would not follow if they are pretending the SHOULD.
Suggesting to merge the text of section 4 into Section 3.2 and remove the
Section 4 bullet point and use MUST instead of SHOULD.
Moreover, especially given that modern programming languages default charset
for Strings are often UTF-8, and given internationalization requirements in
IETF, a paragraph discussing the rationale of not using UTF-8 in this version
or in the future might be worth.
I agree with Arthur that the intent is correct here: POSIX compatibility
is not required here, although it is recommended, and this means the
text should continue to use SHOULD instead of MUST. To document this
better, after this section 4 bullet:
* Time zone designations SHOULD consist of at least three (3) and no
more than six (6) ASCII characters from the set of alphanumerics,
'-', and '+'. This is for compatibility with POSIX requirements
for time zone abbreviations.
perhaps we should add the following bullet (I'm trying to channel
Arthur...):
* Although time zone designations in TZif files can contain
arbitrary non-NUL bytes in a practice that predates the
widespread use of UTF-8, these can could cause problems if
used as-is. Readers SHOULD instead use POSIX-compatible
substitutes when a TZif file's designations are not
POSIX-compatible.
Not that I know of any reader code that actually does that....
Comment 2)
quoting Sec 4. Interoperability Considerations: ""application/tzif-leap"
(Section 8.2) to indicate that leap-second records are included in the TZif
data "
In IANA Considerations section (8), the description for application/tzif-leap
and application/tzif are identical, which does not help a viewer of the IANA
registry to decide which one to use. Suggesting to add text in 8.2
"Applications that use this media type" for application/tzif-leap to the fact
that this one includes leap-second records so that the IANA registry do contain
a differentiation text.
Good point. To fix this, in section 8.1 "application/tzif", under
"Applications that use this media type:", we could change "time zone
information" to "time zone information relative to POSIX time, which
does not use leap seconds". Similarly, in section 8.2 we could change
"time zone information" to "time zone information relative to
Coordinated Universal Time, which does use leap seconds"
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
