idnits 2.17.1 draft-thomson-postel-was-wrong-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational March 9, 2015 5 Expires: September 10, 2015 7 The Harmful Consequences of Postel's Maxim 8 draft-thomson-postel-was-wrong-00 10 Abstract 12 Jon Postel's famous statement in RFC 1122 of "Be liberal in what you 13 accept, and conservative in what you send" - is a principle that has 14 long guided the design of Internet protocols and implementations of 15 those protocols. The posture this statement advocates might promote 16 interoperability in the short term, but that short term advantage is 17 outweighed by negative consequences that affect the long term 18 maintenance of a protocol and its ecosystem. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 10, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. The Protocol Decay Hypothesis . . . . . . . . . . . . . . . . 3 56 3. The Long Term Costs . . . . . . . . . . . . . . . . . . . . . 4 57 4. A New Design Principle . . . . . . . . . . . . . . . . . . . 4 58 4.1. Fail Fast and Hard . . . . . . . . . . . . . . . . . . . 5 59 4.2. Implementations Are Ultimately Responsible . . . . . . . 5 60 4.3. Protocol Maintenance is Important . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Of the great many contributions Jon Postel made to the Internet, his 69 remarkable technical achievements are often ignored in favor of the 70 design and implementation philosophy that he first captured in the 71 original IPv4 specification [RFC0760]: 73 In general, an implementation should be conservative in its 74 sending behavior, and liberal in its receiving behavior. 76 In comparison, his contributions to the underpinnings of the 77 Internet, which are in many respects more significant, enjoy less 78 conscious recognition. Postel's principle has been hugely 79 influential in shaping the Internet and the systems that use Internet 80 protocols. Many consider this principle to be instrumental in the 81 success of the Internet as well as the design of interoperable 82 protocols in general. 84 Over time, considerable changes have occurred in both the scale of 85 the Internet and the level of skill and experience available to 86 protocol and software designers. Part of that experience is with 87 protocols that were designed, informed by Postel's maxim, in the 88 early phases of the Internet. 90 That experience shows that there are negative long-term consequences 91 to interoperability if an implementation applies Postel's advice. 92 Correcting the problems caused by divergent behavior in 93 implementations can be difficult or impossible. 95 It might be suggested that the posture Postel advocates was indeed 96 necessary during the formative years of the Internet, and even key to 97 its success. This document takes no position on that claim. 99 This document instead describes the negative consequences of the 100 application of Postel's principle to the modern Internet. A 101 replacement design principle is suggested. 103 There is good evidence to suggest that designers of protocols in the 104 IETF widely understand the limitations of Postel's principle. This 105 document serves primarily as a record of the shortcomings of His 106 principle for the wider community. 108 2. The Protocol Decay Hypothesis 110 Divergent implementations of a specification emerge over time. When 111 variations occur in the interpretation or expression of semantic 112 components, implementations cease to be perfectly interoperable. 114 Implementation bugs are often identified as the cause of variation, 115 though it is often a combination of factors. Application of a 116 protocol to new and unanticipated uses, and ambiguities or errors in 117 the specification are often confounding factors. 119 Of course, situations where two peers disagree are common, and should 120 be expected over the lifetime of a protocol. Even with the best 121 intentions, the pressure to interoperate can be significant. No 122 implementation can hope to avoid having to trade correctness for 123 interoperability indefinitely. 125 An implementation that reacts to variations in the manner advised by 126 Postel sets up a feedback cycle: 128 o Over time, implementations progressively add new code to constrain 129 how data is transmitted, or to permit variations what is received. 131 o Errors in implementations, or confusion about semantics can 132 thereby be masked. 134 o As a result, errors can become entrenched, forcing other 135 implementations to be tolerant of those errors. 137 An entrenched flaw can become a de facto standard. Any 138 implementation of the protocol is required to replicate the aberrant 139 behavior, or it is not interoperable. This is both a consequence of 140 applying Postel's advice, and a product of a natural reluctance to 141 avoid fatal error conditions. This is colloquially referred to as 142 being "bug for bug compatible". 144 It is debatable as to whether such a process can be completely 145 avoided, but Postel's maxim encourages a reaction that compounds this 146 issue. 148 3. The Long Term Costs 150 Once deviations become entrenched, there is little that can be done 151 to rectify the situation. 153 For widely used protocols, the massive scale of the Internet makes 154 large scale interoperability testing infeasible for all a privileged 155 few. Without good maintenance, new implementations can be restricted 156 to niche uses, where the prolems arising from interoperability issues 157 can be more closely managed. 159 This has a negative impact on the ecosystem of a protocol. New 160 implementations of a protocol are important in ensuring the continued 161 viability of a protocol. New protocol implementations are also more 162 likely to be developed for new and diverse use cases and often are 163 the origin of features and capabilities that can be of benefit to 164 existing users. These problems also reduce the ability of 165 established implementations to change. 167 Protocol maintenance can help by carefully documenting divergence and 168 recommending limits on what is both acceptable and interoperable. 169 The time-consuming process of documenting the actual protocol - 170 rather than the protocol as it was originally conceived - can restore 171 the ability to create and maintain interoperable implementations. 173 Such a process was undertaken for HTTP/1.1 [RFC7230]. This this 174 effort took more than 6 years, it has been successful in documenting 175 protocol variations and describing what has over time become a far 176 more complex protocol. 178 4. A New Design Principle 180 The following principle applies not just to the implementation of a 181 protocol, but to the design and specification of the protocol. 183 Protocol designs and implementations should be maximally strict. 185 Though less pithy than Postel's formulation, this principle is based 186 on the lessons of protocol deployment. The principle is also based 187 on valuing early feedback, a practice central to modern engineering 188 discipline. 190 4.1. Fail Fast and Hard 192 Protocols need to include error reporting mechanisms that ensure 193 errors are surfaced in a visible and expedient fashion. 195 Generating fatal errors for what would otherwise be a minor or 196 recoverable error is preferred, especially if there is any risk that 197 the error represents an implementation flaw. A fatal error provides 198 excellent motivation for addressing problems. 200 On the whole, implementations already have ample motivation to prefer 201 interoperability over correctness. The primary function of a 202 specification is to proscribe behavior in the interest of 203 interoperability. 205 4.2. Implementations Are Ultimately Responsible 207 Implementers are encouraged to expose errors immediately and 208 prominently in addition to what a specification mandates. 210 Exposing errors is particularly important for early implementations 211 of a protocol. If preexisting implementations generate errors in 212 response to divergent behaviour, then new implementations will be 213 able to detect and correct flaws quickly. 215 An implementer that discovers a scenario that is not covered by the 216 specification does the community a greater service by generating a 217 fatal error than by attempted to interpret and adapt. Hiding errors 218 can cause long-term problems. Ideally, specification shortcomings 219 are taken to protocol maintainers. 221 Unreasoning strictness can be detrimental. Protocol designers and 222 implementers expected to exercise judgment in determining what level 223 of strictness is ultimately appropriate. In every case, documenting 224 the decision to deviate from what is specified can avoid later 225 issues. 227 4.3. Protocol Maintenance is Important 229 Protocol designers are strongly encouraged to continue to maintain 230 and evolve protocols beyond their initial inception and definition. 231 If protocol implementations are less tolerant of variation, protocol 232 maintenance becomes critical. Good extensibility [RFC6709] can 233 relieve some of the pressure on maintenance. 235 5. IANA Considerations 237 This document has no IANA actions. 239 6. Security Considerations 241 Sloppy implementations, lax interpretations of specifications, and 242 uncoordinated extrapolation of requirements to cover gaps in 243 specification can result in security problems. Hiding the 244 consequences of protocol variations encourages the hiding of issues, 245 which can conceal bugs and make them difficult to discover. 247 Designers and implementers of security protocols generally understand 248 these concerns. However, general-purpose protocols are not exempt 249 from careful consideration of security issues. Furthermore, because 250 general-purpose protocols tend to deal with flaws or obsolescence in 251 a less urgent fashion than security protocols, there can be fewer 252 opportunities to correct problems in protocols that develop 253 interoperability problems. 255 7. Informative References 257 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, 258 January 1980. 260 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 261 Considerations for Protocol Extensions", RFC 6709, 262 September 2012. 264 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 265 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 266 2014. 268 Author's Address 270 Martin Thomson 271 Mozilla 273 Email: martin.thomson@gmail.com