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
ietf(_at_)ietf(_dot_)org mailing lists by 2015-06-17. Exceptionally, comments
may be sent to iesg(_at_)ietf(_dot_)org 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
signature.asc
Description: OpenPGP digital signature