rfc9694v3.txt		rfc9694.txt
	skipping to change at line 322 ¶		skipping to change at line 322 ¶
	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]. It is in widespread		the First WWW conference in May 1994 [CHEMIME]. It is in 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, different types (in all cases,		or standardization are desired, different types (in all cases,
	properly registered) are strongly recommended. For example, 'x-		properly registered) are strongly recommended. As an example, 'x-
	scheme-handler/http' should be changed to something like		scheme-handler/http' should be changed to something like
	'application/scheme-handler; scheme=http'. The type 'inode/		'application/scheme-handler; scheme=http’. As another example, the
	directory' should be changed to 'multipart/inode-directory' or		type 'inode/directory' should be changed to 'multipart/inode-
	'application/inode-directory.		directory' or 'application/inode-directory.
	The document that previously defined the requirements for new top-		The document that previously defined the requirements for new top-
	level media types was RFC 6838 [RFC6838]. Of particular relevance to		level media types was RFC 6838 [RFC6838]. Of particular relevance to
	the work in the current document are Sections 4.2.5 (Application		the work in the current document are Sections 4.2.5 (Application
	Media Types) and 4.2.7 (Additional Top-Level Types) of [RFC6838].		Media Types) and 4.2.7 (Additional Top-Level Types) of [RFC6838].
	These two sections are not strictly aligned, because the first says		These two sections are not strictly aligned, because the first says
	that anything that doesn't go under a more specific type can go under		that anything that doesn't go under a more specific type can go under
	the 'application' top-level type, while the later section allows for		the 'application' top-level type, while the later section allows for
	new top-level types.		new top-level types.
	skipping to change at line 367 ¶		skipping to change at line 367 ¶
	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).
	4.2. Initialization of the Registry of Top-Level Media Types		4.2. Initialization of the Registry of Top-Level Media Types
	IANA has created the "Top-Level Media Types"		IANA has created the "Top-Level Media Types"
	(https://www.iana.org/assignments/top-level-media-types) registry and		(https://www.iana.org/assignments/top-level-media-types) registry and
	populated it with the values in Table 1. IANA also added a pointer		populated it with the values in Table 1. IANA also added a pointer
	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, and
			they added pointers to this document and to the "Top-Level Media
			Types" registry in the application for a media type at
			<https://www.iana.org/form/media-types>.
	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 | |
	skipping to change at line 415 ¶		skipping to change at line 418 ¶
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| text | [RFC2046] | [Text Media | requires CRLF for |		| text | [RFC2046] | [Text Media | requires CRLF for |
	| | | Types] | newlines |		| | | Types] | newlines |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	| video | [RFC2046] | [Video Media | - |		| video | [RFC2046] | [Video Media | - |
	| | | Types] | |		| | | Types] | |
	+-------------+--------------+--------------+-------------------+		+-------------+--------------+--------------+-------------------+
	Table 1: Initial Values for the Registry of Top-level Media Types		Table 1: Initial Values for the Registry of Top-level Media Types
	IANA has also added pointers to this document and to the "Top-Level
	Media Types" registry in the application for a media type at
	<https://www.iana.org/form/media-types>.
	5. Security Considerations		5. Security Considerations
	This document itself is not expected to introduce any security		This document itself is not expected to introduce any security
	issues. The security issues related to introducing a new top-level		issues. The security issues related to introducing a new top-level
	media type MUST be evaluated and documented carefully.		media type MUST be evaluated and documented carefully.
	Acknowledgements		Acknowledgements
	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
	skipping to change at line 524 ¶		skipping to change at line 523 ¶
	"Deprecating the "X-" Prefix and Similar Constructs in		"Deprecating the "X-" Prefix and Similar Constructs in
	Application Protocols", BCP 178, RFC 6648,		Application Protocols", BCP 178, RFC 6648,
	DOI 10.17487/RFC6648, June 2012,		DOI 10.17487/RFC6648, June 2012,
	<https://www.rfc-editor.org/info/rfc6648>.		<https://www.rfc-editor.org/info/rfc6648>.
	[RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,		[RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
	DOI 10.17487/RFC8081, February 2017,		DOI 10.17487/RFC8081, February 2017,
	<https://www.rfc-editor.org/info/rfc8081>.		<https://www.rfc-editor.org/info/rfc8081>.
	[RFC9695] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-level		[RFC9695] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-level
	Media Type", RFC 9695, DOI 10.17487/RFC9695, December		Media Type", RFC 9695, DOI 10.17487/RFC9695, March 2025,
	2024, <https://www.rfc-editor.org/info/rfc9695>.		<https://www.rfc-editor.org/info/rfc9695>.
	Author's Address		Author's Address
	Martin J. Dürst		Martin J. Dürst
	Aoyama Gakuin University		Aoyama Gakuin University
	Fuchinobe 5-10-1, Chuo-ku, Sagamihara, Kanagawa		Fuchinobe 5-10-1, Chuo-ku, Sagamihara, Kanagawa
	252-5258		252-5258
	Japan		Japan
	Phone: +81 42 759 6329		Phone: +81 42 759 6329
	Email: duerst@it.aoyama.ac.jp		Email: duerst@it.aoyama.ac.jp
End of changes. 5 change blocks.
	11 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48.