Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED

[Christian Groves <[e-mail]>]

> Hello Paul,
>
> No worries. Please see below.
>
> I guess the question is whether you want to use the same syntax as 
> what has already been defined or whether you want to offer new syntax 
> imposing extra restrictions. No clear answer on that one.
>
> Regards, Christian
>
> On 13/08/2014 2:07 AM, Paul Kyzivat wrote:
>> Christian,
>>
>> Thanks for being the first with feedback! Comments inline.
>>
>>     Thanks,
>>     Paul
>>
>> On 8/11/14 10:23 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> A few comments:
>>>
>>> a=rtpmap:
>>> -----------
>>>      a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
>>>        parameters>]
>>>
>>>           Syntax:
>>>
>>>           rtpmap-value = payload-type SP encoding-name "/" clock-rate
>>>             [ "/" encoding-params ]
>>>           payload-type = integer
>>>           encoding-name = token ; ?
>>>           clock-rate = integer
>>>             ; do we want to define a limited range for this?
>>>           encoding-params = token ; ?
>>>             ; 4566 is vague about what this can be. The only example is
>>> an integer.
>>>             ; nor is it clear how multiple params would be encoded
>>>
>>> 1) Would you be better sticking to "fmt" for the payload-type as 
>>> that is
>>> what is already used in the 4566 syntax? i.e.
>>>
>>>     media-field =         %x6d "=" media SP port ["/" integer]
>>>                           SP proto 1*(SP fmt) CRLF
>>
>> rtpmap is only used for protos from the rtp family, where the fmts 
>> are integers. So I don't think we should be more general than that.
>>
>> IIUC, the pt is carried in a fixed size field in RTP, so we might 
>> want to limit the range to what that allows.
> [CNG] I was thinking also of consistency. Your a=ftmp syntax uses 
> "fmt" for the same field.
>
>>
>>> 2) encoding-name: According to RFC4855 the media subtype 
>>> (encoding-name)
>>> is encoding according to RFC2045 i.e. subtype := extension-token /
>>> iana-token. If you want to get more precise you could refer to RFC4288
>>> cl. 4.2.
>>
>> Thanks for the research!
>>
>> Section 3 of RFC4855 (Media Type Registration of RTP Payload Formats) 
>> says that encoding-name is equivalent to <subtype> defined in RFC2045.
>> This ultimately seems to be <token> defined in that rfc. And that is:
>>
>>      token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>>                  or tspecials>
>>
>>      tspecials :=  "(" / ")" / "<" / ">" / "@" /
>>                    "," / ";" / ":" / "\" / <">
>>                    "/" / "[" / "]" / "?" / "="
>>
>> This is hard to reference directly. But if you study it, it is 
>> equivalent to the RFC4566 definition of <token>.
>>
>> RFC4855 also refers to RFC4288 (Media Type Specifications and 
>> Registration Procedures) as the basic mechanism for registering 
>> encoding-names as mime subtypes. The definition there is more 
>> restrictive:
>>
>>        reg-name = 1*127reg-name-chars
>>        reg-name-chars = ALPHA / DIGIT / "!" /
>>                        "#" / "$" / "&" / "." /
>>                        "+" / "-" / "^" / "_"
>>
>> So I think we have to possibilities:
>>
>>          encoding-name = token
>>          encoding-name = subtype-name
>>            ; as defined in RFC4288
>>
>> Since the names must be registered, I think we are safe in going the 
>> easy way and just using <token>.
> [CNG] I think it would be better to use the restrictive syntax. If the 
> IANA procedures say one thing and the syntax another, its open to 
> heartache at some point. Token doesn't equal reg-name.
>
>>
>>> 3) RFC4855 last paragraph cl.3 indicates case insensitivity.
>>
>> OK. That has to be specified in semantics, not syntax.
> [CNG] Yes
>>
>>> 4) For the Clock Rate and Encoding parameters RFC4288 cl.4.3 indicates
>>> requirements for the names / values.
>>
>> That gives the generic syntax for all names and values. But these 
>> parameters are intended to be numeric. Do we really want to use a 
>> syntax that allows them to be non-numeric?
> [CNG] I agree clock rate is meant to be numeric. The general encoding 
> parameters could basically be anything.
>>
>>> a=sdplang & a=lang
>>> --------------------
>>> 1) Do you have the right reference in:
>>> sdplang-value = Language-Tag ; defined in RFC5234
>>>
>>> should this be RFC5646?
>>
>> Yes. That is where I was looking. I just typed the wrong thing.
>>
>> Examining that definition further, it is a proper subset of SDP 
>> <token>. We may prefer to just use that, since the registries will 
>> enforce the subsetting for valid tags.
> [CNG] Even though it may ultimately be a token I think its worth 
> referencing the RFC5646 syntax. At least people then are forced to try 
> and understand it. If its just left as TOKEN it could be anything.
>>
>>
>>> a=framerate
>>> -----------
>>> 1) positive-real-number = (integer / "0") [ "." *integer ]  is the *
>>> before the last integer needed? It would make sense if integer was 
>>> digit.
>>
>> Oops. What I meant was:
>>
>>          positive-real-number = (integer / "0") [ "." [integer] ]
>>
>> Or we could be more restrictive, as:
>>
>>          positive-real-number = (integer / "0") [ "." integer ]
> [CNG] I can't see why someone would use "1." which the first option 
> would allow. I'd prefer the restrictive option however I can see the 
> argument that given the number of implementations out there it may pay 
> to be more lax.
>>
>>
>>> a=quality
>>> ---------
>>> 1) If the value range is 0 to 10. Should you limit the values in the
>>> syntax also? i.e. just using "integer" would allow sending "11".
>>
>> I saw that. But it says *for video* the range is 0 to 10. But AFAIK 
>> this isn't restricted to use for other types of media. It just 
>> doesn't define what it means for other media.
> [CNG] Perhaps it might be worth proposing that this is only for video 
> and see if anybody screams? If someone is using a value quality=150 
> for audio. What does that mean? Outside of some proprietary usage it 
> doesn't seem particularly interoperable.
>>
>>     Thanks,
>>     Paul
>>