⌕ Поиск по атласу

IETF · RFC · RFC2119

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

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 обозначают действительно необязательную возможность: реализации с опцией и без неё обязаны быть готовы к взаимодействию; сниженная функциональность допускается у реализации без опции при обмене с реализацией, имеющей опцию, а обратное исключение относится к функциональности, предоставляемой самой опцией. Императивы следует применять осторожно и редко — только там, где это действительно требуется для обеспечения совместимости или для ограничения поведения, способного причинить вред. Авторам следует разъяснять последствия для безопасности несоблюдения требований и рекомендаций. Сила этих ключевых слов зависит также от уровня требований документа, в котором они используются.

Назначение

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

Применение

Применяется при написании и разборе требований IETF. Авторам следует включать предусмотренную RFC фразу о толковании терминов ближе к началу документа. Императивы допустимы только там, где это действительно требуется для обеспечения совместимости или для ограничения поведения, способного причинить вред.

RFC 2119 является BCP 14 и действует; он обновлён RFC 8174. Специальный нормативный смысл в актуальной практике BCP 14 связан с написанием ключевых слов прописными буквами. Не используйте эти слова для навязывания конкретного метода реализации, если он не нужен для совместимости. Редакционное пояснение: раздел 6 английского оригинала допускает неоднозначную синтаксическую связь условия «действительно требуется» с обеспечением совместимости и ограничением вредного поведения. Близкий к оригиналу перевод сохраняет эту неоднозначность и не устанавливает дополнительного нормативного толкования.

Официальная английская аннотация

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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Связи документа

updated_by: RFC8174

is_also: BCP14

Читать полный русский перевод →

Официальный источник · 1997-03-01

Полные импортированные сведения карточки
{
  "id": "RFC2119",
  "number": 2119,
  "title_en": "Key words for use in RFCs to Indicate Requirement Levels",
  "title_ru": "Ключевые слова для обозначения уровней требований в RFC",
  "summary_ru": "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 обозначают действительно необязательную возможность: реализации с опцией и без неё обязаны быть готовы к взаимодействию; сниженная функциональность допускается у реализации без опции при обмене с реализацией, имеющей опцию, а обратное исключение относится к функциональности, предоставляемой самой опцией. Императивы следует применять осторожно и редко — только там, где это действительно требуется для обеспечения совместимости или для ограничения поведения, способного причинить вред. Авторам следует разъяснять последствия для безопасности несоблюдения требований и рекомендаций. Сила этих ключевых слов зависит также от уровня требований документа, в котором они используются.",
  "purpose_ru": "Установить единообразный нормативный смысл ключевых слов, которыми в RFC и других документах IETF задаётся обязательность требований.",
  "use_ru": "Применяется при написании и разборе требований IETF. Авторам следует включать предусмотренную RFC фразу о толковании терминов ближе к началу документа. Императивы допустимы только там, где это действительно требуется для обеспечения совместимости или для ограничения поведения, способного причинить вред.",
  "full_translation_path": "translations/rfc2119.html",
  "full_translation_checked_at": "2026-09-20",
  "full_translation_source_sha256": "3c2ceb7bfc84cd34720f4a5271338ab9d8280d34bdd1eb250c64306202f2ed8b",
  "architect_note_ru": "RFC 2119 является BCP 14 и действует; он обновлён RFC 8174. Специальный нормативный смысл в актуальной практике BCP 14 связан с написанием ключевых слов прописными буквами. Не используйте эти слова для навязывания конкретного метода реализации, если он не нужен для совместимости. Редакционное пояснение: раздел 6 английского оригинала допускает неоднозначную синтаксическую связь условия «действительно требуется» с обеспечением совместимости и ограничением вредного поведения. Близкий к оригиналу перевод сохраняет эту неоднозначность и не устанавливает дополнительного нормативного толкования.",
  "topics_ru": [
    "нормативные требования",
    "терминология"
  ],
  "translation_state": "reviewed",
  "verification_level": "primary_source_reviewed",
  "verification_level_ru": "Проверено по первичному тексту и реестру RFC Editor",
  "verification_note_ru": "Полный текст и карточка независимо сверены с первоисточником. 2026-09-20",
  "abstract_en": "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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.",
  "authors": [
    "S. Bradner"
  ],
  "organizations": [],
  "publication_date": "1997-03-01",
  "current_status": "BEST CURRENT PRACTICE",
  "current_status_ru": "Лучшая современная практика",
  "publication_status": "BEST CURRENT PRACTICE",
  "publication_status_ru": "Лучшая современная практика",
  "lifecycle": "active",
  "lifecycle_ru": "Действующий",
  "stream": "IETF",
  "stream_ru": "IETF",
  "area": "",
  "area_ru": "",
  "working_group": "NON WORKING GROUP",
  "source_draft": "draft-bradner-key-words-02",
  "page_count": 3,
  "doi": "10.17487/RFC2119",
  "keywords": [
    "Standards",
    "Track",
    "Documents"
  ],
  "formats": [
    "TXT",
    "HTML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [],
    "updated_by": [
      "RFC8174"
    ],
    "is_also": [
      "BCP14"
    ],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc2119/",
    "html": "https://www.rfc-editor.org/rfc/rfc2119.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc2119.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc2119/"
  }
}