Re: [Tzdist] shepherd review and issues for draft-ietf-tzdist-caldav-timezone-ref

[Cyrus Daboo <[e-mail]>]

Hi Eliot,

--On June 9, 2015 at 3:37:55 PM +0200 Eliot Lear <[e-mail]> wrote:

>
> In Section 3.1.2:
>
>>  A CalDAV server supporting this specification MUST have one or more
>>    associated time zone distribution services [I-D.ietf-tzdist-service]
>>    that provide data for the set of time zones known to the server and
>>    expected to be used by clients.  A CalDAV server advertises the set
>>    of time zone distribution services it makes use of via a
>>    CALDAV:timezone-service-set WebDAV property (see Section 5.1) defined
>>    on calendar home collections.  Clients can use the time zone data
>>    distribution services listed in this property to fetch current time
>>    zone definitions for the time zone identifiers in iCalendar data
>>    retrieved from the server.
>
>
> I have a question about this text: is it possible for the client and
> server to become out of sync if they are not using the same TZ
> distribution service, and do we care that much?  That is- should we say
> that clients MUST use one of the TZ distribution services advertised by
> the server?  That would seem harsh, and there might be authorization or
> reachibility issues in some cases, but at least the data is likely to be
> consistent.  Another approach would be to require a standard name within
> the data sets for purposes of comparison.

The hope is that data for the same time zone on different tzdist servers 
will match up, so if a client uses a different one than the server, 
everything should be OK (at least it will be no worse than the situation we 
have today). If it is critical for the client to know that the time zones 
match, then it can compare the server's tzdist server time zones to those 
from the other one it is using.

So, I definitely think a MUST requirement on clients to use the CalDAV 
server's tzdist server is too harsh.

> Section 3.1.3:
>
>>
>>    If the
>>    "vtimezone=no" preference is set by a client on any HTTP request that
>>    returns iCalendar data, then the server MUST NOT return any
>>    "VTIMEZONE" components if the time zone identifier matches one
>>    provided by any of the advertised time zone distribution servers (see
>>    Section 3.1.2).  However, the server MUST return the appropriate
>>    "VTIMEZONE" component for each time zone with an identifier not
>>    available on the advertised time zone distribution servers.
>
>
> I understand the intent here.  In what circumstance would the server and
> client both be aware of a timezone that the tzdist service is not, and
> is that an error or simply local configuration?  My point: if this is a
> case that won't happen, let's not clutter the text.

It is possible a non-standard time zone has been sent in an iTIP 
(scheduling message) to an attendee and they have stored that on their 
CalDAV server. In that case the correct thing to do is maintain the 
original VTIMEZONE component in the data as the attendee is not really 
allowed to "coerce" it into the closest match standard TZID, as that could 
cause problems with any replies they send back. I do think this is a 
situation that will happen a fair bit as we wait for everyone to start 
using tzdist and get IANA tzids used everywhere.

> Later in that section:
>
>>   Thus, in the absence of an explicit "vtimezone=yes" or "vtimezone=no"
>>    preference in the request from a client, servers can opt to not send
>>    standard "VTIMEZONE" components.
>
> Suggestion: s/servers/servers advertizing the no-timezone option/
> and s/can/MAY/

Fixed.

> Section 3.1.4, just to confirm what we're talking about:
>
>
>>    Note that, as per Section 4, clients might send time zone definitions
>>    for time zones that are not advertised by any of the time zone
>>    services associated with the server.  In that case, servers have
>>    various choices:
>>
>>    1.  Servers can preserve the original time zone definitions in the
>>        iCalendar data sent by the client, so that those can be returned
>>        to that or other clients who subsequently request iCalendar data.
>
> This is today's behavior.

Correct.

>>    2.  Servers can refuse to accept any unknown/non-standard time zones,
>>        in which case they MUST reject the HTTP request containing such
>>        data using a WebDAV precondition code of CALDAV:valid-timezone.
>
> This would be new.  What would the client do in these circumstances?
> Surface an error to the user saying, “pick another timezone?”

Well the server returns the "CALDAV:valid-timezone" which should prompt the 
client to apply corrective action. I think item #5 in Section 4 covers what 
the corrective client actions are.

>>
>>    3.  Servers can, with appropriate knowledge, map the unknown/non-
>>        standard time zone to a standard time zone definition that
>>        accurately matches the one supplied by the client.  In doing so,
>>        servers will need to re-write the iCalendar data to make use of
>>        the new standard time zone identifier chosen by the mapping
>>        procedure.
>
> This is not clear (to me).  Is the intent that other clients would
> receive the standard name?  If the event is later retrieved by the
> client would the VTIMEZONE be dropped?

The intent is the server would rewrite the calendar data as it is written, 
such that any future GETs would see the TZID chosen by the server (from its 
standard set). It might be worth clarifying the one situation where that 
would not be appropriate - namely an attendees copy of the event. I have 
changed item 3's text to:

    Servers can, with appropriate knowledge, map the unknown/non-standard
    time zone to a standard time zone definition that accurately matches
    the one supplied by the client. In doing so, servers will need to
    re-write the iCalendar data to make use of the new standard time zone
    identifier chosen by the mapping procedure. Any subsequent request to
    fetch the calendar data would see the new time zone identifier in the
    calendar data. Note there is one important situation where this
    re-mapping is not appropriate: an attendee's copy of an event. In that
    case the original time zone definition needs to be preserved as the
    organizer's calendar user agent will expect to see that in any iTIP
    replies sent by the attendee.

> Nits:
>
> The following text should be removed:
>
>    Discussion of this Internet-Draft is taking place on the tzdist
>    working group mailing list <[e-mail]>.

Fixed.

> Finally, please confirm that you are or are not aware of any IPR
> relating to this document.

I confirm that I am not aware of any IPR relating to this document.

Do you want me to publish a new version of the draft with the above changes?

-- 
Cyrus Daboo