RFC2119 日本語訳
2119 Key words for use in RFCs to Indicate Requirement Levels. S.Bradner. March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: BEST CURRENT PRACTICE)
RFC一覧
英語原文
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
要求レベルを指し示すため RFC で使用するためのキーワード
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.
この文書は、Internet Community のための Internet Best Current
Practices を明細に述べ、改善のための審議と提案を要求する。このメモの配
布は無制限である。
-------------------------------------------------------------------------
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:
多くの standard track 文書で、いくつかの単語は、仕様書での要求を示すた
めに使用される。これらの単語は、しばしば大文字で書かれる。この文書は、
IETF 文書で解釈されるべきとして、これらの単語を定義する。これらのガイ
ドラインに従う著者は、自分の書いた文書の最初のあたりに、次のフレーズを
組み入れるべきである。
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.
この文書での、キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" と
"OPTIONAL" は、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.
1. MUST この単語、もしくは用語 "REQUIRED" や "SHALL" は、定義が仕様書の
絶対の要求であることを意味する。
-------------------------------------------------------------------------
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
2. MUST NOT このフレーズ、もしくはフレーズ "SHALL NOT" は、定義が仕様書
の絶対の禁止であることを意味する。
-------------------------------------------------------------------------
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.
3. SHOULD この単語、もしくは形容詞の "RECOMMENDED" は、特定の状況で、特
定の item を無視するための有効な理由が存在するかもしれないが、完全な実
装は異なった方針を選択する前に、理解され注意深くよく考えられなければな
らないことを意味する。
-------------------------------------------------------------------------
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.
4. SHOULD NOT このフレーズ、もしくはフレーズ "NOT RECOMMENDED" は、特定
のふるまいが容認でき有用ですらあるとき、特定の状況で有効な理由が存在す
るかもしれないが、完全な実装はこのラベルを持ち記述された何らかのふるま
いを実装する前に、理解されるべきであり、このケースは注意深く良く考えら
れなければならないことを意味する。
-------------------------------------------------------------------------
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.)
5. MAY この単語、もしくは形容詞の "OPTIONAL" は、アイテムがほんとうにオ
プションであることを意味する。あるベンダは、特定の市場がそれを必要とす
るか、それが製品を高めるという理由で、そのアイテムを含むことを選ぶかも
しれない。一方、他のベンダは同じアイテムを省略するかもしれない。特定の
オプションを含まない実装は、たぶん機能を減らされるけれども、オプション
を含む他の実装と相互互換性があるように用意しなければならない (MUST)。
同じ気持ちで、特定のオプションを含む実装は、オプションを含まない他の実
装と相互互換性があるように用意しなければならない (MUST) (もちろん、オ
プションが提供する特徴という点を除いて)。
-------------------------------------------------------------------------
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.
6. これら命令の使用でのガイダンス
このメモで定義されたタイプの命令は、注意と倹約して使用されなければなら
ない。特に、実際に相互互換性のために要求されたり、害を引き起こす可能性
を持つふるまいを制限 (たとえば、再送を制限すること) するために使用され
るのみでなければならない (MUST)。たとえば、方法が相互互換性のために必
要とされないような場合に、特定の方法を実装者に課せることを試みるために
決して使用されてはならない。
-------------------------------------------------------------------------
7. Security Considerations
7. セキュリティに関する考察
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.
これらの用語は、しばしば security の意味を持つふるまいを、明細に述べる
ために使用される。MUST や SHOULD を実装しないことや、または仕様書が述
べる MUST NOT や SHOULD NOT がおこなわれる何かをすることの security 上
の影響は、たいへん微妙である。文書の著者は、ほとんどの実装者は仕様書を
生み出した経験と議論の利益を持たないとして、推奨と要求に従わないことの
security の意味を詳細に練り上げるために時間を費すべきである。
-------------------------------------------------------------------------
8. Acknowledgments
8. 謝辞
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.
これらの用語の定義は、number of RFCs から引用された定義の混合である。
その上、提案は Robert Ullmann, Thomas Narten, Neal McBurnett と Robert
Elz を含む幾人かの人達から組み入れられた。
-------------------------------------------------------------------------
9. Author's Address
9. 著者のアドレス
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
---
Copyright (C) The Internet Society (March 1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
一覧
スポンサーリンク
