Subject: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist)

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jun 2014 11:06:51 -0400

Cyrus Daboo has proposed a new working group in the Applications Area,
and I'm initiating charter discussion on it:

https://datatracker.ietf.org/doc/charter-ietf-tzdist/

We'll have the charter discussion here on apps-discuss.  Assuming a
working group comes out of this, we'll create a new mailing list for
the actual work, once the charter is done.

Comments on this charter are welcome.  I expect to put it on the 10
July IESG telechat for initial approval, after which it will go out
for IETF and external review.  So, comments here by 4 July, please.

Barry, Applications AD

---

From: Franck Martin <[email-masked]>
Date: Fri, 20 Jun 2014 15:24:52 -0500 (CDT)

----- Original Message -----
> From: "Barry Leiba" <[email-masked]>
> To: "Apps Discuss" <[email-masked]>
> Sent: Friday, June 20, 2014 8:06:51 AM
> Subject: [apps-discuss] Proposed working group: Timezone Data Distribution	Service (tzdist)
> 

About time....

I used to live in a country, where they would announce timezone changes like 2 weeks in advance, twice a year, every year...

In light of the ntp leap second propagation saga, it would be nice to consider the protocol to be able to work in a multi-tiered environment with out of band messaging.

I mean, before a change is disseminated to a system, there is the possibility to review and approve such change. I wonder if the charter should mention this architecture design, or just indicate the architecture should allow controlled dissemination of changes within a network sub-system.

Finally, I hope the protocol is DoS and DDoS robust.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 Jun 2014 21:07:45 -0400

Hi Franck,

--On June 20, 2014 at 3:24:52 PM -0500 Franck Martin 
<[email-masked]> wrote:

> I used to live in a country, where they would announce timezone changes
> like 2 weeks in advance, twice a year, every year...
>
> In light of the ntp leap second propagation saga, it would be nice to
> consider the protocol to be able to work in a multi-tiered environment
> with out of band messaging.
>
> I mean, before a change is disseminated to a system, there is the
> possibility to review and approve such change. I wonder if the charter
> should mention this architecture design, or just indicate the
> architecture should allow controlled dissemination of changes within a
> network sub-system.
>

draft-douglass-timezone-service is meant as a starting point for any WG 
work. The protocol we defined there is HTTP based (several reasons for that 
choice that can be discussed in the WG).

That document does have an architecture diagram that introduces the 
concepts of contributors, publishers, providers and clients. In the current 
scheme of things, the first two of those would map to: IANA timezone list 
subscribers who post messages about tz changes in their locale 
(contributors), the IANA tz DB itself (publisher).

Anyone running the timezone data distribution server can act as a "primary" 
or "secondary" - with secondary servers typically use within a LAN for 
performance etc. So I think we have captured some of what you are after in 
that initial spec.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Sat, 21 Jun 2014 06:40:55 +0200

Barry,

One issue:

If there is the possibility of multiple sources of naming of timezones,
then there needs to be a way to differentiate those sources, and so
naming cannot be entirely out of scope.  Rather, the scope should be
limited to differentiating the sources.

Also, if there is to be a conversion from Olson to this, we should
determine who is responsible for that conversion.

Eliot

On 6/20/14, 5:06 PM, Barry Leiba wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Jun 2014 06:31:29 +0100

I ask what is intended with the following words in the charter:

> - The timezone data distribution protocol should be "web friendly" to
> allow browser-based calendar clients easy access to the data and API.

The reason why I ask is because there are a number of issues in the current I-D which I do believe is sub-optimal, and just must he hashed out. I do though see the text above might be used as arguments to kill such a discussion. I want to know explicitly whether the following discussions are in scope or not, and if they are not, when and how IETF are going to address them as I see big problems with the increased number of specifications that build on these assumptions:

1. Use of SRV records together with HTTP/1.1 referring to "security as in the HTTP specification" (including HTTPS) and not more

Me: I think it could be interesting if this protocol end up explicitly being HTTP/2 using the strengths of HTTP/2

2. Use of TXT resource records in DNS, and "well known paths"

Me: Why is not either a new RR Type defined, or reuse of the URI RR Type given prefixes for the owner is defined in the I-D

3. Use of "free flow JSON" in the result of the GET

Me: Do we know yet how to reference JSON in a normative way? I guess so -- good in that case, and we should do it more -- and maybe look explicitly how to transport JSON in HTTP/2 (see above under 1)

4. Use of "standard HTTP security", is that good enough

Me: Should we not immediately force the data to be digitally signed, and how is that done, is that not something we should look at in a generic way for HTTP/2, i.e. define "if we want to return a signed JSON blob in HTTP/2, this is how to do it" so that it can be reused in more than one specification

Now, this is written far too early in the morning (before coffee), but the overall question is whether those kind of discussions are ok in this wg or whether they should be held elsewhere, and if so, where?

  Patrik

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 21 Jun 2014 09:53:27 -0400

Hi Eliot,

> limited to differentiating the sources.

Yes. I think that is what we were trying to say when indicating that a 
"namespace prefix" mechanism can be considered. Do you think this point in 
the proposed charter needs further clarification:

    - The naming process for timezone identifiers.  The working group can
    consider adding a mechanism, such as a "namespace" prefix, to
    differentiate different timezone sources, but the nature of the timezone
    identifiers used will be controlled by the sources themselves.

> determine who is responsible for that conversion.

I think the intent is that "publishers" will continue to publish timezone 
data in their own format, but the top-level "providers" that use that data 
will be on the hook for the necessary conversions. Right now we are only 
suggesting a conversion to iCalendar to satisfy the immediate needs of the 
calendaring and scheduling folks. However, in the longer term the service 
could also be used to distribute other formats - for example the "zoneinfo" 
files used by many OS's. All that would be needed for that is a suitable 
MIME type (and perhaps a more formal description of the zoneinfo format 
itself).

Obviously there is a security implication from this approach: the IANA data 
is signed as a whole (somewhat unofficially by the TZ coordinator), but the 
individual timezone definitions derived from it won't be signed by the 
same. So clients will need some form of implicit trust in the top-level 
providers who do the conversion. But that does bring up the question of 
whether the derived data pieces should each be signed so that when they are 
delivered by secondary servers, clients can verify they match what the 
top-level provider has (I think this is what Patrik Fältström is 
suggesting in his response (point 4).

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 21 Jun 2014 10:29:49 -0400

Hi Patrik,

--On June 21, 2014 at 6:31:29 AM +0100 Patrik Fältström <[email-masked]> 
wrote:

> The reason why I ask is because there are a number of issues in the
> current I-D which I do believe is sub-optimal, and just must he hashed
> out. I do though see the text above might be used as arguments to kill
> such a discussion.
One of the key use cases here is to support "thin" clients that don't want 
to be bothered with the complexity of expanding recurrence rules and 
exceptions in order to determine local time UTC offsets for arbitrary 
points in time. For those we have the "expand" action that allows them to 
request the server to do the recurrence expansion and send back the offsets 
over a specified range of time. The starting point for this work was the 
discovery of the fact that several web calendar apps actually had their own 
"private" service that did just that.

I think it is important to note that standards-based calendar clients 
(i.e., ones using iCalendar) are predominantly HTTP based - either via 
CalDAV or web. So that does need to be an important consideration.

> I want to know explicitly whether the following
> discussions are in scope or not, and if they are not, when and how IETF
> are going to address them as I see big problems with the increased number
> of specifications that build on these assumptions:

> 1. Use of SRV records together with HTTP/1.1 referring to "security as in
> the HTTP specification" (including HTTPS) and not more
>
> Me: I think it could be interesting if this protocol end up explicitly
> being HTTP/2 using the strengths of HTTP/2

I am not sure I see why this would need to be explicitly tied to HTTP/2, 
versus using either HTTP/1 or HTTP/2. Do we really expect protocols to only 
support HTTP/2 and not HTTP/1 (certainly in the near term)?

> Me: Why is not either a new RR Type defined, or reuse of the URI RR Type
> given prefixes for the owner is defined in the I-D

I have used SRV+TXT/.well-known in RFC6764 - though I think most 
deployments of that have ignored the TXT record and just stuck with 
SRV->.well-known. The following will give examples of that:

dig _caldavs._tcp.google.com srv
dig _caldavs._tcp.icloud.com srv
dig _caldavs._tcp.yahoo.com srv

Of course I am familiar with draft-faltstrom-uri and had that been 
available, and viable from a deployment standpoint, it would probably have 
been the better choice.

> Me: Do we know yet how to reference JSON in a normative way? I guess so
> -- good in that case, and we should do it more -- and maybe look
> explicitly how to transport JSON in HTTP/2 (see above under 1)

Well we do have RFC7159 now, and there is also draft-bray-i-json which may 
be the best option to use.

> Me: Should we not immediately force the data to be digitally signed, and
> how is that done, is that not something we should look at in a generic
> way for HTTP/2, i.e. define "if we want to return a signed JSON blob in
> HTTP/2, this is how to do it" so that it can be reused in more than one
> specification

I think it is probably important for the data to be signed by top-level 
providers so that clients who make use of a secondary provider can be 
assured that the integrity of the data has been preserved. However, there 
may be cases where that is not possible - e.g., a secondary provider whose 
sole use is by "internet of things" clients that only care about present 
and future data - in which case the secondary provider may choose to 
deliver truncated timezone data, with all the (often large) historical 
rules removed.

That said, I am sure there is plenty of scope for making use of JOSE here.

-- 
Cyrus Daboo

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Jun 2014 15:52:18 +0100

> Hi Patrik,

Hi Cyrus!

> --On June 21, 2014 at 6:31:29 AM +0100 Patrik Fältström <[email-masked]> wrote:
> 
> One of the key use cases here is to support "thin" clients that don't want to be bothered with the complexity of expanding recurrence rules and exceptions in order to determine local time UTC offsets for arbitrary points in time. For those we have the "expand" action that allows them to request the server to do the recurrence expansion and send back the offsets over a specified range of time. The starting point for this work was the discovery of the fact that several web calendar apps actually had their own "private" service that did just that.

Understood. The question here is whether this spec should "follow" and only use features that exists on the market today, or "driver" that pushes a good design onto the market.

What I hear you say is that it is to be a "follower".

My point is that I think it is important to know *now* at the time of chartering.

> I think it is important to note that standards-based calendar clients (i.e., ones using iCalendar) are predominantly HTTP based - either via CalDAV or web. So that does need to be an important consideration.

Understood.

> I am not sure I see why this would need to be explicitly tied to HTTP/2, versus using either HTTP/1 or HTTP/2. Do we really expect protocols to only support HTTP/2 and not HTTP/1 (certainly in the near term)?

Agree, but the question is whether a protocol could be optimized for HTTP/2 and then there might be a "backward compatibility" (with lower functionality, not as optimal) for HTTP/1.

> I have used SRV+TXT/.well-known in RFC6764 - though I think most deployments of that have ignored the TXT record and just stuck with SRV->.well-known. The following will give examples of that:
> 
> Of course I am familiar with draft-faltstrom-uri and had that been available, and viable from a deployment standpoint, it would probably have been the better choice.

That draft is blocked by review in the IETF for reasons I am author has no idea why it is blocked. I have requested publication a number of times from our dear AD's.

That said, the Resource Record Type has been registered for quite some time now as Resource Record Types do not need RFCs for registrations.

> Well we do have RFC7159 now, and there is also draft-bray-i-json which may be the best option to use.

Good.

> I think it is probably important for the data to be signed by top-level providers so that clients who make use of a secondary provider can be assured that the integrity of the data has been preserved. However, there may be cases where that is not possible - e.g., a secondary provider whose sole use is by "internet of things" clients that only care about present and future data - in which case the secondary provider may choose to deliver truncated timezone data, with all the (often large) historical rules removed.
> 

Ok.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Jun 2014 13:13:50 +0200

On 6/21/14, 3:53 PM, Cyrus Daboo wrote:
> "namespace prefix" mechanism can be considered. Do you think this
> point in the proposed charter needs further clarification:
>

Perfect.
> I think the intent is that "publishers" will continue to publish
> timezone data in their own format, but the top-level "providers" that
> use that data will be on the hook for the necessary conversions. Right
> now we are only suggesting a conversion to iCalendar to satisfy the
> immediate needs of the calendaring and scheduling folks. However, in
> the longer term the service could also be used to distribute other
> formats - for example the "zoneinfo" files used by many OS's. All that
> would be needed for that is a suitable MIME type (and perhaps a more
> formal description of the zoneinfo format itself).
>
> Obviously there is a security implication from this approach: the IANA
> data is signed as a whole (somewhat unofficially by the TZ
> coordinator), but the individual timezone definitions derived from it
> won't be signed by the same. So clients will need some form of
> implicit trust in the top-level providers who do the conversion. But
> that does bring up the question of whether the derived data pieces
> should each be signed so that when they are delivered by secondary
> servers, clients can verify they match what the top-level provider has
> (I think this is what Patrik Fältström is suggesting in his response
> (point 4).
>

Ok.  So scaling this doesn't fall on IANA's head, nor does IANA have to
publish alternate formats, right?  If so, THAT should be made crystal
clear in the charter.  So should the possibility that this group may ask
for some adjustments to how data is signed by the TZ maintainer, if that
is a possibility.  I'd suggest that the tz list be kept abreast of this.

Also, I am a little concerned about the laundry list of requirements
found in the charter.  In particular:

> - The timezone data distribution protocol should also offer an API to
> allow thin clients to easily make use of timezone data by querying for
> UTC offsets, offloading the sometimes complex work of expanding
> recurrence rules to the service. This API should be extensible to
> support other types of timezone operations in the future.

To be clear, your starting point does not offer an API.  It is amenable
to one, perhaps.  But that won't really be known until there is one.  I
think you really meant "capability" and not "API".  Whether this is the
same or different protocols is IMHO an important design question that
should be decided now, and I'm glad you've asserted a proposal.  In
looking at draft-douglass-timezone-service it requires a pretty fully
understanding of CalDAV.  Is that indeed appropriate for a thin client?

> - The timezone data distribution protocol will initially be targeted at
> iCalendar-based clients, but should be flexible enough to deliver
> timezone data in other formats.

IMHO interoperability demands that this statement be justified.  IMHO
that's a matter for a working group to debate over.

To a lesser extent I have concerns about this statement:

>  The timezone data distribution protocol should be "web friendly" to

This seems to be a "let's do it in JSON" requirement.  IMHO there is
little need for this statement, given the starting point.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 22 Jun 2014 10:48:15 -0400

Hi Eliot,

> is a possibility.  I'd suggest that the tz list be kept abreast of this.

How about adding the following text to the charter's "out of scope" section:

- Any changes to the IANA timezone database process or infrastructure, as 
documented in RFC 6557, other than recommendations for possible security 
enhancements.

> understanding of CalDAV.  Is that indeed appropriate for a thin client?

No - the current draft has no dependency on CalDAV whatsoever - in fact 
CalDAV is not mentioned in the draft at all. 
draft-daboo-caldav-timezone-ref does discuss how to incorporate the 
timezone distribution service into CalDAV to improve performance and 
reliability there.

As I mentioned in a reply to Patrik Fältström, the initial impetus for 
this work came from the discovery that several web calendar implementations 
had written their own timezone service to provide "thin client" timezone 
expansion apis. In addition to improving the overal distribution process, 
providing for such an api should be a key requirement - though as you point 
out there is the possibility it could be decoupled from the distribution 
piece.

> little need for this statement, given the starting point.

OK, that point is probably redundant given the one preceding it, and can be 
removed.

-- 
Cyrus Daboo

---

From: Mark Baker <[email-masked]>
Date: Mon, 23 Jun 2014 19:25:15 -0400

I had a quick look at draft-douglass-timezone-service. While I agree
it makes ample sense to use HTTP for this, and REST as a guide for
doing so (as claimed by the draft), it isn't REST at all as it opts to
use predefined parameters rather than hypermedia. The use of a custom
URI scheme somewhat addresses this issue from a Web architecture POV,
ensuring that only those clients that know of the scheme - and
therefore the parameters - can proceed. But then that's a pretty large
barrier to other non-TZ agents that might want to pull down TZ data,
or even to TZ tools that might want to make use of generic HTTP tools
and libraries like curl/libcurl, XMLHttpRequest, etc..

Depending upon how serious the authors/would-be-group-members are
about using HTTP to maximum benefit, I suppose the charter could call
this out... Just my 2c.