Subject: [apps-discuss] timezone database maintenance

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Mar 2011 09:45:35 -0700

Dear Apps Folks,

We need to finish our work on draft-lear-iana-timezone-database and
decide if we will pursue the approach outlined in that document, so that
Mr. David Olson (maintainer of the timezone database) can work for a
while within the new processes before starting his well-deserved retirement.

I plan to issue an IETF Last Call on that I-D soon after IETF 80. To
expedite the conversation, I encourage those who care about future
management of the timezone database to weigh in on the apps-discuss
list. In addition, I have reserved a room from 08:00 to 09:00 on
Wednesday, March 30 at the IETF meeting in Prague, so please add that
time slot to your calendar if you wish to participate.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 03 Mar 2011 11:58:55 -0500

comments:

A) XML IANA
- IANA has been converting its "old" registries to XML native format.
- for new registries, XML is used as native format.
- TZ database has its own format.
- wonder if it would be relevant to have IANA do the registry in XML (as 
others and to be managed by the same tools) and then convert to the TZ 
database format.

B) draft shall be updated before IETF last call on the warning of 
community concensus. ie.
"ATTENTION: This memo contains a DRAFT proposal for the IANA to assume
    operational responsibilities relating to the management of the
    Timezone (TZ) Database.  The authors seek comment and review of this
    proposal.  No action will be taken without rough consensus of the TZ
    community."

Should be either changed, updated or removed.

C) Reference code.

I'm not sure IANA is the right place to archive software code.  why not 
have a separate web site/sourceforge/google code/... place for managing 
this?

Marc.

Le 11-03-03 11:45, Peter Saint-Andre a écrit :
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 03 Mar 2011 12:26:53 -0500

Hi Marc,

> others and to be managed by the same tools) and then convert to the TZ

CalConnect has been working on an XML representation for timezone data, but 
I think it is fair to say at this time we consider this premature. One of 
the key things CalConnect wants to do is promote use of a Timezone Service 
protocol (draft-douglass-timezone-service about to be updated) to allow for 
timely, secure, reliable update of timezone information. Right now that is 
focussed primarily on iCalendar timezone data, but we intend to allow it to 
be used by anyone that needs timezone information, including OS's (i.e. 
allow "live" updates to zoneinfo files rather than requiring OS 'patches').

What I think we need to do now is treat the Olson data format as 
"normative" and then work on defining a solid XML representation (with 
hopefully a straightforward mapping to Olson data). We can then make that 
available as an alternative format and allow tools to adopt it, and once we 
have good adoption then move to have that be the normative format. However, 
that is something that will need more time to develop than I think we have 
before we need IANA to start managing the Olson process (given what I know 
about the length of the IETF process).

> have a separate web site/sourceforge/google code/... place for managing

That would probably need additional text describing how that is managed 
(who has commit rights, how would those be administered/changed etc) and 
would be a significant change to the current Olson process. It may be 
reasonable to put the code up on a source site, but if we do that, I do 
think it is important that appropriate "snapshots" be tied to the updates 
to the IANA data - so I still think IANA ought to maintain a tarball of the 
code appropriate to the actual data.

-- 
Cyrus Daboo

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 19:14:23 +0000

The current draft looks pretty good to me. A few small questions:

Is the shouty mustard supposed to mean anything different from normal
English usage?

Section 3:

The word "key" is used to mean both a cryptographic key and a TZ name.
Is there a reason for not using the term "TZ name" or "time zone name"?

Section 6:

Should it be made clear in this section that contributions to the code are
presumed to be in the public domain or under equivalently liberal
licencing terms whether or not the contributions are made via the mailing
list? Or is section 7 enough?

Sections 7 and 8:

Should "database" be expanded to "database and reference code" throughout?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northeast 5 to 7. Moderate or rough. Showers. Good.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Mar 2011 20:22:23 +0100

Tony, Marc, Cyrus,

Thank you for your comments.

> Is the shouty mustard supposed to mean anything different from normal

I searched the draft but couldn't find shouty mustard ;-)  I'd gladly
accept editorial changes to improve language though.  No need to send
those to the list.
> Is there a reason for not using the term "TZ name" or "time zone name"?

No.  There is not.  I will go with TZ name and define it above.

> list? Or is section 7 enough?

And this goes to Marc's point C) as well.  The goal here is to assume
the current responsibilities of the TZ coordinator which includes some
code.  The database itself is in the public domain.  So is much of the
code, but not all.  Thus there is a distinction.
> Should "database" be expanded to "database and reference code" throughout?

I'll review each use, but there are some differences as I noted.

> A) XML IANA 

The database is currently sucked down and used by many many companies,
and it must be maintained in its current form.  New forms are fine. 
Even new normative forms! But this form can't go away.
> B) draft shall be updated before IETF last call on the warning of
Indeed.  Will remove.

Thank you again for your contributions!

Eliot

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 03 Mar 2011 14:28:34 -0500

Le 11-03-03 14:22, Eliot Lear a écrit :
> and it must be maintained in its current form.

I know.

>  New forms are fine.

  What I was trying to say is the following:
- IANA do keep the data in native XML format
- IANA converts XML native to the current file format.
- both formats are available from IANA web sites and are in sync.

that way, IANA continues with its XML infrastructure and have the TZ 
community keep the same file format as before.

Marc.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 19:47:48 +0000

> code, but not all.  Thus there is a distinction.

Right. But it gets very complicated if you try to say that if a
contributor is making a contribution to the Berkeley licenced code then
their licence must also be Berkeley licenced but not otherwise. Do they
get to add their copyright line to the Berkeley code? etc.

If all contributions are unambigously public domain then they can be
freely added to the existing code regardless of the existing code's
licence.

So I'm making a distinction between the licence in contributions and the
licence of the (parts of) the collaborative work as a whole.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: Variable 3 or 4, becoming southwesterly 5 for a time in northwest
Rockall. Moderate or rough. Occasional rain or drizzle. Moderate, occasionally
poor.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 03 Mar 2011 14:49:49 -0500

> licence of the (parts of) the collaborative work as a whole.

I continue to think that archiving and managing software should not be 
done by IANA, but some third party over a forge site.

Marc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Mar 2011 14:22:36 -0700

<hat type='individual'/>

(Or should that be <hat type='none'/>, I wonder...)

> community keep the same file format as before.

Based on the comments from Cyrus [1], it sounds as if that is a good
goal, but that we might not achieve it right away because of the
complexities of modeling this data in XML.

BTW, I know that Michelle Cotton from IANA plans to participate in the
side meeting we'll hold about the timezone database (currently planned
for the morning of Wednesday, March 30, 08:00-09:00), so her input will
be very helpful. I've cc'd her on this message so that she's aware of
this discussion, with threads starting at [2] and [3].

/psa

[1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02303.html

[2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02301.html

[3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02304.html