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

[Eliot Lear <[e-mail]>]

Hi Barry,

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

On 7/21/15 2:36 PM, Barry Leiba wrote:
> 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?

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

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

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

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 ;-)

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

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