RFC文件和互联网草案 如果你是新加入的IETF参与者并试图寻找一份特定的RFC文件或互联网草案，请到RFC编辑处网页：http://www.rfc-editor.org/rfc.html 这个站点也提供指向其他RFC站点的链接，这些站点中的许多具有搜索功能。如果你知道正在寻找的RFC文件的编号，可以直接去IETF的RFC页面，http://www.ietf.org/rfc.html。寻找互联网草案的最佳地点是在IETF的网站： http://www.ietf.org/ID.html，在那里你能按标题或关键字查找文件。
6.1 出版一份IETF标准 新加入IETF者常问"如何出版一份IETF标准？"更准确的问题是"我能写一份IETF标准吗？"答案并不一定。如果你确信要写一份文档并使之成为标准，请注意整个过程可能是很艰难的，即使有很坚定的决心和很充分的准备。尽管有许多指导作者起草文档的指南，仍有很多人对写自己的文档没有信心。 每一个IETF标准都以RFC("Request For Comments")的形式发布，每一个RFC都是从互联网草案(简称"I-D")开始的IETF标准的产生过程如下： 1。发布一份互联网草案 2。接受关于草案的评论 3。根据评论修改你的草案 4。重复1至3步骤数遍 5。请求领域总监将草案带至IESG(如果是个人提交)。如果草案出自一个正式工作组，则由工作组主席向领域总监提交草案。 6。根据IESG讨论结果修改草案(结果可能是草案被否决) 7。等待RFC编辑处编辑出版你的草案 关于标准形成过程的详细说明在BCP9，"互联网标准进程"中。任何想使他的文档成为标准的人都应该去读BCP9,这样他就可以知道如何处理他的文档了。BCP9里论述了一个时常连老IETF成员都很困惑的问题：不同类型的RFC标志着他们在标准进程中的状态和不同的地位。有六种RFC文件： ——建议标准 ——草案标准 ——互联网标准(有时称作"完全标准") ——试验性协议 ——信息文档 ——历史标准 只有前三种文件是IETF的标准。这个问题在RFC1796，"不是所有RFC文件都为标准"中有介绍。 RFC文件又有FYI,BCP,STD三个子集。FYI("For Your Information")文件以面向大众的概要和介绍性主题为主。通常，FYI文档由IETF用户服务领域的工作组撰写。BCP("Best Current Practice")文件描述了互联网中不同技术的应用情况。STD文件是用来确认那些已成为标准的RFC文件的。一些STD文件可能由多个RFC文件组成,并且对所有涉及的RFC都有效。
6.2顺利进阶 有些人不希望把他们的文档提交给IETF而成为标准，一个很大的原因是他们不想放弃对自己工作的主控权。从你开始将你的协议提交给IETF起，你必须完全放弃对你协议的控制权。经许可后，协议的任何部分都有可能被增删或改写，甚至连协议名称都可被改变。 一些作者很难下决心放弃由他们一手创建的协议的主控权。如果这样，你就永远不可能使你的协议成为IETF标准。另一方面，如果你希望你的协议得到大家的支持和评价，那你最好把它提交给IETF标准进程。有时，标准被提交给IETF后还会变化。协议本身可能由于内容上的重大改变而变化，但这些变化都在IETF的掌控下，而不是协议修改者。IETF标准的制定是为方便人们编写可交互的互联网应用程序。这些标准不应有太多个人或公司的色彩。如果一个申请IETF标准的协议不需要评价和修改的话，那它一开始就不该来申请。
6.3 互联网草案 每一个被确认为RFC文档最初都是从互联网草案开始起步的。互联网草案是临时性文档——读者可以提出修改意见，作者则吸收意见并改进草案。由于是临时文件，互联网草案在网上公布六个月后自动失效并从目录中删除。他们不是标准甚至不能被称为规则。BCP9中叙述： 互联网草案的发布不代表一个规则的出版。规则是由RFC文件负责公布的。。。互联网草案不是正式文件，它可以在任何时间被修改或删除。请写作论文，报告和其他文件的作者注意：在任何情况下，关于互联网草案的引用都是无效的。制造商也不应遵循互联网草案来设计产品。你可以大胆的告诉那些不了解IETF(或想弄虚作假)的人，即使他们发布过互联网草案，也不代表任何成就。 一份草案应与RFC文件保持相同格式。和大多数人的看法相反，你不必使草案精确得与RFC一致，但你可以使用与RFC编辑处相同的格式化方法来组织文档。但发布RFC则是RFC编辑处的事情。RFC2223,"RFC写作指导"介绍了编辑处使用的文档格式化方法。 互联网草案可以是工作组草案，也可以由个人提交的。工作组主席会仔细阅读草案以决定是否将它列为工作组议题讨论。
6.3.1 写作者必读 你在写互联网草案初稿前，应先阅读如下文档： ——不只是格式解读，RFC2223也解释了合格草案必须包括的内容。文档建议你把各部分说明和注意事项放在文件的首部，方便他人阅读 ——BCP22，"互联网草案写作者指导"提供了许多实用技巧。比如如何正确设置协议可选项，如何应对超范围问题以及如何制作状态报表。 ——网络资源"互联网草案写作者指南"，http://www.ietf.org/ietf/1id-guidelines.txt，包括了草案写作的最新要求。 ——如果你完成了草案的写作并决定提交，请认真阅读"互联网草案注意事项"，http://www.ietf.org/ID-nits.html，这里有关于如何通过IESG审核的提示。其实，你在写作前就应该阅读，这样才不会导致大量的修改工作。
6.3.2 文件名和其他事项 当你决定提交你的文档时，请把它发送到互联网草案编辑处(internet-drafts@ietf.org)。编辑处有专门人员在审核你的稿件是否符合最低要求。编辑处会决定草案初稿的文件名。如果是从工作组发出的草案，名称将会是"draft-ietf-" 加工作组指定名加一两个描述词以及表示顺序的数字，如"00.txt"。 举例说明，一个由S/MIME工作组提出的关于建立键值的草案文件名就可能是"draft-ietf-smime-keying-00.txt"。如果是个人提交的草案，文件名变成"draft-" 加一个作者的名字加描述词最后是顺序数字。比如说，有个叫Smith的人写的草案文件名就是"draft-smith-keying-00.txt"。如果个人写作者的成果是参考了某一工作组的工作时，编辑处也会将工作组名和个人的名字并列与文件名中，如"draft-smith-smime-keying-00.txt"。你可以在文档里提及自己的名字，但最终的文件名则是由草案编辑处(如果在工作组中，是工作组主席)来决定的。 随着草案修改稿的出现，新文件名末尾的数字将增大。比如S/MIME草案修改后的第二版本文件名为"draft-ietf-smime-keying-01.txt"，注意只有当重要修改后，文件名的顺序数才会增大。 6.4 标准跟踪RFC文件 创建和优化标准的过程在BCP9中有描述。当互联网草案被充分讨论和修改并得到大多数参与者支持后，它被提交给IESG等待审核。如果草案是工作组完成的，则由工作组主席交给他的领域总监。如果是个人发起的草案，这写作或修改者也应向相关领域总监提交。如果有人觉得受到了主席，总监或IESG不公对待时，可以申诉。BCP9中叙述了申诉的具体过程。 当草案提交到IESG后，它被公示于IETF全体成员面前。这样可以吸引更多人参加讨论，并进一步完善草案。本工作组内成员也可以指出他们在讨论时被忽略的意见。工作组草案公示时间是两周，个人草案是四周。 如果IESG批准了草案，并认为可以形成一个互联网标准，它就请求RFC编辑处将草案作为建议标准出版。在草案成为建议标准至少六个月后，作者或工作组主席可以申请将之变为草案标准。然而，他们必须说服领域总监相信他们协议的每一部分都有至少两个独立的可互相验证的实现案例。这能很好的测试标准的有用性和可读性。 其他可能发生的事情包括：部分文字使实现者产生歧异而必须重写；有一些标准的特性没有被实现，这些不实用的特性将被删除。 如果你没有看到一份特定的建议标准未被升级成草案标准时，请不要惊讶。事实上，现在正在运用的大多数协议都还只是建议标准，并一直没有升级。原因可能是没人有空来完善并使之成为草案标准，也可能是标准中引用的部分标准还停留在建议阶段。 在一个草案标准出现的若干年后，它能升级为互联网标准(也就是"完全标准')。这样的标准很少，基本上只涉及到互联网中的关键协议。IESG全力审核一份草案标准来决定是否将之升级为互联网标准。
6.4.1 用词注意点——MUST,SHOULD,MAY的使用 想让你写的标准按照你的意思来被实现是一门艺术。你可以使标准很短，仅包括一个基本要求的列表，但这样做会使实现者失去方向。但是，如果你的标准里充满了不明确的建议而不是简明的要求，操作者同样会不明就里，而且拒绝接受你的建议。最佳的解决办法是处于这两个极端的中间处。 一种使别人明白如何实现操作的方法是将步骤写进标准里。早期的RFC使用各色表示方法解释必须事务，这样实现者很难分清楚那些是建议，那些是要求。因此，IETF要求标准作者使用特定的词表示特定的意义。 RFC1123,"互联网主机要求——应用程序和支持"写于1989，其中有一系列很有用的词，是"must", "should", 和"may"。这些词在BCP14，"RFC文件中表示要求级别的关键词"，中更新并进一步提炼。这个规定被现有的大多说互联网标准遵循。BCP14也定义了"must not" 和"should not",并规定和这些词的简写方式。 在标准里，为了表明你遵循BCP14的规范，你必须做两件事。首先，引用BCP14(尽管很多人引用RFC2119,因为BCP14要你这么做) ，这样读者就指导你是如何定义特定词的。其次，你必须指出文中的哪些词是按照BCP14的规范来定义的。你可以用大写词来表明他们，这就是你在IETF标准中看到全大写的"MUST" 和"SHOULD" 的原因 BCP14很简短，所有要读写IETF标准的人都应该去阅读。尽管"must" 和 "must not"被定义得很清楚，但"should"和 "should not"常引起许多工作组的纷争。在复核互联网草案时，常有问题问："这句话应该用MUST还是SHOULD？" 这个问题很好，因为标准里不应有过多的MUST要求，但也不能在必须用MUST规定的地方用SHOULD。这导致了一个如何防止过度规定和过少规定的问题。
6.4.2 标准中正式的引用方式 撰写IETF标准而能吸引很多新手(也召集很多老手)的方法是较好地引用其他标准文档。一个正式的引用必须是与实现本标准相关的文档。而非正式应用则是那些对实现者有帮助但不是必须的材料。就象前文提过的，MUST语句肯定是正式的要求，所以任何正式的引用都要加上MUST一词。SHOULD或MAY句不一定是正式的。但它可以根据具体情况变成正式的。这儿有可能会产生分歧！ 一个IETF标准可以引用任何在册的比自己等级相当或高的RFC标准，或者是那些其他组织开发的公共标准。这就意味着当一个草案标准要升级为完全标准时，它里面的所有正式引用都要出自与其他草案标准或完全标准。这样做确保标准实现者有一个稳定的环境，即使标准中有对于其他文档的引用。这可以阻碍标准的升级过程达数年甚至更久，直到那些被引用标准完成升级。 关于"开放标准"的定义，是那些稳定的公开的(包括收费服务)由权威标准组织推出的标准。当外部标准经常变化而你又必须引用它时，请注明引用标准的日期。有些标准组织不公开旧标准，这给将来要使用的IETF标准带来了很大困难。如果你不清楚是否该引用某一外部标准，请询问工作组主席或相关领域总监。
6.4.3 IANA注意点 越来越多的IETF标准涉及到不同协议参数的注册，比如协议中的命名选项。在1.2.4部分提过，由于标准需要大量不同种类的注册，IANA需要规定注册参数的方法种类和实体。 任何需要用到IANA注册参数的标准撰写者可以阅读BCP26,"关于在RFC中写IANA注意点部分"文档。文档描述了如何在IANA申请和使用一个注册项。IANA在很早就开始了这些注册业务。
6.4.4 安全注意点 每个RFC文档都要有一个"安全注意点"部分。这部分描述了该协议的任何已知弱点，可能存在的威胁，以及防御方法。不要轻视这一部分，千万别说"这是我们的协议，如果需要安全保证，请使用IPSEC加密"。这不起作用，因为你没有说明你的协议如何与IPSEC互动。如果你不清楚如何处理这部分内容，请咨询你的工作组主席。 6.4.5 IETF标准里的专利 近年来，知识产权问题受到了越来越多的关注和重视。IETF的目标是使它的协议被广泛地使用和被市场所检验。如果产品中应用到的协议标准需要支付专利许可费用，那人们就不太愿意使用这个标准。一般来说，人们希望"尽可能使用优秀的非专利技术"。 当然，这有时不太可能。一些标准制定后马上申请了专利。另一些专利只此一家，没有同类的非专利替代品。还有些专利的拥有者慷慨地为每个使用其专利的人提供免费使用权许可，就如同没有专利限制那样。 IETF对于标准中专利的处理方法是有颇多争议的。你可以阅读BCP9来了解具体情况，但你必须清楚这些规则可以视专利的类型，专利的拥有者以及专利技术的替代品而灵活改变。 那些无偿提供给IETF使用其专利的专利拥有者通常会从IETF团队中受益。比如说，RFC1822中有一个IBM授权的安全专利，安全委员会对IBM公司十分感激(而其他公司由于严格保密他们的安全技术专利而在安全委员会失去了地位)。 如果你在起草一份互联网草案并且指导自己写的东西涉及某个专利，不要在文档里列出来。你应该告知IETF秘书处(ietf-secretariat@ietf.org)相关的专利和知识产权情况。这些情况会在IETF IPR网页上公布：(http://www.ietf.org/ipr.html) 这些信息不在RFC中出现是因为RFC一经出版就不再改动，而IPR信息则可以随时改动。所以，如果在RFC中出现不完整的IPR信息只会迷惑和误导读者。BCP9提供了一段必须加入RFC的特殊文本，以此提示读者文章所涉及的IPR问题。
6.5 信息性和试验性RFC文件 我们以前提过，不是所有的RFC文件都是标准。实际上，许多重要的RFC文件并不是标准系列。目前，有两种非标准的RFC文件：信息性文件(此文即是)和试验性文件。(还有一种历史性文件，此种虽然曾是标准系列，但由于缺乏应用或自身缺陷而被取消了标准资格) 信息性RFC文件的作用在IETF里是有争议的。许多人欢迎它的存在，因为可以使用它介绍那些被引用的外部标准，也可以使用它通报IETF工作组成果。另一方面，有人利用公众的无知，借助那些不是标准的信息文件来推销他们的产品和服务。 实验性RFC文件是一组有趣的规则，但由于有些问题没有解决而无法实现。这些规则可能能解决问题，但人们并不认为这个问题很严重而必须解决。以后如果这个问题重新热门起来，它还会被列为标准文档的。试验RFC文件是用来记录那些不成熟技术的，它为人们继续试验并完善这一技术提供了参考。
