Открыть сервис

RFC 850

RFC 850 — это запрос на комментарии (Request for Comments, RFC), опубликованный в июне 1983 года в рамках серии документов, разрабатываемых Инженерным советом Интернета (IETF). Документ озаглавлен «Standard for Interchange of USENET Messages» (Стандарт обмена сообщениями USENET) и определяет формат сообщений, используемых в сети USENET, одной из первых систем распределённых конференций (телеконференций) и предшественницы современных форумов и групп новостей. RFC 850 устанавливает синтаксис заголовков и тела сообщений, обеспечивая совместимость между различными серверами и клиентами USENET. Документ был разработан Марком Хортоном (Mark Horton) и стал важным этапом в стандартизации обмена текстовыми сообщениями в ранней сети Интернет, хотя впоследствии был заменён более современными стандартами, такими как RFC 1036.

История и контекст

USENET была создана в 1979 году Томом Траскоттом (Tom Truscott) и Джимом Эллисом (Jim Ellis) как система для обмена сообщениями между компьютерами под управлением Unix. Первоначально сообщения передавались по протоколу UUCP (Unix-to-Unix Copy), и формат их заголовков не был строго стандартизирован. К началу 1980-х годов, с ростом числа серверов и пользователей, возникла необходимость в едином формате, который позволил бы разным реализациям USENET (например, B-news, A-news) корректно обрабатывать сообщения.

RFC 850 был опубликован в июне 1983 года и стал первым официальным стандартом для формата сообщений USENET. Он был основан на более ранних неофициальных спецификациях, в частности на «B-news manual» и «A-news manual», а также на практиках, сложившихся в сообществе. Документ был написан Марком Хортоном, одним из разработчиков USENET, и предназначался для замены более ранних, неформальных описаний.

В 1987 году RFC 850 был заменён документом RFC 1036 («Standard for Interchange of USENET Messages»), который уточнил и расширил спецификацию, добавив новые поля заголовков и правила обработки. Тем не менее, RFC 850 остаётся исторически значимым как первый стандарт, зафиксировавший основные принципы форматирования сообщений в USENET.

Структура сообщения по RFC 850

Сообщение в USENET, согласно RFC 850, состоит из двух частей: заголовка (header) и тела (body), разделённых пустой строкой. Заголовок содержит метаданные о сообщении, каждое из которых записывается в виде строки «Поле: значение». RFC 850 определяет обязательные и опциональные поля заголовка.

Обязательные поля заголовка

  • From: адрес электронной почты отправителя (например, user@host.domain). Поле указывает автора сообщения.
  • Date: дата и время отправки сообщения в формате, соответствующем RFC 822 (например, «Wed, 01 Jun 1983 12:00:00 EST»). Формат времени включает часовой пояс.
  • Newsgroups: список групп новостей (иерархических категорий), в которые отправлено сообщение. Группы разделяются запятыми (например, «comp.lang.c, misc.test»).
  • Subject: тема сообщения (строка текста, не превышающая 72 символа). Поле Subject может содержать префиксы, такие как «Re:» для ответов.
  • Message-ID: уникальный идентификатор сообщения, формируемый сервером. Обычно имеет формат <число@домен> (например, 1234@example.com). Идентификатор гарантирует, что каждое сообщение может быть однозначно идентифицировано.

Опциональные поля заголовка

RFC 850 допускает использование дополнительных полей, которые могут быть добавлены клиентами или серверами для расширения функциональности. К ним относятся:

  • Reply-To: адрес для ответов, если он отличается от поля From.
  • Followup-To: список групп новостей, в которые должны направляться последующие обсуждения (например, для перенаправления дискуссии).
  • Expires: дата, после которой сообщение может быть удалено с сервера (например, для временных объявлений).
  • References: список идентификаторов сообщений, на которые отвечает данное сообщение (используется для построения цепочек обсуждений).
  • Keywords: ключевые слова для поиска (строка, разделённая запятыми).
  • Summary: краткое содержание сообщения (строка текста).

Тело сообщения

Тело сообщения содержит собственно текст, который может быть как простым текстом, так и включать цитирование предыдущих сообщений (обычно с префиксом «>»). RFC 850 не определяет формат кодирования символов, но предполагает использование 7-битного ASCII, что было стандартом для ранних сетей. Длина строки тела не должна превышать 72 символа, хотя на практике это ограничение часто нарушалось.

Ограничения и недостатки

RFC 850 имел ряд ограничений, которые были устранены в последующих версиях стандарта:

  • Отсутствие поддержки MIME: RFC 850 не предусматривал возможность вложения файлов или использования не-ASCII символов. Сообщения могли содержать только текст в кодировке ASCII, что ограничивало интернационализацию.
  • Неопределённость в обработке заголовков: Некоторые поля, такие как «Date», не имели строгого формата, что приводило к проблемам совместимости между разными реализациями.
  • Отсутствие механизма подписи: RFC 850 не включал криптографические методы для аутентификации отправителя или проверки целостности сообщения, что делало возможным подделку заголовков (например, поля From).
  • Ограничение на длину строк: Требование к длине строки в 72 символа было неудобным для длинных сообщений и цитирования.

Значение и влияние

RFC 850 сыграл ключевую роль в стандартизации USENET, которая в 1980-х годах была одной из основных платформ для обсуждения технических и научных тем, а также для распространения информации. Документ обеспечил совместимость между различными реализациями серверов и клиентов, что способствовало росту сети. Многие принципы, заложенные в RFC 850, были перенесены в более поздние стандарты, включая RFC 1036 и RFC 5537 (Netnews Architecture and Protocols).

Кроме того, формат заголовков, определённый в RFC 850, оказал влияние на разработку других протоколов, таких как SMTP (RFC 821) и HTTP (RFC 1945), где используются аналогичные структуры полей (например, From, Date, Subject). Однако сам RFC 850 устарел и в настоящее время не используется в современных реализациях USENET, которые опираются на более новые стандарты.

Пример сообщения по RFC 850

Ниже приведён пример сообщения, соответствующего RFC 850:

``` From: user@example.com Date: Wed, 01 Jun 1983 12:00:00 EST Newsgroups: comp.lang.c, misc.test Subject: Re: C programming question Message-ID: 1234@example.com References: 5678@otherhost.com Reply-To: user@example.com

In article 5678@otherhost.com, someone@otherhost.com writes:
How do I declare a pointer to a function in C?

You can use the syntax: int (*func_ptr)(int, char); ```

Сравнение с RFC 1036

RFC 1036, опубликованный в 1987 году, заменил RFC 850 и внёс следующие изменения:

  • Уточнение формата даты: RFC 1036 требует использования формата, строго соответствующего RFC 822, с обязательным указанием часового пояса.
  • Добавление новых полей: Введены поля «Organization», «Distribution» (для ограничения распространения сообщения), «Approved» (для модернируемых групп) и другие.
  • Улучшение обработки цитирования: RFC 1036 рекомендует использовать префикс «>» для цитирования, но не требует строгого соблюдения.
  • Поддержка MIME: RFC 1036 не включает MIME, но последующие расширения (например, RFC 2045) добавили эту возможность.

Современное состояние

Сегодня USENET продолжает существовать, но её использование значительно сократилось с появлением веб-форумов, социальных сетей и систем мгновенного обмена сообщениями. Большинство современных серверов USENET (например, реализующих протокол NNTP) поддерживают формат сообщений, основанный на RFC 1036 и более поздних стандартах, а не на RFC 850. Тем не менее, RFC 850 остаётся важным историческим документом, иллюстрирующим ранние этапы развития сетевых протоколов и стандартизации в Интернете.

Источники

  • RFC 850 — «Standard for Interchange of USENET Messages» (1983)
  • RFC 1036 — «Standard for Interchange of USENET Messages» (1987)
  • RFC 5537 — «Netnews Architecture and Protocols» (2009)
  • «The History of USENET» — статья в сети (различные источники)
  • «USENET: A History» — книга М. Хортона

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →