Key words for use in RFCs to Indicate Requirement Levels
RFC 2119 определяет, как в документах IETF следует толковать слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL при задании требований. MUST/REQUIRED/SHALL означают абсолютное требование, а MUST NOT/SHALL NOT — абсолютный запрет. Для SHOULD допустимы обоснованные исключения, но перед выбором иного подхода последствия должны быть полностью поняты и тщательно взвешены; для SHOULD NOT в определённых обстоятельствах могут существовать обоснованные причины, при которых описанное поведение приемлемо или даже полезно; прежде чем реализовать поведение, помеченное SHOULD NOT, следует понять все последствия и тщательно взвесить конкретный случай. MAY/OPTIONAL обозначают действительно необязательную возможность: реализации с опцией и без неё обязаны быть готовы к взаимодействию; сниженная функциональность допускается у реализации без опции при обмене с реализацией, имеющей опцию, а обратное исключение относится к функциональности, предоставляемой самой опцией. Императивы следует применять осторожно и редко — только там, где это действительно требуется для обеспечения совместимости или для ограничения поведения, способного причинить вред. Авторам следует разъяснять последствия для безопасности несоблюдения требований и рекомендаций. Сила этих ключевых слов зависит также от уровня требований документа, в котором они используются.
Рабочая группа по сетям S. Bradner
Запрос комментариев: 2119 Harvard University
BCP: 14 Март 1997
Категория: Лучшая современная практика
Ключевые слова для обозначения уровней требований в RFC
Статус этого меморандума
Этот документ устанавливает Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение данного меморандума не ограничено.
Аннотация
Во многих документах трека стандартов несколько слов используются для
обозначения требований в спецификации. Эти слова часто пишутся
прописными буквами. Этот документ определяет, как следует
интерпретировать эти слова в документах IETF. Авторам, следующим этим
рекомендациям, следует включать следующую фразу в начале своего
документа:
Ключевые слова "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" и
"OPTIONAL" в этом документе подлежат интерпретации, описанной в
RFC 2119.
Обратите внимание, что сила действия этих слов изменяется уровнем
требований документа, в котором они используются.
1. ДОЛЖЕН (MUST) Это слово или термины "REQUIRED" либо "SHALL" означают,
что определение является абсолютным требованием спецификации.
2. НЕ ДОЛЖЕН (MUST NOT) Эта фраза или фраза "SHALL NOT" означают, что
определение является абсолютным запретом спецификации.
3. СЛЕДУЕТ (SHOULD) Это слово или прилагательное "RECOMMENDED" означают,
что в определённых обстоятельствах могут существовать веские причины
проигнорировать конкретный элемент, но перед выбором другого подхода
необходимо полностью понять и тщательно взвесить все последствия.
4. НЕ СЛЕДУЕТ (SHOULD NOT) Эта фраза или фраза "NOT RECOMMENDED" означают,
что в определённых обстоятельствах могут существовать веские причины,
при которых конкретное поведение приемлемо или даже полезно, но перед
реализацией любого поведения, описанного этой меткой, следует понять
все последствия и тщательно взвесить данный случай.
Bradner Лучшая современная практика [Страница 1]
RFC 2119 Ключевые слова RFC Март 1997
5. МОЖЕТ (MAY) Это слово или прилагательное "OPTIONAL" означают, что
элемент является действительно необязательным. Один поставщик может
решить включить элемент, поскольку он требуется конкретным рынком или
поскольку поставщик считает, что он улучшает продукт, тогда как другой
поставщик может опустить тот же элемент. Реализация, не включающая
конкретную опцию, ДОЛЖНА (MUST) быть готова к взаимодействию с другой
реализацией, включающей эту опцию, хотя, возможно, с ограниченной
функциональностью. Аналогично, реализация, включающая конкретную
опцию, ДОЛЖНА (MUST) быть готова к взаимодействию с другой реализацией,
не включающей эту опцию (за исключением, разумеется, возможности,
предоставляемой этой опцией).
6. Рекомендации по использованию этих императивов
Императивы типа, определённого в этом меморандуме, необходимо
использовать осторожно и редко. В частности, они ДОЛЖНЫ (MUST)
использоваться только там, где это действительно требуется для
взаимодействия или для ограничения поведения, которое потенциально
может причинить вред (например, для ограничения повторных передач).
Например, их не следует использовать для попытки навязать
реализаторам конкретный метод, если этот метод не требуется для
совместимости.
7. Соображения безопасности
Эти термины часто используются для задания поведения, имеющего
последствия для безопасности. Последствия для безопасности от
нереализации требования ДОЛЖЕН (MUST) или СЛЕДУЕТ (SHOULD), либо от
выполнения того, что спецификация предписывает НЕ ДОЛЖЕН (MUST NOT)
или НЕ СЛЕДУЕТ (SHOULD NOT) выполнять, могут быть весьма тонкими.
Авторам документов следует уделить время подробному описанию
последствий несоблюдения рекомендаций или требований для безопасности,
поскольку большинство реализаторов не имели преимуществ опыта и
обсуждений, в результате которых появилась спецификация.
8. Благодарности
Определения этих терминов представляют собой объединение определений,
взятых из ряда RFC. Кроме того, были включены предложения ряда людей,
включая Robert Ullmann, Thomas Narten, Neal McBurnett и Robert Elz.
Bradner Лучшая современная практика [Страница 2]
RFC 2119 Ключевые слова RFC Март 1997
9. Адрес автора
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
Bradner Лучшая современная практика [Страница 3]
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
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.
Bradner Best Current Practice [Page 1]
RFC 2119 RFC Key Words March 1997
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.
Bradner Best Current Practice [Page 2]
RFC 2119 RFC Key Words March 1997
9. Author's Address
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
Bradner Best Current Practice [Page 3]