rfc9720v1.txt		rfc9720.txt
	skipping to change at line 94 ¶		skipping to change at line 94 ¶
	The details described in this document are expected to continue to		The details described in this document are expected to continue to
	change over time as the community and the RFC Production Center (RPC)		change over time as the community and the RFC Production Center (RPC)
	gain further experience implementing the policies described here.		gain further experience implementing the policies described here.
	Implementors of these components are advised to avoid assuming that		Implementors of these components are advised to avoid assuming that
	all such changes will be backwards compatible.		all such changes will be backwards compatible.
	1.1. Changes to RFC 7990		1.1. Changes to RFC 7990
	[RFC7990] defined a framework for how RFCs would be published after		[RFC7990] defined a framework for how RFCs would be published,
	that document was published, including new formats and a new		including new "publication formats" and a new "canonical format". It
	"canonical format" for archiving RFCs. It talked about "the XML		talked about "the XML file" as if there would only be one XML file
	file" as if there would only be one XML file for an RFC because that		for an RFC because that was the expectation at the time [RFC7990] was
	was the expectation at the time [RFC7990] was published. It also		published. It also talked about "publication formats" as the
	talked about "publication formats" as the versions of HTML, text, and		versions of HTML, plain text, and PDF derived from the "canonical
	PDF derived from the "canonical format".		format".
	After extensive experience with publishing RFCs in the RFCXML format		After extensive experience with publishing RFCs in the RFCXML format
	[RFC7991], it has been decided that an RFC's XML file can be updated		[RFC7991], it has been decided that an RFC's XML file can be updated
	for narrowly limited purposes. This document changes [RFC7990] in		for narrowly limited purposes. This document changes [RFC7990] in
	significant ways:		significant ways:
	* It defines four terms that replace the use of the term "canonical"		* It defines four terms that replace the use of the term "canonical"
	and clarifies "format":		and clarifies "format":
	- The "definitive format", which is RFCXML		- The "definitive format", which is RFCXML
	- The "definitive version", which is a published RFC in the		- The "definitive version", which is a published RFC in the
	definitive format		definitive format
	- A "publication format", which is currently one of PDF, plain		- A "publication format", which is currently one of HTML, plain
	text, or HTML		text, and PDF
	- A "publication version", which is a published RFC in one of the		- A "publication version", which is a published RFC in one of the
	publication formats		publication formats
	* It defines a policy governing how the RFCXML format changes.		* It defines a policy governing how the RFCXML format changes.
	* It defines a policy for when the definitive version of an RFC can		* It defines a policy for when the definitive version of an RFC can
	be updated and older definitive versions archived.		be updated and older definitive versions archived.
	* It defines a policy for when the publication versions of an RFC		* It defines a policy for when the publication versions of an RFC
	skipping to change at line 153 ¶		skipping to change at line 153 ¶
	This document uses two terms, "definitive version" and "definitive		This document uses two terms, "definitive version" and "definitive
	format", for the earlier term "canonical format".		format", for the earlier term "canonical format".
	This document also makes the following terminology changes:		This document also makes the following terminology changes:
	* It changes the phrase "xml2rfc version 3" to "RFCXML".		* It changes the phrase "xml2rfc version 3" to "RFCXML".
	* It changes the name of the body that publishes RFCs from "RFC		* It changes the name of the body that publishes RFCs from "RFC
	Editor" to "RFC Production Center" (RPC).		Editor" to "RFC Production Center" (RPC).
	Historical text from [RFC7990], such as Sections 2 ("Problem		Historical text from [RFC7990], such as Section 2 ("Problem
	Statement"), 4 ("Overview of the Decision-Making Process"), and 10		Statement"), Section 4 ("Overview of the Decision-Making Process"),
	("Transition Plan"), was purposely omitted from this document. Text		and Section 10 ("Transition Plan"), was purposely omitted from this
	from [RFC7990] that repeated what was in other RFCs, particularly		document. Text from [RFC7990] that repeated what was in other RFCs,
	Sections 8 ("Figures and Artwork") and 9 ("Content and Page Layout"),		particularly Section 8 ("Figures and Artwork") and Section 9
	was also removed.		("Content and Page Layout"), was also removed.
	1.2. Changes to RFC 9280		1.2. Changes to RFC 9280
	Section 7.6 of [RFC9280] says:		Section 7.6 of [RFC9280] says:
	| Once published, RFC Series documents are not changed.		| Once published, RFC Series documents are not changed.
	This document replaces that sentence with:		This document replaces that sentence with:
	| Once published, RFCs may be reissued, but the semantic content of		| Once published, RFCs may be reissued, but the semantic content of
	| publication versions shall be preserved to the greatest extent		| publication versions shall be preserved to the greatest extent
	| possible.		| possible.
	This document also adds a new policy to Section 7 of [RFC9280]:		This document also adds a new policy to Section 7 of [RFC9280]:
	| 7.8. Consistency		| 7.8. Consistency
	|		|
	| RFCs are copyedited, formatted, published, and may be reissued		| RFCs are copyedited, formatted, and then published. They may
	| to maintain a consistent presentation.		| be reissued to maintain a consistent presentation.
	Sections 2.1 and 3 in this document are based on this updated policy		Sections 2.1 and 3 in this document are based on this policy in
	in [RFC9280].		[RFC9280].
	1.3. Key Changes from the Earlier RFC Process		1.3. Key Changes from the Earlier RFC Process
	The first RFC to be published following the guidance of the group of		The first RFC to be published following the guidance of the group of
	RFCs described in [RFC7990] was [RFC8651], published in October 2019.		RFCs described in [RFC7990] was [RFC8651], published in October 2019.
	In the time since then, all published RFCs have followed the general		In the time since then, all published RFCs have followed the general
	plan from [RFC7990].		plan from [RFC7990].
	At the highest level, the changes that [RFC7990] made to the RFC		At the highest level, the changes that [RFC7990] made to the RFC
	format involved breaking away from solely ASCII [RFC20] plain text		format involved breaking away from solely ASCII [RFC20] plain text
	and moving to a definitive format that includes all the information		and moving to a definitive format that includes all the information
	required for rendering a document into a wide variety of publication		required for rendering a document into a wide variety of publication
	formats. The RPC became responsible for more than just the plain-		formats. The RPC became responsible for more than just the plain-
	text file and a PDF rendering that was created from the plain text at		text file and a PDF rendering that was created from the plain text at
	the time of publication; the RPC now creates the definitive version		the time of publication; the RPC now creates the definitive version
	and three publication versions of the RFC in order to meet the		and three publication versions of the RFC in order to meet the
	diverse requirements of the community.		diverse requirements of the community.
	The final RFCXML file produced by the RPC is the definitive version		The final RFCXML file produced by the RPC is the definitive version
	for RFCs; it holds all the information intended for an RFC.		for RFCs; it holds all the information intended for an RFC.
	Additional publication versions (HTML, PDF, and plain text) are also		Additional publication versions (HTML, plain text, and PDF) are also
	published by the RPC. The publication formats are described in		published by the RPC. The publication formats are fully specified in
	Section 3 and fully specified in other RFCs.		other RFCs.
	2. Definitive Version of an RFC		2. Definitive Version of an RFC
	The definitive version produced by the RPC is the publication version		The definitive version produced by the RPC holds all the information
	that holds all the information intended for an RFC. The RPC may		intended for an RFC. The RPC may change the definitive version of an
	change the definitive version of an RFC over time (that is, change		RFC over time (that is, change the XML file), as described in
	the XML file), as described in Section 2.1. See [RFC7991] for the		Section 2.1. See [RFC7991] for the original complete description of
	original complete description of RFCXML.		RFCXML.
	The XML may contain SVG line art, as originally described in		The XML may contain SVG line art, as originally described in
	[RFC7996]. That SVG will also appear in the HTML publication		[RFC7996]. That SVG will also appear in the HTML publication
	versions. The XML may contain non-ASCII characters, as originally		version. The XML may contain non-ASCII characters, as originally
	described in [RFC7997]. These characters will appear in all the		described in [RFC7997]. These characters will appear in all the
	publication versions.		publication versions.
	The definitive version must contain all information necessary to		The definitive version must contain all information necessary to
	render the specified publication versions; any question about what		render the specified publication versions; any question about what
	was intended in the publication will be answered from this file. It		was intended in the publication will be answered from this file. It
	is self-contained with all the semantic content known at publication		is self-contained with all the semantic content known at publication
	time. For instance, all features that reference externally defined		time. For instance, all features that reference externally defined
	input are expanded. It does not contain src attributes for <artwork>		input are expanded. It does not contain src attributes for <artwork>
	or <sourcecode> elements. It does not contain comments or processing		or <sourcecode> elements. It does not contain comments or processing
	skipping to change at line 247 ¶		skipping to change at line 247 ¶
	2.2. Expected Updates to RFCXML		2.2. Expected Updates to RFCXML
	It is anticipated that [RFC7991] will be updated. Updates to the		It is anticipated that [RFC7991] will be updated. Updates to the
	RFCXML specification that are applied to existing RFCs should		RFCXML specification that are applied to existing RFCs should
	preserve the semantics expressed in the original RFC to the greatest		preserve the semantics expressed in the original RFC to the greatest
	extent possible. The goal of limiting changes only to syntax is to		extent possible. The goal of limiting changes only to syntax is to
	preserve the semantic meaning encoded in the published document.		preserve the semantic meaning encoded in the published document.
	This policy does not require that updates to RFCXML avoid all risk of		This policy does not require that updates to RFCXML avoid all risk of
	introducing semantic changes to existing RFCs. Instead, it only		introducing semantic changes to existing RFCs. Instead, considering
	requires that such updates consider the potential for semantic		the potential for semantic changes, taking steps to understand the
	changes, take steps to understand the risk of a semantic change		risk of a semantic change (either deliberate or inadvertent), and
	(either deliberate or inadvertent), and limit those risks.		limiting associated risks are the only requirements.
	3. Publication Versions		3. Publication Versions
	The RPC is permitted but not required to reissue publication versions		The RPC is permitted but not required to reissue publication versions
	of an RFC, as described in Section 1.2. In deciding whether to		of an RFC, as described in Section 1.2. In deciding whether to
	update the publication versions of an RFC, the RPC will take into		update the publication versions of an RFC, the RPC will take into
	account both the risk of semantic changes and consistency of the		account both the risk of semantic changes and consistency of the
	Series.		Series.
	XML format errors and better design choices have been discovered by		XML format errors and better design choices have been discovered by
	skipping to change at line 292 ¶		skipping to change at line 292 ¶
	archived documents might be located or identified. The methods for		archived documents might be located or identified. The methods for
	storage and access will be determined by the RPC in consultation with		storage and access will be determined by the RPC in consultation with
	the technical community.		the technical community.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	6. Security Considerations		6. Security Considerations
	Allowing changes to the definitive versions and publication versions		Allowing changes to the definitive version and publication versions
	of RFCs introduces risks. A significant risk is that unintended		of RFCs introduces risks. A significant risk is that unintended
	changes could occur in either the definitive version or publication		changes could occur in either the definitive version or publication
	versions of an RFC as a result of an editing error, or may be		versions of an RFC as a result of an editing error. In addition,
	introduced into a publication version when it is regenerated from the		unintended changes may be introduced into a publication version when
	definitive version. This may result in the corruption of a standard,		it is regenerated from the definitive version. This may result in
	practice, or critical piece of information about a protocol, and harm		the corruption of a standard, practice, or critical piece of
	to the reputation of the RFC Series.		information about a protocol, which may harm the reputation of the
			RFC Series.
	The RPC is expected to identify, track, and actively mitigate risks		The RPC is expected to identify, track, and actively mitigate risks
	introduced by this new policy.		introduced by this new policy.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",		[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
	RFC 7991, DOI 10.17487/RFC7991, December 2016,		RFC 7991, DOI 10.17487/RFC7991, December 2016,
End of changes. 11 change blocks.
	38 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48.