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

From: Eliot Lear <[email-masked]>
Date: Tue, 09 Jun 2015 15:37:55 +0200

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

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

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Jun 2015 11:33:10 -0400

Hi Eliot,

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

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

> Suggestion: s/servers/servers advertizing the no-timezone option/

Fixed.

> This is today's behavior.

Correct.

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

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

>    working group mailing list <[email-masked]>.

Fixed.

> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jun 2015 17:59:20 +0200

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

---

From: Steve Allen <[email-masked]>
Date: Thu, 11 Jun 2015 09:12:40 -0700

On Thu 2015-06-11T11:33:10 -0400, Cyrus Daboo hath writ:
> (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.

I think this situation will happen indefinitely.  The Lick Observatory
telescope schedules have always operated in a time zone where the new
day begins at noon PST, or 20 hours behind Greenwich.  This will never
be a standard timezone, but the de facto practice is unlikely to change.

--
Steve Allen                 <[email-masked]>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Jun 2015 12:16:50 -0400

Hi Steve,

> be a standard timezone, but the de facto practice is unlikely to change.

As a matter of interest, do you know the reasoning behind that choice?

-- 
Cyrus Daboo

---

From: Steve Allen <[email-masked]>
Date: Thu, 11 Jun 2015 09:51:53 -0700

> As a matter of interest, do you know the reasoning behind that choice?

sic semper faciebamus.  I think the reasoning is unlikely to be
written explicitly.  It is a conventional local shorthand notation for
a telescope schedule where the inspiration belongs with John
Herschel's 1849 "Outlines of Astronomy" page 678

https://books.google.com/books?id=uj0DAAAAQAAJ&pg=PA678&hl=en#v=onepage&q&f=false

Herschel adopted Scaliger's Julian period with days starting at noon
in Alexandria.  For international purposes that later got moved to
noon at Greenwich.  As things have become robotic over the internet
the convention persists in that the authentication tokens for the use
of a telescope expire at noon.

---

From: Rob Seaman <[email-masked]>
Date: Thu, 11 Jun 2015 10:01:39 -0700

Presumably for the same reason as other observatories.  Data are batched by the calendar date at the beginning of each observing session.  For nighttime observatories this begins with calibration data taken in the afternoon in preparation for science observations taken in twilight and overnight. At our observatory we have long had a noon local time pivot, but have recently moved to 9 am (with a few at 10 am) since sometimes calibrations start early.  A different observer may be using the telescope the following night and you want to wrap up the logistics of closing out data management (and authorization, as Steve says), as early as possible to move on to the next observer.

These are generally local time conventions. This impacts observing modes that use multiple telescopes for co-observing, follow-up, etc. Recent trends include several observatories (such as http://lcogt.net) that operate a network of facilities that may be scheduled together using complex policies. In these cases UTC is more likely to be used, but some components in the science and logistics stack will remain tied to local time.

Rob
[email-masked]
[email-masked]
—

> On Jun 11, 2015, at 9:16 AM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Steve,
> 
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist