The Time Zone Information Format (TZif)
draft-murchison-tzdist-tzif-16

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

§7:

I'm glad to see a privacy considerations section in this document. I do
think, however, that it overlooks a relatively major point. The reasons that a
client might choose to download a time zone other than the one it is currently
in will frequently pertain to upcoming locations that its users are going to
be in. While the specific time frame for such a visit won't be indicated, this
information is likely to be perceived by users as very privacy sensitive. I
believe this document should recommend that time zone retrieval be performed
over a confidential channel.

---------------------------------------------------------------------------

§3.2:

>  verrsion 2+ data block.

Nit: "version"

---------------------------------------------------------------------------

General:

The format described by this document is rather complex in some ways. I think it
would be a great aid to implementors if the document included an example,
especially if it were annotated.

I share Spencer's confusion about whether this is documenting something that exists, or if it is defining new things. I think a section with a little background, and possibly an explanation of the history of the 3 mentioned versions, would be helpful.

(Note that, if the answer is that it is defining (some) new things, I kind of wish this had been a working group document. But I'm not going to push that point this late in the process.)

I agree with Adam's concern about privacy. Are there any use cases where a TZIF object might be associated with a person? (For example, I know people who run scripts to insert their current time zone in their XMPP status.) If so, that might imply geolocation information, which is definitely privacy sensitive.

Otherwise, I have a few editorial comments:

§3: "... data specific to version
N+1 either typically appears after version N data..."
Does "typically" imply "not always? I realize there are two choices in the paragraph, but are there cases where neither are true?

§4: "These recommended practices should be followed..."
That language seems to weaken the MUST in the second bullet.

Updating to remove my Discuss position, as I am confident that it can be
resolved (e.g., via an RFC Editor note).  The original point was:

This is a very boring, almost-trivial discuss point, but the document seems to have
an internal inconsistency to resolve before publication:

Section 3.1 says that the typecnt "MUST NOT be zero", but Section 3.2 says:

   A TZif data block consists of seven variable-length elements, each of
   which is series of zero or more items.  [...]

This is in conflict with the above "MUST NOT be zero" for typecnt.
I don't have a better suggestion than adding a parenthetical "(except for
the local time records, which as mentioned above cannot have zero items)",
even though I acknowledge that it is pretty awkward.

Original COMMENT section:

Section 2

   Coordinated Universal Time (UTC):  The basis for civil time since
      1960.  It is approximately equal to mean solar time at the prime
      meridian (0 degrees longitude).

Usually when "approximately" is used I ask for some quantification/bounds,
but I guess we can skip that for this well-known case.

Section 3.2

   transition types:  A series of one-octet unsigned integers specifying
      the type of local time of the corresponding transition time.
      These values serve as indices into the array of local time type
      records.  The number of type indices is specified by the 'timecnt'
      field in the header.  Each type index MUST be in the range [0,
      'typecnt' -1].

Please specify that the array accesses are zero-indexed.  (Also for
(desig)idx.)

      (is)dst:  A one-octet value indicating whether local time should
         be considered Daylight Savings Time (DST).  The value MUST be 0

nit: just "Daylight Saving"

Section 5.1

nit(?): some readers might interpret the "truncation range" to be "the
range that is truncated, i.e., omitted, from the file" as opposed to "the
range after truncation".  I guess one could make the same claim about the
phrase "truncated range" as well, so maybe no action is the best plan,
here.

Section 7

I also agree with Adam about the privacy considerations -- while the
contents of the file are not the concern, the metadata surrounding which
files go where have privacy implications worth mentioning.

I'm a little confused on one high-level point. In this text, 

   This document defines the Time Zone Information Format (TZif).  It is
   a binary format used by most UNIX systems to calculate local time.
   There is a wide variety of interoperable software [tz-link] capable
   of generating and reading files in this format.

is it correct to say that you're documenting the existing format, or are you also defining aspects that are not currently deployed (which would obviously be "defining")?