Re: [MMUSIC] Comments on ABNF in 4566bis

[Paul Kyzivat <[e-mail]>]

On 12/1/14 6:39 PM, Colin Perkins wrote:

>>> *a=rtpmap:*
>>> - payload-type is an integer in the range 0-127 in RTP
>>> - encoding-name is a MIME subtype, and should have the syntax to match this
>>> - is clock-rate always an integer?
>>
>> If there is no way that larger values could ever be used then I'm fine with calling out this restriction. I’ll probably do it in text rather than in ABNF.
>
> The payload type is a 7-bit field in the RTP header, so definitely cannot be outside this range. Writing this in the text makes sense.

ok

>>> *a=type:*
>>> - I assume a registry was intended, but it’s not clear there’s any need now
>>
>> Do you mean that you don't think we need a mechanism to define further values? Or that it would be sufficient to do so with another update to this document?
>
> This list hasn’t changed in RFC 2327 in 1998. I think it’s safe to leave updates to a future revision of this document.

ok

>> Do you know if these names were intended to be case sensitive? That is an important distinction to make. And whatever choice is made will potentially have backward compatibility problems for somebody.
>
> I expect the general rule at the start of Section 5 (top of page 8) applies:
>
>     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.
>
> Hence, this is case significant.

That is how I have the syntax written now.
So I'll leave it that way unless I get some other strong argument to 
change it.

>>> *a=charset:*
>>> - This is a name from the registry at
>>> http://www.iana.org/assignments/character-sets/character-sets.xhtml and needs to follow that syntax
>>
>> In this and other cases where what goes in the SDP is a reference to something defined in a registry, I am inclined to give a simplified syntax that might be a superset of what is permitted in the registry. It doesn't matter a whole lot if it allows some invalid values, because such names will never be in the registry.
>>
>> This will help implementers. And when the exact formal definition isn't available in ABNF, or is very complex, it can also ease formal checking of the SDP ABNF.
>>
>> Given that explanation, is there anything wrong with what I have?
>
> Why not reference the correct ABNF from RFC 2978? I don’t understand the desire to put something incorrect here.

I commented on this separately.

>>> *a=sdplang:* and *a=lang:*
>>> - Should reference the RFC5646 definition
>>
>> Same comment as charset.
>
> Same answer. There’s already a standard ABNF syntax for these, and this document should refer to it rather than trying to define something new.

OK. I can do that.

>>> *a=quality:*
>>> - I thought the intent here was a real number, in the range 0…10
>>
>> What I could find only discussed quality in the context of video media, and restricted the range to 0..10 in that case. But it didn't explicitly limit (or define) the use of quality for other media. It seems reasonable to me that the same range would apply to any media where quality applies, but I wasn't sure.
>>
>> Also, should the values here be restricted to integral values, or should fractional values be allowed?
>
> I always assumed fractional values were allowed, but you’d have to check with someone who’s implemented this.

I'm happy to do that if it isn't going to break anybody.

I *could* do it so that the fraction is only permitted if it is 
non-zero, as I proposed for another field. But that doesn't necessarily 
make things better if there are uses out there that include a zero 
fractional part.

>> BTW - I just noticed I have an error in my ABNF: I limit the quality-value to an integer, which excludes zero. So I need to change the abnf in one way or another.
>>
>>> *a=fmtp:*
>>> - The format parameters are MIME media type parameters, and need to
>>> reflect their syntax.
>>
>> My understanding is that the values are whatever was in the <fmt> field of the associated m-line. What is valid there is defined for each <proto> field. For the RTP variants, it is a payload type. For UDP it is a media (sub)type. But we can't know in general what if might be for other <proto>s, since new ones could be defined in the future.
>>
>> The m-line syntax defines the fmt as a token. So I figured that the same definition should be used here.
>
> For RTP, you do know explicitly that the <format specific parameters> in the a=fmtp: line are MIME media subtype parameters, and need to conform to that syntax.

We aren't concerned with the <format specific parameters> here.
(The syntax of those is format specific.:-)

We are only concerned with the <fmt> parameter, which replicates one 
from the m-line.

For RTP m-lines this will always be an integer. But for the most part 
rtpmap is used instead of fmtp for RTP format specific parameters. There 
is text saying to use fmtp for codec-specific parameters. So I guess if 
fmtp is used with RTP then one would first need to use rtpmap to 
determine the codec, and then use rules defined by that codec to parse 
the format specific parameters.

	Thanks,
	Paul