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: Mark Handley<[email-masked]>
Date: Wed, 20 Nov 96 19:24:25 -0500

>trivial things that I just noticed for the first time.

Many thanks for the comments!  I'll act on (almost) all of them.

>understand the need for this. My preference is to keep things as is.

The problem was to distinguish between genuine persistent background
sessions and sessions created on demand, but with unknown end time.
I want to discourage the use of permanent sessions for the latter, but
don't feel that setting a specific (arbitrary) end time is quite right
either.  What's in the draft right now is a slightly uneasy compromise.

>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 :-)

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

>On to SAP.

:-)

Mark

---

From: Mark Handley<[email-masked]>
Date: Thu, 21 Nov 96 12:54:22 -0500

>trivial things that I just noticed for the first time.

..

>- In the list of all type=value lines in a session description, you forgot

In adding these I noticed that according to the current spec, it is
legal to have no time field present.  This was not intentional, so
I've changed it so you must have at least one "t=" field.

>for the encoding of video data. It is a media attribute.

Did you intend this to always be an integer, or are fractional values
allowed?  If fractional, we'd better state whether the alternative
notation of 3,1415 is allowed (as opposed to 3.1415).

I suggest the wording:

This gives the maximum frame rate in frames/sec.  It is intended as a
recommendation for the encoding of video data.  Decimal
representations of fractional values using the notation
"<integer>.<fraction>" are allowed.  It is a media attribute.

>10. It is intended as as recommendation for the encoding of the video data.

Is 1 or 10 intended to be best quality?

Do you intend to specify anywhere how this is to be mapped onto H.261
quantisers?  Personally I'd prefer to specify the largest quantiser
permissible as vic does (the app is always free to choose smaller
quantisers if it has sufficient bandwidth available)

Mark