Кратко

  • RFC 1280 была периодическим координационным снимком, а не живым реестром: читателя просили найти актуальную редакцию и не пользоваться этой после 31 июля 1992 года.
  • STATE обозначала зрелость стандартизации, STATUS — требование к реализации. Ни одна отметка сама по себе не доказывала внедрение или успешную работу.

Перечень может вводить в заблуждение именно потому, что он полезен. Тем, кому нужно было понять место протокола в процессе интернет-стандартизации, требовался общий ориентир, а не разрозненные RFC. RFC 1280 свела записи в один документ, объяснила этапы стандартизации и добавила уровни требований. Но она ограничила и собственную актуальность: мартовскую редакцию 1992 года планировали выпускать примерно раз в квартал и предписывали не использовать после июля.

Этот срок не означал, что 1 августа изменятся все протоколы. Он очерчивал временные границы свидетельств, собранных в справочнике. IAB советовал запрашивать действующую копию в Network Information Center или IANA и читать примечания об изменениях. В сентябре RFC 1360 заменила RFC 1280. Официальный перечень мог точно фиксировать состояние на дату публикации и всё же устареть к следующему решению.

Таблица разделяла две координаты. STATE описывала зрелость спецификации: standard, draft standard, proposed standard, experimental, informational или historic. STATUS задавала ожидание от реализации: required, recommended, elective, limited use или not recommended. Предложенная спецификация могла быть необязательной; информационный документ мог рекомендовать применение. Первая ось показывала положение текста в процессе, вторая — ожидания от определённых классов систем.

Это не была перепись работающих устройств. RFC 1280 отмечала, что некоторые протоколы поставщиков получили широкое распространение без рекомендации IESG или ратификации IAB. А отметка «experimental» позволяла документировать исследование, но не рекомендовала производственное применение. Публикация не подтверждает внедрение, а этап стандартизации не измеряет популярность. Для таких выводов нужны отдельные данные: независимые реализации, тесты совместимости и эксплуатационный опыт.

Ссылочные документы также обновлялись не одновременно. Assigned Numbers, Gateway Requirements и Host Requirements имели разные циклы; при расхождении следовало применять более новый документ. RFC 1280 помогала найти актуальную спецификацию протокола, но не синхронизировала всю базу ссылок. RFC 1310 описывала процесс и называла периодический перечень авторитетной записью о статусе спецификаций. Но эта авторитетность ограничена датой и областью: историческая строка не показывает сегодняшнее поведение протокола, фактическую установку или ответ службы.

Источники: RFC 1280; RFC 1310; RFC 1360.