[Joke-RFC] RFC6919 要求レベルを示すRFCで使用するためのさらなるキーワード

# はじめに

* この文書は [RFC6919](https://www.rfc-editor.org/rfc/rfc6919.txt) を勉強と好奇心のため適当に訳したものです。
* 翻訳の正確さは全く保証しません。
* 誤字誤訳等の指摘はいつでも大歓迎です。

# Further Key Words for Use in RFCs to Indicate Requirement Levels（要求レベルを示すRFCで使用するためのさらなるキーワード）

* Independent Submission
* Request for Comments: 6919
* Category: Experimental
* ISSN: 2070-1721

- R. Barnes
- S. Kent
- BBN
- E. Rescorla
- RTFM, Inc.
- 1 April 2013

## 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.

この文書中のキーワード「MUST (BUT WE KNOW YOU WON'T)」「SHOULD CONSIDER」「REALLY SHOULD NOT」「OUGHT TO」「WOULD PROBABLY」「MAY WISH TO」「COULD」「POSSIBLE」「MIGHT」はRFC 6919で説明されたように解釈されるものとする。

## Status of This Memo（このメモの位置づけ）

> This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

この文書はInternet Standards Trackの仕様ではなく、検討、実験的な実装、評価のために公開されたものである。

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

   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.
```

## 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)（しなければならない（が、あなたはやらないだろう））

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

「MUST (BUT WE KNOW YOU WON'T)」というフレーズは、正式なレビュー基準を満たすために必要な要件（例えば、セキュリティメカニズムの実装を義務付ける）を示すために使用されるが、これらのメカニズムは実装者にとって実際に実装するにはあまりにも不便な時に使用される。

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

このフレーズは、カッコ書きを省略した形でよく使われる。
文体上の理由から、カッコ書きは文の後半に移動されることもある。
カッコ書きがある場合、著者は実装者がこの指示に従わないことを知っている理由を、例のようにカッコ書きで示さなければならない(BUT WE KNOW YOU WON'T)。
以下の例では、RFC 6120 の原文でカッコ書きが省略されているケースを示し、適切なカッコ書きを示している。

> 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 Challenge Response Authentication Mechanism [SCRAM]をサポートしなければならない(MUST) —— 特に、SCRAM-SHA-1およびSCRAM-SHA-1-PLUSの亜種について[(BUT WE KNOW YOU WON'T、なぜなら、あなたのTLSライブラリはチャネルバインディング情報の抽出をサポートしていないから)]」 [RFC6120]

## 2.  SHOULD CONSIDER（考えるべき）

> The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what.

「SHOULD CONSIDER」というフレーズは、仕様の作成者が、何かを実装すべきだと考えていることを示すが、その内容をよくわかっていないときに使用する。

> 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ヘッダから収集したリンクを自動的に追跡、信頼、またはその他の方法で使用することによって開かれる攻撃ベクトルを考慮すべきである」 [RFC5988]

## 3.  REALLY SHOULD NOT（本当につかうべきではない）

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

「REALLY SHOULD NOT（本当につかうべきではない）」というフレーズは、ある重要なベンダーが今でも行っている危険な行為を示すもので、それゆえ「MUST NOT」にすることができなかった。

> For example: "This command really should not be used" [RFC0493]

例えば：「このコマンドは本当に使うべきではない」[RFC0493]。

## 4.  OUGHT TO（する義務がある）

> The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and thus does not require substantiation.

「OUGHT TO」というフレーズは、明らかに道徳的に正しい実装動作を楽観的に主張するものであり、したがって実証を必要としない。

> 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]

## 5.  WOULD PROBABLY（おそらく……だろう）

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

「WOULD PROBABLY」というフレーズは、合理的な実装が与えられたケースで何をしそうかという作者の予想を示している。
実装が合理的であることは要求されていない。

> 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]

## 6.  MAY WISH TO（望むなら……してもよい）

> 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]

## 7.  COULD（かもしれない）

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

「COULD」というフレーズは、仕様作成者が存在する可能性を明確にする方法を提供し、信頼性の高い、または安全な運用に不可欠であるかもしれないヒントを提供するものであるが、ハード要件はない。
要件がないため、ベンダーの製品を差別化することができる。

> For example: "An implementation could mitigate this race condition, for example, using timers." [RFC6733]

例えば：「実装は、例えばタイマーを使用して、この競合状態を緩和することができるかもしれない」 [RFC6733]

## 8.  POSSIBLE（可能である）

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

「POSSIBLE」というフレーズは、ワーキンググループのメンバーの何人かが、決して起こらないエッジケースとして考えたものだが、実際にはプロトコルが最も基本的なレベルで機能することが可能なものである。

> 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]

## 9.  MIGHT（するかもしれない）

> The phrase "MIGHT" conveys a requirement in an intentionally stealthy fashion, to facilitate product differentiation (cf. "COULD" above).

「MIGHT」というフレーズは、製品の差別化を図るために、意図的にステルス的に要件を伝えるものである（上記「COULD」参照）。

> 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]

## 10.  Security Considerations（セキュリティに関する考察）

> 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文書におけるセキュリティ要件は、RFC 2119 [RFC2119] の要件ワードと上記のフレーズを混合して表現されてきた。
RFC 2119 のキーワードは、脅威と緩和策が明確でよく定義されている場合に主に有用である。
本書のキーワードは、脅威モデルが曖昧であり、緩和策が不明確または不都合な場合に適用することができる。

## 11.  References

### 11.1.  Normative References

```
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
```

### 11.2.  Informative References

```
   [RFC0493]  Michener, J., Cotton, I., Kelley, K., Liddle, D., and E.
              Meyer, "GRAPHICS PROTOCOL", RFC 493, April 1973.

   [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.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", RFC 6376,
              September 2011.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.
```

## Authors' Addresses

```
   Richard Barnes
   BBN
   1300 N 17th St
   Arlington, VA  22209
   US

   EMail: rlb@ipv.sx


   Stephen Kent
   BBN
   10 Moulton St
   Cambridge, MA  02138
   US

   EMail: kent@bbn.com


   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA  94303
   US

   EMail: ekr@rtfm.com
```