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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Aug 2014 18:10:01 -0400

I took an action item to make a proposal for the syntax of attributes in 
4566bis.

I've *started* on it, and have enough that I would like to get some 
feedback before going further.

Attached is a snippet from section 6 of 4566bis (SDP Attributes) to 
which I have added some ABNF syntax for just the values. (Each addition 
starts with "Syntax:")

This isn't necessarily the *form* it will take when done. For now what 
I'm looking for is feedback on the substance.

Of particular concern - when the format has text values, should those be 
case-sensitive (the default for SDP), or case-insensitive? I think we 
need to sort this out by what the common usage is.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Aug 2014 12:06:01 -0400

I made some corrections based on offline comments from Christian Groves. 
Revised version attached.

	Thanks,
	Paul

On 8/11/14 6:10 PM, Paul Kyzivat wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Fredrik Bergholtz <[email-masked]>
Date: Wed, 13 Aug 2014 11:37:47 +0000

Good job.

I wonder if it would be wrong or bad to change

    fmtp-value = fmt SP format-specific-params

to

    fmtp-value = payload-type SP format-specific-params

thus using the definition of payload-type from a=rtpmap rather than adding a new definition of fmt that would, as I understand it, be essentially the same.

Another issue is that I know of one "extension" that would become invalid if this syntax for a=ptime is introduced. This extension is not yet an official extension of SDP but the standard is accepted as of 2013 within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states:

    8.1 Packet time
    Packet time is described with two SDP attributes defined in RFC 4566.

        a=ptime <milliseconds>[.<milliseconds decimal>]
        a=maxptime <milliseconds>[.<milliseconds decimal>]

    Signaled packet time multiplied by sampling frequency rounded to the nearest integer indicates the number of
    samples in each packet. The packet time descriptions shall be given with error less than half a sample period so
    that the calculated number of samples per packet rounds to the intended integer value. In many cases, this
    requires the inclusion of the <milliseconds decimal> in the description.

If SDP is to allow that kind of usage, the type for ptime, and possibly also maxptime, should be the positive-real-number definition as used in a=framerate:

    packet-time = positive-real-number

Concerning the questions about adding range limits on values, I think that only if the value references something that is range- limited by specification, such as RTP payload type, should the SDP specify a matching range limitation. This means that the integer of the payload-type should be limited to a seven bit, unsigned integer. The other class of values would be values that are limited only by implementation. Among these I count packet times, clock rates, frame rates etc. For these values I would prefer that SDP does not limit the ranges.

Best regards
Fredrik Bergholtz
Swedish Radio

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: den 12 augusti 2014 18:06
> To: [email-masked]
> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
> 
> > I took an action item to make a proposal for the syntax of attributes
> > in 4566bis.
> >
> > which I have added some ABNF syntax for just the values. (Each
> > addition starts with "Syntax:")
> >
> > Of particular concern - when the format has text values, should those
> > be case-sensitive (the default for SDP), or case-insensitive? I think
> > we need to sort this out by what the common usage is.
> >
> >      Thanks,
> >      Paul
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Aug 2014 10:47:33 -0400

> thus using the definition of payload-type from a=rtpmap rather than adding a new definition of fmt that would, as I understand it, be essentially the same.

That would be wrong.

The definition of each <proto> gets to constrain the syntax of the <fmt> 
values allowed with it. The RTP family of <proto> values require that 
the <fmt> values be integers. So when those same values show up in 
rtpmap, they are still constrained to be integers, because rtpmap is 
only used in those cases.

OTOH, fmtmap may be used with any <proto> type, so it must allow the 
more general value.

>      packet-time = positive-real-number

If this is being proposed as an *extension*, what provision is being 
made for backward compatibility? I suspect many implementations won't 
accept a fractional value.

> Concerning the questions about adding range limits on values, I think that only if the value references something that is range- limited by specification, such as RTP payload type, should the SDP s…

I'm not inclined to impose the range in *syntax*.
We can specify it as a semantic constraint, but should probably be 
careful about when we do this. So I'm looking for opinions about when it 
is important to specify this and when it is not - on a case by case basis.

	Thanks,
	Paul

---

From: Fredrik Bergholtz <[email-masked]>
Date: Wed, 13 Aug 2014 16:44:33 +0000

Ah. I did not consider the reality of other transport than RTP, thanks for reminding me. :-)

I understand the backwards compatibility risk of the ptime route taken in AES67. I have been working with another possible future extension that has some theoretical overlap with AES67. In this we used a different approach of extending ptime functionality by introducing a completely new attribute. This work is being done by a subgroup of the ACIP working group of the European Broadcasting Union (EBU). The EBU work is just about ready as a first draft to be agreed upon within EBU. The actual path of getting this or the AES work approved by IETF has not yet begun, but it is likely that feedback such as this will cause changes in both the AES standard and the coming EBU standard. 

I agree that range constraints would have to be carefully thought through. In light of this I think that I change my vote to not having any such constraints at all. Of course, I don't have the full understanding of all attributes and there may be some that I am unaware of that would benefit from this. So I suppose that I didn't really help answering the questions.

Thanks,
Fredrik Bergholtz
Swedish Radio
 
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: den 13 augusti 2014 16:48
> To: Fredrik Bergholtz; [email-masked]
> > thus using the definition of payload-type from a=rtpmap rather than 
> > adding a
> new definition of fmt that would, as I understand it, be essentially the same.
> 
> That would be wrong.
> 
> The definition of each <proto> gets to constrain the syntax of the 
> <fmt> values allowed with it. The RTP family of <proto> values require 
> that the <fmt> values be integers. So when those same values show up 
> in rtpmap, they are still constrained to be integers, because rtpmap is only used in those cases.
> 
> > Another issue is that I know of one "extension" that would become 
> > invalid if
> this syntax for a=ptime is introduced. This extension is not yet an 
> official extension of SDP but the standard is accepted as of 2013 
> within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states:
> >
> >      8.1 Packet time
> >      Signaled packet time multiplied by sampling frequency rounded 
> > to the
> nearest integer indicates the number of
> >      samples in each packet. The packet time descriptions shall be 
> > given with
> error less than half a sample period so
> >      that the calculated number of samples per packet rounds to the 
> > intended
> integer value. In many cases, this
> > If SDP is to allow that kind of usage, the type for ptime, and 
> > possibly also
> maxptime, should be the positive-real-number definition as used in a=framerate:
> >
> > Concerning the questions about adding range limits on values, I 
> > think that only
> if the value references something that is range- limited by 
> specification, such as RTP payload type, should the SDP specify a 
> matching range limitation. This means that the integer of the 
> payload-type should be limited to a seven bit, unsigned integer. The 
> other class of values would be values that are limited only by 
> implementation. Among these I count packet times, clock rates, frame rates etc. For these values I would prefer that SDP does not limit the ranges.
> 
> careful about when we do this. So I'm looking for opinions about when 
> it is important to specify this and when it is not - on a case by case basis.
> 
> 	Thanks,
> 	Paul
> 
> > Best regards
> > Fredrik Bergholtz
> > Swedish Radio
> >
> >
> >>> I took an action item to make a proposal for the syntax of 
> >>> attributes in 4566bis.
> >>>
> >>> I've *started* on it, and have enough that I would like to get 
> >>> some feedback before going further.
> >>>
> >>> Attached is a snippet from section 6 of 4566bis (SDP Attributes) 
> >>> to which I have added some ABNF syntax for just the values. (Each 
> >>> This isn't necessarily the *form* it will take when done. For now 
> >>> what I'm looking for is feedback on the substance.
> >>>
> >>> Of particular concern - when the format has text values, should 
> >>> those be case-sensitive (the default for SDP), or case-insensitive?
> >>> I think we need to sort this out by what the common usage is.
> >>>
> >>>       Thanks,
> >>>       Paul
> >>>
> >>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 14 Aug 2014 09:42:28 +1000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Aug 2014 13:33:59 -0400

[trimming a little bit for clarity]

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

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

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

>> argument that given the number of implementations out there it may pay

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?

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