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 https://github.com/w3c/webrtc-pc/issues/2845#issuecomment-1484992256

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](https://www.rfc-editor.org/rfc/rfc5234#appendix-B.1) 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).