< draft-ietf-appsawg-media-type-regs-07.txt   draft-ietf-appsawg-media-type-regs-08.txt >
Network Working Group N. Freed Network Working Group N. Freed
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 4288 (if approved) J. Klensin Obsoletes: 4288 (if approved) J. Klensin
Intended status: BCP Intended status: BCP
Expires: November 5, 2012 T. Hansen Expires: November 17, 2012 T. Hansen
AT&T Laboratories AT&T Laboratories
May 4, 2012 May 16, 2012
Media Type Specifications and Registration Procedures Media Type Specifications and Registration Procedures
draft-ietf-appsawg-media-type-regs-07 draft-ietf-appsawg-media-type-regs-08
Abstract Abstract
This document defines procedures for the specification and This document defines procedures for the specification and
registration of media types for use in HTTP, MIME and other Internet registration of media types for use in HTTP, MIME and other Internet
protocols. protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2012. This Internet-Draft will expire on November 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.2.5. Application Media Types . . . . . . . . . . . . . . . 11 4.2.5. Application Media Types . . . . . . . . . . . . . . . 11
4.2.6. Multipart and Message Media Types . . . . . . . . . . 12 4.2.6. Multipart and Message Media Types . . . . . . . . . . 12
4.2.7. Additional Top-level Types . . . . . . . . . . . . . . 12 4.2.7. Additional Top-level Types . . . . . . . . . . . . . . 12
4.2.8. Structured Syntax Name Suffixes . . . . . . . . . . . 12 4.2.8. Structured Syntax Name Suffixes . . . . . . . . . . . 12
4.2.9. Deprecated Aliases . . . . . . . . . . . . . . . . . . 13 4.2.9. Deprecated Aliases . . . . . . . . . . . . . . . . . . 13
4.3. Parameter Requirements . . . . . . . . . . . . . . . . . . 13 4.3. Parameter Requirements . . . . . . . . . . . . . . . . . . 13
4.4. Canonicalization and Format Requirements . . . . . . . . . 14 4.4. Canonicalization and Format Requirements . . . . . . . . . 14
4.5. Interchange Recommendations . . . . . . . . . . . . . . . 15 4.5. Interchange Recommendations . . . . . . . . . . . . . . . 15
4.6. Security Requirements . . . . . . . . . . . . . . . . . . 15 4.6. Security Requirements . . . . . . . . . . . . . . . . . . 15
4.7. Requirements specific to XML media types . . . . . . . . . 16 4.7. Requirements specific to XML media types . . . . . . . . . 16
4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 16 4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 17
4.9. Usage and Implementation Non-requirements . . . . . . . . 17 4.9. Usage and Implementation Non-requirements . . . . . . . . 17
4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18 4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 18 4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 19
4.12. Additional Information . . . . . . . . . . . . . . . . . . 19 4.12. Additional Information . . . . . . . . . . . . . . . . . . 19
5. Media Type Registration Procedures . . . . . . . . . . . . . . 19 5. Media Type Registration Procedures . . . . . . . . . . . . . . 19
5.1. Preliminary Community Review . . . . . . . . . . . . . . . 19 5.1. Preliminary Community Review . . . . . . . . . . . . . . . 20
5.2. Submit request to IANA . . . . . . . . . . . . . . . . . . 20 5.2. Submit request to IANA . . . . . . . . . . . . . . . . . . 20
5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20 5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20
5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 20 5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 21
5.4. Comments on Media Type Registrations . . . . . . . . . . . 21 5.4. Comments on Media Type Registrations . . . . . . . . . . . 21
5.5. Location of Registered Media Type List . . . . . . . . . . 21 5.5. Location of Registered Media Type List . . . . . . . . . . 21
5.6. Change Procedures . . . . . . . . . . . . . . . . . . . . 21 5.6. Change Procedures . . . . . . . . . . . . . . . . . . . . 22
5.7. Registration Template . . . . . . . . . . . . . . . . . . 23 5.7. Registration Template . . . . . . . . . . . . . . . . . . 23
6. Structured Syntax Suffix Registration Procedures . . . . . . . 24 6. Structured Syntax Suffix Registration Procedures . . . . . . . 24
6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 25 6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 25
6.2. Structured Syntax Suffix Registration Template . . . . . . 25 6.2. Structured Syntax Suffix Registration Template . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Recent Internet protocols have been carefully designed to be easily Recent Internet protocols have been carefully designed to be easily
extensible in certain areas. In particular, many protocols, extensible in certain areas. In particular, many protocols,
including but not limited to HTTP [RFC2616] and MIME [RFC2045], are including but not limited to HTTP [RFC2616] and MIME [RFC2045], are
capable of carrying arbitrary labeled content. A mechanism is needed capable of carrying arbitrary labeled content. A mechanism is needed
to label such content and a registration process is needed for these to label such content and a registration process is needed for these
labels, so that that the set of such values are defined in a labels, so that that the set of such values are defined in a
reasonably orderly, well-specified, and public manner. reasonably orderly, well-specified, and public manner.
This document defines media type specification and registration This document defines media type specification and registration
procedures that use the Internet Assigned Numbers Authority (IANA) as procedures (Section 5) that use the Internet Assigned Numbers
a central registry. Authority (IANA) as a central registry.
1.1. Historical Note 1.1. Historical Note
The media type registration process was initially defined for The media type registration process was initially defined for
registering media types for use in the context of the asynchronous registering media types for use in the context of the asynchronous
Internet mail environment. In this mail environment there is a need Internet mail environment. In this mail environment there is a need
to limit the number of possible media types, to increase the to limit the number of possible media types, to increase the
likelihood of interoperability when the capabilities of the remote likelihood of interoperability when the capabilities of the remote
mail system are not known. As media types are used in new mail system are not known. As media types are used in new
environments in which the proliferation of media types is not a environments in which the proliferation of media types is not a
skipping to change at page 4, line 44 skipping to change at page 4, line 44
It may be desirable to restrict the use of media types to specific It may be desirable to restrict the use of media types to specific
environments or to prohibit their use in other environments. This environments or to prohibit their use in other environments. This
revision incorporates such restrictions into media type registrations revision incorporates such restrictions into media type registrations
in a systematic way. See Section 4.9 for additional discussion. in a systematic way. See Section 4.9 for additional discussion.
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
This specification makes use of the Augmented Backus-Naur Form (ABNF) This specification makes use of the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation, including the core rules defined in Appendix A of [RFC5234] notation, including the core rules defined in Appendix A of
that document. that document.
2. Media Type Registration Preliminaries 2. Media Type Registration Preliminaries
Registration of a new media type or types starts with the Registration of a new media type or types starts with the
construction of a registration proposal. Registration may occur construction of a registration proposal. Registration may occur
within several different registration trees that have different within several different registration trees that have different
requirements, as discussed below. In general, a new registration requirements, as discussed below. In general, a new registration
proposal is circulated and reviewed in a fashion appropriate to the proposal is circulated and reviewed in a fashion appropriate to the
tree involved. The media type is then registered if the proposal is tree involved. The media type is then registered if the proposal is
acceptable. The following sections describe the requirements and acceptable. The following sections describe the requirements and
procedures used for each of the different registration trees. procedures used for each of the different registration trees.
3. Registration Trees and Subtype Names 3. Registration Trees and Subtype Names
In order to increase the efficiency and flexibility of the In order to increase the efficiency and flexibility of the
registration process, different structures of subtype names may be registration process, different structures of subtype names can be
registered to accommodate the different natural requirements for, registered to accommodate the different natural requirements for,
e.g., a subtype that will be recommended for wide support and e.g., a subtype that will be recommended for wide support and
implementation by the Internet community, or a subtype that is used implementation by the Internet community, or a subtype that is used
to move files associated with proprietary software. The following to move files associated with proprietary software. The following
subsections define registration "trees" that are distinguished by the subsections define registration "trees" that are distinguished by the
use of faceted names, e.g., names of the form use of faceted names, e.g., names of the form
"tree.subtree...subtype". Note that some media types defined prior "tree.subtree...subtype". Note that some media types defined prior
to this document do not conform to the naming conventions described to this document do not conform to the naming conventions described
below. See Appendix A for a discussion of them. below. See Appendix A for a discussion of them.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
In the second case the IESG makes a one time decision on whether the In the second case the IESG makes a one time decision on whether the
registration submitter represents a recognized standards body; after registration submitter represents a recognized standards body; after
that, a Media Types Reviewer (Designated Expert or a group of that, a Media Types Reviewer (Designated Expert or a group of
Designated Experts) performs the Expert Review as specified in this Designated Experts) performs the Expert Review as specified in this
document. Subsequent submissions from the same source do not involve document. Subsequent submissions from the same source do not involve
the IESG. the IESG.
In the case of registration for the IETF itself, the registration In the case of registration for the IETF itself, the registration
proposal MUST be published as an RFC. When the RFC is in the IETF proposal MUST be published as an RFC. When the RFC is in the IETF
stream it is an IETF Consensus RFC, which can be on the Standards stream it is an IETF Consensus RFC [RFC4844] , which can be on the
Track, a BCP, Informational, or Experimental. Registrations Standards Track, a BCP, Informational, or Experimental.
published in non-IETF RFC streams are also allowed, and require IESG Registrations published in non-IETF RFC streams are also allowed, and
approval. require IESG approval.
In the case of registrations for other recognized standards bodies, In the case of registrations for other recognized standards bodies,
the format MUST be described by a formal standards specification the format MUST be described by a formal standards specification
produced by that body. produced by that body.
A standards-tree registration can be either in a standalone A standards-tree registration can be either in a standalone
"registration only" RFC or incorporated into a more general "registration only" RFC or incorporated into a more general
specification of some sort. specification of some sort.
Media types in the standards tree are normally denoted by names that Media types in the standards tree MUST NOT have faceted names, unless
are not explicitly faceted, i.e., do not contain period (".", full they are grandfathered in using the process described in Appendix A.
stop) characters.
The "owner" of a media type registration in the standards tree is The "owner" of a media type registered in the standards tree is
assumed to be the standards body itself. Modification or alteration assumed to be the standards body itself. Modification or alteration
of the specification uses the same level of processing (e.g., a of the specification uses the same level of processing (e.g., a
registration submitted on Standards Track can be revised in another registration submitted on Standards Track can be revised in another
Standards Track RFC, but cannot be revised in an Informational RFC) Standards Track RFC, but cannot be revised in an Informational RFC)
required for the initial registration. required for the initial registration.
Standards-tree registrations from recognized standards bodies may be Standards-tree registrations from recognized standards bodies may be
submitted directly to the IANA, where they will undergo Expert Review submitted directly to the IANA, where they will undergo Expert Review
[RFC5226] prior to approval. In this case, the Expert Reviewer(s) [RFC5226] prior to approval. In this case, the Expert Reviewer(s)
will, among other things, ensure that the required specification will, among other things, ensure that the required specification
skipping to change at page 9, line 7 skipping to change at page 9, line 7
charset, or as a collection of separate entities of another type, is charset, or as a collection of separate entities of another type, is
not allowed. For example, although applications exist to decode the not allowed. For example, although applications exist to decode the
base64 transfer encoding [RFC2045], base64 cannot be registered as a base64 transfer encoding [RFC2045], base64 cannot be registered as a
media type. media type.
This requirement applies regardless of the registration tree This requirement applies regardless of the registration tree
involved. involved.
4.2. Naming Requirements 4.2. Naming Requirements
All registered media types MUST be assigned type and subtype names. All registered media types MUST be assigned top-level type and
The combination of these names serves to uniquely identify the media subtype names. The combination of these names serves to uniquely
type, and the format of the subtype name identifies the registration identify the media type, and the subtype name facet (or the absence
tree. Both type and subtype names are case-insensitive. of one) identifies the registration tree. Both top-level type and
subtype names are case-insensitive.
Type and subtype names MUST conform to the following ABNF: Type and subtype names MUST conform to the following ABNF:
type-name = restricted-name type-name = restricted-name
subtype-name = restricted-name subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" / restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_" "$" / "&" / "-" / "^" / "_"
skipping to change at page 9, line 38 skipping to change at page 9, line 39
[RFC4288]. Also note that while this syntax allows names of up to [RFC4288]. Also note that while this syntax allows names of up to
127 characters, implementation limits may make such long names 127 characters, implementation limits may make such long names
problematic. For this reason the components of names SHOULD be problematic. For this reason the components of names SHOULD be
limited to 64 characters. limited to 64 characters.
Although the name syntax treats "." as equivalent to any other Although the name syntax treats "." as equivalent to any other
character, characters before any initial "." always specify the character, characters before any initial "." always specify the
registration facet. Note that this means that facet-less standards registration facet. Note that this means that facet-less standards
tree registrations cannot use periods in the subtype name. tree registrations cannot use periods in the subtype name.
Similarly, "+" is used in media type names to introduce a structured Similarly, "+" is used in subtype names to introduce a structured
syntax specifier suffix. Structured syntax suffix requirements are syntax specifier suffix. Structured syntax suffix requirements are
specified in Section 4.2.8. specified in Section 4.2.8.
While it is possible for a given media type to be assigned additional 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 names, the use of different names to identify the same media type is
discouraged. discouraged.
These requirements apply regardless of the registration tree These requirements apply regardless of the registration tree
involved. involved.
The choice of top-level type name MUST take into account the nature The choice of top-level type MUST take into account the nature of
of media type involved. New subtypes of top-level types MUST conform media type involved. New subtypes of top-level types MUST conform to
to the restrictions of the top-level type, if any. The following the restrictions of the top-level type, if any. The following
sections describe each of the initial set of top-level types and sections describe each of the initial set of top-level types and
their associated restrictions. Additionally, various protocols, their associated restrictions. Additionally, various protocols,
including but not limited to HTTP and MIME, MAY impose additional including but not limited to HTTP and MIME, MAY impose additional
restrictions on the media types they can transport. (See [RFC2046] restrictions on the media types they can transport. (See [RFC2046]
for additional information on the restrictions MIME imposes.) for additional information on the restrictions MIME imposes.)
4.2.1. Text Media Types 4.2.1. Text Media Types
The "text" media type is intended for sending material that is The "text" top-level type is intended for sending material that is
principally textual in form. principally textual in form.
Many subtypes of text, notably including the subtype "text/plain", Many subtypes of text, notably including the subtype "text/plain",
which is a generic subtype for plain text defined in [RFC2046], which is a generic subtype for plain text defined in [RFC2046],
define a "charset" parameter. If a "charset" parameter is defined define a "charset" parameter. If a "charset" parameter is defined
for a particular subtype of text, it MUST be used to specify a for a particular subtype of text, it MUST be used to specify a
charset name defined in accordance to the procedures laid out in charset name defined in accordance to the procedures laid out in
[RFC2978]. [RFC2978].
As specified in [I-D.ietf-appsawg-mime-default-charset], a "charset" As specified in [I-D.ietf-appsawg-mime-default-charset], a "charset"
skipping to change at page 10, line 34 skipping to change at page 10, line 35
If a "charset" parameter is specified, it SHOULD be a required If a "charset" parameter is specified, it SHOULD be a required
parameter, eliminating the options of specifying a default value. If parameter, eliminating the options of specifying a default value. If
there is a strong reason for the parameter to be optional despite there is a strong reason for the parameter to be optional despite
this advice, each subtype MAY specify its own default value, or this advice, each subtype MAY specify its own default value, or
alternately, it MAY specify that there is no default value. Finally, alternately, it MAY specify that there is no default value. Finally,
the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See
[I-D.ietf-appsawg-mime-default-charset] for additional information on [I-D.ietf-appsawg-mime-default-charset] for additional information on
the use of "charset" parameters in conjunction with subtypes of text. the use of "charset" parameters in conjunction with subtypes of text.
Regardless of what approach is chosen, all text/* registrations MUST
clearly specify how the charset is determined; relying on the US-
ASCII default defined in Section 4.1.2 of [RFC2046] is no longer
permitted. If explanatory text is needed this SHOULD be placed in
the additional information section of the registration.
Plain text does not provide for or allow formatting commands, font Plain text does not provide for or allow formatting commands, font
attribute specifications, processing instructions, interpretation attribute specifications, processing instructions, interpretation
directives, or content markup. Plain text is seen simply as a linear directives, or content markup. Plain text is seen simply as a linear
sequence of characters, possibly interrupted by line breaks or page sequence of characters, possibly interrupted by line breaks or page
breaks. Plain text MAY allow the stacking of several characters in breaks. Plain text MAY allow the stacking of several characters in
the same position in the text. Plain text in scripts like Arabic and the same position in the text. Plain text in scripts like Arabic and
Hebrew may also include facilities that allow the arbitrary mixing of Hebrew may also include facilities that allow the arbitrary mixing of
text segments with different writing directions. text segments with different writing directions.
Beyond plain text, there are many formats for representing what might Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without representations is that they are to some extent readable even without
the software that interprets them. It is useful to distinguish them, the software that interprets them. It is useful to distinguish them,
at the highest level, from such unreadable data as images, audio, or at the highest level, from such unreadable data as images, audio, or
text represented in an unreadable form. In the absence of text represented in an unreadable form. In the absence of
appropriate interpretation software, it is reasonable to present appropriate interpretation software, it is reasonable to present
subtypes of "text" to the user, while it is not reasonable to do so 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 with most non-textual data. Such formatted textual data can be
represented using subtypes of "text". represented using subtypes of "text".
4.2.2. Image Media Types 4.2.2. Image Media Types
A media type of "image" indicates that the content specifies one or A top-level type of "image" indicates that the content specifies one
more individual images. The subtype names the specific image format. or more individual images. The subtype names the specific image
format.
4.2.3. Audio Media Types 4.2.3. Audio Media Types
A media type of "audio" indicates that the content contains audio A top-level type of "audio" indicates that the content contains audio
data. data. The subtype names the specific audio format.
4.2.4. Video Media Types 4.2.4. Video Media Types
A media type of "video" indicates that the content specifies a time- A top-level type of "video" indicates that the content specifies a
varying-picture image, possibly with color and coordinated sound. time-varying-picture image, possibly with color and coordinated
The term 'video' is used in its most generic sense, rather than with sound. The term 'video' is used in its most generic sense, rather
reference to any particular technology or format, and is not meant to than with reference to any particular technology or format, and is
preclude subtypes such as animated drawings encoded compactly. not meant to preclude subtypes such as animated drawings encoded
compactly.
Note that although in general this document strongly discourages the Note that although in general the mixing of multiple kinds media in a
mixing of multiple media in a single body, it is recognized that many single body is discouraged [RFC2046], it is recognized that many
so-called video formats include a representation for synchronized video formats include a representation for synchronized audio and/or
audio and/or text, and this is explicitly permitted for subtypes of text, and this is explicitly permitted for subtypes of "video".
"video".
4.2.5. Application Media Types 4.2.5. Application Media Types
The "application" media type is to be used for discrete data that do The "application" top-level type is to be used for discrete data that
not fit in any of the media types, and particularly for data to be do not fit under any of the other type names, and particularly for
processed by some type of application program. This is information data to be processed by some type of application program. This is
that must be processed by an application before it is viewable or information that must be processed by an application before it is
usable by a user. Expected uses for the "application" media type viewable or usable by a user. Expected uses for the "application"
include but are not limited to file transfer, spreadsheets, type name include but are not limited to file transfer, spreadsheets,
presentations, scheduling data, and languages for "active" presentations, scheduling data, and languages for "active"
(computational) material. (The last, in particular, can pose (computational) material. (The last, in particular, can pose
security problems that must be understood by implementors, and that security problems that must be understood by implementors The
are considered in detail in the discussion of the "application/ "application/postscript" media type registration in [RFC2046]
postscript" media type in [RFC2046].) provides a good example of how to handle these issues.)
For example, a meeting scheduler might define a standard For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates. An representation for information about proposed meeting dates. An
intelligent user agent would use this information to conduct a dialog intelligent user agent would use this information to conduct a dialog
with the user, and might then send additional material based on that with the user, and might then send additional material based on that
dialog. More generally, there have been several "active" languages dialog. More generally, there have been several "active" languages
developed in which programs in a suitably specialized language are developed in which programs in a suitably specialized language are
transported to a remote location and automatically run in the transported to a remote location and automatically run in the
recipient's environment. Such applications may be defined as recipient's environment. Such applications may be defined as
subtypes of the "application" media type. subtypes of the "application" top-level type.
The subtype of "application" will often either be the name or include The subtype of "application" will often either be the name or include
part of the name of the application for which the data are intended. part of the name of the application for which the data are intended.
This does not mean, however, that any application program name may This does not mean, however, that any application program name may
simply be used freely as a subtype of "application"; the subtype simply be used freely as a subtype of "application"; the subtype
needs to be registered. needs to be registered.
4.2.6. Multipart and Message Media Types 4.2.6. Multipart and Message Media Types
Multipart and message are composite types, that is, they provide a Multipart and message are composite types, that is, they provide a
means of encapsulating zero or more objects, each labeled with its means of encapsulating zero or more objects, each one a separate
own media type. media type.
All subtypes of multipart and message MUST conform to the syntax All subtypes of multipart and message MUST conform to the syntax
rules and other requirements specified in [RFC2046] and amended by rules and other requirements specified in [RFC2046] and amended by
Section 3.5 of [RFC6532]. Section 3.5 of [RFC6532].
4.2.7. Additional Top-level Types 4.2.7. Additional Top-level Types
In some cases a new media type may not "fit" under any currently 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 defined top-level type names. Such cases are expected to be quite
rare. However, if such a case does arise a new top-level type can be rare. However, if such a case does arise a new type name can be
defined to accommodate it. Such a definition MUST be done via defined to accommodate it. Such a definition MUST be done via
standards-track RFC; no other mechanism can be used to define standards-track RFC; no other mechanism can be used to define
additional top-level content types. additional type name.
4.2.8. Structured Syntax Name Suffixes 4.2.8. Structured Syntax Name Suffixes
[RFC3023] defined the first such augmentation to the media type [RFC3023] defined the first such augmentation to the media type
definition to additionally specify the underlying structure of that definition to additionally specify the underlying structure of that
media type. To quote: media type. To quote:
This document also standardizes a convention (using the suffix This document also standardizes a convention (using the suffix
'+xml') for naming media types ... when those media types '+xml') for naming media types ... when those media types
represent XML MIME (Multipurpose Internet Mail Extensions) represent XML MIME (Multipurpose Internet Mail Extensions)
entities. entities.
That is, it specified a suffix (in that case, "+xml") to be appended That is, it specified a suffix (in that case, "+xml") to be appended
to the base media type name. to the base subtype name.
Since this was published, the de facto practice has arisen for using Since this was published, the de facto practice has arisen for using
this suffix convention for other well-known structuring syntaxes. In this suffix convention for other well-known structuring syntaxes. In
particular, media types have been registered with suffixes such as particular, media types have been registered with suffixes such as
"+der", "+fastinfoset" and "+json". This specification formalizes "+der", "+fastinfoset" and "+json". This specification formalizes
this practice and sets up a registry for structured type name this practice and sets up a registry for structured type name
suffixes. suffixes.
The primary guideline for whether a structured type name suffix The primary guideline for whether a structured type name suffix is
should be registrable is that it be described by a readily-available registrable is that it be described by a readily-available
description, preferably within a document published by an established description, preferably within a document published by an established
standards organization, and for which there's a reference that can be standards organization, and for which there's a reference that can be
used in a Normative References section of an RFC. used in a Normative References section of an RFC.
Media types that make use of a named structured syntax SHOULD use the Media types that make use of a named structured syntax SHOULD use the
appropriate registered "+suffix" for that structured syntax when they appropriate registered "+suffix" for that structured syntax when they
are registered. By the same token, media types MUST NOT be given are registered. By the same token, media types MUST NOT be given
names incorporating suffixes for structured syntaxes they do not names incorporating suffixes for structured syntaxes they do not
actually employ. "+suffix" constructs for as-yet unregistered actually employ. "+suffix" constructs for as-yet unregistered
structured syntaxes should be used with care, given the possibility structured syntaxes SHOULD NOT be used, given the possibility of
of conflicts with future suffix definitions. conflicts with future suffix definitions.
4.2.9. Deprecated Aliases 4.2.9. Deprecated Aliases
In some cases a single media type may have been widely deployed prior In some cases a single media type may have been widely deployed prior
to registration under multiple names. In such cases a preferred name to registration under multiple names. In such cases a preferred name
MUST be chosen for the media type and applications MUST use this to MUST be chosen for the media type and applications MUST use this to
be compliant with the type's registration. However, a list of be compliant with the type's registration. However, a list of
deprecated aliases the type is known by MAY be supplied as additional deprecated aliases the type is known by MAY be supplied as additional
information in order to assist applications in processing the media information in order to assist applications in processing the media
type properly. type properly.
skipping to change at page 14, line 5 skipping to change at page 14, line 12
Note that this syntax is somewhat more restrictive than what is Note that this syntax is somewhat more restrictive than what is
allowed by the ABNF in [RFC2045] and amended by [RFC2231]. allowed by the ABNF in [RFC2045] and amended by [RFC2231].
Parameter names are case-insensitive and no meaning is attached to Parameter names are case-insensitive and no meaning is attached to
the order in which they appear. It is an error for a specific the order in which they appear. It is an error for a specific
parameter to be specified more than once. parameter to be specified more than once.
There is no defined syntax for parameter values. Therefore There is no defined syntax for parameter values. Therefore
registrations MUST specify parameter value syntax. Additionally, registrations MUST specify parameter value syntax. Additionally,
some transports impose restrictions on parameter value syntax, so some transports impose restrictions on parameter value syntax, so
care should be taken to limit the use of potentially problematic care needs be taken to limit the use of potentially problematic
syntaxes; e.g., pure binary valued parameters, while permitted in syntaxes; e.g., pure binary valued parameters, while permitted in
some protocols, probably should be avoided. some protocols, are best avoided.
New parameters SHOULD NOT be defined as a way to introduce new New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does parameters MAY be added to convey additional information that does
not otherwise change existing functionality. An example of this not otherwise change existing functionality. An example of this
would be a "revision" parameter to indicate a revision level of an would be a "revision" parameter to indicate a revision level of an
external specification such as JPEG. Similar behavior is encouraged external specification such as JPEG. Similar behavior is encouraged
for media types registered in the vendor or personal trees, but is for media types registered in the vendor or personal trees, but is
not required. not required.
Changes to parameters (including the introduction of new ones) is
managed in the same manner as other changes to the media type; see
Section 5.6.
4.4. Canonicalization and Format Requirements 4.4. Canonicalization and Format Requirements
All registered media types MUST employ a single, canonical data All registered media types MUST employ a single, canonical data
format, regardless of registration tree. format, regardless of registration tree.
A permanent and readily available public specification of the format A permanent and readily available public specification of the format
for the media type MUST exist for all types registered in the for the media type MUST exist for all types registered in the
standards tree, and this specification MUST provide sufficient detail standards tree, and this specification MUST provide sufficient detail
so that interoperability between independent implementations using so that interoperability between independent implementations using
the media type is possible. This specification MUST at a minimum be the media type is possible. This specification MUST at a minimum be
skipping to change at page 15, line 47 skipping to change at page 16, line 8
There is absolutely no requirement that media types registered in any There is absolutely no requirement that media types registered in any
tree be secure or completely free from risks. Nevertheless, all tree be secure or completely free from risks. Nevertheless, all
known security risks MUST be identified in the registration of a known security risks MUST be identified in the registration of a
media type, again regardless of registration tree. media type, again regardless of registration tree.
The security considerations section of all registrations is subject The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular MAY be to continuing evaluation and modification, and in particular MAY be
extended by use of the "comments on media types" mechanism described extended by use of the "comments on media types" mechanism described
in Section 5.4 below. in Section 5.4 below.
Some of the issues that should be examined and described in a Some of the issues that need to be examined and described in a
security analysis of a media type are: security analysis of a media type are:
o Complex media types may include provisions for directives that o Complex media types may include provisions for directives that
institute actions on a recipient's files or other resources. In institute actions on a recipient's files or other resources. In
many cases provision is made for originators to specify arbitrary many cases provision is made for originators to specify arbitrary
actions in an unrestricted fashion that may then have devastating actions in an unrestricted fashion that may then have devastating
effects. See the registration of the application/postscript media effects. See the registration of the application/postscript media
type in [RFC2046] for an example of such directives and how they type in [RFC2046] for an example of such directives and how they
should be described in a media type registration. can be described in a media type registration.
o All registrations MUST state whether or not they employ such o Any security analysis MUST state whether or not they employ such
"active content", and if they do, they MUST state what steps have "active content", and if they do, they MUST state what steps have
been taken to protect users of the media type from harm. been taken to protect users of the media type from harm.
o Complex media types may include provisions for directives that o Complex media types may include provisions for directives that
institute actions that, while not directly harmful to the institute actions that, while not directly harmful to the
recipient, may result in disclosure of information that either recipient, may result in disclosure of information that either
facilitates a subsequent attack or else violates a recipient's facilitates a subsequent attack or else violates a recipient's
privacy in some way. Again, the registration of the application/ privacy in some way. Again, the registration of the application/
postscript media type illustrates how such directives can be postscript media type illustrates how such directives can be
handled. handled.
o A media type that employs compression may provide an opportunity o A media type that employs compression may provide an opportunity
for sending a small amount of data that, when received and for sending a small amount of data that, when received and
evaluated, expands enormously to consume all of the recipient's evaluated, expands enormously to consume all of the recipient's
resources. All media types SHOULD state whether or not they resources. All media types SHOULD state whether or not they
employ compression, and if they do they should discuss what steps employ compression, and if they do they SHOULD discuss what steps
need to be taken to avoid such attacks. need to be taken to avoid such attacks.
o A media type might be targeted for applications that require some o A media type might be targeted for applications that require some
sort of security assurance but not provide the necessary security sort of security assurance but not provide the necessary security
mechanisms themselves. For example, a media type could be defined mechanisms themselves. For example, a media type could be defined
for storage of sensitive medical information that in turn requires for storage of sensitive medical information that in turn requires
external confidentiality and integrity protection services, or external confidentiality and integrity protection services, or
which is designed for use only within a secure environment. Types which is designed for use only within a secure environment. Types
not requiring such services SHOULD document this in their security SHOULD always document whether or not they need such servies in
considerations. their security considerations.
4.7. Requirements specific to XML media types 4.7. Requirements specific to XML media types
There are a number of additional requirements specific to the There are a number of additional requirements specific to the
registration of XML media types. These requirements are specified in registration of XML media types. These requirements are specified in
[RFC3023]. [RFC3023].
4.8. Encoding Requirements 4.8. Encoding Requirements
Some transports impose restrictions on the type of data they can Some transports impose restrictions on the type of data they can
skipping to change at page 19, line 24 skipping to change at page 19, line 36
o File name extension(s) commonly used on one or more platforms to o File name extension(s) commonly used on one or more platforms to
indicate that some file contains a given media type. indicate that some file contains a given media type.
o Mac OS File Type code(s) (4 octets) used to label files containing o Mac OS File Type code(s) (4 octets) used to label files containing
a given media type. Some discussion of Macintosh file type codes a given media type. Some discussion of Macintosh file type codes
and their purpose can be found in [MacOSFileTypes]. and their purpose can be found in [MacOSFileTypes].
In the case of a registration in the standards tree, this additional In the case of a registration in the standards tree, this additional
information MAY be provided in the formal specification of the media information MAY be provided in the formal specification of the media
type. It is suggested that this be done by incorporating the IANA type format. It is suggested that this be done by incorporating the
media type registration form into the specification itself. IANA media type registration form into the format specification
itself.
5. Media Type Registration Procedures 5. Media Type Registration Procedures
The media type registration procedure is not a formal standards The media type registration procedure is not a formal standards
process, but rather an administrative procedure intended to allow process, but rather an administrative procedure intended to allow
community comment and sanity checking without excessive time delay. community comment and sanity checking without excessive time delay.
The normal IETF processes should be followed for all IETF Normal IETF processes need to be followed for all IETF registrations
registrations in the standards tree. The posting of an Internet in the standards tree. The posting of an Internet Draft is a
Draft is a necessary first step, followed by posting to the necessary first step, followed by posting to the media-types@iana.org
media-types@iana.org list as discussed below. list as discussed below.
5.1. Preliminary Community Review 5.1. Preliminary Community Review
Notice of a potential media type registration in the standards tree Notice of a potential media type registration in the standards tree
SHOULD be sent to the media-types@iana.org mailing list for review. SHOULD be sent to the media-types@iana.org mailing list for review.
This mailing list has been established for the purpose of reviewing This mailing list has been established for the purpose of reviewing
proposed media and access types. Registrations in other trees MAY be proposed media and access types. Registrations in other trees MAY be
sent to the list for review as well; doing so is entirely OPTIONAL, sent to the list for review as well; doing so is entirely OPTIONAL,
but is strongly encouraged. but is strongly encouraged.
skipping to change at page 20, line 11 skipping to change at page 20, line 26
the references with respect to versions and external profiling the references with respect to versions and external profiling
information, and a review of any interoperability or security information, and a review of any interoperability or security
considerations. The submitter may submit a revised registration considerations. The submitter may submit a revised registration
proposal or abandon the registration completely and at any time. proposal or abandon the registration completely and at any time.
5.2. Submit request to IANA 5.2. Submit request to IANA
Media types registered in the standards tree by the IETF itself MUST Media types registered in the standards tree by the IETF itself MUST
be reviewed and approved by the IESG as part of the normal standards be reviewed and approved by the IESG as part of the normal standards
process. Standards tree registrations by recognized standards bodies process. Standards tree registrations by recognized standards bodies
as well as registrations in the vendor and personal tree should be as well as registrations in the vendor and personal tree are
submitted directly to the IANA, unless other arrangements were made submitted directly to the IANA, unless other arrangements were made
as part of a liaison agreement. In either case posting the as part of a liaison agreement. In either case posting the
registration to the media-types@iana.org list for review prior to registration to the media-types@iana.org list for review prior to
submission is strongly encouraged. submission is strongly encouraged.
Registration requests can be sent to iana@iana.org. A web form for Registration requests can be sent to iana@iana.org. A web form for
registration requests is also available: registration requests is also available:
http://www.iana.org/cgi-bin/mediatypes.pl http://www.iana.org/cgi-bin/mediatypes.pl
skipping to change at page 21, line 44 skipping to change at page 22, line 14
5.6. Change Procedures 5.6. Change Procedures
Once a media type has been published by the IANA, the owner may Once a media type has been published by the IANA, the owner may
request a change to its definition. The descriptions of the request a change to its definition. The descriptions of the
different registration trees above designate the "owners" of each different registration trees above designate the "owners" of each
type of registration. The same procedure that would be appropriate type of registration. The same procedure that would be appropriate
for the original registration request is used to process a change for the original registration request is used to process a change
request. request.
Media type registrations may not be deleted; media types that are no
longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such media types will be
clearly marked in the lists published by the IANA.
Significant changes to a media type's definition should be requested Significant changes to a media type's definition should be requested
only when there are serious omissions or errors in the published only when there are serious omissions or errors in the published
specification. When review is required, a change request may be specification. When review is required, a change request may be
denied if it renders entities that were valid under the previous denied if it renders entities that were valid under the previous
definition invalid under the new definition. definition invalid under the new definition.
The owner of a media type may pass responsibility to another person The owner of a media type may pass responsibility to another person
or agency by informing the IANA; this can be done without discussion or agency by informing the IANA; this can be done without discussion
or review. or review.
The IESG may reassign responsibility for a media type. The most 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 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 where the author of the registration has died, moved out of contact
or is otherwise unable to make changes that are important to the or is otherwise unable to make changes that are important to the
community. 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.
5.7. Registration Template 5.7. Registration Template
Type name: Type name:
Subtype name: Subtype name:
Required parameters: Required parameters:
Optional parameters: Optional parameters:
skipping to change at page 29, line 18 skipping to change at page 29, line 18
Character Sets, Languages, and Continuations", RFC 2231, Character Sets, Languages, and Continuations", RFC 2231,
November 1997. November 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
Appendix A. Grandfathered Media Types Appendix A. Grandfathered Media Types
A number of media types with unfaceted names, registered prior to A number of media types with unfaceted subtype names, registered
1996, would, if registered under the guidelines in this document, be prior to 1996, would, if registered under the guidelines in this
given a faceted name and placed into either the vendor or personal document, be given a faceted name and placed into either the vendor
trees. Reregistration of those types to reflect the appropriate or personal trees. Reregistration of those types to reflect the
trees is encouraged but not required. Ownership and change control appropriate trees is encouraged but not required. Ownership and
principles outlined in this document apply to those types as if they change control principles outlined in this document apply to those
had been registered in the trees described above. types as if they had been registered in the trees described above.
From time to time there may also be cases where a media type with an From time to time there may also be cases where a media type with an
unfaceted name has been widely deployed without being registered. unfaceted subtype name has been widely deployed without being
(Note that this includes types with names beginning with the "x-" registered. (Note that this includes subtype names beginning with
prefix.) If possible such types SHOULD be reregistered with a proper the "x-" prefix.) If possible such media type SHOULD be reregistered
faceted name. However, if this is not possible the type can, subject with a proper faceted subtype name. However, if this is not possible
to approval by both the media types reviewer and the IESG, be the type can, subject to approval by both the media types reviewer
registered in the proper tree with its unfaceted name. and the IESG, be registered in the proper tree with its unfaceted
name.
Appendix B. Changes Since RFC 4288 Appendix B. Changes Since RFC 4288
o Suffixes to indicate the use of a particular structured syntax are o Suffixes to indicate the use of a particular structured syntax are
now fully specified and a suffix registration process has been now fully specified and a suffix registration process has been
defined. defined.
o Registration of widely deployed unregistered unfaceted type names o Registration of widely deployed unregistered unfaceted type names
in the vendor or personal trees is now allowed, subject to in the vendor or personal trees is now allowed, subject to
approval by the media types reviewer and the IESG. approval by the media types reviewer and the IESG.
 End of changes. 50 change blocks. 
99 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/