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

[Paul Kyzivat <[e-mail]>]

[trimming a little bit for clarity]

On 8/13/14 7:42 PM, Christian Groves wrote:

>>>> 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.

I explained this in another reply. rtpmap only applies in cases where 
the fmt happens to be a PT number, but fmtp can be used in cases where 
it is not.

>>>> 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.

I'm willing to go either way here. I'd like to get some other opinions.

My reasoning is that we don't need to define the syntax to constrain to 
only valid values because there is also a semantic constraint that the 
name used be registered.

>>>> 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.

My reluctance is because the definition in 5646 is long and complex. 
Anyone who wants to formally verify the SDP syntax would have to pull in 
that definition (and resolve any naming conflicts) to do the verification.

And the same argument I used above for encoding-name applies here as 
well: the name used in SDP must be one that has previously been defined 
in compliance with 5646.

What if we formally defined it as token but pointed to 5646 in a comment?

>>>> 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.

I don't care here - I'm looking for the choice that will cause the least 
trouble with existing implementations.

Can others chime in here please?

>>>> 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.

Does anybody think it is valid to use this with values outside the range 
[0-10], either with video or non-video media?

	Thanks,
	Paul