Re: [Last-Call] Artart last call review of draft-murchison-rfc8536bis-12

[Arthur David Olson <[e-mail]>]

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

On Fri, Mar 22, 2024 at 10:45 PM Marc Blanchet via Datatracker <
[e-mail]> wrote:

> 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.
>
>
>
>