Comparison rules for RTCRtpCodec needs clarification on how mimeType is compared

[docfaraday]

Recently I've found multiple wpt that are doing case-sensitive comparisons on the mimeType field. Mime-types are case insensitive (see https://datatracker.ietf.org/doc/html/rfc2045#section-5.1); this should be called out in https://w3c.github.io/webrtc-pc/#dfn-codec-dictionary-match

[jan-ivar]

This is a side-effect of not using interfaces to represent platform codecs #2845 (comment)

Following that decision, it seems we need to support JS constructing the inputs to setCodecPreferences out of whole cloth, and we'd need to support case-insensitive mimeType matching here as RFC 2045 says.

[jan-ivar]

WPTs that conjure up inputs to test browser tolerance need to use case-insensitive match.

WPTs that solely operate on codecs emitted by the browser itself are probably fine checking that case matches IMHO.

[alvestrand]

A WPT should never depend on anything that is not written in the specs.
The fact that all implementations today are consistent about the case of their self-generated media types doesn't mean that a WPT can depend on that being so forever.

[jan-ivar]

I didn't mean WPTs relying on all browsers being consistent, only that they're self-consistent.

But sure, if @docfaraday can provide a list of the WPTs in question we can fix them to be case-insensitive.

Just seems a pity to allow some browser to return vIdEo/Vp8. I'm curious how other specs deal with this, if at all.

[alvestrand]

The SDP specs say that if a browser gets vIdEo/Vp8, it has to behave exactly as if it got ViDeO/vP8.
It is good if we test this.

[Orphis]

I did notice that and added some proper comparison in a few newer tests like in https://github.com/web-platform-tests/wpt/blob/master/webrtc-extensions/RTCRtpParameters-codec.html#L28

It would be interesting to clarify which method should be used in JS. Can the mimeType also contain UTF-8 characters?

[jan-ivar]

RTCRtpCodec's mimeType must be:

• "listed in [IANA-RTP-2]."
  • which states "Both type and subtype names are case-insensitive as defined in RFC4288."
  • it further says its "registration procedures ... can be found in [RFC4855]"
    • which says "RFC 4288 [1] defines media type specification and registration
      procedures that use the Internet Assigned Numbers Authority (IANA) as
      a central registry."
      • which is "Obsoleted by: 6838", where section 4.2 says
        • "Both top-level type and subtype names are case-insensitive."
        • and also

          Type and subtype names MUST conform to the following ABNF:
          
          type-name = restricted-name
          subtype-name = restricted-name
          
          restricted-name = restricted-name-first *126restricted-name-chars
          restricted-name-first  = ALPHA / DIGIT
          restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                                   "$" / "&" / "-" / "^" / "_""_
          

          • where ALPHA is defined in core rules as

            ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
            

This seems clear enough to me: case-insensitive, and no UTF. Can we close?

[jan-ivar]

Sorry my bad we need to update the codec dictionary match. I'll do a PR.

[jan-ivar]

It would be interesting to clarify which method should be used in JS. Can the mimeType also contain UTF-8 characters?

This is a good question. Since we take DOMString as an input, we need to lower-case JS input in order to compare it. While we could UTF-8 encode it to bytes and use byte-lowercasing, we can probably just use ascii-lowercase.

[alvestrand]

note - quote from 6886 is missing two lines:

 restricted-name-chars =/ "." ; Characters before first dot always
                              ; specify a facet name
 restricted-name-chars =/ "+" ; Characters after last plus always
                              ; specify a structured syntax suffix

• and . are permitted in names, and have special meaning (facet and structured syntax respectively).