Independent Submission R. Barnes
Request for Comments: 6919 S. Kent
Category: Experimental BBN
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
1 April 2013
Independent Submission R. Barnes
Request for Comments: 6919 S. Kent
Category: Experimental BBN
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
1 April 2013
Further Key Words for Use in RFCs to Indicate Requirement Levels
RFC中用于指示需求水平的其他关键词
Abstract
摘要
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
RFC2119定义了一组用于描述规范要求的标准关键字。许多IETF文件发现，这些词语无法准确地捕捉其规范的细微要求。本文档定义了可用于解决替代需求场景的其他关键词。遵循这些指导原则的作者应在其文件开头加入以下短语：
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
本文件中的关键词“必须（但我们知道您不会）”、“应该考虑”、“确实不应该”、“应该”、“可能会”、“可能希望”、“可以”、“可能”和“可能”应按照RFC 6919中的描述进行解释。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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/rfc6919.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6919.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. MUST (BUT WE KNOW YOU WON'T) . . . . . . . . . . . . . . . . . 3
2. SHOULD CONSIDER . . . . . . . . . . . . . . . . . . . . . . . . 3
3. REALLY SHOULD NOT . . . . . . . . . . . . . . . . . . . . . . . 3
4. OUGHT TO . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. WOULD PROBABLY . . . . . . . . . . . . . . . . . . . . . . . . 4
6. MAY WISH TO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. POSSIBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. MIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. MUST (BUT WE KNOW YOU WON'T) . . . . . . . . . . . . . . . . . 3
2. SHOULD CONSIDER . . . . . . . . . . . . . . . . . . . . . . . . 3
3. REALLY SHOULD NOT . . . . . . . . . . . . . . . . . . . . . . . 3
4. OUGHT TO . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. WOULD PROBABLY . . . . . . . . . . . . . . . . . . . . . . . . 4
6. MAY WISH TO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. POSSIBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. MIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . . 5
The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement.
短语“必须（但我们知道您不会）”用于表示满足正式审查标准所需的需求（例如，强制实施安全机制），当这些机制对实施者来说太不方便而无法实际实施时。
This phrase is frequently used in a contracted form in which the parenthetical is omitted. The parenthetical may also be moved later in the sentence for stylistic reasons. If the parenthetical is present, authors MUST provide a reason why they know implementors will not heed this instruction in the parenthetical, as in the example (BUT WE KNOW YOU WON'T). In the below example, we show a case from RFC 6120 where the original text omitted the parenthetical, and we have indicated an appropriate parenthetical.
这个短语经常以缩略形式使用，省略了插入语。出于文体原因，插入语也可以在句子的后面移动。如果有附加说明，作者必须提供一个原因，说明他们为什么知道实现者不会注意附加说明中的说明，如示例中所示（但我们知道您不会）。在下面的示例中，我们展示了RFC6120中的一个案例，其中原始文本省略了插入语，并且我们已经指出了一个适当的插入语。
For example: "For authentication only, servers and clients MUST support the SASL Salted Challenge Response Authentication Mechanism [SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants [(BUT WE KNOW YOU WON'T, because your TLS library doesn't support extracting channel binding information)]." [RFC6120]
例如：“仅针对身份验证，服务器和客户端必须支持SASL Salted质询响应身份验证机制[SCRAM]——特别是SCRAM-SHA-1和SCRAM-SHA-1-PLUS变体[（但我们知道您不会，因为您的TLS库不支持提取通道绑定信息）]。”[RFC6120]
The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what.
短语“应该考虑”表示规范的作者认为实现应该做些什么，但他们不确定应该做什么。
For example: "Applications that take advantage of typed links should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers." [RFC5988]
例如：“利用类型链接的应用程序应该考虑通过自动跟踪、信任或以其他方式使用从HTTP报头收集的链接打开的攻击向量。”
The phrase "REALLY SHOULD NOT" is used to indicate dangerous behaviors that some important vendor still does and therefore we were unable to make MUST NOT.
短语“真的不应该”用于表示一些重要供应商仍然存在的危险行为，因此我们无法做出禁止。
For example: "This command really should not be used" [RFC0493]
例如：“确实不应该使用此命令”[RFC0493]
The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and thus does not require substantiation.
“应该”一词表达了对实施行为的乐观断言，该行为显然在道德上是正确的，因此不需要证实。
For example: "If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency." [RFC2616]
例如：“如果决策可能会影响语义透明度，那么实现者应该在保持透明度方面犯错误，除非仔细和完整的分析表明破坏透明度有显著的好处。”[RFC2616]
The phrase "WOULD PROBABLY" indicates the authors expectation about what a reasonable implementation is likely to do in a given case. There is no requirement for implementations to be reasonable.
短语“可能”表示作者对合理实现在给定情况下可能做什么的期望。没有要求实现是合理的。
This phrase is also a good example of an aspect of English grammar that is often useful in specification writing, namely the passive-aggressive voice, which provides a meaning in between the active and the passive voice.
这个短语也是英语语法中一个很好的例子，在规范写作中经常有用，即被动攻击性语态，它提供了介于主动语态和被动语态之间的意义。
For example: "A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to." [RFC3207]
例如：“SMTP客户端可能只想验证其服务器证书的域名是客户端认为它正在连接的域名的SMTP服务器。”[RFC3207]
The phrase "MAY WISH TO" indicates a behavior that might seem appealing to some people, but which is regarded as ridiculous or unnecessary by others. This phrase is frequently used to avoid further delay in approval of a document.
短语“MAY WISH TO”表示一种行为，可能对某些人有吸引力，但被其他人视为荒谬或不必要。此短语经常用于避免进一步延迟批准文件。
For example: "Verifiers MAY wish to track testing mode results to assist the Signer." [RFC6376]
例如：“验证者可能希望跟踪测试模式结果以帮助签名者。”[RFC6376]
The phrase "COULD" provides a way for specification authors to articulate existential possibilities, in order to provide a hint that might be critical to reliable or secure operation, but without a hard requirement. The lack of a requirement allows for vendor product differentiation.
短语“可能”为规范作者提供了一种表达存在可能性的方法，以便提供可能对可靠或安全操作至关重要的提示，但没有严格的要求。由于缺乏需求，供应商可以对产品进行区分。
For example: "An implementation could mitigate this race condition, for example, using timers." [RFC6733]
例如：“实现可以缓解这种竞争条件，例如，使用计时器。”[RFC6733]
The phrase "POSSIBLE" describes what some of the working group members thought of as an edge case that will never happen, but in practice allows the protocol to work at the most fundamental level.
“可能”一词描述了一些工作组成员认为永远不会发生的边缘案件，但实际上允许议定书在最基本的层面上发挥作用。
For example: "It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data." [RFC3501]
例如：“服务器也可以发送其他命令的完成响应（如果多个命令正在执行）或未标记的数据。”[RFC3501]
The phrase "MIGHT" conveys a requirement in an intentionally stealthy fashion, to facilitate product differentiation (cf. "COULD" above).
短语“可能”以一种有意隐藏的方式传达要求，以促进产品差异化（参见上文的“可能”）。
For example: "In the case of audio and different "m" lines for different codecs, an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior." [RFC5888]
例如：“在音频和不同编解码器的不同“m”线的情况下，实现可能决定充当不同传入RTP会话的混音器，这是正确的行为。”[RFC5888]
Traditionally, security requirements in IETF documents have been expressed with a mixture of requirements words from RFC 2119 [RFC2119] and the phrases used above. The key words in RFC 2119 are principally useful when threats and mitigations are clear and well defined. The key words in this document can be applied when the threat model is ambiguous, and mitigations are unclear or inconvenient.
传统上，IETF文档中的安全需求是由RFC2119[RFC2119]中的需求词和上面使用的短语混合表达的。当威胁和缓解措施明确且定义良好时，RFC 2119中的关键词主要有用。当威胁模型不明确、缓解措施不明确或不方便时，可以使用本文档中的关键词。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC0493] Michener, J., Cotton, I., Kelley, K., Liddle, D., and E. Meyer, "GRAPHICS PROTOCOL", RFC 493, April 1973.
[RFC0493]Michener，J.，Cotton，I.，Kelley，K.，Liddle，D.，和E.Meyer，“图形协议”，RFC 493，1973年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Hansen，T.，和M.Kucherawy，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基准协议”，RFC 67332012年10月。
Authors' Addresses
作者地址
Richard Barnes BBN 1300 N 17th St Arlington, VA 22209 US
理查德·巴恩斯BBN美国弗吉尼亚州阿灵顿第17街北1300号22209
EMail: rlb@ipv.sx
EMail: rlb@ipv.sx
Stephen Kent BBN 10 Moulton St Cambridge, MA 02138 US
美国马萨诸塞州剑桥莫尔顿街10号斯蒂芬·肯特BBN 02138
EMail: kent@bbn.com
EMail: kent@bbn.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 US
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com