Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value

[Paul Kyzivat <[e-mail]>]

On 8/5/14 10:12 AM, Brett Tate wrote:
> Hi,
>
> Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of
> attribute fields.  However, it doesn't appear to clearly indicate the
> validity/invalidity of colon without a value.
>
> Is an attribute such as "a=rtcp-xr:" valid?  For instance, RFC 3611
> indicates that it is valid; however errata 3795 indicates that it
> potentially shouldn't be valid.
>
> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify
> the topic?

Yes, it probably should.

Given how established SDP is, I think we need to be careful about *how* 
we clarify it, to minimize compatibility issues.

The referenced erratum says that for one particular attribute the colon 
is required even if there is no value after it. And the proposed fix is 
to only permit the colon if there is a value.

Another possibility would be to make the colon optional if there is no 
value.

I am inclined to think that the *generic* syntax for attributes ought to 
work that way, in order to be most forgiving. The current syntax is:

    attribute =           (att-field ":" att-value) / att-field

    att-field =           token

    att-value =           byte-string

    byte-string =         1*(%x01-09/%x0B-0C/%x0E-FF)
                          ;any byte except NUL, CR, or LF

I think we should at least *consider* changing it to:

    attribute =           att-field [ ":" [att-value] ]

It would be good to hear from anybody who thinks this change would be 
troublesome.

Possibly the syntax of individual attributes can continue to be more 
restrictive. That will certainly be the case until/unless they are all 
updated.

In principle we need to confront *that* for each of the attributes 
defined in 4566 if we are going to give ABNF for each of them. But it is 
only of concern for an attribute where the value is optional. I don't 
think that is the case for any attributes defined in 4566.

	Thanks,
	Paul