rfc9694v2.txt		rfc9694.txt
	skipping to change at line 144 ¶		skipping to change at line 144 ¶
	* The IANA Considerations section of an RFC defining a new top-level		* The IANA Considerations section of an RFC defining a new top-level
	type MUST request that IANA add this new top-level type to the		type MUST request that IANA add this new top-level type to the
	registry of top-level types.		registry of top-level types.
	* The criteria for what types do and do not fall under the new top-		* The criteria for what types do and do not fall under the new top-
	level type MUST be defined clearly. Clear criteria are expected		level type MUST be defined clearly. Clear criteria are expected
	to help expert reviewers evaluate whether or not a subtype belongs		to help expert reviewers evaluate whether or not a subtype belongs
	below the new type, and whether the registration template for a		below the new type, and whether the registration template for a
	subtype contains the appropriate information. Criteria that		subtype contains the appropriate information. Criteria that
	cannot be defined clearly is a strong indication that whatever is		cannot be defined clearly are a strong indication that whatever is
	being talked about is not suitable as a top-level type.		being talked about is not suitable as a top-level type.
	* Any RFC defining a new top-level type MUST clearly document the		* Any RFC defining a new top-level type MUST clearly document the
	security considerations applying to all or a significant subset of		security considerations applying to all or a significant subset of
	subtypes.		subtypes.
	* At a minimum, one subtype MUST be described. A top-level type		* At a minimum, one subtype MUST be described. A top-level type
	without any subtypes serves no purpose. Please note that the		without any subtypes serves no purpose. Please note that the
	'example' top-level describes the subtype 'example'.		'example' top-level describes the subtype 'example'.
	skipping to change at line 229 ¶		skipping to change at line 229 ¶
	* A top-level type is not a pointer into another registration space		* A top-level type is not a pointer into another registration space
	that offers duplicate registrations for existing media types.		that offers duplicate registrations for existing media types.
	Example: a top-level type of 'oid', leading to types of the form		Example: a top-level type of 'oid', leading to types of the form
	oid/nnnnn, where nnn is an OID (Object Identifier) designating a		oid/nnnnn, where nnn is an OID (Object Identifier) designating a
	specific media format.		specific media format.
	* A top-level type MUST NOT be defined for the mapping of other		* A top-level type MUST NOT be defined for the mapping of other
	protocol elements to media types. For example, while there may be		protocol elements to media types. For example, while there may be
	some merit to a mapping from media types to URIs, e.g., in the		some merit to a mapping from media types to URIs, e.g., in the
	context of RDF (Resource Description Framework), there is very		context of RDF (Resource Description Framework) [RDF], there is
	limited merit in a reverse mapping, and even less merit in		very limited merit in a reverse mapping, and even less merit in
	creating a top-level type for such a mapping. The same applies to		creating a top-level type for such a mapping. The same applies to
	other protocol elements such as file extensions or URI schemes.		other protocol elements such as file extensions or URI schemes.
	If a mapping is needed, the recommended solution is to choose a		If a mapping is needed, the recommended solution is to choose a
	single type/subtype and put the additional information in an		single type/subtype and put the additional information in an
	appropriately named parameter. As an example, information on a		appropriately named parameter. As an example, information on a
	file extension '.dcat' can be encoded as 'application/octet-		file extension '.dcat' can be encoded as 'application/octet-
	string; filename=foo.dcat'.		string; filename=foo.dcat'.
	* Media types are not a general type system. A top-level type MUST		* Media types are not a general type system. A top-level type MUST
	NOT be defined if its main or only purpose is to map other type		NOT be defined if its main or only purpose is to map other type
	skipping to change at line 314 ¶		skipping to change at line 314 ¶
	were using in preference to official, registered types.		were using in preference to official, registered types.
	RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695		RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695
	and this document were developed in parallel, and RFC 9695 was used		and this document were developed in parallel, and RFC 9695 was used
	to cross-check the considerations and procedures defined in this		to cross-check the considerations and procedures defined in this
	document.		document.
	The "Chemical file format" Wikipedia page [CHEMICAL] reports the		The "Chemical file format" Wikipedia page [CHEMICAL] reports the
	unofficial use of a 'chemical' top-level type. This top-level type		unofficial use of a 'chemical' top-level type. This top-level type
	was proposed by Peter Murray-Rust and Henry Rzepa at a workshop at		was proposed by Peter Murray-Rust and Henry Rzepa at a workshop at
	the First WWW conference in May 1994 CHEMIME [CHEMIME]. It is in		the First WWW conference in May 1994 [CHEMIME]. It is in widespread
	widespread use but remains unregistered.		use but remains unregistered.
	Some Linux desktop logic uses what looks like a top-level type of 'x-		Some Linux desktop logic uses what looks like a top-level type of 'x-
	scheme-handler' to map URI schemes to applications. In addition, the		scheme-handler' to map URI schemes to applications. In addition, the
	type 'inode/directory' is used. However, this is a purely local,		type 'inode/directory' is used. However, this is a purely local,
	system-specific use, and is not intended for exchange. If exchange		system-specific use, and is not intended for exchange. If exchange
	or standardization are desired, a change from, for example, 'x-		or standardization are desired, different types (in all cases,
	scheme-handler/http' to something like 'application/scheme-handler;		properly registered) are strongly recommended. For example, 'x-
	scheme=http' or 'inode/directory' to 'multipart/inode-directory' or		scheme-handler/http' should be changed to something like
	'application/inode-directory (in all cases, properly registered) is		'application/scheme-handler; scheme=http'. The type 'inode/
	strongly recommended.		directory' should be changed to 'multipart/inode-directory' or
			'application/inode-directory.
	The document currently defining the requirements for new top-level		The document that previously defined the requirements for new top-
	media types is RFC 6838 [RFC6838]. Of particular relevance to the		level media types was RFC 6838 [RFC6838]. Of particular relevance to
	work in this document are Sections 4.2.5 (Application Media Types)		the work in the current document are Sections 4.2.5 (Application
	and 4.2.7 (Additional Top-Level Types) of [RFC6838]. These two		Media Types) and 4.2.7 (Additional Top-Level Types) of [RFC6838].
	sections are not strictly aligned, because the first says that		These two sections are not strictly aligned, because the first says
	anything that doesn't go under a more specific type can go under the		that anything that doesn't go under a more specific type can go under
	'application' top-level type, while the later section allows for new		the 'application' top-level type, while the later section allows for
	top-level types.		new top-level types.
	4. IANA Considerations		4. IANA Considerations
	4.1. Registration of Top-level Media Types		4.1. Registration of Top-level Media Types
	Registrations of new top-level types follow the "Standards Action"		Registrations of new top-level types follow the "Standards Action"
	policy (see Section 4.9 of RFC 8126 [RFC8126]).		policy (see Section 4.9 of RFC 8126 [RFC8126]).
	Registrations of new top-level types have to provide the name of the		Registrations of new top-level types have to provide the name of the
	top-level type, the defining specification (RFC, or the respective		top-level type, the defining specification (RFC, or the respective
	draft during the approval process), and, if applicable, some		draft during the approval process), and, if applicable, some
	comments. The defining specification has to contain an "IANA		comments. The defining specification has to contain an "IANA
	Considerations" section requesting addition to the registry of top-		Considerations" section requesting addition to the registry of top-
	level media types, and document security considerations for the top-		level media types, and has to document security considerations for
	level types they register.		the top-level type they register.
	The comments field is empty or contains short comments about the		The comments field is empty or contains short comments about the
	usage of the type. Comments can be added or updated by the experts		usage of the type. Comments can be added or updated by the experts
	for subtype registrations under the respective top-level type, and by		for subtype registrations under the respective top-level type, and by
	IANA itself.		IANA itself.
	There should be at least one subtype, except for registrations that		There should be at least one subtype, except for registrations that
	are for demonstration purposes only (e.g. the example top-level		are for demonstration purposes only (e.g. the example top-level
	type).		type).
	skipping to change at line 375 ¶		skipping to change at line 376 ¶
	to this registry from the "Media Types"		to this registry from the "Media Types"
	(https://www.iana.org/assignments/media-types) registry group.		(https://www.iana.org/assignments/media-types) registry group.
	For each top-level media type, the registry contains the name of the		For each top-level media type, the registry contains the name of the
	type, a pointer to the RFC defining the type, a pointer to IANA's		type, a pointer to the RFC defining the type, a pointer to IANA's
	registry of subtypes for that type, and a comment field.		registry of subtypes for that type, and a comment field.
	The initial state of the registry is as follows:		The initial state of the registry is as follows:
	+=============+==============+==============+===================+		+=============+==============+==============+===================+
	| name | Defining RFC | Registry of | Comments |		| Name | Defining RFC | Registry of | Comments |
	| | | Subtypes | |		| | | Subtypes | |
	+=============+==============+==============+===================+		+=============+==============+==============+===================+
	| application | [RFC2046] | [Application | - |		| application | [RFC2046] | [Application | - |
	| | | Media Types] | |		| | | Media Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| audio | [RFC2046] | [Audio Media | - |		| audio | [RFC2046] | [Audio Media | - |
	| | | Types] | |		| | | Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| example | [RFC4735] | [Example | no registrations, |		| example | [RFC4735] | [Example | no registrations, |
	| | | Media Types] | for examples only |		| | | Media Types] | for examples only |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| font | [RFC8081] | [Font Media | - |		| font | [RFC8081] | [Font Media | - |
	| | | Types] | |		| | | Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| haptics | [RFC9695] | [Haptics | - |		| haptics | [RFC9695] | [Haptics | - |
	| | [RFC9695] | Media Types] | |		| | | Media Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| image | [RFC2046] | [Image Media | - |		| image | [RFC2046] | [Image Media | - |
	| | | Types] | |		| | | Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| message | [RFC2046] | [Message | - |		| message | [RFC2046] | [Message | - |
	| | | Media Types] | |		| | | Media Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| model | [RFC2077] | [Model Media | - |		| model | [RFC2077] | [Model Media | - |
	| | | Types] | |		| | | Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	skipping to change at line 436 ¶		skipping to change at line 437 ¶
	Continuous encouragement for writing this document came from Harald		Continuous encouragement for writing this document came from Harald
	Alvestrand. Further encouragement was provided by Murray		Alvestrand. Further encouragement was provided by Murray
	S. Kucherawy. Both Harald and Murray also provided ideas for actual		S. Kucherawy. Both Harald and Murray also provided ideas for actual
	text. Without them, this memo would never have reached even the		text. Without them, this memo would never have reached even the
	first draft stage. Alexey Melnikov provided the difficult to find		first draft stage. Alexey Melnikov provided the difficult to find
	pointer to RFC 2077 [RFC2077] and examples for applications		pointer to RFC 2077 [RFC2077] and examples for applications
	dispatching on top-level types. Additional information and comments		dispatching on top-level types. Additional information and comments
	were received from Chris Lilley, Graham Kline, Henry S. Rzepa,		were received from Chris Lilley, Graham Kline, Henry S. Rzepa,
	Francesca Palombini, Zaheduzzaman Sarker, Amanda Baber, Paul Wouters,		Francesca Palombini, Zaheduzzaman Sarker, Amanda Baber, Paul Wouters,
	Roman Danyliw, John Scudder, Radia Perlman, Lars Eggert, and Antoine		Roman Danyliw, John Scudder, Radia Perlman, Lars Eggert, and Antoine
	Fressancourt. Inspiration for negative criteria or examples were		Fressancourt. Inspiration for negative criteria or examples was
	provided by Phillip Hallam-Baker, Donald E. Eastlake 3rd, Petter		provided by Phillip Hallam-Baker, Donald E. Eastlake 3rd, Petter
	Reinholdtsen, and Christian Heller.		Reinholdtsen, and Christian Heller.
	References		References
	Normative References		Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	skipping to change at line 477 ¶		skipping to change at line 478 ¶
	index.php?title=Chemical_file_format&oldid=1235421631>.		index.php?title=Chemical_file_format&oldid=1235421631>.
	[CHEMIME] Rzepa, H.S., Murray-Rust, P., and B. Whitaker, "The		[CHEMIME] Rzepa, H.S., Murray-Rust, P., and B. Whitaker, "The
	Application of Chemical Multipurpose Internet Mail		Application of Chemical Multipurpose Internet Mail
	Extensions (Chemical MIME) Internet Standards to		Extensions (Chemical MIME) Internet Standards to
	Electronic Mail and World Wide Web Information Exchange",		Electronic Mail and World Wide Web Information Exchange",
	Journal of Chemical Information Computer Science, vol. 38,		Journal of Chemical Information Computer Science, vol. 38,
	no. 6, pp. 976-982, DOI 10.1021/ci9803233, 14 August 1998,		no. 6, pp. 976-982, DOI 10.1021/ci9803233, 14 August 1998,
	<https://pubs.acs.org/doi/10.1021/ci9803233>.		<https://pubs.acs.org/doi/10.1021/ci9803233>.
			[RDF] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
			Concepts and Abstract Syntax", W3C Recommendation, 25
			February 2014,
			<http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/>.
	[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet		[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
	Mail Extensions): Mechanisms for Specifying and Describing		Mail Extensions): Mechanisms for Specifying and Describing
	the Format of Internet Message Bodies", RFC 1341,		the Format of Internet Message Bodies", RFC 1341,
	DOI 10.17487/RFC1341, June 1992,		DOI 10.17487/RFC1341, June 1992,
	<https://www.rfc-editor.org/info/rfc1341>.		<https://www.rfc-editor.org/info/rfc1341>.
	[RFC1437] Borenstein, N. and M. Linimon, "The Extension of MIME		[RFC1437] Borenstein, N. and M. Linimon, "The Extension of MIME
	Content-Types to a New Medium", RFC 1437,		Content-Types to a New Medium", RFC 1437,
	DOI 10.17487/RFC1437, April 1993,		DOI 10.17487/RFC1437, April 1993,
	<https://www.rfc-editor.org/info/rfc1437>.		<https://www.rfc-editor.org/info/rfc1437>.
End of changes. 10 change blocks.
	23 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48.