registration
Click on the red underlined text to get to the source
... RFC2045], are capable of carrying
arbitrary labeled content. A mechanism is needed to label such
content and a registration process is needed for these labels, to
ensure that the set of such values is developed in an orderly, well-
specified, and public manner.
...
...
This document defines media type specification and registration
procedures that use the Internet Assigned Numbers Authority (IANA) as
...
... Historical Note
The media type registration process was initially defined for
registering media types for use in the context ...
... MIME document set. The media type specification
and registration procedure has now been moved to this separate
document, to make it clear that it is independent of MIME.
...
... environments or to prohibit their use in other environments. This
revision attempts for the first time to incorporate such
restrictions into media type registrations in a systematic way.
See Section 4.9 for additional discussion.
...
... media type or types starts with the
construction of a registration proposal. Registration may occur
within several different registration trees ...
... starts with the
construction of a registration proposal. Registration may occur
within several different registration trees that have different
...
... registration proposal. Registration may occur
within several different registration trees that have different
requirements, as discussed below. In general, a new registration
proposal ...
... registration trees that have different
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 ...
... acceptable. The following sections describe the requirements and
procedures used for each of the different registration trees.
...
... Registration Trees and Subtype Names ...
...
In order to increase the efficiency and flexibility of the
registration process, different structures of subtype names may be
registered to accommodate the different natural requirements ...
... 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., names of the form
...
... standards tree is intended for types of general interest to the
Internet community. Registrations in the standards tree MUST be
approved by the IESG ...
... approved by the IESG and MUST correspond to a formal publication by a
recognized standards body. In the case of registration for the IETF
itself, the registration proposal ...
... registration for the IETF
itself, the registration proposal MUST be published as an RFC.
Standards-tree registration RFCs can either be standalone
...
... 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
...
... Standards-tree registration RFCs can either be standalone
"registration only" RFCs, or they can be incorporated into a more
general specification of some sort.
...
... stop) characters.
The "owner" of a media type registration in the standards tree is
assumed to be the standards body itself. Modification or alteration
...
... assumed to be the standards body itself. Modification or alteration
of the specification requires the same level of processing (e.g.,
standards track) required for the initial registration.
...
... context.
A registration may be placed in the vendor tree by anyone who needs
to interchange files associated with the particular product.
...
... vendor tree by anyone who needs
to interchange files associated with the particular product.
However, the registration formally belongs to the vendor or
organization producing the software or file format ...
... discussed in subsequent sections.
Registrations in the vendor tree will be distinguished by the leading
facet "vnd.". That may be followed, at the discretion of the
...
... 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 ...
... 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 leading facet "prs.".
The owner of "personal" registrations and associated specifications
is the person or entity making the registration ...
... registrations and associated specifications
is the person or entity making the registration, or one to whom
responsibility has been transferred as described below.
...
... ietf-types list for
review is strongly encouraged to improve the quality of those
specifications. Registrations in the personal tree may be submitted
directly to the IANA ...
...
For convenience and symmetry with this registration scheme, subtype
names with "x." as the first facet may be used for the same purposes
for which names starting ...
... agreement of the parties exchanging them.
However, with the simplified registration procedures described above
for vendor and personal trees ...
... 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 ...
... 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 ...
... 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. Establishment of these new trees ...
... Registration Requirements ...
...
Media type registration proposals are all expected to conform to
various requirements laid out in the following sections. Note that
...
... 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.
...
... Media types MUST function as an actual media format. Registration of
things that are better thought of as a transfer encoding, as a
...
...
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.
...
...
These requirements apply regardless of the registration tree
involved.
...
... There is no defined syntax for parameter values. Therefore
registrations MUST specify parameter value syntax. Additionally,
some transports ...
... 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
...
... standards tree
and MUST at a minimum be referenced by, if it isn't actually included
in, the media type registration proposal itself.
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
limit specification to which software and version ...
... such media types. References to or inclusion of format
specifications in registration proposals is encouraged but not
required.
...
... required.
Format specifications are still required for registration in the
personal tree, but may be either published as RFCs or otherwise
...
... Some media types involve the use of patented technology. The
registration of media types involving patented technology is
specifically permitted. However, the restrictions set forth in
...
... 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.
...
... 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
...
... tree be secure or completely free from risks. Nevertheless, all
known security risks MUST be identified in the registration of a
media type, again regardless of registration tree ...
... registration of a
media type, again regardless of registration tree.
The security considerations ...
...
The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular MAY be
...
... many cases provision is made for originators to specify arbitrary
actions in an unrestricted fashion that may then have devastating
effects. See the registration of the application/postscript media
type in [RFC2046 ...
... media
type in [RFC2046] for an example of such directives and how they
should be described in a media type registration.
o All registrations ...
... media type registration.
o All registrations MUST state whether or not they employ such
"active ...
... attack or else violates a recipient's
privacy in some way. Again, the registration of the
application/postscript media type ...
... There are a number of additional requirements specific to the
registration of XML media types. These requirements are specified in
...
... It is therefore useful to note what sort of data a media type can
consist of as part of its registration. An "encoding considerations"
field is provided for this purpose. Possible values of this field
...
... implemented. This was asserted in the past as a reason to limit the
number of possible media types, and it resulted in a registration
process with a significant hurdle and delay for those registering
media types.
...
... However, the need for "common" media types does not require limiting
the registration of new media types. If a limited set of media types
...
... media type is
NOT a requirement for registration. However, if a media type is
explicitly intended for limited use, this MUST be noted in its
...
... media type is
explicitly intended for limited use, this MUST be noted in its
registration. The "Restrictions on Usage" field is provided for this
purpose.
...
... media type proposals and
"publish" them as part of the media types registration tree itself.
As stated previously, standards tree ...
...
As stated previously, standards tree registrations for media types
defined in documents produced by other standards bodies MUST be
...
... defined in documents produced by other standards bodies MUST be
described by a formal standards specification produced by that body.
Such specifications MUST contain an appropriate media type
registration template taken from Section 10. Additionally, the
copyright on the registration template MUST allow the IANA ...
... Such specifications MUST contain an appropriate media type
registration template taken from Section 10. Additionally, the
copyright on the registration template MUST allow the IANA to copy it
into the IANA registry ...
... IETF registrations in the standards tree, the registration
of a data type does not imply endorsement, approval, or
...
... IETF standards process. This is
too difficult and too lengthy a process for the convenient
registration of media types.
...
... media type.
In the case of a registration in the standards tree, this additional
information MAY be provided in the formal specification of the media
type ...
... media
type. It is suggested that this be done by incorporating the IANA
media type registration form into the specification itself.
...
... Registration Procedure ...
...
The media type registration procedure is not a formal standards
process, but rather an administrative procedure intended to allow
community comment and sanity checking without excessive time delay.
...
... IETF processes should be followed for all IETF
registrations in the standards tree. The posting of an Internet
Draft is a necessary first step, followed by posting to the
...
... ietf-types@iana.org list as discussed below.
Registrations in the vendor and personal tree should be submitted
...
... ietf-types@iana.org list for review.
Proposed registrations in the standards tree by other standards
bodies should be communicated to the IESG ...
...
Internet Draft is not required for these registrations, but may be
helpful to the IESG and is encouraged.
...
...
Notice of a potential media type registration in the standards tree
MUST be sent to the "ietf-types ...
... mailing list has been established for the purpose of reviewing
proposed media and access types. Registrations in other trees MAY be
sent to the list for review as well.
...
... information, and a review of any interoperability or security
considerations. The submitter may submit a revised registration or
abandon the registration completely and at any time.
...
... security
considerations. The submitter may submit a revised registration or
abandon the registration completely and at any time.
...
... IANA Registration ...
... requirements
and has obtained whatever approval is necessary, the author may
submit the registration request to the IANA. Registration requests
...
... submit the registration request to the IANA. Registration requests
can be sent to iana@iana.org. A web form for registration requests
...
... IANA. Registration requests
can be sent to iana@iana.org. A web form for registration requests
is also available:
...
... IANA.
When the registration is either part of an RFC publication request or
a registration in the standards tree ...
... When the registration is either part of an RFC publication request or
a registration in the standards tree submitted to the IESG, close
...
... IESG means IESG approval in
effect submits the registration to the IANA. There is no need for an
additional registration ...
... registration to the IANA. There is no need for an
additional registration request in such cases.
...
...
Registrations submitted to the IANA will be passed on to the media
types reviewer. The media types ...
... IETF Applications Area Director(s), will review the registration to
make sure it meets the requirements set forth in this document.
...
... requirements set forth in this document.
Registrations that do not meet these requirements will be returned to
the submitter for revision.
...
... RFC2026] section 6.5.4.
Once a media type registration has passed review, the IANA will
register ...
... Comments on Media Type Registrations ...
... media type if
possible. Submitters of comments may request that their comment be
attached to the media type registration itself, and if the IANA
approves of this, the comment will be made accessible in conjunction ...
... approves of this, the comment will be made accessible in conjunction
with the type registration.
...
...
Media type registrations are listed by the IANA at:
...
... response to a communication from the IESG stating that a given
registration has been approved. Vendor and personal types will be
registered by the IANA ...
... IANA to
conduct a comprehensive security review of media type
registrations. Nevertheless, the IANA has the authority to
...
... submitter for revision.)
Registrations in the standards tree MUST satisfy the additional
requirement ...
... 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
...
... different registration trees above designate the "owners" of each
type of registration. The same procedure that would be appropriate
for the original registration request is used to process a change
...
... type of registration. The same procedure that would be appropriate
for the original registration request is used to process a change
request.
...
... media type. The most
common case of this will be to enable changes to be made to types
where the author of the registration has died, moved out of contact
or is otherwise unable to make changes that are important to the
community.
...
... Registration Template ...
...
Security requirements for media type registrations are discussed in
Section 4.6.
...
...
The current authors would like to acknowledge their debt to the late
Dr. Jon Postel, whose general model of IANA registration procedures
and specific contributions shaped the predecessors of this document
[RFC2048 ...
... Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. ...
... Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555prop(-> 4856prop | 4855prop), July 2003. ...
... Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048(-> 4289 | 4288), November 1996. ...
...
o Media type specification and registration procedures have been
moved out of the MIME document set to this separate specification.
...
... tree is now called the standards tree, and the
registration rules for this tree have been relaxed to allow use by
other standards bodies.
...
... other standards bodies.
o The text describing the media type registration procedure has
clarified.
...
... o RFC 3023prop is now referenced as the source of additional information
concerning the registration of XML media types.
...
... added.
o Concerns regarding copyrights on media type registration templates
produced by other standards bodies have been dealt with by
requiring that the IANA ...
... produced by other standards bodies have been dealt with by
requiring that the IANA be allowed to copy the registration
template into the registry.
...
... registry.
o The basic registration requirements for the various top-level
types have been moved from RFC 2046draft to this document.
...
...
o Ietf-types list review of registrations in the standards tree is
now required rather than just recommended.
...