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

[Paul Kyzivat <[e-mail]>]

On 8/5/14 1:54 PM, Brett Tate wrote:
>> Given how established SDP is, I think we need to be careful about
>> *how* we clarify it, to minimize compatibility issues.
>
> I agree.  One option is potentially to keep it invalid.  A comment
> potentially could be added indicating that RFC 3611 is a reason to
> accommodate the unexpected ABNF expansion (i.e. sender not updated to
> comply with the errata).
>
>> 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.
>
> Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply with
> RFC 4566.
>
>> 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.
>
> It would cause the rfc4566bis attribute ABNF to not be backward compatible
> with RFC 4566 devices.
>
> This could cause issues with some RFC 4566 devices; however some already
> accommodate it for interoperability reasons.

In practice this is only an issue for attributes that are specified to 
be meaningful both with and without a value. We could investigate the 
current population to see how many fit into that category. I suspect it 
is very few.

My thought in proposing the change was to encourage those ignoring 
attributes they don't understand to also ignore those with a colon and 
no value. But we don't want to encourage people to do that. If we only 
have one case that called for this usage, then maybe we just deal with 
it there.

	Thanks,
	Paula

	Thanks,
	Paul