< draft-ietf-appsawg-media-type-regs-00.txt		draft-ietf-appsawg-media-type-regs-01.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: August 6, 2012		Expires: August 7, 2012
	T. Hansen		T. Hansen
	AT&T Laboratories		AT&T Laboratories
	February 3, 2012		February 4, 2012
	Media Type Specifications and Registration Procedures		Media Type Specifications and Registration Procedures
	draft-ietf-appsawg-media-type-regs-00		draft-ietf-appsawg-media-type-regs-01
	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 August 6, 2012.		This Internet-Draft will expire on August 7, 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 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 24		6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 24
	6.2. Structured Syntax Suffix Registration Template . . . . . . 24		6.2. Structured Syntax Suffix Registration Template . . . . . . 24
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 25		7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 26		10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	10.2. Informative References . . . . . . . . . . . . . . . . . . 27		10.2. Informative References . . . . . . . . . . . . . . . . . . 27
	Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 27		Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 27
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 27		Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 28
	Appendix C. Changes Since RFC 4288 . . . . . . . . . . . . . . . 28		Appendix C. Changes Since RFC 4288 . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	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
	skipping to change at page 18, line 34 ¶		skipping to change at page 18, line 34 ¶
	o Magic number(s) (length, octet values). Magic numbers are byte		o Magic number(s) (length, octet values). Magic numbers are byte
	sequences that are always present at a given place in the file and		sequences that are always present at a given place in the file and
	thus can be used to identify entities as being of a given media		thus can be used to identify entities as being of a given media
	type.		type.
	o File name extension(s) commonly used on one or more platforms to		o File name extension(s) commonly used on one or more platforms to
	indicate that some file contains a given media type.		indicate that some file contains a given media type.
	o Mac OS File Type code(s) (4 octets) used to label files containing		o Mac OS File Type code(s) (4 octets) used to label files containing
	a given media type.		a given media type. Some discussion of Macintosh file type codes
			and their purpose can be found in [MacOSFileTypes].
	o Information about how fragment/anchor identifiers [RFC3986] are		o Information about how fragment/anchor identifiers [RFC3986] are
	constructed for use in conjunction with this media type.		constructed for use in conjunction with this media type.
	In the case of a registration in the standards tree, this additional		In the case of a registration in the standards tree, this additional
	information MAY be provided in the formal specification of the media		information MAY be provided in the formal specification of the media
	type. It is suggested that this be done by incorporating the IANA		type. It is suggested that this be done by incorporating the IANA
	media type registration form into the specification itself.		media type registration form into the specification itself.
	5. Media Type Registration Procedures		5. Media Type Registration Procedures
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 9 ¶
	Provisional registration? (standards tree only):		Provisional registration? (standards tree only):
	(Any other information that the author deems interesting may be		(Any other information that the author deems interesting may be
	added below this line.)		added below this line.)
	"'N/A', written exactly that way, can be used in any field if desired		"'N/A', written exactly that way, can be used in any field if desired
	to emphasize the fact that it does not apply or that the question was		to emphasize the fact that it does not apply or that the question was
	not omitted by accident. Do not use 'none' or other words that could		not omitted by accident. Do not use 'none' or other words that could
	be mistaken for a response".		be mistaken for a response".
	Some discussion of Macintosh file type codes and their purpose can be
	found in [MacOSFileTypes].
	6. Structured Syntax Suffix Registration Procedures		6. Structured Syntax Suffix Registration Procedures
	Someone wishing to define a "+suffix" name for a structured syntax		Someone wishing to define a "+suffix" name for a structured syntax
	for use with a new media type registration SHOULD:		for use with a new media type registration SHOULD:
	1. Check IANA's registry of media type name suffixes to see whether		1. Check IANA's registry of media type name suffixes to see whether
	or not there is already an entry for that well-defined structured		or not there is already an entry for that well-defined structured
	syntax.		syntax.
	2. If there is no entry for their suffix scheme, fill out the		2. If there is no entry for their suffix scheme, fill out the
	skipping to change at page 25, line 33 ¶		skipping to change at page 25, line 28 ¶
	Section 4.6.		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
			names:
			o The name is the "Structured Syntax Suffix" registry.
			o The registration process is specified in Section 6.
			o The information required for a registry entry as well as the entry
			format are specified in Section 6.2.
			o The initial content of the registry shall be constructed at the
			time of the registry's creation by the designated media types
			reviewer(s) by examining the current media types registry and
			extracting all conforming uses of "+suffix" names.
	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 and Alexey Melnikov provided many helpful review comments
	skipping to change at page 28, line 4 ¶		skipping to change at page 28, line 11 ¶
	had been registered in the trees described above.		had been registered in the trees described above.
	From time to time there may also be cases where a media type with an		From time to time there may also be cases where a media type with an
	unfaceted name has been widely deployed without being registered. If		unfaceted name has been widely deployed without being registered. If
	possible such types SHOULD be reregistered with a proper faceted		possible such types SHOULD be reregistered with a proper faceted
	name. However, if this is not possible the type can, subject to		name. However, if this is not possible the type can, subject to
	approval by both the media types reviewer and the IESG, be registered		approval by both the media types reviewer and the IESG, be registered
	in the proper tree with its unfaceted name.		in the proper tree with its unfaceted name.
	Appendix B. Open Issues		Appendix B. Open Issues
	o The list of fields in the registration is getting long. Should		o The list of fields in the registration is getting long. Should
	the fields be numbered and referred to by number in order to		the fields be numbered and referred to by number in order to
	facilitate translation into other languages and similar		facilitate translation into other languages and similar
	activities?		activities?
	o Currently anyone can register a vendor media type on behalf of a		o Currently anyone can register a vendor media type on behalf of a
	vendor but subsequent to that only the vendor can make changes.		vendor but subsequent to that only the vendor can make changes.
	Do we want to retain this restriction?		Do we want to retain this restriction?
			o Should we add a field to the registration template where limited-
			use media types can provide an explicit list of the applications
			that employ that type?
	Appendix C. Changes Since RFC 4288		Appendix C. Changes Since RFC 4288
	o Suffixes to indicate the use of a particular structured syntax are		o Suffixes to indicate the use of a particular structured syntax are
	now fully specified and a suffix registration process has been		now fully specified and a suffix registration process has been
	defined.		defined.
	o Registration of widely deployed unregistered unfaceted type names		o Registration of widely deployed unregistered unfaceted type names
	in the vendor or personal trees is now allowed, subject to		in the vendor or personal trees is now allowed, subject to
	approval by the media types reviewer and the IESG.		approval by the media types reviewer and the IESG.
	skipping to change at page 29, line 26 ¶		skipping to change at page 29, line 39 ¶
	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: klensin+ietf@jck.com		Email: john+ietf@jck.com
	Tony Hansen		Tony Hansen
	AT&T Laboratories		AT&T Laboratories
	200 Laurel Ave.		200 Laurel Ave.
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Email: tony+mtsuffix@maillennium.att.com		Email: tony+mtsuffix@maillennium.att.com
End of changes. 11 change blocks.
	10 lines changed or deleted		28 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/