idnits 2.17.1 draft-iab-protocol-maintenance-07.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 (1 June 2022) is 667 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EDM M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational D. Schinazi 5 Expires: 3 December 2022 Google LLC 6 1 June 2022 8 The Harmful Consequences of the Robustness Principle 9 draft-iab-protocol-maintenance-07 11 Abstract 13 The robustness principle, often phrased as "be conservative in what 14 you send, and liberal in what you accept", has long guided the design 15 and implementation of Internet protocols. The posture this statement 16 advocates promotes interoperability in the short term, but can 17 negatively affect the protocol ecosystem over time. For a protocol 18 that is actively maintained, the robustness principle can, and 19 should, be avoided. 21 About This Document 23 This note is to be removed before publishing as an RFC. 25 The latest revision of this draft can be found at 26 https://intarchboard.github.io/draft-protocol-maintenance/draft-iab- 27 protocol-maintenance.html. Status information for this document may 28 be found at https://datatracker.ietf.org/doc/draft-iab-protocol- 29 maintenance/. 31 Discussion of this document takes place on the EDM IAB Program 32 mailing list (mailto:edm@iab.org), which is archived at 33 https://www.iab.org/mailman/listinfo/edm. 35 Source for this draft and an issue tracker can be found at 36 https://github.com/intarchboard/draft-protocol-maintenance. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 3 December 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 4 70 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 7 73 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 9 75 8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 11. Informative References . . . . . . . . . . . . . . . . . . . 11 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The robustness principle has been hugely influential in shaping the 85 design of the Internet. As stated in the IAB document on 86 Architectural Principles of the Internet [RFC1958], the robustness 87 principle advises to: 89 Be strict when sending and tolerant when receiving. 90 Implementations must follow specifications precisely when sending 91 to the network, and tolerate faulty input from the network. When 92 in doubt, discard faulty input silently, without returning an 93 error message unless this is required by the specification. 95 This simple statement captures a significant concept in the design of 96 interoperable systems. Many consider the application of the 97 robustness principle to be instrumental in the success of the 98 Internet as well as the design of interoperable protocols in general. 100 Time and experience shows that negative consequences to 101 interoperability accumulate over time if implementations apply the 102 robustness principle. This problem originates from an assumption 103 implicit in the principle that it is not possible to effect change in 104 a system the size of the Internet. It assumes that once a protocol 105 specification is published, changes that might require existing 106 implementations to change are not feasible. 108 Many problems that the robustness principle was intended to solve can 109 instead be better addressed by active maintenance. Active protocol 110 maintenance is where a community of protocol designers, implementers, 111 and deployers work together to continuously improve and evolve 112 protocol specifications alongside implementations and deployments of 113 those protocols. A community that takes an active role in the 114 maintenance of protocols will no longer need to rely on the 115 robustness principle to avoid interoperability issues. 117 There is good evidence to suggest that many important protocols are 118 routinely maintained beyond their inception. In particular, a 119 sizeable proportion of IETF activity is dedicated to the stewardship 120 of existing protocols. This document serves primarily as a record of 121 the hazards in applying the robustness principle too broadly, and 122 offers an alternative strategy for handling interoperability problems 123 in deployments. 125 Ideally, protocol implementations can be actively maintained and 126 never have to apply the robustness principle. The robustness 127 principle may still need to used as a short-term mitigation for 128 deployments that cannot yet be easily updated and do not yet have 129 documented specifications for workarounds, but such cases need not be 130 permanent. This is discussed further in Section 5. 132 Avoiding use of the robustness principle does not mean that 133 implementations will be inflexible to new input. As discussed in 134 Section 6, the flexibility to handle future extensions is better 135 supported by specifications being very clear about their extension 136 mechanisms, and implementations being strict in following the 137 requirements of those specifications. 139 2. Fallibility of Specifications 141 The context from which the robustness principle was developed 142 provides valuable insights into its intent and purpose. The earliest 143 form of the principle in the RFC series (the Internet Protocol 144 specification [RFC0760]) is preceded by a sentence that reveals the 145 motivation for the principle: 147 While the goal of this specification is to be explicit about the 148 protocol there is the possibility of differing interpretations. 149 In general, an implementation should be conservative in its 150 sending behavior, and liberal in its receiving behavior. 152 This formulation of the principle expressly recognizes the 153 possibility that the specification could be imperfect. This 154 contextualizes the principle in an important way. 156 Imperfect specifications are unavoidable, largely because it is more 157 important to proceed to implementation and deployment than it is to 158 perfect a specification. A protocol benefits greatly from experience 159 with its use. A deployed protocol is immeasurably more useful than a 160 perfect protocol specification. This is particularly true in early 161 phases of system design, to which the robustness principle is best 162 suited. 164 As demonstrated by the IAB document on Successful Protocols 165 [RFC5218], success or failure of a protocol depends far more on 166 factors like usefulness than on technical excellence. Timely 167 publication of protocol specifications, even with the potential for 168 flaws, likely contributed significantly to the eventual success of 169 the Internet. 171 This premise that specifications will be imperfect is correct -- 172 however, the robustness principle is almost always the incorrect 173 solution to the problem. 175 3. Protocol Decay 177 The application of the robustness principle to any system that is in 178 early phases of deployment, such as the early Internet, is expedient. 179 Applying the principle defers the effort of dealing with 180 interoperability problems and prioritizes progress. However, this 181 deferral can amplify the ultimate cost of handling interoperability 182 problems. 184 Divergent implementations of a specification emerge over time. When 185 variations occur in the interpretation or expression of semantic 186 components, implementations cease to be perfectly interoperable. 188 Implementation bugs are often identified as the cause of variation, 189 though it is often a combination of factors. Using a protocol in 190 ways that were not anticipated in the original design, or ambiguities 191 and errors in the specification are often contributing factors. 192 Disagreements on the interpretation of specifications should be 193 expected over the lifetime of a protocol. 195 Even with the best intentions to maintain protocol correctness, the 196 pressure to interoperate can be significant. No implementation can 197 hope to avoid having to trade correctness for interoperability 198 indefinitely. 200 An implementation that reacts to variations in the manner recommended 201 in the robustness principle enters a pathological feedback cycle. 202 Over time: 204 * Implementations progressively add logic to constrain how data is 205 transmitted, or to permit variations in what is received. 207 * Errors in implementations or confusion about semantics are 208 permitted or ignored. 210 * These errors can become entrenched, forcing other implementations 211 to be tolerant of those errors. 213 A flaw can become entrenched as a de facto standard. Any 214 implementation of the protocol is required to replicate the aberrant 215 behavior, or it is not interoperable. This is both a consequence of 216 applying the robustness principle, and a product of a natural 217 reluctance to avoid fatal error conditions. Ensuring 218 interoperability in this environment is often referred to as aiming 219 to be "bug for bug compatible". 221 For example, in TLS [TLS], extensions use a tag-length-value format 222 and can be added to messages in any order. However, some server 223 implementations terminated connections if they encountered a TLS 224 ClientHello message that ends with an empty extension. To maintain 225 interoperability, client implementations were required to be aware of 226 this bug and ensure that a ClientHello message ends in a non-empty 227 extension. 229 The original JSON specification [RFC4627] demonstrates the effect of 230 specification shortcomings: it did not tightly specify some important 231 details including Unicode handling, ordering and duplication of 232 object members, and number encoding. Consequently, a range of 233 interpretations were used by implementations. An updated JSON 234 specification [RFC7159] did not correct these errors, concentrating 235 instead on identifying the interoperable subset of JSON. I-JSON 237 [RFC7493] takes that subset and defines a new format that prohibits 238 the problematic parts of JSON. Of course, that means that I-JSON is 239 not fully interoperable with JSON. Consequently, I-JSON is not 240 widely implemented in parsers. Many JSON parsers now implement the 241 more precise algorithm specified in [ECMA262]. 243 The robustness principle therefore encourages a chain reaction that 244 can create interoperability problems over time. In particular, the 245 application of the robustness principle is particularly deleterious 246 for early implementations of new protocols as quirks in early 247 implementations can affect all subsequent deployments. 249 4. Ecosystem Effects 251 From observing widely deployed protocols, it appears there are two 252 stable points on the spectrum between being strict versus permissive 253 in the presence of protocol errors: 255 * If implementations predominantly enforce strict compliance with 256 specifications, newer implementations will experience failures if 257 they do not comply with protocol requirements. Newer 258 implementations need to fix compliance issues in order to be 259 successfully deployed. This ensures that most deployments are 260 compliant. 262 * Conversely, if non-compliance is tolerated by existing 263 implementations, non-compliant implementations can be deployed 264 successfully. Newer implementations then have strong incentive to 265 tolerate any existing non-compliance in order to be successfully 266 deployed. This ensures that most deployments are tolerant of the 267 same non-compliant behavior. 269 This happens because interoperability requirements for protocol 270 implementations are set by other deployments. Specifications and - 271 where they exist - conformance test suites might guide the initial 272 development of implementations, but implementations ultimately need 273 to interoperate with deployed implementations. 275 For widely used protocols, the massive scale of the Internet makes 276 large-scale interoperability testing infeasible for all but a 277 privileged few. The cost of building a new implementation using 278 reverse engineering increases as the number of implementations and 279 bugs increases. Worse, the set of tweaks necessary for wide 280 interoperability can be difficult to discover. In the worst case, a 281 new implementer might have to choose between deployments that have 282 diverged so far as to no longer be interoperable. 284 Consequently, new implementations might be forced into niche uses, 285 where the problems arising from interoperability issues can be more 286 closely managed. However, restricting new implementations into 287 limited deployments risks causing forks in the protocol. If 288 implementations do not interoperate, little prevents those 289 implementations from diverging more over time. 291 This has a negative impact on the ecosystem of a protocol. New 292 implementations are key to the continued viability of a protocol. 293 New protocol implementations are also more likely to be developed for 294 new and diverse use cases and are often the origin of features and 295 capabilities that can be of benefit to existing users. 297 The need to work around interoperability problems also reduces the 298 ability of established implementations to change. An accumulation of 299 mitigations for interoperability issues makes implementations more 300 difficult to maintain and can constrain extensibility (see also the 301 IAB document on the Long-Term Viability of Protocol Extension 302 Mechanisms [RFC9170]). 304 Sometimes what appear to be interoperability problems are symptomatic 305 of issues in protocol design. A community that is willing to make 306 changes to the protocol, by revising or extending it, makes the 307 protocol better in the process. Applying the robustness principle 308 instead conceals problems, making it harder, or even impossible, to 309 fix them later. 311 5. Active Protocol Maintenance 313 The robustness principle can be highly effective in safeguarding 314 against flaws in the implementation of a protocol by peers. 315 Especially when a specification remains unchanged for an extended 316 period of time, incentive to be tolerant of errors accumulates over 317 time. Indeed, when faced with divergent interpretations of an 318 immutable specification, the only way for an implementation to remain 319 interoperable is to be tolerant of differences in interpretation and 320 implementation errors. 322 From this perspective, application of the robustness principle to the 323 implementation of a protocol specification that does not change is 324 logical, even necessary. But that conclusion relies on an assumption 325 that existing specifications and implementations cannot change. 326 Applying the robustness principle in this way disproportionately 327 values short-term gains over the negative effects on future 328 implementations and the protocol as a whole. 330 For a protocol to have sustained viability, it is necessary for both 331 specifications and implementations to be responsive to changes, in 332 addition to handling new and old problems that might arise over time. 334 Maintaining specifications so that they closely match deployments 335 ensures that implementations are consistently interoperable and 336 removes needless barriers for new implementations. Maintenance also 337 enables continued improvement of the protocol. New use cases are an 338 indicator that the protocol could be successful [RFC5218]. 340 Protocol designers are strongly encouraged to continue to maintain 341 and evolve protocol specifications beyond their initial inception and 342 definition. This might require the development of revised 343 specifications, extensions, or other supporting material that 344 documents the current state of the protocol. Involvement of those 345 who implement and deploy the protocol is a critical part of this 346 process, as they provide input on their experience with how the 347 protocol is used. 349 Most interoperability problems do not require revision of protocols 350 or protocol specifications. For instance, the most effective means 351 of dealing with a defective implementation in a peer could be to 352 contact the developer responsible. It is far more efficient in the 353 long term to fix one isolated bug than it is to deal with the 354 consequences of workarounds. 356 Early implementations of protocols have a stronger obligation to 357 closely follow specifications as their behavior will affect all 358 subsequent implementations. In addition to specifications, later 359 implementations will be guided by what existing deployments accept. 360 Tolerance of errors in early deployments is most likely to result in 361 problems. Protocol specifications might need more frequent revision 362 during early deployments to capture feedback from early rounds of 363 deployment. 365 Neglect can quickly produce the negative consequences this document 366 describes. Restoring the protocol to a state where it can be 367 maintained involves first discovering the properties of the protocol 368 as it is deployed, rather than the protocol as it was originally 369 documented. This can be difficult and time-consuming, particularly 370 if the protocol has a diverse set of implementations. Such a process 371 was undertaken for HTTP [HTTP] after a period of minimal maintenance. 372 Restoring HTTP specifications to relevance took significant effort. 374 Maintenance is most effective if it is responsive, which is greatly 375 affected by how rapidly protocol changes can be deployed. For 376 protocol deployments that operate on longer time scales, temporary 377 workarounds following the spirit of the robustness principle might be 378 necessary. For this, improvements in software update mechanisms 379 ensure that the cost of reacting to changes is much lower than it was 380 in the past. Alternatively, if specifications can be updated more 381 readily than deployments, details of the workaround can be 382 documented, including the desired form of the protocols once the need 383 for workarounds no longer exists and plans for removing the 384 workaround. 386 6. Extensibility 388 Good extensibility [EXT] can make it easier to respond to new use 389 cases or changes in the environment in which the protocol is 390 deployed. 392 The ability to extend a protocol is sometimes mistaken for an 393 application of the robustness principle. After all, if one party 394 wants to start using a new feature before another party is prepared 395 to receive it, it might be assumed that the receiving party is being 396 tolerant of unexpected inputs. 398 A well-designed extensibility mechanism establishes clear rules for 399 the handling of things like new messages or parameters. This depends 400 on precisely specifying the handling of malformed or illegal inputs 401 so that implementations behave consistently in all cases that might 402 affect interoperation. If extension mechanisms and error handling 403 are designed and implemented correctly, new protocol features can be 404 deployed with confidence in the understanding of the effect they have 405 on existing implementations. 407 In contrast, relying on implementations to consistently apply the 408 robustness principle is not a good strategy for extensibility. Using 409 undocumented or accidental features of a protocol as the basis of an 410 extensibility mechanism can be extremely difficult, as is 411 demonstrated by the case study in Appendix A.3 of [EXT]. 413 A protocol could be designed to permit a narrow set of valid inputs, 414 or it could allow a wide range of inputs as a core feature (see for 415 example [HTML]). Specifying and implementing a more flexible 416 protocol is more difficult; allowing less variability is preferable 417 in the absence of strong reasons to be flexible. 419 7. Virtuous Intolerance 421 A well-specified protocol includes rules for consistent handling of 422 aberrant conditions. This increases the chances that implementations 423 will have consistent and interoperable handling of unusual 424 conditions. 426 Choosing to generate fatal errors for unspecified conditions instead 427 of attempting error recovery can ensure that faults receive 428 attention. This intolerance can be harnessed to reduce occurrences 429 of aberrant implementations. 431 Intolerance toward violations of specification improves feedback for 432 new implementations in particular. When a new implementation 433 encounters a peer that is intolerant of an error, it receives strong 434 feedback that allows the problem to be discovered quickly. 436 To be effective, intolerant implementations need to be sufficiently 437 widely deployed that they are encountered by new implementations with 438 high probability. This could depend on multiple implementations 439 deploying strict checks. 441 This does not mean that intolerance of errors in early deployments of 442 protocols has the effect of preventing interoperability. On the 443 contrary, when existing implementations follow clearly-specified 444 error handling, new implementations or features can be introduced 445 more readily as the effect on existing implementations can be easily 446 predicted; see also Section 6. 448 Any intolerance also needs to be strongly supported by 449 specifications, otherwise they encourage fracturing of the protocol 450 community or proliferation of workarounds; see Section 8. 452 Intolerance can be used to motivate compliance with any protocol 453 requirement. For instance, the INADEQUATE_SECURITY error code and 454 associated requirements in HTTP/2 [HTTP/2] resulted in improvements 455 in the security of the deployed base. 457 8. Exclusion 459 Any protocol participant that is affected by changes arising from 460 maintenance might be excluded if they are unwilling or unable to 461 implement or deploy changes that are made to the protocol. 463 Deliberate exclusion of problematic implementations is an important 464 tool that can ensure that the interoperability of a protocol remains 465 viable. While compatible changes are always preferable to 466 incompatible ones, it is not always possible to produce a design that 467 protects the ability of all current and future protocol participants 468 to interoperate. Developing and deploying changes that risk 469 exclusion of previously interoperating implementations requires some 470 care, but changes to a protocol should not be blocked on the grounds 471 of the risk of exclusion alone. 473 Exclusion is a direct goal when choosing to be intolerant of errors 474 (see Section 7). Exclusionary actions are employed with the 475 deliberate intent of protecting future interoperability. 477 Excluding implementations or deployments can lead to a fracturing of 478 the protocol system that could be more harmful than any divergence 479 resulting from following the robustness principle. The IAB document 480 on Uncoordinated Protocol Development Considered Harmful [RFC5704] 481 describes how conflict or competition in the maintenance of protocols 482 can lead to similar problems. 484 9. Security Considerations 486 Sloppy implementations, lax interpretations of specifications, and 487 uncoordinated extrapolation of requirements to cover gaps in 488 specification can result in security problems. Hiding the 489 consequences of protocol variations encourages the hiding of issues, 490 which can conceal bugs and make them difficult to discover. 492 The consequences of the problems described in this document are 493 especially acute for any protocol where security depends on agreement 494 about semantics of protocol elements. For instance, use of unsafe 495 security mechanisms, such as weak primitives [MD5] or obsolete 496 mechanisms [SSL3], are good examples of where forcing exclusion 497 (Section 8) can be desirable. 499 10. IANA Considerations 501 This document has no IANA actions. 503 11. Informative References 505 [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th 506 Edition, June 2018, . 509 [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 510 Considerations for Protocol Extensions", RFC 6709, 511 DOI 10.17487/RFC6709, September 2012, 512 . 514 [HTML] "HTML", WHATWG Living Standard, 8 March 2019, 515 . 517 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 518 Protocol (HTTP/1.1): Message Syntax and Routing", 519 RFC 7230, DOI 10.17487/RFC7230, June 2014, 520 . 522 [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 523 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 524 DOI 10.17487/RFC7540, May 2015, 525 . 527 [MD5] Turner, S. and L. Chen, "Updated Security Considerations 528 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 529 RFC 6151, DOI 10.17487/RFC6151, March 2011, 530 . 532 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, 533 DOI 10.17487/RFC0760, January 1980, 534 . 536 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 537 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 538 . 540 [RFC4627] Crockford, D., "The application/json Media Type for 541 JavaScript Object Notation (JSON)", RFC 4627, 542 DOI 10.17487/RFC4627, July 2006, 543 . 545 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 546 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 547 . 549 [RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 550 Protocol Development Considered Harmful", RFC 5704, 551 DOI 10.17487/RFC5704, November 2009, 552 . 554 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 555 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 556 2014, . 558 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 559 DOI 10.17487/RFC7493, March 2015, 560 . 562 [RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol 563 Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, 564 December 2021, . 566 [SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 567 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 568 DOI 10.17487/RFC7568, June 2015, 569 . 571 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 572 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 573 . 575 Acknowledgments 577 Constructive feedback on this document has been provided by a 578 surprising number of people including Bernard Aboba, Brian Carpenter, 579 Stuart Cheshire, Mark Nottingham, Russ Housley, Eric Rescorla, 580 Henning Schulzrinne, Robert Sparks, Brian Trammell, and Anne Van 581 Kesteren. Please excuse any omission. 583 Authors' Addresses 585 Martin Thomson 586 Mozilla 587 Email: mt@lowentropy.net 589 David Schinazi 590 Google LLC 591 1600 Amphitheatre Parkway 592 Mountain View, CA 94043 593 United States of America 594 Email: dschinazi.ietf@gmail.com