Subject: [Tzdist] Some comments on draft-douglass-timezone-service-11

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Aug 2014 09:26:13 +0200

Hi,

These are some comments I had while reading the document.

   - A) Section: 4.2.1.1. Timezone Service SRV Service Labels

_timezones._tcp shouldn't it be: _timezones._sub._http._tcp

    - B) Section 4.1.3: "Clients SHOULD poll for such changes at least once
a day.  A server acting as a local provider, caching timezone data from
another server, SHOULD poll for changes once per hour.  See Section 9 on
expected client and server behavior regarding high request rates."
         In future version I would like to elaborate a bit more how this
system is scalable. Maybe that is already in the document and I missed it.
I can provide text too.

    - C)  clarification on the "name" pattern:  (Mostly editorial) Section
5.8 "name" Parameter: looks to me like a pattern rather than something
standardized (newyorknew-york, nyc, EST...). If my understanding is
correct, as name is also used for the JSON model, maybe we could use
another designation like tzidpattern for example....

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Tue, 19 Aug 2014 10:10:05 +0100

On 19/08/14 08:26, Daniel Migault wrote:
>     - C)  clarification on the "name" pattern:  (Mostly editorial)
> Section 5.8 "name" Parameter: looks to me like a pattern rather than
> something standardized (newyorknew-york, nyc, EST...). If my
> understanding is correct, as name is also used for the JSON model, maybe
> we could use another designation like tzidpattern for example....

This has been an area of division on the tz list, and bounces through to
the current geonames data. The current already truncated set of zone1970
names provided by default on tz ignore any historic detail, and geonames
is only providing this truncated set, so the recent backzone file in
conjunction with the zone and backward files provide a more complete
historic list, but still without a formal mechanism for adding any newly
found historic zones.

For a proper support of any un-truncated data we need a names source and
tz source that removes the 1970 truncation and a naming system which
allows that to happen.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Aug 2014 16:13:29 +0200

Hi, thank for the feed back. I have been scratching my head on it, but I am
not sure I completely got it.

The way I understood name of section 5.8 is that name can be used in
conjunction of a find action to find a specific zone without knowing the
exact syntax.   I figure it out to be mostly like a grep *name* command in
to the tz1970 file.

Now the format of tz1970 imposes a 14 length for the TZ.  Which would not
make possible to find
Yuzhno-Sakhalins or  Yuzhno-Sakhalinsk as the TZ is Asia/Yuzhno-Sakhalin.
Is that what you refer too?

Can you explain a bit more what you mean with tz source and name source?

On Tue, Aug 19, 2014 at 11:10 AM, Lester Caine <[email-masked]> wrote:

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

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Thu, 21 Aug 2014 09:24:39 -0700

Daniel Migault wrote:

> the format of tz1970 imposes a 14 length for the TZ.

I expect Lester Caine was referring not to truncation of individual zone 
names, but to truncation of the database by limiting its scope to zones 
whose time stamps agree since 1970.  Without that limitation, the tz 
database could add many, many more zones that would each need a name. 
According to the admittedly-questionable Shanks data, hundreds of extra 
zones would be needed just to handle Indiana since 1883.

By "names source" and "tz source" I expect he means a hypothetical 
alternative source of names and data that would be willing to take on 
the potential burden of supporting these many extra zones.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Aug 2014 18:35:57 +0200

ok got thanks.

Then do you think the find action should take into consideration zones that
are larger than 14 characters, and more generally patterns that are longer
then the target? I do not know how many zones are concerned by this.

BR,
Daniel

On Thu, Aug 21, 2014 at 6:24 PM, Paul Eggert <[email-masked]> wrote:

> alternative source of names and data that would be willing to take on the
> potential burden of supporting these many extra zones.
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Thu, 21 Aug 2014 11:02:05 -0700

Daniel Migault wrote:
> are larger than 14 characters

Sorry, I don't have the context here (I've read only sections 1-4), but 
many zone names have more than 14 characters, e.g., 
'America/Argentina/Buenos_Aires'.

Although the tz guidelines currently limit zone name components like 
'Argentina' to at most 14 characters, long ago one longer component 
sneaked in.  It is in the backward-compatibility alias 
'Canada/East-Saskatchewan', a name that is bad for another reason (it 
was added by mistake, as it's not really about east Saskatchewan).  It's 
possible that at some point we'll simply remove this bad alias.

It's possible that the 14-character limit will be increased some day, so 
I hope tzdist is not imposing any limit shorter than (say) 255 bytes for 
zone name components.

More generally, the tzdist protocol should not assume that names are 
permanent.  The names are stable in practice, but nothing is permanent.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 22 Aug 2014 09:11:52 +0200

Thanks for the response.

If my understanding is correct tzdist do not introduce such limitations.
These limitations are those of the tz file. It seems this 14 character
limit does not present practical limitations. In addition, this format may
be modified in the future. As a result, it is better to keep matching rules
of the find action simple as they are described in the current version
draft.

BR,
Daniel

On Thu, Aug 21, 2014 at 8:02 PM, Paul Eggert <[email-masked]> wrote:

> 'Argentina' to at most 14 characters, long ago one longer component sneaked
> in.  It is in the backward-compatibility alias 'Canada/East-Saskatchewan',
> a name that is bad for another reason (it was added by mistake, as it's not
> really about east Saskatchewan).  It's possible that at some point we'll
> simply remove this bad alias.
>
> It's possible that the 14-character limit will be increased some day, so I
> hope tzdist is not imposing any limit shorter than (say) 255 bytes for zone
> name components.
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Fri, 22 Aug 2014 11:31:18 +0100

On 22/08/14 08:11, Daniel Migault wrote:
> limit does not present practical limitations. In addition, this format
> may be modified in the future. As a result, it is better to keep
> matching rules of the find action simple as they are described in the
> current version draft.

Current state of play on geonames is that it has a little 9.3 million
names with a length of up to 151 characters (number of bytes uses for
UTF8 text), and is using the 'zone.tzb' list to populate the timezone
entry which has a maximum of 30 characters used. 0.03% of the data does
not have a timezone set, but I've not as yet investigated why on that.

There are currently 418 distinct timezones in geonames, from 1 entry for
Asia/Ust-Nere through to 732128 entries using America/New_York although
it will be interesting to see why Europe/Oslo has 292555 hits ...

The problem which Paul is describing where historically the offset used
by a location was somewhat volatile comes in part from local preferences
changing so the time zone being used would switch. This is still
happening even now, with counties in some states switching between
adjacent timezones where they feel that the DST 'savings' are better.
Essentially tz can't cope well with this type of change as it's outside
of the time data. It is the returning of the correct timezone for a
location over the past few years that may rely on a second level of
historic recording, and is where additional timezones may be required.

Personally I'm looking to simplify things in the database and so we can
use either a numeric ID, although lookup may be helped if that is
prefixed by the CC2 country code. I've currently allowed 40 characters
for the timezone field, but all that needs really is a 16bit number.

The remaining problem is if one records the history of timezone used by
a location, or create a timezone record that reflects that history? And
identifying that is where a longer name may result.

---

From: Paul Eggert <[email-masked]>
Date: Fri, 22 Aug 2014 08:02:04 -0700

Lester Caine wrote:
> This is still
> of the time data.

The tz database does record these changes when we're given reliable 
sources for them.  So, for example, when Mercer County, North Dakota 
switched from US mountain to US central time, release 2011b of the tz 
database added a zone America/North_Dakota/Beulah that covers just that 
one county.

In the long run I suspect this approach may not scale, though, which is 
perhaps your point.  It might be better to have one database that 
records timekeeping practices for time zones (e.g., US mountain time and 
US mountain standard time would be two entries in this database) and 
another database that maps (location, UTC time stamp) pairs to time zone 
names, instead of tz's current approach that attempts to do both things 
at once.  That'd be a big change, though, and one outside the scope of 
the current draft.

---

From: Lester Caine <[email-masked]>
Date: Fri, 22 Aug 2014 19:28:23 +0100

> at once.  That'd be a big change, though, and one outside the scope of

I think this is sort of where I am getting.

The 'rule' sections form a smaller subset of information, and in order
to handle the 'changedsince' filtering, the history of changes needs to
be logged in the server ... I think on a rule by rule basis. Then
timezones use a combination of rules to build a specific timezone
sequence again with a version control log which provides the
'changedsince' data? As you say this may  not scale well especially when
one starts adding pre 1970 data which as we have agreed in the past is
more a case of location specific changes than particularly timezone
changes.

The problem with the current draft is that it does totally avoid the
underlying problems and tends to assume that there IS a clean simple
database that is the basis for all of this. Something which does not
actually exist. Even limiting the initial spec to just post 1970 data
will still leave a few areas where the tz data is quite complex?

I have the change log of tzdata since day one but that is not in a
usable format and while we will start with a particular release of tz as
the base for tzdata, this history allows testing of the 'changedsince'
and updating process. Since tzdist allows for multiple data sources, I
would expect a server to restrict it's service to a single source, but
checking for differences in data between sources is something that
should also be tracked.

---

From: Tim Parenti <[email-masked]>
Date: Fri, 22 Aug 2014 14:47:56 -0400

On 22 August 2014 11:02, Paul Eggert <[email-masked]> wrote:

> It might be better to have one database that records timekeeping practices
> for time zones (e.g., US mountain time and US mountain standard time would
> be two entries in this database) and another database that maps (location,
> UTC time stamp) pairs to time zone names, instead of tz's current approach
> that attempts to do both things at once.  That'd be a big change, though,
> and one outside the scope of the current draft.

Andy Lipscomb proposed an "extended" notation for the tz database last
year, which I think would aim to move tz maintenance in such a direction:

http://mm.icann.org/pipermail/tz/2013-September/019952.html

But I agree that's ultimately a job for tz, and is out-of-scope for
tzdist.  If, say, zic is updated to implement this, tzdist implementations
should still be able to extract the relevant data and expose it via their
APIs.

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Fri, 22 Aug 2014 20:31:40 +0100

On 22/08/14 19:47, Tim Parenti wrote:
> tzdist.  If, say, zic is updated to implement this, tzdist
> implementations should still be able to extract the relevant data and
> expose it via their APIs.

The original discussion on removing all pre 1970 data from tz was
eventually reversed, but the result is not a reliable compromise. While
tzdist can be built today with an integral default truncation of 1970,
and earlier data can still be included when providing a genealogically
correct server, some data is not a simple 'yes/no'. Rather a 'maybe' and
it's the management of the level of uncertainty that is integral in
genealogical data, which will also affect the timezone information that
goes with it.

My own concern is simply that if the zdist system is ONLY producing data
post 1970, then what does a user who needs earlier information use when
tzdist fails to provide a result?

---

From: Tim Parenti <[email-masked]>
Date: Fri, 22 Aug 2014 16:10:36 -0400

> tzdist fails to provide a result?

I think that falls to the user to ensure they're using a tzdist source that
provides historical data as far back as their needs dictate.
Hypothetically, different tzdist servers will fill different niches in this
space.

The tzdist protocol can help by issuing clear responses when data that has
been truncated is requested.  For example, a tzdist server which only
provides data since 1970 should give an unambiguous and helpful response if
a user requests data from, say, 1955.  Perhaps for a particular user's
use-case, they might then attempt to poll another tzdist server for this
information.  (I haven't had time to look over the drafts to see if this is
already covered somehow.)

--
Tim Parenti

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 22 Aug 2014 16:34:57 -0400

Hi Lester,

> tzdist fails to provide a result?

Assuming that there is a time zone data publisher who has that information 
to the degree of accuracy needed, then the user either gets that raw data, 
or persuades someone else to run a tzdist server serving up that 
publisher's set of data.

i.e., the user is not beholden to any one provider - if they don't like 
what they get from one tzdist server, they can go find another that gives 
them what they want.

On the issue of "history": I don't think any one really cares about what 
the TZDB looked like, say a year ago. What really counts is the current 
state reflecting the known past observances for a particular timezone. How 
our understanding of those observances have changed over time is something 
the publisher can can maintain in their notes, but that does not need 
exposure in tzdist.

I also want to clarify the purpose of "dtstamp" and "changedsince": those 
are purely elements of the protocol and have no relation to the actual tz 
data. They represent changes made to the underlying HTTP resources so that 
clients need only download those resources which have actually changed. 
Thus the "dtstamp" is governed by when the server updated its copy of the 
data as opposed to when the publisher published a new version of the data. 
If those attributes need better clarification we can update Section 4.1.3 
in the draft to try and do that.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Fri, 22 Aug 2014 17:18:43 -0400

Hi Tim,

On 08/22/2014 04:10 PM, Tim Parenti wrote:
>
> On 22 August 2014 15:31, Lester Caine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> I think that falls to the user to ensure they're using a tzdist source 
> that provides historical data as far back as their needs dictate.  
> Hypothetically, different tzdist servers will fill different niches in 
> this space.
>
> The tzdist protocol can help by issuing clear responses when data that 
> has been truncated is requested.  For example, a tzdist server which 
> only provides data since 1970 should give an unambiguous and helpful 
> response if a user requests data from, say, 1955.  Perhaps for a 
> particular user's use-case, they might then attempt to poll another 
> tzdist server for this information.  (I haven't had time to look over 
> the drafts to see if this is already covered somehow.)
>

The tzdist protocol already has the ability to announce whether it can 
serve truncated or untruncated data in its capabilities document.  The 
example given in the draft shows this "info" object:

      "info": {
        "primary-source": "Olson:2011m",
        "truncate" : {
          "any": false,
          "years": [1970, 2000, 2010],
          "untruncated": true
        },
        "contacts": ["mailto:[email-masked]"]
      },

This means that the server can serve up untruncated data (presumably 
back to 1883 or as far back as the Olson data goes), or data truncated 
at 1970, 2000, or 2010 (as requested by the client).  If the "any" 
feature were "true" that would mean that the server could truncate the 
data at any client requested year.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Fri, 22 Aug 2014 22:38:58 +0100

On 22/08/14 21:34, Cyrus Daboo wrote:
> I also want to clarify the purpose of "dtstamp" and "changedsince":
> those are purely elements of the protocol and have no relation to the
> actual tz data. They represent changes made to the underlying HTTP
> resources so that clients need only download those resources which have
> actually changed. Thus the "dtstamp" is governed by when the server
> updated its copy of the data as opposed to when the publisher published
> a new version of the data. If those attributes need better clarification
> we can update Section 4.1.3 in the draft to try and do that.

One of my interests here is to provide a suitable server for historic
data, which is why I'm getting involved. Maintaining a reliable source
of data is the first problem, and ensuring the users have the correct
material with the correct provenance and range of certainty is the next.

If I provide a user with a result today and they archive that data, they
have the 'dtstamp' for today. A second user reads the data in a weeks
time, but it has changed due to a change to the timezone data so they
get a 'dtstamp' tagging the modified version. If the first user then
asks if his data has 'changedsince' the first date, they will get a yes
and the new data while the second user will get a no. The only reason
the 'underlying HTTP resources' have changed is due to a change which
MAY result in the data the user is working with changing from the first
use. They will have to assess if the information created on the first
visit now needs to be updated, and carry out any additional work
required as a result. tzdist MUST be able to provide this type of update
information, but since the data being returned may be truncated and
different truncations may or may not have changed for different users,
calculating 'changedsince' data requires a complex comparison which may
involve a number of updates in the intervening period ... which might
even mean that there has not actually been a change to the ORIGINAL
result if some intermediate result has been rolled back, but results
returned during the 'faulty' period will require one.

Yes 'dtstamp' is a version stamp for the server, but the provenance of
the data used for that update would be identified against the publisher.
The requested 'changedsince' value could be several versions behind the
current version and each version needs to be maintained in the server in
order to correctly respond. It would be possible to simply respond that
there has been a change even if that does not ACTUALLY apply to the
truncated view originally requested, but I don't think that would be the
ideal way of working when feeding light clients? We should 'no change'
any truncated views that have not changed?

---

From: Lester Caine <[email-masked]>
Date: Fri, 22 Aug 2014 22:52:43 +0100

On 22/08/14 22:18, Ken Murchison wrote:
> back to 1883 or as far back as the Olson data goes)

Why 1883?
This is the problem since the data we have has a variable range of
detail, this is different for the majority of timezones, and certainly
dates go back beyond 1883 so how does one respond when a request drops
off the actual start date of a timezone? This may be an LMT period which
is required to make the tz data work, but it may not be the timezone so
do we say 'invalid-start', 'invalid-tzid' or better  return a 'truncate'
date of the start of the timezone?

---

From: Tim Parenti <[email-masked]>
Date: Sat, 23 Aug 2014 00:36:18 -0400

On 22 August 2014 17:18, Ken Murchison <[email-masked]> wrote:

> serve truncated or untruncated data in its capabilities document.

I think we may be speaking about slightly different concerns here.  Given
the example in
http://tools.ietf.org/html/draft-douglass-timezone-service-11#section-5.9
representing a server that can only return data truncated at 1970...

   truncated: {
     "any": false,
     "years": [1970],
     "untruncated": false
   }

What is the behavior when a client requests data from 1960?  It seems to me
that this should be an error response which reminds the client to
double-check the restrictions on the data available.

What is the behavior when a client requests data be truncated at 1980?  Is
this an error, too?  Is the 1970-truncated data (the smallest available
superset of the requested data) sent anyway, leaving the client expected to
work out whether to throw the unneeded bits away?  Or does the server take
the 1970-truncated data and re-truncate it at 1980 before sending a
response?  (I personally think that it should be one of the last two.)

Moreover, though, I think the concern raised by Lester has more to do with
the granularity of this truncation.  Say I'm a tzdist server and I want to
share high-quality data I have going back to 1900 for certain zones; but
for all other zones, I have no data prior to 1970.  (In practice, the
"start dates" for real data are far more numerous than two.)  How should I
convey what's available here?  If I declare "years": [1900, 1970], a client
will assume I have full data from 1900, and may request some pre-1970 data
which I don't have.  How implementations should handle this entire process
seems ill-defined, and so perhaps truncation might be more appropriately
(or optionally) handled on a per-zone basis.  There are likely many ways
this could be introduced into the protocol.

Lastly, it seems the "untruncated" parameter is merely a flag for a
server's default behavior, which looks alright in theory... but in practice
all data is truncated (and often messily), even if the first entry is, say
LMT beginning with the Big Bang.  (Unless, of course, we include a separate
entry in responses indicating a specific value to be used from the first
"real" entry backwards into negative-infinity.  But this rapidly becomes
devoid of meaning.)

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Sat, 23 Aug 2014 08:44:22 +0100

On 23/08/14 05:36, Tim Parenti wrote:
> server's default behavior, which looks alright in theory... but in
> practice all data is truncated (and often messily), even if the first
> entry is, say LMT beginning with the Big Bang.  (Unless, of course, we
> include a separate entry in responses indicating a specific value to be
> used from the first "real" entry backwards into negative-infinity.  But
> this rapidly becomes devoid of meaning.)

That is perhaps a good overview.

My own interest started when reviewing the material that tz was serving
up and then finding the holes. The 'solution' proposed by Paul was to
simply kill all pre 1970 data but there was unsurprisingly a backlash to
that and the compromise has been to move material prior to 1970 into
'backzone' a additional set of historic material, but only a day ago
additional material for Madras arrived on tz. Paul has tagged this
'pre1970' but a clarification is that there is insufficient information
to update backzone. MY view is that this is just the sort of provenance
that adds doubt to what is currently served up and users need some
indication to that ...
Correctly managed, this information should hopefully allow further local
input to fill in the missing information!

There is no doubt that a lot of history has been lost, but what is
available should not be ignored simply because it's too difficult to
maintain. If tzdist is providing that data it needs the ability to
handle the problems as well, even if providing historic dates is
optional. 'Start-date' for a timezone is perhaps a valid piece of
information, but also is 'assumed' where gaps in the data exist. Paul
has done a thankless job removing suspect provenance but quite rightly
he does not want to research every point himself.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Aug 2014 12:04:36 +0200

Hi Lester,

> date of the start of the timezone?

Again, I'd suggest others chime in, but this is probably
database-specific, and so the best that one can do is either indicate an
error if there is no data for that period, as there may be for some time
zones, or provide LMT (or any other information), and let the client
interpret the result just as if it  had made use of localtime() with the
information in a file.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Mon, 25 Aug 2014 13:19:20 +0100

> interpret the result just as if it  had made use of localtime() with the

Looking at the information coming back from the current test server,
while not reliable, the earliest DTSTART date in the VTIMEZONE can be
used as a start date for the timezone. It would be nice if that element
was provided in the 'list' return and then it is a matter of how an
access prior to the start date of that timezone is returned? We do have
a TZOFFSETFROM for the prior offset, which is the default tz itself
uses, but some tag that this is a period where location rather than this
average would be more accurate. For some zones, the first transition is
to a 'local' LMT time rather than a GMT based timezone and I think this
can be identified by the TZNAME.

Thinking aloud, TZNAME gets bounced to the "name" field in expand, so
pre-timezone entries there just need a suitable TAG. The problem that
exists with some of that area is that there is often disagreement as to
what the shorthand name should be. The same initials pop up in different
parts of the world, so something cleanly identifiable. A simple 'Local'
comes to mind.

---

From: Lester Caine <[email-masked]>
Date: Mon, 25 Aug 2014 13:28:32 +0100

> parts of the world, so something cleanly identifiable. A simple 'Local'

Checking 'New York' on the demo server actually highlights the error there.
    {
      "onset":"1870-01-01T00:00:00",
      "name":"EST",

But EST did not get created until 1883, so that should be something else
prior to the tz data starting ...

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 25 Aug 2014 11:09:11 -0400

Hi Lester,

--On August 25, 2014 at 1:28:32 PM +0100 Lester Caine <[email-masked]> 
wrote:

> Checking 'New York' on the demo server actually highlights the error
> there.     {

OK, yes. The spec should make it clear that when truncation or expansion is 
done using a start date prior to the first valid observance of a time zone 
(1883 in the case of America/New_York), that the first observance in the 
returned data should be the first valid observance, not a "fake" one 
inserted at the truncation date (as is currently suggested by the 3rd 
paragraph of Section 3.4).

I'll look into fixing my implementation to properly handle that, and I'll 
make sure we have that on our list of things to test at the next CalConnect 
interop event. Several implementors are using a common test suite for their 
CalDAV products and we have extended that to also test the tzdist protocol. 
I will also add some tests to that to cover the proper truncation/expand 
prior to first valid observance behavior.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Mon, 25 Aug 2014 17:42:57 +0100

On 25/08/14 16:27, Eliot Lear wrote:
> Lester, with this matter being taken on board, are you able to withdraw
> your objection?

I am now seeing the holes better, and have now nailed down where the
race hazards are in the current draft which I think have now been
identified. If it is intended that the first step is to rework
draft-douglass-timezone-service with the necessary changes already
identified then we are not exactly accepting the current draft anyway?

Root Providers would ideally provide all available information so that
local providers are not hamstrung before they start? I now think that
VTIMEZONE could support replicating all the source data, but I still
don't feel this is the ideal way of working. I think I would probably be
recomending that ISP's worked direct from the publisher level and create
their own master servers rather than relying on other root servers? If a
number of short notice changes arise, then the entries in 'list' AND the
VTIMEZONE data all needs to be in sync? If one updates before the other
there is a problem? But how does one ensure that happens?