Guidelines for the Definition of New Top-Level Media Types
This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 8 must, 2 should, 0 may.
2.1 Required Criteria
- MUST* Every new top-level type MUST be defined in a Standards Track RFC (see Section 4.9 of RFC 8126 [RFC8126]).
- MUST* The IANA Considerations section of an RFC defining a new top-level type MUST request that IANA add this new top-level type to the registry of top-level types.
- MUST* The criteria for what types do and do not fall under the new top- level type MUST be defined clearly.
- MUST* Any RFC defining a new top-level type MUST clearly document the security considerations applying to all or a significant subset of subtypes.
- MUST* At a minimum, one subtype MUST be described.
2.3 Negative Criteria
- MUST NOT* A top-level type MUST NOT be defined for the mapping of other protocol elements to media types.
- MUST NOTA top-level type MUST NOT be defined if its main or only purpose is to map other type systems, e.g., in programming languages or ontologies.
- SHOULD NOT* A new top-level type SHOULD NOT generate aliases for existing widely used types or subtypes.
- SHOULD NOT* Top-level types with an "X-" prefix cannot be registered, and SHOULD NOT be used.
5 Security Considerations
- MUSTThe security issues related to introducing a new top-level media type MUST be evaluated and documented carefully.