codec.name - some complications

In WebRTC WG, Harald Alvestrand has pointed out potential issues in only returning the MIME subtype in the name attribute (or mimeType attribute in WebRTC 1.0).

For example, take a look at the IANA table:
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2

There are distinct entries for "audio/ulpfec" and "video/ulpfec" as well as  "audio/rtx" and "video/rtx"  as well as "audio/RED" (but NOT "video/RED"!).

One might argue that providing the MIME media type is unnecessary since calling getCapabilities("audio") or getCapabilities("video") allows the application to only retrieve codec with a MIME media type equal to the kind argument.

However, is it always the case that getCapabilities(kind) will only return codecs with a MIME media type of kind?

For example, AFAIK the W3C does not define a kind corresponding to each MIME media type (e.g. there is no kind for "text").  So if an ORTC implementation were to support a capability for a MIME media type which has no corresponding kind, it is not clear that these capabilities could be retrieved by calling getCapabilities(kind).

As an example, the IANA table has entries for "text/ulpfec", "text/rtx" and "text/red" (note the different spelling!).

So if an ORTC implementation were to support RFC 4103 (RTT), an application could call getCapabilities("text") in order to discover that the implementation supported "text/t140".