tree
Click on the red underlined text to get to the source
... registration proposal. Registration may occur
within several different registration trees that have different
requirements, as discussed below. In general, a new registration
proposal ...
... requirements, as discussed below. In general, a new registration
proposal is circulated and reviewed in a fashion appropriate to the
tree involved. The media type is then registered if the proposal is
acceptable. The following sections describe the requirements ...
... acceptable. The following sections describe the requirements and
procedures used for each of the different registration trees.
...
... Registration Trees and Subtype Names ...
... to move files associated with proprietary software. The following
subsections define registration "trees" that are distinguished by the
use of faceted names, e.g., names of the form
"tree ...
... trees" that are distinguished by the
use of faceted names, e.g., names of the form
"tree.subtree...subtype". Note that some media types defined prior
...
... Standards Tree ...
...
The standards tree is intended for types of general interest to the
Internet community. Registrations ...
... Internet community. Registrations in the standards tree MUST be
approved by the IESG and MUST correspond to a formal publication by a
...
... itself, the registration proposal MUST be published as an RFC.
Standards-tree registration RFCs can either be standalone
"registration only" RFCs, or they can be incorporated into a more
...
...
Media types in the standards tree are normally denoted by names that
are not explicitly faceted, i.e., do not contain period (".", full
stop) characters.
...
...
The "owner" of a media type registration in the standards tree is
assumed to be the standards body itself. Modification or alteration
of the specification requires the same level of processing (e.g.,
...
... Vendor Tree ...
...
The vendor tree is used for media types associated with commercially
available products. "Vendor ...
...
A registration may be placed in the vendor tree by anyone who needs
to interchange files associated with the particular product.
However, the registration ...
...
Registrations in the vendor tree will be distinguished by the leading
facet "vnd.". That may be followed, at the discretion of the
registrant, by either a media subtype ...
... While public exposure and review of media types to be registered in
the vendor tree is not required, using the ietf-types@iana.org
mailing list ...
... mailing list for review is strongly encouraged to improve the quality
of those specifications. Registrations in the vendor tree may be
submitted directly to the IANA.
...
... Personal or Vanity Tree ...
... 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.".
...
... While public exposure and review of media types to be registered in
the personal tree is not required, using the ietf-types list for
review is strongly encouraged to improve the quality of those
...
... review is strongly encouraged to improve the quality of those
specifications. Registrations in the personal tree may be submitted
directly to the IANA.
...
... Special x. Tree ...
... registration procedures described above
for vendor and personal trees, it should rarely, if ever, be
necessary to use unregistered experimental ...
... both "x-" and "x." forms is discouraged.
Types in this tree MUST NOT be registered.
...
... Additional Registration Trees ...
... and with the advice and consent of the IESG, create new top-level
registration trees. It is explicitly assumed that these trees may be
created ...
... IESG, create new top-level
registration trees. It is explicitly assumed that these trees may be
created for external registration ...
... media types specific to the sciences they cover. In general, the
quality of review of specifications for one of these additional
registration trees is expected to be equivalent to registrations in
the standards tree ...
... additional
registration trees is expected to be equivalent to registrations in
the standards tree. Establishment of these new trees will be
announced through RFC publication approved by the IESG ...
... registrations in
the standards tree. Establishment of these new trees will be
announced through RFC publication approved by the IESG.
...
... requirements laid out in the following sections. Note that
requirement specifics sometimes vary depending on the registration
tree, again as detailed in the following sections.
...
...
This requirement applies regardless of the registration tree
involved.
...
... The combination of these names serves to uniquely identify the media
type, and the format of the subtype name identifies the registration
tree. Both type and subtype names are case-insensitive.
...
... experimental use and MUST NOT be registered. This parallels the
restriction on the x. tree, as discussed in Section 3.4.
...
...
These requirements apply regardless of the registration tree
involved.
...
...
when a media type is registered in the standards tree, and SHOULD be
specified as completely as possible when media types are registered
...
... media types are registered
in the vendor or personal trees.
Parameter names have the syntax as media type names ...
...
New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does
not otherwise change existing functionality. An example of this
...
... All registered media types MUST employ a single, canonical data
format, regardless of registration tree.
A precise and openly available specification of the format of each
...
... A precise and openly available specification of the format of each
media type MUST exist for all types registered in the standards tree
and MUST at a minimum be referenced by, if it isn't actually included
in, the media type registration ...
... The specifications of format and processing particulars may or may
not be publicly available for media types registered in the vendor
tree, and such registration proposals are explicitly permitted to
...
... Format specifications are still required for registration in the
personal tree, but may be either published as RFCs or otherwise
deposited with the IANA. The deposited specifications will meet the
...
... part of a standards-track protocol. In addition, other standards
bodies making use of the standards tree may have their own rules
regarding intellectual property that must be observed in their
registrations ...
... subject to continuing evaluation.
These recommendations apply regardless of the registration tree
involved.
...
... An analysis of security issues MUST be done for all types registered
in the standards Tree. A similar analysis for media types registered
in the vendor ...
... media types registered
in the vendor or personal trees is encouraged but not required.
However, regardless of what security analysis has or has not been
...
... done, all descriptions of security issues MUST be as accurate as
possible regardless of registration tree. In particular, a statement
that there are "no security issues associated with this type" MUST
...
... requirement that media types registered in any
tree be secure or completely free from risks. Nevertheless, all
known security risks MUST be identified in the registration ...
... registration of a
media type, again regardless of registration tree.
The security considerations ...
...
Proposals for media types registered in the standards tree by the
IETF itself MUST be published as RFCs. RFC publication of vendor ...
... media type proposals and
"publish" them as part of the media types registration tree itself.
As stated previously, standards tree ...
... registration tree itself.
As stated previously, standards tree registrations for media types
...
... media types.
The standards tree exists for media types that do require a
substantive review and approval process in a recognized standards
...
... substantive review and approval process in a recognized standards
body. The vendor and personal trees exist for those media types that
do not require such a process. It is expected that applicability
statements ...
...
In the case of a registration in the standards tree, this additional
information MAY be provided in the formal specification of the media
type. It is suggested that this be done by incorporating the IANA ...
... IETF
registrations in the standards tree. The posting of an Internet
Draft is a necessary first step, followed by posting to the
ietf-types ...
... Registrations in the vendor and personal tree should be submitted
directly to the IANA, ideally after first posting to the
...
...
Proposed registrations in the standards tree by other standards
bodies should be communicated to the IESG (at iesg@ietf.org) and to
...
...
Notice of a potential media type registration in the standards tree
MUST be sent to the "ietf-types@iana.org" mailing list ...
... proposed media and access types. Registrations in other trees MAY be
sent to the list for review as well.
...
...
Media types registered in the standards tree MUST be approved by the
IESG prior to registration ...
... registration is either part of an RFC publication request or
a registration in the standards tree submitted to the IESG, close
coordination between the IANA ...
... IANA will only register media types in the standards tree in
response to a communication from the IESG stating that a given
...
... prefix.
o Types registered in the personal tree MUST either provide a format
specification or a pointer to one.
...
...
Registrations in the standards tree MUST satisfy the additional
requirement that they originate from the IETF ...
... IANA, the owner may
request a change to its definition. The descriptions of the
different registration trees above designate the "owners" of each
type of registration. The same procedure that would be appropriate
...
... registered under the guidelines in this document, be placed into
either the vendor or personal trees. Reregistration of those types
to reflect the appropriate trees is encouraged but not required.
...
... vendor or personal trees. Reregistration of those types
to reflect the appropriate trees is encouraged but not required.
Ownership and change control principles outlined in this document
...
... Ownership and change control principles outlined in this document
apply to those types as if they had been registered in the trees
described above.
...
... o The unfaceted IETF tree is now called the standards tree, and the
registration rules for this tree ...
... standards tree, and the
registration rules for this tree have been relaxed to allow use by
other standards bodies.
...
... o Ietf-types list review of registrations in the standards tree is
now required rather than just recommended.
...