Subject: comments on SDP draft-03

From: Valerie Lasker <[email-masked]>
Date: Wed, 20 Nov 1996 10:28:01 -0800

Here are my comments on the latest draft SDP spec. Included are a few
trivial things that I just noticed for the first time.

For those of you that don't know me, Precept's IP/TV Program Guide product
is my implementation of SDP and SAP version 0.

4.1 Multicast Announcements
- says "sd clients", should say "SDP clients"
- says "The first eight bytes are the Session Announcement Protocol
header.", shouldn't give the (now possibly wrong) size of this header.

6. SDP Specification
- In the list of all type=value lines in a session description, you forgot
r= and z=.

5.2 Timing Information and 
6. Times, Repeat Times and Time Zones
- I don't understand the need to introduce: t=<start time> 0, for unbounded
sessions in addition to the t=0 0 form, which you now call permanent sessions.
Your email said you added this feature in response to requests. I'd like to
understand the need for this. My preference is to keep things as is.

- [for discussion]
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.

- [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.

Suggested Attributes
- I believe I gave you text quite a while ago asking you to include the
following as suggested attributes, for video encoding:

a=framerate:<frame rate>
This gives the frame rate in frames/sec. It is intended as a recommendation
for the encoding of video data. It is a media attribute.

a=quality:<quality>
This gives the compression quality. For H.261, it is a number between 1 and
10. It is intended as as recommendation for the encoding of the video data.
It is a media attribute.

Other than the above, your draft looks good.
On to SAP.

-- Valerie

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 22 Nov 1996 12:07:08 -0800 (PST)

>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.

Fair enough.  This also has the advantage of saving space in the common case
where each medium uses the same group address - i.e., you don't need to
repeat it in each media description.

>>>>of month form of repeats?
>...
>>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".
>
>Very good point.  You'd also need to specify an offset from UTC to
>make this unambiguous.

FYI, the current concensus within the IETF "calendar scheduling" WG seems to
be that event descriptions (both single and repeating) should include all
three of: event timezone, event local time, offset from UTC.  The idea being
that "event local time-offset from UTC" will give you the event time in UTC,
but that "event local time" and "event timezone" are also available as
'hints' that the receiver can use if he wishes.  (I'm not thrilled by this,
but some people are concerned about the possibility of the event creator's
DST rules changing after the event description has been created, for
instance.)  Anyway, one fortunate side effect of having the "event local
time" available is that we can make things like "same day of the month"
unambiguous.  (I'm still not sure what's the best solution to the "not all
months have 29th, 30th, 31st" problem, though.)

>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?

I vote for removing the "Y" and "M" specifications from the SDP spec, at
least for now.  As we've noted, they're broken, noone currently seems to be
using them, and in the future we'll probably have to modify SDP anyway to
conform to the spec that comes out of the "calendar scheduling" group.  (At
the very least, we may need to add an "event timezone" field.)

        Ross.