MIME type record macro for other specifications

[annevk]

Writing

Let <var>mimeType</var> be a new <a>MIME type</a> whose <a for="MIME type">type</a> 
is "<code>application</code>" and <a for="MIME type">subtype</a> is 
"<code>octet-stream</code>".

is rather tedious. We could make something like

Let <var>mimeType</var> be a new <a>MIME type</a> 
&lt;<code>application/octet-stream</code>>.

mean the same thing. At least, I don't think we want to have a <dfn> for each MIME type.

XMLHttpRequest would use it. I'm pretty sure HTML would. This standard would use it. Fetch would use it.

I initially compared this with URLs, but needing a macro for a unique URL is much more rare.

[domenic]

I'm still not entirely sure it's short enough. E.g. what would you write for the various bullets in https://mimesniff.spec.whatwg.org/#mime-type-groups ? Would it be e.g.

• MIME type <application/x-rar-compressed>
• MIME type <application/zip>
• MIME type <application/x-gzip>

? That seems kind of tedious :-/.

The only alternative I can think of is to just say that when you write the MIME type without quotes, it's a representation of a MIME type record. Maybe you could even use a different font style, e.g. italic-monospace, or non-monospace plain, or something like that.

[annevk]

Oh, you want to go even further. Hmm, maybe something like <a lt="MIME type literal"><code>text/html</code></a>? So when you follow the link it's defined what it means? (I'd probably define it as taking the value and putting it in the parser...)

[domenic]

Well, but I kind of like how in HTML these MIME types currently link to their actual definitions, e.g. https://html.spec.whatwg.org/#text/html

[annevk]

Fair, although the whole IANA thing is rather messy. So how about we require MIME type the term to be mentioned nearby the literals? Or even stricter, that it's unambiguous the literal is a MIME type literal (and then define how you extract a MIME type record from such a literal).

[domenic]

That, coupled with ensuring there are no quotes, seems reasonable. Still monospace though, is the plan?

FWIW I think we should try to disallow writing e.g. TEXT/Html, even though that will parse correctly. So a definition in terms of the parser isn't the whole story, I think.

[annevk]

Yeah, <code>. I suppose we could define some custom ABNF for specifications to conform to, but...