Subject: Re: [dispatch] draft-murchison-rfc8536bis-02

From: Patrick McManus <[email-masked]>
Date: Thu, 16 Dec 2021 18:35:52 -0500

Hi All - this is mostly an update to a document from a closed WG. The only
dispatch input we have heard on it was back on the -00 where a previous
participant in the now closed wg thought the update made sense as an AD
sponsored item, and there being no contrary input, it seemed to be a good
candidate for AD sponsorship to the dispatch chairs as well. Murray has
agreed that makes sense and the dispatch chairs have offered this list as a
venue for any related discussion during sponsorship.

I anticipate we'll hear more from Murray and authors on this - but I wanted
to tie up the dispatch loose end.

On Wed, Nov 10, 2021 at 11:36 AM Ken Murchison <[email-masked]> wrote:

> Hi all,
>
> I was traveling during DISPATCH this week and wasn't able to ask this
> question there, so I'm bringing it to the list.  I'm looking to dispatch
> draft-murchison-rfc8536bis
> <https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis>.  RFC
> 8536 was previously handled on the tzdist-bis mailing list and was
> shepherded by Eliot Lear.  Per the introduction in the draft:
>
>    This document obsoletes RFC 8536 <https://datatracker.ietf.org/doc/html/rfc8536>, providing editorial improvements,
>    new details, and errata fixes while keeping full compatibility with
>    the interchange format of RFC 8536 <https://datatracker.ietf.org/doc/html/rfc8536>.  Additionally, a new version of
>    the format is defined.  The changes from RFC 8536 <https://datatracker.ietf.org/doc/html/rfc8536> are summarized in
>    Appendix C <https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis#appendix-C>.
>
> I, along with my co-authors, would be happy to continue this work wherever
> this group deems suitable.  I don't believe that we expect too much churn
> at this point, unless serious technical issues are raised.
>
> FWIW, recent versions of tzcode already are capable of using the v4 format
> where appropriate.
>
> Regards,
> Ken
>
> --
> Kenneth Murchison
> Senior Software Developer
> Fastmail US LLC
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Dec 2021 08:22:29 +0100

I've read over the changes relating to truncation in particular, and the 
text *seems* good.  But there are often corner cases.  I wrote test code 
to validate the previous work, and I suggest that someone do the same 
for this document, particularly as relates to §5.1.  If someone contacts 
me offline, I can provide that code, privately with the usual caveats 
(not for release, should not be used in production, may cause cancer or 
warts, etc).  I might have some time to whack the code myself, but I 
can't promise it.

Bugs here could conceivably cause people a fair amount of 
gastro-intestinal distress.  Therefore, it might be good to get some 
reviews from the tz mailing list, as well as the downstream 
implementations (php, python, java).

Eliot

On 17.12.21 00:35, Patrick McManus wrote:
> Hi All - this is mostly an update to a document from a closed WG. The 
> only dispatch input we have heard on it was back on the -00 where a 
> previous participant in the now closed wg thought the update made 
> sense as an AD sponsored item, and there being no contrary input, it 
> seemed to be a good candidate for AD sponsorship to the dispatch 
> chairs as well. Murray has agreed that makes sense and the dispatch 
> chairs have offered this list as a venue for any related discussion 
> during sponsorship.
>
> I anticipate we'll hear more from Murray and authors on this - but I 
> wanted to tie up the dispatch loose end.
>
>     I was traveling during DISPATCH this week and wasn't able to ask
>     this question there, so I'm bringing it to the list.  I'm looking
>     to dispatch draft-murchison-rfc8536bis
>     <https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis>.
>     RFC 8536 was previously handled on the tzdist-bis mailing list and
>     was shepherded by Eliot Lear.  Per the introduction in the draft:
>
>         This document obsoletesRFC 8536  <https://datatracker.ietf.org/doc/html/rfc8536>, providing editorial improvements,
>         the interchange format ofRFC 8536  <https://datatracker.ietf.org/doc/html/rfc8536>.  Additionally, a new version of
>         the format is defined.  The changes fromRFC 8536  <https://datatracker.ietf.org/doc/html/rfc8536>  are summarized in
>     I, along with my co-authors, would be happy to continue this work
>     wherever this group deems suitable.  I don't believe that we
>     expect too much churn at this point, unless serious technical
>     issues are raised.
>
>     FWIW, recent versions of tzcode already are capable of using the
>     v4 format where appropriate.
>
>     Regards,
>     Ken
>
>     -- 
>     Kenneth Murchison

---

From: Paul Eggert <[email-masked]>
Date: Fri, 17 Dec 2021 00:42:19 -0800

On 12/16/21 23:22, Eliot Lear wrote:
> I wrote test code to validate the previous work, and I suggest that 
> someone do the same for this document, particularly as relates to §5.1.

Yes, it would be nice for someone to do that. (Hope it doesn't have to 
be me....)

PS. Thought you might be amused by today's email exchange about glibc 
and a truncated TZif file representing Asuncion, Paraguay. It indicates 
some real-world experience and issues with TZif truncation (this email 
exchange is independent of the 8536bis draft changes):

https://sourceware.org/pipermail/libc-alpha/2021-December/134316.html
https://sourceware.org/pipermail/libc-alpha/2021-December/134322.html