Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01

[Adam Roach <[e-mail]>]

On 2/2/16 11:41, Colin Perkins wrote:
> I didn’t find a precise specification in the draft for what RID parameters constrain what “a=fmtp:" parameters, for what RTP payload formats. I think this draft needs a complete list of which parameters are constrained by each RID parameter, to ensure unambiguous behaviour with existing codecs.

I fear such an approach may be intractable. On a quick analysis, I find 
almost 100 RFCs that define "a=fmtp" parameters, and most of those 
define more than one. If you want to volunteer to slog through that 
entire corpus and figure out which correspond to the constraints we're 
defining, I'll happily accept the output of that work. But I suspect 
you'll reach the same conclusion as I did: it's not a reasonable task.

That said, the principle here is pretty easy to grasp: when the "a=fmtp" 
parameters constrain your encoding in some way, and the "a=rid" 
parameters also constrain your encoding in some way, you need to meet 
both constraints simultaneously. If you think there's some text we can 
add to Section 9 to clarify this principle, I'm happy to expound on it. 
But I'm pretty certain that the future-proof approach here is to lay out 
a principle of interaction, rather than (for example) spending the 
energy to figure out how the "pgroup" parameter for SMPTE 292M might 
interact with any of the constraints we're defining, and then doing that 
same kind of analysis hundreds of times over.

> Also, to ensure consistency going forward, the draft should probably give some guidance to the PAYLOAD working group, mandating “a=fmtp:” parameter names for common features when defining future payload formats, so they match the RID parameter names if they’re intended to be restricted by RID parameters, and to use different names otherwise.

Trying to harmonize PAYLOAD's handling of <format specific parameters> 
seems to be somewhat outside the scope of what this document is doing. I 
mean, I get that the lack of coordination of constraining parameters on 
video codecs is a pretty sad state of affairs, but it's not really fair 
to shackle this draft to the task of solving that mess before it can 
move forward.

To be clear, I'd be happy to see some kind of guidance regarding <format 
specific parameters> put forth in an independent document so that there 
is at least a modicum of uniformity for future formats. I just think 
it's not in the scope of the RID work.

/a