GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4288

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4288.txt · Last modified: 2005/12/02 18:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki