Naming
A media type consists of a ''type'' and a ''subtype'', which is further structured into a ''tree''. A media type can optionally define a ''suffix'' and ''parameters'': : As of November 1996, the registered types were: , , , , , and . By December 2020, the registered types included the foregoing, plus , , and . An unofficial top-level name in common use is . As an example, an HTML file might be designated . In this example, is the type, is the subtype, and is an optional parameter indicating the character encoding. A subtype typically consists of a media format, but it may or must also contain other content, such as a tree prefix, producer, product or suffix, according to the different rules in registration trees. Types, subtypes, and parameter names are case-insensitive. Parameter values are usually case-sensitive, but may be interpreted in a case-insensitive fashion depending on the intended use.Common examples
* * * * (.doc) * * * * (.xls) * (.ppt) * (.odt) * (.pptx) * (.xlsx) * (.docx) * * * * (.zst) * * * * (.jpg, .jpeg, .jfif, .pjpeg, .pjp) * * (.svg) * * * * * *Registration trees
All media types should be registered using the IANA registration procedures. For the efficiency and flexibility of the media type registration process, different structures of subtypes can be registered in registration trees that are distinguished by the use of tree prefixes. Currently the following trees are created: standard (no prefix), vendor ( prefix), personal or vanity ( prefix), unregistered ( prefix). These registration trees were first defined in November 1996 (obsoleted RFC 2048 - currently RFC 6838). New registration trees may be created byStandards tree
The standards tree does not use any tree prefix: : Examples: , . Registrations in the standards tree must be either associated with IETF specifications approved directly by the IESG, or registered by an IANA recognized standards-related organization.Vendor tree
The vendor tree includes media types associated with publicly available products. It uses the tree prefix: : Examples: , . The terms "vendor" and "producer" are considered equivalent in the context. Industry consortia as well as non-commercial entities can register media types in the vendor tree. A registration in the vendor tree may be created by anyone who needs to interchange files associated with some software product or set of products. However, the registration belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party.Personal or vanity tree
The personal or vanity tree includes media types associated with non publicly available products or experimental media types. It uses the tree prefix: : Examples: , .Unregistered tree
The unregistered tree includes media types intended exclusively for use in private environments and only with the active agreement of the parties exchanging them. It uses the tree prefix: : Examples: , . Media types in this tree cannot be registered. According toSuffix
Suffix is an augmentation to the media type definition to additionally specify the underlying structure of that media type, allowing for generic processing based on that structure and independent of the exact type's particular semantics. Media types that make use of a named structured syntax should use the appropriate IANA registered for that structured syntax when they are registered. Unregistered suffixes should not be used (since January 2013). Structured syntax suffix registration procedures are defined inMailcap
Mailcap (derived from the phrase "mail capability") is a type of meta file used to configure how MIME-aware applications such as mail clients and web browsers render files of different MIME-types. The mailcap format is defined byMime.types
An associated file is the mime.types file, which associates filename extensions with a ''MIME type''. If the MIME type is properly set, this is unnecessary, but MIME types may be incorrectly set, or set to a generic type such as , and mime.types allows one to fall back on the extension in these cases. Similarly, since many file systems do not store MIME type information, but instead rely on the filename extension, a mime.types file is frequently used by web servers to determine MIME type. When ''viewing'' a file, these two work together as follows: associates an extension with a MIME type, while mailcap
associates a MIME type with a program.
In UNIX-type systems, the mime.types file is usually located at /etc/mime.types
and/or $HOME/.mime.types
and the format is simply that each line is a space-delimited list of a MIME type, followed by zero or more extensions. For example, the HTML type can be associated with the extensions and by the following line:
text/html htm html
Netscape use
The mime.types file dates to Netscape, where it used a different format;WEBMASTERSSee also
* Content negotiation * Content sniffing * XML and MIME *References
External links
* IANA list of official media types