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

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Jul 2015 08:36:08 -0400

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 21:10:31 +0200

Hi Barry,

I'm asking Cyrus to make one correct below, and then I believe a
discussion is indeed in order on two points.

> to break them?  Can someone point me to that discussion so I can give

To my knowledge the above text was NOT seriously debated, but taken as
given.  I believe it was mentioned on the interim call.  Embarrassingly
(for me) I now see that an issue was opened on this very point, and
apparently not addressed, but perhaps Cyrus can comment.
> somewhat mitigate point 1).  No?  Should we discuss this?

Yes.  Because I don't think updating 4791 really solves the problem.

> client knows about, while the server's tzdist sources are

Yes, in fact we did, and I believe we have a slight inconsistency in the
text, because we decided in Section 3.1.2 that we would NOT require that
clients use the same server, and here it says that they MUST. 
Therefore, I suggest that the above text change to be in accordance with
both WG consensus and Section 3.1 2 ;-)

>  Should the document address that?

Unless we are updating the behavior of Prefer, which I don't think we
want to do.  Cyrus should comment on this but it is tied to the issue above.

Eliot