Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-rid-14: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 15 May 2018 19:42:50 -0500

On 4/17/18 2:46 PM, Benjamin Kaduk wrote:
> Presumably I'm just being dense, but from perusing the formal grammar
> I couldn't decide if it's allowed to have both PT and parameter
> restrictions applied on the same rid-id.

That's the intention, yes. If you're looking at the formal grammar, the 
key here is:

rid-pt-param-list = SP rid-fmt-list *(";" rid-param)

Where <rid-fmt-list> is the "pt=..." production, and <rid-param> is the 
parameter restriction production.

> Section 5
>
> Similarly (me being dense), I'm a bit confused at the relationship between
> max-fps and max-pps -- aren't there encodings that can send update frames that
> do not include the full pixel density of a frame?

Yes -- the intention here (I believe; this is inherited text) is that 
the restriction applies to decoded frames rather than some notion of the 
number of pixels represented by on-the-wire bits. One might presumably 
use this when the communication bus between the CPU and the screen 
requires full-frame refreshes, and has a bottleneck somewhere along the 
path that limits how quickly such data can be transmitted.

> Section 6.2.2
>
>     4.  If the "direction" field is "recv", The answerer ensures that
>         "a=rid" restrictions are supported.  In the case of an
>         unsupported restriction, the "a=rid" line is discarded.
>
> "that "a=rid" restrictions are supported" reads like a feature test
> for being able to parse a=rid at all, but the context suggests that
> this is intended to refer to the Section-5 restriction stanzas that
> appear on an a=rid line.

Well spotted. It's the latter. The confusion arises because the sentence 
is missing an article. Updated to read:

  4. If the "direction" field is "recv", the answerer ensures that the 
specified
     "a=rid" restrictions are supported.  In the case of an unsupported
     restriction, the "a=rid" line is discarded.

> Section 8
>
> I thought I remembered something going by to the effect of s/non-empty
> union/non-empty intersection/ but didn't find it in a quick search, so dropping
> a note just in case.

Another good catch. There are two references to "non-empty union" that 
clearly mean "non-empty intersection." Fixed.

> Section 8.2
>
>     The following codec format parameters correspond to restrictions on
>     receiver capabilities, and never indicate sending restrictions.
>
> Maybe "The codec format parameters covered in the following
> subsections [...]"?

That's an improvement. Updated accordingly.

> Section 10
>
> Should
>      float-param-val   = 1*DIGIT "." 1*DIGIT
> have the last entry be 1*4DIGIT to catch the "four digits after the
> decimal place" requirement of max-bpp, or are we leaving the float-param-value
> grammar less restricted in case of potential future use?
>

The notion here is to leave it open for re-use by future floating-point 
values.

You can view the diffs between -14 and -15 at 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rid-14&url2=draft-ietf-mmusic-rid-15>

/a