互联网的两大标准制定组织(IETF、IRTF)和一协会(ISOC)

 

一、互联网工作组包括两大组织和一个重要的协会

 互联网研究任务组(IRTF) 专注于 与 互联网相关的长期研究问题，而平行组织 互联网工程任务组 ( IETF ) 则专注于工程和标准制定的短期问题

https://www.ietf.org/ 互联网工程任务组 (IETF) 是首要的互联网标准机构，通过开放流程开发开放标准。
IETF 是一个由网络设计者、运营商、供应商和研究人员组成的大型开放国际社区，关注互联网架构的演进和互联网的顺利运行。IETF 的技术工作在工作组中完成，这些工作组按主题组织成几个领域。大部分工作是通过 邮件列表处理的。IETF 每年召开3 次 会议。
IETF 标准制定过程 对任何有兴趣提供技术贡献的个人开放。
刚接触 IETF 的参与者——即使是以前有互联网技术经验或在其他标准制定机构工作的人——会发现阅读 IETF 入门和 IETF 之道很有帮助。

IETF 工作组指导方针和程序请访问这里 (1994 年 3 月)，定义在了 rfc1603里面
https://datatracker.ietf.org/doc/rfc1603/

互联网工程任务组 (IETF) 负责　　开发和审查旨在作为 Internet 的规范标准。IETF活动被组织成工作组 (WG)。
本文件描述了组建的指导方针和程序和IETF工作组的运作。它描述了正式的IETF参与者WG和Internet 之间的关系
工程指导小组 (IESG)。IETF的基本职责参与者，包括 WG 主席和 IESG 区域主任。

IETF互联网社区使用的流程请看rfc2026

IETF成立历史点这里
https://irtf.org/ 互联网研究任务组(IRTF) 专注于 与 互联网相关的长期研究问题，而平行组织 互联网工程任务组 ( IETF ) 则专注于工程和标准制定的短期问题。IRTF 由多个专注的长期 研究小组组成。 这些小组致力于与互联网协议、应用程序、架构和技术相关的主题。
研究小组拥有稳定的长期成员，以促进研究合作和团队合作的发展，以探索研究问题。参与的是个人贡献者，而不是组织的代表。
IRTF 还组织了 ACM/IRTF 应用网络研究研讨会 和 应用网络研究奖 ，以鼓励学术研究界和互联网标准社区之间的合作。
IRTF 提供数量有限的 旅行补助金 ，以支持博士生和早期职业研究人员参加我们的活动和研讨会
IRTF成立历史点这里
https://www.internetsociety.org/

互联网协会( ISOC ) 是一家美国非营利性倡导组织，成立于 1992 年，在世界各地设有分会。其使命是“促进互联网的开放发展、演进和使用，造福全世界所有人”。它在美国弗吉尼亚州雷斯顿和瑞士日内瓦设有办事处。

2012 年，在 ISOC 成立 20 周年之际，它设立了 互联网名人堂，该奖项旨在“公开表彰为全球互联网的发展和进步做出重大贡献的杰出的、精选的有远见的人、领导者和杰出人物
互联网名人堂网站: https://www.internethalloffame.org/

协会成立历史点这里

二、IETF具体介绍

　　Internet 工程任务组( IETF ) 是 Internet 的标准组织，负责组成Internet协议套件(TCP/IP)的技术标准。它没有正式的会员名册或要求，所有参与者都是志愿者。他们的工作通常由雇主或其他赞助商资助。
　　 IETF 被组织成大量的工作组和非正式讨论组，每个组处理一个特定的主题。IETF 以自下而上的任务创建模式运行，主要由这些工作组驱动。[2]每个工作组都有一名指定的主席（或有时数名联合主席）；描述其重点的章程；以及预计生产什么，何时生产。它对所有希望参与并在公开邮件列表或 IETF 会议上进行讨论的人开放。

　　IETF 最初由美国联邦政府支持，但自 1993 年以来一直在国际非营利组织Internet Society的主持下运作。

　　该互联网工程任务组， 成立于1985年，主要定义互联网标准
       网址： http://ietf.org
　　rfc文档下载： https://www.ietf.org/rfc/ (注意是和OSI七层模型紧密结合的)
　　例子： 我们平时提到的RFC文档都是他们的制定的，包括协议:IP、TCP、 UDP、FTP、HTTP1.1等。

　　RFC

　　RFC 文档包含 Internet 的技术规范和组织说明。
　　https://www.rfc-editor.org/
　　包含有关 Internet 的技术和组织文档，包括由四个流产生的规范和政策文档：Internet Engineering Task Force ( IETF )、Internet Research Task Force ( IRTF )、Internet Architecture Board ( IAB ) 和Independent Submissions。

　IETF 产生的 RFC 涵盖了计算机网络的许多方面。它们描述了 Internet 的技术基础，例如寻址、路由和传输技术。RFC 还指定了TLS 1.3、QUIC和WebRTC等协议，用于交付数十亿人每天使用的服务，例如实时协作、电子邮件和域名系统。

只有一些 RFC 是标准。根据其成熟度级别和所涵盖的内容，RFC 被标记为不同的状态：Internet 标准、提议的标准、最佳当前实践、实验性、信息性和历史性。

　RFC 系列包括由 IETF、互联网架构委员会 ( IAB )、互联网研究任务组 ( IRTF ) 和独立提交者制作的文档。所有 RFC 均由RFC Editor发布，它是检索 RFC 的权威来源。

　RFC 通常以个人或小组编写的Internet 草案 ( I-D ) 开始。在 IETF 中，这些通常由工作组采用，并进行改进和修订。在 IETF 中，I-D 很少被视为由区域主管赞助的“个人提交”。虽然并非每个 ID 都成为 RFC，但一组定义明确的流程（也记录在 RFC 中）指导文档的考虑和进展。当它们发布时，RFC 可以在线免费获得。 

　世界各地的软件开发商、硬件制造商和网络运营商自愿实施和采用 RFC 描述的技术规范。

　IETF 认识到 IETF 协议中会发现安全漏洞，并欢迎研究人员对其进行批判性评估。互联网工程指导小组就如何报告据信在 IETF 协议中发现的漏洞提供了指导。

　该系列的第一个文档RFC 1编写于 1969 年。很快其他文档紧随其后，包括那些描述当今仍在 Internet 中使用的核心 Internet 协议 (IP) 的文档。RFC 最初是非正式的技术说明，最初的名称代表“Request For Comments”，但现在它们被简称为 RFC。用于开发早期 RFC 的协作过程仍然是 IETF 精神的重要组成部分。今天，该系列中有 9000 多份单独编号的文件。

 

　　资源(Resoures):

   
Internet 标准 https://www.ietf.org/standards/
发布和访问 RFC https://www.ietf.org/rfc/
RFC 风格指南 https://www.rfc-editor.org/styleguide/
RFC 文档包含 Internet 的技术规范和组织说明 https://www.ietf.org/standards/rfcs/
   
   
RFC 文档包含 Internet 的技术规范和组织说明,RFC 系列包括  
IETF  
互联网架构委员会 ( IAB )  
互联网研究任务组 ( IRTF )  
独立提交者  
发布器（在线编辑） https://www.rfc-editor.org/



 三、IRTF具体介绍

      互联网研究任务组 (IRTF) 促进对互联网协议、应用程序、体系结构和技术的发展具有重要意义的研究。

　 概述

　　互联网研究任务组(IRTF) 专注于 与 互联网相关的长期研究问题，而平行组织 互联网工程任务组 ( IETF ) 则专注于工程和标准制定的短期问题。IRTF 由多个专注的长期 研究小组组成。 这些小组致力于与互联网协议、应用程序、架构和技术相关的主题。研究小组拥有稳定的长期成员，以促进研究合作和团队合作的发展，以探索研究问题。参与的是个人贡献者，而不是组织的代表。

        IRTF 还组织了 ACM/IRTF 应用网络研究研讨会 和 应用网络研究奖 ，以鼓励学术研究界和互联网标准社区之间的合作。

　　IRTF 提供数量有限的 旅行补助金 ，以支持博士生和早期职业研究人员参加我们的活动和研讨会。

　活跃的研究小组

      这14个研究小组目前正在特许或拟特许：
　　

研究组 网址 主题内容
cfrg https://datatracker.ietf.org/rg/cfrg/about/ 加密
coinrg https://datatracker.ietf.org/rg/coinrg/about/ 网络
dinrg https://datatracker.ietf.org/rg/dinrg/about/ 去中心化
gaia https://datatracker.ietf.org/rg/gaia/about/ 全球访问
hrpc https://datatracker.ietf.org/rg/hrpc/about/ 人权注意事情
iccrg https://datatracker.ietf.org/rg/iccrg/about/ 互联网拥塞控制
icnrg https://datatracker.ietf.org/rg/icnrg/about/ 以信息为中心
maprg https://datatracker.ietf.org/rg/maprg/about/ 协议研究组的测量和分析
nmrg https://datatracker.ietf.org/rg/nmrg/about/ 网络管理研究组
nwcrg https://datatracker.ietf.org/rg/nwcrg/about/ 高效网络通讯
panrg https://datatracker.ietf.org/rg/panrg/about/ 路径感知
pearg https://datatracker.ietf.org/rg/pearg/about/ 隐私增强
qirg https://datatracker.ietf.org/rg/qirg/about/ 量子
t2trg https://datatracker.ietf.org/rg/t2trg/about/ 物对物研究组

　　      其它所有组

研究组 网址 主题内容
aaaarch https://irtf.org/concluded/aaaarch AAA架构组
asrg https://irtf.org/concluded/asrg 发垃圾邮件
buds https://irtf.org/concluded/buds 建立差异化服务
dtnrg https://irtf.org/concluded/dtnrg 延迟容忍
eme https://irtf.org/concluded/eme 端中端
end2end https://irtf.org/concluded/end2end 端到端
gsec https://irtf.org/concluded/gsec 集团安全
hiprg https://irtf.org/concluded/hiprg 主机身份
idrm https://irtf.org/concluded/idrm 互联网数字版权
iiarg https://irtf.org/concluded/iiarg 信息基础设施架构
imrg https://irtf.org/concluded/imrg 测量
ipnrg https://irtf.org/concluded/ipnrg 星际
ird https://irtf.org/concluded/ird 资源发现
mobopts https://irtf.org/concluded/mobopts ip移动优化
ncrg https://irtf.org/concluded/ncrg 网络复杂性
nfvrg https://irtf.org/concluded/nfvrg 网络功能虚拟化
nsrg https://irtf.org/concluded/nsrg 命名空间
p2prg https://irtf.org/concluded/p2prg 对等研究
pkng https://irtf.org/concluded/pkng 公钥下一代
psrg https://irtf.org/concluded/psrg 隐私和安全
rmrg https://irtf.org/concluded/rmrg 可靠组播
rrg https://irtf.org/concluded/rrg 路由
samrg https://irtf.org/concluded/samrg 可扩展自适应
sdnrg https://irtf.org/concluded/sdnrg 软件定义
siren https://irtf.org/concluded/siren 可搜索互联网资源名称
smrg https://irtf.org/concluded/smrg 服务管理
tmrg https://irtf.org/concluded/tmrg 交通模型
vnrg https://irtf.org/concluded/vnrg 虚拟网络

四、关于Jonathan Bruce Postel
　　
　　Jonathan Bruce Postel（1943 年 8 月 6 日 - 1998 年 10 月 16 日）是一位美国计算机科学家，他为互联网的发展做出了许多重大贡献，特别是在标准方面。他主要以担任征求意见(RFC) 文档系列的编辑、简单邮件传输协议(SMTP) 的编辑以及管理互联网号码分配机构(IANA) 直到他去世而闻名。在他的一生中，他被称为“互联网之神” 因为他的综合影响力；Postel 本人指出，这个“赞美”带有一个倒钩，暗示他应该被一个“专业人士”取代，并以典型的谦逊实事求是的回应：“当然，没有任何‘上帝互联网的。互联网之所以有效，是因为很多人合作共同做事。” 

　　Postel 于 1969 年 12 月 23 日开始在 UCLA 工作，担任研究生研究工程师 (I)，在那里他参与了ARPANET的早期工作。他参与了 Internet 域系统的开发，在他的怂恿下，Vint Cerf 和 Bob Kahn 开发了第二套用于处理网络之间数据的协议，现在称为Internet 协议套件。Jonathan Bruce Postel与 Vint Cerf 和Steve Crocker一起致力于实现大多数 ARPANET 协议。Vint Cerf 后来成为 TCP/IP 标准的主要设计者之一，由于被称为Postel 定律的句子而起作用. 

Postel 一直在 ARPANET 工作，直到 1973 年 8 月 24 日他离开加入MITRE 公司。他协助Elizabeth Feinler在 SRI 建立的 网络信息中心。1977 年 3 月，他加入南加州大学信息科学研究所，担任研究科学家。

　　Postel从 1969 年到去世一直担任RFC编辑，编写和编辑了许多重要的 RFC，包括定义Internet 协议套件基本协议的 RFC 791、RFC 792 和 RFC 793，以及 RFC 2223，RFC 作者说明。在 1982 年到 1984 年间，Postel 与人合着了 RFC，这些 RFC 成为了今天的 DNS （RFC 819、RFC 881、RFC 882 和 RFC 920）的基础，1995 年他还与人合写了 RFC 1591。他总共撰写或共同撰写了 200 多个 RFC。

　　Postel 在互联网架构委员会及其前身任职多年。从一开始，他就是互联网号码分配机构(IANA)名称和号码分配信息交换所的主管。他是互联网协会的第一位成员，并且是其董事会成员。他是最初的长期.us 顶级域管理员。他还管理着 Los Nettos 网络。

　　以上所有这些都是他在担任南加州大学信息科学研究所计算机网络部第 7 部主任时担任的兼职活动。

      特别说的是，他的导师是David J. Farber(1961-1972年工作在贝尔实验室，被称为互联网之父) 

     David J. Farber 他的研究工作专注于创建世界上第一个可操作的分布式计算机系统。作为特拉华大学电气工程系的成员，他帮助构想和组织了美国主要的研究网络CSNET、NSFNet和国家研究与教育网络(NREN)。他帮助创建了 NSF/DARPA 资助的千兆网络测试床计划，并担任千兆测试床协调委员会主席

　

五 RFC8700(五十年的RFC)
    https://www.rfc-editor.org/rfc/rfc8700.html#
   

　　　　　　　　　　　　　　　　　　　　　　　　RFC 8700

　　　　　　　　　　　　　　　　　　　　　　　　五十年的 RFC

地位：信息性
更新：2555 , 5540
更多信息：存在勘误表| 数据跟踪器| 知识产权| 信息页面

  抽象的

　　本 RFC 标志着 RFC 系列五十周年。它既包括来自关键转折点的个人的回顾性材料，也包括对当前事态的回顾。它以对未来五十年系列的可能性的想法结束。本文档更新了 RFC 2555(RFC三十周年) 和 RFC 5540(RFC四十周年) 中提供的观点。

活动 更新文档
三十年纪念 RFC 2555
四十年纪念 RFC 5540
五十年纪念 https://tools.ietf.org/html/rfc8700

 

   本备忘录的状态

　 本文档不是 Internet Standards Track 规范；它是为了提供信息而发布的。

     本文档是 Internet 架构委员会 (IAB) 的产品，代表 IAB 认为有价值的信息，可提供永久记录。它代表了互联网架构委员会 (IAB) 的共识。IAB 批准发布的文件不是任何级别的互联网标准的候选者；2 节。¶

     有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8700。

  一、简介

　RFC 系列始于 1969 年 4 月，由 Steve Crocker 出版了“主机软件”。事实上，早期的 RFC 是征求对想法和建议的评论。目标是开始对话，而不是创建标准或最佳实践的档案记录。这个目标随着时间的推移而改变，随着出版过程的形式的发展和消费材料的社区的增长。今天，已经发布了 8500 多个 RFC，涵盖最佳实践指南、实验协议、信息材料，当然还有 Internet 标准。材料被接受通过 IETF、IAB、IRTF 和独立提交流发布，每个都有关于如何提交草稿和可能批准作为 RFC 发布的明确流程。最终，RFC 系列的目标是为 RFC 编辑发布的材料提供规范的来源，并支持永久保存该材料。

　RFC Editor 作为一个角色是在第一个 RFC 发布几年后出现的。术语“RFC Editor”首次使用的实际日期未知，但它是由[ RFC0902 ]于 1984 年 7 月正式确定的；Jon Postel，第一位 RFC 编辑，通过他的行动定义了这个角色，后来又定义了围绕 RFC 发布的初始流程。可以肯定的是，RFC 编辑器的目标是生成可读、清晰、一致和合理统一的文档，并且维护已发布内容的档案记录。

　该系列确实发生了变化，尽管速度很慢。首先，我们看到分发方式从邮寄到 FTP 再到电子邮件。RFC 最初无法以电子方式分发，因为直到第一个 RFC “发布”数年后才定义分发方式。甚至并非所有早期的 RFC 都是以电子方式创建的。有些是用手或打字机写出来的。最终，创建 RFC 的过程变得更加结构化。作者获得了有关如何编写 RFC 的指导。编辑工作从 Steve Crocker 到一个更正式的模特，指定编辑Jon Postel，后来又变成了一个由五到七个人组成的团队。实际的编辑和发布工作从协议代码点的注册服务中分离出来。审查了整个 RFC 编辑器结构[ RFC4844 ]，精炼[ RFC5620 ]，再精炼[ RFC6635 ]。而且，在过去的几年里，改变 RFC 文档本身格式的过程已经开始[ RFC7990 ]。

　  这就是进化；该系列将继续进行调整，以满足使用 RFC 系列的实施者、运营商、历史学家和作者社区的需求和期望。这些变化将始终与该系列的核心使命保持平衡：维护与高级研究计划署网络 (ARPANET) 和 Internet 网络社区相关的技术规范、协议和其他信息的强大、稳定的档案记录。

　　RFC 系列的历史比本文档涵盖的要多。对早期观点感兴趣的读者可能会发现以下 RFC 特别感兴趣。这些 RFCs文档集中在  Jon Postel的巨大贡献、套接字的编号 [ RFC0433 ]的Czar 和 第一个 RFC 编辑器的巨大贡献：

  • [ RFC2441 ] “与 Jon 合作，1998 年 10 月 30 日在 UCLA 发表的致敬” 
  • [ RFC2555 ] “30 年的 RFC” 
  • [ RFC5540 ] “40 年的 RFC” 

　　在本文档中，该系列的历史是通过参与塑造系列的几个人的眼光来看待的。这种性质的叙述对事件的看法有限；几乎可以肯定，还有其他关于事件的观点、记忆和观点同样有效，并且会反映不同的历史。因此，虽然这些回顾具有巨大的价值，并提供了对当天事件的洞察力，但它们只是 RFC 系列历史的一个镜头。

　　Steve Crocker，[ RFC0001 ]的作者，就系列赛开始的方式和原因提出了他的想法。Leslie Daigle 是 RFC Editor 模型发展的主要影响者，她提出了她对 RFC Editor 向更强大、更简洁的功能转变的想法。Nevil Brownlee，2010 年至 2018 年 2 月的独立投稿编辑，分享了他对独立流 (IS) 的澄清及其在 Bob Braden 退休后的过渡的看法。作为当前的 RFC 系列编辑，我将谈谈我对系列数字保存形式化的最新变化、在尊重稳定性需求的同时使格式现代化的过程以及我对未来 50 年 RFC 的想法. 

　　本文档更新了[ RFC2555 ]和[ RFC5540 ]中提供的观点。

  2. RFC 历史上的关键时刻

表 1： RFC 历史上的关键时刻
标记日期事件
[ RFC0001 ] 1969 年 4 月 第一个 RFC 发布
[ RFC0114 ] 1971 年 4 月 第一次通过网络分发 RFC
[ RFC0433 ] 1972 年 12 月 第一次提到 Socket Numbers 的 Czar 和正式注册的提议
[ RFC0690 ] 1975 年 6 月 信息科学研究所 (ISI) 和 RFC 编辑之间的关系开始了（根据 Jon Postel 的隶属关系变化判断）
[ RFC0748 ] 1977 年 4 月 第一次 4 月 1 日 RFC 发布
[ IETF1 ] 1986 年 1 月 第一次互联网工程任务组 (IETF) 会议
[ IAB-19880712 ] 1988 年 7 月 IAB 批准创建 Internet-Draft 系列
[ RFC1122 ] [ RFC1123 ] 1988 年 12 月 审查关键规范和编写适用性声明的第一次重大努力
[ RFC1083 ] 1989 年 10 月 首次定义三阶段标准流程
[ RFC1150 ] 1990 年 3 月 FYI 子系列开始
[ RFC1311 ] 1992 年 3 月 STD子系列开始
[ RFC1818 ] 1995 年 8 月 BCP子系列开始
[ RFC-在线] 大约 1998 RFC Online Project 开始恢复“丢失”的早期 RFC
[ RFC2441 ] 1998 年 10 月 15 日 乔恩·波斯特尔之死
[ RFC4844 ] 2007 年 7 月 记录 RFC 系列管理结构
[ RFC4846 ] 2007 年 7 月 独立提交文件流正式化
[ RFC5620 ] 2009 年 8 月 RFC Editor 组织正式成立为 RFC Series Editor、Independent Submission Editor、RFC Production Center 和 RFC Publisher
[ ISI 到 AMS ] 2009 年 10 月 RFC Production Center 和 RFC Publisher 的过渡从 Information Sciences Institute (ISI) 开始向 Association Management Solutions (AMS)
[ RFC5540 ] 2010 年 1 月 Bob Braden 从 RFC 编辑退休
[ RFC5743 ] 2009 年 12 月 互联网研究工作组文件流正式化
[ RFC-在线] 大约 2010 RFC Online Project 恢复“丢失”的早期 RFC 已完成
[ RFC6360 ] 2011 年 8 月 FYI子系列结束
[ RFC6410 ] 2011 年 10 月 两阶段标准流程正式化
[ RFC6635 ] 2012 年 6 月 更新了分配给 RFC Series Editor、RFC Production Center 和 RFC Publisher 的 RFC Series 职责
[ RFC6949 ] 2013 年 5 月 RFC 格式变更项目启动
[ RFC8153 ] 2017 年 4 月 RFC 在发布时不再打印到纸上

3.观点

   3.1 RFC 的起源 - Stephen D. Crocker

      （这是对 30 多年前[ RFC1000 ]中包含的材料的修订）

　　互联网社区现在包括数百万个节点和数十亿用户。它的起源要归功于 ARPANET，在高级研究计划署 (ARPA) 的 J. C. R. Licklider、Bob Taylor 和 Larry Roberts 眼中，它曾经只是一线希望。虽然大部分开发都按计划进行，但协议的初始设计和 RFC 的创建在很大程度上是偶然的。

　　1968 年夏天开始采购 ARPANET；还记得越南、花儿、孩子等吗？之前已经在各个 ARPA 站点进行了将计算机系统连接在一起的实验，但这是第一个探索分组交换作为通信策略核心部分的版本。（“ARPA”直到 1972 年才成为“DARPA”（国防高级研究计划署）。它在 1993 年短暂改回 ARPA，然后又改回 DARPA。）政府的报价请求（RFQ）要求四个数据包-交换设备，称为接口消息处理器（“IMP”），将被传送到美国西部的四个地点：加利福尼亚大学洛杉矶分校（UCLA）；加利福尼亚州门洛帕克的 SRI 国际（斯坦福研究所）；加州大学圣巴巴拉分校（UCSB）；和盐湖城的犹他大学。这些站点分别运行科学数据系统 (SDS) Sigma 7、SDS 940、IBM 360/75 和 DEC PDP-10。这些机器不仅有不同的操作系统，甚至字符集和字节大小等细节也各不相同。其他网站会有进一步的变化。这些机器不仅有不同的操作系统，甚至字符集和字节大小等细节也各不相同。其他网站会有进一步的变化。这些机器不仅有不同的操作系统，甚至字符集和字节大小等细节也各不相同。其他网站会有进一步的变化。

　　重点是数据的基本移动。ARPANET 的确切用途没有事先说明，因此需要研究界采取一些主动行动。为了促进这一进程，1968 年 8 月召开了一次会议，会议由来自 SRI 的 Elmer Shapiro 主持，来自选定地点的代表。根据夏皮罗在那次会议上的记录，与会者是来自 SRI 的 Dave Hopper 和 Jeff Rulifson；来自圣巴巴拉的 Glen Culler 和 Gordon Buck；来自犹他州的 R. Stephenson、C. Stephen Carr 和 W. Boam；加州大学洛杉矶分校的 Vint Cerf 和我；以及来自潜在未来网站的其他一些人。

　　第一次会议是开创性的。我们有很多问题。IMP 和“主机”（我想那是我第一次接触到这个词）是如何联系起来的？主持人会互相说什么？将支持哪些应用程序？唯一具体的答案是远程登录以替代拨号、基于电话的交互式终端访问和文件传输，但我们知道愿景必须更大。我们发现自己在想象各种可能性：交互式图形、合作流程、自动数据库查询、电子邮件等，但没有人知道从哪里开始。我们不确定是否真的有空间来认真思考这些问题。肯定是高级主管，可能来自东方，会逐渐带来这个词。但我们确实得出了一个结论：我们应该再次见面。在接下来的几个月里，我们在每个站点都会见面，从而开创了定期面对面会议的先例。我们也立刻感受到了讽刺。这个新网络应该可以让远距离合作成为可能，而我们做的第一件事就是安排大量的旅行。

　　在接下来的几个月里，来自前四个站点的一小部分相当一致的研究生和工作人员会面。我们使用术语网络工作组 (NWG) 来指定我们自己。这与 Elmer Shapiro 在召开我们第一次会议时使用的术语相同，尽管在此之前它一直用于指代主要调查人员和 ARPA 人员：一直在规划网络的高级人员。我们的小组是初级小组，与前一组脱节，当然，除了我们每个人都为一位主要调查员工作。

　　最初的几次会议非常艰难，主要是因为我们不确定我们的目标应该是多窄多远。我们没有正式的章程或领导，至少在我看来，是否有人或某个团体会以官方权力和责任出现来接管我们正在处理的问题仍然不清楚。如果没有明确定义主机-IMP 接口的外观，甚至没有准确定义 IMP 将提供什么功能，我们就专注于更广泛的想法。我们设想了应用程序特定协议的可能性，将代码下载到用户站点，并且我们尝试设计一种语言来支持这一点。第一个版本被称为 DEL，代表“解码-编码语言”

　　1968 年末，马萨诸塞州剑桥市的 Bolt Beranek 和 Newman (BBN) 赢得了 IMP 的合同，并于 1969 年 1 月开始工作。我们中的一些人于 2 月中旬飞往波士顿与 BBN 工作人员会面。由 Frank Heart 领导的 BBN 成员包括 Bob Kahn、Severo Ornstein、Ben Barker、Will Crowther、Bernie Cosell 和 Dave Walden。他们是有组织的、专业的和专注的。他们首先关心的是如何满足他们在 9 月初向 UCLA 交付第一个 IMP 的合同时间表，以及如何让钻头快速可靠地流动。主机-IMP 接口的细节尚未确定；几个月后，该规范以 BBN 报告 1822 的形式出现。特别是，BBN 没有接管我们的协议设计过程，也没有出现任何其他权威来源。因此，我们顽固地继续辩论和设计协议。

　　一个月后，我们的小型 NWG 在犹他州相遇。随着会议接近尾声，我们很清楚应该开始写下我们的讨论。我们积累了一些关于 DEL 的设计和其他事项的笔记，我们决定将它们放在一个笔记中。我们为每个人分配了写作任务，我承担了组织笔记的额外任务。虽然我发起了 RFC，但我的角色远不及编辑。每个 RFC 都按顺序编号。我强加的唯一规则是在我分配数字之前必须完成注释，因为我想尽量减少序列中的孔数。

　　我尝试了几次写笔记，说明笔记将如何组织，但我发现自己充满了恐惧。这些笔记会不会看起来好像我们在宣扬我们没有的权威？我们会无意冒犯官方协议设计者吗？终于睡不着了，写了几句不起眼的文字。基本的基本规则是任何人都可以说任何事情，并且没有任何事情是官方的。为了强调这一点，我使用了 Bill Duvall 的建议并将注释标记为“征求意见”。我从没想过这些笔记最终会通过我们在这些笔记中讨论的媒介分发：谈论魔法师的学徒！（见[学徒]。）

　　在 BBN 将 IMP 硬件和软件接口的规范分发给最初的 ARPANET 站点之后，我们的注意力转移到了低层次的事情上。自动下载代码的雄心勃勃的想法消失了。移动代码、远程过程调用、ActiveX、JAVA 和具象状态传输 (RESTful) 接口之类的想法出现还需要几年时间。

　　那年春夏两季，我们都在努力解决协议设计的细节问题。尽管我们对计算机间通信的巨大潜力有远见，但设计可用的协议是另一回事。我们知道我们设计的任何东西都需要在操作系统中添加自定义硬件接口和自定义软件，我们预计这些会给每个站点带来一些困难。我们寻找现有的抽象来使用。如果我们可以让网络简单地看起来像一个普通设备，例如磁带驱动器，那会很方便，但我们知道那是行不通的。这个网络的本质是机器之间的点对点合作以及在其中运行的进程，不是控制相关设备的中央机器。我们选择了一个虚拟比特流层作为协议的基本构建块；但即使在那时，我们也知道某些应用程序（如语音）可能需要避开该层软件。（为什么要用虚拟比特流而不是虚拟字节流？因为每台计算机都有自己的概念，即一个字节中有多少比特。直到几年后，8 位字节才成为标准。）

　　在接下来的两年里，我们开发、交流和实施了想法。1971 年 6 月，我从加州大学洛杉矶分校（UCLA）休假，在 ARPA 工作。Jon Postel 在接下来的 27 年里接管了 RFC 的管理和提供工作，改进了流程并增加了合作者。

　　网络和工作组的快速增长也导致了大量的 RFC。当第 100 个 RFC 出现时，麻省理工学院研究机构 (MITRE) 的佩吉·卡普 (Peggy Karp) 承担了为它们编制索引的任务。那时这似乎是一项艰巨的任务，我们几乎无法预料几年后会看到超过 1000 个 RFC 以及更晚向 Internet-Drafts 的演变。

　　当我们第一次开始研究协议时，网络并不存在。除了我们偶尔的面对面会议之外，RFC 是我们唯一的交流方式。在[ RFC0003 ]中，我将标准设置得尽可能低：

　　NWG 注释的内容可以是与 HOST 软件或网络其他方面相关的任何想法、建议等。鼓励笔记及时而不是修饰。没有示例或其他细节的哲学立场，没有介绍性或背景说明的具体建议或实施技术，以及没有任何尝试答案的明确问题，都是可以接受的。NWG 注释的最小长度是一个句子。

出于两个原因，明确说明了这些标准（或缺少这些标准）。首先，存在将书面声明视为事实上的权威的趋势，我们希望促进远低于权威的观点的交流和讨论。其次，对于发表一些未经修饰的东西，自然会犹豫不决，我们希望能缓解这种抑制。

　　使 RFC 变得非正式不仅是一种鼓励参与的方式；这对于使交流有效也很重要。其中一位早期参与者表示，他在编写和发送 RFC 时遇到了麻烦，因为他的机构希望对它们进行发布审查。我声明，这些不是“出版物”，问题就消失了。另一个小细节，本能地处理，没有争论，是分配模型。每个机构都必须直接向其他少数参与机构发送一份副本。每个机构自己处理内部副本和分发。无需向中心点提交重新分配，以尽量减少延误。然而，SRI 的网络信息中心，

　　我们并没有刻意挑战现有的标准组织，但我们的自然运作模式产生了一些惊人的结果。RFC 在两个重要方面是开放的：任何人都可以免费编写一个，任何人都可以免费获得它们。当时，几乎每个 ARPANET 社区的人都是由政府赞助的，因此几乎没有竞争，也没有必要使用文件来筹集资金。当然，只要我们有电子邮件在 ARPANET 上工作，我们就会以电子方式分发 RFC。当 ARPANET 成为 Internet 的一部分时，这种分发过程就变成了全球性的。这种开放的效果常常被忽视。即使是现在，全世界的学生和年轻的专业人​​士都能够下载 RFC，了解其中的技术，进而构建最令人惊叹的软件。（它们也是历史学家的绝佳资源。）

　　它会在哪里结束？ARPANET 诞生了 Internet，底层技术从最初的主机-主机协议过渡到 TCP/IP。但是，协议层的上层结构、社区驱动的协议设计和 RFC 仍在继续。通过物理层技术的改变，导致速度从每秒数千比特增加到数十亿比特，同样从数千到数十亿用户，这个上层结构，包括 RFC，继续为社区服务。所有的计算机都发生了变化，所有的传输线也发生了变化，但 RFC 继续前进。也许我会为 RFC 10,000 写几句话。

　　很明显，情况发生了变化。电子邮件和其他媒体最常用于即时交流早期想法。Internet-Drafts 是交换实质性（尽管有时是推测性）内容的手段，而 RFC 则保留用于完全完善、审查、编辑和批准的规范。不要求对 RFC 进行评论，尽管与使用相关的讨论和邮件列表上的其他评论仍然经常发生。我没有哀叹这种变化，而是将其视为适应的一个显着例子。RFC 继续为协议开发社区服务。事实上，它们是推动和引导互联网革命的充满活力和富有成效的过程的基石。

3.2. RFC 管理和编辑团队 - 由 Vint Cerf

        正如史蒂夫克罗克在第 3.1 节中提到的那样, Jon Postel 于 1971 年在史蒂夫离开加州大学洛杉矶分校前往 ARPA 时担任 RFC 经理的角色。除了随后的“数字沙皇”职责外，乔恩还担任了这个角色。最初，他的重点主要是为有抱负的作家分配 RFC 编号，但随着时间的推移，随着 ARPANET 和 Internet 协议的标准化持续快速发展，他开始担任编辑职务。此外，作为一名有成就的软件工程师，除了写作风格之外，他对技术内容也有自己的看法，并且在即将出版的作者提出他们的产品供他审查时毫不犹豫地行使编辑自由裁量权。随着负荷的增加，他招募了更多的“志愿者”人才，最著名的是乔伊斯·K·雷诺兹，USC/ISI 的研究员。在随后的几年里，他还把罗伯特（鲍勃）布拉登选入了球队，当乔恩在 1998 年 10 月意外去世时（见[ RFC2468 ]），Joyce 和 Bob 接替他继续 RFC 工作，并将 Sandy Ginoza 添加到团队中。在 Jon Postel  和 Joyce 密切合作的那段时间里，Joyce 会挑战我告诉我哪些剪辑是 Jon 做的，哪些是她做的。我发现这是不可能的，他们的编辑感受是如此一致。可悲的是，这些不知疲倦的 Internauts 中有 3 人已经去世，我们只有他们共同工作的产物以及 Sandy Ginoza 和其他人的企业记忆来回忆历史。

3.3. 形式化 RFC 编辑器模型 - Leslie Daigle

　　我是互联网架构委员会的主席，该委员会负责对 RFC 系列进行总体监督，处于所有互联网技术机构发展的特定转折点。为了理解我们做了什么，以及为什么我们必须这样做，让我首先描绘这些机构的弧线的更广泛的画面。

　　与 00 年代中期担任决策角色的许多其他人一样，互联网诞生时我并不在场。传给我的传说是，在开发核心规范和确定互联网方向的一群才华横溢的研究人员中，不同的人加紧担任必要的角色，以保持规范开发过程的有序和开放。随着规范工作的扩展，这些人普遍得到了本着同样精神的组织的支持。这主要是 Jon Postel，负责管理名称和号码的分配和分配，以及担任 RFC 的编辑，但也有个人和机构支持 IETF' s 秘书处职能。到了 20 世纪后期，即使是这种模型也已经变得单薄了。支持功能正在增长，组织没有能力捐赠更多的资源来运行它们。在某些情况下 (IANA)，该功能及其中立性在行业和国际上存在很大的依赖性。

　　IETF 在规模、地位和商业依赖方面也有所增长。这种“飞速发展”的机构部分系统没有提供 IETF 所需的那种合同规则或集成开发。那些在机构发展过程中没有去过那里的人，包括 IETF 的决策者，并没有天生理解为什么事情“必须是这样”，并且在尝试更新单个系统以满足新要求以及更好时感到沮丧整合到各种活动中。

　　互联网工程已经扩展到可以由一组松散耦合的组织提供支持，这些组织从一开始就在那里并且彼此非常了解。需要新的治理形式以及合理的筹资模式。IANA 职能被吸收到一个专门建立的国际非营利组织中。IETF 加紧管理自己的组织命运，创建了 IETF 行政支持活动 (IASA)，秘书处成为其签约职能之一。

　　这使得 RFC Editor 功能成为 Internet Society 支持的独立工作。

这种独立性对于 RFC 系列在考虑所有技术贡献方面的历史作用是必要的。但是，在系列历史的那个转折点，它需要一个新的治理和资金模式，就像支持互联网技术规范的其他组织一样。此外，IETF 领导层有一些担忧，认为需要在其自己的技术出版物流中加以解决。虽然 RFC 系列是在 IETF 出现之前建立的，并且历史上一直在其中包含并非源自 IETF 的文档，但 IETF 是其最大和最有组织的贡献者。没有特定的独立贡献者组织。一样，RFC 编辑的资金当时来自互联网协会，打着“支持 IETF”的幌子。对于从一开始就没有参与该机构的人来说，很容易将 RFC 系列视为 IETF 的出版物系列。因此，挑战在于识别和解决 IETF 的问题以及治理和资金问题，同时又不牺牲 RFC 系列作为比 IETF 更广泛的出版物系列的基本性质。

　　为了让人们了解当时普遍存在的那种紧张局势，让我分享一下那些讨论中留在我脑海中的一句话是“推动出版”。IETF 领导层中的一些人认为，如果 RFC 可以通过在 IESG 批准的那一刻按下 Web 界面上的按钮来发布，将会显着降低成本并提高及时性。他们认为，这还将消除由复制编辑引入的规范问题，这些编辑作为临时工被雇用来帮助提高出版率，但他们不一定在技术规范的艺术方面跟上进度。

　　从制度上讲，目标是在互联网技术社区（而不是任何特定的私人组织）的范围内实现 RFC 编辑器功能治理，而不是专门将其与 IETF 绑定。这可以通过确保在 IAB 的监督下建立生成的部分来合理地实现（它本身独立于 IETF，即使它得到 IASA 组织的支持）。

　　IETF 编写了一份概述其技术规范出版物的功能要求的文件。这可能有助于建立自己的系列，但也有助于建立对文档发布挑战的认识（当你没有想到它时它总是看起来很容易），也有助于为与 RFC 的对话奠定基础编辑。需求文档以[ RFC4714 ]作为信息 RFC 发布，如今它为围绕 IETF 出版物的编辑过程提供指导。

　　然而，对于 RFC 系列本身的决策和变更的责任仍然缺乏明确性。为此，我和 IAB 与各相关方合作制作[ RFC4844 ]. 该文档记录了 RFC 系列任务（其目的比 IETF 技术规范出版物更重要）以及相关各方的角色和责任。RFC Editor 负责确保任务的执行。IAB 继续承担监督职责，包括政策监督，它可以通过改变 RFC 编辑角色的人（组织）来采取行动。同时，操作监督被转移到 IETF（和 IAB）的 IASA 支持功能。

　　讨论，以及由此产生的[ RFC4844 ]出版物，使人们对 RFC 系列作为一般互联网出版物有了更大的了解和承诺。这也意味着可以随着需求的变化进行后续调整；责任方明确。

3.4. 溪流的延续或创造——内维尔·布朗利

　　可以说从 2006 年的[ RFC4714 ]开始，IAB 和 IETF 社区在 00 年代中期花了一些时间来发展 RFC 系列的结构。这项工作包括定义那些发布到 RFC 系列（最初包括 IETF、IAB [ RFC4845 ]和独立提交流[ RFC4846 ]，后来发展到包括 IRTF [ RFC5743 ]）的小组如何处理批准文件以以 RFC 形式发布。2009 年，IAB 发布了“RFC Editor Model (Version 1)” [ RFC5620 ]. 在此模型中，在 RFC 编辑器中创建了一个新角色：RFC 系列编辑器 (RSE)。此人将监督 RFC 的发布和开发，同时将批准文件发布的流程留在其职责范围之外。虽然可以说，这是一个长期由 Jon Postel、Bob Braden 和 Joyce Reynolds 等人担任的角色，但 [ RFC5620 ]看到 RFC Series Editor 的角色被定义为将其与独立提交编辑器的角色明显区分开来（伊势）。

在 2009 年之前，RFC 编辑可以接受来自个人的“独立”提交，如果它们被判断为重要，则将它们作为 RFC 发布；建立独立流以继续该功能。从 2010 年 2 月到 2018 年 2 月，我是 ISE。在阅读 了[ RFC4846 ]之后，我继续开发独立流 (IS)。

　　首先，我与 RFC 编辑 (Bob Braden)、Sandy Ginoza 和 Alice Hagens 在 Marina Del Ray 的信息科学研究所 (ISI) 的 RFC 生产中心呆了几天，以了解 RFC 的实际编辑和发布方式。所有 RFC 都以 Internet-Drafts 的形式到达生产中心；他们被复制编辑，直到编辑的版本可以得到其作者的批准（AUTH48）。在任何阶段，作者都可以通过 RFC Editor 网站检查他们的草稿状态。

　　对于独立投稿，Bob 为每个草稿保留了一份日志（一个简单的 ASCII 文件），记录了他与作者的互动，并按草稿名称索引。Bob 还将独立草稿输入 RFC Editor 数据库，以便作者可以跟踪草稿的状态。在我和他的团队在 ISI 呆了几天之后，他把那本杂志（大约 30 份草稿）交给了我，并说：“现在交给你了！” 

　　我开始追随 Bob 的脚步，维护期刊并在 RFC Editor 数据库中跟踪每个草稿的状态。我的第一个考虑是提交的每一份严肃的互联网草案都需要多次仔细审查。那时，如果 ISE 知道合适的审稿人，他或她可以简单地询问他们。否则，如果草案与 IETF 或 IRTF 工作组有关，ISE 可以要求工作组主席或区域主任推荐审稿人。独立提交编辑委员会 (Ed Board) 是 ISE 可以要求审稿人的另一个地方。我与审稿人的经验是，我接触过的大多数人都很乐意提供帮助。

　　大多数草稿都很简单，但有些草稿需要额外注意。通常，草案要求 IANA 代码点，为此，IANA 总是迅速提供帮助和支持。一些 IANA 注册管理机构中的代码点需要专家评审[ RFC8126 ]；有时与专家审稿人的互动需要很长时间！同样，有时草案似乎更适合 IETF 流；对于这些，我建议草稿作者尝试寻找一位区域主管来赞助他们的工作，作为个人提交给 IETF 流。

　　在我担任 ISE 的最初几年之后，IETF 工具团队开发了 Datatracker [ DATATRACKER ]来显示草稿状态并为所有流执行所有“内务管理”任务。在那个阶段，我转而使用 Datatracker 而不是 RFC Editor 数据库。

　　一旦草稿经过审查并且作者在与他们的审稿人对话中对其进行了修改，ISE 必须将该草稿提交给 IESG 进行“IESG 审查” [ RFC5742 ]。总的来说，每个 IS 草案都受益于与我的编委和 IESG 的讨论（通常很简单）。A（非常）很少有争议；对于那些，我能够与 IESG 合作协商一个合适的“IESG 声明”和/或“ISE 声明”，以明确 ISE 发布该草案的原因。

　　独立流的一个相当特殊的部分是 4 月 1 日的 RFC。这些是幽默的 RFC，没有正式的审查和批准流程。作者必须将它们直接发送给 ISE 或 RFC 编辑器。每年只能发布其中的少数，并且每个都由 ISE 和 RSE 审查。Bob Braden 对 4 月 1 日草稿的标准是：

  • 它们必须与 Internet 相关（就像所有草稿一样）。
  • 他们的读者应该在意识到它是 4 月 1 日的 RFC 之前到达第二页的末尾。
  • 他们一定很有趣！

　　4 月 1 日 RFC 拥有大量追随者，每年 4 月 1 日来自 Internet 社区的反馈非常热情且迅速！

　　在我担任 ISE 的八年期间，159 个 RFC 在独立流中发布。在这八年中，我与他们的大多数作者一起工作，并经常在 IETF 会议上与他们会面。对我来说，这是一次非常有益的经历，所以我感谢所有做出贡献的人。在这八年里，我也和 IESG 的大部分成员一起工作，他们也给了我很多有益的互动。最后，我一直很喜欢与 RSE 和 RFC 制作中心的所有员工一起工作。IETF（作为一个整体）非常幸运能够拥有这样一支由才华横溢的专业员工组成的高效团队。

3.5. RFC 编辑器内部的视图 - Sandy Ginoza

　　当我加入 ISI 时，在 Jon Postel 去世后不久，我们今天所知道的 RFC 编辑器模型（在 [RFC5620] 中定义并被[ RFC6548 ]和[ RFC6635 ] 淘汰）并不存在。RFC 编辑器作为一个单元发挥作用：没有 RSE、生产中心、出版商或独立提交编辑器。所有这些角色都由“RFC 编辑”执行，该编辑由四个人组成：Bob Braden、Joyce Reynolds、兼职学生程序员和我。

　　Bob 提供了高级指导并审查了独立提交的内容。虽然 Bob 是 ISI 的“Div 7”（网络）研究员，表面上看，他用于 RFC 编辑器的时间百分比是 10%，但他投入了更多时间来保持系列的运行。他尽其所能，尤其是在处理时间越来越长的情况下。有一次，他甚至 NROFFed 了几个 RFC。

　　乔伊斯是一名全职 ISI 员工。然而，在继续确保发布 RFC 的同时，她还担任用户服务领域主管和互联网主题演讲者，在 IANA 分离后成立期间，她还临时借用了 IANA 50% 的时间来自 ISI。学生程序员按要求执行编程任务，当时负责解析 MIB。

　　我是一名全职员工，必须快速掌握诀窍，以便继续发布 RFC。我的主要任务是管理发布队列、格式化和准备文档以供 Joyce 审阅，在 Joyce 完成审阅后执行 AUTH48，以及发布、索引和存档 RFC（软拷贝和硬拷贝）。

　　在接下来的几年里，工作量显着增加。随着工作量的增加，RFC 编辑做出了反应，并随着时间的推移慢慢增加了他们的员工。要了解团队的成长，我们先来看看历史上的发表率。下表显示了 5 年期间的平均年出版率。

表 2： 年出版率
年平均 每年的酒吧
1969 - 1972 80
1973 - 1977 55
1978 - 1982 20
1983 - 1987 39
1988 - 1992 69
1993 - 1997 171
1998 - 2002 237
2003 - 2007 325
2008 - 2012 333
2013 - 2017 295

　　上世纪 90 年代及以后的发表率显着提高，1993 年至 2007 年期间发表数量几乎翻了一番。2004 年，年度提交数量首次超过 300 份，并达到 385 份的历史新高在 2011 年。提交率直到 2016 年（284）才下降到 300 以下。

　　随着提交的数量增加，RFC 编辑经历了成长的痛苦。由于现有员工无法跟上不断扩大的队列规模，处理时间开始增加。为了减少培训难度并避免在提交突发事件是侥幸的情况下永久雇用员工，ISI 聘请了临时文案编辑；这样，员工可以根据需要轻松调整大小。然而，正如 Leslie 所指出的，这并没有很好地工作。实验的效果将是持久的，因为这导致了我们现在拥有的流程形式，RFC 编辑在 AUTH/AUTH48 期间提出更多问题，技术变更需要相关区域主管或流经理的批准，具体取决于文档流。这些变化增加了工作量并延长了出版时间；

　　除了文档提交的增加外，我们还进行了工具测试，并经历了几次编辑流程变更。由于从临时文案编辑中吸取了教训，我们的团队变得更加固定。虽然我们在其间添加了其他编辑器，但其中有两个特别有趣，因为他们经历了 RFC 编辑器成长的大部分痛苦，帮助我们摆脱了积压状态，塑造了 RFC 编辑器功能，并且至今仍在团队中：Alice Russo 于 2005 年加入团队，Megan Ferguson 于 2007 年加入我们

　　我们了解到创纪录的提交数量并非异常，我们对 RFC 编辑器功能的基础架构进行了重大升级，以促进文档跟踪和报告。例如，著名的“黑色活页夹”（用于跟踪 RFC 编号分配的实际 3 环活页夹）、用于队列页面的手动编辑的 HTML 文件，以及创建队列统计的 Rube Goldberg 文本文件和脚本集，所有最终被替换；提出并实施了勘误表系统；XML 成为新近接受的源文件。

　　2009 年，[ RFC5620 ]发布，介绍了我们现在拥有的 RFC 编辑器模型的初始版本。虽然它于 2009 年发布，但直到 2010 年才生效，当时我所知道的 RFC Editor 项目被解散并分为四个部分：RFC Series Editor (RSE)、Independent Submissions Editor (ISE)、RFC Production Center (RPC) 和 Publisher 功能。此外，创建 RFC 系列咨询小组 (RSAG) 的目的是“就影响 RFC 系列运营和开发的事项提供专家、知情的指导（主要是向 RSE）” [ RSAG ]。

　　2010 年，RPC 和 Publisher 合同被授予 Association Management Solutions (AMS)。在那里，我们从现有的三名团队成员（Alice Russo、Megan Ferguson 和我）开始，我们很高兴有新同事 Lynne Bartholomew 和 Rebecca VanRheenen 加入到 AMS 办公室。

　　我对这个模型很警惕，特别担心鲍勃布拉登的离开会造成的空洞。对我们来说幸运的是，鲍勃布拉登在过渡期间（及以后）提供了明智的建议和洞察力。他给了过渡到 AMS 的员工特别有用的告别词，“让 RFC 不断涌现”，这就是我们所做的。

　　AMS 采用 RFC 系列并帮助我们快速设置新服务器。RFC Production Center 和 Publisher 现在是 AMS 家族的一部分，他们全力以赴，确保过渡顺利进行，以尽量减少对文档处理的影响。

　　我们在过渡期间的重点是 1) 保持列车运行；也就是说，我们希望以最少的停机时间启动和运行，2) 与过渡性 RSE（在过渡结束前结束的角色）、ISE (Nevil Brownlee)、RSAG 和 IETF 行政总监合作（ IAD）以更好地理解和实现新定义的 RFC 编辑器模型。

　　尽管过渡的某些部分具有挑战性并且持续的时间比预期的要长，但代理 RSE (Olaf Kolkman) 于 2012 年正式将缰绳移交给新的 RSE (Heather Flanagan)。她必须加入，学习 RFC 编辑和 IETF 文化，并解决积压的问题，而这些问题一直无人看管。

　　其中两个积压的问题太老了，以至于有人在我第一次 IETF 会议上问过我：RFC 编辑器什么时候允许在 RFC 中使用非 ASCII 字符？RFC 编辑器何时会采用更现代的发布格式？

　　那时，虽然我们理解希望支持更广泛的字符集并拥有更现代的输出，但我们也经常收到来自个人的电子邮件，要求我们向他们发送纯文本文件（而不是指向网站），因为他们的互联网访问受到限制。我们还经常收到来自< https://www.rfc-editor.org >用户的投诉， 只要网站上的某些内容无法在旧版浏览器中正常运行。简而言之，如果不留下大量用户，我们就无法前进。

　　然而，我们现在发现自己处于变革的边缘。随着我们从发布纯文本、仅 ASCII 文件过渡到发布允许非 ASCII 字符和SVG 艺术。

　　有趣的是，我发现自从我加入团队以来，RFC 编辑器一直处于几乎不断变化的状态，尽管 RFC 编辑器的目标保持不变：及时生成易于访问的归档质量 RFC后人。

4. RFC 的下一个 50 年

　　正如史蒂夫克罗克所提到的，该系列的目标是沟通而不是形式和开放而不是结构。随着互联网的发展并成为一个普遍的全球性结构，我们仍然以开放和通信为目标，但要认识到，要支持互操作性的协议和其他信息，必须有稳定点可以构建。从小型应用程序开发人员到价值数十亿美元的公司，每个人都处于同一立场。任何人都应该能够回顾某个时间点并了解所做的事情和原因。

　　虽然非正式已经让位于增加的结构，但该系列提供的开放性和坚实基础必须继续下去。考虑到这一点，未来 50 年的 RFC 会如何发展？

4.1。保存

　　RFC 编辑器的存在是为了编辑、发布和维护 RFC 系列中发布的文档的存档。然而，正确的数字存档不仅仅是将 RFC 保存到磁盘并确保磁盘已备份；数字保存领域已经发展并转变为一个行业。“RFC 系列的数字保存注意事项” [ RFC8153 ] 回顾了数字档案在今天的意义，并描述了在未来支持档案的方法。它还推荐了 RFC 编辑器利用那些专门从事该领域的组织的方法。

　　就 RFC 系列而言，数字保存的未来将意味着寻找新的合作伙伴，将 RFC 吸收并存档到公共的、维护的数字档案中，并审查 RFC 格式以确保发布的文档可以根据任何行业最佳实践是随着时间的推移。

4.2. RFC 格式的演变

　　RFC 在本系列的早期就一直是数字文档。虽然并不总是以 US-ASCII 格式发布，但该格式几十年来一直是规范格式。这种格式经历了如此多的演变和变化，这一事实令人瞩目。

　　不幸的是，US-ASCII 格式的扩展不足以满足当今许多用户的期望和要求。在某些情况下，在线文档呈现、消费和保存的整个领域只是在第一个 RFC 发布数年后才发明出来的。虽然可以（并且一直）认为那些较新的领域及其工具没有机会经受住时间的考验，但 RFC 系列编辑器（与社区协商）在 2012 年开始齐心协力将 RFC系列与一系列新的保存和展示可能性保持一致。

　　在[ RFC7990 ]中可以找到有关 RFC 格式项目的信息以及正在进行的更改的初始推理和要求。随着这些变化的出现，随着数字资料存档规范的发展以及对 Web 开发的期望的提高，考虑未来进一步变化的大门已经打开。

  4.3. 流结构

　在许多人的眼中，尤其是在 IETF 内部，RFC 系列是 IETF 的同义词。虽然该系列本身比 IETF 早了 18 年，但随着时间的推移，IETF 已成为提交给 RFC 编辑发布的大多数文件的来源。为 IETF 流草稿制定的政策往往适用于所有四个文档流，与出版物相关的工具往往将 IETF 视为其使用的主要受众。人们很难看出系列和 IETF 之间是如何，甚至是为什么存在区别。

　我们现在比以往任何时候都更关心这个问题。系列的未来是什么？如果人们不知道 IETF 在哪里结束而 Series 从哪里开始，我们是否应该认为这是一种人为的区分并宣布它们是同一个实体？

　　最终，这将是社区决定的事情，并且正在进行对话以考虑可能的变化的后果。

  5.结论

　随着互联网的发展，期望和可能性也在发展。在接下来的 50 年里，该系列将继续展示在忠实于出版和保存的原始使命的需求之间的平衡，同时也与 RFC 的作者和消费者的需求保持相关。平衡这些需求的压力取决于 RFC 编辑器和社区来解决。我们不会缺少挑战。

  6. IANA 考虑事项

    本文档没有 IANA 操作。

  7.安全考虑

  本文档没有安全考虑。

  8.参考资料

[APPRENTICE]
维基百科，“魔法师的学徒”，2019 年 12 月, < https://en.wikipedia.org/w/index.php?title=The_Sorcerer%27s_Apprentice&oldid=925824658 > .
[DATATRACKER]
互联网工程任务组，“IETF Datatracker”，< https://datatracker.ietf.org >。
[IAB-19880712]
IAB，“IAB 会议纪要 1988-07-12”，1988 年 7 月, < https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-07-12/ > .
[IETF1]
MITRE 公司，“1986 年 1 月 16 日至 17 日 DARPA 网关算法和数据结构工作组会议记录”，IETF 1 ，1986 年 1 月, < https://www.ietf.org/old/2009/proceedings/prior29/IETF01.pdf > .
[ISI 到 AMS]
IETF 行政支持活动 (IASA)，“Association Management Solutions, LLC 和互联网协会之间的 RFC 生产中心协议”，2009 年 10 月, < https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-2009.pdf > .
[RFC-在线]
RFC 编辑器，“RFC 在线项目的历史”，2000，< https://www.rfc-editor.org/rfc-online-2000.html >。
[RFC0001]
Crocker, S.，“主机软件”，RFC 1，DOI 10.17487/RFC0001，1969 年 4 月, < https://www.rfc-editor.org/info/rfc1 > .
[RFC0003]
Crocker, S.，“文档约定”，RFC 3，DOI 10.17487/RFC0003，1969 年 4 月, < https://www.rfc-editor.org/info/rfc3 > .
[RFC0114]
Bhushan, A.，“文件传输协议”，RFC 114，DOI 10.17487/RFC0114，1971 年 4 月, < https://www.rfc-editor.org/info/rfc114 > .
[RFC0433]
Postel, J.，“套接字号列表”，RFC 433，DOI 10.17487/RFC0433，1972 年 12 月, < https://www.rfc-editor.org/info/rfc433 > .
[RFC0690]
Postel, J.，“对提议的主机/IMP 协议更改的评论”，RFC 690，DOI 10.17487/RFC0690，1975 年 6 月, < https://www.rfc-editor.org/info/rfc690 > .
[RFC0748]
Crispin, M.，“Telnet 随机丢失选项”，RFC 748，DOI 10.17487/RFC0748，1978 年 4 月, < https://www.rfc-editor.org/info/rfc748 > .
[RFC0902]
Reynolds, J.和 J. Postel，“ARPA 互联网协议政策”，RFC 902，DOI 10.17487/RFC0902，1984 年 7 月, < https://www.rfc-editor.org/info/rfc902 > .
[RFC1000]
Reynolds, J.和 J. Postel，“征求意见参考指南”，RFC 1000，DOI 10.17487/RFC1000，1987 年 8 月, < https://www.rfc-editor.org/info/rfc1000 > .
[RFC1083]
国防高级研究计划局和互联网活动委员会，“IAB 官方协议标准”，RFC 1083，DOI 10.17487/RFC1083，1988 年 12 月, < https://www.rfc-editor.org/info/rfc1083 > .
[RFC1122]
Braden，R.，Ed。, "Internet 主机要求 - 通信层" , STD 3 , RFC 1122 , DOI 10.17487/RFC1122 ,1989 年 10 月, < https://www.rfc-editor.org/info/rfc1122 > .
[RFC1123]
Braden，R.，Ed。, "Internet 主机要求 - 应用和支持" , STD 3 , RFC 1123 , DOI 10.17487/RFC1123 ,1989 年 10 月, < https://www.rfc-editor.org/info/rfc1123 > .
[RFC1150]
Malkin, G.和 J. Reynolds，“FYI on FYI: Introduction to the FYI Notes”，RFC 1150，DOI 10.17487/RFC1150，1990 年 3 月, < https://www.rfc-editor.org/info/rfc1150 > .
[RFC1311]
Postel, J.，“STD 说明简介”，RFC 1311，DOI 10.17487/RFC1311，1992 年 3 月, < https://www.rfc-editor.org/info/rfc1311 > .
[RFC1818]
Postel, J. 、Li, T.和 Y. Rekhter，“当前最佳实践”，RFC 1818，DOI 10.17487/RFC1818，1995 年 8 月, < https://www.rfc-editor.org/info/rfc1818 > .
[RFC2441]
Cohen, D.，“与 Jon 合作，1998 年 10 月 30 日在 UCLA 发表的致敬”，RFC 2441，DOI 10.17487/RFC2441，1998 年 11 月, < https://www.rfc-editor.org/info/rfc2441 > .
[RFC2468]
Cerf, V.，“我记得 IANA”，RFC 2468，DOI 10.17487/RFC2468，1998 年 10 月, < https://www.rfc-editor.org/info/rfc2468 > .
[RFC2555]
编辑，RFC。等等。人。, "30 年 RFC" , RFC 2555 , DOI 10.17487/RFC2555 ,1999 年 4 月, < https://www.rfc-editor.org/info/rfc2555 > .
[RFC4714]
Mankin, A.和 S. Hayes，“IETF 技术出版服务要求”，RFC 4714，DOI 10.17487/RFC4714，2006 年 10 月, < https://www.rfc-editor.org/info/rfc4714 > .
[RFC4844]
Daigle，L.，Thaler。和 Internet 架构委员会，“RFC 系列和 RFC 编辑器”，RFC 4844，DOI 10.17487/RFC4844，2007 年 7 月, < https://www.rfc-editor.org/info/rfc4844 > .
[RFC4845]
Daigle，L.，Thaler。和 Internet 架构委员会，“IAB RFC 发布流程”，RFC 4845，DOI 10.17487/RFC4845，2007 年 7 月, < https://www.rfc-editor.org/info/rfc4845 > .
[RFC4846]
Klensin，J.，Thaler。和 D. Thaler，Ed。, "独立提交给 RFC 编辑器" , RFC 4846 , DOI 10.17487/RFC4846 ,2007 年 7 月, < https://www.rfc-editor.org/info/rfc4846 > .
[RFC5540]
编辑，RFC。, "40 年 RFC" , RFC 5540 , DOI 10.17487/RFC5540 ,2009 年 4 月, < https://www.rfc-editor.org/info/rfc5540 > .
[RFC5620]
Kolkman，O.，Ed。和 IAB，“RFC 编辑器模型（版本 1）”，RFC 5620，DOI 10.17487/RFC5620，2009 年 8 月, < https://www.rfc-editor.org/info/rfc5620 > .
[RFC5742]
Alvestrand, H.和 R. Housley，“IESG 处理独立和 IRTF 流提交的程序”，BCP 92，RFC 5742，DOI 10.17487/RFC5742，2009 年 12 月, < https://www.rfc-editor.org/info/rfc5742 > .
[RFC5743]
Falk, A.，“互联网研究任务组 (IRTF) 文档流的定义”，RFC 5743，DOI 10.17487/RFC5743，2009 年 12 月, < https://www.rfc-editor.org/info/rfc5743 > .
[RFC6360]
Housley, R.，“FYI RFC 子系列结论”，RFC 6360，DOI 10.17487/RFC6360，2011 年 8 月, < https://www.rfc-editor.org/info/rfc6360 > .
[RFC6410]
Housley, R. 、Crocker, D.和 E. Burger，“将标准跟踪降低到两个成熟度级别”，BCP 9，RFC 6410，DOI 10.17487/RFC6410，2011 年 10 月, < https://www.rfc-editor.org/info/rfc6410 > .
[RFC6548]
Brownlee，N.，Ed。和 IAB，“独立提交编辑器模型”，RFC 6548，DOI 10.17487/RFC6548，2012 年 6 月, < https://www.rfc-editor.org/info/rfc6548 > .
[RFC6635]
Kolkman，O.，Ed。，Halpern，J.，Ed。和 IAB，“RFC 编辑器模型（第 2 版）”，RFC 6635，DOI 10.17487/RFC6635，2012 年 6 月, < https://www.rfc-editor.org/info/rfc6635 > .
[RFC6949]
Flanagan, H.和 N. Brownlee，“RFC 系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013 年 5 月, < https://www.rfc-editor.org/info/rfc6949 > .
[RFC7990]
Flanagan, H.，“RFC 格式框架”，RFC 7990，DOI 10.17487/RFC7990，2016 年 12 月, < https://www.rfc-editor.org/info/rfc7990 > .
[RFC8126]
Cotton, M. 、Leiba, B.和 T. Narten，“在 RFC 中编写 IANA 注意事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017 年 6 月, < https://www.rfc-editor.org/info/rfc8126 > .
[RFC8153]
Flanagan, H.，“RFC 系列的数字保存注意事项”，RFC 8153，DOI 10.17487/RFC8153，2017 年 4 月, < https://www.rfc-editor.org/info/rfc8153 > .
[RSAG]
RFC 编辑，“RFC 系列咨询小组”，< https://www.rfc-editor.org/about/rsag/ >。

批准时的 IAB 成员

    • Jari Arkko
    • Alissa Cooper
    • Stephen Farrell
    • Wes Hardaker
    • Ted Hardie
    • Christian Huitema
    • Zhenbin Li
    • Erik Nordmark
    • Mark Nottingham
    • Melinda Shore
    • Jeff Tantsura
    • Martin Thomson
    • Brian Trammell

致谢

非常感谢 John Klensin 对系列历史的反馈和见解，他直接参与并影响了许多参与开发 RFC 系列的关键人物。

还要感谢 RFC 系列咨询小组和独立投稿编辑委员会的成员，特别是 Scott Bradner、Brian Carpenter 和 Adrian Farrel，感谢他们对系列历史上一系列关键时刻的早期评论和投入。

贡献者

非常感谢 Steve Crocker、Vint Cerf、Leslie Daigle、Nevil Brownlee 和 Sandy Ginoza 对系列赛的看法和他们的持续支持。

作者地址

希瑟·弗拉纳根（编辑）
RFC 编辑器
网址： https ://orcid.org/0000-0002-2647-2220

 




RFC 5540
posted @ 2022-06-20 15:20  jinzi  阅读(340)  评论(0)  编辑  收藏  举报