Полный русский перевод · RFC2119

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

Key words for use in RFCs to Indicate Requirement Levels

Карточка документа · Архив принятого перевода · Официальный источник

Рабочая группа по сетям                                      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.

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

что определение является абсолютным требованием спецификации.

определение является абсолютным запретом спецификации.

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

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

элемент является действительно необязательным. Один поставщик может
   решить включить элемент, поскольку он требуется конкретным рынком или
   поскольку поставщик считает, что он улучшает продукт, тогда как другой
   поставщик может опустить тот же элемент. Реализация, не включающая
   конкретную опцию, ДОЛЖНА (MUST) быть готова к взаимодействию с другой
   реализацией, включающей эту опцию, хотя, возможно, с ограниченной
   функциональностью. Аналогично, реализация, включающая конкретную
   опцию, ДОЛЖНА (MUST) быть готова к взаимодействию с другой реализацией,
   не включающей эту опцию (за исключением, разумеется, возможности,
   предоставляемой этой опцией).

Императивы типа, определённого в этом меморандуме, необходимо
   использовать осторожно и редко. В частности, они ДОЛЖНЫ (MUST)
   использоваться только там, где это действительно требуется для
   взаимодействия или для ограничения поведения, которое потенциально
   может причинить вред (например, для ограничения повторных передач).
   Например, их не следует использовать для попытки навязать
   реализаторам конкретный метод, если этот метод не требуется для
   совместимости.

Эти термины часто используются для задания поведения, имеющего
   последствия для безопасности. Последствия для безопасности от
   нереализации требования ДОЛЖЕН (MUST) или СЛЕДУЕТ (SHOULD), либо от
   выполнения того, что спецификация предписывает НЕ ДОЛЖЕН (MUST NOT)
   или НЕ СЛЕДУЕТ (SHOULD NOT) выполнять, могут быть весьма тонкими.
   Авторам документов следует уделить время подробному описанию
   последствий несоблюдения рекомендаций или требований для безопасности,
   поскольку большинство реализаторов не имели преимуществ опыта и
   обсуждений, в результате которых появилась спецификация.

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

Scott Bradner
      Harvard University
      1350 Mass. Ave.
      Cambridge, MA 02138

      phone - +1 617 495 3864

      email - sob@harvard.edu