Subject: Re: [IPTEL] CPL time ranges

From: [email-masked]
Date: Fri, 29 Sep 2000 10:41:59 -0400

From:  Tom Gray@MITEL on 09/29/2000 10:41 AM

In the description below, there is an account of exception handling when
monthly, quarterly, annual events fall on weekends. Is there similar handling
for statutory holidays which are distinct on the local, regional and national
levels. Similarly are there means for handling events of purely local
significance such as plant shut downs, organisational celebrations, no meeting
days and so on. The need to handle such execptions would seem to me to have
signficance in the allocation of responsibilities between the client and server.

Jay Batson <[email-masked]> on 09/29/2000 12:56:31 AM

To:   [email-masked]
cc:    (bcc: Tom Gray/Kan/Mitel)

Subject:  Re: [IPTEL] CPL time ranges

I can speak to one other, very mature calendaring
system:  MeetingMaker.  For reference, I was VP of Engineering of the team
that built this client/server group calendaring product, which is still in
wide use.  (E.g it is the group meeting scheduler at Cisco.)  I am proud to
brag that MM a very sophisticated product that is targeted at high-end,
very large, geographically diverse enterprises.

Following Jonathan L.'s outline, Meeting Maker provides:

Start time
Duration (from which stop time is calculated)
Frequency:
     Daily
       - options: every day, every 'n' days, on specified days of the week
     Weekly
       - options: on specified day of week, every week; every 'n' weeks; on
specified week of month (e.g. 1st, 2nd, 3rd, 4th, last)
     Monthly
       - options: Every month on this date, every other month on this date,
29th day of every month, 29th day of every other month, and what to do if
activity falls on weekend (don't move, move to previous weekday, move to
next weekday, move to closest weekday)
     Quarterly
       - options: What to do if activity falls on weekend (see previous choices)
     Annually
       - options: What to do if activity falls on weekend (see previous choices)

Exception vector:
     (Not an explicit choice.  However, when a user sees a recurring meeting in
their calendar, and they select the meeting and hit "delete," the program
asks them if they want to cancel "the meeting on this (selected) date,"
"the meetings after this (selected) date," or "all occurrences of this
meeting."  Note that the Palm desktop provides the same options.)

Time zone is attached to the meeting object by the server involved.  (Users
are "associated" with a server within their time zone, and the server is
told its time zone.  In MeetingMaker, when a meeting proposal is sent to a
user on another server, the remote server adjusts for time zone
differences, so that the proposal ends up being presented to the user in
their "local" time.)  The meeting is stored in Zulu (GMT) time, along with
storing the meeting proposer's time zone.  On servers, time zones are set
in +/- GMT, and they know their local time zone rules (e.g. Arizona.)

Meetings/activities can span midnight, but for reasons I can't remember
cannot exceed 24 hours.

For the record, I will claim substantial credit for getting the IETF iCal
working group started.  I wanted to get calendaring products to provide the
ability to propose meetings between companies, so I harangued other
calendar vendors into getting the IETF to let us start the group.

As a non-technical contributor, I didn't chair the group, etc., but
employees from my team contributed to the (never-completed) portion of iCal
that was creating the "live" calendaring *protocol* for interactions
between systems.  (Never completed because we couldn't solve some
fundamental problems, e.g. information protection/security.)

The data representation portions of iCal -- which this group is mostly
looking at -- is made up primarily of work done by Microsoft, and by
Qualcomm (who was expecting to build a calendaring product, but never
did.)  Much of the data representation decisions were made to suit
Microsoft's then-current-product needs.

Note that there are various *calendaring* products out today which support
parsing of iCal data, e.g. Outlook and Organizer.

For the record (again), I'm an old unix hack.  crontab was *maybe* okay in
1986, but was and is maddening obtuse.  I always had the opinion that the
crontab format was the bad idea of a junior programmer who hadn't thought
through all the issues, and that we were all stuck with his/her bad
ideas.  I even wrote a replacement for it when I was at BBN that we toyed
with distributing as part of the OS release for our Mach-based massively
parallel processor computers.  (It was a *tad* better, though not much.... ;-)

IMHO, I think the work done by the iCal WG was pretty good.  There are
*many* subtleties that arise when you have to think about representing
events and times, and you don't always know what they are till you've been
there.  People who had "been there" built the iCal data representation, and
did good work.

So I'm sad (nah -- happy!) to say that I can't provide "running code," I
would place myself on the side of using iCal in some manner -- abbreviated
or not -- when it comes to the "rough consensus" part.  Now if Jonathan L.
can provide the running code.... ;-)

-jb
----------
Jay Batson
Pingtel Corp.
[email-masked]

781-938-5306 (office)
781-938-9650 (fax)

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel