< draft-iab-protocol-maintenance-05.txt		draft-iab-protocol-maintenance-06.txt >
	Network Working Group M. Thomson		Network Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Informational 12 July 2021		Intended status: Informational D. Schinazi
	Expires: 13 January 2022		Expires: 12 November 2022 Google LLC
			11 May 2022
	The Harmful Consequences of the Robustness Principle		The Harmful Consequences of the Robustness Principle
	draft-iab-protocol-maintenance-05		draft-iab-protocol-maintenance-06
	Abstract		Abstract
	The robustness principle, often phrased as "be conservative in what		The robustness principle, often phrased as "be conservative in what
	you send, and liberal in what you accept", has long guided the design		you send, and liberal in what you accept", has long guided the design
	and implementation of Internet protocols. The posture this statement		and implementation of Internet protocols. The posture this statement
	advocates promotes interoperability in the short term, but can		advocates promotes interoperability in the short term, but can
	negatively affect the protocol ecosystem over time. For a protocol		negatively affect the protocol ecosystem over time. For a protocol
	that is actively maintained, the robustness principle can, and		that is actively maintained, the robustness principle can, and
	should, be avoided.		should, be avoided.
	Note to Readers		About This Document
	Discussion of this document takes place on the Architecture-Discuss		This note is to be removed before publishing as an RFC.
	mailing list (architecture-discuss@ietf.org), which is archived at
	https://mailarchive.ietf.org/arch/browse/architecture-discuss/		Status information for this document may be found at
	(https://mailarchive.ietf.org/arch/browse/architecture-discuss/).		https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/.
			Discussion of this document takes place on the EDM IAB Program
			mailing list (mailto:edm@iab.org), which is archived at
			https://www.iab.org/mailman/listinfo/edm.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	https://github.com/intarchboard/protocol-maintenance		https://github.com/intarchboard/draft-protocol-maintenance.
	(https://github.com/intarchboard/protocol-maintenance).
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 12 November 2022.
	This Internet-Draft will expire on 13 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document.
	extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3		2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3
	3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5		4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5
	5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6		5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 7
	6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 8		7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 9
	8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. Informative References . . . . . . . . . . . . . . . . . . . 10		11. Informative References . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The robustness principle has been hugely influential in shaping the		The robustness principle has been hugely influential in shaping the
	design of the Internet. As stated in IAB RFC 1958 [PRINCIPLES], the		design of the Internet. As stated in the IAB document on
	robustness principle advises to:		Architectural Principles of the Internet [RFC1958], the robustness
			principle advises to:
	Be strict when sending and tolerant when receiving.		Be strict when sending and tolerant when receiving.
	Implementations must follow specifications precisely when sending		Implementations must follow specifications precisely when sending
	to the network, and tolerate faulty input from the network. When		to the network, and tolerate faulty input from the network. When
	in doubt, discard faulty input silently, without returning an		in doubt, discard faulty input silently, without returning an
	error message unless this is required by the specification.		error message unless this is required by the specification.
	This simple statement captures a significant concept in the design of		This simple statement captures a significant concept in the design of
	interoperable systems. Many consider the application of the		interoperable systems. Many consider the application of the
	robustness principle to be instrumental in the success of the		robustness principle to be instrumental in the success of the
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	a system the size of the Internet. That is, the idea that once a		a system the size of the Internet. That is, the idea that once a
	protocol specification is published, changes that might require		protocol specification is published, changes that might require
	existing implementations to change are not feasible.		existing implementations to change are not feasible.
	Many problems that might lead to applications of the robustness		Many problems that might lead to applications of the robustness
	principle are avoided for protocols under active maintenance. Active		principle are avoided for protocols under active maintenance. Active
	protocol maintenance is where a community of protocol designers,		protocol maintenance is where a community of protocol designers,
	implementers, and deployers work together to continuously improve and		implementers, and deployers work together to continuously improve and
	evolve protocol specifications alongside implementations and		evolve protocol specifications alongside implementations and
	deployments of those protocols. A community that takes an active		deployments of those protocols. A community that takes an active
	role in the maintenance of protocols can greatly reduce and even		role in the maintenance of protocols will no longer need to rely on
	eliminate opportunities to apply the robustness principle.		the robustness principle to avoid interoperability issues.
	There is good evidence to suggest that many important protocols are		There is good evidence to suggest that many important protocols are
	routinely maintained beyond their inception. In particular, a		routinely maintained beyond their inception. In particular, a
	sizeable proportion of IETF activity is dedicated to the stewardship		sizeable proportion of IETF activity is dedicated to the stewardship
	of existing protocols. This document serves primarily as a record of		of existing protocols. This document serves primarily as a record of
	the hazards inherent in applying the robustness principle and to		the hazards inherent in applying the robustness principle and to
	offer an alternative strategy for handling interoperability problems		offer an alternative strategy for handling interoperability problems
	in deployments.		in deployments.
	Ideally, protocol implementations never have to apply the robustness		Ideally, protocol implementations never have to apply the robustness
	principle. Or, where it is unavoidable, use of the robustness		principle. Or, where it is unavoidable, use of the robustness
	principle is viewed as a short term workaround that needs to be		principle is viewed as a short term workaround that needs to be
	quickly reverted.		quickly reverted.
	2. Fallibility of Specifications		2. Fallibility of Specifications
	The context from which the robustness principle was developed		The context from which the robustness principle was developed
	provides valuable insights into its intent and purpose. The earliest		provides valuable insights into its intent and purpose. The earliest
	form of the principle in the RFC series (in RFC 760 [IP]) is preceded		form of the principle in the RFC series (the Internet Protocol
	by a sentence that reveals the motivation for the principle:		specification [RFC0760]) is preceded by a sentence that reveals the
			motivation for the principle:
	While the goal of this specification is to be explicit about the		While the goal of this specification is to be explicit about the
	protocol there is the possibility of differing interpretations.		protocol there is the possibility of differing interpretations.
	In general, an implementation should be conservative in its		In general, an implementation should be conservative in its
	sending behavior, and liberal in its receiving behavior.		sending behavior, and liberal in its receiving behavior.
	This formulation of the principle expressly recognizes the		This formulation of the principle expressly recognizes the
	possibility that the specification could be imperfect. This		possibility that the specification could be imperfect. This
	contextualizes the principle in an important way.		contextualizes the principle in an important way.
	An imperfect specification is natural, largely because it is more		An imperfect specification is natural, largely because it is more
	important to proceed to implementation and deployment than it is to		important to proceed to implementation and deployment than it is to
	perfect a specification. A protocol, like any complex system,		perfect a specification. A protocol benefits greatly from experience
	benefits greatly from experience with its use. A deployed protocol		with its use. A deployed protocol is immeasurably more useful than a
	is immeasurably more useful than a perfect protocol. The robustness		perfect protocol. The robustness principle is a tool that is suited
	principle is a tool that is suited to early phases of system design.		to early phases of system design.
	As [SUCCESS] demonstrates, success or failure of a protocol depends		As demonstrated by the IAB document on Successful Protocols
	far more on factors like usefulness than on on technical excellence.		[RFC5218], success or failure of a protocol depends far more on
	Timely publication of protocol specifications, even with the		factors like usefulness than on technical excellence. Timely
	potential for flaws, likely contributed significantly to the eventual		publication of protocol specifications, even with the potential for
	success of the Internet.		flaws, likely contributed significantly to the eventual success of
			the Internet.
	The problem is therefore not with the premise, but with its		The problem is therefore not with the premise, but with its
	conclusion: the robustness principle itself.		conclusion: the robustness principle itself.
	3. Protocol Decay		3. Protocol Decay
	The application of the robustness principle to the early Internet, or		The application of the robustness principle to the early Internet, or
	any system that is in early phases of deployment, is expedient.		any system that is in early phases of deployment, is expedient.
	Applying the principle defers the effort of dealing with		Applying the principle defers the effort of dealing with
	interoperability problems, which prioritizes progress. However,		interoperability problems, which prioritizes progress. However,
	skipping to change at page 5, line 16 ¶		skipping to change at page 5, line 19 ¶
	to be tolerant of those errors.		to be tolerant of those errors.
	A flaw can become entrenched as a de facto standard. Any		A flaw can become entrenched as a de facto standard. Any
	implementation of the protocol is required to replicate the aberrant		implementation of the protocol is required to replicate the aberrant
	behavior, or it is not interoperable. This is both a consequence of		behavior, or it is not interoperable. This is both a consequence of
	applying the robustness principle, and a product of a natural		applying the robustness principle, and a product of a natural
	reluctance to avoid fatal error conditions. Ensuring		reluctance to avoid fatal error conditions. Ensuring
	interoperability in this environment is often referred to as aiming		interoperability in this environment is often referred to as aiming
	to be "bug for bug compatible".		to be "bug for bug compatible".
	For example, in TLS [TLS] extensions use a tag-length-value format,		For example, in TLS [TLS], extensions use a tag-length-value format
	and they can be added to messages in any order. However, some server		and they can be added to messages in any order. However, some server
	implementations terminate connections if they encounter a TLS		implementations terminated connections if they encountered a TLS
	ClientHello message that ends with an empty extension. To maintain		ClientHello message that ends with an empty extension. To maintain
	interoperability, client implementations are required to be aware of		interoperability, client implementations were required to be aware of
	this bug and ensure that a ClientHello message ends in a non-empty		this bug and ensure that a ClientHello message ends in a non-empty
	extension.		extension.
	The original JSON specification [JSON] demonstrates the effect of		The original JSON specification [RFC4627] demonstrates the effect of
	specification shortcomings. RFC 4627 omitted critical details on a		specification shortcomings: it did not tightly specify some important
	range of key details including Unicode handling, ordering and		details including Unicode handling, ordering and duplication of
	duplication of object members, and number encoding. Consequently, a		object members, and number encoding. Consequently, a range of
	range of interpretations were used by implementations. An updated		interpretations were used by implementations. An updated JSON
	specification [JSON-BIS] did not correct these errors, concentrating		specification [RFC7159] did not correct these errors, concentrating
	instead on identifying the interoperable subset of JSON. I-JSON		instead on identifying the interoperable subset of JSON. I-JSON
	[I-JSON] takes that subset and defines a new format that prohibits		[RFC7493] takes that subset and defines a new format that prohibits
	the problematic parts of JSON. Of course, that means that I-JSON is		the problematic parts of JSON. Of course, that means that I-JSON is
	not fully interoperable with JSON. Consequently, I-JSON is not		not fully interoperable with JSON. Consequently, I-JSON is not
	widely implemented in parsers. Many JSON parsers now implement the		widely implemented in parsers. Many JSON parsers now implement the
	more precise algorithm specified in [ECMA262].		more precise algorithm specified in [ECMA262].
	The robustness principle therefore encourages a reaction that can		The robustness principle therefore encourages a chain reaction that
	create interoperability problems. In particular, the application of		can create interoperability problems. In particular, the application
	the robustness principle is particularly deleterious for early		of the robustness principle is particularly deleterious for early
	implementations of new protocols as quirks in early implementations		implementations of new protocols as quirks in early implementations
	can affect all subsequent deployments.		can affect all subsequent deployments.
	4. Ecosystem Effects		4. Ecosystem Effects
	Once deviations become entrenched, it can be extremely difficult - if		From observing widely deployed protocols, it appears there are two
	not impossible - to rectify the situation.		stable points on the spectrum between being strict versus permissive
			in the presence of protocol errors:
	Interoperability requirements for protocol implementations are set by		* If implementations predominantly enforce strict compliance with
	other deployments. Specifications and - where they exist -		specifications, newer implementations will experience failures if
	conformance test suites might guide the initial development of		they do not comply with protocol requirements. Newer
	implementations, but implementations ultimately need to interoperate		implementations need to fix compliance issues in order to be
	with deployed implementations.		successfully deployed. This ensures that most deployments are
			compliant.
			* Conversely, if non-compliance is tolerated by existing
			implementations, non-compliant implementations can be deployed
			successfully. Newer implementations then have strong incentive to
			tolerate any existing non-compliance in order to be successfully
			deployed. This ensures that most deployments are tolerant of the
			same non-compliant behavior.
			This happens because interoperability requirements for protocol
			implementations are set by other deployments. Specifications and -
			where they exist - conformance test suites might guide the initial
			development of implementations, but implementations ultimately need
			to interoperate with deployed implementations.
	For widely used protocols, the massive scale of the Internet makes		For widely used protocols, the massive scale of the Internet makes
	large-scale interoperability testing infeasible for all but a		large-scale interoperability testing infeasible for all but a
	privileged few. The cost of building a new implementation using		privileged few. The cost of building a new implementation using
	reverse engineering increases as the number of implementations and		reverse engineering increases as the number of implementations and
	bugs increases. Worse, the set of tweaks necessary for wide		bugs increases. Worse, the set of tweaks necessary for wide
	interoperability can be difficult to discover.		interoperability can be difficult to discover. In the worst case, a
			new implementer might have to choose between deployments that have
			diverged so far as to no longer be interoperable.
	Consequently, new implementations might be forced into niche uses,		Consequently, new implementations might be forced into niche uses,
	where the problems arising from interoperability issues can be more		where the problems arising from interoperability issues can be more
	closely managed. However, restricting new implementations into		closely managed. However, restricting new implementations into
	limited deployments risks causing forks in the protocol. If		limited deployments risks causing forks in the protocol. If
	implementations do not interoperate, little prevents those		implementations do not interoperate, little prevents those
	implementations from diverging more over time.		implementations from diverging more over time.
	This has a negative impact on the ecosystem of a protocol. New		This has a negative impact on the ecosystem of a protocol. New
	implementations are important in ensuring the continued viability of		implementations are key to the continued viability of a protocol.
	a protocol. New protocol implementations are also more likely to be		New protocol implementations are also more likely to be developed for
	developed for new and diverse use cases and often are the origin of		new and diverse use cases and are often the origin of features and
	features and capabilities that can be of benefit to existing users.		capabilities that can be of benefit to existing users.
	The need to work around interoperability problems also reduces the		The need to work around interoperability problems also reduces the
	ability of established implementations to change. An accumulation of		ability of established implementations to change. An accumulation of
	mitigations for interoperability issues makes implementations more		mitigations for interoperability issues makes implementations more
	difficult to maintain and can constrain extensibility (see also		difficult to maintain and can constrain extensibility (see also the
	[USE-IT]).		IAB document on the Long-Term Viability of Protocol Extension
			Mechanisms [RFC9170]).
	Sometimes what appear to be interoperability problems are symptomatic		Sometimes what appear to be interoperability problems are symptomatic
	of issues in protocol design. A community that is willing to make		of issues in protocol design. A community that is willing to make
	changes to the protocol, by revising or extending it, makes the		changes to the protocol, by revising or extending it, makes the
	protocol better in the process. Applying the robustness principle		protocol better in the process. Applying the robustness principle
	instead conceals problems, making it harder, or even impossible, to		instead conceals problems, making it harder, or even impossible, to
	fix them later.		fix them later.
	5. Active Protocol Maintenance		5. Active Protocol Maintenance
	skipping to change at page 6, line 52 ¶		skipping to change at page 7, line 26 ¶
	Especially when a specification remains unchanged for an extended		Especially when a specification remains unchanged for an extended
	period of time, incentive to be tolerant of errors accumulates over		period of time, incentive to be tolerant of errors accumulates over
	time. Indeed, when faced with divergent interpretations of an		time. Indeed, when faced with divergent interpretations of an
	immutable specification, the only way for an implementation to remain		immutable specification, the only way for an implementation to remain
	interoperable is to be tolerant of differences in interpretation and		interoperable is to be tolerant of differences in interpretation and
	implementation errors.		implementation errors.
	From this perspective, application of the robustness principle to the		From this perspective, application of the robustness principle to the
	implementation of a protocol specification that does not change is		implementation of a protocol specification that does not change is
	logical, even necessary. But that conclusion relies on an assumption		logical, even necessary. But that conclusion relies on an assumption
	that existing specifications and implementations are unable to		that existing specifications and implementations cannot change.
	change. Applying the robustness principle in this way		Applying the robustness principle in this way disproportionately
	disproportionately values short-term gains over the negative effects		values short-term gains over the negative effects on future
	on future implementations and the protocol as a whole.		implementations and the protocol as a whole.
	For a protocol to have sustained viability, it is necessary for both		For a protocol to have sustained viability, it is necessary for both
	specifications and implementations to be responsive to changes, in		specifications and implementations to be responsive to changes, in
	addition to handling new and old problems that might arise over time.		addition to handling new and old problems that might arise over time.
	Maintaining specifications so that they closely match deployments		Maintaining specifications so that they closely match deployments
	ensures that implementations are consistently interoperable and		ensures that implementations are consistently interoperable and
	removes needless barriers for new implementations. Maintenance also		removes needless barriers for new implementations. Maintenance also
	enables continued improvement of the protocol. New use cases are an		enables continued improvement of the protocol. New use cases are an
	indicator that the protocol could be successful [SUCCESS].		indicator that the protocol could be successful [RFC5218].
	Protocol designers are strongly encouraged to continue to maintain		Protocol designers are strongly encouraged to continue to maintain
	and evolve protocol specificationss beyond their initial inception		and evolve protocol specifications beyond their initial inception and
	and definition. This might require the development of revised		definition. This might require the development of revised
	specifications, extensions, or other supporting material that		specifications, extensions, or other supporting material that
	documents the current state of the protocol. Involvement of those		documents the current state of the protocol. Involvement of those
	who implement and deploy the protocol is a critical part of this		who implement and deploy the protocol is a critical part of this
	process, as they provide input on their experience with how the		process, as they provide input on their experience with how the
	protocol is used.		protocol is used.
	Most interoperability problems do not require revision of protocols		Most interoperability problems do not require revision of protocols
	or protocol specifications. For instance, the most effective means		or protocol specifications. For instance, the most effective means
	of dealing with a defective implementation in a peer could be to		of dealing with a defective implementation in a peer could be to
	email the developer responsible. It is far more efficient in the		email the developer responsible. It is far more efficient in the
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 30 ¶
	as it is deployed, rather than the protocol as it was originally		as it is deployed, rather than the protocol as it was originally
	documented. This can be difficult and time-consuming, particularly		documented. This can be difficult and time-consuming, particularly
	if the protocol has a diverse set of implementations. Such a process		if the protocol has a diverse set of implementations. Such a process
	was undertaken for HTTP [HTTP] after a period of minimal maintenance.		was undertaken for HTTP [HTTP] after a period of minimal maintenance.
	Restoring HTTP specifications to relevance took significant effort.		Restoring HTTP specifications to relevance took significant effort.
	Maintenance is most effective if it is responsive, which is greatly		Maintenance is most effective if it is responsive, which is greatly
	affected by how rapidly protocol changes can be deployed. For		affected by how rapidly protocol changes can be deployed. For
	protocol deployments that operate on longer time scales, temporary		protocol deployments that operate on longer time scales, temporary
	workarounds following the spirit of the robustness principle might be		workarounds following the spirit of the robustness principle might be
	necessary. If specifications can be updated more readily than		necessary. For this, improvements in software update mechanisms
	deployments, details of the workaround can be documented, including		ensure that the cost of reacting to changes is much lower than it was
	the desired form of the protocols once the need for workarounds no		in the past. Alternatively, if specifications can be updated more
	longer exists and plans for removing the workaround.		readily than deployments, details of the workaround can be
			documented, including the desired form of the protocols once the need
			for workarounds no longer exists and plans for removing the
			workaround.
	6. Extensibility		6. Extensibility
	Good extensibility [EXT] can make it easier to respond to new use		Good extensibility [EXT] can make it easier to respond to new use
	cases or changes in the environment in which the protocol is		cases or changes in the environment in which the protocol is
	deployed.		deployed.
	The ability to extend a protocol is sometimes mistaken for an		The ability to extend a protocol is sometimes mistaken for an
	application of the robustness principle. After all, if one party		application of the robustness principle. After all, if one party
	wants to start using a new feature before another party is prepared		wants to start using a new feature before another party is prepared
	to receive it, it might be assumed that the receiving party is being		to receive it, it might be assumed that the receiving party is being
	tolerant of unexpected inputs.		tolerant of unexpected inputs.
	A well-designed extensibility mechanism establishes clear rules for		A well-designed extensibility mechanism establishes clear rules for
	the handling of things like new messages or parameters. This depends		the handling of things like new messages or parameters. This depends
	on having clear rules for the handling of malformed or illegal inputs		on precisely specifying the handling of malformed or illegal inputs
	so that implementations behave consistently in all cases that might		so that implementations behave consistently in all cases that might
	affect interoperation. If extension mechanisms and error handling		affect interoperation. If extension mechanisms and error handling
	are designed and implemented correctly, new protocol features can be		are designed and implemented correctly, new protocol features can be
	deployed with confidence in the understanding of the effect they have		deployed with confidence in the understanding of the effect they have
	on existing implementations.		on existing implementations.
	In contrast, relying on implementations to consistently apply the		In contrast, relying on implementations to consistently apply the
	robustness principle is not a good strategy for extensibility. Using		robustness principle is not a good strategy for extensibility. Using
	undocumented or accidental features of a protocol as the basis of an		undocumented or accidental features of a protocol as the basis of an
	extensibility mechanism can be extremely difficult, as is		extensibility mechanism can be extremely difficult, as is
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 33 ¶
	protocol is more difficult; allowing less variability is preferable		protocol is more difficult; allowing less variability is preferable
	in the absence of strong reasons to be flexible.		in the absence of strong reasons to be flexible.
	7. Virtuous Intolerance		7. Virtuous Intolerance
	A well-specified protocol includes rules for consistent handling of		A well-specified protocol includes rules for consistent handling of
	aberrant conditions. This increases the chances that implementations		aberrant conditions. This increases the chances that implementations
	will have consistent and interoperable handling of unusual		will have consistent and interoperable handling of unusual
	conditions.		conditions.
	Intolerance of any deviation from specification, where		Choosing to generate fatal errors for unspecified conditions instead
	implementations generate fatal errors in response to observing		of attempting error recovery can ensure that faults receive
	undefined or unusual behaviour, can be harnessed to reduce		attention. This intolerance can be harnessed to reduce occurrences
	occurrences of aberrant implementations. Choosing to generate fatal		of aberrant implementations.
	errors for unspecified conditions instead of attempting error
	recovery can ensure that faults receive attention.
	This improves feedback for new implementations in particular. When a		Intolerance toward violations of specification improves feedback for
	new implementation encounters a peer that is intolerant of an error,		new implementations in particular. When a new implementation
	it receives strong feedback that allows the problem to be discovered		encounters a peer that is intolerant of an error, it receives strong
	quickly.		feedback that allows the problem to be discovered quickly.
	To be effective, intolerant implementations need to be sufficiently		To be effective, intolerant implementations need to be sufficiently
	widely deployed that they are encountered by new implementations with		widely deployed that they are encountered by new implementations with
	high probability. This could depend on multiple implementations		high probability. This could depend on multiple implementations
	deploying strict checks.		deploying strict checks.
	This does not mean that intolerance of errors in early deployments of		This does not mean that intolerance of errors in early deployments of
	protocols have the effect of preventing interoperability. On the		protocols have the effect of preventing interoperability. On the
	contrary, when existing implementations follow clearly specified		contrary, when existing implementations follow clearly specified
	error handling, new implementations or features can be introduced		error handling, new implementations or features can be introduced
	more readily as the effect on existing implementations can be easily		more readily as the effect on existing implementations can be easily
	predicted; see also Section 6.		predicted; see also Section 6.
	Any intolerance also needs to be strongly supported by		Any intolerance also needs to be strongly supported by
	specifications, otherwise they encourage fracturing of the protocol		specifications, otherwise they encourage fracturing of the protocol
	community or proliferation of workarounds; see Section 8.		community or proliferation of workarounds; see Section 8.
	Intolerance can be used to motivate compliance with any protocol		Intolerance can be used to motivate compliance with any protocol
	requirement. For instance, the INADEQUATE_SECURITY error code and		requirement. For instance, the INADEQUATE_SECURITY error code and
	associated requirements in HTTP/2 [HTTP2] resulted in improvements in		associated requirements in HTTP/2 [HTTP/2] resulted in improvements
	the security of the deployed base.		in the security of the deployed base.
	8. Exclusion		8. Exclusion
	Any protocol participant that is affected by changes arising from		Any protocol participant that is affected by changes arising from
	maintenance might be excluded if they are unwilling or unable to		maintenance might be excluded if they are unwilling or unable to
	implement or deploy changes that are made to the protocol.		implement or deploy changes that are made to the protocol.
	Deliberate exclusion of problematic implementations is an important		Deliberate exclusion of problematic implementations is an important
	tool that can ensure that the interoperability of a protocol remains		tool that can ensure that the interoperability of a protocol remains
	viable. While compatible changes are always preferable to		viable. While compatible changes are always preferable to
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 43 ¶
	exclusion of previously interoperating implementations requires some		exclusion of previously interoperating implementations requires some
	care, but changes to a protocol should not be blocked on the grounds		care, but changes to a protocol should not be blocked on the grounds
	of the risk of exclusion alone.		of the risk of exclusion alone.
	Exclusion is a direct goal when choosing to be intolerant of errors		Exclusion is a direct goal when choosing to be intolerant of errors
	(see Section 7). Exclusionary actions are employed with the		(see Section 7). Exclusionary actions are employed with the
	deliberate intent of protecting future interoperability.		deliberate intent of protecting future interoperability.
	Excluding implementations or deployments can lead to a fracturing of		Excluding implementations or deployments can lead to a fracturing of
	the protocol system that could be more harmful than any divergence		the protocol system that could be more harmful than any divergence
	resulting from following the robustness principle. RFC 5704		resulting from following the robustness principle. The IAB document
	[UNCOORDINATED] describes how conflict or competition in the		on Uncoordinated Protocol Development Considered Harmful [RFC5704]
	maintenance of protocols can lead to similar problems.		describes how conflict or competition in the maintenance of protocols
			can lead to similar problems.
	9. Security Considerations		9. Security Considerations
	Sloppy implementations, lax interpretations of specifications, and		Sloppy implementations, lax interpretations of specifications, and
	uncoordinated extrapolation of requirements to cover gaps in		uncoordinated extrapolation of requirements to cover gaps in
	specification can result in security problems. Hiding the		specification can result in security problems. Hiding the
	consequences of protocol variations encourages the hiding of issues,		consequences of protocol variations encourages the hiding of issues,
	which can conceal bugs and make them difficult to discover.		which can conceal bugs and make them difficult to discover.
	The consequences of the problems described in this document are		The consequences of the problems described in this document are
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 43 ¶
	<https://www.rfc-editor.org/rfc/rfc6709>.		<https://www.rfc-editor.org/rfc/rfc6709>.
	[HTML] "HTML", WHATWG Living Standard, 8 March 2019,		[HTML] "HTML", WHATWG Living Standard, 8 March 2019,
	<https://html.spec.whatwg.org/>.		<https://html.spec.whatwg.org/>.
	[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/rfc/rfc7230>.		<https://www.rfc-editor.org/rfc/rfc7230>.
	[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/rfc/rfc7540>.		<https://www.rfc-editor.org/rfc/rfc7540>.
	[I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,		[MD5] Turner, S. and L. Chen, "Updated Security Considerations
	DOI 10.17487/RFC7493, March 2015,		for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
	<https://www.rfc-editor.org/rfc/rfc7493>.		RFC 6151, DOI 10.17487/RFC6151, March 2011,
			<https://www.rfc-editor.org/rfc/rfc6151>.
	[IP] Postel, J., "DoD standard Internet Protocol", RFC 760,		[RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760,
	DOI 10.17487/RFC0760, January 1980,		DOI 10.17487/RFC0760, January 1980,
	<https://www.rfc-editor.org/rfc/rfc760>.		<https://www.rfc-editor.org/rfc/rfc760>.
	[JSON] Crockford, D., "The application/json Media Type for		[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
			Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
			<https://www.rfc-editor.org/rfc/rfc1958>.
			[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627,		JavaScript Object Notation (JSON)", RFC 4627,
	DOI 10.17487/RFC4627, July 2006,		DOI 10.17487/RFC4627, July 2006,
	<https://www.rfc-editor.org/rfc/rfc4627>.		<https://www.rfc-editor.org/rfc/rfc4627>.
	[JSON-BIS] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
			Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
			<https://www.rfc-editor.org/rfc/rfc5218>.
			[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
			Protocol Development Considered Harmful", RFC 5704,
			DOI 10.17487/RFC5704, November 2009,
			<https://www.rfc-editor.org/rfc/rfc5704>.
			[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <https://www.rfc-editor.org/rfc/rfc7159>.		2014, <https://www.rfc-editor.org/rfc/rfc7159>.
	[MD5] Turner, S. and L. Chen, "Updated Security Considerations		[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
	for the MD5 Message-Digest and the HMAC-MD5 Algorithms",		DOI 10.17487/RFC7493, March 2015,
	RFC 6151, DOI 10.17487/RFC6151, March 2011,		<https://www.rfc-editor.org/rfc/rfc7493>.
	<https://www.rfc-editor.org/rfc/rfc6151>.
	[PRINCIPLES]		[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
	Carpenter, B., Ed., "Architectural Principles of the		Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
	Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,		December 2021, <https://www.rfc-editor.org/rfc/rfc9170>.
	<https://www.rfc-editor.org/rfc/rfc1958>.
	[SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley,		[SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
	"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,		"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
	DOI 10.17487/RFC7568, June 2015,		DOI 10.17487/RFC7568, June 2015,
	<https://www.rfc-editor.org/rfc/rfc7568>.		<https://www.rfc-editor.org/rfc/rfc7568>.
	[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful
	Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
	<https://www.rfc-editor.org/rfc/rfc5218>.
	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.		<https://www.rfc-editor.org/rfc/rfc8446>.
	[UNCOORDINATED]		Acknowledgments
	Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
	Protocol Development Considered Harmful", RFC 5704,
	DOI 10.17487/RFC5704, November 2009,
	<https://www.rfc-editor.org/rfc/rfc5704>.
	[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension
	Mechanisms", Work in Progress, Internet-Draft, draft-iab-
	use-it-or-lose-it-00, 7 August 2019,
	<https://datatracker.ietf.org/doc/html/draft-iab-use-it-
	or-lose-it-00>.
	Appendix A. Acknowledgments
	Constructive feedback on this document has been provided by a		Constructive feedback on this document has been provided by a
	surprising number of people including Bernard Aboba, Brian Carpenter,		surprising number of people including Bernard Aboba, Brian Carpenter,
	Stuart Cheshire, Mark Nottingham, Russ Housley, Henning Schulzrinne,		Stuart Cheshire, Mark Nottingham, Russ Housley, Eric Rescorla,
	Robert Sparks, Brian Trammell, and Anne Van Kesteren. Please excuse		Henning Schulzrinne, Robert Sparks, Brian Trammell, and Anne Van
	any omission.		Kesteren. Please excuse any omission.
	Author's Address		Authors' Addresses
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: mt@lowentropy.net		Email: mt@lowentropy.net
			David Schinazi
			Google LLC
			1600 Amphitheatre Parkway
			Mountain View, CA 94043
			United States of America
			Email: dschinazi.ietf@gmail.com
End of changes. 48 change blocks.
	131 lines changed or deleted		149 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/