Subject: Re: comments on SDP draft-03

From: Ross Finlayson <[email-masked]>
Date: Thu, 21 Nov 1996 15:20:12 -0800 (PST)

Some more comments/questions:

I notice that the "c=" field remains compulsory in the "session
description", and optional in each "media description".  However I vaguely
recall (from some previous IETF meeting) a discussion of whether "c="
could/should be removed from the "session description", and made compulsory
in each "media description" instead.  Was there any further discussion of
this?  This would seem to be a bit more logical.  It would also make more
sense for the case of 'info-only' announcements that contain no media
descriptions at all.  (Right now, these announcements contain a dummy,
unused "c=" field.)

>>Has anyone implemented/has plans to implement the same day of year/same day
>>of month form of repeats? I haven't and neither has Mark. If not required,
>>I'd like to propose simplifying the repeat syntax.
>
>They're difficult to implement.  Unfortunately I have the strong
>feeling that they're going to be required.  If everyone else doesn't
>think so I'd love to remove them :-)

I'm not thrilled about these either, but like Mark, I suspect that people
are going to want them.  However, it occurred to me recently that the
specification, as it currently stands, is ambiguous, because for events that
occur near month boundaries, it's not always clear exactly what "same day of
the month" is really intended.

Example: Suppose that we receive a description that specifies:
        start time: March 1, 1997 3am UTC,
        repeated "same day of the month, each month"

Unfortunately, it's not clear from this what "same day of the month" the
creator really intended.  For instance, if I created the announcement here
in California (8 hours behind UTC), then I probably meant "the 28th of each
month" (my time; the next day in UTC).  But if the creator was in the UK,
then he probably meant "the 1st of each month".

There's also the issue about what to do about the fact that not every month
has a "31st"...

Unless we can sort these problems out, it might be better to omit the "Y"
and "M" options for repeating events, at least for now.  After all, if we
head down this slope, how far should we go?  Should we also have a way to
specify things like "the first Monday of each month"?  For now it might be
best to wait to see what the IETF "calendar scheduling" working group comes
up with, with the intention of incorporating that (or something isomorphic)
in a future version of SDP.

>>- [I'm curious]
>>Has anyone implemented the z= records for daylight savings time shifts? I
>>understand why this is necessary, but it is a bit complicated.
>
>Actually it's not complicated at all to code as a receiver.  Coding it
>as a sender is not bad if you have suitable OS libraries that can tell
>you the time a change should occur.  Without them, it's a nightmare,
>but I can't think of any format that's any simpler, and almost
>everything else is much worse to code for receivers.

Yes, I agree.  I used to hate this, until I realized that I couldn't see a
better solution myself :-)  Recently I've been beating on the IETF "calendar
scheduling" WG to make them aware of this issue (& solution).  (I seem to be
making headway, although there are still a couple of holdouts :-)

        Ross.

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 08:13:33 -0500

>descriptions at all.  (Right now, these announcements contain a dummy,

An alternative I prefer is to make the session-level "c" field
optional, but that if it did not appear, then media-level "c" fields
are compulsory.  If there is a session-level "c" field, media-level "c"
fields are optional.  I.e, you need one or the other...

Partly I prefer this because it won't break sdr :-), but also because
it's pretty natural from the media-inherit-properties-from-session way
sdr works.

>>>of month form of repeats?
...
>However, it occurred to me recently that the

Very good point.  You'd also need to specify an offset from UTC to
make this unambiguous.  Alternatively you could specify the start time
as being a day later and use a negative offset of one day, which
achieves the same purpose with no extra fields.  Both are icky.

>There's also the issue about what to do about the fact that not every month

There are four sensible options here:
 - omit those months
 - map to last day of month
 - map to first day of next month
 - map to equivalent day since start of month

I'm not going to add mechanisms to do all of these!
My Psion organiser chose to map to last day of month, which does seem
the best choice to me.  If we have to specify one, this is the one I'd
choose.

So, I believe we can make this unambiguous, and do mostly what people
expect. 

The question Valerie asked was very valid though - do we *need* these?
We can always explicitly list the times using extra "t" fields - this
is perfectly valid, though somewhat lengthy.  It is however what we
agreed on for "first tuesday of each month" type sessions.

Opinions?

Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 22 Nov 1996 14:06:23 +0000

>the best choice to me.  If we have to specify one, this is the one I'd

Psion have just  released a TCP stack......it should work on their IrDA port
ok and talk to PCs and things like HP's netbeam (infrared to ether
bridge)

time to port the mbone tools to the world's best palmtop, and have a
working startrek communicator all the wayfrom the UK??

 jon