3. Registration Trees and Subtype Names

In order to increase the efficiency and flexibility of the registration process, different structures of subtype names can be registered to accommodate the different natural requirements for, e.g., a subtype that will be recommended for wide support and implementation by the Internet community, or a subtype that is used to move files associated with proprietary software. The following subsections define registration "trees" that are distinguished by the use of faceted names, e.g., subtype names that begin with a "tree." prefix. Note that some media types defined prior to this document do not conform to the naming conventions described below. See Appendix A for a discussion of them.

3.1 Standards Tree

The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be either:

1. in the case of registrations associated with IETF specifications, approved directly by the IESG, or

2. registered by a recognized standards-related organization using the "Specification Required" IANA registration policy [RFC5226] (which implies Expert Review).

The first procedure is used for registrations from IETF Consensus documents, or in rare cases when registering a grandfathered (see Appendix A) and/or otherwise incomplete registration is in the interest of the Internet community. The registration proposal MUST be published as an RFC. When the registration RFC is in the IETF stream, it must have IETF Consensus, which can be attained with a status of Standards Track, BCP, Informational, or Experimental. Registrations published in non-IETF RFC streams are also allowed and require IESG approval. A registration can be either in a stand-alone "registration only" RFC or incorporated into a more general specification of some sort.

In the second case, the IESG makes a one-time decision on whether the registration submitter represents a recognized standards-related organization; after that, a Media Types Reviewer (Designated Expert or a group of Designated Experts) performs the Expert Review as specified in this document. Subsequent submissions from the same source do not involve the IESG. The format MUST be described by a formal standards specification produced by the submitting standards-related organization.

Media types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A.

The "owner" of a media type registered in the standards tree is assumed to be the standards-related organization itself. Modification or alteration of the specification uses the same level of processing (e.g., a registration submitted on Standards Track can be revised in another Standards Track RFC, but cannot be revised in an Informational RFC) required for the initial registration.

Standards-tree registrations from recognized standards-related organizations are submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval. In this case, the Expert Reviewer(s) will, among other things, ensure that the required specification provides adequate documentation.

3.2 Vendor Tree

The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree.

A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it. See Section 5.5 for additional information.

When a third party registers a type on behalf of someone else, both entities SHOULD be noted in the Change Controller field in the registration. One possible format for this would be "Foo, on behalf of Bar".

Vendor-tree registrations will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registrant, by either a media subtype name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer's name that is followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures).

While public exposure and review of media types to be registered in the vendor tree are not required, using the [email protected] mailing list for review is encouraged, to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval.

3.3 Personal or Vanity Tree

Registrations for media types created experimentally or as part of products that are not distributed commercially may be registered in the personal or vanity tree. The registrations are distinguished by the leading facet "prs.".

The owner of "personal" registrations and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below.

While public exposure and review of media types to be registered in the personal tree are not required, using the [email protected] mailing list (see Section 5.1) for review is encouraged, to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval.

3.4 Unregistered x. Tree

Subtype names with "x." as the first facet may be used for types intended exclusively for use in private, local environments. Types in this tree cannot be registered and are intended for use only with the active agreement of the parties exchanging them.

However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered types. Therefore, use of types in the "x." tree is strongly discouraged.

Note that types with names beginning with "x-" are no longer considered to be members of this tree (see [RFC6648]). Also 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.

3.5 Additional Registration Trees

From time to time and as required by the community, new top-level registration trees may be created by IETF Standards Action. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent organizations, such as scientific societies for media types specific to the sciences they cover.

---