Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
draft-ietf-tzdist-caldav-timezone-ref-05

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

(Barry Leiba; former steering group member) Yes

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 steering group member) Yes

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 steering group member) No Objection

(Alissa Cooper; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

(Deborah Brungard; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Kathleen Moriarty; former steering group member) No Objection

I will follow along with the discussion around Stephen's comments, I don't have any others to add for security.

(Martin Stiemerling; former steering group member) No Objection

(Spencer Dawkins; former steering group member) No Objection

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 steering group member) No Objection

- 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 steering group member) No Objection