Subject: Re: Last Call: <draft-murchison-tzdist-tzif-13.txt> (The Time Zone Information Format (TZif)) to Proposed Standard

From: tom petch <[email-masked]>
Date: Thu, 13 Sep 2018 11:54:34 +0000

My arithmetic may be letting me down, but in s.3.2, when there are
'typecnt' entries in a list of transition types, then I would expect the
index to be
[0, 'typecnt'-1)
or
[1, 'typecnt')
but not
[0, 'typecnt')
as the I-D says, unless zero has a special meaning but then it is not
really an index.

Ditto for (desig)idx  and charcnt except that this list is NUL
terminated, but then I would not expect it to be valid to index the NUL.

I infer, and would rather be told explicitly, that
"The total number of octets is specified by the 'charcnt' field ..
excludes the NUL that terminates the list.

In s.1,
"the source the time zone data  metadata, identifiers, ..."
would appear to be light of an 'of'.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 11, 2018 4:55 PM

> The IESG has received a request from an individual submitter to
consider the
> following document: - 'The Time Zone Information Format (TZif)'
>   <draft-murchison-tzdist-tzif-13.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-10-09. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>    This document defines the Time Zone Information Format (TZif) for
>    representing and exchanging time zone information, independent of
any
>    particular service or protocol.  Two MIME media types for this
format
>    are also defined.
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/ballot/
>
> No IPR declarations have been submitted directly on this I-D.
>

---

From: Tim Parenti <[email-masked]>
Date: Thu, 13 Sep 2018 10:21:09 -0400

It's a fairly standard interval or range notation in mathematics that the
types of the brackets used are important.  I would imagine this appears in
plenty of other RFCs and the like.

The square left bracket next to 0 means "starting at and including 0",
while the round right bracket next to 'typecnt' means "up to but NOT
including 'typecnt'."  So there are a total of 'typecnt' elements, indexed
from 0 to 'typecnt'-1, inclusive.  Likewise for (desig)idx and charcnt.

https://en.wikipedia.org/wiki/Interval_(mathematics)

This convention of including the lower bound and excluding the upper has an
established history in computing as well:
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

--
Tim Parenti

On Thu, 13 Sep 2018 at 07:55, tom petch <[email-masked]> wrote:

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

---

From: Paul Eggert <[email-masked]>
Date: Thu, 13 Sep 2018 11:32:18 -0700

tom petch wrote:
> I would expect the

Alhough the [lo, hi) notation is well-established (as Tim Parenti mentioned), it 
wouldn't hurt to reword this to [0, 'typecnt'-1] to avoid the confusion you ran 
into.
> excludes the NUL that terminates the list.

charcnt includes the NUL; it does not exclude it. Since you inferred otherwise 
we should make this explicit. Also, come to think of it, we should say that 
charcnt MUST NOT be zero, as this constraint (which is a logical implication of 
the already-documented constraint that typecnt must not be zero) will help avoid 
further confusion in this area.
> would appear to be light of an 'of'.

Thanks, good catch.

Proposed patch attached. It attempts to address all the above issues.
--- draft-murchison-tzdist-tzif-14.xml	2018-09-13 11:08:37.082278967 -0700
+++ draft-murchison-tzdist-tzif-14-01.xml	2018-09-13 11:27:43.484884588 -0700
@@ -118,7 +118,7 @@

	      <t>This specification does not define the source of leap second
-	      information, nor does it define the source the time zone
+	      information, nor does it define the source of the time zone
	      data, metadata, identifiers, aliases, localized names, or
	      versions as defined in Section 3 of <xref target='RFC7808'/>.
	      One such source is the IANA-hosted time zone database <xref
@@ -379,7 +379,9 @@
		    <t hangText="charcnt:">
	              A four-octet unsigned integer specifying the total number
	              of octets used by the set of time zone designations
-	              contained in the data block.
+	              contained in the data block - MUST NOT be zero.
+		      The count includes the trailing NUL (0x00) octet at the
+		      end of the last time zone designation.
		    </t>
		  </list>
	        </t>
@@ -448,7 +450,7 @@
	              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').
+	              Each type index MUST be in the range [0, 'typecnt'-1].
		    </t>
		    <t hangText="local time type records:">
	              A series of six-octet records specifying a local time
@@ -490,7 +492,7 @@
	                  A one-octet unsigned integer specifying an index into
	                  the series of time zone designation octets,
	                  thereby selecting a particular designation string.
-	                  Each index MUST be in the range [0, 'charcnt'), and
+	                  Each index MUST be in the range [0, 'charcnt'-1], and
			  MUST index a NUL-terminated (0x00) sequence of
			  octets.
	                </t>

---

From: tom petch <[email-masked]>
Date: Thu, 13 Sep 2018 11:54:34 +0000

In s.1,

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;

consider the
final
be
beginning of
any
format

---

From: tom petch <[email-masked]>
Date: Tue, 18 Sep 2018 10:19:18 +0000

----- Original Message -----
From: "Tim Parenti" <[email-masked]>
Sent: Thursday, September 13, 2018 3:21 PM

> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Ah yes, my mathematics has indeed let me down. Thank you for putting me
right.

Tom Petch