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

["Patrik Fältström " <[e-mail]>]

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:
> - '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 [e-mail] mailing lists by 2015-06-17. Exceptionally, comments may be sent to [e-mail] 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