Subject: [Tzdist-bis] so... draft-murchison-tzdist-tzif-07

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jun 2018 08:33:18 +0200

Hi,

Looking over this draft, I want to do two things:

 1. Review text changes
 2. Review open issues

First text changes.  I have one nit about the current text.  The first
is that there seems to be some redundancy:

>    leap second records:  A series of eight- or twelve-octet records
>       specifying the corrections that need to be applied to UTC in order
>       to determine TAI.  The records are sorted by the occurrence time
>       in strictly ascending order.  The number of records is specified
>       by the 'leapcnt' field in the header.  If no records are present,
>       or if a timestamp occurs before the occurrence time in the first
>       record, the value of TAI - UTC - 10 is zero, and this zero value
>       applies proleptically even to timestamps before the introduction
>       of TAI or UTC.  

^^ I think Paul's intent, and Paul can correct me if I'm wrong, is that
the text from below replace the last sentence above.

>
>       corr(ection):  A four-octet signed integer specifying the value of
>          TAI - UTC - 10 on or after the occurrence.  The correction
>          value in the first leap second record, if present, MUST be
>          either one (1) or minus one (-1).  The correction values in
>          adjacent leap second records MUST differ by exactly one (1).
>          For timestamps that occur before the occurrence time in the
>          first leap second record (or for all timestamps if there are no
>          leap second records), the value of TAI - UTC - 10 is zero, and
>          this zero value applies even to timestamps before the
>          introduction of TAI or UTC.  (The expression "TAI - UTC - 10"
>          comes from the fact that TAI - UTC was defined to be 10 just
>          prior to the first leap second in 1972, so clocks with leap
>          seconds that use the UNIX Time origin of 1970 have a zero
>          offset relative to UTC before the first leap second.)

^^ The last two sentences here (including the parenthetical.  My
suggestion is to remove the first occurrence.

Now to open issues:

>    o  Should we allow TZDIST clients to choose whether they want TZif
>       files with/without leap seconds via separate MIME types?  E.g.
>       application/tzif and application/tzif+leap?

If we have two content types, then there must be a
"mandatory-to-implement", and we must say that along the lines of-

TZDIST servers offering application/tzif+leap MUST also offer
application/tzif.  That way a client can indicate what it wants, and the
server can provide the appropriate content.

Does that make sense?  This leaves open what happens when email is used
as a transport.  We might want to add some guidance about including both
in MIME multipart/alternative, in terms of preference, but that's about
as far as I would go.

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Jun 2018 18:04:53 -0400

On 06/26/2018 02:33 AM, Eliot Lear wrote:
> ^^ I think Paul's intent, and Paul can correct me if I'm wrong, is 
> that the text from below replace the last sentence above.
>

Good catch.  I will make that change as soon as Paul confirms.

> application/tzif.  That way a client can indicate what it wants, and 
> the server can provide the appropriate content.
>
> Does that make sense?
>

Yes, perfect sense.  Have we settled on application/tzif+leap?  Is +leap 
the preferred way to distinguish the MIME type?  Is a parameter better 
or worse?

> This leaves open what happens when email is used as a transport.  We 
> might want to add some guidance about including both in MIME 
> multipart/alternative, in terms of preference, but that's about as far 
> as I would go.
>

Do we even need to discuss email as a transport?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Jun 2018 00:20:20 +0200

Hi Ken,

On 27.06.18 00:04, Ken Murchison wrote:
> Have we settled on application/tzif+leap?  Is +leap the preferred way
> to distinguish the MIME type?  Is a parameter better or worse?
>
Bringing Ned back in.  I don't know the answer.  Ned, should we use a
"+" or should we use a "-"?  My understanding is that "+" tends to
indicate encoding options, like "mud+json" or "mud+xml".  I don't view
this as an encoding option but more a matter of whether data is present.
>> multipart/alternative, in terms of preference, but that's about as
>> far as I would go.
>>
>

No, but if we did it would be one sentence.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Tue, 26 Jun 2018 16:49:36 -0700

Eliot Lear wrote:
> I have one nit about the current text.  The first
You are correct that there's unwanted redundancy here. My intent was to have my 
June 12 proposal 
<https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00094.html> 
supersede my June 11 proposal 
<https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00092.html>, and 
now that you mention it I see that the redundancy came from the following 
passage, which was in the June 11 but not the June 12 proposal and which should 
be deleted:

> +		      If no records are present, or if a timestamp occurs
> +		      before the occurrence time in the first record, the
> +		      value of TAI - UTC - 10 is zero, and this zero value
> +		      applies proleptically even to timestamps before the
> +		      introduction of TAI or UTC.

I am attaching a proposed patch to do that. This patch also fixes some other 
glitches I noticed in tzif-07, as follows:

* For version 2: "The TZ string in the footer, if present and nonempty, MUST 
strictly adhere to the POSIX-specified value ranges." First, this is confusing, 
because if the footer is present then the TZ string must be present by 
definition (it may be empty). So the "present and" should be removed. Second, 
the TZ string must not merely adhere to the POSIX-specified ranges; it must 
adhere to all the POSIX rules for TZ strings, for example, the POSIX 
restrictions on the characters that can go into time zone abbreviations.

* For version 3: "The TZ string in the footer, if present and nonempty, MAY use 
the TZ string extensions". Left unstated is that the TZ string must stick to 
POSIX except for using these extensions.

* For "TZ string": "The string is either empty or MUST use the expanded format" 
This is defining what a TZ string is, so isn't "MUST" out of place? Otherwise 
we'd need to use MUST in a lot more places than we do (pretty much in every 
definition). More important, this definition requires that a TZ string must 
conform to POSIX, but that is not true for version 3 TZ strings, which can use 
some extensions to POSIX.

* <https://www.freebsd.org/cgi/man.cgi?query=zic> is a zic man page that is so 
out-of-date that I would rather not point to it from the TZif spec. Instead, 
let's point to the GNU/Linux man pages which at least are from the current 
decade (and I will file bug reports to get them to be more up-to-date). So let's 
change this to <http://man7.org/linux/man-pages/man8/zic.8.html>.
--- draft-murchison-tzdist-tzif-07.xml	2018-06-21 14:24:35.276770884 -0700
+++ draft-murchison-tzdist-tzif-07-1.xml	2018-06-26 16:32:56.475227669 -0700
@@ -322,17 +322,18 @@
	                  header and data block, a 64-bit header and data
	                  block, and a footer.
	                  The TZ string in the
-	                  <xref target='footer'>footer</xref>, if present and
+			  <xref target='footer'>footer</xref>, if
	                  nonempty, MUST strictly adhere to the
-	                  POSIX-specified value ranges.
+			  POSIX requirements for the TZ environment variable.
		        </t>
		        <t hangText="'3' (0x33)">
			  Version 3 - The file MUST contain the 32-bit
	                  header and data block, a 64-bit header and data
	                  block, and a footer.
	                  The TZ string in the
-	                  <xref target='footer'>footer</xref>, if present and
-	                  nonempty, MAY use the TZ string extensions
+			  <xref target='footer'>footer</xref>, if
+			  nonempty, MUST conform to POSIX requirements
+			  except that it MAY use the TZ string extensions
	                  <xref target='tzstrext'>described below</xref>.
	                  <vspace/><vspace/>
	                  Implementations SHOULD generate a version 3 file if
@@ -506,11 +507,6 @@
	              strictly ascending order.
	              The number of records is specified by the
	              'leapcnt' field in the header.
-		      If no records are present, or if a timestamp occurs
-		      before the occurrence time in the first record, the
-		      value of TAI - UTC - 10 is zero, and this zero value
-		      applies proleptically even to timestamps before the
-		      introduction of TAI or UTC.
	              Each record has one of the following structures:
		      <list style='hanging'>
		        <t hangText="32-bit Data Block:">
@@ -652,11 +648,14 @@
	            <t hangText="TZ string:">
	              A rule for computing local time changes after the last
	              transition time stored in the 64-bit data block.
-	              The string is either empty or MUST use the expanded format
+		      The string is either empty or uses the expanded format
	              of the "TZ" environment variable as defined in Section 8
	              of the "Base Definitions" Volume of <xref
-	              target="POSIX"/>.  If empty, the corresponding
-	              information is not available.
+		      target="POSIX"/>, possibly with extensions
+		      <xref target='tzstrext'>described below</xref> in
+		      version 3 files.
+		      If the string is empty, the corresponding information is
+		      not available.
		      If the string is nonempty and one or more transitions
		      appear in the 64-bit data, the string MUST be
	              consistent with the last 64-bit transition - i.e.,
@@ -848,7 +847,7 @@
	            applications that need to use or exchange time zone
	            information, such as the
	            <eref
-	                target='https://www.freebsd.org/cgi/man.cgi?query=zic'>
+			target='http://man7.org/linux/man-pages/man8/zic.8.html'>
	              Time Zone Information Compiler (zic)
	            </eref>
	            and the

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 27 Jun 2018 13:56:30 +0900

> this as an encoding option but more a matter of whether data is present.

Yes, tzif-leap is better. + should only be used with defined suffixes.

Regards,   Martin.

---

From: Ned Freed <[email-masked]>
Date: Wed, 27 Jun 2018 07:26:41 -0700 (PDT)

> this as an encoding option but more a matter of whether data is present.

Unless you intend to define +leap as a structured format - which I doubt -
you have to use a dash.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Jun 2018 10:39:16 -0400

Hi Ned,

Does using a parameter (e.g. ";leapseconds=true") rather than the 
"-leap" suffix make more sense?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Jun 2018 16:47:16 +0200

Don't do a parameter, for reasons we discussed earlier.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Jun 2018 11:07:18 -0400

Fair enough.

Ned, where in the registration templates do I state that the data must 
(not) include leap second records?  Interop considerations? Restrictions?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Wed, 27 Jun 2018 18:07:19 -0700 (PDT)

> (not) include leap second records?  Interop considerations? Restrictions?

I'd put it under interop. Of course the real place for it is in the
specification.

				Ned