본 글은 RFC2119 내용을 DeepL을 이용하여 번역한 내용입니다.
Key words for use in RFCs to Indicate Requirement Levels
RFC에서 요구 수준을 나타내는 데 사용되는 키워드
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
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:
많은 표준 트랙 문서에서 명세의 요구 사항을 나타내기 위해 여러 단어가 사용됩니다. 이러한 단어들은 종종 대문자로 표시됩니다. 이 문서에서는 이러한 단어들을 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.
이 단어나 "REQUIRED" 또는 "SHALL"이라는 용어는 해당 정의가 명세의 절대적인 요구 사항임을 의미합니다
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
이 구문이나 "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.
이 단어나 형용사 "RECOMMENDED"는 특정 상황에서 특정 항목을 무시할 수 있는 유효한 이유가 있을 수 있지만, 다른 방향을 선택하기 전에 전체적인 영향을 이해하고 신중히 고려해야 함을 의미합니다.
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.
이 구문이나 "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.)
이 단어나 형용사 "OPTIONAL"은 항목이 실제로 선택 사항임을 의미합니다. 특정 시장에서 필요하거나 제품을 향상시킨다고 판단되어 특정 업체가 해당 항목을 포함하기를 선택할 수 있으며, 다른 업체는 동일한 항목을 생략할 수 있습니다. 특정 옵션을 포함하지 않는 구현은 해당 옵션을 포함한 다른 구현과 상호 운용할 수 있어야 하지만 기능이 줄어들 수 있습니다. 마찬가지로, 특정 옵션을 포함한 구현은 해당 옵션을 포함하지 않은 다른 구현과도 상호 운용할 수 있어야 합니다(물론, 옵션이 제공하는 기능을 제외하고).
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.
이 용어들은 보안 영향을 가진 행동을 지정하는 데 자주 사용됩니다. MUST 또는 SHOULD를 구현하지 않거나 명세서에서 MUST NOT 또는 SHOULD NOT로 명시한 동작을 수행하지 않는 경우의 보안 영향은 매우 미묘할 수 있습니다. 문서 작성자는 권장 사항이나 요구 사항을 따르지 않을 때의 보안 영향을 자세히 설명하는 데 시간을 할애해야 합니다. 대부분의 구현자는 명세서를 작성한 경험과 토론의 혜택을 받지 못했을 것이므로요.
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.
이러한 용어의 정의는 여러 RFC에서 가져온 정의들의 융합입니다. 또한, Robert Ullmann, Thomas Narten, Neal McBurnett, 그리고 Robert Elz를 비롯한 여러 사람들의 제안이 통합되었습니다.
9. Author's Address
[RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
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. This document specifies an Inte
datatracker.ietf.org](https://datatracker.ietf.org/doc/html/rfc2119#section-9)
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
댓글