Subject: [Tzdist-bis] Opsdir last call review of draft-murchison-tzdist-tzif-14

From: Qin Wu <[email-masked]>
Date: Tue, 25 Sep 2018 21:57:20 -0700

Reviewer: Qin Wu
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document defines the Time Zone Information Format (TZif) for representing
and exchanging time zone information. The typical application is iCalendar or
scheduling system.

This document is ready, and I only found a few nits in it.
1.Section 3, what is 32-bit transitions, what is 64 bit transitions, how it is
different from 32-bit transition times and leap second occurrences, why header
should also include 32 bit transitions? Wouldn’t header a 44-octet header?
Would it be great to add transition as a new term in the terminology section.

2.Section 3.2 What is the header of the 64-bit data block, how it is different
from 64bit transitions? Isn’t header of the 64 bit data block 44-octet header?

3.Leap second records definition
How 64 bit data block can be used to accommodate 16 octet records?
4. Can you explain footer is needed for version 2 and 3 of TZif file while not
needed for version 1?

---

From: Paul Eggert <[email-masked]>
Date: Thu, 27 Sep 2018 08:38:24 -0700

Thanks for the review. Attached is a proposed patch that attempts to 
> How 64 bit data block can be used to accommodate 16 octet records?

The draft doesn't mention 16-octet records, so I'm not sure what this 
comment is referring to. A leap second record is 8 octets in the 32-bit 
data block, and is 12 octets in the 64-bit data block. The difference in 
length is because the former uses a 4 octet 'occur' field whereas the 
latter uses 8. The 'corr' field is always a 4-octet value, because it's 
assumed that the leap second correction (which is a relative time, not 
an absolute time) must fit into a 32-bit signed integer. In hindsight 
perhaps the leap second correction should also have been an 8-octet 
value, as the 4-octet value will stop working many thousands of years 
from now (see <https://www.ucolick.org/~sla/leapsecs/dutc.html> for why) 
whereas an 8-octet value would have been more future-proof. However, 
billions of readers already assume 4-octet leap second corrections so 
we'll have to defer fixing this to a later version of TZif. Most likely 
version 3 will be obsolete for other reasons long before the limited 
'corr' range becomes a real problem. (If you think this issue should be 
discussed in the spec, I can add something; just let me know.)

The attached proposed patch assumes an earlier patch 
<https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00339.html> 
that I proposed in response to Tom Petch's review.

--- draft-murchison-tzdist-tzif-14-01.xml	2018-09-13 11:27:43.484884588 -0700
+++ draft-murchison-tzdist-tzif-14-02.xml	2018-09-27 08:11:16.386765915 -0700
@@ -162,6 +162,10 @@
	          The time according to a location's current time zone
	          offset from Universal Time.
	        </t>
+	        <t hangText="POSIX Epoch:">
+		  1970-01-01 00:00:00 UTC, the basis for absolute timestamps
+		  in this document.
+		</t>
	        <t hangText="Standard Time:">
	          The time according to a location's law or practice,
	          unadjusted for Daylight Saving Time.
@@ -185,6 +189,11 @@
	          time zone abbreviations."  The interchange format defined in
	          this document is one such form of time zone data.
	        </t>
+	        <t hangText="Transition Time:">
+		  The moment of occurrence of a time change that is not a leap
+		  second.  It is identified with a signed integer count of
+		  Unix Leap Time seconds since the POSIX Epoch.
+		</t>
	        <t hangText="Universal Time (UT):">
	          The basis of civil time.
	          This is the principal form of the mean solar time at the
@@ -201,7 +210,7 @@
	          target="http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html">
	          Section 3 of the "System Interfaces" Volume</eref> of <xref
	          target="POSIX"/>).  This is an integer number of seconds
-	          since the POSIX Epoch (1970-01-01 00:00:00 UTC) not counting
+	          since the POSIX Epoch, not counting
	          leap seconds.  As an extension to POSIX, negative values
	          represent times before the POSIX Epoch, using UT.
	        </t>
@@ -233,7 +242,10 @@
	      variable-length <xref target='data'>data block</xref> using
	      four-octet  (32-bit) transition times and leap second
	      occurrences. These 32-bit values are limited to representing
-	      times from 1901-12-13 20:45:52 through 2038-01-19 03:14:07 UT.</t>
+	      time changes from 1901-12-13 20:45:52 through 2038-01-19 03:14:07 UT,
+	      and the initial header and data block are present only for backward
+	      compatibility with obsolescent readers as discussed in
+	      <a xref='issues'>Common Interoperability Issues</a>.</t>
	
	      <t>The TZif header contains a field which specifies the version
	      of the file's format.  Version 1 files terminate after the
@@ -385,6 +397,11 @@
		    </t>
		  </list>
	        </t>
+	
+		<t>Although the 32- and 64-bit headers have the same format
+		with the same magic number and version fields, their count
+		fields can differ because the 32-bit data can be a subset of
+		the 64-bit data.</t>
	      </section>  <!-- header -->
	
	      <section anchor='data' title='TZif Data Block'>
@@ -671,6 +688,10 @@
		  </list>
	        </t>
	
+		<t>The TZif footer is present only in Version 2 and 3 files,
+		as the obsolescent Version 1 format was designed before the
+		need for a footer was apparent.</t>
+	
	        <section anchor='tzstrext' title='TZ String Extensions'>
		  <t>The TZ string in a Version 3 TZif file MAY use the
		  following extensions to POSIX TZ strings.

---

From: Paul Eggert <[email-masked]>
Date: Thu, 27 Sep 2018 08:38:24 -0700

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Sep 2018 02:42:35 +0000

-----邮件原件-----
发件人: Paul Eggert [mailto:[email-masked]] 
发送时间: 2018年9月27日 23:38
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]; Ken Murchison; [email-masked]
主题: Re: Opsdir last call review of draft-murchison-tzdist-tzif-14

> How 64 bit data block can be used to accommodate 16 octet records?

The draft doesn't mention 16-octet records, so I'm not sure what this comment is referring to. 

[Qin]: My bad, it is a 12-octets records, however I am not sure how 64bit data block can accommodate 96bit (i.e.,12 octets), is data block length 64 bit or a multiple of 64 bit, I think it is the latter, right?
Still in the figure for General Format of TZif Files, header for 32-bit transitions and Data for 32-bit transitions are not clear to me, since the header length is 44 octets, the data block length is a multiple of 32-bit
I would suggest to make this clear since you are using "32-bit transitions", 32 bit transition is equivalent to a multiple of 32-bit? No

A leap second record is 8 octets in the 32-bit data block, and is 12 octets in the 64-bit data block. The difference in length is because the former uses a 4 octet 'occur' field whereas the latter uses 8. The 'corr' field is always a 4-octet value, because it's assumed that the leap second correction (which is a relative time, not an absolute time) must fit into a 32-bit signed integer. In hindsight perhaps the leap second correction should also have been an 8-octet value, as the 4-octet value will stop working many thousands of years from now (see <https://www.ucolick.org/~sla/leapsecs/dutc.html> for why) whereas an 8-octet value would have been more future-proof. However, billions of readers already assume 4-octet leap second corrections so we'll have to defer fixing this to a later version of TZif. Most likely version 3 will be obsolete for other reasons long before the limited 'corr' range becomes a real problem. (If you think this issue should be discussed in the spec, I can add something; just let me know.)

The attached proposed patch assumes an earlier patch <https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00339.html>
that I proposed in response to Tom Petch's review.

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Sep 2018 02:42:35 +0000

---

From: Paul Eggert <[email-masked]>
Date: Thu, 27 Sep 2018 20:41:47 -0700

> [Qin]: My bad, it is a 12-octets records, however I am not sure how 64bit data block can accommodate 96bit (i.e.,12 octets), is data block length 64 bit or a multiple of 64 bit, I think it is the l…

The data block length is not necessarily a multiple of 64 bits (8 
octets). The data block can therefore easily accommodate 12-octet 
records. The time zone designations part of the data block even 
accommodates 1-octet records.

> Still in the figure for General Format of TZif Files, header for 32-bit transitions and Data for 32-bit transitions are not clear to me, since the header length is 44 octets, the data block length…

I don't see anything in the figure implying that the data block length 
is a multiple of 32 bits. To avoid confusion, we could append to the 
following NOTE some text that says "Headers, blocks, the footer, and 
their components are not aligned or padded; for example, an eight-octet 
time value can appear at an odd offset from the start of the data."

> I would suggest to make this clear since you are using "32-bit transitions", 32 bit transition is equivalent to a multiple of 32-bit?

Each 32-bit transition time is indeed 32 bits and is represented by 4 
octets. However, these octets are not aligned to be on a 4-octet 
boundary. I hope the abovementioned proposed addition clears up any 
confusion in this area.

---

From: Paul Eggert <[email-masked]>
Date: Thu, 27 Sep 2018 20:41:47 -0700

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Sep 2018 03:54:21 +0000

-----邮件原件-----
发件人: Paul Eggert [mailto:[email-masked]] 
发送时间: 2018年9月28日 11:42
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]; Ken Murchison; [email-masked]
主题: Re: Opsdir last call review of draft-murchison-tzdist-tzif-14

> [Qin]: My bad, it is a 12-octets records, however I am not sure how 64bit data block can accommodate 96bit (i.e.,12 octets), is data block length 64 bit or a multiple of 64 bit, I think it is the l…

The data block length is not necessarily a multiple of 64 bits (8 octets). The data block can therefore easily accommodate 12-octet records. The time zone designations part of the data block even accommodates 1-octet records.

[Qin]: I can understand 8-octets accommodate 1-octet record, but How does 8-octets data block accommodate 12-octet record, I can not understand.
> Still in the figure for General Format of TZif Files, header for 
> 32-bit transitions and Data for 32-bit transitions are not clear to 
> me, since the header length is 44 octets, the data block length is a 
> multiple of 32-bit

I don't see anything in the figure implying that the data block length is a multiple of 32 bits. To avoid confusion, we could append to the following NOTE some text that says "Headers, blocks, the footer, and their components are not aligned or padded; for example, an eight-octet time value can appear at an odd offset from the start of the data."

[Qin]: how does 44 octets header can be inserted into such "header for 32-bit transitions"? Does header for 32-bit transitions stand for 4 octets header?

> I would suggest to make this clear since you are using "32-bit transitions", 32 bit transition is equivalent to a multiple of 32-bit?

Each 32-bit transition time is indeed 32 bits and is represented by 4 octets. However, these octets are not aligned to be on a 4-octet boundary. I hope the abovementioned proposed addition clears up any confusion in this area.

[Qin]: You are using plura, i.e., "32-bit **transitions**".

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Sep 2018 03:54:21 +0000

---

From: Paul Eggert <[email-masked]>
Date: Fri, 28 Sep 2018 10:49:53 -0700

> [Qin]: I can understand 8-octets accommodate 1-octet record, but How does 8-octets data block accommodate 12-octet record, I can not understand.

The draft does not say that data block sizes are multiples of 8 octets, and 
indeed they need not be multiples of 8 octets. Data blocks are merely 
concatenations of octets, with no padding or alignment. If a field requires only 
1 octet, exactly 1 octet is appended to a data block. If it requires 8 octets, 
exactly 8 octets are appended to the data block. If it requires 12 octets, 
exactly 12 octets are appended to the data block. So it doesn't matter how many 
octets a field requires: whatever number that is, that's the number of octets 
that appear in the resulting data block.

> [Qin]: how does 44 octets header can be inserted into such "header for 32-bit transitions"? Does header for 32-bit transitions stand for 4 octets header?

The header for 32-bit transitions is a 44-octet header. There is no "insertion" 
of one header into another; there's just the one 44-octet header.

> [Qin]: You are using plura, i.e., "32-bit **transitions**".

Sorry, I've lost context. I guess you are suggesting that we make a minor 
wording change to clarify a point about the 32-bit transitions, but I don't know 
what the point is. Could you suggest a specific wording change that would make 
things clearer?

---

From: Paul Eggert <[email-masked]>
Date: Fri, 28 Sep 2018 10:49:53 -0700

---

From: Qin Wu <[email-masked]>
Date: Sat, 29 Sep 2018 01:12:37 +0000

Hi, Paul:
-----邮件原件-----
发件人: Paul Eggert [mailto:[email-masked]] 
发送时间: 2018年9月29日 1:50
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]; Ken Murchison; [email-masked]
主题: Re: Opsdir last call review of draft-murchison-tzdist-tzif-14

> [Qin]: I can understand 8-octets accommodate 1-octet record, but How does 8-octets data block accommodate 12-octet record, I can not understand.

The draft does not say that data block sizes are multiples of 8 octets, and indeed they need not be multiples of 8 octets. Data blocks are merely concatenations of octets, with no padding or alignment. If a field requires only
1 octet, exactly 1 octet is appended to a data block. If it requires 8 octets, exactly 8 octets are appended to the data block. If it requires 12 octets, exactly 12 octets are appended to the data block. So it doesn't matter how many octets a field requires: whatever number that is, that's the number of octets that appear in the resulting data block.

[Qin]:12 octets are appended into the same 8-octet data block? I assume 1000 octets can be appended into that 8-octet data block. It looks you are using some kind of compression algorithm.

> [Qin]: You are using plura, i.e., "32-bit **transitions**".

Sorry, I've lost context. I guess you are suggesting that we make a minor wording change to clarify a point about the 32-bit transitions, but I don't know what the point is. Could you suggest a specific wording change that would make things clearer?
[Qin]: I don't understand the meaning of 32 bit transitions,  does this mean one header comprise multiple 32 bit transitions? Does it mean one header length is 32 bit?
For 32 bit data block or data for 32 bit transitions, does it mean one data block comprise multiple 32 bit transitions or one 32 bit transition?
My suggestion is to provide definition for 32 bit transitions.

---

From: Qin Wu <[email-masked]>
Date: Sat, 29 Sep 2018 01:12:37 +0000

Hi, Paul: