Subject: [dispatch] draft-murchison-rfc8536bis-00

From: Ken Murchison <[email-masked]>
Date: Mon, 8 Mar 2021 15:55:09 -0500

All,

The authors of RFC 8536 (Time Zone Information Format) have started an 
update 
<https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis> 
providing editorial improvements, new details, and errata fixes. The 
original specification was done within the now-closed TZDIST WG.

We started this effort too late to get on the DISPATCH agenda earlier 
today, so Barry Leiba suggested that we bring the existing draft here to 
see where the members feel where the continuing work should reside.

The current draft does not make any changes to the format, but we 
recently have determined that an upcoming clarification MAY dictate that 
we specify a new v4 format.

-- 
Kenneth Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Mar 2021 22:13:35 +0100

Hi Ken,

This looks good.  These are very incremental changes, and I’ve confirmed at least that the example that you have for all year DST works on several implementations.  Last time around we did a mini-wg.  Unless there is a real reason to do a v4 format, I’d say that AD-sponsored could get this out quickly.  A v4 format is a horse of a different color.  For that I’d do another mini-WG.  What’s the clarification?

Eliot

> On 8 Mar 2021, at 21:55, Ken Murchison <[email-masked]> wrote:
> 
> All,
> 
> The authors of RFC 8536 (Time Zone Information Format) have started an update <https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis>providing editorial improvements, new details, and errata fixes.  The original specification was done within the now-closed TZDIST WG.
> 
> We started this effort too late to get on the DISPATCH agenda earlier today, so Barry Leiba suggested that we bring the existing draft here to see where the members feel where the continuing work should reside.
> 
> The current draft does not make any changes to the format, but we recently have determined that an upcoming clarification MAY dictate that we specify a new v4 format.
> 
> --
> Kenneth Murchison
> Cyrus Development Team
> Fastmail US LLC
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ken Murchison <[email-masked]>
Date: Tue, 9 Mar 2021 07:43:14 -0500

Hi Eliot,

The clarification is that there is currently no (good) method for 
specifying the expiration of the leap second table.  This wouldn't 
require a change to the format, but perhaps a change in the semantics of 
the last (or additional) leap second record.  Whether this change would 
require a bump in the version is the open question.

On 3/8/21 4:13 PM, Eliot Lear wrote:
> Hi Ken,
>
> This looks good.  These are *very* incremental changes, and I’ve 
> confirmed at least that the example that you have for all year DST 
> works on several implementations.  Last time around we did a mini-wg. 
>  Unless there is a real reason to do a v4 format, I’d say that 
> AD-sponsored could get this out quickly.  A v4 format is a horse of a 
> different color.  For that I’d do another mini-WG.  What’s the 
> clarification?
>
> Eliot
>
>> On 8 Mar 2021, at 21:55, Ken Murchison <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> All,
>>
>> The authors of RFC 8536 (Time Zone Information Format) have started 
>> an update 
>> today, so Barry Leiba suggested that we bring the existing draft here 
>> to see where the members feel where the continuing work should reside.
>>
>> recently have determined that an upcoming clarification MAY dictate 
>> that we specify a new v4 format.
>>
>> -- 
>> Kenneth Murchison
>> Cyrus Development Team
>> Fastmail US LLC
>> [email-masked] <mailto:[email-masked]>