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

[Eliot Lear <[e-mail]>]

Hi Cyrus,

Thanks very much for your prompt attention.  Please publish an update
with the changes, assuming nobody objects.

Eliot


On 6/11/15 5:33 PM, Cyrus Daboo wrote:
> 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?
>