draft-iab-protocol-maintenance-04.txt   draft-iab-protocol-maintenance-05.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational November 04, 2019 Intended status: Informational 12 July 2021
Expires: May 7, 2020 Expires: 13 January 2022
The Harmful Consequences of the Robustness Principle The Harmful Consequences of the Robustness Principle
draft-iab-protocol-maintenance-04 draft-iab-protocol-maintenance-05
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 Note to Readers
Discussion of this document takes place on the Architecture-Discuss Discussion of this document takes place on the Architecture-Discuss
mailing list (architecture-discuss@ietf.org), which is archived at mailing list (architecture-discuss@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/architecture-discuss/ [1]. https://mailarchive.ietf.org/arch/browse/architecture-discuss/
(https://mailarchive.ietf.org/arch/browse/architecture-discuss/).
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 [2]. https://github.com/intarchboard/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 May 7, 2020. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . 6
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 8 7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 8
8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Informative References . . . . . . . . . . . . . . . . . . . 10
11.1. Informative References . . . . . . . . . . . . . . . . . 10
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 IAB RFC 1958 [PRINCIPLES], the
robustness principle advises to: robustness principle advises to:
Be strict when sending and tolerant when receiving. Be strict when sending and tolerant when receiving.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Timely publication of protocol specifications, even with the Timely publication of protocol specifications, even with the
potential for flaws, likely contributed significantly to the eventual potential for flaws, likely contributed significantly to the eventual
success of the Internet. 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. The any system that is in early phases of deployment, is expedient.
consequence of applying the principle is deferring the effort of Applying the principle defers the effort of dealing with
dealing with interoperability problems, which can amplify the interoperability problems, which prioritizes progress. However,
ultimate cost of handling those problems. deferral can amplify the ultimate cost of handling interoperability
problems.
Divergent implementations of a specification emerge over time. When Divergent implementations of a specification emerge over time. When
variations occur in the interpretation or expression of semantic variations occur in the interpretation or expression of semantic
components, implementations cease to be perfectly interoperable. components, implementations cease to be perfectly interoperable.
Implementation bugs are often identified as the cause of variation, Implementation bugs are often identified as the cause of variation,
though it is often a combination of factors. Application of a though it is often a combination of factors. Application of a
protocol to uses that were not anticipated in the original design, or protocol to uses that were not anticipated in the original design, or
ambiguities and errors in the specification are often confounding ambiguities and errors in the specification are often confounding
factors. Disagreements on the interpretation of specifications factors. Disagreements on the interpretation of specifications
should be expected over the lifetime of a protocol. should be expected over the lifetime of a protocol.
Even with the best intentions, the pressure to interoperate can be Even with the best intentions, the pressure to interoperate can be
significant. No implementation can hope to avoid having to trade significant. No implementation can hope to avoid having to trade
correctness for interoperability indefinitely. correctness for interoperability indefinitely.
An implementation that reacts to variations in the manner recommended An implementation that reacts to variations in the manner recommended
in the robustness principle sets up a feedback cycle. Over time: in the robustness principle sets up a feedback cycle. Over time:
o Implementations progressively add logic to constrain how data is * Implementations progressively add logic to constrain how data is
transmitted, or to permit variations in what is received. transmitted, or to permit variations in what is received.
o Errors in implementations or confusion about semantics are * Errors in implementations or confusion about semantics are
permitted or ignored. permitted or ignored.
o These errors can become entrenched, forcing other implementations * These errors can become entrenched, forcing other implementations
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".
skipping to change at page 6, line 43 skipping to change at page 6, line 43
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
The robustness principle can be highly effective in safeguarding The robustness principle can be highly effective in safeguarding
against flaws in the implementation of a protocol by peers. against flaws in the implementation of a protocol by peers.
Especially when a specification remains unchanged for an extended Especially when a specification remains unchanged for an extended
period of time, the inclination to be tolerant accumulates over time. period of time, incentive to be tolerant of errors accumulates over
Indeed, when faced with divergent interpretations of an immutable time. Indeed, when faced with divergent interpretations of an
specification, the best 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 suggests that the problem is with logical, even necessary. But that conclusion relies on an assumption
the assumption that existing specifications and implementations are that existing specifications and implementations are unable to
unable to change. Applying the robustness principle in this way change. Applying the robustness principle in this way
disproportionately values short-term gains over the negative effects disproportionately values short-term gains over the negative effects
on future implementations and the protocol as a whole. on future 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
skipping to change at page 7, line 36 skipping to change at page 7, line 36
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
long term to fix one isolated bug than it is to deal with the long term to fix one isolated bug than it is to deal with the
consequences of workarounds. consequences of workarounds.
Early implementations of protocols have a stronger obligation to Early implementations of protocols have a stronger obligation to
closely follow specifications as their behavior will affect all closely follow specifications as their behavior will affect all
subsequent implementations. Protocol specifications might need more subsequent implementations. In addition to specifications, later
frequent revision during early deployments to capture feedback from implementations will be guided by what existing deployments accept.
early rounds of deployment. Tolerance of errors in early deployments is most likely to result in
problems. Protocol specifications might need more frequent revision
during early deployments to capture feedback from early rounds of
deployment.
Neglect can quickly produce the negative consequences this document Neglect can quickly produce the negative consequences this document
describes. Restoring the protocol to a state where it can be describes. Restoring the protocol to a state where it can be
maintained involves first discovering the properties of the protocol maintained involves first discovering the properties of the protocol
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 currency 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. If specifications can be updated more readily than
deployments, details of the workaround can be document, including the deployments, details of the workaround can be documented, including
desired form of the protocols once the need for workarounds no longer the desired form of the protocols once the need for workarounds no
exists and plans for removing the workaround. 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.
Extensibility is sometimes mistaken for an application of the The ability to extend a protocol is sometimes mistaken for an
robustness principle. After all, if one party wants to start using a application of the robustness principle. After all, if one party
new feature before another party is prepared to receive it, it might wants to start using a new feature before another party is prepared
be assumed that the receiving party is being tolerant of unexpected to receive it, it might be assumed that the receiving party is being
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. If an the handling of things like new messages or parameters. This depends
extension mechanism is designed and implemented correctly, new on having clear rules for the handling of malformed or illegal inputs
protocol features can be deployed with confidence in the so that implementations behave consistently in all cases that might
understanding of the effect they have on existing implementations. affect interoperation. If extension mechanisms and error handling
are designed and implemented correctly, new protocol features can be
deployed with confidence in the understanding of the effect they have
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
demonstrated by the case study in Appendix A.3 of [EXT]. demonstrated by the case study in Appendix A.3 of [EXT].
A protocol could be designed to permit a narrow set of valid inputs, A protocol could be designed to permit a narrow set of valid inputs,
or it could allow a wide range of inputs as a core feature (see for or it could allow a wide range of inputs as a core feature (see for
example [HTML]). Specifying and implementing a more flexible example [HTML]). Specifying and implementing a more flexible
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 interoperable handling of unusual conditions. will have consistent and interoperable handling of unusual
conditions.
Intolerance of any deviation from specification, where Intolerance of any deviation from specification, where
implementations generate fatal errors in response to observing implementations generate fatal errors in response to observing
undefined or unusual behaviour, can be harnessed to reduce undefined or unusual behaviour, can be harnessed to reduce
occurrences of aberrant implementations. Choosing to generate fatal occurrences of aberrant implementations. Choosing to generate fatal
errors for unspecified conditions instead of attempting error errors for unspecified conditions instead of attempting error
recovery can ensure that faults receive attention. recovery can ensure that faults receive attention.
This improves feedback for new implementations in particular. When a This improves feedback for new implementations in particular. When a
new implementation encounters an intolerant implementation, it new implementation encounters a peer that is intolerant of an error,
receives strong feedback that allows problems to be discovered it receives strong feedback that allows the problem to be discovered
quickly. 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
protocols have the effect of preventing interoperability. On the
contrary, when existing implementations follow clearly specified
error handling, new implementations or features can be introduced
more readily as the effect on existing implementations can be easily
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 [HTTP2] resulted in improvements in
the security of the deployed base. 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
skipping to change at page 9, line 41 skipping to change at page 10, line 6
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
incompatible ones, it is not always possible to produce a design that incompatible ones, it is not always possible to produce a design that
protects the ability of all current and future protocol participants protects the ability of all current and future protocol participants
to interoperate. Developing and deploying changes that risk to interoperate. Developing and deploying changes that risk
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), which is deployed with the intent of protecting (see Section 7). Exclusionary actions are employed with the
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. RFC 5704
[UNCOORDINATED] describes how conflict or competition in the [UNCOORDINATED] describes how conflict or competition in the
maintenance of protocols can lead to similar problems. 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
skipping to change at page 10, line 24 skipping to change at page 10, line 34
especially acute for any protocol where security depends on agreement especially acute for any protocol where security depends on agreement
about semantics of protocol elements. For instance, use of unsafe about semantics of protocol elements. For instance, use of unsafe
security mechanisms, such as weak primitives [MD5] or obsolete security mechanisms, such as weak primitives [MD5] or obsolete
mechanisms [SSL3], are good examples of where forcing exclusion mechanisms [SSL3], are good examples of where forcing exclusion
(Section 8) can be desirable. (Section 8) can be desirable.
10. IANA Considerations 10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
11. References 11. Informative References
11.1. Informative References
[ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th
Edition, June 2018, <https://www.ecma- Edition, June 2018, <https://www.ecma-
international.org/publications/standards/Ecma-262.htm>. international.org/publications/standards/Ecma-262.htm>.
[EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>. <https://www.rfc-editor.org/rfc/rfc6709>.
[HTML] "HTML", WHATWG Living Standard, 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/info/rfc7230>. <https://www.rfc-editor.org/rfc/rfc7230>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] 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/info/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>. <https://www.rfc-editor.org/rfc/rfc7493>.
[IP] Postel, J., "DoD standard Internet Protocol", RFC 760, [IP] 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/info/rfc760>. <https://www.rfc-editor.org/rfc/rfc760>.
[JSON] Crockford, D., "The application/json Media Type for [JSON] 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/info/rfc4627>. <https://www.rfc-editor.org/rfc/rfc4627>.
[JSON-BIS] [JSON-BIS] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
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/info/rfc7159>. 2014, <https://www.rfc-editor.org/rfc/rfc7159>.
[MD5] Turner, S. and L. Chen, "Updated Security Considerations [MD5] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/rfc/rfc6151>.
[PRINCIPLES] [PRINCIPLES]
Carpenter, B., Ed., "Architectural Principles of the Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/info/rfc1958>. <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/info/rfc7568>. <https://www.rfc-editor.org/rfc/rfc7568>.
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <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/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[UNCOORDINATED] [UNCOORDINATED]
Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
Protocol Development Considered Harmful", RFC 5704, Protocol Development Considered Harmful", RFC 5704,
DOI 10.17487/RFC5704, November 2009, DOI 10.17487/RFC5704, November 2009,
<https://www.rfc-editor.org/info/rfc5704>. <https://www.rfc-editor.org/rfc/rfc5704>.
[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension [USE-IT] Thomson, M., "Long-term Viability of Protocol Extension
Mechanisms", draft-thomson-use-it-or-lose-it-04 (work in Mechanisms", Work in Progress, Internet-Draft, draft-iab-
progress), July 2019. use-it-or-lose-it-00, 7 August 2019,
<https://datatracker.ietf.org/doc/html/draft-iab-use-it-
11.2. URIs or-lose-it-00>.
[1] https://mailarchive.ietf.org/arch/browse/architecture-discuss/
[2] https://github.com/intarchboard/protocol-maintenance
Appendix A. Acknowledgments 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, Henning Schulzrinne,
Robert Sparks, Brian Trammell, and Anne Van Kesteren. Please excuse Robert Sparks, Brian Trammell, and Anne Van Kesteren. Please excuse
any omission. any omission.
Author's Address Author's Address
 End of changes. 41 change blocks. 
80 lines changed or deleted 87 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/