[MMUSIC] syntax for attributes in 4566bis

[Paul Kyzivat <[e-mail]>]

I have been working on an SDP Directorate review of a draft that defines 
some new SDP attributes. In the process of doing that I came across some 
things that I think ought to be improved in 4566bis:

1) The formal syntax for SDP in 4566 defines a generic syntax for 
attributes:

    attribute-fields =    *(%x61 "=" attribute CRLF)
    attribute =           (att-field ":" att-value) / att-field
    att-field =           token
    att-value =           byte-string

This is fine. Elsewhere it defines a number of specific attributes:

       a=cat:<category>
       ...
       a=keywds:<keywords>
       ....

These are defined with informal patterns such as above, along with text. 
There is no formal specification of the syntax of the values of these 
attributes.

Then in the IANA considerations section these attributes are added to 
the IANA registry of SDP attributes.

The main problem with the above is the lack of syntax for the values.
With newer attributes in other drafts we have typically required ABNF. I 
think 4566bis ought to provide ABNF syntax for all of the attributes it 
defines.

2) If syntax is to be provided, then there is a question of *how* it 
should be done. There are a number of possibilities. Here are two:

- link it right into the full SDP syntax. E.g.,

    cat-attr = "cat:" category
    category = token
    attribute =/ cat-attr

- define the syntax of the attribute, but *don't* link it into the
   the full SDP syntax.

In my opinion it is better to *not* link into the general syntax. It 
doesn't matter much for this draft, but it sets a bad precedent for 
other drafts that define attributes. Each draft that does so (via use of 
'attribute =/ ...' is an *update* to the rfc that defines 'attribute', 
and should be marked as such.

The existence of the IANA registry for attributes means that it is not 
necessary to formally extend the syntax of 'attribute' and so the draft 
need not be an update.

Whatever we do here will become a defacto template for how future drafts 
define attributes. So we should make it a good example.

3) The IANA registration of attributes has become a mess. Section 8.2.4 
both defines the IANA registry for attributes and populates it with the 
attributes defined in the draft. But it doesn't precisely specify the 
name or format of the table. It *does* specify what information must be 
provided.

What is actually present in IANA are *four* different tables for attributes:

SDP Parameters att-field (both session and media level)
SDP Parameters att-field (media level only)
SDP Parameters att-field (session level)
SDP Parameters att-field (source level)
SDP Parameters att-field (unknown level)

This is hard to read, and its hard for a draft to specify precisely what 
table things should go in.

I suggest it would be good to reorganize the IANA registry, so that it 
only has one table, with a separate column (or columns) to indicate 
where the attribute may be used: session, media, source.

Then ensure that the registrations for the attributes defined in the bis 
are good examples of how to use this, including explicitly referencing 
the table to be updated.

4) RFC5576 introduced the notion of source-level attributes. In 
principle the same attributes may be used at source level and the other 
levels, so they should be incorporated into the same table structure. 
Some thought ought to be given to how to ensure 4566bis integrates well 
with 5576 regarding definition and registration of attributes. Perhaps 
it would be better to make 4566bis replace 5576 as well. Or maybe that 
isn't necessary. Should be discussed.

	Thanks,
	Paul