Application for Media Type

We recommend that you read the following RFCs before proceeding with this application. It is important that you understand the application process and requirements completely. These documents are the standards for media types:
Please read the following questions carefully and provide complete answers. Write "N/A" for fields that are not applicable.
When referring to specifications, please provide URLs (if applicable).
What is the media type name?
See the Top-Level Media Types registry.
What is the media subtype name? (The prefix, if any, will be taken from the drop-down menu and should be omitted from the text field.)
Review the existing subtype names. See also RFC 2046 and RFC 6838 (sections 3 and 4.2).
Registrations in the standards tree must be approved by the IESG or correspond to a formal publication by a recognized standards body. See RFC 6838 (section 3.1).
If the name includes a suffix (text that follows a "+" at the end of the subtype name), that suffix must be listed in the Structured Syntax Suffixes registry.
The appearance of a dot (".") in a standards-tree subtype name would require registration of a new facet, which may not be what is intended.
Describe the required parameters. (If none, enter "N/A.")
See RFC 2046, section 1, and RFC 6838, section 4.3.
Text types should pay attention to the discussion of the charset parameter in RFC 6838, section 4.2.1.
Describe the optional parameters. (If none, enter "N/A.")
See RFC 2046, section 1, and RFC 6838, section 4.3.
7-bit text 8-bit text (this media type may require encoding on transports not capable of handling 8-bit text) binary (this media type may require encoding on transports not capable of handling binary) framed (transport must provide framing information)
Additional notes (optional):
See RFC 2045, section 6, and RFC 6838, section 4.8.
8-bit data consists of lines no longer than 998 octets, separated by CRLF.
The following questions should help determine whether to select "8-bit" or "binary":
(1) Can NUL octet appear in the format? If yes, then encoding is "binary."
(2) Can CR and/or LF octets appear outside of CRLF sequence? If yes, then encoding is "binary."
(3) Does the format allow for lines longer than 998 octets? If yes, then encoding is "binary."
(4) Otherwise the encoding is "8-bit."
If the format is based on JSON or XML, "binary" should generally be selected due to the possibility that lines could be longer than 998 octets.
If the format is encoded using UTF-16, the encoding is always "binary."
Provide a discussion of the security considerations.
All media type registrations must describe their security considerations; simply saying there are none or leaving the section blank is unacceptable.
In discussing the security considerations for a media type, it is necessary to cover at least these points:
(1) State whether or not the media type contains active or executable content. If the media type does contain executable content, explain what measures have been taken to insure that it can be executed safely, e.g. a sandbox, safe operation set, signed content, etc.
(2) State whether or not the information contained in the media type needs privacy or integrity services.
(3) If the answer to (2) is yes, elaborate on any privacy or integrity services the media type itself provides. If it doesn't provide such services, explain how they should be provided externally, e.g., through the use of SSL/TLS.
(4) If the media type uses an existing format, e.g. XML or JSON, the security considerations for that format must be referenced and any issues specific to the usage of that format, e.g., XML extensibility, must be described.
(4a) If the media type employs compression, the security considerations associated with that usage must be covered.
(4b) If the media type employs a container format, e.g., ZIP, any issues associated with that usage need to be described.
(5) If the media type incorporates links that must be referenced in order to properly interpret the type, this should be noted.
Finally, although it is discouraged, it is acceptable to simply say that the security considerations of the media type have not been assessed.
See RFC 6838, section 4.6.
Provide a discussion of the interoperability considerations.
See RFC 6838, section 4.5.