Postel’s law may apply here: “Be conservative in what you send, be liberal in what you accept.”
Since previous RFCs have left the character encoding of time zone strings undesignated, there can be Tzif-format files in the field with varying encodings; it’s best if software readers can cope with the variants; leaving the encoding unspecified in section 3 may encourage that coping.
Going forward it’s best to encourage interoperability in section 4. The POSIX standard specifies the form of TZ environment variables; among the specifications for that variable’s zone designation portions: “All characters...shall be alphanumeric characters from the portable character set in the current locale, the <plus-sign> ( '+' ) character, or the <hyphen-minus> ( '-' ) character.” Thus the call for ASCII in section 4 (where, with the alphanumeric restriction, ASCII is the same as the portable character set in the C locale). It falls to the POSIX standard writers to provide the rationale for the use of ASCII rather than UTF-8.
--ado
Reviewer: Marc Blanchet
Review result: Ready with Nits
I'm the assigned ART reviewer for this document. While I'm aware of TZ and its
use, I have no competency in this technology.
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.
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
