Subject: [MMUSIC] QUERY: are SDP attributes case sensitive?

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2014 10:50:49 -0400

While thinking about how to give syntax for SDP attributes, I realized 
that it is not entirely clear whether SDP attribute names are intended 
to be case sensitive or not. 4566 says:

    An SDP session description consists of a number of lines of text of
    the form:

       <type>=<value>

    where <type> MUST be exactly one case-significant character and
    <value> is structured text whose format depends on <type>.  In
    general, <value> is either a number of fields delimited by a single
    space character or a free format string, and is case-significant
    unless a specific field defines otherwise.  Whitespace MUST NOT be
    used on either side of the "=" sign.

And I find nothing stating that attributes are case sensitive.

This is fine for attributes that are defined informally - they don't say 
anything to imply that attribute names are case insensitive. But it is a 
problem for those defined using ABNF. For example, consider the 
following definition from RFC5888:

            group-attribute     = "a=group:" semantics
                                  *(SP identification-tag)
            semantics           = "LS" / "FID" / semantics-extension
            semantics-extension = token
                                  ; token is defined in RFC 4566

ABNF says that matching against rules containing quoted strings is 
case-insensitive. So the above considers all of the following to be valid:

a=group:ls
A=GROUP:LS
a=Group:Ls

The SDP spec disallows the 'A=', but maybe not the others.

If you want to specify a case-sensitive string constant in ABNF you must 
do so by specifying each byte numerically. That isn't very convenient or 
readable. (We do it for SIP method names, and I hate it.)

A straightforward solution to this is to only specify the attribute 
*values* with ABNF, not the *names*. Specify the names independently, 
and note that they are case sensitive.

But that won't help for those that have already been defined in other 
drafts using ABNF and quoted strings.

What I really want to avoid is saying that we are defining syntax using 
ABNF, but that *our* ABNF treats quoted strings in a case-sensitive way. 
If that is what we want, then we should try to get an upgrade to ABNF to 
support both case-sensitive and case-insensitive strings.

For *values*, if they are already defined in ABNF, then case sensitivity 
is as defined by ABNF. We might have to be very careful about this when 
defining the syntax for the attributes defined in 4566.

A couple of questions:

1) does anybody think attribute *names* are/should-be case-*in*sensitive?

2) does anybody think that the ABNF *values* currently defined in ABNF 
(such as the example from 5888 above) are intended to be matched in a 
case-*sensitive* way in violation of the ABNF matching rules?

	Thanks,
	Paul