Кратко

  • RFC 2000 фиксировал два независимых решения: положение спецификации в процессе стандартизации и силу рекомендации по реализации в заданной области применимости.
  • Включение, зрелость и Required были датированными институциональными свидетельствами. Они сами по себе не доказывали внедрение, взаимодействие реализаций, трафик, полномочия на закупку или актуальность; Historic также не означал исчезновения действующих систем.

RFC 2000 вышел в феврале 1997 года как STD 1 и заменил RFC 1920 вместе с более ранними сводками. Документ ожидал примерно ежеквартального обновления и прямо запрещал пользоваться этой редакцией после 16 июня. В июне его сменил RFC 2200 с новой предельной датой. Официальной была текущая версия снимка, а не вечный список.

Строка такого списка отвечала на вопрос о классификации в конкретный момент. Она не подсчитывала работающие реализации. Сам RFC 2000 признавал, что некоторые протоколы производителей получили широкое распространение без одобрения IESG. Формальный статус и эксплуатационное принятие могли расходиться.

Первая ось, STATE, содержала Standard, Draft Standard, Proposed Standard, Experimental, Informational и Historic. Вторая, STATUS, содержала Required, Recommended, Elective, Limited Use и Not Recommended. Нарисованная матрица показывала приблизительно типичные сочетания, а не количество узлов, продажи или долю трафика.

На оси зрелости Standard означал, что IESG установил официальный Internet Standard и назначил номер STD. По RFC 2026 Draft Standard требовал не менее двух независимых взаимодействующих реализаций из разных кодовых баз и достаточного успешного опыта эксплуатации. Даже тогда крупный производственный масштаб мог выявить неожиданное поведение. Proposed Standard обычно не требовал ни реализации, ни эксплуатации. Он подтверждал относительно стабильного кандидата, но не работу нескольких продуктов в поле.

Вне стандартизационной дорожки находились три иные категории. Experimental сохранял результаты исследований; RFC 2000 включал их для удобства сообщества, а не как доказательство стандартизации. Informational мог описывать работу другой организации или поставщика. Historic отмечал заменённую или считающуюся устаревшей спецификацию. Эти определения не опрашивали оборудование и не обнуляли установленную базу.

STATUS задавал другой вопрос — ожидание внутри области применимости. Required требовался для минимального соответствия, определённого соответствующим Applicability Statement, а не для любого устройства и покупателя. Recommended был желателен, но не обязателен для минимального соответствия. Elective не создавал общей обязанности, хотя выбранную функцию следовало реализовать по спецификации. Limited Use и Not Recommended ограничивали общее использование по разным причинам, не измеряя оставшиеся системы.

Механизмы изменения тоже были разными. RFC 2000 говорил, что по стандартизационной дорожке продвигает только смена STATE, тогда как STATUS можно пересмотреть в любое время. Зрелость не превращала текст во всеобщую обязанность, а узкая необходимость не добавляла ему технической зрелости.

Внутри сводки видны и разные часы обновления. Первая часть всё ещё называла RFC 1602 окончательным описанием процесса, тогда как раздел новых RFC уже содержал RFC 2026, заменивший RFC 1602 в октябре 1996 года. Причину из этого установить нельзя. Но можно установить, что общая дата публикации не синхронизировала каждый фрагмент составного документа.

Позже изменились и правила, и носитель. RFC 6410 в 2011 году сократил дорожку до Proposed Standard и Internet Standard, сохранив для верхнего уровня требования независимых реализаций, взаимодействия, широкого развёртывания и успешной эксплуатации. RFC 7100 в 2013 году упразднил периодическую сводку STD 1: она перестала обновляться, а читатели перешли к онлайновому списку RFC Editor.

Поэтому сегодня RFC 2000 надёжно свидетельствует об официальной классификации в одном окне 1997 года. Реальное использование, соответствие, взаимодействие, закупку или сохранение нужно доказывать отдельно — реестрами реализаций, тестами, наблюдениями, областью договора и актуальным источником статуса.

Источники: RFC 2000, запись RFC Editor, RFC 1920, RFC 2026, RFC 2200, RFC 6410, RFC 7100.