< draft-ietf-appsawg-media-type-regs-06.txt		draft-ietf-appsawg-media-type-regs-07.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: October 28, 2012 T. Hansen		Expires: November 5, 2012 T. Hansen
	AT&T Laboratories		AT&T Laboratories
	April 26, 2012		May 4, 2012
	Media Type Specifications and Registration Procedures		Media Type Specifications and Registration Procedures
	draft-ietf-appsawg-media-type-regs-06		draft-ietf-appsawg-media-type-regs-07
	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 28, 2012.		This Internet-Draft will expire on November 5, 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 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	registration is in the interest of the Internet community.		registration is in the interest of the Internet community.
	In the second case the IESG makes a one time decision on whether the		In the second case the IESG makes a one time decision on whether the
	registration submitter represents a recognized standards body; after		registration submitter represents a recognized standards body; after
	that, a Media Types Reviewer (Designated Expert or a group of		that, a Media Types Reviewer (Designated Expert or a group of
	Designated Experts) performs the Expert Review as specified in this		Designated Experts) performs the Expert Review as specified in this
	document. Subsequent submissions from the same source do not involve		document. Subsequent submissions from the same source do not involve
	the IESG.		the IESG.
	In the case of registration for the IETF itself, the registration		In the case of registration for the IETF itself, the registration
	proposal MUST be published as an IETF Consensus RFC, which can be on		proposal MUST be published as an RFC. When the RFC is in the IETF
	the Standards Track, a BCP, Informational, or Experimental. In the		stream it is an IETF Consensus RFC, which can be on the Standards
	case of registrations for other recognized standards bodies, the		Track, a BCP, Informational, or Experimental. Registrations
	format MUST be described by a formal standards specification produced		published in non-IETF RFC streams are also allowed, and require IESG
	by that body.		approval.
	Registrations published in non-IETF RFC streams are allowed and		In the case of registrations for other recognized standards bodies,
	require IESG approval.		the format MUST be described by a formal standards specification
			produced by that body.
	Standards-tree registration RFCs can either be standalone		A standards-tree registration can be either in a standalone
	"registration only" RFCs, or they can be incorporated into a more		"registration only" RFC or incorporated into a more general
	general specification of some sort.		specification of some sort.
	Media types in the standards tree are normally denoted by names that		Media types in the standards tree are normally denoted by names that
	are not explicitly faceted, i.e., do not contain period (".", full		are not explicitly faceted, i.e., do not contain period (".", full
	stop) characters.		stop) characters.
	The "owner" of a media type registration in the standards tree is		The "owner" of a media type registration 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)
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 40 ¶
	4. Registration Requirements		4. Registration Requirements
	Media type registrations are all expected to conform to various		Media type registrations are all expected to conform to various
	requirements laid out in the following sections. Note that		requirements laid out in the following sections. Note that
	requirement specifics sometimes vary depending on the registration		requirement specifics sometimes vary depending on the registration
	tree, again as detailed in the following sections.		tree, again as detailed in the following sections.
	4.1. Functionality Requirement		4.1. Functionality Requirement
	Media types MUST function as an actual media format. Registration of		Media types MUST function as actual media formats. Registration of
	things that are better thought of as a transfer encoding, as a		things that are better thought of as a transfer encoding, as a
	charset, or as a collection of separate entities of another type, is		charset, or as a collection of separate entities of another type, is
	not allowed. For example, although applications exist to decode the		not allowed. For example, although applications exist to decode the
	base64 transfer encoding [RFC2045], base64 cannot be registered as a		base64 transfer encoding [RFC2045], base64 cannot be registered as a
	media type.		media type.
	This requirement applies regardless of the registration tree		This requirement applies regardless of the registration tree
	involved.		involved.
	4.2. Naming Requirements		4.2. Naming Requirements
	All registered media types MUST be assigned type and subtype names.		All registered media types MUST be assigned 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 = restricted name-first *126restricted-name-chars		restricted-name = restricted-name-first *126restricted-name-chars
	restricted-name-first = ALPHA / DIGIT		restricted-name-first = ALPHA / DIGIT
	restricted-name-chars = ALPHA / DIGIT / "!" /		restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
	"#" / "$" / "&" / "." /		"$" / "&" / "-" / "^" / "_"
	"+" / "-" / "^" / "_"		restricted-name-chars =/ "." ; Characters before first dot always
			; specify a facet name
			restricted-name-chars =/ "+" ; Characters after last plus always
			; specify a structured syntax suffix
	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] or section 4.2 of		allowed by the ABNF in section 5.1 of [RFC2045] or section 4.2 of
	[RFC4288]. Also note that while this syntax allows names of up to		[RFC4288]. Also note that while this syntax allows names of up to
	127 characters, implementation limits may make such long names		127 characters, implementation limits may make such long names
	problematic. For this reason the components of names SHOULD be		problematic. For this reason the components of names SHOULD be
	limited to 64 characters.		limited to 64 characters.
	Although the name syntax treats "+" as equivalent to any other		Although the name syntax treats "." as equivalent to any other
	character, it is used in media type names to introduce a structured		character, characters before any initial "." always specify the
			registration facet. Note that this means that facet-less standards
			tree registrations cannot use periods in the subtype name.
			Similarly, "+" is used in media type names to introduce a structured
	syntax specifier suffix. Structured syntax suffix requirements are		syntax specifier suffix. Structured syntax suffix requirements are
	specified in Section 4.2.8.		specified in Section 4.2.8.
	While it is possible for a given media type to be assigned additional		While it is possible for a given media type to be assigned additional
	names, the use of different names to identify the same media type is		names, the use of different names to identify the same media type is
	discouraged.		discouraged.
	These requirements apply regardless of the registration tree		These requirements apply regardless of the registration tree
	involved.		involved.
	skipping to change at page 14, line 43 ¶		skipping to change at page 14, line 45 ¶
	version produce or process such media types. As such, references 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 BCP
	[RFC3979] and [RFC5378] on the use of patented technology in IETF		79 [RFC3979] and BCP 78 [RFC5378] on the use of patented technology
	standards-track protocols must be respected when the specification of		in IETF standards-track protocols must be respected when the
	a media type is part of a standards-track protocol. In addition,		specification of a media type is part of a standards-track protocol.
	other standards bodies making use of the standards tree may have		In addition, other standards bodies making use of the standards tree
	their own rules regarding intellectual property that must be observed		may have their own rules regarding intellectual property that must be
	in their registrations.		observed in their registrations.
	IPR disclosures for registrations in the vendor and personal tree are		IPR disclosures for registrations in the vendor and personal tree are
	encouraged but not required.		encouraged but not required.
	4.5. Interchange Recommendations		4.5. Interchange Recommendations
	Media types SHOULD interoperate across as many systems and		Media types SHOULD interoperate across as many systems and
	applications as possible. However, some media types will inevitably		applications as possible. However, some media types will inevitably
	have problems interoperating across different platforms. Problems		have problems interoperating across different platforms. Problems
	with different versions, byte ordering, and specifics of gateway		with different versions, byte ordering, and specifics of gateway
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 32 ¶
	for sending a small amount of data that, when received and		for sending a small amount of data that, when received and
	evaluated, expands enormously to consume all of the recipient's		evaluated, expands enormously to consume all of the recipient's
	resources. All media types SHOULD state whether or not they		resources. All media types SHOULD state whether or not they
	employ compression, and if they do they should discuss what steps		employ compression, and if they do they should discuss what steps
	need to be taken to avoid such attacks.		need to be taken to avoid such attacks.
	o A media type might be targeted for applications that require some		o A media type might be targeted for applications that require some
	sort of security assurance but not provide the necessary security		sort of security assurance but not provide the necessary security
	mechanisms themselves. For example, a media type could be defined		mechanisms themselves. For example, a media type could be defined
	for storage of sensitive medical information that in turn requires		for storage of sensitive medical information that in turn requires
	an external confidentiality and integrity protection services, or		external confidentiality and integrity protection services, or
	which is designed for use only within a secure environment. Types		which is designed for use only within a secure environment. Types
	not requiring such services SHOULD document this in their security		not requiring such services SHOULD document this in their security
	considerations.		considerations.
	4.7. Requirements specific to XML media types		4.7. Requirements specific to XML media types
	There are a number of additional requirements specific to the		There are a number of additional requirements specific to the
	registration of XML media types. These requirements are specified in		registration of XML media types. These requirements are specified in
	[RFC3023].		[RFC3023].
	skipping to change at page 24, line 28 ¶		skipping to change at page 24, line 28 ¶
	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
	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 BCP 78 [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 media-types@iana.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
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 5 ¶
	for media type encoding considerations given in Section 4.8 apply		for media type encoding considerations given in Section 4.8 apply
	here.		here.
	Interoperability considerations		Interoperability considerations
	Any issues regarding the interoperable use of types employing this		Any issues regarding the interoperable use of types employing this
	structured syntax should be given here. Examples would include		structured syntax should be given here. Examples would include
	the existence of incompatible versions of the syntax, issues		the existence of incompatible versions of the syntax, issues
	combining certain charsets with the syntax, or incompatibilities		combining certain charsets with the syntax, or incompatibilities
	with other types or protocols.		with other types or protocols.
	Fragment identifier considerations Generic processing of fragment		Fragment identifier considerations
	identifiers for any type employing this syntax should be described		Generic processing of fragment identifiers for any type employing
	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 option of not assessing the security
	considerations is not available for suffix registrations.		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
End of changes. 15 change blocks.
	36 lines changed or deleted		44 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/