RFC 2119

「RFCで使用する要件レベルを示すキーワード」についての定め。

従っておくといいかもしれない(OPTIONAL)

code:copy.txt

この文書におけるキーワード「MUST(しなければいけない)」「SHOULD(する必要がある)」「MAY(しても良い)」は、RFC 2119で説明されているように解釈してください。

いかに和訳と英語の全文をおいておきます、原文は調べたら出てくる

code:ja.md

# RFCで使用する要件レベルを示すキーワード(RFC 2119)

この文書は、インターネットコミュニティのための現状における最善の実践を規定し、議論と改善のための提案を要求するものです。

このメモの配布は無制限です。

多くの標準追跡文書では、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、しばしば大文字で表記されます。

この文書では、IETFの文書で解釈されるべきこれらの単語を定義します。

このガイドラインに従う著者は、文書の冒頭付近に以下の文章を組み込むことが推奨されます(RECOMMENDED)。

『この文書におけるキーワード「MUST(しなければいけない)」「MUST NOT(してはいけない)」「REQUIRED(要求される)」「SHALL(することになる)」「SHALL NOT(することはない)」「SHOULD(する必要がある)」「SHOULD NOT(しないほうが良い)」「RECOMMENDED(推奨される)」「NOT RECOMENDED(推奨されない)」「MAY(しても良い)」「OPTIONAL(選択できる)」は、RFC 2119で説明されているように解釈されるものです。』

なお、これらの言葉の強さは、使用される文書の要求水準によって変化することに留意してください。

この言葉、あるいは"REQUIRED(要求される)"や"SHALL(することになる)"という言葉は、その事項が仕様の絶対条件であることを意味します。

この文言や"SHALL NOT(することはない)"という文言は、その事項が仕様の絶対的な禁止事項であることを意味します。

この言葉、または"RECOMMENDED(推奨される)"という形容詞は、特定の状況においてその事項を無視する正当な理由があるかもしれないが、別の道を選ぶ前に、その意味を深く理解し、慎重に判断しなければならないことを意味します。

この文言や"NOT RECOMMEND(推奨されない)"という文言は、特定の状況において、その事項が許容される、あるいは有用であるという正当な理由が存在するかもしれないが、このラベルで記述された行動を実施する前に、その意味を十分に理解し、ケースを慎重に判断すべきであるということを意味します。

この言葉、あるいは形容詞の"OPTIONAL(選択できる)"は、その事項が本当に選択的であることを意味します。

ある人は、特定の市場がそれを要求しているから、あるいはそれが製品を強化すると感じているから、その項目を含めることを選択するかもしれないが、別の人は同じ項目を省くかもしれません。

ある選択を含まない実装は、その選択を含む別の実装と、おそらく機能は低下するものの、相互運用できるように準備しなければなりません(MUST)。

同じように、ある選択を含む実装は、その選択を含まない別の実装と相互運用できるように準備しなければなりません(MUST)(もちろん、そのオプションが提供する機能を除いて)。

このメモに定義されている表現は、注意深く、控えめに使用されなければなりません。

特に、相互運用のために実際に必要な場合、または害を及ぼす可能性のある動作(例えば、再送信の制限)を制限する場合にのみ使用されなければなりません(MUST)。

例えば、相互運用のために必要でない特定の方法を実装者に押し付けようとするために使用してはなりません。

これらの用語は、セキュリティに影響を与える動作を指定するために頻繁に使用されます。

MUSTやSHOULDを実装しない、あるいは仕様でMUST NOTやSHOULD NOTとされていることを行うことによるセキュリティへの影響は、非常に微妙なものである場合があります。

文書作成者は、推奨事項や要求事項に従わない場合のセキュリティへの影響について、時間をかけて詳しく説明する必要があります。ほとんどの人は、その仕様を作成した経験や議論の恩恵を受けていないからです。

これらの用語の定義は、多くのRFCから引用された定義の融合です。

さらに、Robert Ullmann、Thomas Narten、Neal McBurnett、Robert Elzを含む多くの人からの提案も取り入れられています。

Scott Bradner

Harvard University

1350 Mass. Ave.

Cambridge, MA 02138

phone - +1 617 495 3864

email - sob@harvard.edu

code:en.txt

Key words for use in RFCs to Indicate Requirement Levels

Status of this 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.

Abstract

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.

Note that the force of these words is modified by the requirement level of the document in which they are used.

1. MUST

This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

2. MUST NOT

This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

3. SHOULD

This word, or the adjective "RECOMMENDED", 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.

4. SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" 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.

5. MAY

This word, or the adjective "OPTIONAL", mean that an item is truly optional.

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

6. Guidance in the use of these Imperatives

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.

7. Security Considerations

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.

8. Acknowledgments

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.

9. Author's Address

Scott Bradner

Harvard University

1350 Mass. Ave.

Cambridge, MA 02138

phone - +1 617 495 3864

email - sob@harvard.edu