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

[Colin Perkins <[e-mail]>]

Thanks - I do think that helps.
Colin



> On 8 Feb 2016, at 23:23, Adam Roach <[e-mail]> wrote:
> 
> Colin:
> 
> I've dropped a new version (-04) that incorporates this feedback. Please review the changes (https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-04) and confirm that they address your feedback.
> 
> /a
> 
> On 2/8/16 14:46, Adam Roach wrote:
>> On 2/4/16 18:17, Colin Perkins wrote:
>>>> On 3 Feb 2016, at 16:14, Adam Roach <[e-mail]> wrote:
>>>> 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.
>>> I’m not volunteering, but I think the problem is smaller than it seems, since this only applies to video codecs that have flexibility in encoding. Many of those 100 RFCs are for audio, text, or FEC formats, and many of the remaining are for video codecs are have insufficient flexibility to be impacted by the constraints, or are effectively obsolete.
>>> 
>>> At the least, it ought to do the analysis and mapping of a=fmtp parameters to rid constraints for the small number of modern codecs that people are likely to use - the WebRTC recommendations, for example.
>> 
>> It seems that anything less than full coverage would be difficult to do in a normative way, unless we restrict RIDs for use with the subset of codecs we decided to analyze.
>> 
>> That said, it seems reasonable and tractable to have a non-normative description of how the fmtp parameters of two codecs you indicate interact with the constraints defined in this document. I'll make a run at this and put the results out as a -04.
>> 
>>>> 
>>>> 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.
>>> I thought this wasn’t do bad: “registrations of future RTP payload format specifications that define media types that have parameters matching the RID constraints specified in this memo SHOULD name those parameters in a manner that matches the names of those RID constraints, and SHOULD explicitly state what media type parameters are constrained by what RID constraints”?
>>> 
>>> IANA considerations: "this draft updates RFC 4855 to give additional guidance on choice of parameter names, and on their relation to RID constraints [RFC XXXX]”
>> 
>> I'm happy to add your proposed text, but I'm going to very quick to suggest pulling it out if it looks like it's going to slow down this document. It's really not the core purpose of this spec to fix PAYLOAD's format parameter naming morass.
>> 
>> /a
> 



-- 
Colin Perkins
https://csperkins.org/