各種要件レベルを指示するために RFC 用に利用されるキーワード

この~memoの位置付け

この文書は、 `Internet Community^en 用の `Internet Best Current Practices^en 【 “~internetにおける現在の最善な実施”, 略称 BCP 】 を指定する。 また、 改善のための論点と示唆を要請する。 この~memoの配布は制限されない。 ◎ This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

多くの `standards track^en 文書 【 “標準~化されることを~~目指す文書” 】 は、 いくつかの語句を利用して，当の仕様~内に要件を記す — これらの語句は、 大字~化されることが多い。 この文書は、 【`§ 各種~keyword＠#_keywords$にて】 これらの語句を定義する — それらは、 ~IETF文書において解釈する必要があるので。 ◎ In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.＼

この指針に従う作者は、 次の句を，自身の文書の冒頭近くに組入れるべきである ⇒ “この文書における，次に挙げる~keywordは、 `RFC 2119＠~RFCx/rfc2119$ に述べるとおりに解釈すること” ⇒＃ `MUST^2119, `MUST NOT^2119, `REQUIRED^2119, `SHALL^2119, `SHALL NOT^2119, `SHOULD^2119, `SHOULD NOT^2119, `RECOMMENDED^2119, `MAY^2119, `OPTIONAL^2119 ◎ Authors who follow these guidelines should incorporate this phrase near the beginning of their document: ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

これらの語句の強制力は、 それらを利用する文書の要件~levelにより改変されることに注意。 【これは、正確には何を意味する？】 ◎ Note that the force of these words is modified by the requirement level of the document in which they are used.

~RFC 8174 による~RFC 2119 に対する変更点

【 編集上の都合により， `~RFC 8174＠#_8174$ を成す主要な内容 （`§ ~keywordの大字~化による明確化-法＠#_8174-section-2$） をここに与える。 】

`RFC8174$r により， `RFC2119$r の `§ ~~要約＠#_abstract$ を成す内容は、 最後の段落を除き，以下のとおり変更された： ◎ The following change is made to [RFC2119]: ◎ === OLD === In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

多くの~IETF文書は、 いくつかの語句 — 下に示すとおり，すべて大字からなる語句 — を利用して，仕様における要件を記す。 これらの大字~化された語句には、 きちんと定義された意味があるので，文書に有意な明確性と一貫性をもたらし得る。 この文書は、 ~IETF文書において，それらの語句が — すべて大字からなるとき — どう解釈されるかを定義する。 ◎ In many IETF documents, several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. These capitalized words can bring significant clarity and consistency to documents because their meanings are well defined. This document defines how those words are interpreted in IETF documents when the words are in all capitals.

• これらの語句は、 ここに定義されるものとして利用できるが，利用することは要求されない。 特定的には、 これらの~keywordの利用は，規範的な~textにも要求されない。 それらは、 明確性と一貫性が求まれるとき，それを得るために利用されるが、 それらを利用しない規範的な~textもたくさんあり，依然として規範的である。 ◎ o These words can be used as defined here, but using them is not required. Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative.
• これらの語句は、 すべて大字であるときに限り，ここに指定される意味を有する。 ◎ o The words have the meanings specified herein only when they are in all capitals.
• これらの語句が大字~化されていないときは、 通常の英語による意味を有し，この文書により影響されない。 ◎ o When these words are not capitalized, they have their normal English meanings and are not affected by this document.

以上の指針に従う作者は、 次の句を，自身の文書の冒頭近くに組入れるべきである ⇒ “この文書における，次に挙げる~keywordは、［ そこに示すとおり，すべて大字で出現するとき ］に限り， ~BCP 14 — `RFC2119$r, `RFC8174$r — に述べられるとおりに解釈すること” ⇒＃ `MUST^2119, `MUST NOT^2119, `REQUIRED^2119, `SHALL^2119, `SHALL NOT^2119, `SHOULD^2119, `SHOULD NOT^2119, `RECOMMENDED^2119, `MAY^2119, `OPTIONAL^2119 ◎ Authors who follow these guidelines should incorporate this phrase near the beginning of their document: ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. === END ===

【 この節が `RFC8174$r 以前の~RFCにも遡及的に適用されるかどうかは，はっきりしないが、 大字かどうかが恣意的に一貫しないように記されることは考えにくいので、 大字~keywordを利用している仕様には，概ね適用されるものと解釈してよいように思われる。 】

各種~keyword

【 これらの~keywordが、 この~siteの日本語訳にてどう表記されるかについては、 `RFC 2119 が規定する句に利用される対訳＠index.html#rfc2119-phrase$ を見よ。 】

`MUST^2119 ／ `REQUIRED^2119 ／ `SHALL^2119 ◎ 1. MUST This word, or the terms "REQUIRED" or "SHALL",＼

これらの語句は、 次を意味する ⇒ 当の定義は、 仕様における絶対的な要件である。 ◎ mean that the definition is an absolute requirement of the specification.

`MUST NOT^2119 ／ `SHALL NOT^2119 ◎ 2. MUST NOT This phrase, or the phrase "SHALL NOT",＼

これらの語句は、 次を意味する ⇒ 当の定義は、 仕様における絶対的な禁制である。 ◎ mean that the definition is an absolute prohibition of the specification.

`SHOULD^2119 ／ `RECOMMENDED^2119 ◎ 3. SHOULD This word, or the adjective "RECOMMENDED",＼

これらの語句は、 次を意味する ⇒ 特定0の状況下においては，特定0の条項を無視する妥当な理由が存在し得るが、 異なる道を選ぶ前に、 当の条項による含意を全部的に理解した上で，注意深く比較検討しなければならない。 ◎ mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

`SHOULD NOT^2119 ／ `NOT RECOMMENDED^2119 ◎ 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED"＼

これらの語句は、 次を意味する ⇒ この~labelを伴って述べられる挙動には — 特に，特定0の挙動が受容-可能なとき, または有用にすらなる状況下において — 妥当な理由が存在し得るが、 それを実装する前に、 その含意を全部的に理解した上で，当の事例を注意深く比較検討するべきである。 ◎ mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

`MAY^2119 ／ `OPTIONAL^2119 ◎ 5. MAY This word, or the adjective "OPTIONAL",＼

これらの語句は、 次を意味する ⇒ 当の条項は、 真に任意選択である。 ◎ mean that an item is truly optional.＼

当の条項を含めることを — それが［ 特定0の市場から要求される／自身の製品を強化すると~~見込まれる ］ことから — 選ぶ~vendorも，同じ条項を省略する~vendorもあり得る。 特定0の選択肢を［ 含めない／含める ］実装は、 それを［ 含める／含めない ］実装と相互運用するよう準備しなければナラナイ（もちろん，その選択肢が供する特能は除いて） — 含めない実装は、 たぶん†，その機能性は抑制されるであろうが。 ◎ One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.＼ An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.＼ In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

【† 条項を含めることと選択肢を含めることは、 同義になるとは限らず，逆にもなり得る。 すなわち、 選択肢を狭めるよう制約する場合もある （例：相互運用能に必要なため容認されていた機能性を~securityや~privacyの懸念に因り不能化するような条項など）。 】

これらの命令句の利用に関する指導

この~memoにて定義される類の命令句は、 ~careの下で，控目に利用しなければならない。 特に，これらを利用するのは、［ 相互運用のため／害を及ぼし得る挙動を制限する（例：再伝送を制限する）ため ］に実際に要求される所に限らなければナラナイ。 例えば、 実装者に対し［ 相互運用能に要求されない特定0の手法 ］を課すよう試行するために，これらを利用してはならない。 ◎ Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.

~securityの考慮点

これらの用語は、 ~securityの含意を伴う挙動を指定するために利用されることも多い。 仕様が［ `MUST^2119 や `SHOULD^2119 を伴う何かを実装しないこと ］または［ `MUST NOT^2119 や `SHOULD NOT^2119 を伴う何かに反して，それを行うこと ］による~securityに対する効果は、 ごく微妙にもなり得る。 文書~作者は、 推奨や要件に従わないことによる，~securityの含意を調べ上げる時間を割くべきである — ほとんどの実装者は、 仕様を生産した経験や論点からの恩恵にあずかることはないので。 ◎ These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification.

謝辞

これらの用語の定義は、 いくつかの~RFCから採られた定義の集成である。 加えて，次を含む何人かからの示唆も組入れられている ⇒ `Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz^en ◎ The definitions of these terms are an amalgam of definitions taken from a number of RFCs. In addition, suggestions have been incorporated from a number of people including Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz.

RFC 8174 （ RFC 2119 ~keywordにおける大文字 対 小文字の多義性）