doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6838.txt b/doc/rfc/rfc6838.txt
new file mode 100644
index 0000000..85cfd82
--- /dev/null
+++ b/doc/rfc/rfc6838.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          N. Freed
+Request for Comments: 6838                                        Oracle
+BCP: 13                                                       J. Klensin
+Obsoletes: 4288
+Category: Best Current Practice                                T. Hansen
+ISSN: 2070-1721                                        AT&T Laboratories
+                                                            January 2013
+
+
+         Media Type Specifications and Registration Procedures
+
+Abstract
+
+   This document defines procedures for the specification and
+   registration of media types for use in HTTP, MIME, and other Internet
+   protocols.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6838.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 1]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Historical Note  . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  4
+   2.  Media Type Registration Preliminaries  . . . . . . . . . . . .  4
+   3.  Registration Trees and Subtype Names . . . . . . . . . . . . .  4
+     3.1.  Standards Tree . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  Vendor Tree  . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.3.  Personal or Vanity Tree  . . . . . . . . . . . . . . . . .  6
+     3.4.  Unregistered x. Tree . . . . . . . . . . . . . . . . . . .  7
+     3.5.  Additional Registration Trees  . . . . . . . . . . . . . .  7
+   4.  Registration Requirements  . . . . . . . . . . . . . . . . . .  7
+     4.1.  Functionality Requirement  . . . . . . . . . . . . . . . .  8
+     4.2.  Naming Requirements  . . . . . . . . . . . . . . . . . . .  8
+       4.2.1.  Text Media Types . . . . . . . . . . . . . . . . . . .  9
+       4.2.2.  Image Media Types  . . . . . . . . . . . . . . . . . . 10
+       4.2.3.  Audio Media Types  . . . . . . . . . . . . . . . . . . 10
+       4.2.4.  Video Media Types  . . . . . . . . . . . . . . . . . . 10
+       4.2.5.  Application Media Types  . . . . . . . . . . . . . . . 11
+       4.2.6.  Multipart and Message Media Types  . . . . . . . . . . 11
+       4.2.7.  Additional Top-Level Types . . . . . . . . . . . . . . 12
+       4.2.8.  Structured Syntax Name Suffixes  . . . . . . . . . . . 12
+       4.2.9.  Deprecated Aliases . . . . . . . . . . . . . . . . . . 13
+     4.3.  Parameter Requirements . . . . . . . . . . . . . . . . . . 13
+     4.4.  Canonicalization and Format Requirements . . . . . . . . . 14
+     4.5.  Interchange Recommendations  . . . . . . . . . . . . . . . 15
+     4.6.  Security Requirements  . . . . . . . . . . . . . . . . . . 15
+     4.7.  Requirements Specific to XML Media Types . . . . . . . . . 16
+     4.8.  Encoding Requirements  . . . . . . . . . . . . . . . . . . 16
+     4.9.  Usage and Implementation Non-Requirements  . . . . . . . . 17
+     4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
+     4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 18
+     4.12. Additional Information . . . . . . . . . . . . . . . . . . 19
+   5.  Media Type Registration Procedures . . . . . . . . . . . . . . 19
+     5.1.  Preliminary Community Review . . . . . . . . . . . . . . . 19
+     5.2.  Submit Request to IANA . . . . . . . . . . . . . . . . . . 20
+       5.2.1.  Provisional Registrations  . . . . . . . . . . . . . . 20
+     5.3.  Review and Approval  . . . . . . . . . . . . . . . . . . . 21
+     5.4.  Comments on Media Type Registrations . . . . . . . . . . . 21
+     5.5.  Change Procedures  . . . . . . . . . . . . . . . . . . . . 21
+     5.6.  Registration Template  . . . . . . . . . . . . . . . . . . 22
+   6.  Structured Syntax Suffix Registration Procedures . . . . . . . 23
+     6.1.  Change Procedures  . . . . . . . . . . . . . . . . . . . . 24
+     6.2.  Structured Syntax Suffix Registration Template . . . . . . 24
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
+
+
+
+Freed, et al.             Best Current Practice                 [Page 2]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 28
+   Appendix A.  Grandfathered Media Types . . . . . . . . . . . . . . 30
+   Appendix B.  Changes since RFC 4288  . . . . . . . . . . . . . . . 30
+
+1.  Introduction
+
+   Recent Internet protocols have been carefully designed to be easily
+   extensible in certain areas.  In particular, many protocols,
+   including but not limited to HTTP [RFC2616] and MIME [RFC2045], are
+   capable of carrying arbitrary labeled content.
+
+   The mechanism used to label such content is a media type, consisting
+   of a top-level type and a subtype, which is further structured into
+   trees.  Optionally, media types can define companion data, known as
+   parameters.
+
+   A registration process is needed for these labels, so that the set of
+   such values are defined in a reasonably orderly, well-specified, and
+   public manner.
+
+   This document specifies the criteria for media type registrations and
+   defines the procedures to be used to register media types (Section 5)
+   as well as media type structured suffixes (Section 6) in the Internet
+   Assigned Numbers Authority (IANA) central registry.
+
+   The location of the media type registry managed by these procedures
+   is:
+
+     http://www.iana.org/assignments/media-types/
+
+1.1.  Historical Note
+
+   The media type registration process was initially defined for
+   registering media types for use in the context of the asynchronous
+   Internet mail environment.  In this mail environment, there is a need
+   to limit the number of possible media types, to increase the
+   likelihood of interoperability when the capabilities of the remote
+   mail system are not known.  As media types are used in new
+   environments in which the proliferation of media types is not a
+   hindrance to interoperability, the original procedure proved
+   excessively restrictive and had to be generalized.  This was
+   initially done in [RFC2048], but the procedure defined there was
+   still part of the MIME document set.  The media type specification
+   and registration procedure is now a separate document, to make it
+   clear that it is independent of MIME.
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 3]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   It may be desirable to restrict the use of media types to specific
+   environments or to prohibit their use in other environments.  This
+   specification incorporates such restrictions into media type
+   registrations in a systematic way.  See Section 4.9 for additional
+   discussion.
+
+1.2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119] when they
+   appear in ALL CAPS.  They may also appear in lower or mixed case as
+   plain English words, without any normative meaning.
+
+   This specification makes use of the Augmented Backus-Naur Form (ABNF)
+   [RFC5234] notation, including the core rules defined in Appendix B of
+   that document.
+
+2.  Media Type Registration Preliminaries
+
+   Registration of a new media type or types starts with the
+   construction of a registration proposal.  Registration may occur
+   within several different 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 is then registered if the proposal is
+   acceptable.  The following sections describe the requirements and
+   procedures used for each of the different registration trees.
+
+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:
+
+
+
+Freed, et al.             Best Current Practice                 [Page 4]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   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.
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 5]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+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 media-types@iana.org
+   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.
+
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 6]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   While public exposure and review of media types to be registered in
+   the personal tree are not required, using the media-types@iana.org
+   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;
+   for example, scientific societies may register 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 by a
+   recognized standards-related organization.  When the IETF performs
+   such review, it needs to consider the greater expertise of the
+   requesting organization with respect to the subject media type.
+
+4.  Registration Requirements
+
+   Media type registrations are all expected to conform to various
+   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.
+
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 7]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+4.1.  Functionality Requirement
+
+   Media types MUST function as actual media formats.  Registration of
+   things that are better thought of as a transfer encoding, as a
+   charset, or as a collection of separate entities of another type, is
+   not allowed.  For example, although applications exist to decode the
+   base64 transfer encoding [RFC2045], base64 cannot be registered as a
+   media type.
+
+   This requirement applies regardless of the registration tree
+   involved.
+
+4.2.  Naming Requirements
+
+   All registered media types MUST be assigned top-level type and
+   subtype names.  The combination of these names serves to uniquely
+   identify the media type, and the subtype name facet (or the absence
+   of one) identifies the registration tree.  Both top-level type and
+   subtype names are case-insensitive.
+
+   Type and subtype names MUST conform to the following ABNF:
+
+     type-name = restricted-name
+     subtype-name = restricted-name
+
+     restricted-name = restricted-name-first *126restricted-name-chars
+     restricted-name-first  = ALPHA / DIGIT
+     restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
+                              "$" / "&" / "-" / "^" / "_"
+     restricted-name-chars =/ "." ; Characters before first dot always
+                                  ; specify a facet name
+     restricted-name-chars =/ "+" ; Characters after last plus always
+                                  ; specify a structured syntax suffix
+
+   Note that this syntax is somewhat more restrictive than what is
+   allowed by the ABNF in Section 5.1 of [RFC2045] or Section 4.2 of
+   [RFC4288].  Also note that while this syntax allows names of up to
+   127 characters, implementation limits may make such long names
+   problematic.  For this reason, <type-name> and <subtype-name> SHOULD
+   be limited to 64 characters.
+
+   Although the name syntax treats "." as equivalent to any other
+   character, characters before any initial "." always specify the
+   registration facet.  Note that this means that facet-less standards-
+   tree registrations cannot use periods in the subtype name.
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                 [Page 8]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   Similarly, the final "+" in a subtype name introduces a structured
+   syntax specifier suffix.  Structured syntax suffix requirements are
+   specified in Section 4.2.8.
+
+   While it is possible for a given media type to be assigned additional
+   names, the use of different names to identify the same media type is
+   discouraged.
+
+   These requirements apply regardless of the registration tree
+   involved.
+
+   The choice of top-level type MUST take into account the nature of
+   media type involved.  New subtypes of top-level types MUST conform to
+   the restrictions of the top-level type, if any.  The following
+   sections describe each of the initial set of top-level types and
+   their associated restrictions.  Additionally, various protocols,
+   including but not limited to HTTP and MIME, MAY impose additional
+   restrictions on the media types they can transport.  (See [RFC2046]
+   for additional information on the restrictions MIME imposes.)
+
+4.2.1.  Text Media Types
+
+   The "text" top-level type is intended for sending material that is
+   principally textual in form.
+
+   Many subtypes of text, notably including the subtype "text/plain",
+   which is a generic subtype for plain text defined in [RFC2046],
+   define a "charset" parameter.  If a "charset" parameter is defined
+   for a particular subtype of text, it MUST be used to specify a
+   charset name defined in accordance to the procedures laid out in
+   [RFC2978].
+
+   As specified in [RFC6657], a "charset" parameter SHOULD NOT be
+   specified when charset information is transported inside the payload
+   (e.g., as in "text/xml").
+
+   If a "charset" parameter is specified, it SHOULD be a required
+   parameter, eliminating the options of specifying a default value.  If
+   there is a strong reason for the parameter to be optional despite
+   this advice, each subtype MAY specify its own default value, or
+   alternatively, it MAY specify that there is no default value.
+   Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the
+   default.  See [RFC6657] for additional information on the use of
+   "charset" parameters in conjunction with subtypes of text.
+
+   Regardless of what approach is chosen, all new text/* registrations
+   MUST clearly specify how the charset is determined; relying on the
+   US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer
+
+
+
+Freed, et al.             Best Current Practice                 [Page 9]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   permitted.  If explanatory text is needed, this SHOULD be placed in
+   the additional information section of the registration.
+
+   Plain text does not provide for or allow formatting commands, font
+   attribute specifications, processing instructions, interpretation
+   directives, or content markup.  Plain text is seen simply as a linear
+   sequence of characters, possibly interrupted by line breaks or page
+   breaks.  Plain text MAY allow the stacking of several characters in
+   the same position in the text.  Plain text in scripts like Arabic and
+   Hebrew may also include facilities that allow the arbitrary mixing of
+   text segments with different writing directions.
+
+   Beyond plain text, there are many formats for representing what might
+   be known as "rich text".  An interesting characteristic of many such
+   representations is that they are to some extent readable even without
+   the software that interprets them.  It is useful to distinguish them,
+   at the highest level, from such unreadable data as images, audio, or
+   text represented in an unreadable form.  In the absence of
+   appropriate interpretation software, it is reasonable to present
+   subtypes of "text" to the user, while it is not reasonable to do so
+   with most non-textual data.  Such formatted textual data can be
+   represented using subtypes of "text".
+
+4.2.2.  Image Media Types
+
+   A top-level type of "image" indicates that the content specifies one
+   or more individual images.  The subtype names the specific image
+   format.
+
+4.2.3.  Audio Media Types
+
+   A top-level type of "audio" indicates that the content contains audio
+   data.  The subtype names the specific audio format.
+
+4.2.4.  Video Media Types
+
+   A top-level type of "video" indicates that the content specifies a
+   time-varying-picture image, possibly with color and coordinated
+   sound.  The term 'video' is used in its most generic sense, rather
+   than with reference to any particular technology or format, and is
+   not meant to preclude subtypes such as animated drawings encoded
+   compactly.
+
+   Note that although in general the mixing of multiple kinds of media
+   in a single body is discouraged [RFC2046], it is recognized that many
+   video formats include a representation for synchronized audio and/or
+   text, and this is explicitly permitted for subtypes of "video".
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 10]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+4.2.5.  Application Media Types
+
+   The "application" top-level type is to be used for discrete data that
+   do not fit under any of the other type names, and particularly for
+   data to be processed by some type of application program.  This is
+   information that must be processed by an application before it is
+   viewable or usable by a user.  Expected uses for the "application"
+   type name include but are not limited to file transfer, spreadsheets,
+   presentations, scheduling data, and languages for "active"
+   (computational) material.  (The last, in particular, can pose
+   security problems that must be understood by implementors.  The
+   "application/postscript" media type registration in [RFC2046]
+   provides a good example of how to handle these issues.)
+
+   For example, a meeting scheduler might define a standard
+   representation for information about proposed meeting dates.  An
+   intelligent user agent would use this information to conduct a dialog
+   with the user, and might then send additional material based on that
+   dialog.  More generally, there have been several "active" languages
+   developed in which programs in a suitably specialized language are
+   transported to a remote location and automatically run in the
+   recipient's environment.  Such applications may be defined as
+   subtypes of the "application" top-level type.
+
+   The subtype of "application" will often either be the name or include
+   part of the name of the application for which the data are intended.
+   This does not mean, however, that any application program name may
+   simply be used freely as a subtype of "application"; the subtype
+   needs to be registered.
+
+4.2.6.  Multipart and Message Media Types
+
+   Multipart and message are composite types; that is, they provide a
+   means of encapsulating zero or more objects, each one a separate
+   media type.
+
+   All subtypes of multipart and message MUST conform to the syntax
+   rules and other requirements specified in [RFC2046] and amended by
+   Section 3.5 of [RFC6532].
+
+
+
+
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 11]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+4.2.7.  Additional Top-Level Types
+
+   In some cases, a new media type may not "fit" under any currently
+   defined top-level type names.  Such cases are expected to be quite
+   rare.  However, if such a case does arise, a new type name can be
+   defined to accommodate it.  Definition of a new top-level type name
+   MUST be done via a Standards Track RFC; no other mechanism can be
+   used to define additional type names.
+
+4.2.8.  Structured Syntax Name Suffixes
+
+   XML in MIME [RFC3023] defined the first such augmentation to the
+   media type definition to additionally specify the underlying
+   structure of that media type.  To quote:
+
+      This document also standardizes a convention (using the suffix
+      '+xml') for naming media types ... when those media types
+      represent XML MIME (Multipurpose Internet Mail Extensions)
+      entities.
+
+   That is, it specified a suffix (in that case, "+xml") to be appended
+   to the base subtype name.
+
+   Since this was published, the de facto practice has arisen for using
+   this suffix convention for other well-known structuring syntaxes.  In
+   particular, media types have been registered with suffixes such as
+   "+der", "+fastinfoset", and "+json".  This specification formalizes
+   this practice and sets up a registry for structured type name
+   suffixes.
+
+   The primary guideline for whether a structured type name suffix is
+   registrable is that it be described by a readily available
+   description, preferably within a document published by an established
+   standards-related organization, and for which there's a reference
+   that can be used in a Normative References section of an RFC.
+
+   Media types that make use of a named structured syntax SHOULD use the
+   appropriate registered "+suffix" for that structured syntax when they
+   are registered.  By the same token, media types MUST NOT be given
+   names incorporating suffixes for structured syntaxes they do not
+   actually employ. "+suffix" constructs for as-yet unregistered
+   structured syntaxes SHOULD NOT be used, given the possibility of
+   conflicts with future suffix definitions.
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 12]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+4.2.9.  Deprecated Aliases
+
+   In some cases, a single media type may have been widely deployed
+   prior to registration under multiple names.  In such cases, a
+   preferred name MUST be chosen for the media type, and applications
+   MUST use this to be compliant with the type's registration.  However,
+   a list of deprecated aliases by which the type is known MAY be
+   supplied as additional information in order to assist applications in
+   processing the media type properly.
+
+4.3.  Parameter Requirements
+
+   Media types MAY elect to use one or more media type parameters, or
+   some parameters may be automatically made available to the media type
+   by virtue of being a subtype of a content type that defines a set of
+   parameters applicable to any of its subtypes.  In either case, the
+   names, values, and meanings of any parameters MUST be fully specified
+   when a media type is registered in the standards tree, and SHOULD be
+   specified as completely as possible when media types are registered
+   in the vendor or personal trees.
+
+   Parameter names have the syntax as media type names and values:
+
+       parameter-name = restricted-name
+
+   Note that this syntax is somewhat more restrictive than what is
+   allowed by the ABNF in [RFC2045] and amended by [RFC2231].
+
+   Parameter names are case-insensitive and no meaning is attached to
+   the order in which they appear.  It is an error for a specific
+   parameter to be specified more than once.
+
+   There is no defined syntax for parameter values.  Therefore,
+   registrations MUST specify parameter value syntax.  Additionally,
+   some transports impose restrictions on parameter value syntax, so
+   care needs be taken to limit the use of potentially problematic
+   syntaxes; e.g., pure binary valued parameters, while permitted in
+   some protocols, are best avoided.
+
+   Note that a protocol can impose further restrictions on parameter
+   value syntax, depending on how it chooses to represent parameters.
+   Both MIME [RFC2045] [RFC2231] and HTTP [RFC2045] [RFC5987] allow
+   binary parameters as well as parameter values expressed in a specific
+   charset, but other protocols may be less flexible.
+
+   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
+
+
+
+Freed, et al.             Best Current Practice                [Page 13]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   not otherwise change existing functionality.  An example of this
+   would be a "revision" parameter to indicate a revision level of an
+   external specification such as JPEG.  Similar behavior is encouraged
+   for media types registered in the vendor or personal trees, but is
+   not required.
+
+   Changes to parameters (including the introduction of new ones) is
+   managed in the same manner as other changes to the media type; see
+   Section 5.5.
+
+4.4.  Canonicalization and Format Requirements
+
+   All registered media types MUST employ a single, canonical data
+   format, regardless of registration tree.
+
+   A permanent and readily available public specification of the format
+   for the media type MUST exist for all types registered in the
+   standards tree.  This specification MUST provide sufficient detail so
+   that interoperability between independent implementations using the
+   media type is possible.  This specification MUST at a minimum be
+   referenced by, if it is not 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
+   and personal trees.  Such registrations are explicitly permitted to
+   limit the information in the registration to which software and
+   version produce or process such media types.  As such, references to
+   or inclusion of format specifications in registrations is encouraged
+   but not required.  Note, however, that the public availability of a
+   meaningful specification will often make the difference between
+   simply having a name reserved so that there are no conflicts with
+   other uses and having the potential for other implementations of the
+   media type and useful interoperation with them.
+
+   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 BCP
+   79 [RFC3979] and BCP 78 [RFC5378] on the use of patented technology
+   in IETF Standards Track protocols must be respected when the
+   specification of a media type is part of a Standards Track protocol.
+   In addition, other standards-related organizations making use of the
+   standards tree may have their own rules regarding intellectual
+   property that must be observed in their registrations.
+
+   Intellectual Property Rights (IPR) disclosures for registrations in
+   the vendor and personal trees are encouraged but not required.
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 14]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+4.5.  Interchange Recommendations
+
+   Ideally, media types will be defined so they interoperate across as
+   many systems and applications as possible.  However, some media types
+   will inevitably have problems interoperating across different
+   platforms.  Problems with different versions, byte ordering, and
+   specifics of gateway handling can and will arise.
+
+   Universal interoperability of media types is not required, but known
+   interoperability issues SHOULD be identified whenever possible.
+   Publication of a media type does not require an exhaustive review of
+   interoperability, and the interoperability considerations section is
+   subject to continuing evaluation.
+
+   The recommendations in this subsection apply regardless of the
+   registration tree involved.
+
+4.6.  Security Requirements
+
+   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 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, the
+   security considerations MUST NOT state that there are "no security
+   issues associated with this type".  Security considerations for types
+   in the vendor or personal tree MAY say that "the security issues
+   associated with this type have not been assessed".
+
+   There is absolutely no 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 of a
+   media type, again regardless of registration tree.
+
+   The security considerations section of all registrations is subject
+   to continuing evaluation and modification, and in particular MAY be
+   extended by use of the "comments on media types" mechanism described
+   in Section 5.4 below.
+
+   Some of the issues that need to be examined and described in a
+   security analysis of a media type are:
+
+   o  Complex media types may include provisions for directives that
+      institute actions on a recipient's files or other resources.  In
+      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
+
+
+
+Freed, et al.             Best Current Practice                [Page 15]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+      type in [RFC2046] for an example of such directives and how they
+      can be described in a media type registration.
+
+   o  Any security analysis MUST state whether or not they employ such
+      "active content"; if they do, they MUST state what steps have been
+      taken, or MUST be taken by applications of the media type, to
+      protect users of the media type from harm.
+
+   o  Complex media types may include provisions for directives that
+      institute actions that, while not directly harmful to the
+      recipient, may result in disclosure of information that either
+      facilitates a subsequent attack or else violates a recipient's
+      privacy in some way.  Again, the registration of the application/
+      postscript media type illustrates how such directives can be
+      handled.
+
+   o  A media type that employs compression may provide an opportunity
+      for sending a small amount of data that, when received and
+      evaluated, expands enormously to consume all of the recipient's
+      resources.  All media types SHOULD state whether or not they
+      employ compression; if they do, they SHOULD discuss what steps
+      need to be taken to avoid such attacks.
+
+   o  A media type might be targeted for applications that require some
+      sort of security assurance but don't provide the necessary
+      security mechanisms themselves.  For example, a media type could
+      be defined for storage of sensitive medical information that in
+      turn requires external confidentiality and integrity protection
+      services, or which is designed for use only within a secure
+      environment.  Types SHOULD always document whether or not they
+      need such services in their security considerations.
+
+4.7.  Requirements Specific to XML Media Types
+
+   There are a number of additional requirements specific to the
+   registration of XML media types.  These requirements are specified in
+   [RFC3023].
+
+4.8.  Encoding Requirements
+
+   Some transports impose restrictions on the type of data they can
+   carry.  For example, Internet mail traditionally was limited to 7bit
+   US-ASCII text.  Encoding schemes are often used to work around such
+   transport limitations.
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 16]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   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
+   are:
+
+   7bit:  The content of the media type consists solely of CRLF-
+      delimited 7bit US-ASCII text.
+
+   8bit:  The content of the media type consists solely of CRLF-
+      delimited 8bit text.
+
+   binary:  The content consists of an unrestricted sequence of octets.
+
+   framed:  The content consists of a series of frames or packets
+      without internal framing or alignment indicators.  Additional out-
+      of-band information is needed to interpret the data properly,
+      including but not necessarily limited to knowledge of the
+      boundaries between successive frames and knowledge of the
+      transport mechanism.  Note that media types of this sort cannot
+      simply be stored in a file or transported as a simple stream of
+      octets; therefore, such media types are unsuitable for use in many
+      traditional protocols.  A commonly used transport with framed
+      encoding is the Real-time Transport Protocol, RTP.  Additional
+      rules for framed encodings defined for transport using RTP are
+      given in [RFC4855].
+
+   Additional restrictions on 7bit and 8bit text are given in Section
+   4.1.1 of [RFC2046].
+
+4.9.  Usage and Implementation Non-Requirements
+
+   In the asynchronous mail environment, where information on the
+   capabilities of the remote mail agent is frequently not available to
+   the sender, maximum interoperability is attained by restricting the
+   media types used to those "common" formats expected to be widely
+   implemented.  This was asserted in the past as a reason to limit the
+   number of possible media types, and 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
+   is recommended for a particular application, that should be asserted
+   by a separate applicability statement specific for the application
+   and/or environment.
+
+   Therefore, universal support and implementation of a media type are
+   NOT a requirement for registration.  However, if a media type is
+
+
+
+Freed, et al.             Best Current Practice                [Page 17]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   explicitly intended for limited use, this MUST be noted in its
+   registration.  The "Restrictions on Usage" field is provided for this
+   purpose.
+
+4.10.  Publication Requirements
+
+   Media types registered in the standards tree by the IETF itself MUST
+   be published as RFCs.  RFC publication of vendor and personal media
+   type registrations is allowed but not required.  In all cases, the
+   IANA will retain copies of all media type registrations and "publish"
+   them as part of the media types registration tree itself.
+
+   As stated previously, standards-tree registrations for media types
+   defined in documents produced by other standards-related
+   organizations MUST be described by a formal standards specification
+   produced by that organization.  Additionally, any copyright on the
+   registration template MUST allow the IANA to copy it into the IANA
+   registry.
+
+   Other than IETF registrations in the standards tree, the registration
+   of a media type does not imply endorsement, approval, or
+   recommendation by the IANA or the IETF or even certification that the
+   specification is adequate.  To become an IETF standard, a protocol or
+   data object must go through the IETF standards process.  While it
+   provides additional assurances when it is appropriate, this is too
+   difficult and too lengthy a process for the convenient registration
+   of media types.
+
+   The standards tree exists for media types that do require a
+   substantive review and approval process in a recognized standards-
+   related organization.  The vendor and personal trees exist for those
+   media types that do not require such a process.  It is expected that
+   applicability statements for particular applications will be
+   published from time to time in the IETF, recommending implementation
+   of, and support for, media types that have proven particularly useful
+   in those contexts.
+
+   As discussed above, registration of a top-level type requires
+   Standards Action in the IETF and, hence, the publication of a RFC on
+   the Standards Track.
+
+4.11.  Fragment Identifier Requirements
+
+   Media type registrations can specify how applications should
+   interpret fragment identifiers (specified in Section 3.5 of
+   [RFC3986]) associated with the media type.
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 18]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   Media types are encouraged to adopt fragment identifier schemes that
+   are used with semantically similar media types.  In particular, media
+   types that use a named structured syntax with a registered "+suffix"
+   MUST follow whatever fragment identifier rules are given in the
+   structured syntax suffix registration.
+
+4.12.  Additional Information
+
+   Various sorts of optional information SHOULD be included in the
+   specification of a media type if it is available:
+
+   o  Magic number(s) (length, octet values).  Magic numbers are byte
+      sequences that are always present at a given place in the file and
+      thus can be used to identify entities as being of a given media
+      type.
+
+   o  File name extension(s) commonly used on one or more platforms to
+      indicate that some file contains a given media type.
+
+   o  Mac OS File Type code(s) (4 octets) used to label files containing
+      a given media type.  Some discussion of Macintosh file type codes
+      and their purpose can be found in [MacOSFileTypes].
+
+   In the case of a registration in the standards tree, this additional
+   information MAY be provided in the formal specification of the media
+   type format.  It is suggested that this be done by incorporating the
+   IANA media type registration form into the format specification
+   itself.
+
+5.  Media Type Registration Procedures
+
+   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.
+
+   Normal IETF processes need to 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 media-types@iana.org
+   list as discussed below.
+
+5.1.  Preliminary Community Review
+
+   Notice of a potential media type registration in the standards tree
+   SHOULD be sent to the media-types@iana.org mailing list for review.
+   This 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; doing so is entirely OPTIONAL,
+   but is strongly encouraged.
+
+
+
+Freed, et al.             Best Current Practice                [Page 19]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   The intent of the public posting to this list is to solicit comments
+   and feedback on the choice of type/subtype name, the unambiguity of
+   the references with respect to versions and external profiling
+   information, and a review of any interoperability or security
+   considerations.  The submitter may submit a revised registration
+   proposal or abandon the registration completely and at any time.
+
+5.2.  Submit Request to IANA
+
+   Media types registered in the standards tree by the IETF itself MUST
+   be reviewed and approved by the IESG as part of the normal standards
+   process.  Standards-tree registrations by recognized standards-
+   related organizations as well as registrations in the vendor and
+   personal trees are submitted directly to the IANA, unless other
+   arrangements were made as part of a liaison agreement.  In either
+   case, posting the registration to the media-types@iana.org list for
+   review prior to submission is strongly encouraged.
+
+   Registration requests can be sent to iana@iana.org.  A web form for
+   registration requests is also available:
+
+     http://www.iana.org/form/media-types
+
+5.2.1.  Provisional Registrations
+
+   Standardization processes often take considerable time to complete.
+   In order to facilitate prototyping and testing, it is often helpful
+   to assign identifiers, including but not limited to media types,
+   early in the process.  This way, identifiers used during standards
+   development can remain unchanged once the process is complete, and
+   implementations and documentation do not have to be updated.
+
+   Accordingly, a provisional registration process is provided to
+   support early assignment of media type names in the standards tree.
+   A provisional registration MAY be submitted to IANA for standards-
+   tree types.  The only required fields in such registrations are the
+   media type name and contact information (including the standards-
+   related organization name).
+
+   Upon receipt of a provisional registration, IANA will check the name
+   and contact information, then publish the registration in a distinct
+   publicly visible provisional registration list.
+
+   Provisional registrations MAY be updated or abandoned at any time.
+   When the registration is abandoned, the media type is no longer
+   registered in any sense; it can subsequently be registered just like
+   any other unassigned media type name.
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 20]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+5.3.  Review and Approval
+
+   With the exception of provisional standards-tree registrations,
+   registrations submitted to the IANA will be passed on to the media
+   types reviewer.  The media types reviewer, who is appointed by the
+   IETF Applications Area Director(s), will review the registration to
+   make sure it meets the requirements set forth in this document.
+   Registrations that do not meet these requirements will be returned to
+   the submitter for revision.
+
+   Decisions made by the media types reviewer may be appealed to the
+   IESG using the procedure specified in Section 6.5.4 of [RFC2026].
+
+   Once a media type registration has passed review, the IANA will
+   register the media type and make the media type registration
+   available to the community.
+
+   In the case of standards-tree registrations from other standards-
+   related organizations, IANA will also check that the submitter is in
+   fact a recognized standards-related organization.  If the submitter
+   is not currently recognized as such, the IESG will be asked to
+   confirm their status.  Recognition from the IESG MUST be obtained
+   before a standards-tree registration can proceed.
+
+5.4.  Comments on Media Type Registrations
+
+   Comments on registered media types may be submitted by members of the
+   community to the IANA at iana@iana.org.  These comments will be
+   reviewed by the media types reviewer and then passed on to the
+   "owner" of the media type if possible.  Submitters of comments may
+   request that their comment be attached to the media type registration
+   itself; if the IANA, in consultation with the media types reviewer,
+   approves, the comment will be made accessible in conjunction with the
+   type registration.
+
+5.5.  Change Procedures
+
+   Once a media type has been published by the 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
+   for the original registration request is used to process a change
+   request.
+
+   Media type registrations may not be deleted; media types that are no
+   longer believed appropriate for use can be declared OBSOLETE by a
+   change to their "intended use" field; such media types will be
+   clearly marked in the lists published by the IANA.
+
+
+
+Freed, et al.             Best Current Practice                [Page 21]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   Significant changes to a media type's definition should be requested
+   only when there are serious omissions or errors in the published
+   specification.  When review is required, a change request may be
+   denied if it renders entities that were valid under the previous
+   definition invalid under the new definition.
+
+   The owner of a media type may pass responsibility to another person
+   or agency by informing the IANA; this can be done without discussion
+   or review.
+
+   The IESG may reassign responsibility for a 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.
+
+5.6.  Registration Template
+
+   Type name:
+
+   Subtype name:
+
+   Required parameters:
+
+   Optional parameters:
+
+   Encoding considerations:
+
+   Security considerations:
+
+   Interoperability considerations:
+
+   Published specification:
+
+   Applications that use this media type:
+
+   Fragment identifier considerations:
+
+   Additional information:
+
+     Deprecated alias names for this type:
+     Magic number(s):
+     File extension(s):
+     Macintosh file type code(s):
+
+   Person & email address to contact for further information:
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 22]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   Intended usage:
+
+   (One of COMMON, LIMITED USE, or OBSOLETE.)
+
+   Restrictions on usage:
+
+   (Any restrictions on where the media type can be used go here.)
+
+   Author:
+
+   Change controller:
+
+   Provisional registration? (standards tree only):
+
+   (Any other information that the author deems interesting may be
+   added below this line.)
+
+   "N/A", written exactly that way, can be used in any field if desired
+   to emphasize the fact that it does not apply or that the question was
+   not omitted by accident.  Do not use 'none' or other words that could
+   be mistaken for a response.
+
+   Limited-use media types should also note in the applications list
+   whether or not that list is exhaustive.
+
+6.  Structured Syntax Suffix Registration Procedures
+
+   Someone wishing to define a "+suffix" name for a structured syntax
+   for use with a new media type registration SHOULD:
+
+   1.  Check IANA's registry of media type name suffixes to see whether
+       or not there is already an entry for that well-defined structured
+       syntax.
+
+   2.  If there is no entry for their suffix scheme, fill out the
+       template (specified in Section 6.2) and include that with the
+       media type registration.  The template may be contained in an
+       Internet Draft, alone or as part of some other protocol
+       specification.  The template may also be submitted in some other
+       form (as part of another document or as a stand-alone document),
+       but the contents will be treated as an "IETF Contribution" under
+       the guidelines of BCP 78 [RFC5378].
+
+   3.  Send a copy of the template or a pointer to the containing
+       document (with specific reference to the section with the
+       template) to the mailing list media-types@iana.org, requesting
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 23]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+       review.  This may be combined with a request to review the media
+       type registration.  Allow a reasonable time for discussion and
+       comments.
+
+   4.  Respond to review comments and make revisions to the proposed
+       registration as needed to bring it into line with the guidelines
+       given in this document.
+
+   5.  Submit the (possibly updated) registration template (or pointer
+       to the document containing it) to IANA at iana@iana.org.
+
+   Upon receipt of a structured syntax suffix registration request,
+
+   1.  IANA checks the submission for completeness; if sections are
+       missing or citations are not correct, IANA rejects the
+       registration request.
+
+   2.  IANA checks the current registry for an entry with the same name;
+       if such a registry exists, IANA rejects the registration request.
+
+   3.  IANA requests Expert Review of the registration request against
+       the corresponding guidelines.
+
+   4.  The Designated Expert may request additional review or
+       discussion, as necessary.
+
+   5.  If Expert Review recommends registration, IANA adds the
+       registration to the appropriate registry.
+
+   The initial registry content specification [RFC6839] provides
+   examples of structured syntax suffix registrations.
+
+6.1.  Change Procedures
+
+   Registrations may be updated in each registry by the same mechanism
+   as required for an initial registration.  In cases where the original
+   definition of the scheme is contained in an IESG-approved document,
+   update of the specification also requires IESG approval.
+
+6.2.  Structured Syntax Suffix Registration Template
+
+   This template describes the fields that must be supplied in a
+   structured syntax suffix registration request:
+
+   Name
+      Full name of the well-defined structured syntax.
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 24]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   +suffix
+      Suffix used to indicate conformance to the syntax.
+
+   References
+      Include full citations for all specifications necessary to
+      understand the structured syntax.
+
+   Encoding considerations
+      General guidance regarding encoding considerations for any type
+      employing this syntax should be given here.  The same requirements
+      for media type encoding considerations given in Section 4.8 apply
+      here.
+
+   Interoperability considerations
+      Any issues regarding the interoperable use of types employing this
+      structured syntax should be given here.  Examples would include
+      the existence of incompatible versions of the syntax, issues
+      combining certain charsets with the syntax, or incompatibilities
+      with other types or protocols.
+
+   Fragment identifier considerations
+      Generic processing of fragment identifiers for any type employing
+      this syntax should be described here.
+
+   Security considerations
+      Security considerations shared by media types employing this
+      structured syntax must be specified here.  The same requirements
+      for media type security considerations given in Section 4.6 apply
+      here, with the exception that the option of not assessing the
+      security considerations is not available for suffix registrations.
+
+   Contact
+      Person (including contact information) to contact for further
+      information.
+
+   Author/Change controller.
+      Person (including contact information) authorized to change this
+      suffix registration.
+
+7.  Security Considerations
+
+   Security requirements for both media type and media type suffix
+   registrations are discussed in Section 4.6.
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 25]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+8.  IANA Considerations
+
+   The purpose of this document is to define IANA registries for media
+   types and structured syntax suffixes as well as the procedures for
+   managing these registries.  Additionally, this document requires IANA
+   to maintain a list of standards-related organizations for which the
+   IESG has approved media type registrations in the standards tree.
+
+   The existing media type registry has been extended to include a
+   section for provisional registrations.  Only standards-tree
+   registrations are allowed in the standards tree and only at the
+   request of an organization on the IANA list of standards-related
+   organizations.  See Section 5.2.1 for additional information on
+   provisional registrations.
+
+   IANA has also added the following note at the top of the provisional
+   registry:
+
+      This registry, unlike some other provisional IANA registries, is
+      only for temporary use.  Entries in this registry are either
+      finalized and moved to the main media types registry, or are
+      abandoned and deleted.  Entries in this registry are suitable for
+      use for development and test purposes only.
+
+   The structured syntax name suffix registry has been created as
+   follows:
+
+   o  The name is the "Structured Syntax Suffix" registry.
+
+   o  The registration process is specified in Section 6.
+
+   o  The information required for a registry entry as well as the entry
+      format are specified in Section 6.2.
+
+   o  The initial content of the registry is specified in [RFC6839].
+
+   Entries in both the media type and structured suffix registries will
+   be annotated by IANA with both the original registration date as well
+   as the date of the most recent update to the entry.  Registrations
+   made prior to the implementation of this specification may, if
+   necessary, be marked as such, rather than with a specific date.
+
+   Since registration entries can be updated multiple times, IANA will
+   also maintain the history of changes to each registration in such a
+   way that the state of the registration at any given time can be
+   determined.
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 26]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   Finally, per this document, IANA has created a new email address,
+   media-types@iana.org, for the media type review list, which replaces
+   the ietf-types@iana.org address specified in RFC 4288.
+   ietf-types@iana.org has been retained as an alias.
+
+9.  Acknowledgments
+
+   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] [RFC4288].  We hope that the current version is one with
+   which he would have agreed but, as it is impossible to verify that
+   agreement, we have regretfully removed his name as a co-author.
+
+   Randy Bush, Francis Dupont, Bjoern Hoehrmann, Barry Leiba, Murray
+   Kucherawy, Alexey Melnikov, S. Moonesamy, Mark Nottingham, Tom Petch,
+   Peter Saint-Andre, and Jeni Tennison provided many helpful review
+   comments and suggestions.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2045]         Freed, N. and N. Borenstein, "Multipurpose Internet
+                     Mail Extensions (MIME) Part One: Format of Internet
+                     Message Bodies", RFC 2045, November 1996.
+
+   [RFC2046]         Freed, N. and N. Borenstein, "Multipurpose Internet
+                     Mail Extensions (MIME) Part Two: Media Types",
+                     RFC 2046, November 1996.
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2978]         Freed, N. and J. Postel, "IANA Charset Registration
+                     Procedures", BCP 19, RFC 2978, October 2000.
+
+   [RFC3023]         Murata, M., St. Laurent, S., and D. Kohn, "XML
+                     Media Types", RFC 3023, January 2001.
+
+   [RFC3629]         Yergeau, F., "UTF-8, a transformation format of ISO
+                     10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3979]         Bradner, S., "Intellectual Property Rights in IETF
+                     Technology", BCP 79, RFC 3979, March 2005.
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 27]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   [RFC3986]         Berners-Lee, T., Fielding, R., and L. Masinter,
+                     "Uniform Resource Identifier (URI): Generic
+                     Syntax", STD 66, RFC 3986, January 2005.
+
+   [RFC4855]         Casner, S., "Media Type Registration of RTP Payload
+                     Formats", RFC 4855, February 2007.
+
+   [RFC5226]         Narten, T. and H. Alvestrand, "Guidelines for
+                     Writing an IANA Considerations Section in RFCs",
+                     BCP 26, RFC 5226, May 2008.
+
+   [RFC5234]         Crocker, D. and P. Overell, "Augmented BNF for
+                     Syntax Specifications: ABNF", STD 68, RFC 5234,
+                     January 2008.
+
+   [RFC5378]         Bradner, S. and J. Contreras, "Rights Contributors
+                     Provide to the IETF Trust", BCP 78, RFC 5378,
+                     November 2008.
+
+   [RFC6532]         Yang, A., Steele, S., and N. Freed,
+                     "Internationalized Email Headers", RFC 6532,
+                     February 2012.
+
+   [RFC6657]         Melnikov, A. and J. Reschke, "Update to MIME
+                     regarding "charset" Parameter Handling in Textual
+                     Media Types", RFC 6657, July 2012.
+
+   [RFC6839]         Hansen, T. and A. Melnikov, "Additional Media Type
+                     Structured Syntax Suffixes", RFC 6839,
+                     January 2013.
+
+10.2.  Informative References
+
+   [MacOSFileTypes]  Apple Computer, Inc., "Mac OS: File Type and
+                     Creator Codes, and File Formats", Apple Knowledge
+                     Base Article 55381, June 1993,
+                     <http://www.info.apple.com/kbnum/n55381>.
+
+   [RFC2026]         Bradner, S., "The Internet Standards Process --
+                     Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2048]         Freed, N., Klensin, J., and J. Postel,
+                     "Multipurpose Internet Mail Extensions (MIME) Part
+                     Four: Registration Procedures", BCP 13, RFC 2048,
+                     November 1996.
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 28]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   [RFC2231]         Freed, N. and K. Moore, "MIME Parameter Value and
+                     Encoded Word Extensions:
+                     Character Sets, Languages, and Continuations",
+                     RFC 2231, November 1997.
+
+   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                     Masinter, L., Leach, P., and T. Berners-Lee,
+                     "Hypertext Transfer Protocol -- HTTP/1.1",
+                     RFC 2616, June 1999.
+
+   [RFC4288]         Freed, N. and J. Klensin, "Media Type
+                     Specifications and Registration Procedures",
+                     BCP 13, RFC 4288, December 2005.
+
+   [RFC5987]         Reschke, J., "Character Set and Language Encoding
+                     for Hypertext Transfer Protocol (HTTP) Header Field
+                     Parameters", RFC 5987, August 2010.
+
+   [RFC6648]         Saint-Andre, P., Crocker, D., and M. Nottingham,
+                     "Deprecating the "X-" Prefix and Similar Constructs
+                     in Application Protocols", BCP 178, RFC 6648,
+                     June 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 29]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+Appendix A.  Grandfathered Media Types
+
+   A number of media types with unfaceted subtype names, registered
+   prior to 1996, would, if registered under the guidelines in this
+   document, be given a faceted name and placed into either the 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 apply to those
+   types as if they had been registered in the trees described above.
+
+   From time to time there may also be cases where a media type with an
+   unfaceted subtype name has been widely deployed without being
+   registered.  (Note that this includes subtype names beginning with
+   the "x-" prefix.)  If possible, such a media type SHOULD be
+   reregistered with a proper faceted subtype name, possibly using a
+   deprecated alias to identify the original name (see Section 4.2.9).
+   However, if this is not possible, the type can, subject to approval
+   by both the media types reviewer and the IESG, be registered in the
+   proper tree with its unfaceted name.
+
+Appendix B.  Changes since RFC 4288
+
+   o  Suffixes to indicate the use of a particular structured syntax are
+      now fully specified and a suffix registration process has been
+      defined.
+
+   o  Registration of widely deployed unregistered unfaceted type names
+      in the vendor or personal trees is now allowed, subject to
+      approval by the media types reviewer and the IESG.
+
+   o  The standards-tree registration process has been revised to
+      include Expert Review and generalized to address cases like media
+      types in non-IETF stream documents.
+
+   o  A field for fragment identifiers has been added to the
+      registration template and brief directions for specifying fragment
+      identifiers have been added.
+
+   o  The specification requirements for personal-tree registrations
+      have been changed to be the same as those for the vendor tree.
+      The text has been changed to encourage (but not require)
+      specification availability.
+
+   o  The process for defining additional trees has been clarified to
+      state that an IETF Standards Action is required.
+
+   o  Widely deployed types with "x-" names can now be registered as an
+      exception in the vendor tree.
+
+
+
+Freed, et al.             Best Current Practice                [Page 30]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+   o  The requirements on changes to registrations have been loosened so
+      minor changes are easier to make.
+
+   o  The registration process has been completely restructured so that
+      with the exception of IETF-generated types in the standards tree,
+      all requests are processed by IANA and not the IESG.
+
+   o  A provisional registration process has been added for early
+      assignment of types in the standards tree.
+
+   o  Many editorial changes have been made throughout the document to
+      make the requirements and processes it describes clearer and
+      easier to follow.
+
+   o  The ability to specify a list of deprecated aliases for a media
+      type has been added.
+
+   o  Types with names beginning with "x-" are no longer considered to
+      be members of the unregistered "x." tree.  As with any unfaceted
+      type, special procedures have been added to allow registration of
+      such types in an appropriate tree.
+
+   o  Changes to a type registered by a third party may now be made by
+      the designated change controller even if that isn't the vendor or
+      organization that created the type.  However, the vendor or
+      organization may elect to assert ownership and change controller
+      over the type at any time.
+
+   o  Limited-use media types are now asked to note whether or not the
+      supplied list of applications employing the media type is
+      exhaustive.
+
+   o  The ABNF for media type names has been further restricted to
+      require that names begin with an alphanumeric character.
+
+   o  Mailing list review is no longer required prior to registration of
+      media types.  Additionally, the address associated with the media
+      type review mailing list has been changed to media-types@iana.org.
+
+   o  The rules for text/* media types have been updated to reflect the
+      changes specified in [RFC6657].
+
+
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 31]
+
+RFC 6838                 Media Type Registration            January 2013
+
+
+Authors' Addresses
+
+   Ned Freed
+   Oracle
+   800 Royal Oaks
+   Monrovia, CA  91016-6347
+   USA
+
+   EMail: ned+ietf@mrochek.com
+
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+   USA
+
+   EMail: john+ietf@jck.com
+
+
+   Tony Hansen
+   AT&T Laboratories
+   200 Laurel Ave.
+   Middletown, NJ  07748
+   USA
+
+   EMail: tony+mtsuffix@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed, et al.             Best Current Practice                [Page 32]
+