RFC 2119 · BCP 14 · Март 1997

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

Network Working Group
С. Брэднер (S. Bradner), Harvard University
Категория: наилучшая текущая практика

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

Этот документ определяет наилучшую текущую практику Интернета для интернет-сообщества и приглашает к обсуждению и предложениям по улучшению. Распространение документа не ограничено.

Аннотация

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

5. MAY — допускается

Это слово, а также прилагательное «OPTIONAL» означают, что положение действительно необязательно. Один поставщик может включить такую возможность, поскольку этого требует определённый рынок или поскольку, по его мнению, она улучшает продукт; другой поставщик может её не включать. Реализация, не включающая определённую необязательную возможность, ОБЯЗАНА (MUST) быть готовой взаимодействовать с реализацией, которая эту возможность включает, хотя, возможно, с сокращённой функциональностью. Аналогично реализация, включающая определённую необязательную возможность, ОБЯЗАНА (MUST) быть готовой взаимодействовать с реализацией, которая её не включает — разумеется, за исключением функций, предоставляемых самой этой возможностью.

6. Рекомендации по использованию этих предписаний

Предписания, определённые в этом документе, необходимо использовать осторожно и умеренно. В частности, их ОБЯЗАТЕЛЬНО (MUST) использовать лишь там, где это действительно необходимо для взаимодействия либо для ограничения поведения, способного причинить вред, например для ограничения повторных передач. Их, например, нельзя использовать для навязывания разработчикам конкретного метода, если этот метод не требуется для совместимости.

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

Телефон: +1 617 495 3864
Email: sob@harvard.edu

Перевод: RFCNET · rfcnet.ru

Неофициальный перевод. При расхождениях см. оригинал.