Re: Merged Draft containing feedback from all of you.

[Keith Moore <moore@xxxxxxxxxx>]

> TIMEZONE AND DAYLIGHT SAVINGS ISSUES FOR RECURRING MEETINGS
> - How important is it to allow a recurring meeting that lasts 2 years? 
> 5 years? 10 years?  should we bound this part of the problem?

You should be able to schedule a recurring meeting that lasts
indefinitely.  You should also be able to change the DST rules for
that meeting, after the meeting is scheduled.

> - What TZ should be used when scheduling a meeting.  creator location?  
> event location?

The TZ in the event description should match whatever TZ the event is
actually scheduled in.

> - How should a change in TZ rules be handled?  sender re-issues meeting 
> request?

Sender re-issues aren't general enough.  There's probably no single
mechanism that is general enough and deployable in the near term.

Having said that, I still like the idea of having a URL for the event
description (or perhaps just the timezone description) included in the
event description itself, so that a recipient's calendar app could
occasionally download a fresh copy.  It puts the incentive for updates
in the right place, distributes the costs fairly, and any network
failures get detected by the recipient (rather than the sender).

> - Is a server which is a world-wide authority on DSTs changes
> feasible?

Technically feasible? yes.  The big problems are: (1) how do we get
the right parties to update it when their DST rules change (along with
the various and sundry authentication and security problems), and (2)
how does the service (especially one which might operate on a large
scale) get paid for?

I suggest we not concern ourselves with those things right now, since
they will delay the part of the spec which we understand and which is
under our control.

If we could define a standard for timezone names, and a format for
describing a timezone relative to UTC, that would be a good start.
Even so, I suggest that these (especially the latter) be peripheral to
the main effort of the group.

> - DST shifs are explicitly specified in the meeting request by the 
> creator of the meeting and are relative to the timezone of the location 
> of the creator of the meeting.

Just as the UTC equivalent time is as good as we can do as a
short-term approximation for one-time events, DST shifts seem to be
about as good as we can do as a short-term approximation for recurring
events.

> GENERAL RECURRANCE PATTERN ISSUES
> - How important are non-Gregorian calendars?

To those who use them to schedule meetings, very important.

For now, I propose that there be a specific indicator to distinguish
between various types of calendars.  As to whether the syntax for
recurring events that is defined for Gregorian calendars, also works
for other calendars...that is a matter for future study.  Other
calendars could define their own recurrance patterns (with a different
attribute name) if it turns out to be necessary for them to do so.

Keith