This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21268 - Define MIME type terminology
Summary: Define MIME type terminology
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: MIME (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Gordon P. Hemsley
QA Contact: sideshowbarker+mimespec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-13 16:24 UTC by Gordon P. Hemsley
Modified: 2019-03-29 22:40 UTC (History)
5 users (show)

See Also:


Attachments

Description Gordon P. Hemsley 2013-03-13 16:24:46 UTC
If a file is characterized as "text/html;charset=utf-8", we need to make sure we have terminology for the following subsets of that:

* "text/html;charset=utf-8"
* "text/html"
* "text"

At the moment, the term "MIME type" (or "type") can apply to any one of those.
Comment 1 Simon Sapin 2013-03-13 16:26:21 UTC
I’ve been using "MIME type with parameters" for the first one.
Comment 2 Anne 2013-03-13 16:29:49 UTC
As far as I know we never needed a term for "text". I recommend treating "text/html" as a single entity.

"MIME type" and "MIME type with parameters" works for me.
Comment 3 Gordon P. Hemsley 2013-03-13 17:16:14 UTC
(In reply to comment #2)
> As far as I know we never needed a term for "text". I recommend treating
> "text/html" as a single entity.

Such a term is used extensively in the MIME Sniffing spec, and I would guess elsewhere. Categories like "text", "image", "audio", "video", and "application" make it easier to group similar file formats, and I don't think it would be wise to treat "text/html" as a single atomic entity when it is clearly made up of two separate parts ("type" and "subtype").

> "MIME type" and "MIME type with parameters" works for me.

I'm fine with that, too, but I think earlier discussion indicated that existing usage might be such that "MIME type" includes parameters (at least in some cases). If we want to buck that trend, that's OK by me.

But I also want to reiterate that "MIME type" would then be an entity divisible into "type" and "subtype" parts. By extension, then, "MIME type with parameters" would be made up of "type", "subtype", and "parameters" parts. (And both would also have additional separator characters involved, like slashes and semicolons.)
Comment 4 Ian 'Hixie' Hickson 2013-03-14 00:44:54 UTC
Why do we care about type vs subtype as separate referenceable parts? Shouldn't we just treat the whole thing as an opaque string?
Comment 5 Ian 'Hixie' Hickson 2013-03-14 00:45:28 UTC
Sorry, missed the part where you said you needed that specifically for the sniffing spec.
Comment 6 Domenic Denicola 2019-03-29 22:40:33 UTC
This now exists: https://mimesniff.spec.whatwg.org/#mime-type-representation :

- MIME type, or valid MIME type string
- MIME type's essence
- MIME type's type