RFC 2119 关键词中大写与小写的歧义

简介: 本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已被互联网工程指导小组 (IESG) 批准出版。有关 BCP 的更多信息,请参见 RFC 7841 的第 2 节。

640.gif


RFC8174:Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,May 2017


梗概


RFC 2119 指定了可能在协议规范中使用的通用关键字。本文档旨在通过澄清只有大写的关键词才具有定义的特殊含义来减少歧义。


本备忘录的状态


本备忘录记录了 Internet 最佳当前实践。


本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已被互联网工程指导小组 (IESG) 批准出版。有关 BCP 的更多信息,请参见 RFC 7841 的第 2 节。


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


版权声明


版权所有 (c) 2017 IETF Trust 和确定为文档作者的人员。版权所有。


本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束,在本文档发布之日生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本,并且不提供如简化 BSD 许可中所述的保证。


1、 介绍


RFC 2119 指定了可能在协议规范中使用的常见关键字,例如“必须”、“应该”和“可以”。它说关键词“经常大写”,这引起了人们对如何解释“必须”和“应该”等非大写词的困惑。


本文档更新了 RFC 2119,阐明只有大写的关键字才具有定义的特殊含义。本文档是 BCP 14 的一部分。


2、 明确关键词的大小写


对 [RFC2119] 进行了以下更改:


=== 旧版 ===


在许多标准跟踪文件中,使用几个词来表示规范中的要求。这些词通常大写。本文档定义了这些词,因为它们应该在 IETF 文档中被解释。遵循这些准则的作者应在其文档的开头附近加入此短语:


本文档中的关键词“必须”、“不得”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以”和“可选”是 按照 RFC 2119 中的描述进行解释。


=== 新版 ===


在许多 IETF 文档中,有几个单词,当它们全部大写时,如下所示,用于表示规范中的要求。这些大写单词可以为文档带来显着的清晰度和一致性,因为它们的含义定义明确。本文档定义了当这些词全部大写时,这些词在 IETF 文档中的解释方式。


** 这些词可以按照此处的定义使用,但不是必需的。具体来说,规范性文本不需要使用这些关键词。当需要时,它们用于清晰和一致性,但许多规范性文本不使用它们并且仍然是规范性的。


** 词语仅在全部大写时才具有此处规定的含义。


** 当这些单词没有大写时,它们具有正常的英语含义,不受本文档的影响。


遵循这些准则的作者应在其文档的开头附近加入此短语:


关键词“必须”、“不得”、“要求”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” “当且仅当它们以所有大写字母出现时,本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释,如此处所示。


=== 结束 ===


3、 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>.


相关文章
|
4月前
|
人工智能 前端开发 Java
让AI Coding 效率翻倍!AGENTS.md 标准化文档详解:兼容Claude/Cursor/Codex全方案
在多AI编程工具并行使用的团队开发场景中,长期存在一个普遍痛点:不同AI客户端各自使用独立规则配置文件,Claude依赖CLAUDE.md、Cursor使用.cursorrules、Codex采用AGENT.md,团队需要同步多份内容高度重合的文档,维护成本成倍上涨。同时AI无法完整理解项目整体架构,前后端代码上下文割裂、私有组件不识别、编码规范不清晰、无法自主构建自测等问题,导致AI生成代码返工率极高,大幅拉低开发效率。
1134 0
|
6月前
|
SQL 消息中间件 存储
阿里云 EventHouse 正式公测!连接企业数据与 AI Agent,释放实时数据价值
统一接入、沉淀并治理多源异构数据,支持自然语言对话分析,加速业务数据转化为可执行洞察。
613 54
|
5月前
|
人工智能 运维 安全
Agent 从“能用”到“管好”,中间差了什么?
AgentRun 开放平台是企业级 AI 运维中台,专解 Agent 规模化落地难题。以员工权限为核心,构建“用户组-用户-用户空间”三层多租户体系,实现细粒度隔离、动态审批、成本可控、安全合规与全生命周期管理,助力企业从“玩具”迈向可信、高效、可治理的 AI 生产环境。
|
6月前
|
人工智能 安全 机器人
AI赋能研发全链路:需求→设计→开发→审查实战指南
AI赋能全自动研发不是普通AI编程,而是把「环境、Git、AI、协作」打包成一套全自动研发,不用反复配环境、不用盯着AI改代码、不用手动做Code Review,手机打开网页都能写项目,这才是AI编程该有的样子。
871 0
|
缓存 算法 NoSQL
短信验证码登录接口,如何防止恶意攻击
该文讨论了移动应用中常见的手机短信验证码登录(短验登录)的安全设计。后端通常需要提供获取短信验证码和手机短验登录两个API。为了增强机短验登录API的安全性,提出了几种无需依赖Redis等存储介质的方案:1)使用数字签名确保请求合法性;2)基于时间戳的验证,允许在一定时间范围内有效;3)应用TOTP算法生成动态码进行验证;4)利用JWTToken进行身份验证并设置有效期。文章强调了创新思考在解决安全问题中的重要性,并鼓励读者分享更多方案。
1580 1
|
算法
重磅!2025年中科院预警期刊名单正式发布!
中国科学院文献情报中心发布的《国际期刊预警名单》旨在防范学术不端与不当出版行为,保护科研生态良性发展。2025年版本聚焦两大问题:学术不端(如引用操纵、论文工厂)和不利于中国学术成果国际化传播的行为(如中国作者占比过高或APC费用不合理)。预警名单动态调整,发布时点从年底改为年初,便于科研人员及时调整投稿策略。被列入预警名单的期刊可能影响职称评审及科研经费认可,建议优先选择中科院分区表推荐期刊,警惕“快速代发”陷阱,并关注期刊官网声明。未来科研生态将更注重规范化与原创性,推动高质量学术发表。维护健康的学术环境对提升中国科研全球影响力至关重要。
2811 0
|
前端开发 JavaScript
|
存储 文件存储 数据库
【QT项目】QT项目综合练习之简易计数器(QT6+文件存储)
【QT项目】QT项目综合练习之简易计数器(QT6+文件存储)
|
Kubernetes API 调度
k8s学习--pod的所有状态详解(图例展示)
k8s学习--pod的所有状态详解(图例展示)
2520 2
|
编译器 API C语言
【QT速成】半小时入门QT6之QT前置知识扫盲(一)
【QT速成】半小时入门QT6之QT前置知识扫盲(一)

热门文章

最新文章