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

[Ballot comment]

- 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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

1.  Summary
This document is "CalDAV: Time Zones by Reference" from C. Daboo.  The
Working Group is TZDIST. The document shepherd is Eliot Lear. The
responsible Area Director is Barry Leiba.

This document specifies changes to the CalDAV protocol that enables
clients and servers to not have to exchange VTIMEZONE infromation, but
instead make use of tzdist servers.

2.  Review and Consensus
An issue tracker was maintained and all open issues have been
resolved.  This draft enjoys support from the WG, although there are
fewer interested parties when it comes to caldav.

One significant issue came up during AD Evaluation with respect to
the use of the "Prefer:" header field.  The result of the discussion was
to remove the use of "Prefer:" (which is non-deterministic) and to
replace it with the definition of a new header field, "CalDAV-Timezones",
to control whether the server will return timezone information or
whether the client expects to obtain that on its own through this
protocol.  The only point of disagreement here concerned the default,
and the clear decision of the working group, based on existing deployment
expectations, was for the default to be the latter, a change from current
behaviour.

3. Intellectual Property
The author has stated that he is unaware of any IPR claims against the
draft.  No discussion about any existing IPR took place in the working
group.

4. Other Notes
None.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tzdist-caldav-timezone-ref-04. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Permanent Message Header Field Names registry of the Message Headers registry located at:

https://www.iana.org/assignments/message-headers/

a new registration is to be made as follows:

Header Field Name: CalDAV-Timezones
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CalDAV: Time Zones by Reference) to Proposed Standard


The IESG has received a request from the Time Zone Data Distribution
Service WG (tzdist) to consider the following document:
- 'CalDAV: Time Zones by Reference'
  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@ietf.org mailing lists by 2015-09-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to the CalDAV calendar access
  protocol (RFC 4791) to allow clients and servers to exchange
  iCalendar data without the need to send full time zone data.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-timezone-ref/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-timezone-ref/ballot/


No IPR declarations have been submitted directly on this I-D.

1.  Summary
This document is "CalDAV: Time Zones by Reference" from C. Daboo.  The
Working Group is TZDIST. The document shepherd is Eliot Lear. The
responsible Area Director is Barry Leiba.

This document specifies changes to the CalDAV protocol that enables
clients and servers to not have to exchange VTIMEZONE infromation, but
instead make use of tzdist servers.

2.  Review and Consensus

An issue tracker was maintained and all open issues have been
resolved.  This draft enjoys support from the WG, although there are
fewer interested parties when it comes to caldav.  A review of the
Prefer: header request is in progress.

c) Intellectual Property

The author has stated that he is unaware of any IPR claims against the
draft.  No discussion about any existing IPR took place in the working
group.


Other)

No nits were found.

1.  Summary
This document is "CalDAV: Time Zones by Reference" from C. Daboo.  The
Working Group is TZDIST. The document shepherd is Daniel Migault. The
responsible Area Director is Barry Leiba.

This document specifies changes to the CalDAV protocol that enables
clients and servers to not have to exchange VTIMEZONE infromation, but
instead make use of tzdist servers.

2.  Review and Consensus

An issue tracker was maintained and all open issues have been
resolved.  This draft enjoys support from the WG, although there are
fewer interested parties when it comes to caldav.  A review of the
Prefer: header request is in progress.

c) Intellectual Property

The author has stated that he is unaware of any IPR claims against the
draft.  No discussion about any existing IPR took place in the working
group.


Other)

No nits were found.