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

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

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

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

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

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

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

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

Это точки пули. Теперь мы собираемся вдаваться в детали.

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

BCP 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 - это тот, за кем следуют.