Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
draft-ietf-tzdist-caldav-timezone-ref-05
Yes
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 04 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2015-09-22 for -04)
Unknown
Note the discussion in the shepherd writeup about the default value for "CalDAV-Timezones". The document specifies the working group's clear consensus to use a default that changes current behaviour.
Ben Campbell Former IESG member
Yes
Yes
(2015-09-29 for -04)
Unknown
Abstract: Is this an extension of 4791, or an update? The abstract says "extends", but the draft has an "Updates:" header. (I suspect from some of the behavior, this truly is an update.) Should the titles of 3.1.5 and 3.1.6 say "Support _of_ Time Zone Identifiers..." The security considerations say this adds no new considerations beyond those in CalDAV and iCalendar. It seems to me that adding an out-of-band mechanism to get TZ info from third parties would add some considerations. Perhaps this should reference the security and privacy considerations from ietf-tzdist-service? It's already a normative reference.
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-09-30 for -04)
Unknown
I will follow along with the discussion around Stephen's comments, I don't have any others to add for security.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-09-28 for -04)
Unknown
Is the last sentence in this paragraph truncated?
3. Clients can expect servers not to include standard time zone
definitions in any iCalendar data they receive from the server,
if there is no "CalDAV-Timezones" request header field in the
HTTP request. Clients MUST retrieve standard time zone
definitions from the set of time zone distribution servers
advertised by the CalDAV server (see Section 3.1.2), or a known.
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-09-30 for -04)
Unknown
- 3.1.2: The tzdist protocol says clients SHOULD use TLS. A question then is ought servers here (be able to) include trust point information for tzdist for the service in question when they tell a client to use a particular tzdist service? - Given the three points below, maybe it is worth specifying some 'background' kind of traffic to be sent between client and tzdist services? What do you think? - section 4, point 5: that seems onerous - is a client supposed to retrieve all known timezones from all servers? What if/when those change? - section 8: missing privacy issue: if I create an event using a weird TZ and can see who accesses the tzdist service, then I can find out who is subscribed to some calendars maybe. Worth noting? I don't see what can be done about it, except maybe to ask clients to occasionally make a random query to the tzdist service just to confuse matters, but that'd also have downsides if not done well. - section 8: missing security issue: if a lot of clients are fetching this information from a tzdist server, then that becomes an interesting thing to attack as the consequences could be significant. Maybe worth noting just to encourage folks to (document their code so as to get others to) think about this when deploying.
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown