Subject: [Tzdist-bis] draft-murchison-tzdist-tzif: Assembled last call edits

From: Ken Murchison <[email-masked]>
Date: Mon, 8 Oct 2018 12:00:06 -0400

For those not keeping score at home, attached are the diffs from draft 
-14 and my current working copy.  The diff is mostly (entirely?) new 
text from Paul with a few minor edits by me.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 8 Oct 2018 10:21:21 -0700

Thanks for the heads-up. I saw one typo in this text under "(is)dst".

    A value of one (1) indicates that this time is DST.

The word "type" is missing. It should read:

    A value of one (1) indicates that this time type is DST.

---

From: Tim Parenti <[email-masked]>
Date: Tue, 9 Oct 2018 22:00:33 -0400

Thanks, Ken, for the summary.  It really helps.

One thought, looking through this, which gets into the general idea of
distributed governance (which is largely theoretical right now, though §1
makes a point of not defining the data source) and, as such, may get a bit
toward the fringes of the intended scope of this document, but I do think
it merits a bit of discussion, whether here or elsewhere.

§3.1 indicates simply that the ver(sion) octet in the header MUST be NUL,
'2', or '3'.  While I realize that, unlike most RFCs, this is meant to be a
retrospective document to define extant formats, I don't see anything in §4
or Appendix A that discusses specifically how future versions should be
identified by existing parsers.  Unless there is a clear statement which
I'm missing, this seems to be an oversight.  Or possibly the process of how
future tzif versions would be defined has been thought through outside the
scope of this document, in which case, I would appreciate being given an
executive summary, as any given process is not always clear from IETF
webpages, and then that process should be documented elsewhere.

What I'm envisioning is some new, unforeseen, data-driven need may arise
within the tz community (or any similar community), and version '4' (or
what have you) becomes necessary.  I'd like to avoid two scenarios:

(1) A data source such as tz creates and distributes their own version '4'
based on their own imminent needs, but this later must go through the same
RFC process here and becomes mutated, ultimately resulting in '4', though
widely distributed and recognizable, being effectively "unofficial" and
requiring a quick revision to an "official" version '5'.  Instead, there
could be a process — an unused octet in the header, perhaps — which
indicates whether any extensions are used which have not gone through the
RFC process; effectively, a version '3' file with a 'tz 4-beta' flag.

(2) Downstream parsers see a version '4' file and simply give up, saying
"well, that's not a valid tzif file according to RFC XXXX".  I may be
missing it, but I see no suggestion that says that implementations which
can understand tzif versions 1, 2, and 3 SHOULD be resilient to receiving
future data versions whenever possible.  In the case that a future version
simply appends more data to what would otherwise be a version 3 file, this
could be handled (roughly, but decently) by simply discarding the extra
data.  In the case that a future version introduces a breaking format
change, that would neither be feasible nor desirable.

While it is certainly not necessary to define upfront a whole system for
whether any future format change is breaking or not, it may behoove us to
define at least how the first such breaking change would be indicated.
Something akin to semantic versioning <https://semver.org/> could perhaps
find its way into a future version to help with this; perhaps with this in
mind, the next breaking version (whenever necessary) could be '400',
spelled as three octets: 0x34 0x30 0x30.  The idea being that "major"
versions would hopefully be as rare as they have been so far and could go
through a fuller RFC process, but that "minor" and "patch" versions would
effectively be local extensions to the x.0.0 standard, which would allow
individual data sources and parsers flexibility and responsiveness in
implementation and could conceivably be tagged in some manner if deemed
necessary.

Of course, a simpler solution would be to simply state now that future
versions N+1 SHOULD NOT be assumed to be a non-breaking change from version
N, even though versions 3 and 2 were designed with such backward
compatibility and interoperability in mind.

On a more personal note, please accept my apologies that life events have
interfered with my ability to help much here over the last several months.
That said, I think you all have done a very good job of defining the format
as it currently exists, which is a large part of why I have stayed quiet.
While I was a bit dismayed to wake up to the (arguably premature?)
expiration notice this morning — indeed, I didn't worry about writing this
as soon as Ken's message came through yesterday since I thought I had a bit
more time — seeing as this is a quite small group and it is still
2018-10-09 for most of us, including all three listed authors, hopefully we
can either quickly incorporate a few sentences addressing this or otherwise
quickly put this concern at ease.

In short: What will the expected process look like for defining tzif
version '4', and does it behoove us to define any of that in this document?

Thanks again.

--
Tim Parenti

On Mon, 8 Oct 2018 at 13:25, Paul Eggert <[email-masked]> wrote:

> _______________________________________________
> Tzdist-bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist-bis
>

---

From: Paul Eggert <[email-masked]>
Date: Tue, 9 Oct 2018 19:17:38 -0700

On 10/9/18 7:00 PM, Tim Parenti wrote:
> What will the expected process look like for defining tzif version 
> '4', and does it behoove us to define any of that in this document?

Not sure what the spec process will be, but we were trying to capture 
what users can expect in this recently-added text. If this is not 
enough, what more should we say?

       Readers designed for version N can read
       version N+1 files without too much trouble; data specific to
       version N+1 either typically appears after version N data so
       that earlier-version readers can easily ignore later-version
       data they are not designed for, or it appears as a minor
       extension to version N that version N readers are likely to
       tolerate well.

---

From: Tim Parenti <[email-masked]>
Date: Tue, 9 Oct 2018 22:39:00 -0400

Hm, while that statement is true for existing versions ("data…typically
appears"), it doesn't really say anything about the future ("data…SHOULD
appear").  However, the following alternative may be too restraining:

Readers designed for version N can expect to read version N+1 files without
too much trouble; data specific to version N+1 SHOULD either appear after
version N data so that earlier-version readers can easily ignore
later-version data they are not designed for, or SHOULD appear as a minor
extension to version N that version N readers are likely to tolerate well.

Perhaps instead, simply prepend/append (or add nearby) something like:

To date, readers designed for…   …  Future versions beyond 3 SHOULD adhere
to similar principles whenever feasible.

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Tue, 9 Oct 2018 21:52:02 -0700

Tim Parenti wrote:
> Future versions beyond 3 SHOULD adhere

I've never been a big fan of entailments, and I'd rather that our successors get 
to decide on their own what to do. (They will anyway.)

---

From: Tim Parenti <[email-masked]>
Date: Wed, 10 Oct 2018 12:22:25 -0400

> to decide on their own what to do. (They will anyway.)

That's why it wasn't a MUST.  ;)

The vague notion of "feasibility" would provide wiggle room anyway, but
yes, our successors and/or future selves can be presumed to know about
these concerns, having read the rest of this spec… so it's probably not
necessary to broach explicitly.

Having removed the question of what the data looks like, then, that only
leaves the question of what the process would look like.  Again, it doesn't
seem that's for us to define.  As long as we think the text as it stands
serves as sufficient guidance to those who will write version 4 as to what
that should entail — especially while keeping in mind that going through a
full spec process may not be feasible at that time — then I think I can
consider my (mostly) curiosity satisfied.

Thanks for clarifying.

--
Tim Parenti

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Oct 2018 18:33:10 +0200

Hi Tim,

We actually did go down this road a bit a while back, in contemplating
something like a version 4, for instance, in which one wouldn't include
a v1 header.  I think we backed out of that entire discussion in part
because nobody is ready to have running code to test what we will really
need.

If worst comes to worst, we can externalize a new version with a new
MIME type, at which point we have complete freedom to do whatever.

Eliot

On 10.10.18 18:22, Tim Parenti wrote:
>
> On Wed, 10 Oct 2018 at 00:52, Paul Eggert <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> The vague notion of "feasibility" would provide wiggle room anyway,
> but yes, our successors and/or future selves can be presumed to know
> about these concerns, having read the rest of this spec… so it's
> probably not necessary to broach explicitly.
>
> Having removed the question of what the data looks like, then, that
> only leaves the question of what the process would look like.  Again,
> it doesn't seem that's for us to define.  As long as we think the text
> as it stands serves as sufficient guidance to those who will write
> version 4 as to what that should entail — especially while keeping in
> mind that going through a full spec process may not be feasible at
> that time — then I think I can consider my (mostly) curiosity satisfied.
>
> Thanks for clarifying.
>
> --
> Tim Parenti
>
>

---

From: Tim Parenti <[email-masked]>
Date: Wed, 10 Oct 2018 12:38:06 -0400

On Wed, 10 Oct 2018 at 12:33, Eliot Lear <[email-masked]> wrote:

> If worst comes to worst, we can externalize a new version with a new MIME
> type, at which point we have complete freedom to do whatever.
>
That seems like a reasonable approach for the pessimal case; thanks.

--
Tim Parenti