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

[Cyrus Daboo <[e-mail]>]

Hi Barry,
Sorry for the delay - addressing this now I am back from vacation.

--On July 21, 2015 at 8:36:08 AM -0400 Barry Leiba 
<[e-mail]> wrote:

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

See below - I am going to propose use something other than Prefer.

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

As Eliot noted there is no specific discussion of this on the list. It was 
certainly discussed by CalConnect folks when we first started working on 
this spec. It is an important point and probably does deserve an explicit 
"OK" from WG participants.

>From my perspective I have not yet come across a client that I know would 
be broken by this. I would be OK adding text such as the following, though:

    To support legacy clients that do not send the XXX header field in
    requests, yet expect "VTIMEZONE" components to be present, servers MAY
    provide an administrator configuration setting to override the new
    default behavior based on client User-Agent request header field values.


> 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 I think this should "Update 4791" as we really want to draw any 4791 
implementors' attention to this new behavior as we really want everyone to 
adopt it.

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

I think the wording of that bullet point is too strong and I would like to 
propose the following instead:

    In this case, clients will have to retrieve the missing standard time
    zone definitions either from its own cache of standard time zones, or
    from the set of time zone distribution servers advertised by the CalDAV
    server (see 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?

Since there was push back along the same lines by the Prefer designated 
expert I would like to propose removing use of the Prefer header and 
instead replace it with a new HTTP request header:

CalDAV-Timezones: Y
CalDAV-Timezones: N

With the "Y" value requesting the server to send VTZ data, and "N" 
requesting that no VTZ data is sent.

If there is agreement that this addresses the problem of using Prefer, then 
I will go ahead and make this change in the next document update.

-- 
Cyrus Daboo