[Tzdist] AD review of draft-ietf-tzdist-caldav-timezone-ref-03

[Barry Leiba <[e-mail]>]

Please excuse the delay in my review of
draft-ietf-tzdist-caldav-timezone-ref.  I do have some
comments/questions.  I'd like to discuss the questions before I
request last call on the document.

Please change all uses of "Prefer header" to be "Prefer header field"
(Sections 3.1.3, Section 4 bullets 1 and 2).

-- Section 3.1.3 --

   Observation and experiments have shown that, in the vast majority of
   cases, CalDAV clients have typically ignored time zone definitions in
   data received from servers, and instead make use of their own "built-
   in" definitions for the corresponding time zone identifier.  This
   means that it is reasonable for CalDAV servers to unilaterally decide
   not to send "VTIMEZONE" components for standard time zones that
   clients are expected to have "built-in" (i.e., IANA time zones).
   Thus, in the absence of an explicit "vtimezone=yes" or "vtimezone=no"
   preference in the request from a client, servers advertizing the
   "calendar-no-timezone" capability MAY opt to not send standard
   "VTIMEZONE" components.

Two points about this:

1. This breaks clients (the small minority, I guess, yet they've been
compliant until now) that do *not* behave this way, and expect, as has
been required until now, that the VTIMEZONE components will be there.
Did the working group explicitly discuss that and decide that it's OK
to break them?  Can someone point me to that discussion so I can give
it a scan?

2. It might be best if, because of this change to the normal behaviour
of CalDAV, this document would "update" 4791 (which could at least
somewhat mitigate point 1).  No?  Should we discuss this?

-- Section 4 --

Bullet 1:

       In this case, clients
       MUST retrieve the missing standard time zone definitions from the
       set of time zone distribution servers advertised by the CalDAV
       server (see Section 3.1.2).

Did the working group discuss the possibility that the client has
tzdist servers configured, and might prefer to use them insted?
(Perhaps, for example, there are network-local tzdist servers that the
client knows about, while the server's tzdist sources are
network-remote.)

Bullet 2:

       Clients can include an HTTP "Prefer" header with a
       "vtimezone=yes" preference to ensure that the CalDAV server does
       include all "VTIMEZONE" components in any iCalendar data returned
       in a response (see Section 3.1.3).

But this doesn't "ensure" it: the HTTP Prefer header field "is used to
indicate that particular server behaviors are preferred by the client
but are not required for successful completion of the request."  The
server is allowed to fail to honor the preference.  Is that a problem?
 Should the document address that?

--
Barry, ART Director