Subject: SDP and order of tags

From: Christian Zahl <[email-masked]>
Date: Thu, 23 Jan 1997 18:59:02 +0000

To Mark!

I had some discoussions with some others about the order of the tags
in the SDP draft. As mentioned in my prior mail, I noticed that 
a lot of currently received SDP packets have misorderd tags. Well,
according to the draft, we have to ignore these packets!

In fact, there is no real reason for the strict order of the tags,
except for
	- the v= should be the very first tag
	- the Time Description group has to be started by t=
	- the Media Description group has to be started by m=

So all the other tags can occur anywhere in the packet. The hope,
that it is easier to write a simple parser when there is a strict 
order seems also not to be true. It is much easier to parse the packet
when the order is not fixed, eg. by using a "switch()". And this is
more flexible, because this parser still works when new tags will
be included in the SDP packet; they will simply ignored. It's much
more difficult to do that when your parser expect a fixed order of
the tags!

I also think, that the usage of the a=, k=, b= and c= before the 
"Media Description" should be removed. The gain when using these tags
as "global" definition, rather than specifying them in each media
description seems to be very small! And the current packets show
that often both informations are included in an SDP packet.

Anyway, the draft should give us more flexibility und should follow the
philosophy: "be conservative in what you send, be liberal in what you
accept". So the draft should allow us to use packets with misorderd
tags. I don't think that is realy necessary to define a strict order
for sending.

Any comments are wellcome,
Chris

---

From: Mark Handley <[email-masked]>
Date: Thu, 23 Jan 1997 13:22:01 -0500

>according to the draft, we have to ignore these packets!

Yes, the e and p fields are reversed in sdr.  This will be fixed soon.

>that often both informations are included in an SDP packet.

You have to be careful here - there is a two-level hierarchy (session
wide attributes and media attributes).  Some things only make sense in
one context or the other.  It isn't just for the purposes of compression.

Mark