doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4288.txt b/doc/rfc/rfc4288.txt
new file mode 100644
index 0000000..7405600
--- /dev/null
+++ b/doc/rfc/rfc4288.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                           N. Freed
+Request for Comments: 4288                              Sun Microsystems
+BCP: 13                                                       J. Klensin
+Obsoletes: 2048                                            December 2005
+Category: Best Current Practice
+
+
+         Media Type Specifications and Registration Procedures
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines procedures for the specification and
+   registration of media types for use in MIME and other Internet
+   protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 1]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Media Type Registration Preliminaries ...........................4
+   3. Registration Trees and Subtype Names ............................4
+      3.1. Standards Tree .............................................4
+      3.2. Vendor Tree ................................................5
+      3.3. Personal or Vanity Tree ....................................5
+      3.4. Special x. Tree ............................................5
+      3.5. Additional Registration Trees ..............................6
+   4. Registration Requirements .......................................6
+      4.1. Functionality Requirement ..................................6
+      4.2. Naming Requirements ........................................6
+         4.2.1. Text Media Types ......................................7
+         4.2.2. Image Media Types .....................................8
+         4.2.3. Audio Media Types .....................................8
+         4.2.4. Video Media Types .....................................8
+         4.2.5. Application Media Types ...............................9
+         4.2.6. Multipart and Message Media Types .....................9
+         4.2.7. Additional Top-level Types ............................9
+      4.3. Parameter Requirements ....................................10
+      4.4. Canonicalization and Format Requirements ..................10
+      4.5. Interchange Recommendations ...............................11
+      4.6. Security Requirements .....................................11
+      4.7. Requirements specific to XML media types ..................13
+      4.8. Encoding Requirements .....................................13
+      4.9. Usage and Implementation Non-requirements .................13
+      4.10. Publication Requirements .................................14
+      4.11. Additional Information ...................................15
+   5. Registration Procedure .........................................15
+      5.1. Preliminary Community Review ..............................16
+      5.2. IESG Approval .............................................16
+      5.3. IANA Registration .........................................16
+      5.4. Media Types Reviewer ......................................16
+   6. Comments on Media Type Registrations ...........................17
+   7. Location of Registered Media Type List .........................17
+   8. IANA Procedures for Registering Media Types ....................17
+   9. Change Procedures ..............................................18
+   10. Registration Template .........................................19
+   11. Security Considerations .......................................20
+   12. IANA Considerations ...........................................20
+   13. Acknowledgements ..............................................20
+   14. References ....................................................20
+   Appendix A.  Grandfathered Media Types ............................22
+   Appendix B.  Changes Since RFC 2048 ...............................22
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 2]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+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 MIME [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
+   a central registry.
+
+   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 has now been moved to this separate
+      document, to make it clear that it is independent of MIME.
+
+      It may be desirable to restrict the use of media types to specific
+      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.
+
+1.1.  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].
+
+   This specification makes use of the Augmented Backus-Naur Form (ABNF)
+   [RFC4234] notation, including the core rules defined in Appendix A of
+   that document.
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 3]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+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 may 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., names of the form
+   "tree.subtree...subtype".  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
+   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 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
+   general specification of some sort.
+
+   Media types in the standards tree are normally denoted by names that
+   are not explicitly faceted, i.e., do not contain period (".", full
+   stop) characters.
+
+   The "owner" of a media type registration in the standards tree is
+   assumed to be the standards body itself.  Modification or alteration
+   of the specification requires the same level of processing (e.g.,
+   standards track) required for the initial registration.
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 4]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+3.2.  Vendor Tree
+
+   The vendor tree is used for media types associated with commercially
+   available products.  "Vendor" or "producer" are construed as
+   equivalent and very broadly in this context.
+
+   A registration may be placed in the 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 being registered.
+   Changes to the specification will be made at their request, as
+   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
+   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 is not required, using the ietf-types@iana.org
+   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.
+
+3.3.  Personal or Vanity Tree
+
+   Registrations for media types created experimentally or as part of
+   products that are not distributed commercially may be registered in
+   the personal or vanity tree.  The registrations are distinguished by
+   the leading facet "prs.".
+
+   The owner of "personal" registrations and associated specifications
+   is the person or entity making the registration, or one to whom
+   responsibility has been transferred as described below.
+
+   While public exposure and review of media types to be registered in
+   the personal tree is not required, using the 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.
+
+3.4.  Special x. Tree
+
+   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 in "x-" are used.  These types are
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 5]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   unregistered, experimental, and 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 experimental types.  Therefore, use of
+   both "x-" and "x." forms is discouraged.
+
+   Types in this tree MUST NOT be registered.
+
+3.5.  Additional Registration Trees
+
+   From time to time and as required by the community, the IANA may, by
+   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 for external registration and management by well-known
+   permanent bodies; 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.  Establishment of these new trees will be
+   announced through RFC publication approved by the IESG.
+
+4.  Registration Requirements
+
+   Media type registration proposals 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.
+
+4.1.  Functionality Requirement
+
+   Media types MUST function as an actual media format.  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 type and subtype names.
+   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.
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 6]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   Type and subtype names beginning with "X-" are reserved for
+   experimental use and MUST NOT be registered.  This parallels the
+   restriction on the x. tree, as discussed in Section 3.4.
+
+
+   Type and subtype names MUST conform to the following ABNF:
+
+       type-name = reg-name
+       subtype-name = reg-name
+
+       reg-name = 1*127reg-name-chars
+       reg-name-chars = ALPHA / DIGIT / "!" /
+                       "#" / "$" / "&" / "." /
+                       "+" / "-" / "^" / "_"
+
+   Note that this syntax is somewhat more restrictive than what is
+   allowed by the ABNF in [RFC2045].
+
+   In accordance with the rules specified in [RFC3023], media subtypes
+   that do not represent XML entities MUST NOT be given a name that ends
+   with the "+xml" suffix.  More generally, "+suffix" constructs should
+   be used with care, given the possibility of conflicts with future
+   suffix definitions.
+
+   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 name 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 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" media type is intended for sending material that is
+   principally textual in form.  A "charset" parameter MAY be used to
+   indicate the charset of the body text for "text" subtypes, notably
+   including the subtype "text/plain", which is a generic subtype for
+   plain text defined in [RFC2046].  If defined, a text "charset"
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 7]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   parameter MUST be used to specify a charset name defined in
+   accordance to the procedures laid out in [RFC2978].
+
+   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 opposite 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 should be
+   represented using subtypes of "text".
+
+4.2.2.  Image Media Types
+
+   A media type of "image" indicates that the content specifies or more
+   separate images that require appropriate hardware to display.  The
+   subtype names the specific image format.
+
+4.2.3.  Audio Media Types
+
+   A media type of "audio" indicates that the content contains audio
+   data.
+
+4.2.4.  Video Media Types
+
+   A media 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 this document strongly discourages the
+   mixing of multiple media in a single body, it is recognized that many
+   so-called video formats include a representation for synchronized
+   audio and/or text, and this is explicitly permitted for subtypes of
+   "video".
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 8]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+4.2.5.  Application Media Types
+
+   The "application" media type is to be used for discrete data that do
+   not fit in any of the media types, 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" media type
+   include but are not limited to file transfer, spreadsheets,
+   presentations, scheduling data, and languages for "active"
+   (computational) material.  (The latter, in particular, can pose
+   security problems that must be understood by implementors, and are
+   considered in detail in the discussion of the "application/
+   PostScript" media type in [RFC2046].)
+
+   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" media type.
+
+   The subtype of "application" will often be either 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 be
+   used freely as a subtype of "application".
+
+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 labeled with its
+   own media type.
+
+   All subtypes of multipart and message MUST conform to the syntax
+   rules and other requirements specified in [RFC2046].
+
+4.2.7.  Additional Top-level Types
+
+   In some cases a new media type may not "fit" under any currently
+   defined top-level content type.  Such cases are expected to be quite
+   rare.  However, if such a case does arise a new top-level type can be
+   defined to accommodate it.  Such a definition MUST be done via
+   standards-track RFC; no other mechanism can be used to define
+   additional top-level content types.
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 9]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+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 = reg-name
+
+   Note that this syntax is somewhat more restrictive than what is
+   allowed by the ABNF in [RFC2045] and amended by [RFC2231].
+
+   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 should be taken to limit the use of potentially problematic
+   syntaxes; e.g., pure binary valued parameters, while permitted in
+   some protocols, probably should be avoided.
+
+   New parameters SHOULD NOT be defined as a way to introduce new
+   functionality in types registered in the standards tree, although new
+   parameters MAY be added to convey additional information that does
+   not otherwise change existing functionality.  An example of this
+   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.
+
+4.4.  Canonicalization and Format Requirements
+
+   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
+   media type MUST exist for all types registered in the standards tree
+   and MUST at a minimum be referenced by, if it isn't actually included
+   in, the media type registration 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
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 10]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   limit specification to which software and version produce or process
+   such media types.  References to or inclusion of format
+   specifications in registration proposals is encouraged but not
+   required.
+
+   Format specifications are still required for registration in the
+   personal tree, but may be either published as RFCs or otherwise
+   deposited with the IANA.  The deposited specifications will meet the
+   same criteria as those required to register a well-known TCP port
+   and, in particular, need not be made public.
+
+   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
+   [RFC2026] 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
+   bodies making use of the standards tree may have their own rules
+   regarding intellectual property that must be observed in their
+   registrations.
+
+4.5.  Interchange Recommendations
+
+   Media types SHOULD 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.
+
+   These recommendations 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, a statement
+   that there are "no security issues associated with this type" MUST
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 11]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   NOT be confused with "the security issues associates 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 6 below.
+
+   Some of the issues that should be looked at 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
+      type in [RFC2046] for an example of such directives and how they
+      should be described in a media type registration.
+
+   o  All registrations MUST state whether or not they employ such
+      "active content", and if they do, they MUST state what steps have
+      been taken 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, and 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 not provide the necessary security
+      mechanisms themselves.  For example, a media type could be defined
+      for storage of confidential medical information that in turn
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 12]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+      requires an external confidentiality service, or which is designed
+      for use only within a secure environment.
+
+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.
+
+   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 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 [RFC3555].
+
+   Additional restrictions on 7bit and 8bit text are given in [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
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 13]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   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 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
+   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 is
+   NOT a requirement for registration.  However, if a 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.
+
+4.10.  Publication Requirements
+
+   Proposals for media types registered in the standards tree by the
+   IETF itself MUST be published as RFCs.  RFC publication of vendor and
+   personal media type proposals is encouraged but not required.  In all
+   cases the IANA will retain copies of all media type proposals 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 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 to copy it
+   into the IANA registry.
+
+   Other than IETF registrations in the standards tree, the registration
+   of a data type does not imply endorsement, approval, or
+   recommendation by the IANA or the IETF or even certification that the
+   specification is adequate.  To become Internet Standards, a protocol
+   or data object must go through the IETF standards process.  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
+   body.  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
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 14]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   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-track processing in the IETF and, hence, RFC publication.
+
+4.11.  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.
+
+   o  Information about how fragment/anchor identifiers [RFC3986] are
+      constructed for use in conjunction with this 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.  It is suggested that this be done by incorporating the IANA
+   media type registration form into the specification itself.
+
+5.  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.
+
+   The normal 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
+   directly to the IANA, ideally after first posting to the
+   ietf-types@iana.org list for review.
+
+   Proposed registrations in the standards tree by other standards
+   bodies should be communicated to the IESG (at iesg@ietf.org) and to
+   the ietf-types list (at ietf-types@iana.org).  Prior posting as an
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 15]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   Internet Draft is not required for these registrations, but may be
+   helpful to the IESG and is encouraged.
+
+5.1.  Preliminary Community Review
+
+   Notice of a potential media type registration in the standards tree
+   MUST be sent to the "ietf-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.
+
+   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 or
+   abandon the registration completely and at any time.
+
+5.2.  IESG Approval
+
+   Media types registered in the standards tree MUST be approved by the
+   IESG prior to registration.
+
+5.3.  IANA Registration
+
+   Provided that the media type meets all of the relevant requirements
+   and has obtained whatever approval is necessary, the author may
+   submit the registration request to the IANA.  Registration requests
+   can be sent to iana@iana.org.  A web form for registration requests
+   is also available:
+
+     http://www.iana.org/cgi-bin/mediatypes.pl
+
+   Sending to ietf-types@iana.org does not constitute submitting the
+   registration to the IANA.
+
+   When the registration is either part of an RFC publication request or
+   a registration in the standards tree submitted to the IESG, close
+   coordination between the IANA and the IESG means IESG approval in
+   effect submits the registration to the IANA.  There is no need for an
+   additional registration request in such cases.
+
+5.4.  Media Types Reviewer
+
+   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.
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 16]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   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 [RFC2026] section 6.5.4.
+
+   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.
+
+6.  Comments on Media Type Registrations
+
+   Comments on registered media types may be submitted by members of the
+   community to the IANA.  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, and if the IANA
+   approves of this, the comment will be made accessible in conjunction
+   with the type registration.
+
+7.  Location of Registered Media Type List
+
+   Media type registrations are listed by the IANA at:
+
+      http://www.iana.org/assignments/media-types/
+
+8.  IANA Procedures for Registering Media Types
+
+   The IANA will only register media types in the standards tree in
+   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 automatically and without any formal approval
+   process as long as the following minimal conditions are met:
+
+   o  Media types MUST function as an actual media format.  In
+      particular, charsets and transfer encodings MUST NOT be registered
+      as media types.
+
+   o  All media types MUST have properly formed type and subtype names.
+      All type names MUST be defined by a standards-track RFC.  All
+      type/subtype name pairs MUST be unique and MUST contain the proper
+      tree prefix.
+
+   o  Types registered in the personal tree MUST either provide a format
+      specification or a pointer to one.
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 17]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   o  All media types MUST have a reasonable security considerations
+      section.  (It is neither possible nor necessary for the IANA to
+      conduct a comprehensive security review of media type
+      registrations.  Nevertheless, the IANA has the authority to
+      identify obviously incompetent material and return it to the
+      submitter for revision.)
+
+   Registrations in the standards tree MUST satisfy the additional
+   requirement that they originate from the IETF itself or from another
+   standards body recognized as such by the IETF.
+
+9.  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.
+
+   Changes 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 and the ietf-types list; 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.
+
+   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 & Klensin          Best Current Practice                 [Page 18]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+10.  Registration Template
+
+   To: ietf-types@iana.org
+   Subject: Registration of media type XXX/YYY
+
+   Type name:
+
+   Subtype name:
+
+   Required parameters:
+
+   Optional parameters:
+
+   Encoding considerations:
+
+   Security considerations:
+
+   Interoperability considerations:
+
+   Published specification:
+
+   Applications that use this media type:
+
+   Additional information:
+
+     Magic number(s):
+     File extension(s):
+     Macintosh file type code(s):
+
+   Person & email address to contact for further information:
+
+   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:
+
+   (Any other information that the author deems interesting may be added
+   below this line.)
+
+   Some discussion of Macintosh file type codes and their purpose can be
+   found in [MacOSFileTypes].  Additionally, please refrain from writing
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 19]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   "none" or anything similar when no file extension or Macintosh file
+   type is specified, lest "none" be confused with an actual code value.
+
+11.  Security Considerations
+
+   Security requirements for media type registrations are discussed in
+   Section 4.6.
+
+12.  IANA Considerations
+
+   The purpose of this document is to define IANA registries for media
+   types.
+
+13.  Acknowledgements
+
+   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].  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.
+
+14.  References
+
+14.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.
+
+   [RFC3555]        Casner, S. and P. Hoschka, "MIME Type Registration
+                    of RTP Payload Formats", RFC 3555, July 2003.
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 20]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   [RFC3986]        Berners-Lee, T., Fielding, R., and L. Masinter,
+                    "Uniform Resource Identifier (URI): Generic Syntax",
+                    STD 66, RFC 3986, January 2005.
+
+   [RFC4234]        Crocker, D. Ed., and P. Overell, "Augmented BNF for
+                    Syntax Specifications: ABNF", RFC 4234, October
+                    2005.
+
+14.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.
+
+   [RFC2231]        Freed, N. and K. Moore, "MIME Parameter Value and
+                    Encoded Word Extensions: Character Sets, Languages,
+                    and Continuations", RFC 2231, November 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 21]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+Appendix A.  Grandfathered Media Types
+
+   A number of media types, registered prior to 1996, would, if
+   registered under the guidelines in this document, be placed into
+   either the vendor or personal trees.  Reregistration of those types
+   to reflect the appropriate trees is encouraged but not required.
+   Ownership and change control principles outlined in this document
+   apply to those types as if they had been registered in the trees
+   described above.
+
+Appendix B.  Changes Since RFC 2048
+
+   o  Media type specification and registration procedures have been
+      moved out of the MIME document set to this separate specification.
+
+   o  The various URLs and addresses in this document have been changed
+      so they all refer to iana.org rather than isi.edu.  Additionally,
+      many of the URLs have been changed to use HTTP; formerly they used
+      FTP.
+
+   o  Much of the document has been clarified in the light of
+      operational experience with these procedures.
+
+   o  The unfaceted IETF tree is now called the standards tree, and the
+      registration rules for this tree have been relaxed to allow use by
+      other standards bodies.
+
+   o  The text describing the media type registration procedure has
+      clarified.
+
+   o  The rules and requirements for constructing security
+      considerations sections have been extended and clarified.
+
+   o  RFC 3023 is now referenced as the source of additional information
+      concerning the registration of XML media types.
+
+   o  Several of the references in this document have been updated to
+      refer to current versions of the relevant specifications.
+
+   o  A note has been added discouraging the assignment of multiple
+      names to a single media type.
+
+   o  Security considerations and IANA considerations sections have been
+      added.
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 22]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+   o  Concerns regarding copyrights on media type registration templates
+      produced by other standards bodies have been dealt with by
+      requiring that the IANA be allowed to copy the registration
+      template into the registry.
+
+   o  The basic registration requirements for the various top-level
+      types have been moved from RFC 2046 to this document.
+
+   o  A syntax is now specified for media type, subtype, and parameter
+      names.
+
+   o  Imposed a maximum length of 127 on all media type and subtype
+      names.
+
+   o  A note has been added to caution against excessive use of
+      "+suffix" constructs in subtype names.
+
+   o  The encoding considerations field has been extended to allow the
+      value "framed".
+
+   o  A reference describing Macintosh Type codes has been added.
+
+   o  Ietf-types list review of registrations in the standards tree is
+      now required rather than just recommended.
+
+
+Authors' Addresses
+
+   Ned Freed
+   Sun Microsystems
+   3401 Centrelake Drive, Suite 410
+   Ontario, CA  92761-1205
+   USA
+
+   Phone: +1 909 457 4293
+   EMail: ned.freed@mrochek.com
+
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+
+   EMail: klensin+ietf@jck.com
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 23]
+
+RFC 4288                Media Type Registration            December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 24]
+