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

From: Cyrus Daboo <[email-masked]>
Date: Mon, 24 Aug 2015 17:26:06 -0400

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 
<[email-masked]> 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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 24 Aug 2015 17:51:19 -0400

> Sorry for the delay - addressing this now I am back from vacation.

I hope you enjoyed...

>    default behavior based on client User-Agent request header field values.

That sounds reasonable and wise.

>    server (see Section 3.1.2).

Yes, I like the removal of the 2119 key word from there.  In your
text, just change "its own" to "their own" for number agreement.

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

That also sounds reasonable.  What will the default be if
CalDAV-Timezones is absent?

b

---

From: Ken Murchison <[email-masked]>
Date: Mon, 24 Aug 2015 18:26:49 -0400

On 08/24/2015 05:26 PM, Cyrus Daboo wrote:
>
> 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
>
> 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.
>

I'm fine with using a new header as proposed.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Michael Douglass <[email-masked]>
Date: Tue, 25 Aug 2015 00:44:29 -0400

This is fine with me

On 8/24/15 18:26, Ken Murchison wrote:
>> 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.
>>
>
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Aug 2015 07:27:47 +0200

> CalDAV-Timezones is absent?

For backward compatibility I would suggest that it be that VTIMEZONEs
are transmitted.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 25 Aug 2015 17:18:02 -0400

Hi Eliot,

> For backward compatibility I would suggest that it be that VTIMEZONEs

Well actually I would rather stick with what the current spec says: by 
default no vtz is sent - but the new text I proposed would make it clear 
that an exception might have to be made for a small number of existing 
clients. The point is to provide the immediate benefit of not sending vtz 
to existing clients without having to wait for them to be updated to send 
the new header.

The alternative to the above, is to go with the default of sending vtz, but 
allow the server to "whitelist" known clients and not send vtz to those. 
Most implementations would simply whitelist everything and then special 
case those clients that would be a problem - in effect making the default 
to not send vtz. However, defining like this does make it appear to be more 
backwards compatible.

In summary, two choices for the WG (with #1 being the currently defined 
behavior):

1) In the absence of the new request header, by default the server does not 
send VTIMEZONE components, but it SHOULD provide an option to override that 
behavior for specific clientsE, based on User-Agent, that always require a 
VTIMEZON.

2) In the absence of the new request header, by default the server always 
sends VTIMEZONE components, but it MAY provide an option to override that 
behavior for specific clients, based on User-Agent, that are known to 
ignore VTIMEZONEs in the data.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 28 Aug 2015 10:29:22 -0400

Hi Eliot, Barry,

--On August 25, 2015 at 5:18:02 PM -0400 Cyrus Daboo <[email-masked]> 
wrote:

> 1) In the absence of the new request header, by default the server does
> not send VTIMEZONE components, but it SHOULD provide an option to
> override that behavior for specific clientsE, based on User-Agent, that
> always require a VTIMEZON.
>

Any comment on this before I update the spec? In the absence of any 
preference I will leave the spec as is (i.e., choice #1).

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Fri, 28 Aug 2015 10:33:27 -0400

On 08/28/2015 10:29 AM, Cyrus Daboo wrote:
> Hi Eliot, Barry,
>
> --On August 25, 2015 at 5:18:02 PM -0400 Cyrus Daboo 
> <[email-masked]> wrote:
>

I believe that choice #2 would be the norm for new behavior (opt-in), 
but I don't have a strong opinion either way since it appears that most, 
if not all, clients use their own VTIMEZONE data anyways.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 11:13:17 -0400

I'm with Ken here: mild preference for the default being as things
were, but not a strong preference.  You guys know the actual
deployment issues.

Barry

On Fri, Aug 28, 2015 at 10:33 AM, Ken Murchison <[email-masked]> wrote:
> I believe that choice #2 would be the norm for new behavior (opt-in), but I
> don't have a strong opinion either way since it appears that most, if not
> all, clients use their own VTIMEZONE data anyways.
>
>
> --
> Kenneth Murchison

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Aug 2015 17:46:49 +0200

And that's where I am.