"Get Supported Capabilities for Audio/Video Type" algorithm should treat null contentType the same as invalid contentType

[cpearce]

The "Get Supported Capabilities for Audio/Video Type" algorithm has these steps:

1. If content type is the empty string, return null.
2. If content type is an invalid or unrecognized MIME type, continue to the next iteration.

An empty content type string is invalid. Why isn't it treated the same as other invalid or unrecognized MIME types, where we'd skip that content type and continue the next iteration? Why is an empty content type worse than other forms of invalid MIME types?

I propose we merge these two steps into:

1. If content type is the empty string, or is an invalid or unrecognized MIME type, continue to the next iteration.

[ddorwin]

The empty string is universally invalid input, so we can fail so that the author knows to fix the call. Otherwise, this mistake could be masked. It's also an easy check in implementations.

Unrecognized is implementation-specific, and invalid (non-empty) could also be implementation-specific (i.e. invalid codecs for a real container type that is not recognized by the implementation). Thus, we just skip to the next iteration.

Other than one less step, do you see an advantage to continuing instead of returning on the empty string?

[ddorwin]

@cpearce, any comments?

[cpearce]

OK, I think it's reasonable that null input is universally invalid, whereas other non-null inputs may be implementation specific. I'm fine with closing this.