summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4288.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4288.txt')
-rw-r--r--doc/rfc/rfc4288.txt1347
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]
+