Кратко

  • RFC 1 разделила ответственность: BBN описала программное обеспечение Interface Message Processor (IMP), а группам хостов предстояло согласовать ПО, которое позволило бы их компьютерам использовать сеть.
  • Стив Крокер назвал содержание предварительным и ждал откликов. Позже RFC 3 объяснила, что опубликованный текст могут принять за авторитетное решение лишь потому, что он записан, хотя серия была задумана для обсуждения ещё не утверждённых идей.
  • Изменения в RFC 6, реализация GORDO в UCLA, описанная RFC 11, и последующие правки в RFC 33 показывают продолжающуюся работу. Они не доказывают, что все хосты приняли RFC 1 без изменений.

Над пакетной сетью требовалось согласовать работу хостов

В ранней ARPA Network существовала чёткая техническая граница. Bolt, Beranek and Newman описала программное обеспечение IMP — машин, пересылавших сообщения между узлами сети. Подключённым компьютерам всё равно требовались общие программные правила: как открывать соединения, различать логические линии и обрабатывать данные, пришедшие с удалённого хоста.

7 апреля 1969 года Стив Крокер попытался свести эту задачу взаимодействия хостов в один документ. RFC 1 кратко описала формат сообщений IMP и наметила ПО для запросов соединения, сеансов, похожих на работу с телетайпом, передачи больших файлов, проверки ошибок и интерактивной работы. В ней также обсуждался локальный интерфейс, который мог бы мгновенно отвечать на действия терминала без пересылки каждой клавиши через сеть.

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

Во введении Крокер прямо указал состояние проекта: группа достигла нескольких предварительных договорённостей, столкнулась с открытыми вопросами, и мало что в записке было окончательно. Значение документа отчасти в том, что он сохранил эту незавершённость. Если читать его как готовую спецификацию, исчезает сама стадия работы, которую он описывает.

Что именно предлагала первая записка

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

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

Первые описанные эксперименты тоже имели ограниченный охват. Крокер рассказал о работе SRI над поисковой системой и DEL-фронтендом, а также о планах UCLA и Utah использовать NLS. Это показывает, что пытались создать участники. Но это не реестр установок на каждом узле и не доказательство, что все четыре начальных хоста реализовали каждое предложение.

Первая RFC не была приказом органа стандартизации. Она давала общее место для обсуждения вариантов, исправлений и обратной связи, а распределённой между разными университетами группе — конкретный текст для совместной работы.

Серия помогала фиксировать разногласия

Через два дня после RFC 1 Билл Дюваль написал RFC 2 с тем же названием — «Host Software». В RFC 3 появились правила для документов: записку мог подготовить любой участник с любого узла; своевременность ставилась выше редакционной отделки; одинаковые названия допускались. Серийные номера выдавал Билл Дюваль из SRI.

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

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

Изменения и реализации дают разные свидетельства

RFC 6, где Крокер описал разговор с Бобом Каном 10 апреля, зафиксировала изменение поля линии Host–IMP: его сократили до пяти битов и добавили бит, указывающий на преобразование. Деталь невелика, но важна хронология: всего через несколько дней после RFC 1 один из её элементов ещё обсуждался и менялся.

В августе Джерард Делош в RFC 11 описал процедуры взаимодействия хостов и их реализацию в GORDO — системе разделения времени UCLA для SDS Sigma 7. Документ охватывал типы соединений, управляющие сообщения, контрольные суммы, буферы и программы, связывавшие пользователей с интерфейсом IMP. В том же месяце RFC 13 сослалась на RFC 11 и предложила сообщение нулевой длины для обозначения конца передачи файла по вспомогательному соединению.

Эти записи показывают, как идеи становились конкретнее в названной реализации, а затем порождали узкое предложение для отдельной задачи. Но они не доказывают, что каждый хост использовал процедуры GORDO или что сеть перестала меняться. Реализация убедительнее предложения показывает работу на одном узле, но не сообщает, сколько других узлов её приняли.

RFC 33 прямо проводит эту границу. В феврале 1970 года она сообщала о множестве изменений по сравнению со старым протоколом RFC 11 и связывала их с сетевой встречей в декабре. В записке говорилось, что приложенных материалов недостаточно для написания Network Control Program, и запрашивались ответы. Соединения уже работали и сеть начали использовать, но протокол хостов всё ещё пересматривали и описывали.

Почему RFC 1 важна, хотя она не сказала последнего слова

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

Это не то же самое, что развернуть протокол. Текст может очертить общую задачу; правка — сузить разногласия; код — показать, что одна система работает; повторные испытания совместимости — подтвердить, что независимые системы одинаково понимают сообщения. Этапы связаны, но один не подтверждает автоматически следующий.

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

Источники

RFC 1 — первичный источник предварительного предложения Крокера. RFC 2 содержит записку Билла Дюваля «Host Software», а RFC 3 объясняет ранние правила документации. RFC 6 фиксирует последующее обсуждение интерфейса Host–IMP. В RFC 11 Делош описал процедуры и реализацию GORDO; в RFC 13 Серф предложил маркер конца вспомогательной передачи. RFC 33 Крокера и коллег документирует последующие изменения и нерешённые вопросы. В индексе RFC 170 за 1971 год перечислены ранние записки и их даты.