Network Working Group                                         S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       March 1997
Category: Best Current Practice

Ключевые слова для обозначения уровня требований в RFC

Key words for use in RFCs to Indicate Requirement Levels

PDF

Статус документа

Этот документ относится к категории документов BCP (Best Current Practice) для сообщества Internet. Принимаются поправки и предложения, направленные на совершенствование документа. Допускается свободное распространение документа.

Аннотация

Во многих документах, описывающих стандарты, используются модальные глаголы для обозначения уровня требований. Такие слова часто выделяются заглавными буквами¹. В данном документе определяется толкование этих глаголов и производных от них слов в документах 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².

Отметим, что “сила” этих глаголов зависит от уровня требований использующего их документа.

1. MUST – необходимо

Это слово, а также термины требуется (REQUIRED) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

2. MUST NOT – недопустимо

Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

3. SHOULD – следует

Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

4. SHOULD NOT – не следует

Эта фраза и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

5. MAY – возможно

Это слово, а также прилагательное необязательный (OPTIONAL) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие – опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счёт некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.

6. Рекомендации по использованию

Приведённые в этом документе определения следует использовать очень аккуратно. В частности, необходимо применять их лишь там, где это действительно диктуется требованиями функциональной совместимости или для предотвращения ситуаций, когда может быть нанесён вред (например, для ограничения избыточных повторов передачи). Например, такие обозначения недопустимо использовать для обозначения преимуществ одной реализации по сравнению с другой, если это не продиктовано соображениями функциональной совместимости.

7. Вопросы безопасности

Рассматриваемые здесь термины часто используются при обсуждении вопросов безопасности. Отказ от выполнения необходимых (MUST) или рекомендуемых (SHOULD) требований или реализация недопустимых (MUST NOT)/нерекомендуемых (SHOULD NOT) может существенно влиять на безопасность. Авторы документов должны уделить внимание вопросам безопасности, чтобы не появлялись реализации с невыполненными требованиями или рекомендациями.

8. Благодарности

Определения терминов даны на основе использования этих терминов в RFC. Кроме того, при подготовке документа были учтены предложения многих людей, включая Robert Ullmann, Thomas Narten, Neal McBurnett, Robert Elz.

9. Адрес автора

Scott Bradner

Harvard University

1350 Mass. Ave.

Cambridge, MA 02138

phone – +1 617 495 3864

email – sob@harvard.edu

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru