[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dhcwg] [Fwd: Re: Internet draft "A Timezone Option for DHCP" available]

John Hawkinson has provided comments regarding the draft, which I would
class as minor issues.  Paul has recommended some changes to accommodate
those concerns, which I attach below.  Without objection these will be
applied after last call closes.

Eliot
--- Begin Message --- 
Thanks for the comments!

John Hawkinson <jhawk at mit.edu> writes:

> paragraph two of the Introduction gives the example:
>
> | to derive a human readable display string such as "EST" or "EDT"
>
> rather than an example like US/Eastern.

I think the idea is that most humans in California would understand
"PST" or "PDT" but would get confused by raw strings like
"America/Los_Angeles" or "PST8PDT,M4.1.0,M10.5.0".  To make the intent
clearer, perhaps we should change the phrase "display string" to
"abbreviation".

> It might also be nice to see some discussion of what a client is
> supposed to do when a timezone changes out from under it.

Good point.  I'll propose a change along those lines below.


Eliot Lear <lear at cisco.com> writes:

> I believe it is possible to generate a some reasonably meaningful
> POSIX string from a TZ database entry.  I believe this in part
> because I believe the code paths converge if I recall correctly, but
> more so because Paul indicated to me at one point that he wrote some
> code along these lines ;-)

Yes, the code I'm thinking about is the Emacs cal-dst code: it infers
a POSIX-style rule from a TZ database entry.  The heuristic is not
perfect, but it's good enough for most applications (let's put it this
way: the last bug report against GNU Emacs in this area was in 1996 :-).
It is probably worth putting in a generic informational sentence in to
that effect, along with a reference.


One other point: I recently recalled the "Million-dollar glitch" at
the Tiwai Point aluminum smelter on 1997-01-01
<http://catless.ncl.ac.uk/Risks/18.74.html#subj5>.  That was a
leap-year bug, not a time zone bug, but the same thing could happen
with us.  Let's add a warning against relying on timezone settings
when controlling heavy machinery.


Here's a proposed change that addresses the above issues, plus fixing
all the editorial problems people have noted to me privately ("time
zone" -> "timezone" for consistency, "the author is" -> "the authors
are", "three options" -> "two options", "compatability" ->
"compatibility", "Option for DHCPv6" -> "Options for DHCPv6",
redundant option-length paragraph, "String Index" -> "String", "TZ
Database String" -> "TZ Name", "POSIX string" -> "TZ POSIX string",
"suboption" -> "option", less weasel wording when introducing
examples).  I don't know if we can introduce all these changes at this
stage of the process, but if not I guess we can save them for the next
go-round.  Most of them are editorial and can go in now, I hope.

Thanks again for your comments.


--- draft-ietf-dhc-timezone-option-02.txt	2006-08-09 08:49:02.000000000 -0700
+++ draft-ietf-dhc-timezone-option-02-fix1.txt	2006-08-09 10:05:26.000000000 -0700
@@ -75,7 +75,7 @@ Internet-Draft         A Timezone option
 
    In addition, an offset is not sufficient to determine the actual
    timezone in which a client resides, and thus there is no means to
-   derive a human readable display string such as "EST" or "EDT".
+   derive a human readable abbreviation such as "EST" or "EDT".
 
    This memo specifies a means to provide hosts with more accurate
    timezone information than was previously available.  There are
@@ -97,7 +97,10 @@ Internet-Draft         A Timezone option
    real-world locations since 1970.  The TZ database also attempts to
    provide a stable set of human readable timezone identifiers.  In
    addition, many systems already make use of the TZ database, and so
-   the names used are a defacto standard.
+   the names used are a defacto standard.  Because the TZ database
+   contains more information, one can heuristically derive the POSIX
+   information from a TZ identifier (see [9] for an example), but the
+   converse is not true.
 
 1.1.  What about VTIMEZONE elements from iCalendar?
 
@@ -116,7 +119,7 @@ Internet-Draft         A Timezone option
    accuracy requires that a full entry must be specified.  To achieve
    the same information would range from 300 octets upwards with no
    particular bound.  Furthermore, at the time of this writing the
-   author is aware of no operating system that natively takes advantage
+   authors are aware of no operating system that natively takes advantage
    of VTIMEZONE entries.  It might be possible to include an option for
    a TZURL.  However, in a cold start environment, it will be bad enough
    that devices are stressing the DHCP server, and perhaps unwise to
@@ -125,7 +128,7 @@ Internet-Draft         A Timezone option
 
 2.  New Timezone Options for DHCPv4
 
-   The following three options are defined for DHCPv4:
+   The following two options are defined for DHCPv4:
 
 
             PCode  Len   TZ-POSIX String
@@ -149,9 +152,9 @@ Internet-Draft         A Timezone option
    they are NOT terminated by an ASCII NULL.
 
 
-3.  New Timezone Option for DHCPv6
+3.  New Timezone Options for DHCPv6
 
-   The semantics and content of the DHCPv6 encoding of this option are
+   The semantics and content of the DHCPv6 encoding of these options are
    exactly the same as the encoding described for DHCPv4, other than
    necessary differences between the way options are encoded in DHCPv4
    and DHCPv6.
@@ -181,9 +184,7 @@ Internet-Draft         A Timezone option
 
    option-code: OPTION_NEW_POSIX_TIMEZONE(TBD)
 
-   option-length: length of the TZ POSIX String described below.
-
-   option-length: the number of octets of the TZ POSIX String Index
+   option-length: the number of octets of the TZ POSIX String
    described below.
 
 
@@ -192,23 +193,22 @@ Internet-Draft         A Timezone option
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  OPTION_NEW_TZDB_TIMEZONE    |          option-length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                     TZ Database String                        |
+      |                           TZ Name                             |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
    option-code: OPTION_NEW_TZDB_TIMEZONE(TBD)
 
-   option-length: the number of octets of the TZ Database String Index
-   described below.
+   option-length: the number of octets of the TZ Name described below.
 
 
 4.  The TZ POSIX String
 
-   POSIX string is a string suitable for the TZ variable as specified by
+   TZ POSIX string is a string suitable for the TZ variable as specified by
    [1] in Section 8.3, with the exception that a string may not begin
    with a colon (":").  This string is NOT terminated by an ASCII NULL.
-   An example might be as follows:
+   Here is an example:
 
    "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00"
 
@@ -228,17 +228,17 @@ Internet-Draft         A Timezone option
    "EDT".
 
    Clients and servers implementing other timezone options MUST support
-   this suboption for basic compatability.
+   this option for basic compatibility.
 
 
-5.  The TZ Database String
+5.  The TZ Name
 
    TZ Name is the name of a Zone entry in the database commonly referred
    to as the TZ database.  In order for this option to be useful, the
    client must already have a copy of the database.  This string is NOT
    terminated with an ASCII NULL.
 
-   An example string would be "Europe/Zurich".
+   An example string is "Europe/Zurich".
 
    A client that supports this option SHOULD prefer this option to POSIX
    string if it recognizes the TZ Name that was returned.  If it doesn't
@@ -263,6 +263,17 @@ Internet-Draft         A Timezone option
    change dictates prudence, as certain governments give little if any
    notification.
 
+   The effect of a changed timezone on client applications is not
+   specified by this memo, but it may be helpful to note common
+   problems in this area.  Often, client applications consult the
+   timezone setting only during process initialization, or inherit the
+   setting from a parent process, so existing processes on a client
+   may ignore a timezone change returned from the server.  Sometimes
+   it is normal and expected for processes on the same client to have
+   different timezone settings (e.g., remote logins), so client
+   implementations may not change the timezone settings of existing
+   processes.
+
 
 7.  The New Timezone Option and Lease times
 
@@ -292,7 +303,8 @@ Internet-Draft         A Timezone option
 
    An attacker could provide erroneous information to a client.  It is
    possible that someone might miss a meeting or otherwise show up
-   early.  If clients have job processing tools such as cron that
+   early, or that heavy machinery might act at the wrong time or fail
+   to act.  If clients have job processing tools such as cron that
    operate on wall clock time it is possible that certain jobs could be
    triggered either earlier or later, or even repeated or skipped
    entirely if scheduled during a DST transition.  In such cases, the
@@ -304,8 +316,8 @@ Internet-Draft         A Timezone option
    standard or daylight-saving abbreviations, as this might well trigger
    security-relevant bugs in applications.
 
-   Clients using the POSIX option should also be suspicious of any time
-   zone setting whose UTC offset exceeds 25 hours (the POSIX limit, if
+   Clients using the POSIX option should also be suspicious of any
+   timezone setting whose UTC offset exceeds 25 hours (the POSIX limit, if
    the default daylight-saving offset is used).  As of this writing, the
    maximum UTC offset is 14 hours in practice, but governments may
    extend this somewhat in the future.
@@ -375,6 +387,10 @@ Internet-Draft         A Timezone option
         Scheduling Core Object Specification (iCalendar)", RFC 2445,
         November 1998.
 
+   [9]  Eggert, P. and E. Reingold, "cal-dst.el --- calendar functions
+        for daylight savings rules",
+        <http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.
+
 
 Appendix A.  Changes

--- End Message ---
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg