< draft-ietf-appsawg-media-type-regs-08.txt		draft-ietf-appsawg-media-type-regs-09.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 17, 2012 T. Hansen		Expires: November 19, 2012 T. Hansen
	AT&T Laboratories		AT&T Laboratories
	May 16, 2012		May 18, 2012
	Media Type Specifications and Registration Procedures		Media Type Specifications and Registration Procedures
	draft-ietf-appsawg-media-type-regs-08		draft-ietf-appsawg-media-type-regs-09
	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 17, 2012.		This Internet-Draft will expire on November 19, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4		1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Conventions Used in This Document . . . . . . . . . . . . 4		1.2. Conventions Used in This Document . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . . 9		4.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 10		4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 10
	4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 11		4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 11
	4.2.3. Audio Media Types . . . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . . 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 . . . . . . . . . 17
	4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 17		4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 17
	4.9. Usage and Implementation Non-requirements . . . . . . . . 17		4.9. Usage and Implementation Non-requirements . . . . . . . . 18
	4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18		4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
	4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 19		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 . . . . . . . . . . . . . . 20
	5.1. Preliminary Community Review . . . . . . . . . . . . . . . 20		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 . . . . . . . . . . . . . . . . . . . 21		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. Change Procedures . . . . . . . . . . . . . . . . . . . . 22
	5.6. Change Procedures . . . . . . . . . . . . . . . . . . . . 22		5.6. 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
	Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 29		Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 29
	Appendix B. Changes Since RFC 4288 . . . . . . . . . . . . . . . 29		Appendix B. Changes Since RFC 4288 . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		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.
	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
	reasonably orderly, well-specified, and public manner.
	This document defines media type specification and registration		The mechanism used to label such content is a media type, consisting
	procedures (Section 5) that use the Internet Assigned Numbers		of a top-level type and a subtype, which is further structured into
	Authority (IANA) as a central registry.		trees. Optionally, media types can define companion data, known as
			parameters.
			A registration process is needed for these labels, so that that the
			set of such values are defined in a reasonably orderly, well-
			specified, and public manner.
			This document specifies the criteria for media type registrations and
			defines the procedures to be used to register media types (Section 5)
			as well as media type structured suffixes (Section 6) in the Internet
			Assigned Numbers Authority (IANA) central registry.
			The location of the media type registry managed by these procedures
			is:
			http://www.iana.org/assignments/media-types/
	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 45 ¶		skipping to change at page 5, line 10 ¶
	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] when they		document are to be interpreted as described in [RFC2119] when they
	appear in ALL CAPS. These words may also appear in this document in		appear in ALL CAPS. They may also appear in lower or mixed case as
	lower case as plain English words, absent their normative meanings.		plain English words, without any normative meaning.
	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
	skipping to change at page 5, line 46 ¶		skipping to change at page 6, line 12 ¶
	1. in the case of registrations in IETF specifications, approved		1. in the case of registrations in IETF specifications, approved
	directly by the IESG, or		directly by the IESG, or
	2. registered by a recognized standards body using the		2. registered by a recognized standards body using the
	"Specification Required" IANA registration policy [RFC5226]		"Specification Required" IANA registration policy [RFC5226]
	(which implies Expert Review).		(which implies Expert Review).
	The first procedure is used for registering registrations from IETF		The first procedure is used for registering registrations from IETF
	Consensus documents, or in rare cases when registering a		Consensus documents, or in rare cases when registering a
	grandfathered (see Appendix A) and/or otherwise incomplete		grandfathered (see Appendix A) and/or otherwise incomplete
	registration is in the interest of the Internet community.		registration is in the interest of the Internet community. The
			registration 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 Track, a BCP, Informational, or Experimental.
			Registrations published in non-IETF RFC streams are also allowed, and
			require IESG approval. A registration can be either in a standalone
			"registration only" RFC or incorporated into a more general
			specification of some sort.
	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. The format MUST be described by a formal standards
			specification produced by the submitting standards body.
	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
	stream it is an IETF Consensus RFC [RFC4844] , which can be on the
	Standards Track, a BCP, Informational, or Experimental.
	Registrations published in non-IETF RFC streams are also allowed, and
	require IESG approval.
	In the case of registrations for other recognized standards bodies,
	the format MUST be described by a formal standards specification
	produced by that body.
	A standards-tree registration can be either in a standalone
	"registration only" RFC or incorporated into a more general
	specification of some sort.
	Media types in the standards tree MUST NOT have faceted names, unless		Media types in the standards tree MUST NOT have faceted names, unless
	they are grandfathered in using the process described in Appendix A.		they are grandfathered in using the process described in Appendix A.
	The "owner" of a media type registered 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.
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 11 ¶
	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 a registration done by a third party in order to		assert ownership of a registration done by a third party in order to
	correct or update it. See Section 5.6 for additional information.		correct or update it. See Section 5.5 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
	entities 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
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 46 ¶
	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 type names. 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 type name 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 type name.		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		XML in MIME [RFC3023] defined the first such augmentation to the
	definition to additionally specify the underlying structure of that		media type definition to additionally specify the underlying
	media type. To quote:		structure of that 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 subtype 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
	skipping to change at page 14, line 27 ¶		skipping to change at page 14, line 35 ¶
	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		Changes to parameters (including the introduction of new ones) is
	managed in the same manner as other changes to the media type; see		managed in the same manner as other changes to the media type; see
	Section 5.6.		Section 5.5.
	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
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 17 ¶
	time in the IETF, recommending implementation of, and support for,		time in the IETF, recommending implementation of, and support for,
	media types that have proven particularly useful in those contexts.		media types that have proven particularly useful in those contexts.
	As discussed above, registration of a top-level type requires		As discussed above, registration of a top-level type requires
	Standards Action in the IETF and, hence, the publication of a RFC on		Standards Action in the IETF and, hence, the publication of a RFC on
	the Standards Track.		the Standards Track.
	4.11. Fragment Identifier Requirements		4.11. Fragment Identifier Requirements
	Media type registrations can specify how applications should		Media type registrations can specify how applications should
	interpret fragment identifiers [RFC3986] associated with the media		interpret fragment identifiers (specified in section 3.5 of
	type.		[RFC3986]) associated with the media type.
	Media types are encouraged to adopt fragment identifier schemes that		Media types are encouraged to adopt fragment identifier schemes that
	are used with semantically similar media types. In particular, media		are used with semantically similar media types. In particular, media
	types that use a named structured syntax with a registered "+suffix"		types that use a named structured syntax with a registered "+suffix"
	MUST follow whatever fragment identifier rules are given in the		MUST follow whatever fragment identifier rules are given in the
	structured syntax suffix registration.		structured syntax suffix registration.
	4.12. Additional Information		4.12. Additional Information
	Various sorts of optional information SHOULD be included in the		Various sorts of optional information SHOULD be included in the
	skipping to change at page 21, line 40 ¶		skipping to change at page 21, line 51 ¶
	Recognition from the IESG MUST be obtained before a standards tree		Recognition from the IESG MUST be obtained before a standards tree
	registration can proceed.		registration can proceed.
	5.4. Comments on Media Type Registrations		5.4. Comments on Media Type Registrations
	Comments on registered media types may be submitted by members of the		Comments on registered media types may be submitted by members of the
	community to the IANA at iana@iana.org. These comments will be		community to the IANA at iana@iana.org. These comments will be
	reviewed by the media types reviewer and then passed on to the		reviewed by the media types reviewer and then passed on to the
	"owner" of the media type if possible. Submitters of comments may		"owner" of the media type if possible. Submitters of comments may
	request that their comment be attached to the media type registration		request that their comment be attached to the media type registration
	itself, and if the IANA approves of this, the comment will be made		itself, and if the IANA, in consultation with the media types
	accessible in conjunction with the type registration.		reviewer, approves, the comment will be made accessible in
			conjunction with the type registration.
	5.5. Location of Registered Media Type List
	Media type registrations are listed by the IANA at:
	http://www.iana.org/assignments/media-types/
	5.6. Change Procedures		5.5. 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		Media type registrations may not be deleted; media types that are no
	longer believed appropriate for use can be declared OBSOLETE by a		longer believed appropriate for use can be declared OBSOLETE by a
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	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.
	5.7. Registration Template		5.6. Registration Template
	Type name:		Type name:
	Subtype name:		Subtype name:
	Required parameters:		Required parameters:
	Optional parameters:		Optional parameters:
	Encoding considerations:		Encoding considerations:
	skipping to change at page 27, line 17 ¶		skipping to change at page 27, line 17 ¶
	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] [RFC4288]. We hope that the current version is one with		[RFC2048] [RFC4288]. We hope that the current version is one with
	which he would have agreed but, as it is impossible to verify that		which he would have agreed but, as it is impossible to verify that
	agreement, we have regretfully removed his name as a co-author.		agreement, we have regretfully removed his name as a co-author.
	Bjoern Hoehrmann, Barry Leiba, Murray Kucherawy, Alexey Melnikov, S.		Randy Bush, Bjoern Hoehrmann, Barry Leiba, Murray Kucherawy, Alexey
	Moonesamy, Peter Saint-Andre, and Jeni Tennison provided many helpful		Melnikov, S. Moonesamy, Mark Nottingham, Tom Petch, Peter Saint-
	review comments and suggestions.		Andre, and Jeni Tennison provided many helpful review comments and
			suggestions.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.appsawg-media-type-suffix-regs]		[I-D.appsawg-media-type-suffix-regs]
	Hansen, T., "Additional Media Type Structured Syntax		Hansen, T., "Additional Media Type Structured Syntax
	Suffixes", draft-appsawg-media-type-suffix-regs-00 (work		Suffixes", draft-appsawg-media-type-suffix-regs-00 (work
	in progress), April 2012.		in progress), April 2012.
	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 subtype names, registered		A number of media types with unfaceted subtype names, registered
	prior to 1996, would, if registered under the guidelines in this		prior to 1996, would, if registered under the guidelines in this
	document, be given a faceted name and placed into either the vendor		document, be given a faceted name and placed into either the vendor
	or personal trees. Reregistration of those types to reflect the		or personal trees. Reregistration of those types to reflect the
	appropriate trees is encouraged but not required. Ownership and		appropriate trees is encouraged but not required. Ownership and
	change control principles outlined in this document apply to those		change control principles outlined in this document apply to those
	types as if they had been registered in the trees described above.		types as if they had been registered in the trees described above.
End of changes. 25 change blocks.
	61 lines changed or deleted		59 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/