Subject: SDP repeat time fields

From: Mark Handley <[email-masked]>
Date: Wed, 14 Jun 95 17:49:06 +0100

Having tried to implement code to use the SDP repeat time fields, I've
come to the conclusion that the current format specified in the 00
draft (or even in the revised working draft) is not what's required.

Feel free to say "I told you so" :-)

There are a number of problems including:

- you can't specify some required repeat times that I think we need.
- you can specify too much to describe to the user in any interface I can 
  think of.
- dealing with timezones is unnecessarily complicated,
- dealing with switching from standard to daylight time is really horrible.

Thus I'd like to suggest an alternative much simpler format:

t=<starttime> <stoptime>
r=<repeat interval> <duration> <list of offsets from starttime>

If no "r" field is specified, the session is active between the start
and stop times.  If one or more "r" fields are specified then the
session is only active between the start and stop times specified by
the "t" field at the times specified by the "r" fields.

Each "r" field specifies a repeat relative to the previous "t" field.
<repeat interval> is the time between repeats.  <duration> is how long
it's active for.  The <list of offsets from starttime> is zero if the
session repeats once per interval starting at <starttime>.  Otherwise
it's a list of offsets from starttime - for example if you wanted to
have a session active monday, wednesday and friday each week for one
hour, you might have (all times in seconds):

r=604800 3600 0 172800 345600

(the time of day should be specified by <starttime> which in this case
would be on th Monday. 172800 is the number of seconds in 2 days, etc)

You can have multiple "r" fields per "t" field if required.

Now, there's some things you can't represent with this format.
Specifying repeating each month by date (eg, 12th of each month), and
specifying each month by weekday (third thursday of the month) aren't
possible.

Now we could add extra syntax to deal with these (and how many other
odd cases?).  However, I'm starting to think that this may not be
necessary, and that maybe these sort of events should simply be
specified by an explicit list of "t" fields.

Both the above "difficult" examples are timezone dependant (which day
you're on depends on which timezone you're in!).  I'd like to avoid
format that are timezone dependant if possible (NTP times and offsets
from them are timezone independant).

Let me know what you think.

Of yes, that brings me to daylight savings time!

We probably need an additional field specifying daylight savings time
switches if you want your repeated session to be at the same time each
day, winter and summer.  As this changes at different times and dates
depending on where you are in the world, you have to specify which
timezone is relevant for the session, and what time the change occurs
at.  In it's simplest form this is a list of NTP timestamps (ie when
the change happens) and offsets (how big the change is).  Thus the
current suggestion is:

z=<change time> <offset> <change time> <offset> .....

Anyone have any problems with either of these, or alternatively any
better ideas?

Mark