< draft-ietf-appsawg-media-type-regs-04.txt   draft-ietf-appsawg-media-type-regs-05.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
Expires: October 3, 2012 Intended status: BCP
T. Hansen Expires: October 17, 2012 T. Hansen
AT&T Laboratories AT&T Laboratories
April 1, 2012 April 15, 2012
Media Type Specifications and Registration Procedures Media Type Specifications and Registration Procedures
draft-ietf-appsawg-media-type-regs-04 draft-ietf-appsawg-media-type-regs-05
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 October 3, 2012. This Internet-Draft will expire on October 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 20 skipping to change at page 2, line 20
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Media Type Registration Preliminaries . . . . . . . . . . . . 5 2. Media Type Registration Preliminaries . . . . . . . . . . . . 5
3. Registration Trees and Subtype Names . . . . . . . . . . . . . 5 3. Registration Trees and Subtype Names . . . . . . . . . . . . . 5
3.1. Standards Tree . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Standards Tree . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Personal or Vanity Tree . . . . . . . . . . . . . . . . . 7 3.3. Personal or Vanity Tree . . . . . . . . . . . . . . . . . 7
3.4. Unregistered x. Tree . . . . . . . . . . . . . . . . . . . 7 3.4. Unregistered x. Tree . . . . . . . . . . . . . . . . . . . 7
3.5. Additional Registration Trees . . . . . . . . . . . . . . 8 3.5. Additional Registration Trees . . . . . . . . . . . . . . 8
4. Registration Requirements . . . . . . . . . . . . . . . . . . 8 4. Registration Requirements . . . . . . . . . . . . . . . . . . 8
4.1. Functionality Requirement . . . . . . . . . . . . . . . . 8 4.1. Functionality Requirement . . . . . . . . . . . . . . . . 8
4.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 8 4.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 9
4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 9 4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 10
4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 10 4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 11
4.2.3. Audio Media Types . . . . . . . . . . . . . . . . . . 10 4.2.3. Audio Media Types . . . . . . . . . . . . . . . . . . 11
4.2.4. Video Media Types . . . . . . . . . . . . . . . . . . 11 4.2.4. Video Media Types . . . . . . . . . . . . . . . . . . 11
4.2.5. Application Media Types . . . . . . . . . . . . . . . 11 4.2.5. Application Media Types . . . . . . . . . . . . . . . 11
4.2.6. Multipart and Message Media Types . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 16
4.9. Usage and Implementation Non-requirements . . . . . . . . 17 4.9. Usage and Implementation Non-requirements . . . . . . . . 17
4.10. Publication Requirements . . . . . . . . . . . . . . . . . 17 4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
4.11. Additional Information . . . . . . . . . . . . . . . . . . 18 4.11. Additional Information . . . . . . . . . . . . . . . . . . 18
5. Media Type Registration Procedures . . . . . . . . . . . . . . 19 5. Media Type Registration Procedures . . . . . . . . . . . . . . 19
5.1. Preliminary Community Review . . . . . . . . . . . . . . . 19 5.1. Preliminary Community Review . . . . . . . . . . . . . . . 19
5.2. Submit request to IANA . . . . . . . . . . . . . . . . . . 19 5.2. Submit request to IANA . . . . . . . . . . . . . . . . . . 19
5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20 5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20
5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 20 5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . 21
5.7. Registration Template . . . . . . . . . . . . . . . . . . 22 5.7. Registration Template . . . . . . . . . . . . . . . . . . 23
6. Structured Syntax Suffix Registration Procedures . . . . . . . 23 6. Structured Syntax Suffix Registration Procedures . . . . . . . 24
6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 24 6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 25
6.2. Structured Syntax Suffix Registration Template . . . . . . 24 6.2. Structured Syntax Suffix Registration Template . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 28 Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 29
Appendix B. Changes Since RFC 4288 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 4288 . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
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.
skipping to change at page 7, line 4 skipping to change at page 7, line 4
broadly in this context and are considered equivalent. Note that broadly in this context and are considered equivalent. Note that
industry consortia as well as non-commercial entities that do not industry consortia as well as non-commercial entities that do not
qualify as recognized standards bodies can quite appropriately qualify as recognized standards bodies can quite appropriately
register media types in the vendor tree. register media types in the vendor tree.
A registration may be placed in the vendor tree by anyone who needs A registration may be placed in the vendor tree by anyone who needs
to interchange files associated with some product or set of products. to interchange files associated with some product or set of products.
However, the registration properly belongs to the vendor or However, the registration properly belongs to the vendor or
organization producing the software that employs the type being organization producing the software that employs the type being
registered, and that vendor or organization can at any time elect to registered, and that vendor or organization can at any time elect to
assert ownership of the registration. assert ownership of a registration done by a third party in order to
correct or update it. See Section 5.6 for additional information.
When a third party registers a type on behalf of someone else both When a third party registers a type on behalf of someone else both
entites SHOULD be noted in the Change Controller field in the entities SHOULD be noted in the Change Controller field in the
registration. One possible format for this would be "Foo, on behalf registration. One possible format for this would be "Foo, on behalf
of Bar". of Bar".
Registrations in the vendor tree will be distinguished by the leading Registrations in the vendor tree will be distinguished by the leading
facet "vnd.". That may be followed, at the discretion of the facet "vnd.". That may be followed, at the discretion of the
registrant, by either a media subtype name from a well-known producer registrant, by either a media subtype name from a well-known producer
(e.g., "vnd.mudpie") or by an IANA-approved designation of the (e.g., "vnd.mudpie") or by an IANA-approved designation of the
producer's name that is followed by a media type or product producer's name that is followed by a media type or product
designation (e.g., vnd.bigcompany.funnypictures). designation (e.g., vnd.bigcompany.funnypictures).
While public exposure and review of media types to be registered in While public exposure and review of media types to be registered in
the vendor tree is not required, using the ietf-types@iana.org the vendor tree is not required, using the media-types@iana.org
mailing list for review is encouraged to improve the quality of those mailing list for review is encouraged to improve the quality of those
specifications. Registrations in the vendor tree may be submitted specifications. Registrations in the vendor tree may be submitted
directly to the IANA, where they will undergo Expert Review [RFC5226] directly to the IANA, where they will undergo Expert Review [RFC5226]
prior to approval. prior to approval.
3.3. Personal or Vanity Tree 3.3. Personal or Vanity Tree
Registrations for media types created experimentally or as part of Registrations for media types created experimentally or as part of
products that are not distributed commercially may be registered in products that are not distributed commercially may be registered in
the personal or vanity tree. The registrations are distinguished by the personal or vanity tree. The registrations are distinguished by
the leading facet "prs.". the leading facet "prs.".
The owner of "personal" registrations and associated specifications The owner of "personal" registrations and associated specifications
is the person or entity making the registration, or one to whom is the person or entity making the registration, or one to whom
responsibility has been transferred as described below. responsibility has been transferred as described below.
While public exposure and review of media types to be registered in While public exposure and review of media types to be registered in
the personal tree is not required, using the ietf-types@iana.org the personal tree is not required, using the media-types@iana.org
mailing list (see Section 5.1) for review is encouraged to improve mailing list (see Section 5.1) for review is encouraged to improve
the quality of those specifications. Registrations in the personal the quality of those specifications. Registrations in the personal
tree may be submitted directly to the IANA, where they will undergo tree may be submitted directly to the IANA, where they will undergo
Expert Review [RFC5226] prior to approval. Expert Review [RFC5226] prior to approval.
3.4. Unregistered x. Tree 3.4. Unregistered x. Tree
Subtype names with "x." as the first facet may be used for types Subtype names with "x." as the first facet may be used for types
intended exclusively for use in private, local environments. Types intended exclusively for use in private, local environments. Types
in this tree cannot be registered and are intended for use only with in this tree cannot be registered and are intended for use only with
skipping to change at page 9, line 12 skipping to change at page 9, line 17
All registered media types MUST be assigned type and subtype names. All registered media types MUST be assigned type and subtype names.
The combination of these names serves to uniquely identify the media The combination of these names serves to uniquely identify the media
type, and the format of the subtype name identifies the registration type, and the format of the subtype name identifies the registration
tree. Both type and subtype names are case-insensitive. tree. Both 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 = 1*127restricted-name-chars restricted-name = restricted name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / restricted-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." / "#" / "$" / "&" / "." /
"+" / "-" / "^" / "_" "+" / "-" / "^" / "_"
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 section 5.1 of [RFC2045]. Also note that allowed by the ABNF in section 5.1 of [RFC2045] or section 4.2 of
while this syntax allows names of up to 127 characters, [RFC4288]. Also note that while this syntax allows names of up to
implementation limits may make such long names problematic. For this 127 characters, implementation limits may make such long names
reason the components of names SHOULD be limited to 64 characters. problematic. For this reason the components of names SHOULD be
limited to 64 characters.
Although the name syntax treates "+" as equivalent to any other Although the name syntax treats "+" as equivalent to any other
character, it is used in media type names to introduce a structured character, it is used in media type names to introduce a structured
syntax specificer 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 name MUST take into account the nature
skipping to change at page 10, line 8 skipping to change at page 10, line 17
The "text" media type is intended for sending material that is The "text" media 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].
A "charset" parameter SHOULD NOT be specified when charset As specified in [I-D.ietf-appsawg-mime-default-charset], a "charset"
information is transported inside the payload (e.g., as in "text/ parameter SHOULD NOT be specified when charset information is
xml"). transported inside the payload (e.g., as in "text/xml").
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.
skipping to change at page 12, line 33 skipping to change at page 12, line 44
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 media type name.
Since this was published, the defacto 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
should be registerable is that it be described by a readily-available should be 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 References section of an RFC. used in a 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 be used with care, given the possibility
of conflicts with future suffix definitions. of 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 registrion 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 application in processing the media information in order to assist application in processing the media
type properly. type properly.
4.3. Parameter Requirements 4.3. Parameter Requirements
Media types MAY elect to use one or more media type parameters, or Media types MAY elect to use one or more media type parameters, or
some parameters may be automatically made available to the media type some parameters may be automatically made available to the media type
skipping to change at page 14, line 20 skipping to change at page 14, line 30
A precise and openly available specification of the format of each A precise and openly available specification of the format of each
media type MUST exist for all types registered in the standards tree media type MUST exist for all types registered in the standards tree
and MUST at a minimum be referenced by, if it is not actually and MUST at a minimum be referenced by, if it is not actually
included in, the media type registration proposal itself. included in, the media type registration proposal itself.
The specifications of format and processing particulars may or may The specifications of format and processing particulars may or may
not be publicly available for media types registered in the vendor not be publicly available for media types registered in the vendor
and personal trees, and such registrations are explicitly permitted and personal trees, and such registrations are explicitly permitted
to limit the information in the registration to which software and to limit the information in the registration to which software and
version produce or process such media types. As such, teferences to version produce or process such media types. As such, references to
or inclusion of format specifications in registrations is encouraged or inclusion of format specifications in registrations is encouraged
but not required. Note, however, that the public availability of a but not required. Note, however, that the public availability of a
meaningful specification will often make the difference between meaningful specification will often make the difference between
simply having a name reserved so that there are no conflicts with simply having a name reserved so that there are no conflicts with
other uses and having the potential for other implementations of the other uses and having the potential for other implementations of the
media type and useful interoperation with them. media type and useful interoperation with them.
Some media types involve the use of patented technology. The Some media types involve the use of patented technology. The
registration of media types involving patented technology is registration of media types involving patented technology is
specifically permitted. However, the restrictions set forth in specifically permitted. However, the restrictions set forth in
skipping to change at page 19, line 15 skipping to change at page 19, line 26
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 The normal IETF processes should be followed for all IETF
registrations in the standards tree. The posting of an Internet registrations in the standards tree. The posting of an Internet
Draft is a necessary first step, followed by posting to the Draft is a necessary first step, followed by posting to the
ietf-types@iana.org list as discussed below. media-types@iana.org 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 ietf-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.
The intent of the public posting to this list is to solicit comments 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 and feedback on the choice of type/subtype name, the unambiguity of
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 should be
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 ietf-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
5.2.1. Provisional Registrations 5.2.1. Provisional Registrations
Standardization processes often take considerable time to complete. Standardization processes often take considerable time to complete.
In order to facilitate prototyping and testing it is often helpful to In order to facilitate prototyping and testing it is often helpful to
assign identifiers, including but not limited to media types, early assign identifiers, including but not limited to media types, early
in the process. This way identifiers used during standards in the process. This way identifiers used during standards
development can remain unchanged once the process is complete and development can remain unchanged once the process is complete and
implementations and documentation do not have to be updated. implementations and documentation do not have to be updated.
Accordingly, a provisonal registration process is provided to support Accordingly, a provisional registration process is provided to
early assigment of media type names. A provisional registration MAY support early assignment of media type names. A provisional
be submitted to IANA for standards tree types. The only required registration MAY be submitted to IANA for standards tree types. The
fields in such registrations are the media type name and contact only required fields in such registrations are the media type name
information (inckuding the standards body name). and contact information (including the standards body name).
Upon receipt of a provisionl registration, IANA will check the name Upon receipt of a provisional registration, IANA will check the name
and contact information, then publish the registration in a separate and contact information, then publish the registration in a separate
provisional registration list. provisional registration list.
Provisional registrations MAY be updated or abandoned at any time. Provisional registrations MAY be updated or abandoned at any time.
5.3. Review and Approval 5.3. Review and Approval
With the exception of provisional standards tree registrations, With the exception of provisional standards tree registrations,
registrations submitted to the IANA will be passed on to the media registrations submitted to the IANA will be passed on to the media
types reviewer. The media types reviewer, who is appointed by the types reviewer. The media types reviewer, who is appointed by the
skipping to change at page 23, line 32 skipping to change at page 24, line 32
template (specified in Section 6.2) and include that with the template (specified in Section 6.2) and include that with the
media type registration. The template may be contained in an media type registration. The template may be contained in an
Internet Draft, alone or as part of some other protocol Internet Draft, alone or as part of some other protocol
specification. The template may also be submitted in some other specification. The template may also be submitted in some other
form (as part of another document or as a stand-alone document), form (as part of another document or as a stand-alone document),
but the contents will be treated as an "IETF Contribution" under but the contents will be treated as an "IETF Contribution" under
the guidelines of RFC 5378 [RFC5378]. the guidelines of RFC 5378 [RFC5378].
3. Send a copy of the template or a pointer to the containing 3. Send a copy of the template or a pointer to the containing
document (with specific reference to the section with the document (with specific reference to the section with the
template) to the mailing list ietf-types@ietf.org, requesting template) to the mailing list media-types@iana.org, requesting
review. This may be combined with a request to review the media review. This may be combined with a request to review the media
type registration. Allow a reasonable time for discussion and type registration. Allow a reasonable time for discussion and
comments. comments.
4. Respond to review comments and make revisions to the proposed 4. Respond to review comments and make revisions to the proposed
registration as needed to bring it into line with the guidelines registration as needed to bring it into line with the guidelines
given in this document. given in this document.
5. Submit the (possibly updated) registration template (or pointer 5. Submit the (possibly updated) registration template (or pointer
to the document containing it) to IANA at iana@iana.org. to the document containing it) to IANA at iana@iana.org.
skipping to change at page 24, line 27 skipping to change at page 25, line 27
6.1. Change Procedures 6.1. Change Procedures
Registrations may be updated in each registry by the same mechanism Registrations may be updated in each registry by the same mechanism
as required for an initial registration. In cases where the original as required for an initial registration. In cases where the original
definition of the scheme is contained in an IESG-approved document, definition of the scheme is contained in an IESG-approved document,
update of the specification also requires IESG approval. update of the specification also requires IESG approval.
6.2. Structured Syntax Suffix Registration Template 6.2. Structured Syntax Suffix Registration Template
This template describes the fields that must be supplied in a This template describes the fields that must be supplied in a
structured syntax sufficx registration request: structured syntax suffix registration request:
Name Name
Full name of the well-defined structured syntax. Full name of the well-defined structured syntax.
+suffix +suffix
Suffix used to indicate conformance to the syntax. Suffix used to indicate conformance to the syntax.
References. References.
Include full citations for all specifications necessary to Include full citations for all specifications necessary to
understand the structured syntax. understand the structured syntax.
skipping to change at page 25, line 43 skipping to change at page 26, line 43
This document also creates a new registry for structured syntax This document also creates a new registry for structured syntax
names: names:
o The name is the "Structured Syntax Suffix" registry. o The name is the "Structured Syntax Suffix" registry.
o The registration process is specified in Section 6. o The registration process is specified in Section 6.
o The information required for a registry entry as well as the entry o The information required for a registry entry as well as the entry
format are specified in Section 6.2. format are specified in Section 6.2.
o The initial content of the registry shall be constructed at the o The initial content of the registry is specified in
time of the registry's creation by the designated media types [I-D.hansen-media-type-suffix-regs].
reviewer(s) by examining the current media types registry and
extracting all conforming uses of "+suffix" names. Finally, this document calls for the creation of a new email address,
media-types@iana.org, for the media type review list, which replaces
the ietf-types@iana.org address specified in RFC 4288.
ietf-types@iana.org should be retained as an alias.
9. Acknowledgements 9. Acknowledgements
The current authors would like to acknowledge their debt to the late The current authors would like to acknowledge their debt to the late
Dr. Jon Postel, whose general model of IANA registration procedures Dr. Jon Postel, whose general model of IANA registration procedures
and specific contributions shaped the predecessors of this document and specific contributions shaped the predecessors of this document
[RFC2048]. We hope that the current version is one with which he [RFC2048]. We hope that the current version is one with which he
would have agreed but, as it is impossible to verify that agreement, would have agreed but, as it is impossible to verify that agreement,
we have regretfully removed his name as a co-author. we have regretfully removed his name as a co-author.
Barry Leiba and Alexey Melnikov provided many helpful review comments Barry Leiba, Murray Kucherawy, Alexey Melnikov, and Peter Saint-Andre
and suggestions. provided many helpful review comments and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.hansen-media-type-suffix-regs]
Hansen, T., "Additional Media Type Structured Syntax
Suffixes", draft-hansen-media-type-suffix-regs-01 (work in
progress), April 2012.
[I-D.ietf-appsawg-mime-default-charset] [I-D.ietf-appsawg-mime-default-charset]
Melnikov, A. and J. Reschke, "Update to MIME regarding Melnikov, A. and J. Reschke, "Update to MIME regarding
Charset Parameter Handling in Textual Media Types", Charset Parameter Handling in Textual Media Types",
draft-ietf-appsawg-mime-default-charset-00 (work in draft-ietf-appsawg-mime-default-charset-01 (work in
progress), February 2012. progress), March 2012.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
skipping to change at page 27, line 31 skipping to change at page 28, line 33
to the IETF Trust", BCP 78, RFC 5378, November 2008. to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC6532] Yang, A., Steel, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steel, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, January 2012. Email Headers", RFC 6532, January 2012.
10.2. Informative References 10.2. Informative References
[I-D.ietf-appsawg-xdash] [I-D.ietf-appsawg-xdash]
Saint-Andre, P. and D. Crocker, "Deprecating the X- Prefix Saint-Andre, P. and D. Crocker, "Deprecating the X- Prefix
and Similar Constructs in Application Protocols", and Similar Constructs in Application Protocols",
draft-ietf-appsawg-xdash-04 (work in progress), draft-ietf-appsawg-xdash-05 (work in progress),
March 2012. April 2012.
[MacOSFileTypes] [MacOSFileTypes]
Apple Computer, Inc., "Mac OS: File Type and Creator Apple Computer, Inc., "Mac OS: File Type and Creator
Codes, and File Formats", Apple Knowledge Base Article Codes, and File Formats", Apple Knowledge Base Article
55381, June 1993, 55381, June 1993,
<http://www.info.apple.com/kbnum/n55381>. <http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996. Procedures", BCP 13, RFC 2048, November 1996.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Word Extensions:
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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
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 names, registered prior to
1996, would, if registered under the guidelines in this document, be 1996, would, if registered under the guidelines in this document, be
given a faceted name and placed into either the vendor or personal given a faceted name and placed into either the vendor or personal
trees. Reregistration of those types to reflect the appropriate trees. Reregistration of those types to reflect the appropriate
trees is encouraged but not required. Ownership and change control trees is encouraged but not required. Ownership and change control
principles outlined in this document apply to those types as if they principles outlined in this document apply to those types as if they
had been registered in the trees described above. had been registered in the trees described above.
skipping to change at page 29, line 5 skipping to change at page 30, line 11
have been changed to be the same as those for the vendor tree. have been changed to be the same as those for the vendor tree.
The text has been changed to encourage (but not require) The text has been changed to encourage (but not require)
specification availability. specification availability.
o The definition of additional trees has been clarified to state o The definition of additional trees has been clarified to state
that an IETF Standards Action is required. that an IETF Standards Action is required.
o Widely deployed types with "x-" names can now be registered as an o Widely deployed types with "x-" names can now be registered as an
exception in the vendor tree. exception in the vendor tree.
o The reqiremeents on changes to registrations have been loosened so o The requirements on changes to registrations have been loosened so
minor changes are easier to make. minor changes are easier to make.
o The registration process has been completely restructured so that o The registration process has been completely restructured so that
with the exception of IETF-generated types in the standards tree, with the exception of IETF-generated types in the standards tree,
all requests are procesed by IANA and not the IESG. all requests are processed by IANA and not the IESG.
o A provisional registration process has been added for early o A provisional registration process has been added for early
assignment of types in the standards tree. assignment of types in the standards tree.
o Many editorial changes have been made throughout the document to o Many editorial changes have been made throughout the document to
make the requirements and processes it describes clearer and make the requirements and processes it describes clearer and
easier to follow. easier to follow.
o The ability to specify a list of deprecated aliases has been o The ability to specify a list of deprecated aliases for a media
added. type has been added.
o Types with names beginning with "x-" are no longer considered to o Types with names beginning with "x-" are no longer considered to
be members of the unregistered "x." tree. As with any unfaceted be members of the unregistered "x." tree. As with any unfaceted
type, special procedures have been added to allow registration of type, special procedures have been added to allow registration of
such types in an appropriate tree. such types in an appropriate tree.
o Changes to a type registered by a third party may now be made by o Changes to a type registered by a third party may now be made by
the designated change controller even if that isn't the vendor or the designated change controller even if that isn't the vendor or
organization that created the type. However, the vendor or organization that created the type. However, the vendor or
orgnanization may elect to assert ownership and change controler organization may elect to assert ownership and change controller
over the type at any time. over the type at any time.
o Limited use media types are now asked to note whether or not the o Limited use media types are now asked to note whether or not the
supplied list of applications employing the media type is supplied list of applications employing the media type is
exhaustive. exhaustive.
o The ABNF for media type names has been further restricted to
require that names begin with an alphanumeric character.
o Mailing list review is no longer required prior to registration of
media types. Additionally, the address associated with the media
type review mailing list has been changed to media-types@iana.org.
Authors' Addresses Authors' Addresses
Ned Freed Ned Freed
Oracle Oracle
800 Royal Oaks 800 Royal Oaks
Monrovia, CA 91016-6347 Monrovia, CA 91016-6347
USA USA
Email: ned+ietf@mrochek.com Email: ned+ietf@mrochek.com
John C. Klensin John C. Klensin
1770 Massachusetts Ave, #322 1770 Massachusetts Ave, #322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Email: john+ietf@jck.com Email: john+ietf@jck.com
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
 End of changes. 43 change blocks. 
73 lines changed or deleted 95 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/