RTCRtpCapabilities "features" ?

dictionary RTCRtpCapabilities {
     sequence<RTCRtpCodec> audioCodecs;
     sequence<RTCRtpCodec> videoCodecs;
     sequence<DOMString>   headerExtensions;
     sequence<DOMString>   features;
};


What is "features"? Is this a IANA style namespace that defines meaning 
to what rtp style "features" the browser engine supports?

The description for "features" currently says 'Supported RTP features, 
such as "nack" from [RFC4585 
<http://internaut.com:8080/%7Ebaboba/ortc/ortc-4-24-2014-revised.html#bib-RFC4585>].'

If it's a namespace type thing, would it define features such as support 
rtcp feedback parameters and other "future" rtp/rtcp capabilities?

Or is the intention to have "features" define exactly what stuff is 
supported for feedback parameters as per in RFC 4585?

If it's mean to define RTCP feedback mechanisms as per RFC 4585 then 
it's not quite right since:

rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

       rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                          / fmt   ; as defined in SDP spec

       rtcp-fb-val        = "ack" rtcp-fb-ack-param
                          / "nack" rtcp-fb-nack-param
                          / "trr-int" SP 1*DIGIT
                          / rtcp-fb-id rtcp-fb-param

       rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

       rtcp-fb-param      = SP "app" [SP byte-string]
                          / SP token [SP byte-string]
                          / ; empty

       rtcp-fb-ack-param  = SP "rpsi"
                          / SP "app" [SP byte-string]
                          / SP token [SP byte-string]
                          / ; empty

       rtcp-fb-nack-param = SP "pli"
                          / SP "sli"
                          / SP "rpsi"
                          / SP "app" [SP byte-string]
                          / SP token [SP byte-string]
                          / ; empty


.. would require a more detailed definition.

Basically, to give clear indication for rtcp feedback support, the 
capabilities would have to be more like this:

dictionary RTCRtpCapabilities {
     sequence<RTCRtpCodec> audioCodecs;
     sequence<RTCRtpCodec> videoCodecs;
     sequence<DOMString>   headerExtensions;
     sequence<RTCRtcpFeedbackCapability>   feedbackParamters;
};


dictionary RTCRtcpFeedbackCapability {
     DOMString  type;    // e.g. "ack", "nack", "trr-int", ...
     sequence<DOMString >   value;    // e.g. for "nack" would be list 
of "pli", "sli", "rpsi", "app"
};


I'm guessing since we already have a list of "RTCRtcpFeedbackParam" for 
each codec which can indicate that information per codec for feedback 
mechanisms that Rtc capability "features" is meant to be an IANA style 
namespace set of features supported by the browser engine.

But if a "feature" was listed as string "nack", does that mean the 
browser engine supports all types of "nack", e.g.: "pli", "sli", "rpsi", 
... ? (personally, I don't think that makes much sense). If it doesn't 
mean all are supported then does "nack" mean that 'at least one (or 
more) of the "nack" feedback mechanisms are supported'? In that case 
would we say "to know exactly what rtcp feedback mechanisms are 
supported, the application would have to obtain the per codec rtcp 
feedback parameters to know what feedback parameters are available"?

So I propose that "features" is left as is, i.e. a sequence of 
DOMStrings and that it represents an IANA style definition of RTP 
"features" that are available and that for each feature we define what 
that feature means. And in the case of "nack", I think 'at least one or 
more of "pli", "sli, "rpsi", "app" is supported but details are left to 
be discovered inside codec parameters.

If others have use cases where we need a "capabilities" style mechanism 
to discover more detailed but generalized (i.e outside each codec) 
possible rtcp feedback mechanisms then I suggest we add 
"sequence<RTCRtcpFeedbackCapability>   feedbackParamters;" to the 
RTCRtpCapabilities dictionary, but I'm not in favour of that unless we 
have a strong need.

Thoughts?

-Robin