Кратко

  • RFC 1681 предлагал кодировать в адресе назначения класс плательщика либо индекс таблицы алгоритмов начисления, чтобы клиент и пограничный маршрутизатор могли решить вопрос до обращения.
  • Документ считал неприемлемым узнавать о расходах постфактум и объяснял, почему сообщение при установлении соединения не помогает в автоматическом обмене или после незаметного перенаправления Gopher.
  • Сигнал адреса мог выбрать политику, но сам по себе не доказывал личность, действующие условия, осознанное согласие, полезную услугу, верное измерение, законный счёт или его погашение.

Перенаправление могло опередить предупреждение

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

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

Предложение переносило один элемент тарифа вперёд. Часть битов адреса определяла бы, кто платит. Более длинное поле могло стать индексом таблицы алгоритмов начисления. Маршрутизатор на границе организации распознавал бы платный класс и применял локальный запрет или разрешение до пересылки.

Адрес не превращался в счёт. Он становился ранней машинной меткой, которую обычный сетевой путь видел до обращения к услуге.

Число хостов переставало определять число адресов

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

Вторичный адрес мог обозначать службу, а не физический сервер. Тогда службу можно было переместить, сохранив внешнее имя на сетевом уровне. Несколько адресов на одном хосте позволяли открыть разные представления и правила доступа без нового протокола или необычного порта. Межсетевой экран мог пропускать только адрес службы, если процессы были правильно привязаны. Обычные риски аутентификации по адресу никуда не исчезали.

Документ рассматривал и расширение DNS, возвращающее номер порта. Издержкой была необходимость менять каждый клиент. Новая семантика адреса выглядела способом использовать уже развёрнутое поведение приложений.

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

Четыре ответа на вопрос о плательщике

RFC 1681 перечислил четыре модели оплаты по использованию. В обычной модели каждый хост платил за собственные пакеты, и расходы могли нести обе стороны разговора. В «caller pays» платил инициатор. В варианте collect call — получатель. Премиальная услуга по образцу американского номера «900» взимала с инициатора дополнительную плату в пользу сервера.

Поэтому вызывающая и принимающая стороны должны были заранее знать, кто платит. Узнать лишь после того, как затраты уже возникли, документ считал недопустимым.

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

Вариант с индексом делает зависимость очевидной. Адрес указывает строку, но правило находится в таблице, которой управляет конкретная сторона в конкретный период. Если сохранить адрес и потерять версию таблицы, останется ключ без исторического значения.

Маршрутизатор мог отказать, но не дать согласие за человека

Пограничный маршрутизатор был ограниченной локальной точкой контроля. RFC 1681 предполагал, что анонимным рабочим станциям в компьютерном классе общежития можно запретить collect call. Организация могла закрыть платный класс до того, как все приложения научатся показывать тариф.

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

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

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

Информационный RFC нельзя задним числом сделать внедрённым стандартом

Карточка RFC Editor относит RFC 1681 к Informational. Он был ответом на приглашение IPng в RFC 1550 и прямо указывал: публикация не означает принятия идей областью IPng. RFC 1550 описывал белые книги как материал для выбора и часть исторического следа процесса.

Позднейшие документы дают полезное сравнение, но не подтверждение. RFC 4291 назначает IPv6-адреса интерфейсам и разрешает одному интерфейсу несколько адресов разных типов и областей. Это доказывает множественность адресов в IPv6, но не принятие тарифных битов и не причинную связь с RFC 1681.

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

Рекомендация предусмотреть по 2^6, а возможно и 2^8, дополнительных адресов на хост была запасом для возможных применений, особенно дорогой схемы «адрес на пользователя». Это не наблюдаемое среднее и не гарантированное выделение.

Между сигналом и расчётом нет одного окончательного факта

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

Нижняя ступень не доказывает верхнюю. Класс не доказывает свежесть таблицы. Допуск маршрутизатора не доказывает согласие. Соединение не доказывает услугу. Счётчик пакетов не доказывает цену. Выставленный счёт не доказывает оплату.

Принцип Heng Lu Running-Code Primacy требует отделять предложение, публикацию, принятие и наблюдаемую работу. Minimum Initial Specification отделяет общие правила совместимости от коммерческих соглашений, способных оставаться локальными. Reality, Not Advocacy задаёт редакционный предел: не возрождать идею и не высмеивать её, а точно сохранить доказанный масштаб.

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

Источники