draft-iab-protocol-maintenance-00.txt   draft-iab-protocol-maintenance-01.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational May 03, 2018 Intended status: Informational October 22, 2018
Expires: November 4, 2018 Expires: April 25, 2019
The Harmful Consequences of the Robustness Principle The Harmful Consequences of the Robustness Principle
draft-iab-protocol-maintenance-00 draft-iab-protocol-maintenance-01
Abstract Abstract
Jon Postel's famous statement of "Be liberal in what you accept, and Jon Postel's famous statement of "Be liberal in what you accept, and
conservative in what you send" is a principle that has long guided conservative in what you send" is a principle that has long guided
the design and implementation of Internet protocols. The posture the design and implementation of Internet protocols. The posture
this statement advocates promotes interoperability, but can produce this statement advocates promotes interoperability in the short term,
negative effects in the protocol ecosystem in the long term. Those but can negatively affect the protocol ecosystem. For a protocol
effects can be avoided by maintaining protocols. that is actively maintained, the Postel's robustness principle can,
and should, be avoided.
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 November 4, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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 . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4
4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5
5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 5 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6
6. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 6 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Error Handling . . . . . . . . . . . . . . . . . . . . . 7 7. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 8
6.2. Feedback from Implementations . . . . . . . . . . . . . . 7 7.1. Feedback from Implementations . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.2. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Of the great many contributions Jon Postel made to the Internet, his Of the great many contributions Jon Postel made to the Internet, his
remarkable technical achievements are often shadowed by his remarkable technical achievements are often shadowed by his
contribution of a design and implementation philosophy known as the contribution of a design and implementation philosophy known as the
robustness principle: robustness principle:
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
skipping to change at page 2, line 50 skipping to change at page 3, line 5
the Internet and the systems that use Internet protocols. Many the Internet and the systems that use Internet protocols. Many
consider the application of the robustness principle to be consider the application of the robustness principle to be
instrumental in the success of the Internet as well as the design of instrumental in the success of the Internet as well as the design of
interoperable protocols in general. interoperable protocols in general.
Over time, considerable experience has been accumulated with Over time, considerable experience has been accumulated with
protocols that were designed by the application of Postel's maxim. protocols that were designed by the application of Postel's maxim.
That experience shows that there are negative long-term consequences That experience shows that there are negative long-term consequences
to interoperability if an implementation applies Postel's advice. to interoperability if an implementation applies Postel's advice.
This document shows that flaw in Postel's logic originates from the The flaw in Postel's logic originates from the presumption of an
presumption of immutability of protocol specifications. Thus rather inability to affect change in a system the size of the Internet.
than apply the robustness principle, this document recommends That is, once a protocol specification is published, changes that
continuing maintenance for protocols beyond their initial design and might be different to the practice of existing implementations are
deployment. Active maintenance of protocols reduces or eliminates not feasible.
the opportunities to apply Postel's guidance.
There is good evidence to suggest that protocols are routinely Many of the shortcomings that lead to applications of the robustness
maintained beyond their inception. This document serves primarily as principle are avoided for protocols under active maintenance. Active
a record of the shortcomings of the robustness principle. protocol maintenance is where a community of protocol designers,
implementers, and deployers continuously improve and evolve
protocols. A community that takes an active role in the maintenance
of protocols can greatly reduce and even eliminate opportunities to
apply Postel's guidance.
There is good evidence to suggest that many important protocols are
routinely maintained beyond their inception. This document serves
primarily as a record of the hazards inherent in applying the
robustness principle and to offer an alternative strategy for
handling interoperability problems in deployments.
Ideally, protocol implementations never have to apply the robustness
principle. Or, where it is unavoidable, any application can be
quickly reverted.
2. Fallibility of Specifications 2. Fallibility of Specifications
What is often missed in discussions of the robustness principle is The context from which the robustness principle was developed
the context in which it appears. The earliest form of the principle provides valuable insights into its intent and purpose. The earliest
in the RFC series (in RFC 760 [IP]) is preceded by a sentence that form of the principle in the RFC series (in RFC 760 [IP]) is preceded
reveals the motivation for the principle: 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 motivating statement is a frank admission of fallibility and Here Postel recognizes the possibility that the specification could
remarkable for it. Here Postel recognizes the possibility that the be imperfect. As a frank admission of fallibility it is a
specification could be imperfect. This is an important statement, significant statement. However, the same statement is inexplicably
but inexplicably absent from the later versions in [HOSTS] and absent from the later versions in [HOSTS] and [PRINCIPLES].
[PRINCIPLES].
Indeed, an imperfect specification is natural, largely because it is An imperfect specification is natural, largely because it is more
more important to proceed to implementation and deployment than it is important to proceed to implementation and deployment than it is to
to perfect a specification. A protocol, like any complex system, perfect a specification. A protocol, like any complex system,
benefits greatly from experience with its use. A deployed protocol benefits greatly from experience with its use. A deployed protocol
is immeasurably more useful than a perfect protocol. is immeasurably more useful than a perfect protocol.
As [SUCCESS] demonstrates, success or failure of a protocol depends As [SUCCESS] demonstrates, success or failure of a protocol depends
far more on factors like usefulness than on on technical excellence. far more on factors like usefulness than on on technical excellence.
Postel's timely publication of protocol specifications, even with the Postel's timely publication of protocol specifications, even with the
potential for flaws, likely had a significant effect in the eventual potential for flaws, likely had a significant effect in 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
skipping to change at page 5, line 41 skipping to change at page 6, line 10
implementations are important in ensuring the continued viability of implementations are important in ensuring the continued viability of
a protocol. New protocol implementations are also more likely to be a protocol. New protocol implementations are also more likely to be
developed for new and diverse use cases and often are the origin of developed for new and diverse use cases and often are the origin of
features and capabilities that can be of benefit to existing users. features and 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. For instance, an ability of established implementations to change. For instance, an
accumulation of mitigations for interoperability issues makes accumulation of mitigations for interoperability issues makes
implementations more difficult to maintain. implementations more difficult to maintain.
Sometimes what appear to be interoperability problems are symptomatic
of issues in protocol design. A community that is willing to make
changes to the protocol, by revising or extending it, makes the
protocol better in the process. Applying the robustness principle
might conceal the problem. That can make it harder, or even
impossible, to fix later.
A similar class of problems is described in RFC 5704 [UNCOORDINATED],
which addresses conflict or competition in the maintenance of
protocols. This document concerns itself primarily with the absence
of maintenance, though the problems are similar.
5. Active Protocol Maintenance 5. Active Protocol Maintenance
The robustness principle is best suited to safeguarding against flaws The robustness principle can be highly effective in safeguarding
in a specification that is intended to remain unchanged for an against flaws in the implementation of a protocol by peers.
extended period of time. Indeed, in the face of divergent Especially when a specification remains unchanged for an extended
interpretations of an immutable specification, the only hope for an period of time, the inclination to be tolerant accumulates over time.
implementation to remain interoperable is to be tolerant of Indeed, when faced with divergent interpretations of an immutable
differences in interpretation and an occasional outright specification, the best way for an implementation to remain
implementation error. interoperable is to be tolerant of differences in interpretation and
an occasional outright implementation error.
From this perspective, application of Postel's advice to the From this perspective, application of Postel's advice 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 suggests that the problem is with
the presumption of immutability of specifications. the assumption that the situation - existing specifications and
implementations - are unable to change.
Active maintenance of a protocol can ensure that specifications As already established, this is not a sustainable. For a protocol to
remain accurate and that new implementations are possible. Protocol be viable, it is necessary for both specifications and
designers are strongly encouraged to continue to maintain and evolve implementations to be responsive to changes, in addition to handling
protocols beyond their initial inception and definition. new and old problems that might arise over time.
Maintenance is needed in response to the discovery of errors in Active maintenance of a protocol is critical in ensuring that
specification that might cause interoperability issues. Maintenance specifications correctly reflect the requirements for
is also critical for ensuring that the protocol is viable for interoperability with existing implementations. Maintenance enables
application to use cases that might not have been envisaged during both new implementations and the continued improvement of the
its original design. New use cases are an indicator that the protocol. New use cases are an indicator that the protocol could be
protocol could be successful [SUCCESS]. successful [SUCCESS].
Maintenance does not necessarily involve the development of new Protocol designers are strongly encouraged to continue to maintain
versions of protocols or protocol specifications. For instance, RFC and evolve protocols beyond their initial inception and definition.
793 [TCP] remains the canonical TCP reference, but a large number of
update and extension RFCs together document the protocol as deployed.
Good extensibility [EXT] can make it easier to respond to new use Involvement of protocol implementers is a critical part of this
cases or changes in the environment in which the protocol is process, as they provide input on their experience with
deployed. implementation and deployment of the protocol.
Maintenance does not necessarily involve the development of new
versions of protocols or protocol specifications. For instance, the
most effective means of dealing with a defective implementation in a
peer is often to email the developer of the stack. It is far more
efficient in the long term to fix one isolated bug than it is to deal
with the consequences of workarounds.
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 currency took significant effort.
6. The Role of Feedback 6. Extensibility
Good extensibility [EXT] can make it easier to respond to new use
cases or changes in the environment in which the protocol is
deployed.
Extensibility is sometimes mistaken for an application of the
robustness principle. After all, if one party 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 tolerant of unexpected
inputs.
A well-designed extensibility mechanism establishes clear rules for
the handling of things like new messages or parameters. If an
extension mechanism is designed and implemented correctly, the user
of a new protocol feature can confidently predict the effect that
feature will have on existing implementations.
Relying on implementations consistently applying the robustness
principle is not a good strategy for extensibility. Using
undocumented or accidental features of a protocol as the basis of an
extensibility mechanism can be extremely difficult, as is
demonstrated by the case study in Appendix A.3 of [EXT].
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
example [HTML]). Specifying and implementing a more flexible
protocol is more difficult; allowing less variation is preferable in
the absence of strong reasons to be flexible.
7. The Role of Feedback
Protocol maintenance is only possible if there is sufficient Protocol maintenance is only possible if there is sufficient
information about the deployment of the protocol. Feedback from information about the deployment of the protocol. Feedback from
deployment is critical to effective protocol maintenance. deployment is critical to effective protocol maintenance.
For a protocol specification, the primary and most effective form of For a protocol specification, the primary and most effective form of
feedback comes from people who implement and deploy the protocol. feedback comes from people who implement and deploy the protocol.
This comes in the form of new requirements, or in experience with the This comes in the form of new requirements, or in experience with the
protocol as it is deployed. protocol as it is deployed.
Managing and deploying changes to implementations can be expensive. Managing and deploying changes to implementations can be expensive.
However, it is widely recognized that maintenance is a critical part However, it is widely recognized that regular updates are a vital
of the deployment of computer systems for security reasons [IOTSU]. part of the deployment of computer systems for security reasons (see
for example [IOTSU]).
6.1. Error Handling
Ideally, specifications include rules for consistent handling of
aberrant conditions as well as expected. This increases the changes
that implementations have interoperable handling of unusual
conditions.
Choosing to generate fatal error for unspecified conditions instead
of attempting error recovery can ensure that faults receive
attention. Fatal errors can provide excellent motivation to address
a problem if they are sufficiently rare.
A protocol could be designed to permit a narrow set of valid inputs,
or it could allow a wide range of inputs (see for example [HTML]).
Specifying and implementing a more flexible protocol is more
difficult, allowing less variation is preferable in the absence of
strong reasons to be flexible.
6.2. Feedback from Implementations 7.1. Feedback from Implementations
Automated error reporting mechanisms in protocol implementations Automated error reporting mechanisms in protocol implementations
allows for better feedback from deployments. Exposing faults through allows for better feedback from deployments. Exposing faults through
operations and management systems is highly valuable, but it might be operations and management systems is highly valuable, but it might be
necessary to ensure that the information is propagated further. necessary to ensure that the information is propagated further.
Building telemetry and error logging systems that report faults to Building telemetry and error logging systems that report faults to
the developers of the implementation is superior in many respects. the developers of the implementation is superior in many respects.
However, this is only possible in deployments that are conducive to However, this is only possible in deployments that are conducive to
the collection of this type of information. Giving consideration to the collection of this type of information. Giving due consideration
protection of the privacy of protocol participants is critical prior to protection of the privacy of protocol participants is critical
to deploying any such system. prior to deploying any such system.
7. Security Considerations 7.2. Virtuous Intolerance
A well-specified protocol includes rules for consistent handling of
aberrant conditions. This increases the changes that implementations
have interoperable handling of unusual conditions.
Intolerance of any deviation from specification, where
implementations generate fatal errors in response to observing
undefined or unusal behaviour, can be harnessed to reduce occurrences
of abherrent implementations. Choosing to generate fatal error for
unspecified conditions instead of attempting error recovery can
ensure that faults receive attention.
This improves feedback for new implementations in particular. When a
new implementation encounters a virtuously intolerant implementation,
it receives strong feedback that allows problems to be discovered
quickly.
To be effective, virtuously intolerant implementations need to be
sufficiently widely deployed that they are encountered by new
implementations with high probability. This could depend on multiple
implementations of the same strict checks. Any intolerance also
needs to be strongly supported by specifications, otherwise they
encourage fracturing of the protocol community or proliferation of
workarounds.
Virtuous intolerance can be used to motivate compliance with any
protocol requirement. For instance, the INADEQUATE_SECURITY error
code and associated requirements in HTTP/2 [HTTP2] resulted in
improvements in the security of the deployed base.
8. 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.
8. IANA Considerations The consequences of the problems described in this document are
especially acute for any protocol where security depends on agreement
about semantics of protocol elements.
9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Informative References 10. Informative References
[ECMA262] "ECMAScript(R) 2017 Language Specification", ECMA-262 8th [ECMA262] "ECMAScript(R) 2017 Language Specification", ECMA-262 8th
Edition, June 2017, <http://www.ecma- Edition, June 2017, <http://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/info/rfc6709>.
skipping to change at page 8, line 33 skipping to change at page 10, line 13
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[HTML] "HTML", WHATWG Living Standard, October 2017, [HTML] "HTML", WHATWG Living Standard, October 2017,
<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/info/rfc7230>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/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/info/rfc7493>.
[IOTSU] Tschofenig, H. and S. Farrell, "Report from the Internet [IOTSU] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016", of Things Software Update (IoTSU) Workshop 2016",
RFC 8240, DOI 10.17487/RFC8240, September 2017, RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
[IP] Postel, J., "DoD standard Internet Protocol", RFC 760, [IP] Postel, J., "DoD standard Internet Protocol", RFC 760,
skipping to change at page 9, line 19 skipping to change at page 11, line 5
[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/info/rfc1958>.
[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/info/rfc5218>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[UNCOORDINATED]
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/info/rfc5704>.
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 Mark Nottingham, Brian surprising number of people including Bernard Aboba, Brian Carpenter,
Trammell, and Anne Van Kesteren. Please excuse any omission. Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks,
Brian Trammell, and Anne Van Kesteren. Please excuse any omission.
Author's Address Author's Address
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
 End of changes. 29 change blocks. 
97 lines changed or deleted 186 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/