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

[Adam Roach <[e-mail]>]

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