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

[Eliot Lear <[e-mail]>]

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.

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.

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/


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.

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

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


Nits:

The following text should be removed:

   Discussion of this Internet-Draft is taking place on the tzdist
   working group mailing list <[e-mail]>.


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

Eliot