Кратко

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

Анализ

Адрес терминала не наблюдал человека

RFC 1312 вышел в апреле 1992 года как Experimental-протокол для отправки короткого сообщения пользователю на терминал некоторого хоста. Формат включал октет версии и заканчивающиеся нулём поля: получатель, терминал получателя, текст сообщения, отправитель, терминал отправителя, cookie и подпись. Вся структура ограничивалась 512 октетами. Краткость пакета не устраняла того, что его человеческий адресат оставался переменной.

Пустое поле получателя могло разрешить доставку любому пользователю целевой системы. Если пустым было поле терминала, система должна была выбрать «правильный» терминал, причём это решение RFC называет зависящим от системы. Звёздочка в поле терминала означала все терминалы. При двух пустых полях сообщение следовало записать на console — место, которое, вероятно, увидит оператор или администратор. Это полезные указания получающей службе. Они не говорят, кто находится перед устройством, какой экран выбран и вошёл ли текст в чьё-либо внимание.

Такое различие не сводится к придирке к словам. Имя получателя здесь является частью запроса, который местная система ещё должна истолковать. Терминал может быть предпочтением, набором устройств или результатом внутреннего выбора. Console определяется своей функцией, а не личностью читателя. Успешная обработка запроса машиной не становится из-за этого наблюдением за человеком.

У плюса был ограниченный предмет

В варианте TCP клиент устанавливал соединение, посылал сообщение и получал от сервера один символ — + или , при необходимости с пояснением. Плюс обозначал успешную доставку некоторому пользователю или терминалу; минус — отсутствие доставки на какой-либо терминал. Для состояния самой службы это различие реально и полезно.

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

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

Молчание UDP и cookie решали иные задачи

Служба UDP может послать ответную дейтаграмму. Если сообщение адресовано конкретному пользователю и успешно доставлено именно ему, следует отправить положительное подтверждение. На сообщение для любого пользователя и на неудачную доставку ответ не посылается. RFC объясняет это желанием предотвратить лавину ответов от всех серверов при широковещательном сообщении.

Следовательно, отсутствие ответа не имеет одного-единственного смысла «доставка не удалась». Оно может быть предусмотренной политикой подавления ответов. Учёт, который механически приравнивает любую тишину UDP к провалу, добавляет к протоколу определённость, которой в нём нет.

Cookie вместе с исходным UDP-портом отправителя должен быть уникальным, чтобы сервер мог распознавать дубликаты сообщений. Клиенту разрешено передавать одно и то же сообщение несколько раз, повышая шанс приёма; сервер может отбросить повтор. Это механизм управления повторной обработкой в обозначенной области. Он не доказывает показ первой копии, внимание нужного адресата или завершение обмена между людьми.

Поле подписи не завершало вопрос об идентичности

Если SIGNATURE пусто, то, по RFC, идентичность отправителя проверить нельзя. Если поле не пусто, это регистронезависимое текстовое представление некоего защитного токена. Сам RFC не определяет ни его кодирование, ни его интерпретацию. В форме сообщения есть место для потенциального токена, но нет готового утверждения о проверенной личности.

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

Небольшое подтверждение полезнее не увеличивать

RFC 1312 не описывает современные уведомления, чаты или системы оповещения. Он не доказывает, что реальный человек получил, увидел, прочитал или одобрил сообщение, и не говорит о внедрении либо результате. Это экспериментальный текст 1992 года о конкретной службе. Его историческая ценность — в дисциплине точного названия состояния: успешная отметка должна обозначать именно тот переход, который компонент действительно наблюдал.

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

Источники

RFC 1312 — экспериментальная спецификация 1992 года; она не доказывает реального адресата, показ, прочтение, согласие, идентичность, внедрение или результат.