rfc9694v1.txt		rfc9694.txt
	Internet Engineering Task Force (IETF) M. Dürst		Internet Engineering Task Force (IETF) M.J. Dürst
	Request for Comments: 9694 Aoyama Gakuin University		Request for Comments: 9694 Aoyama Gakuin University
	BCP: 13 February 2025		BCP: 13 March 2025
	Updates: 6838		Updates: 6838
	Category: Best Current Practice		Category: Best Current Practice
	ISSN: 2070-1721		ISSN: 2070-1721
	Guidelines for the Definition of New Top-Level Media Types		Guidelines for the Definition of New Top-Level Media Types
	Abstract		Abstract
	This document defines best practices for defining new top-level media		This document defines best practices for defining new top-level media
	types. It also introduces a registry for top-level media types, and		types. It also introduces a registry for top-level media types, and
	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 185 ¶		skipping to change at line 185 ¶
	registering an initial slate of subtypes, and provide examples of		registering an initial slate of subtypes, and provide examples of
	what is considered a valid subtype for future subtype		what is considered a valid subtype for future subtype
	registrations.		registrations.
	* The registration and actual use of a certain number of subtypes		* The registration and actual use of a certain number of subtypes
	under the new top-level type should be expected. The existence of		under the new top-level type should be expected. The existence of
	a single subtype should not be enough; it should be clear that new		a single subtype should not be enough; it should be clear that new
	similar types may appear in the future. Otherwise, the creation		similar types may appear in the future. Otherwise, the creation
	of a new top-level type is most probably not justified.		of a new top-level type is most probably not justified.
	* The proposers of the new top-level type and the wider community		* The proposers of the new top-level type and the wider user
	should be willing to commit to emitting and consuming the new top-		community should be willing to commit to emitting and consuming
	level type in environments that they control.		the new top-level type in environments that they control.
	* Desirability for common parameters: The fact that a group of		* Desirability for common parameters: The fact that a group of
	(potential) types have (mostly) common parameters may be an		(potential) types have (mostly) common parameters may be an
	indication that they belong under a common new top-level type.		indication that they belong under a common new top-level type.
	* Top-level types can help humans with understanding and debugging.		* Top-level types can help humans with understanding and debugging.
	Therefore, evaluating how a new top-level type helps humans		Therefore, evaluating how a new top-level type helps humans
	understand types may be crucial. But as often with humans,		understand types may be crucial. But as often with humans,
	opinions may widely differ.		opinions may widely differ.
	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 273 ¶		skipping to change at line 273 ¶
	| This set of top-level names is intended to be substantially		| This set of top-level names is intended to be substantially
	| complete. It is expected that additions to the larger set of		| complete. It is expected that additions to the larger set of
	| supported types can generally be accomplished by the creation of		| supported types can generally be accomplished by the creation of
	| new subtypes of these initial types. In the future, more top-		| new subtypes of these initial types. In the future, more top-
	| level types may be defined only by an extension to this standard.		| level types may be defined only by an extension to this standard.
	| If another primary type is to be used for any reason, it must be		| If another primary type is to be used for any reason, it must be
	| given a name starting with "X-" to indicate its non-standard		| given a name starting with "X-" to indicate its non-standard
	| status and to avoid a potential conflict with a future official		| status and to avoid a potential conflict with a future official
	| name.		| name.
	The first time an additional top-level type was defined was in RFC		RFC 1437 [RFC1437] defined the first additional top-level type;
	1437 [RFC1437], but this was an April Fools RFC, purely for		however, it was not registered because RFC 1437 is an April Fools RFC
	entertainment purposes.		that was published purely for entertainment purposes.
	RFC 2046 [RFC2046] discouraged the use of "X-" for (new) top-level		RFC 2046 [RFC2046] discouraged the use of "X-" for (new) top-level
	types, with the following words:		types, with the following words:
	| In general, the use of "X-" top-level types is strongly		| In general, the use of "X-" top-level types is strongly
	| discouraged. Implementors should invent subtypes of the existing		| discouraged. Implementors should invent subtypes of the existing
	| types whenever possible. In many cases, a subtype of		| types whenever possible. In many cases, a subtype of
	| "application" will be more appropriate than a new top-level type.		| "application" will be more appropriate than a new top-level type.
	RFC 2048 [RFC2048], published at the same time as RFC 2046 [RFC2046],		RFC 2048 [RFC2048], published at the same time as RFC 2046 [RFC2046],
	skipping to change at line 306 ¶		skipping to change at line 306 ¶
	1997.		1997.
	RFC 4735 [RFC4735] introduced the 'example' top-level type for use in		RFC 4735 [RFC4735] introduced the 'example' top-level type for use in
	documentation examples.		documentation examples.
	The 'font' top-level type was defined in RFC 8081 [RFC8081], a work		The 'font' top-level type was defined in RFC 8081 [RFC8081], a work
	of the 'justfont' IETF WG, in 2017. This was formalizing the		of the 'justfont' IETF WG, in 2017. This was formalizing the
	widespread use of the unofficial 'font' top-level type that people		widespread use of the unofficial 'font' top-level type that people
	were using in preference to official, registered types.		were using in preference to official, registered types.
	There is ongoing work to define a new 'haptics' top-level media type		RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695
	in RFC 9695 [RFC9695].		and this document were developed in parallel, and RFC 9695 was used
			to cross-check the considerations and procedures defined in this
			document.
	Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format)		The "Chemical file format" Wikipedia page [CHEMICAL] reports the
	reports the unofficial use of a 'chemical' top-level type. This top-		unofficial use of a 'chemical' top-level type. This top-level type
	level type was proposed by Peter Murray-Rust and Henry Rzepa at a		was proposed by Peter Murray-Rust and Henry Rzepa at a workshop at
	workshop at the First WWW conference in May 1994 [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. As an 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'. As another example, the
	strongly recommended.		type 'inode/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 specifications have 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).
	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" registry and populated		IANA has created the "Top-Level Media Types" registry
	it with the values in Table 1. IANA also added a pointer to this		(https://www.iana.org/assignments/top-level-media-types) and
	registry from the "Media Types" registry group.		populated it with the values in Table 1. IANA also added a pointer
			to this registry from the "Media Types" registry group
			(https://www.iana.org/assignments/media-types), 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 |Registry of Subtypes |Comments |		| Name | Defining RFC | Registry of | Comments |
	| |RFC | | |		| | | Subtypes | |
	+===========+=========+==================================+==============+		+=============+==============+==============+===================+
	|application|[RFC2046]|[Application Media Types |- |		| application | [RFC2046] | [Application | - |
	| | |(https://www.iana.org/assignments/| |		| | | Media Types] | |
	| | |media-types/)] | |		+-------------+--------------+--------------+-------------------+
	+-----------+---------+----------------------------------+--------------+		| audio | [RFC2046] | [Audio Media | - |
	|audio |[RFC2046]|[Audio Media Types |- |		| | | Types] | |
	| | |(https://www.iana.org/assignments/| |		+-------------+--------------+--------------+-------------------+
	| | |media-types/)] | |		| example | [RFC4735] | [Example | no registrations, |
	+-----------+---------+----------------------------------+--------------+		| | | Media Types] | for examples only |
	|example |[RFC4735]|[Example Media Types] |no |		+-------------+--------------+--------------+-------------------+
	| | | |registrations,|		| font | [RFC8081] | [Font Media | - |
	| | | |for examples |		| | | Types] | |
	| | | |only |		+-------------+--------------+--------------+-------------------+
	+-----------+---------+----------------------------------+--------------+		| haptics | [RFC9695] | [Haptics | - |
	|font |[RFC8081]|[Font Media Types] |- |		| | | Media Types] | |
	+-----------+---------+----------------------------------+--------------+		+-------------+--------------+--------------+-------------------+
	|haptics |[RFC9695]|[Haptics Media Types] |- |		| image | [RFC2046] | [Image Media | - |
	| |[RFC9695]| | |		| | | Types] | |
	+-----------+---------+----------------------------------+--------------+		+-------------+--------------+--------------+-------------------+
	|image |[RFC2046]|[Image Media Types] |- |		| message | [RFC2046] | [Message | - |
	+-----------+---------+----------------------------------+--------------+		| | | Media Types] | |
	|message |[RFC2046]|[Message Media Types] |- |		+-------------+--------------+--------------+-------------------+
	+-----------+---------+----------------------------------+--------------+		| model | [RFC2077] | [Model Media | - |
	|model |[RFC2077]|[Model Media Types] |- |		| | | Types] | |
	+-----------+---------+----------------------------------+--------------+		+-------------+--------------+--------------+-------------------+
	|multipart |[RFC2046]|[Multipart Media Types] |- |		| multipart | [RFC2046] | [Multipart | - |
	+-----------+---------+----------------------------------+--------------+		| | | Media Types] | |
	|text |[RFC2046]|[Text Media Types] |requires CRLF |		+-------------+--------------+--------------+-------------------+
	| | | |for newlines |		| text | [RFC2046] | [Text Media | requires CRLF for |
	+-----------+---------+----------------------------------+--------------+		| | | Types] | newlines |
	|video |[RFC2046]|[Video Media Types] |- |		+-------------+--------------+--------------+-------------------+
	+-----------+---------+----------------------------------+--------------+		| video | [RFC2046] | [Video Media | - |
			| | | 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 as such 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
	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 459 ¶		skipping to change at line 465 ¶
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Informative References		Informative References
			[CHEMICAL] Wikipedia, "Chemical file format", 19 July 2024,
			<https://en.wikipedia.org/w/
			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>.
	skipping to change at line 507 ¶		skipping to change at line 522 ¶
	[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,		[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
	"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. 20 change blocks.
	81 lines changed or deleted		96 lines changed or added
This html diff was produced by rfcdiff 1.48.