Rfc

如何浏览RFC无论好坏，Requests for Comments (RFCs) 是互联网上许多协定内容的具体阐明(specify)。这些文件被开发者视为圣典，他们剖析这些文件的深层含意，然而又因为无奈了解这些内容而把这些文件漠视掉或者漠视局部内容（irrelevant）,这会给人带来挫败感，更重要的是可能会造成软硬件之间的信息替换和导致平安问题。然而如果你对它们的构建和公布过程有一些理解，就会对这些内容有一个更深的理解。 上面是我依据从HTTP以及其余一些事件中得出的教训。 Where to start? - 从什么中央查找咱们须要的RFCRFC Editor Web Site 是查找RFCs文档比拟权威的中央。然而，正如咱们在上面所看到的那样这个网站短少一些要害信息，所以大多数人应用tools.inetf.org。 你能够用浏览器搜寻你想查看的RFC文档,但因为RFCs数量泛滥,(目前有近9000个),所以说找到本人所需的RFC是比拟艰难的。高效期间,你能够在 RFC Editor Web Site 网站上进行搜寻。 另一个网站是rfc.fyi,这个网站容许你按 “题目” 和 “关键词” 搜寻，能够点击界面上的一些 “标签” 快速访问一些内容。 RFC Editor Web Site 正在开发一种体验更好并带有自定义选项的新RFC格局,以此改善之前纯文本的RFC难以浏览的问题,同时,如果你想取得更多可用的RFCs，你能够应用第第三方资源库来查问;例如，greenbytes保留了一个WebDAV相干的RFCs列表,HTTP工作组也保留了一些与HTTP相干的内容。 What kind of RFC is it? RFC的类型是什么所有RFC文档顶部都有一个横幅，看起来像上面这样 下面第一行,写着 "Internet Engineering Task Force (IETF)"。这表明该文档通过了IETF审查并对该协定内容达成了共识;只管IETF并不广为人知,但还有其余办法能够公布RFC，而不须要IETF的共识；例如，独立集体或者其余个人(independent stream)。 事实上，有许多 "集体或者个人(streams)" 能够公布文件。只有 “IETF” 示意整个IETF曾经审查了该协定并发表了对该协定标准达成共识。(原文:Only the IETF stream indicates that the entire IETF has reviewed and has declared consensus on a protocol’s specification.) ...

最近读 RFC 文档的过程中，发现在过来十几年里，每年都有尝试翻译 RFC 的小伙伴，然而大家没有对立的标准，译文的组织也十分涣散，翻译的程度参差不齐。 为了可能使大家的工作成绩失去保护，并提供对译文一直迭代的可能，我最近建了一个 Github 仓库和一个网站；另外，我还翻译了几篇比拟根底的 RFC，对于 RFC 文档的精确了解和翻译都很重要。心愿通过做一点渺小的奉献，达到“前人栽树，后人乘凉”的目标。 网站的视觉效果应该会好些，应用了等宽字体，并且有中英对照；但毕竟是第一次进行网站开发，且应用的是最低配的服务器，响应工夫、页面布局会有很多问题。 https://github.com/dianbo-rfc/dianbo-rfc https://dianbo-rfc.cn/progress 上面是译文： Internet Engineering Task Force (IETF) B. LeibaRequest for Comments: 8174 Huawei TechnologiesBCP: 14 May 2017Updates: 2119Category: Best Current PracticeISSN: 2070-1721 对于 RFC 2119 中所定义的关键词, 其大小写模式的歧义性摘要 在 RFC 2119 中指定了一组用于协定标准的罕用关键词。此文档的目标是缩小 在应用这些关键词时的歧义性, 即明确阐明: 只有应用这些关键词的大写模式 时, 它们才具备所定义的非凡含意。Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8174.Leiba Best Current Practice [Page 1]RFC 8174 RFC 2119 Clarification May 2017Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.目录 1. 导言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 关键词的大写模式示意的明确阐明 . . . . . . . . . . . . . . . 3 3. IANA 注意事项 . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 平安注意事项 . . . . . . . . . . . . . . . . . . . . . . . . 4 5. 前提类参考文献 . . . . . . . . . . . . . . . . . . . . . . . 4 作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41. 导言 在 RFC 2119 中指定了一组用于协定标准的罕用关键词, 例如【必须】"MUST", 【该当】"SHOULD" 和【可能】"MAY" 等。其中提到这些关键词 "通常以大写字 母的模式呈现", 这造成了一个困惑, 即该如何解释非大写字母模式的关键词, 例如 "must" 和 "should" 等。 此文档是对 RFC 2119 的更新, 明确阐明了: 只有应用这些关键词的大写模式 时, 它们才具备所定义的非凡含意。此文档是 BCP 14 的一部分。Leiba Best Current Practice [Page 2]RFC 8174 RFC 2119 Clarification May 20172. 关键词的大写模式示意的明确阐明 对 [RFC2119] 进行如下批改: === 批改前 === 在许多规范跟踪文档中 (standards track documents), 有一些词被用来示意 标准的要求。这些词通常以大写字母的模式呈现。此文给出了这些词的定义, 即当这些词被用于 IETF 文档中时, 该当被解释为何种含意。遵循这些指南的 作者, 该当在他们的文档结尾的左近, 退出以下短语: 在此文档中, 对于关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 与 "OPTIONAL" 的解释, 见 RFC 2119 中的形容。 === 批改后 === 在许多 IETF 文档中, 当一些词采纳如下所示的、全大写字母的模式时, 这些 词被用于阐明标准的要求级别。这些大写的单词能使文档的清晰性和一致性得 到明显提高, 因为它们的含意失去了明确定义。此文档定义了: 在 IETF 文档 中, 当这些单词采纳全大写字母模式时, 该如何解释它们。 o 能够依照在此文档中的定义来应用这些词, 但这不是必须的。特地的, 标准 性的文本自身就不须要应用这些词。当想要保障文档的清晰性和一致性时, 能够应用这些词, 然而许多的规范性的文本即便不应用这些词, 其表述内容 仍旧是规范的、标准的。 o 仅当这些词采纳全大写字母模式时, 才具备这里所规定的含意。 o 当这些词未采纳大写字母模式时, 它们具备失常的英文含意, 不受此文档的 影响。 遵循这些指南的作者, 该当在他们的文档结尾的左近, 退出以下短语: 在此文档中, 对于关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 与 "OPTIONAL" 的解释, 当且仅当它们采纳全大写模式时, 见 BCP 14 的文档 [RFC2119] 与 [RFC8174] 中的形容。 === 完结 ===Leiba Best Current Practice [Page 3]RFC 8174 RFC 2119 Clarification May 20173. IANA 注意事项 此文档不须要任何 IANA 操作。4. 平安注意事项 此文档齐全是程序性质的; 无平安相干的注意事项。5. 前提类参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.作者地址 Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/Leiba Best Current Practice [Page 4]

要获取更多Jerry的原创文章，请关注公众号"汪子熙":

3 月 9 日凌晨，Nervos 基金会推出了 Nervos CKB 经济模型提案，该提案由 Kevin Wang 主笔，与 Nervos 团队以及国内外一线经济学家、博弈论学者共同架构而成。提案中，CKB 的发行由「基础发行」和「二级发行」组成。其中「基础发行」部分的代币会通过挖矿的方式奖励给矿工，作为保护网络的激励措施，「基础发行」的总供给量有限，大约每 4 年减半一次，直到所有「基础发行」的代币被挖出；而「二级发行」的设计则是为了收取状态租金，每年的发行数量不变，「基础发行」停止后，「二级发行」仍会继续。我们希望通过这样的经济模型设计，确保底层协议的安全性和长期可持续性，同时协调不同参与者，为促进整个网络的价值增长而作出贡献。在推出提案的两天时间里，我们陆续收到了来自社区不同的反馈，很多小伙伴提出的问题和反馈都非常具有代表性，比如：CKB 是如何捕获上层资产价值的？CKB 是如何协调 Miner、Holder、User 之间的利益的？Nervos DAO 存在的意义是什么？CKB 是如何进行状态管制的？CKB Cell 模型以及 CKB-VM 的设计，给予了经济模型怎样独特的支持？……小伙伴们提出的问题让我们特别欣喜，这也让我们更加期待能和大家产生更多的思想碰撞。为了让更多来自中文社区的小伙伴参与讨论，Nervos 基金会首次在 Talk 论坛上开启针对 CKB 经济模型提案解读的奖励计划，希望和大家一起探讨加密经济的未来！我们为本次活动设置了丰厚的奖励，你将有机会得到 Nervos 周边以及 Token 奖励，同时，你还可以@Nervos 团队的任何一位成员，TA 会在第一时间解答你的疑惑，分享你的收获。活动一：Let’s Talk 计划目前，Nervos 社区志愿者已经完成了对 CKB 经济模型提案中文版的翻译初稿，希望可以借此帮助大家了解这份提案的研究方向，以及 CKB 经济模型的设计思路。现在我们邀请小伙伴们一起到 Nervos Talk 论坛参与讨论这份提案，你可以在这里发表你对经济模型的任何想法，哪怕只是一句吐槽，或是一个困惑，这些内容我们会非常欢迎。当然，我们更希望多看到一些你对 CKB 经济模型的真实理解和分析。奖励方式：我们将选出 10 位优秀观点的贡献者，每位赠送「Nervos 纪念版卫衣以及 10000 CKB」。活动时间：2019.3.11—2019.4.30参与方式：进入 Nervos Talk 论坛相关话题参与讨论，或在「中文 CN」分类-「加密经济学」模块中建立新的话题。GitHub 中文版翻译初稿：https://github.com/nervos-com…Nervos Talk：https://talk.nervos.org/话题参考：你能从不同的角度，对这次提案的研究方向提出不一样的观点吗？你认为一个好的加密经济模型，要解决的核心问题还有哪些？对于提案的内容，你有反对的观点，或者愿意 Challenge 我们的经济学研究小组么？对于提案中提出的，针对现有主网络平台的经济模型分析，你有不同的观点吗？对于 CKB 的加密经济模型，你有更好的想法么？……活动二：完善提案计划我们的 Nervos CKB 加密经济模型提案，需要汇聚更多小伙伴们的智慧！我们欢迎大家在 GitHub 上提出针对这份提案的各种修正、解读、以及注释。完善类型：翻译修正（Pull Request）针对翻译/原文中出现的问题进行修正，或给出更好的表述文字注释（Pull Request）针对提案中未说明完整的知识点进行注释，让提案更加通俗易懂插图注释（Email）针对提案中的任何内容或知识点，用插图的形式表达你的看法奖励方式：我们将选取共 10 名优秀贡献者，赠予每位「秘猿木制猿猴一只以及 10000 CKB」。活动时间：2019.3.11—2019.4.30参与方式：直接通过 GitHub 参与协作，或将稿件 Email 至 market-team@cryptape.com。GitHub 中文版翻译初稿：https://github.com/nervos-com…卓越贡献奖我们希望借助本次活动，让大家更加了解 Nervos 开源社区的态度，也希望透过大家的参与，和小伙伴们一起把国内 Nervos 社区打造成你喜欢的样子！于是，我们专程设计了「卓越贡献奖」，送给那个最特别的你！奖励方式：活动期间，我们将在「活动一」与「活动二」的参与者里，各选出一名社区卓越贡献者，每位赠送「机械盔甲猿一只（含硬件钱包功能）以及 50000 CKB」！）我们将于 5 月 2 日在 Talk 论坛上公布以上奖项的获奖名单，欢迎大家踊跃参加，一起构建加密经济的未来！另外，若您对活动内容有任何疑问，请加 Jack 小哥哥的微信号「JackXiao2016」并注明「加密经济」，我们会邀请您加入活动微信群！PS：以上活动可同时参与，不会影响获奖资格。关于 RFCRFC 是 Request for Comments（意见征求）的缩写，提交 RFC 是 Nervos 社区方案实施的第一步。RFC 的建立为新协议的改善和最佳实践，提供了一个开放的社区驱动路径，就像以太坊社区有 EIP（以太坊改进提案），比特币社区有 BIP。众多的开源社区，包括 Rust 也是通过 RFC 的形式一步步将提案走向完善。通过 RFC，我们能在开源社区中，跟最前沿的开发者、学者们讨论最深刻的话题，从技术、到经济、到社区治理。正是这些毫无保留的分享、讨论，造就了一个个如此蓬勃的开源生态。建构一个完善的加密经济体，是一件艰巨的任务，从经济学到加密学，从不同角色的激励机制，都非常考验模型的设计。Nervos 基金会从一开始便决定秉持着开放的态度，希望能与社区共同推进每一个决定。所以，我们在项目成立之初就建立完善的社区提案、讨论、实施流程。目前，我们的 RFC 还是以最简单严谨的文字形式在社区中呈现，它的完善，需要汇聚更多小伙伴们的智慧：我们欢迎各种犀利观点和创意的碰撞，欢迎各种修正和注释的补充，欢迎各种插图或故事的呈现，我们相信这些社区的智慧，会让这份提案更加的完善，我们也相信，会有更多人因为你的贡献而打开新世界的大门！What are you waiting for？Let’s Talk！https://talk.nervos.org/t/ner…关于 NervosNervos Network 由 Nervos 基金会推动，通过分层架构为未来加密经济提供基础设施，承载各种网络上的可信组件。其底层公有链 CKB（Common Knowledge Base）作为核心的信任基础设施，用于支撑二层扩展方案，保证了安全和去中心化。Nervos Network 通过分层设计，兼顾性能、安全以及去中心的特性，从而满足多样化的商业场景需求。 ...