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

[Paul Eggert <[e-mail]>]

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"