Кратко

  • RFC 8174 применяет особые значения BCP 14 только к словам, целиком набранным прописными буквами в рамках объявленного соглашения. Строчные формы сохраняют обычный английский смысл.
  • Это не означает, что нормативным бывает лишь текст с прописными словами. Нормативная фраза может обходиться без них, а сила ключевого слова зависит и от уровня документа.
  • Надежная квитанция соответствия хранит версию и статус, соглашение, полное предложение, субъекта, условие, исключение, тест и наблюдаемый результат. Список совпадений — только указатель.

Поиск нашел метку раньше обязательства

Собрать все MUST из RFC и превратить их в строки контрольной таблицы несложно. Однако та же последовательность букв может находиться в цитате, примере или обсуждении чужого требования. Поиск еще не установил, применяет ли документ BCP 14.

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

RFC 8174 устраняет одно конкретное сомнение. Именно точность решения показывает место, где автоматическое обнаружение должно уступить контекстному суждению.

«Часто прописными» оставляло две грамматики

RFC 2119 Scott Bradner ввел общий словарь уровней требований. MUST означает абсолютное требование спецификации, MUST NOT — абсолютный запрет. SHOULD допускает отступление по веской причине после оценки последствий. MAY сохраняет реальный выбор и одновременно требует совместимости вариантов.

Первоначальный текст говорил, что эти слова «часто» пишутся прописными. Поэтому строчное must можно было принять за небрежно оформленный специальный термин или за обычное английское слово. Автор, рецензент и программа могли читать одну строку по разным правилам.

Leiba закрыл развилку: специальное значение получает только полностью прописная форма. Иначе действует обычный английский смысл. Новая вводная формула заставляет сам документ объявить это соглашение.

Строчная фраза тоже может быть нормативной

Соблазнительное сокращение звучит так: прописное — нормативно, строчное — пояснение. RFC 8174 прямо не позволяет сделать такой вывод. Ключевые слова необязательны, а значительная часть нормативного текста не использует их.

Остаются два разных вопроса. Вызывает ли конкретное слово определение BCP 14? И обладает ли все предложение нормативной силой, откуда она происходит и кого охватывает? Регистр отвечает только на первый.

Если одна регулярная формула решает оба, система пропускает обязательства в обычной прозе и превращает цитаты в местные предписания. Ошибки становятся аккуратными, но не исчезают.

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

Сам RFC 2119 предупреждает: сила терминов меняется уровнем требований документа. Типографика не превращает Internet-Draft в стандарт, информационный RFC — во всеобщий мандат совместимости, а частный список — в консенсус IETF.

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

Прописные буквы делают передачу яснее, но не заменяют ни одного участника. Поэтому формула BCP 14 — запись происхождения словаря, а не украшение.

SHOULD хранит процедуру исключения

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

Текущая памятка IETF для авторов считает SHOULD особенно трудным. Нужно объяснить, почему не выбрано MUST и что произойдет при отступлении. Пометка «необязательно» в матрице соответствия удаляет именно эту логику.

Исполнимое требование включает субъекта, действие, предпосылку, исключение и влияние на совместимость. Выделенное слово лишь ведет к этой записи.

Руководство по стилю объявляет другую грамматику

RFC 7322 сначала сообщает, что не применяет терминологию RFC 2119, а затем использует строчные must и should в локальных редакционных значениях: изменения, которые RFC Editor внесет автоматически, и рекомендации, которые можно обсудить.

Это не ослабляет BCP 14. Документ заранее объясняет язык, поэтому читатель не принимает строчную форму за ошибку.

То же руководство требует нормативно сослаться на RFC 2119, если используется его толкование; иначе правильное толкование нужно определить. Знакомый вид слова не заменяет происхождение.

Структурная разметка окружает только выражение

RFCXML предлагает необязательный элемент <bcp14> вокруг выражения вроде MUST или SHOULD NOT. Официальное описание отдельно запрещает заключать в него все требование.

Граница схемы показательна. Машиночитаемый объект меньше обязательства. Субъект, действие, условие, исключение и ссылки остаются в предложении и структуре документа.

Разметка дает качественный сигнал для поиска кандидатов. Непосредственно превратить ее в испытание — значит приписать XML решение, которого он не хранит.

Регистр подтверждает словарь, а не полномочие

Barry Leiba не сделал прописные буквы более властными. Он сделал проверяемым момент, когда слово принимает определение BCP 14.

Полномочия приходят от консенсуса, потока и статуса. Область действия — от предложения и ссылок. Соответствие — от реализации и теста. По одному регистру ни один слой не восстановить.

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

Источники