< draft-ietf-appsawg-media-type-regs-09.txt		draft-ietf-appsawg-media-type-regs-10.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 19, 2012 T. Hansen		Expires: November 25, 2012 T. Hansen
	AT&T Laboratories		AT&T Laboratories
	May 18, 2012		May 24, 2012
	Media Type Specifications and Registration Procedures		Media Type Specifications and Registration Procedures
	draft-ietf-appsawg-media-type-regs-09		draft-ietf-appsawg-media-type-regs-10
	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 19, 2012.		This Internet-Draft will expire on November 25, 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 33 ¶		skipping to change at page 2, line 33 ¶
	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 . . . . . . . . . . . . . . . . . . 16
	4.7. Requirements specific to XML media types . . . . . . . . . 17		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 . . . . . . . . 18		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 . . . . . . . . . . . . . . 20		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 . . . . . . . . . . . . . . 21
	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 . . . . . . . . . . . 22
	5.5. Change Procedures . . . . . . . . . . . . . . . . . . . . 22		5.5. Change Procedures . . . . . . . . . . . . . . . . . . . . 22
	5.6. Registration Template . . . . . . . . . . . . . . . . . . 23		5.6. 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 . . . . . . . . . . . . . . . . . . 29
	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 . . . . . . . . . . . . . . . 30
	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.		capable of carrying arbitrary labeled content.
	The mechanism used to label such content is a media type, consisting		The mechanism used to label such content is a media type, consisting
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	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 needs 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, are best avoided.		some protocols, are best avoided.
			Note that a protocol can impose further restrictions on parameter
			value syntax, depending on how it chooses to represent parameters.
			Both MIME [RFC2045] [RFC2231] and HTTP [RFC2045] [RFC5987] allow
			binary parameters as well as parameter values expressed in a specific
			charset, but other protocols may be less flexible.
	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		Changes to parameters (including the introduction of new ones) is
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 40 ¶
	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
	can be described in a media type registration.		can be described in a media type registration.
	o Any security analysis 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, or MUST be taken by applications of the media type, 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
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 15 ¶
	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 provisional registration process is provided to		Accordingly, a provisional registration process is provided to
	support early assignment of media type names. A provisional		support early assignment of media type names in the standards tree.
	registration MAY be submitted to IANA for standards tree types. The		A provisional registration MAY be submitted to IANA for standards
	only required fields in such registrations are the media type name		tree types. The only required fields in such registrations are the
	and contact information (including the standards body name).		media type name and contact information (including the standards body
			name).
	Upon receipt of a provisional 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.		publicly visible provisional registration list.
	Provisional registrations MAY be updated or abandoned at any time.		Provisional registrations MAY be updated or abandoned at any time.
			When this happens the media type is no longer registered in any
			sense; it can subsequently be registered just like any other
			unassigned media type name.
	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
	IETF Applications Area Director(s), will review the registration to		IETF Applications Area Director(s), will review the registration to
	make sure it meets the requirements set forth in this document.		make sure it meets the requirements set forth in this document.
	Registrations that do not meet these requirements will be returned to		Registrations that do not meet these requirements will be returned to
	the submitter for revision.		the submitter for revision.
	skipping to change at page 26, line 13 ¶		skipping to change at page 26, line 13 ¶
	with other types or protocols.		with other types or protocols.
	Fragment identifier considerations		Fragment identifier considerations
	Generic processing of fragment identifiers for any type employing		Generic processing of fragment identifiers for any type employing
	this syntax should be described here.		this syntax should be described here.
	Security considerations		Security considerations
	Security considerations shared by media types employing this		Security considerations shared by media types employing this
	structured syntax must be specified here. The same requirements		structured syntax must be specified here. The same requirements
	for media type security considerations given in Section 4.6 apply		for media type security considerations given in Section 4.6 apply
	here, with the exception that option of not assessing the security		here, with the exception that the option of not assessing the
	considerations is not available for suffix registrations.		security considerations is not available for suffix registrations.
	Contact		Contact
	Person (including contact information) to contact for further		Person (including contact information) to contact for further
	information.		information.
	Author/Change controller.		Author/Change controller.
	Person (including contact information) authorized to change this		Person (including contact information) authorized to change this
	suffix registration.		suffix registration.
	7. Security Considerations		7. Security Considerations
	Security requirements for media type registrations are discussed in		Security requirements for both media type and media type suffx
	Section 4.6.		registrations are discussed in Section 4.6.
	8. IANA Considerations		8. IANA Considerations
	The purpose of this document is to define IANA registries for media		The purpose of this document is to define IANA registries for media
	types and structured syntax suffixes as well as the procedures for		types and structured syntax suffixes as well as the procedures for
	managing these registries. Additionally, this document requires IANA		managing these registries. Additionally, this document requires IANA
	to maintain a list of IESG-recognized standards bodies who are		to maintain a list of IESG-recognized standards bodies who are
	allowed to register types in the standards tree.		allowed to register types in the standards tree.
	This document also creates a new registry for structured syntax		The existing media type registry has been extended to include a
	names:		section for provisional registrations. Only standards tree
			registrations are allowed in the standards tree and only at the
			request of a standards body on the IESG-recognized standards body
			list. See Section 5.2.1 for additional information on provisional
			registrations.
			The structured syntax name suffix registry is to be created as
			follows:
	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 is specified in		o The initial content of the registry is specified in
	[I-D.appsawg-media-type-suffix-regs].		[I-D.appsawg-media-type-suffix-regs].
			Entries in both the media type and structured suffix registries will
			be annotated by IANA with both the original registration date as well
			as the date of the most recent update to the entry. Registions made
			prior to the implementations of this specification can be marked as
			"registered under RFC 4288 or earlier".
			Since registration entries can be updated mutiple times, IANA is also
			requested to maintain the history of changes to each registration in
			such a way that the state of the registration at any given time can
			be determined
	Finally, this document calls for the creation of a new email address,		Finally, this document calls for the creation of a new email address,
	media-types@iana.org, for the media type review list, which replaces		media-types@iana.org, for the media type review list, which replaces
	the ietf-types@iana.org address specified in RFC 4288.		the ietf-types@iana.org address specified in RFC 4288.
	ietf-types@iana.org should be retained as an alias.		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
	skipping to change at page 29, line 18 ¶		skipping to change at page 29, line 38 ¶
	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.
			[RFC5987] Reschke, J., "Character Set and Language Encoding for
			Hypertext Transfer Protocol (HTTP) Header Field
			Parameters", RFC 5987, August 2010.
	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.
	skipping to change at page 31, line 12 ¶		skipping to change at page 31, line 34 ¶
	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		o The ABNF for media type names has been further restricted to
	require that names begin with an alphanumeric character.		require that names begin with an alphanumeric character.
	o Mailing list review is no longer required prior to registration of		o Mailing list review is no longer required prior to registration of
	media types. Additionally, the address associated with the media		media types. Additionally, the address associated with the media
	type review mailing list has been changed to media-types@iana.org.		type review mailing list has been changed to media-types@iana.org.
			o The rules for text/* media types have been updated to reflect the
			changes specified in [I-D.ietf-appsawg-mime-default-charset].
	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. 21 change blocks.
	22 lines changed or deleted		57 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/