Internet RFC简介

Internet也就是我们常说的互联网,它的标准都是以RFC文稿的方式写成的。比如说大名鼎鼎的TCP传输协议,主要是在RFC793这篇文稿里面定义的。

RFC的全称是Request For Comments。总的来说,RFC是一种流程,用于改进既有的标准。举个例子,比如有个人觉得RFC793里面所描述的TCP协议存在某些问题,于是乎他提了一个新的RFC来描述和改进这些问题。但是他所描述问题是否真的就是问题,以及他所提倡的改进方法是否有效,需要大家一起来讨论和评判。翻译成英文,这个过程就叫Request For Comments。

用网络化的用语来描述RFC,就是“我有一个好主意,不服来战”。

既然RFC是一种流程,它也不是Internet独有,好多其他就项目都采用类似的流程。比如Rust语言有Rust RFC,React JS项目有ReactJS RFC,等等等等。

根据IETF,也就是管理Internet标准的组织的要求,要进入RFC流程,首先要提交一篇Internet-Draft文稿(简称I-D文稿)。当I-D文稿被一个IETF working group接受以后,就变成了一篇Working Group Draft(简称WG Draft)。在Working Group里面经过一系列的讨论和评判,好的WG Draft会被提交,然后发布成一篇RFC文稿。重要的RFC文稿会被发布在Standard Track(标准轨道),最终变成Internet Standard,也就是互联网标准。

当然,本文不是为了介绍IETF的流程,而是为了介绍RFC文稿的写作格式。从一开始的Internet-Draft到最后发布成互联网标准的RFC文稿,它们的格式都是一样的,以下统称为RFC文稿格式

RFC文稿格式

RFC文稿都是纯文本格式的文档,而非像Word那种富文本格式的文档。早期的RFC文稿多是用Unix的文本格式化工具比如Roff生成的。Roff的原文件通常包含简单的指令,可以实现换行,或者文本居中等简单的文本格式化任务。

随着RFC2629的发布,XML成为一种RFC文稿的写作格式。基于XML的RFC文稿原文件,通过一个Python程序XML2RFC可以转化为RFC文稿。

XML作为一种中间格式的话,显得非常灵活。但是把XML作为一种书写格式,则十分让人讨厌。树形结果的XML文档不是很便于人阅读,编辑起来也很繁琐。于是乎很多人想要一种更加简单易用,并且贴近书写习惯的格式,比如Markdown。

基于Markdown的RFC文稿的工作流是这样的:

  1. 原文件用Markdown写成
  2. 通过程序把Markdown转化成XML格式
  3. 通过XML2RFC把XML格式转为最终的RFC格式

对于第二步,把Markdown转化成XML格式的程序至少有两个:

上面两者的功能类似。不同之处在对Markdown语法的支持(Markdown本身没有完全统一的标准),以及一些其他使用细节。另外从编程语言的角度,一个是基于Ruby,另一个是基于Go语言。

通过GitHub协作

我们可以通过GitHub来把RFC文稿的生成过程自动化。把Markdown文件存放在Git仓库,然后提交到GitHub,接着通过自动构建工具(比如Travis CI)完成Markdown到XML到RFC文稿的转化。

如果你要创建一个新的文稿,又不想自己做上面的设置,可以使用GitHub上一个仓库模板i-d-template。参考它的说明,可以很方便得配置好自动构建工具,然后开始文稿协作。

QUIC(谷歌主推的类似TCP的传输协议)就是采用i-d-template,它的仓库位于quicwg/base-drafts,生成的文档可以在https://quicwg.org/查看。

GitHub的PR和Issues

GitHub提供的其他两项功能也非常方便RFC文稿的写作。一个是PR(Pull Request),也就是你克隆了文稿的主仓库,然后对文稿做了一些修改,希望能够合并到主仓库中去。这时候可以提一个PR,然后主仓库的管理员接受之后就可以合并到主仓库中去了。

另一个GitHub提供的功能是Issues,可以用来对文稿发起讨论。

(完)