Subject: [Tzdist] Last Call: <draft-ietf-tzdist-service-08.txt> (Time Zone Data Distribution Service) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 03 Jun 2015 11:21:16 -0700

The IESG has received a request from the Time Zone Data Distribution
Service WG (tzdist) to consider the following document:
- 'Time Zone Data Distribution Service'
  <draft-ietf-tzdist-service-08.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 2015-06-17. 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 a time zone data distribution service that
   allows reliable, secure and fast delivery of time zone data and leap
   second rules to client systems such as calendaring and scheduling
   applications or operating systems.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 17 Jun 2015 15:17:46 -0300

On 3 Jun 2015, at 15:21, The IESG wrote:

> The IESG has received a request from the Time Zone Data Distribution Service WG (tzdist) to consider the following document:
> 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 2015-06-17. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

I have two comments that neither should be blocking for this draft to be published, but I encourage IETF/IAB to take the issues serious because one day we will be bitten by this. I have been following the evolution of this since I was Area Director and while I think the tzdist work is something that should have been done from day one of the iCal work, I do not think we are done yet.

Good: Personally I have been pushing for not having TZ definitions in the events themselves, but instead have then referenced since the iCal spec was an I-D. In those days, I was in the rough side of rough consensus, so it is good to see things go in the right directions at last :-)

Steps for improvement: The references to the timezones is by the TZID, and that is good, but I think most parties when deciding on an event pin it to a geographical location, like city/country or so in some combination. Because of this I think ultimately a reference should be in the form of a location that the tzid service should be able to resolve to the correct TZ definition (i.e. time + location gives TZ definition).

Worrying, but IETF seems unable to resolve this issue, so maybe there is not much we can do: How to find what URIs to use to fetch data.

We have in IETF initiatives that include TXT RR, DDDS resolution using NAPTR (and variants thereof), SRV, other specialized RR Types in DNS, "well known URI", the URI RR and what not. I have on request from various parties first developed the DDDS things with ENUM, then when people felt that was too complicated I did the URI RR, which people say is "interesting" (and implement). At the same time some WGs do use TXT records (because implementing a new RR Type "is too hard"), while people that use HTTP seem to rather go down the path of "well known URI" together with in some cases SRV. And then we have "happy eyeballs" on top of that for IPv6 and IPv4 resolution. And then DANE.

So, is this draft specifying the right thing? Possibly...

*I* think URI RR Type would be better than SRV + Well known URI, but that is me. Others say that is not possible due to javascript inability to query for weird RR Types.

At least it seems we get SRV+"Well known uri" instead of TXT, but...

Any taker on looking seriously on a HappyEyeballs2.0 spec?

Maybe the first document should only just define the landscape? And most of this might be done based on what for example Paul Hoffman and others have done with the "New DNS Library Work"?

To conclude: this draft rises many thoughts in my head, but nothing that should be blocking factors for *this* draft.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Jun 2015 22:11:10 +0200

Hi Patrik,

Just a question on one of your two points:

> Steps for improvement: The references to the timezones is by the TZID, and that is good, but I think most parties when deciding on an event pin it to a geographical location, like city/country or s…

How do you want user-facing client behavior to change?  I'm not sure I
see that.

Thanks,

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 17 Jun 2015 17:14:43 -0300

> How do you want user-facing client behavior to change?  I'm not sure I

Many clients do today ask where the event takes place. One select timezone based on a city, or location. I want that location I choose in the client to stay in the calendar object. Not be translated to some TZid (and now to a TZ definition that is inserted in the object).

So, yes, having TZID in the object is a BIG step forward, the most important one.

The next is to for example be able to have the address of a physical event both as location for the event and as pointer into a TZ database.

Once again, tzdist is The Key Thing, that I have waited for.

The rest is just implementation and agreement on what you can use for lookups.

   Patrik

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 Jun 2015 16:58:33 -0400

Hi Patrik,

--On June 17, 2015 at 5:14:43 PM -0300 Patrik Fältström <[email-masked]> 
wrote:

> Many clients do today ask where the event takes place. One select
> timezone based on a city, or location. I want that location I choose in
> the client to stay in the calendar object. Not be translated to some TZid
> (and now to a TZ definition that is inserted in the object).
>
> The next is to for example be able to have the address of a physical
> event both as location for the event and as pointer into a TZ database.
>

I think this boils down to changing the set of time zone identifiers that 
clients use from the current IANA tzdb set, to a more dynamic city/country 
code. That is certainly much more feasible to do once we start getting 
clients and servers using tzdist, because the tzdist server could manage .

We have also talked about implementing a geo->tzid mapping action in tzdist 
as an extension. That would probably be a good first step along the road to 
getting to where we want to be.

-- 
Cyrus Daboo