Статус документа
Этот документ относится к категории документов 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) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие — опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.