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.
Header analyser parses a real message and says what each header is claiming. Open header analyser
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
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.