Subject: Re: Additional comments on the SDP draft

From: [email-masked] (Ross Finlayson)
Date: Mon, 24 Apr 1995 17:49:37 -0700

> >3/ The 'grammar' often seems unnecessarily restrictive
...
> For example, it seems unnecessary to restrict the order of
> >the ?= fields to be exactly the order given in the paper.  Instead, you
> >could just specify that "s=" must come first, followed by the other session
> >description fields in any order (but including the manditory "o=" and "c="
> >fields), followed by zero[*] or more media description sections. Since many
> >of the fields are optional anyway, allowing them to occur in any order
> >doesn't make parsers any more complicated.
> 
> I'm slightly confused by this.  Allowing the fields to be in any order
> doesn't make *session descriptions* any less restrictive, unless you
> allow implied semantics to the field ordering, which I think is a very
> bad idea.

No, I definitely wasn't suggesting this.  Relaxing the order restrictions on
the ?= fields merely increases the set of 'legal' descriptions; it doesn't
make the language any more expressive *semantically*.  Thus, this isn't a
big deal.  But I suspect that most implementations will adopt the philosophy
of "be liberal in what you accept", and will allow looser orderings
anyway (especially since this is likely to make the parser less complicated
- i.e., it can just be a switch statement inside a loop).  So you may as
well relax the grammar accordingly.

> >As another example, the inheritance rules seem somewhat ad hoc.  The paper
> >says that the "c=", "a=" and "k=" fields are the only ones that can be
> >redefined in media descriptions.  But one could make a case for allowing
> >some of the other fields (most notably "i=" and "b=") to be redefined also.
> >(For instance, one might want to attach additional (short) descriptions to
> >specific media specs.) 
...
> ... I'm still unconvinced by the argument that
> media fields benefit from having "i" fields to the extent that it's
> worth adding the extra complexity to UIs to deal with it.

But lets not forget that first and foremost we're designing a *protocol*,
not an application.  If it makes sense - which I think it does - to allow
short information strings to be associated with media descriptions, then the
protocol should allow it.  It's up to application designers to decide what
to do with this (if anything).

> > You will need to
> > explain how (or even whether) SDPv1 and SDPv2 will interoperate.  If you
> > don't intend them to interoperate - i.e., if you anticipate the root SDPv2
> > directory using a different group address/port than the root SDPv1
> > directory - then that would give you the freedom to make otherwise
> > incompatible changes in SPDv2 (including adding a version field).
> 
> Originally SPDv1 was meant to be a subset of SDPv2.  I'm moving away
> from this idea, and I'm going to suggest a number of changes that will
> mean that SDPv1 messages will not be parsed be an SDPv2 tool (without
> extra legacy code or a gateway).  Given this, and the rule about
> unknown fields rendering the announcement void, we can always add a
> version number later if it's needed.

No, please add a version field now, and make it manditory.  You won't
regret it.  Also, it'll be better to make the version field part of the
initial, *binary* portion of the payload (& probably at the start), in case
you ever want to change this in the future.  BTW, this reminds me: What
exactly do/did you have in mind for the first 4 bytes of the binary
payload?  (I see that you describe it just as "authentication data for proxy
announcements".)  Is this something that you anticipate being in SDPv2 too?

> >5/ We need "unique ids" for announcements
> >=========================================
> ...
> >Instead, I suggest that (logical) announcements be identified by a
> >combination of (i) the "originator" (i.e., "o=") field, and
> >(ii) a creation timestamp (a new, manditory, field).
> 
> The issue of o=, h=, and unique ids is going to be revised.  I
> strongly dislike using the session name as part of the id.

Good.

> >6/ The treatment of time is inconsistent
> >========================================
> ...
> The concensus of the meeting in danvers was to move the start and stop
> times to a redefined t field.

Yes, this is a good idea.

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Apr 95 13:22:32 +0100

>to do with this (if anything).

Actually I disagree with you - if a field is present, it must be
interpreted by the application.  

As I said before, I don't really mind the concept of media stream
labels - I'm just not convinced that they should be i= fields - along
with the implied lengthy descriptions.  

>regret it.  

OK.

>Also, it'll be better to make the version field part of the
>you ever want to change this in the future.  

No, then you can't use SDP via email, WWW etc.  If it's in it has to
be a text field.

Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 Apr 95 14:00:36 +0100

Mark

in some senses the scalable multimedia multiservice net of the future
is basically a question of finding the right intersection of
hierarchies!

for example, we are now proposing a name hierarchy for sessions, and a
scope hierarchy for session directory servers

there is a proposal for hierarchical multicast addresses, as well as a
hierarchy of (area?) multicast routers...

there is a Class Hierarchy of traffic types/flows, so that
scheduling/reservations can be aggregated in routers...

and in CCCP we have a hierarchy of media types so that we can get
scalable conference control...

hier and hier:-)

 jon