Media Type Specifications and Registration Procedures
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.
Replaces RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1342: Representation of Non-ASCII Text in Internet Message Headers, RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1590: Media Type Registration Procedure, RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, RFC 4288: Media Type Specifications and Registration Procedures.
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 33 must, 16 should, 12 may.
3.1 Standards Tree
- MUSTRegistrations in the standards tree MUST be either:
- MUSTThe registration proposal MUST be published as an RFC.
- MUSTThe format MUST be described by a formal standards specification produced by the submitting standards- related organization.
- MUST NOTMedia types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A.
3.2 Vendor Tree
- SHOULDWhen a third party registers a type on behalf of someone else, both entities SHOULD be noted in the Change Controller field in the registration.
3.4 Unregistered x. Tree
- MAYAlso note that if a generally useful and widely deployed type incorrectly ends up with an "x-" name prefix, it MAY be registered using its current name in an alternative tree by following the procedure defined in Appendix A.
4.1 Functionality Requirement
- MUSTMedia types MUST function as actual media formats.
4.2 Naming Requirements
- MUSTAll registered media types MUST be assigned top-level type and subtype names.
- MUSTType and subtype names MUST conform to the following ABNF:
- SHOULDFor this reason, <type-name> and <subtype-name> SHOULD be limited to 64 characters.
- MUSTThe choice of top-level type MUST take into account the nature of media type involved.
- MUSTNew subtypes of top-level types MUST conform to the restrictions of the top-level type, if any.
- MAYAdditionally, various protocols, including but not limited to HTTP and MIME, MAY impose additional restrictions on the media types they can transport.
4.2.1 Text Media Types
- MUSTIf a "charset" parameter is defined for a particular subtype of text, it MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
- SHOULD NOTAs specified in [RFC6657], a "charset" parameter SHOULD NOT be specified when charset information is transported inside the payload (e.g., as in "text/xml").
- SHOULDIf a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value.
- MAYIf there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value.
- SHOULDFinally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default.
- MUSTRegardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer
- SHOULDIf explanatory text is needed, this SHOULD be placed in the additional information section of the registration.
- MAYPlain text MAY allow the stacking of several characters in the same position in the text.
4.2.6 Multipart and Message Media Types
- MUSTAll subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046] and amended by Section 3.5 of [RFC6532].
4.2.7 Additional Top-Level Types
- MUSTDefinition of a new top-level type name MUST be done via a Standards Track RFC; no other mechanism can be used to define additional type names.
4.2.8 Structured Syntax Name Suffixes
- SHOULDMedia types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they are registered.
- MUST NOTBy the same token, media types MUST NOT be given names incorporating suffixes for structured syntaxes they do not actually employ.
- SHOULD NOT"+suffix" constructs for as-yet unregistered structured syntaxes SHOULD NOT be used, given the possibility of conflicts with future suffix definitions.
4.2.9 Deprecated Aliases
- MUSTIn such cases, a preferred name MUST be chosen for the media type, and applications MUST use this to be compliant with the type's registration.
- MAYHowever, a list of deprecated aliases by which the type is known MAY be supplied as additional information in order to assist applications in processing the media type properly.
4.3 Parameter Requirements
- MAYMedia types MAY elect to use one or more media type parameters, or some parameters may be automatically made available to the media type by virtue of being a subtype of a content type that defines a set of parameters applicable to any of its subtypes.
- MUSTIn either case, the names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree, and SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees.
- MUSTTherefore, registrations MUST specify parameter value syntax.
- SHOULD NOTNew parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards tree, although new parameters MAY be added to convey additional information that does
4.4 Canonicalization and Format Requirements
- MUSTAll registered media types MUST employ a single, canonical data format, regardless of registration tree.
- MUSTA permanent and readily available public specification of the format for the media type MUST exist for all types registered in the standards tree.
- MUSTThis specification MUST provide sufficient detail so that interoperability between independent implementations using the media type is possible.
- MUSTThis specification MUST at a minimum be referenced by, if it is not actually included in, the media type registration proposal itself.
4.5 Interchange Recommendations
- SHOULDUniversal interoperability of media types is not required, but known interoperability issues SHOULD be identified whenever possible.
4.6 Security Requirements
- MUSTAn analysis of security issues MUST be done for all types registered in the standards tree.
- MUSTHowever, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible regardless of registration tree.
- MUST NOTIn particular, the security considerations MUST NOT state that there are "no security issues associated with this type".
- MAYSecurity considerations for types in the vendor or personal tree MAY say that "the security issues associated with this type have not been assessed".
- MUSTNevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree.
- MAYThe security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in Section 5.4 below.
- MUSTo Any security analysis MUST state whether or not they employ such "active content"; if they do, they MUST state what steps have been taken, or MUST be taken by applications of the media type, to protect users of the media type from harm.
- SHOULDAll media types SHOULD state whether or not they employ compression; if they do, they SHOULD discuss what steps need to be taken to avoid such attacks.
- SHOULDTypes SHOULD always document whether or not they need such services in their security considerations.
4.9 Usage and Implementation Non-Requirements
- MUSTexplicitly intended for limited use, this MUST be noted in its registration.
4.10 Publication Requirements
- MUSTMedia types registered in the standards tree by the IETF itself MUST be published as RFCs.
- MUSTAs stated previously, standards-tree registrations for media types defined in documents produced by other standards-related organizations MUST be described by a formal standards specification produced by that organization.
- MUSTAdditionally, any copyright on the registration template MUST allow the IANA to copy it into the IANA registry.
4.11 Fragment Identifier Requirements
- MUSTIn particular, media types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration.
4.12 Additional Information
- SHOULDVarious sorts of optional information SHOULD be included in the specification of a media type if it is available:
- MAYIn the case of a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type format.
5.1 Preliminary Community Review
- SHOULDNotice of a potential media type registration in the standards tree SHOULD be sent to the media-types@iana.org mailing list for review.
- MAYRegistrations in other trees MAY be sent to the list for review as well; doing so is entirely OPTIONAL, but is strongly encouraged.
5.2 Submit Request to IANA
- MUSTMedia types registered in the standards tree by the IETF itself MUST be reviewed and approved by the IESG as part of the normal standards process.
5.2.1 Provisional Registrations
- MAYA provisional registration MAY be submitted to IANA for standards- tree types.
- MAYProvisional registrations MAY be updated or abandoned at any time.
5.3 Review and Approval
- MUSTRecognition from the IESG MUST be obtained before a standards-tree registration can proceed.
6 Structured Syntax Suffix Registration Procedures
- SHOULDSomeone wishing to define a "+suffix" name for a structured syntax for use with a new media type registration SHOULD:
10.2 Informative References
- SHOULD(Note that this includes subtype names beginning with the "x-" prefix.) If possible, such a media type SHOULD be reregistered with a proper faceted subtype name, possibly using a deprecated alias to identify the original name (see Section 4.2.9).