Кратко
- RFC 733 унифицировал форму текстовых сообщений, передаваемых между узлами ARPANET; он не определял полноценную почтовую службу или пользовательский интерфейс.
- Общая грамматика появилась, когда доставка всё ещё использовала команды FTP, а прежние предложения и локальные парсеры уже сформировали разные ожидания.
Анализ
Быстрое решение оставалось частью FTP
К 1973 году сетевая почта уже передавалась двумя командами File Transfer Protocol: MAIL и MLFL. Они могли поместить сообщение в локальную почтовую систему получателя, но не обеспечивали единообразия заголовков. Один узел мог передать автора, тему или дату в форме, которую другой узел не распознавал надёжно. Для FTP всё сообщение, включая заголовок, оставалось данными.
RFC 524 предложил более развитый почтовый протокол внутри пространства команд FTP. Автор также объяснил, почему опирался на FTP: тот был широко реализован, тогда как предложенный унифицированный протокол пользовательского уровня — нет. RFC 561 выбрал более быстрый временный путь. Вместо ожидания новых команд доставки четыре автора предложили текстовую конвенцию для сообщений, уже отправлявшихся через MAIL или MLFL. From, Date и Subject получили узнаваемый вид, а для других полей оставалось место. Авторы прямо писали, что этот вариант легче внедрить, чем менять почтовый протокол.
Масштаб вмешательства был ограниченным. RFC 561 не заменял транспорт, а стремился сделать передаваемые данные понятнее людям и программам. Гибкость оставила и пробел: поля «прочее» можно было добавлять, но для адресатов и других элементов ещё не существовало общей грамматики.
Название RFC могло обещать больше, чем его содержание
Опубликованный в 1975 году RFC 680 назывался «Message Transmission Protocol» и расширял набор полей сообщения. Его текст определял заголовки и предполагаемый смысл полей, но не описывал передачу сообщения между узлами. RFC 724, предложивший пересмотр, указывает, что RFC 680 получил ограниченное распространение и не был формально принят как официальный стандарт ARPANET. Тем не менее некоторые разработчики воспринимали его как стандарт.
RFC 724 отмечает и другой, более непосредственный источник влияния: уже работающие почтовые программы. По словам авторов, системы TENEX создавали больше сетевых сообщений, чем узлы других типов, поэтому формат To и Cc из TENEX стал фактической конвенцией. Программы чтения TENEX начали ожидать именно его. В Multics пробовали иные форматы; согласно отчёту, затем пользователи жаловались, что почтовые системы TENEX не могут их разобрать. Это свидетельство комитета того времени, а не перепись всех узлов. Но оно показывает, почему одного официального названия документа было недостаточно, чтобы закрепить формат: ожидания формировали уже обращавшиеся сообщения и работающие парсеры.
RFC 733 стандартизировал границу
Опубликованный в ноябре 1977 года RFC 733 заменил RFC 561, RFC 680 и проект RFC 724. Он упорядочил синтаксис текстовых сообщений ARPANET, включая формы адресации получателей и ссылки на сохранённые списки адресов. В предисловии говорится, что обсуждение шло год в самой почтовой среде и в нём участвовали более двадцати человек. Это свидетельство рабочего процесса, но не доказательство принятия результата каждым узлом.
Документ чётко ограничивал свою задачу: определить формат содержимого, передаваемого между узлами. Он не предписывал, какие функции должна поддерживать локальная почтовая система и как должны выглядеть программы создания и чтения сообщений. Синтаксис позволял структурированные поля, но каждый узел мог сам решить, какие из них обрабатывать автоматически. Авторы рассчитывали, что общий формат покроет насущные потребности и даст разработчикам пространство, чтобы «надлежащим образом» создать отдельный протокол передачи почты.
Это был практический компромисс: сначала унифицировать форму сообщения, оставив конструкцию локальной службы открытой. Отправитель мог составить письмо в одной системе, а получатель прочитать его в другой, не имея одинакового интерфейса. Но публикация стандарта не обеспечивала совместимость всех реализаций по приказу. Парсеры по-прежнему надо было писать, а принятие зависело от узлов, которые их запускали.
Позднейшие стандарты яснее разделили эти уровни
В 1982 году RFC 821 определил Simple Mail Transfer Protocol как механизм передачи между узлами по надёжному упорядоченному потоку данных. В том же году RFC 822 отдельно описал формат текстовых сообщений ARPA Internet и прямо заменил RFC 733. Вместе эти документы разделяют два вопроса: как сообщение перемещается и как устроено его содержимое.
Источники позволяют сделать ограниченный вывод, но не утверждать, что RFC 733 изобрёл электронную почту или немедленно унифицировал все почтовые системы. RFC 724 сообщает о широко применявшейся, но неформальной конвенции заголовков; RFC 733 задаёт формальный синтаксис и его область; RFC 821 и 822 позднее фиксируют отдельные стандарты передачи и содержимого. Ни один из этих документов сам по себе не измеряет, сколько узлов реализовало каждое правило и когда изменилась конкретная система.
Источники и пределы доказательств
Первичные источники — RFC 524, 561, 680, 724, 733, 821 и 822. Сведения о TENEX и Multics приписаны RFC 724, документу того времени, а не превращены в статистику принятия стандарта во всей сети. Более поздняя Note 64 Хэнга Лу о минимальной начальной спецификации, локальных будущих решениях и добровольном принятии служит только аналитической оптикой. Она не доказывает намерения авторов 1970-х.
Источники
- RFC 524 — A Proposed Mail Protocol
- RFC 561 — Standardizing Network Mail Headers
- RFC 680 — Message Transmission Protocol
- RFC 724 — Proposed Official Standard for the Format of ARPA Network Messages
- RFC 733 — Standard for the Format of ARPA Network Text Messages
- RFC 821 — Simple Mail Transfer Protocol
- RFC 822 — Standard for the Format of ARPA Internet Text Messages
- Heng Lu, Note 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption (более поздняя аналитическая перспектива)
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

