Subject: SDP issues

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Apr 2000 14:55:49 -0400

During the SIP bake-off, two SDP-related issues were raised:

Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
at least one character. It doesn't seem necessary to enforce that s=
have anything in them (like a space). Other textual Internet protocols
seem to be fine with having empty unformatted fields (like Subject: in
email).

Secondly, the rtpmap description does not specify whether the 'encoding
name' is case-sensitive or not. Since it's also used as a media type and
media types are case-insensitive (RFC 2616, 3.7), it probably makes
sense to make them CI in SDP as well.

Comments are appreciated.

Henning

---

From: Jeff Ayars <[email-masked]>
Date: Sat, 22 Apr 2000 17:44:00 -0700

>seem to be fine with having empty unformatted fields (like Subject: in

Sounds like s= might as well be optional then.  There's already a great 
deal of flexibility in SDP that makes interoperation difficult.  The field 
is marked as required in the spec and the grammar for "text" is clearly 1 
or more.  I don't see a compelling reason to change this.

>sense to make them CI in SDP as well.

I completely agree with this clarification.  We have always treated it as 
case-insensitive and a consistent interpretation is needed for interoperation.

Jeff Ayars
Technical Lead, Core Technologies
RealNetworks, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Apr 2000 20:50:25 -0400

> or more.  I don't see a compelling reason to change this.
Any half-way robust implementation needs to be able to deal with missing
s= and with s= followed by nothing. Might as well get the benefit of
allowing it officially.

---

From: Mark Handley <[email-masked]>
Date: Sat, 22 Apr 2000 19:12:47 -0700

>s= and with s= followed by nothing. Might as well get the benefit of

Whatever you might wish the SDP spec would say, it's fairly clear on
this issue: if there's no s= line, you should treat the SDP as
corrupted and act accordingly.  If you send SDP without the s= line,
you are definitely not compliant with RFC 2327 and shouldn't expect
your message to be accepted.

Changing the spec at this stage would introduce backward compatibility
issues, so should not be done lightly.  The more incompatible changes
we introduce, the less likely we are to be able to move SDP (and hence
SIP and RTSP) to Draft Standard without cycling it at Proposed
Standard first.

Cheers,
	Mark

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 16:57:38 -0400

There was another issue raised; SDP says very little overall about case
sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
depend on the type. The only types which discuss case sensitivity are:

1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
seconds) characters are case sensitive.
2. a=charset:, which uses case insensitive matching for the character
set.

So, we also agreed that in the spirit of SDP, all other values are CASE
SENSITIVE unless otherwise noted. This includes the encoding name
Henning mentions below, which, along with the character set, represent
the only two case insensitive matches in SDP (I believe).

-Jonathan R. 

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jeff Ayars <[email-masked]>
Date: Sun, 23 Apr 2000 22:13:36 -0700

>the only two case insensitive matches in SDP (I believe).

I'm confused by this last paragraph.  First you say all 'other' values are 
CASE SENSITIVE.  Then you say that encoding name, along with the character 
set represent the only two case insensitive matches.

So are you agreeing that <encoding name> from a=rtpmap and <media> from m= 
should be CASE INSENSITIVE?  Or are you saying that since SDP is silent on 
the case sensitivity of <encoding name> and <media> that they should be 
CASE SENSITIVE?

I agree with Henning's suggestion below that since <media> and <encoding 
name> form a media type and media types are CASE INSENSITIVE, that <media> 
and <encoding name> should also be CASE INSENSITIVE.

Jeff Ayars
Technical Lead
RealNetworks, Inc.

---

From: Mark Handley <[email-masked]>
Date: Sun, 23 Apr 2000 23:05:29 -0700

>the only two case insensitive matches in SDP (I believe).

RFC 2367 states:

   An SDP session description consists of a number of lines of text of
   the form <type>=<value> <type> is always exactly one character and is
   case-significant.  <value> is a structured text string whose format
   depends on <type>.  It also will be case-significant unless a
   specific field defines otherwise.

The only place where RFC 2367 states that something is case-insentive
is in the case of the charset attribute.

By default, this means that attributes are case-sensitive unless
specified otherwise, and all other fields are case-sensitive.

In the case of the rtpmap attribute, the issue of the meaning of
encoding names is punted to the relevant RTP profile spec.  As far as
SDP is concerned, they're case _sensitive_ by virtue of not specifying
otherwise.  However, the RTP AV profile specifies that the encoding
name is a MIME subtype, and I believe MIME specifies that subtypes are
not case sensitive.  Hence when rtpmap is used with protocol "RTP/AVP"
(and it's not currently specified for any other protocol), then
although the SDP string is case-sensitive to the SDP parser, it makes
sense to treat the encoding name as case-insensitive.  The rest of the
rtpmap attribute would still be case-sensitive.

BTW RFC 2327 also specifies:

   SDP session descriptions are entirely textual using the ISO 10646
   character set in UTF-8 encoding. SDP field names and attributes names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values may use the full ISO 10646 character set.

Thus the rtpmap attribute (with the exception of the attribute name
("rtpmap") itself) is also in ISO 10646 UTF 8.  However, the encoding
name is going to have to be in the US ASCII subset of ISO 10646 UTF 8
to be a valid MIME subtype, although the SDP syntax allows non-ASCII
encoding names.  

The key point is that SDP doesn't specify how to interpret the
encoding-name at all.  The RTP AV profile specifies this, and so adds
additional semantics to the basic SDP syntax.  

Cheers,
	Mark

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Apr 2000 02:27:46 -0400

>    specific field defines otherwise.

Duh. Of all the sentences in the spec I miss, somehow its this one. My
apologies. I'm glad at least the recommended clarification we made fits
with whats actually in the spec :)

-Jonathan R.

---

From: Chip Sharp <[email-masked]>
Date: Mon, 24 Apr 2000 11:16:11 -0400

Thanks for the clarification.

When moving to Draft,  the ABNF should be made consistent with the main 
text in regards to case-sensitivity.

RFC2234 (ABNF) states:
"NOTE:     ABNF strings are case-insensitive and
            the character set for these strings is us-ascii."

An example of the change needed in the ABNF is:
      attribute-fields =    *("a=" attribute CRLF)
should be:
      attribute-fields =    *(%x61 attribute CRLF)

Chip

>additional semantics to the basic SDP syntax.

-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Apr 2000 11:55:38 -0400

>       attribute-fields =    *(%x61 attribute CRLF)

Are you sure that applies to the protocol specified by the grammar or
just to the tokens within the ABNF, so that "CRLF" and "crlf" are
equivalent?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Chip Sharp <[email-masked]>
Date: Mon, 24 Apr 2000 12:29:43 -0400

>just to the tokens within the ABNF, so that "CRLF" and "crlf" are

These days, I'm not "sure" of much of anything. :-)

I don't believe RFC2234 is very clear on this issue either.
However, if you look at page 5 under "Concatenation" there is this example:

----begin quote----
    A rule can define a simple, ordered string of values -- i.e., a
    concatenation of contiguous characters -- by listing a sequence of
    rule names.  For example:

         foo         =  %x61           ; a

         bar         =  %x62           ; b

         mumble      =  foo bar foo

         So that the rule <mumble> matches the lowercase string "aba".