Назад | Перейти на главную страницу

Какие RFC следует указывать в качестве интернет-стандартов?

Чрезвычайно часто RFC цитируются в поддержку мнений (включая вопросы и ответы по Serverfault), но средний ИТ-сотрудник очень плохо понимает, какие RFC определяют стандарты, а какие являются чисто информативными. Это не должно вызывать удивления: системные администраторы с любым уровнем опыта обычно избегают пристально смотреть на RFC, если у них нет другого выбора.

На таком сайте, как наш, чрезвычайно важно, чтобы мы не увековечивали распространенные недоразумения в наших ответах, за которые проголосовали. Случайные пользователи, заходящие из поисковых систем, будут считать, что голоса «за» без спорных комментариев являются достаточным показателем проверки. Недавно я наткнулся на ответ 2011 года, в котором было очевидно, что это точно не поймают в некоторых случаях, когда мы голосуем за и, вероятно, требует некоторых усилий по информированию нашего сообщества и Интернета в целом.

Итак, без лишних слов, как отличить RFC, который цитируется как интернет-стандарт, и тот, который является чисто информативным?

Только RFC на дорожка стандартов можно назвать определяющим стандартом. Попутно читателю необходимо понять следующие основные моменты:

  • Некоторые из старых RFC не имеют четкой маркировки. Если сомневаетесь, вставьте его в поле поиска по адресу http://www.rfc-editor.org/ и обратите внимание на Положение дел столбец. Будьте очень осторожны со всем, что помечено как Неизвестно, поскольку они фактически заброшены и не считаются актуальными.
  • Любой RFC с обозначением Исторический был устаревшим, независимо от того, как он был первоначально классифицирован.
  • Любой RFC со статусом Предлагаемый стандарт, или Интернет Стандарт жестяная банка использоваться в качестве технической справки по применимому интернет-стандарту. Это несколько противоречит интуиции и будет затронуто ниже.

  • Во всех остальных случаях RFC не может считаться обязательным авторитетным источником информации относительно стандартов Интернета.

    • При этом RFC с обозначением Лучшая текущая практика (BCP) следует рассматривать как имеющий значительный рекомендательный вес. Они не являются обязательными, как стандарт, но они тщательно проверяются и подвергаются той же проверке, что и RFC в треке стандартов. Их игнорирование не нарушает стандарта, но обычно плохая идея.
    • Информационная RFC, в которых отсутствует идентификатор BCP, лучше всего сравнить со статьей, которую вы встретите в ИТ-журнале. Вы бы не вытащили из-за стола редакционную статью и сказали директору, что она определяет стандарт, верно?
    • Экспериментальный RFC можно использовать только в качестве справочника для описываемых в них экспериментальных функций, но не как справочник по стандарту, с которым они связаны. Они существуют в вакууме, пока не будут переведены на уровень стандартов.
    • Время от времени техническая ссылка может быть опубликована в виде информационного RFC до включения в качестве стандарта Интернета. DMARC (RFC 7489) является одним из наиболее широко известных современных примеров этого. Для всех намерений и целей относитесь к ним как к экспериментальному RFC. Они существуют в вакууме и описывают необязательную функцию.
  • Даже после того, как вы пройдете по этому лабиринту, имейте в виду, что новые RFC, возможно, устарели значительные части RFC, из которых вы цитируете! Настоятельно рекомендуется использовать инструменты, предоставляющие гиперссылки на RFC, которые обновляют тот, который вы просматриваете, например, предоставленные http://tools.ietf.org/ и http://www.rfc-editor.org/.

Это основные пункты списка. Теперь перейдем к конкретике.

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

ПП 9 определяет дорожку стандартов Интернета, в первую очередь прогресс от Предлагаемый стандарт к Интернет Стандарт. Следует отметить, что это объединение нескольких RFC, начиная с RFC 2026.

Чтение RFC 2026 само по себе в вакууме - обычное дело, но также ужасная идея:

  • RFC 6410 устраняет понятие Проект стандартов целиком.
  • RFC 7127 является более поздним (2014 г.) обновлением BCP 9, в котором ясно показано, что многие Предлагаемые стандарты никогда не повышаются до Интернет Стандарт несмотря на широкое внедрение и высокую стабильность. Это во многом связано с более высокими стандартами проверки, которые современные Предлагаемые стандарты подвергаются до того, как будут классифицированы как таковые. Этот RFC фактически отменяет предыдущее заявление RFC 2026 о том, что «Разработчики должны рассматривать Предлагаемые стандарты как незрелые спецификации». Никогда никому не цитируйте эту строчку.

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

Отказ от ответственности

Как видно из приведенного выше, дорожка интернет-стандартов, определенная BCP 9, является подвижной целью. Этот ответ является моментальным снимком во времени и может потребовать обновления в будущем. Учитывая его статус вики сообщества, не стесняйтесь делать это или улучшать его любым способом.

В предыдущем ответе довольно хорошо изложены категории документов IETF. Все стандарты отслеживания RFC перечислены здесь:

https://www.rfc-editor.org/standards

Процесс перехода RFC от предложенного или чернового к полному стандарту достаточно утомителен, поэтому немногие авторы удосуживаются этим заниматься. Это означает, что на практике, хотя пересмотренный документ, такой как RFC 5322, является всего лишь черновиком стандарта, а его предшественник 822 все еще является номинальным интернет-стандартом, 5322 - это тот, которому следуют люди.