Internet Engineering Task Force Jacob Palme INTERNET-DRAFT Stockholm University Expires: December, 2005 Royal Institute of Technology Informational 7 June 2005 The IETF Golden Rules draft-palme-golden-rules-00.txt 1. Abstract This memo presents the following rules, which to some extend can be regarded as the golden rules of IETF, even though there are exceptions when these rules should not be adhered to. - Be liberal in what you accept, and conservative in what you send - Do not munge forwarded data - Modify as late as possible - Cause no harm - Leave nothing undefined - Keep it simple, stupid - No voting, rough consensus - Plain ASCII text is enough 2. IPR Statement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Copyright (C) The Internet Society (2005). This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on 7 December 2005. 3. Table of contents 1. Abstract 1 2. IPR Statement 1 3. Table of contents 2 4. Mailing list and web area 3 5. Introduction 3 6. Rule one: Be liberal in what you accept, and conservative in what you send 3 7. Rule two: Do not munge forwarded data 6 8. Rule three: Modify as late as possible 7 9. Rule four: Leave nothing undefined 8 10. Rule five: Cause no harm 8 11. Rule six: Keep it simple, stupid 8 12. Rule seven: No voting, rough consensus 9 13. Rule eight: Plain ASCII text is enough 10 14. Contradiction between the rules 11 15. Other documents 11 16. References 12 17. Acknowledgements 12 18. Author's address 12 19. Intellectual Property Statement 12 20. Full Copyright Statement 13 4. Mailing list and web area Comments and discussion on this MEMO can be sent to the ietf-golden@dsv.su.se mailing list. More information about this list, as well as information how to subscribe, unsubscribe and view the archives of the list, can be found at http://lists.dsv.su.se/cgi-bin/mailman/listinfo/ietf-golden The latest version of this memo can be found at http://dsv.su.se/jpalme/ietf/golden-rule/. 5. Introduction The Internet Engineering Task Force (IETF) is the largest and most successful standards organization in the area of Internet protocols. The success of IETF, as compared to other standards making organization, depends on its written and unwritten rules. This memo summarizes some of the most important of these rules. The rules are not carved in stone, there are cases where the IETF itself has chosen to partially break these rules. Still, some of these rules are important and need to be written down. This memo presents the rules in a rough priority order, with the most important rule first. For each rule, some explanation is given, as well as some examples of how it has been used. 6. Rule one: Be liberal in what you accept, and conservative in what you send This is the oldest, most wellknown and most important of the rules. It is usually attributed to [RFC1123]. Below is a direct quote of the text in [RFC1123] which explains this rule: At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: "Be liberal in what you accept, and conservative in what you send" Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course! Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure. The second part of the principle is almost as important: software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is "watch out for misbehaving hosts"; host software should be prepared, not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility. One could interpret this rule to mean that there are actually three versions of each standard: (1) The actual standard as specified in the standards specification. (2) What good implementers should accept, and which is a superset of (1). (3) What good implementers should produce, and which is a subset of (1). This is shown in this figure: +-------------------------------------------+ | (2) What you should accept | | +-------------------------------------+ | | | (1) The actual standard | | | | +-------------------------------+ | | | | | (3) What you should produce | | | | | +-------------------------------+ | | | +-------------------------------------+ | +-------------------------------------------+ But if there are in reality three standards, would it not be better if the standards document described all three of them? Well, this would make the standards documents much larger. However, it is more and more common that standards especially specify, at least in some cases, the difference between each standard, for example by saying that certain functions are deprecated or obsolete. Functions marked as deprecated or obsolete belong to category (2) above, what you should accept but not produce. Example, quote from [RFC2068], the HTTP standard: The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient. This text thus says that it is allowed to send a text with HTTP without a character set indication, but that it MAY be good to include a character set indication, even when it has the default value ISO-8859-1. A good (conservative) implementation should thus always indicate the character set, even though it is not mandatory. It is unfortunate that the HTTP standard says that when no character set is specified, the default is ISO-8859-1, while the e-mail standards say that when no character set is specified, the default is plain ASCII. This discrepancy between two mayor standards has caused lots of confusion and incorrect implementations. The robustness rule quoted above says that it is good practice to always identify the character set of HTTP-transmitted text, even though this is formally optional. The e-mail standard [RFC2046] says: The default character set, US-ASCII, has been the subject of some confusion and ambiguity in the past. Not only were there some ambiguities in the definition, there have been wide variations in practice. In order to eliminate such ambiguity and variations in the future, it is strongly recommended that new user agents explicitly specify a character set as a media type parameter in the Content-Type header field. "US-ASCII" does not indicate an arbitrary 7-bit character set, but specifies that all octets in the body must be interpreted as characters according to the US-ASCII character set. National and application-oriented versions of ISO 646 [ISO-646] are usually NOT identical to US-ASCII, and in that case their use in Internet mail is explicitly discouraged. The omission of the ISO 646 character set from this document is deliberate in this regard. The character set name of "US-ASCII" explicitly refers to the character set defined in ANSI X3.4-1986 [US-ASCII]. The new international reference version (IRV) of the 1991 edition of ISO 646 is identical to US-ASCII. The character set name "ASCII" is reserved and must not be used for any purpose. Note that again, the standard says that the Character-set attribute is not mandatory, but good (conservative) implementations should always specify it for textual body parts in e-mail. Both e-mail and HTTP standards does say that this attribute is optional but should be used in what you produce. One of the most comprehensive explicit specification of the difference between the recommended and the allowed standard is the e-mail body format standard, [RFC2822]. This standard has a special chapter 4, with the title "Obsolete syntax". This chapter goes into great detail in specifying everything a good implementation should accept, but not produce. Probably, such explicit specification of what a good implementation should accept but not produce will occur in the future. When a standard grows old, the experience on how to interpret the liberal-conservative rule increases. Note: By "produce" in Rule one is meant new data which an agent produces. It does normally not apply to data which an agent receives and forwards. For such data, instead, the "Rule two: Do not munge forwarded data" below applies. 7. Rule two: Do not munge forwarded data It may seem natural for an implementer, when receiving incorrect data, to correct it before sending it further. Such corrections of incorrect data is in IETF vocabulary called "munging", and it is in general disapproved. The reason for this is that long experience has shown that attempts to correct incorrect data will usually cause more confusion than keeping it as it is. This might be seen as a contraction to the liberal-conservative rule, but it is not, since the liberal-conservative rule talks about what you produce, not about what you forward. A commonly occuring case where implementers wrongly do not adhere to "Rule two: Do not munge" is certain mail systems which when it receives a message converts it to an internal format. When the same message is then sent out again, it is converted back again to standard format. The correct behaviour of such systems is that even if they need to convert the message to an internal format to be able to handle it locally, they should keep a copy of the original message before conversion, and use this when sending it out again. A much-used mailer will for example change the Message-ID when resending a message. Doing this is bad, because it can cause mailing-list loops, because threads are broken and for other reasons. There are of course cases where the "do not munge" rule should not be adhered to. A well-known example is certain attributes in submission to Mail Transfer Agents (MTAs). Some MTAs will correct incorrect mail by adding missing "Date:" and "Content-ID" headers. This is in general not good. For example, if an MTA adds "Content-ID" to a message which it receives by SMTP from another MTA, different versions of the same message may turn up with different values of the Content-ID, which can cause various problems. However, the first MTA which receives a message from the originating Message User Agent (MUA) can add a missing Content-ID without this risk. Therefore, a specific standard has been written, [RFC2476] which specifies what kind of munging is allowed and not allowed for the first MTA which receives a message from an MUA. There are certain advantages with doing this in some cases, for example, the submission MTA may have a more reliable clock than the originating MUA. 8. Rule three: Modify as late as possible If you absolutely have to modify incoming data, this modification should be done as late as possible. If possible, standards should be written so that data need not be modified. The reason for this rule is that modifying or converting data often causes some damage to the data (either loss of information or addition of possibly incorrect information or both). And if this conversion is done as late as possible, it is easier for the recipient to control how it is done. For example, if you receive an HTML document which your browser cannot display properly, you can choose to display it using another web browser instead of converting it. Another reason is that you may need to send out what you have received. And when re-sending information, "Rule two: Do not munge" usually means that the original document should be sent, unless you explicitly under manual control make changes to it or convert it. This is the reason, for example, for the use of the Content-Location heading in the MHTML standard [MHTML]. Using Content-Location, HTML documents can be fetched unchanged from a web site and put into e-mail. The alternative (Content-ID, which is also allowed according to MHTML) usually requires rewriting of the HTML code when it is to be sent by e- mail. 9. Rule four: Leave nothing undefined When in a trouble about how to describe a certain function, there is a simple, but bad, way out. That is to leave the function undefined. This is bad, because implementors may choose to implement this function in different ways, which can cause interoperability problems. 10. Rule five: Cause no harm Refractory implementers may follow a standards specification to the letter, but interpret it in ways which means that other agents receiving the information may be confused or even crash. Thus, the "cause no harm" rule says that you should not produce information which has a potential of causing harm to a well-working internet. Examples of this is to send unreasonably long data, which might cause so-called "buffer overflows" which are known to be a major cause of security problems in standards. An example is lines in e-mail, where the [RFC2822] standard says: Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. Note that it is possible to send e-mail with more than 78 characters per line, using either the MIME [RFC2046] standard and the BASE64 or the Quoted-Printable encodings, or by using the format=flowed format [RFC 2646]. 11. Rule six: Keep it simple, stupid There is a tendency for standards developers to make standards overly complex. One reason for this is that a simple way out of disagreements and reaching consensus is to include everything anyone wants in a standard. There is also an obvious risk that people from large software vendors may prefer a complex standard, since this reduces the number of competitors who have the capacity to implement the full standard. IETF is not immune from this tendency. For example the HTTP standard does probably provide unnecessarily too many ways of indicating that a page should not be automatically saved in any way in the receiving computer. I read, in a bulletin board, the following recommendation of how to use HTTP to reduce the risk that a page is saved: Expires: Mon, 26 Jul 1997 05:00:00 GMT ; Date in the past Last-Modified: 4 June 2005 15:20:00 GMT ; Current date Cache-Control: no-store, nocache, must-revalidate, max-age=0 ; HTTP/1.1 Cache-Control: no-store, no-cache, must-revalidate, max-age=0 ; HTTP/1.1 Pragma: no-cache ; HTTP/1.0 The reason this recommendation is given, is that some HTTP implementations may not support all the methods, so therefore it is safest to use all of them. This is a typical example of the risk that complex standards cause different implementations to support different subsets of the standard, which can cause incompatibility problems. Note: There are certainly reasons why the HTTP authors have chosen to provide so many ways of specifying this. In spite of what is said above, IETF standards are usually much simpler than, for example, the competing OSI standards developed by ISO and ITU. And this is probably a major reason why IETF standards usually have been more successful than competing ISO and ITU standards. The rule that any feature not implemented in two co-working independent standards, before an IETF standard is progressed from "Proposed standard" to "Draft standard" has certainly contributed to making the standards simpler. The advantage with simpler standards are that they are usually less easy to misunderstand by implementers. Also, with a complex standard, the risk is larger that two implementers will implement non-compatible subsets of the standard. For ISO/ITU standards, a special set of standards called "functional standards" specify good subsets to the ISO/ITU standards. Such functional standards are not as much needed for IETF standards, since they are simpler from the beginning. 12. Rule seven: No voting, rough consensus IETF developers often claim that IETF has a rule of "no voting". Anyone who has participated in IETF meetings know that this is not true, some kinds of voting does happen now and then. Voting, however, is not part of the formal decision process in IETF, as it is in ISO and ITU. One reason for this is that all are not equal in standards work. Opinions of people known to be reasonable and knowledgeable are more important than those of other people participating in the standards work. Another reason is that there is no voting procedure which will always produce the optimal result. This problem has been extensively discussed in the political science sub-area with the name "social choice theory". A simple example to illustrate the issue. Suppose we are to choose between three solutions. +----------+----------+----------+----------+----------+----------+ | |very good | good | OK | bad | very bad | +----------+----------+----------+----------+----------+----------+ |Solution A| 40 % | | | | 60 % | +----------+----------+----------+----------+----------+----------+ |Solution B| 35 % | | | | 65 % | +----------+----------+----------+----------+----------+----------+ |Solution C| 25 % | 75 % | | | | +----------+----------+----------+----------+----------+----------+ It is not obvious, in the above situation, what is the best choice to make in a standards making organisation. Probably solution C is best, since everyone thinks it is good, even though it has the least number of people who thinks it is very good. I have in fact implemented a voting program with the special goal of being suitable for IETF. In this program, people are given a list of alternatives, and can rate each alternative on a scale from very good to very bad. The results are not presented as numbers. Instead, the results are presented by listing the names of the people who voted in each box in the table as shown in the example above. "Rough consensus" means that all or most reasonable experts agree, even though some may dissent. 13. Rule eight: Plain ASCII text is enough This may be the least important of the golden rules, but all IETF standards are written in plain ASCII, with no other formatting than CRLF between the lines and FF between the pages. They are also written to be printed with a monospace font (a font where all characters have equal widths) otherwise some tables or diagrams (like in this memo) may not display well. This rule is not only for standards text. Also discussion about standards in IETF working groups adhere to this rule. MIME, HTML and other newfangled ideas are looked down upon in IETF mailing lists. And best is if lines are no longer than 72 characters. 14. Contradiction between the rules There may, of course, be contradictons between the rules. Note however that Rule two and Rule three are rules about relaying information, while Rule one and Rule five are rules about producing information. The rest of the rules mainly concern how standards are written, rather than how they are implemented. A well-known example of a contradiction is if you have to combine snipetts of HTML produced by different agents. An error in one of the snippets, for example might then damage HTML coming after the illegally formatted snippets. The best way around this problem is to surround the included HTML with
and
, or, even safer, put it into a separate FRAME or IFRAME (although FRAMEs and IFRAMEs may have other drawbacks). Some software also adds finishing HTML for unfinished elements, for example adds

,
, etc. at the end of the incorrectly formatted HTML snippet. These additions may be wrong, but the risk is certainly less than by adding start HTML elements to try to correct incorrect snippets. 15. Other documents There are many RFCs describing IETF workings and procedure. Some of them are certainly more authorative than this memo. Examples of other such RFCs are (in publication order): RFC2418: IETF Working Group Guidelines and Procedures, by S. Bradner, September 1998. RFC3160: The Tao of IETF - A Novice's Guide to the Internet Engineering, by S. Harris, August 2001. RFC3184: IETF Guidelines for Conduct, by S. Harris. October 2001. RFC3233: Defining the IETF, by P. Hoffman, S. Bradner. February 2002. RFC3844: IETF Problem Resolution Process. E. Davies, edited by J. Hofmann, August 2004. RFC3929: Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF, by T. Hardie. October 2004. RFC3935: A Mission Statement for the IETF, by H. Alvestrand, October 2004. 16. References For more references, see chapter 14 above. [RFC1123]: Requirements for Internet Hosts -- Application and Support, By Robert Braden, October 1989. [RFC2046]: Multipurpose Internet Mail Extensions(MIME) Part Two: Media Type, by N Freed and N Borenstein, November 1996. [RFC2476]: Message swubmission, by R. Gellens and J. Klensin, December 1998. [RFC2557]: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), by J. Palme, A. Hoffman and N. Shellness, March 1999. [RFC2646]: The Text/Plain Format and DelSp Parameter, by R. Gellens, February 2004. [RFC2822]: Internet Message Format, by Pete Resnick, April 2001. 17. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. 18. Author's address Jacob Palme Skeppargatan 73 11530 Stockholm Phone: +46-8-16 16 67 19. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 20. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft will expire on 6 December 2005.