Кратко

  • RFC 880 хранил статус, определяющий документ, известные проблемы, дополнительные ссылки, зависимости и контакт как разные утверждения.
  • Строки показывали независимость этих фактов: TCP был рекомендован при открытых дефектах текста, TFTP был выборочным, но использовался, GGP был экспериментальным и работал в центральных шлюзах.
  • Позднее зрелость стандарта и обязательность реализации стали отдельными осями, а периодический сводный RFC уступил онлайн-списку; ни один список сам по себе не доказывал исполнение.

Опубликованный в октябре 1983 года RFC 880 назывался Official Protocols. Название обещало перечень, а содержание давало систему предостережений. Оно показывало не только, какой документ считать спецификацией, но и где он устарел, какие реализации расходились с ним и какие функции были фактически распространены.

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

Сводить приходилось несколько документальных времён

В первом приближении RFC 880 относил к официальным протоколы из Internet Protocol Transition Workbook марта 1982 года. Затем перечислял исключения. Некоторые используемые протоколы отсутствовали в книге, другие были пересмотрены. Почта, Telnet и советы для разработчиков разошлись по новым изданиям; старые опции оставались в руководстве ARPANET 1978 года.

Предшествующий RFC 840 использовал почти ту же схему в апреле 1983-го и через полгода был заменён. Новая редакция меняла снимок каталога, а не одномоментно все программы.

STATUS, SPECIFICATION, COMMENTS, OTHER REFERENCES, DEPENDENCIES и CONTACT имели собственные полномочия. Ожидаемое внедрение, текст, отклонения, контекст, технические предпосылки и путь ответственности не сливались.

Статусы не образовывали рейтинг качества

Required требовал реализации на всех узлах. Recommended поощрял её. Elective оставлял выбор. Experimental разрешал участие в согласованном эксперименте. None означал, что запись не является протоколом.

IP и ICMP были Required, UDP и TCP — Recommended, TFTP — Elective, EGP и GGP — Experimental. Catenet Model получил None как архитектурное описание.

Из Required нельзя вывести наличие функции на конкретной машине. Recommended не удостоверяет совместимость. Elective не означает редкость. Experimental не измеряет отсутствие рабочего трафика.

Рекомендованный TCP не скрывал долг документа

Строка TCP ссылалась на RFC 793 и ставила Recommended. В комментарии говорилось о множестве исправлений, главным образом ошибок документа, а не обязательно замысла протокола.

Требовалось уточнить обработку событий. Push всё ещё напоминал в тексте маркер записи, хотя им не являлся. MSS имел неясные границы и значение по умолчанию. Слушающие серверы, бездействующие соединения, данные в очереди при закрытии, сегменты не по порядку и пользовательский таймер тоже требовали пояснений.

Рекомендация и список проблем могли быть истинны одновременно. Каталог координировал направление внедрения, но сохранял места, где один ярлык не мог решить задачу программиста.

Экспериментальный протокол мог работать в ядре

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

Эта фраза не даёт числа шлюзов, результатов тестов или доступности. Она разрушает только неверное равенство: Experimental не означает нулевое эксплуатационное применение.

У Stream Protocol реализация развилась и могла уже не соответствовать спецификации. Работающий код не удостоверял текст. TFTP был Elective и одновременно применялся в нескольких локальных сетях. Возможность выбрать и состоявшийся выбор — разные факты.

Для Telnet понадобился отдельный признак USE

Таблица опций Telnet показывала RFC или документ NIC, наличие в новом сборнике, наличие в старом руководстве и USE. Echo, Binary Transmission, Suppress Go Ahead и несколько обновлённых опций часто реализовывались; многие другие не имели общего применения.

Семейство опций оставалось Elective. Из этого RFC 880 не делал вывод, что каждый Telnet содержит каждую функцию. Широкое утверждение «поддерживает Telnet» не предсказывает согласование конкретной опции.

USE не был глобальной телеметрией с известным методом и знаменателем. Но отдельный столбец признавал необходимость отдельно говорить о документе, разрешении и наблюдаемой реализации.

Зависимость связывала статус с нижними слоями

SMTP и Telnet зависели от TCP, TFTP — от UDP, шлюзовые протоколы — от IP. Официальная верхняя строка не создавала всю цепочку исполнения.

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

RFC 991 продолжил серию в 1986 году и назвал себя официальным отчётом о статусе. Последовательность выпусков включала время в саму модель.

Зрелость и требование стали двумя формальными осями

В 1991 году RFC 1200 отделил STATE стандартизации — Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic — от STATUS требования — Required, Recommended, Elective, Limited Use, Not Recommended.

RFC 2026 развил процесс стандартов и применимость. RFC 6410 позднее сократил три уровня зрелости до двух. Изменение процедуры не было измерением внедрения.

Устарел и периодический сводный документ. RFC 7100 в 2013 году вывел из обращения последнюю сводку и STD 1 после перехода к онлайн-списку RFC Editor. Обновляемость стала лучше; список не стал датчиком работающей сети.

Источники и границы

Использованы RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 и RFC 7100. Они не доказывают нынешнюю долю внедрения, соответствие конкретного продукта, текущую безопасность, политику оператора, аварию или инцидент.