Subject: Some comments on the "time" fields in the SDPv2 spec

From: Ross Finlayson <[email-masked]>
Date: Tue, 9 Apr 1996 01:53:55 -0700

Mark (cc. "confctrl"),

I was recently taking another look through the SDPv2 spec (draft 02.1, 27th
Feb), and it occurred to me that the specifications of the various "time"
fields ("t=", "r=" and "z=") are still somewhat imprecise, and in places
potentially confusing.

Some comments/questions regarding the "t=" (start/stop times) field:

- What happens if there's no "t=" field?  Is this equivalent to a single
field "t=0 0" - i.e., specifying an unbounded session?  I presume so, but
this needs to be made clear.
- Is it OK for a "t=" field to specify a non-zero start time, but a zero
(i.e., unbounded) end time?  This should probably be allowed, although
discouraged (just as "t=0 0" is discouraged).
- The rules for allowing more than one "t=" field need to be elaborated.
Obviously, in this case the (start time, end time) intervals should not
overlap.  But it also makes sense to require that they be listed in
ascending order of time.  (This pushes the work of sorting the intervals to
the (one) session creator, instead of to the (many) session recipients.)

Some comments/questions regarding the "r=" (repeat times) and "z=" (zone
adjustment) fields:

- These fields are not mentioned at all on your list on page 6.
- The grammar in Appendix A doesn't mention the "r=" or "z=" labels.

Finally, I'm still a little worried that we might be reinventing a wheel
somewhere.  Does anyone know of any efforts under way - e.g., in some other
standards organization - to define or promote a standard calendar
interchange format for PIMs ("personal information managers")?  If such a
standard (even a "de facto" standard) doesn't exist already, then it should,
IMHO.  In any case, I expect that users will want to drag SDP-specified
sessions to their calendar managers.

        Ross.

---

From: Mark Handley <[email-masked]>
Date: Tue, 09 Apr 96 12:21:23 +0100

>fields ("t=", "r=" and "z=") are still somewhat imprecise, and in places

Thanks for your comments Ross - I'll try and address them...

>this needs to be made clear.

You're quite correct.  I had though "t" was specified as compulsory, but
thats not what the current working states.

>discouraged (just as "t=0 0" is discouraged).

I think you're correct (especially as you can't specify repeats
without a start time to work from) but I'm slightly concerned about
anything that might encourage more use of unbounded sessions as they
are going to be a really bad idea as the number of sessions increases.

>overlap.  

No - they must be allowed to overlap for some odd repeat patterns -
the end time specifies when the repeat pattern finishes repeating.

>But it also makes sense to require that they be listed in

Makes sense.

>- The grammar in Appendix A doesn't mention the "r=" or "z=" labels.

These are errors in the draft, and I'll fix them.

>sessions to their calendar managers.

Agreed - we discussed this a little in the meeting about a year ago.
The current format seems to work OK for most things but I'm not really
all that happy with it.  Bear in mind though that the requirements are
slighly different from calendar managers in that you need to specify a
time uniquely and globallly without requiring too much knowledge on
the receivers part about your timezone, your daylight saving time,
etc.  This constrains the format a little.  When we started this, I
was pointed at several calendar formats and none of them could do this
task unambiguously.

>        Ross.

Thanks again,
	Mark