Application for a 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.

Provide references to the published specification.

See RFC 6838, section 4.10.

Describe applications which use/will use this media type.

See RFC 6838, section 4.5.

See RFC 6838, section 4.11.

See RFC 6838, section 4.9.

Is this a request for provisional registration only? (Vendor-tree and personal-tree requests must select "No.")

Yes. This is a request for provisional standards-tree registration only. A request for permanent registration will be submitted at a later date.
No. This is a request for vendor-tree, personal-tree, or permanent standards-tree registration.

See RFC 6838, section 5.2.1 and the provisional standards-tree media type registry.

See RFC 6838, section 4.12.

Deprecated alias names for this type

Magic number(s)

File extension(s)

Macintosh File Type Code(s)

Object Identifier(s) or OID(s) — See RFC 1494.

Additional information (if necessary):

"LIMITED USE" can be appropriate when the media type is restricted in its usage, such as when it is used only in a particular protocol (e.g. HTTP, but not email) or application, and its use is not recommended in other contexts.

See RFC 6838, section 5.5.

Contact Name

Contact Email Address

Author/Change Controller (for standards-tree registrations, this is typically the standards body)

By submitting my personal data, I agree that my personal data will be processed in accordance with our Privacy Policy and agree to abide by the website Terms of Service.