Кратко

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

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

RFC 3354 был опубликован в августе 2002 года как Informational-документ с требованиями к задуманной второй версии Internet Open Trading Protocol. IOTP v1 уже описывал электронную торговлю ролями, блоками и сообщениями. Новый проект хотел сохранить основу, но снять ограничение «один платёж, затем одна доставка». Стороны должны были иметь возможность предложить любую последовательность шагов.

Ключевой глагол — «предложить». Можно сначала запросить оферту, вставить внешний платёжный протокол между сообщениями или дождаться отправки до платёжного запроса. Такая схема выражает возможные зависимости. Само её существование не даёт участникам права исполнять следующий шаг.

RFC 3354 не был готовой спецификацией IOTP v2. Он делил функции на обязательные, возможные и находящиеся вне области работы. История рабочей группы IETF TRADE отмечает завершение этапа требований v2. Это подтверждает готовность требований, а не протокола, реализации или внедрения.

В обязательный набор входили динамические последовательности, Offer Request Block, улучшенное разрешение проблем, более ясная роль Customer Care, платёжные протоколы вне туннеля IOTP и серверные кошельки. Клиент мог предъявить поддержке подписанную квитанцию. Она усиливала доказательную позицию, но не заставляла службу вернуть деньги и не доказывала её полномочий.

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

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

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

Пример отправки показывает ту же границу со стороны события. Расширенное сообщение между серверами могло позволить Delivery Handler сообщить Payment Handler, что товар отправлен. Такое сообщение могло стать предварительным условием списания с карты. Предварительное условие не является командой. Оно доказывает лишь утверждение известного участника в пределах аутентифицированного сообщения.

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

Соседние документы помогают провести слои. RFC 2801 определил транзакции IOTP v1, роли, идентификаторы и идемпотентную обработку. Защита от повторов не даёт полномочий новой последовательности. В RFC 2802 manifest задавал состав подписанного материала. Корректная подпись аутентифицирует выбранное содержимое, но не создаёт отсутствующего согласия.

RFC 2935 переносил IOTP поверх HTTP, а RFC 3106 унифицировал имена полей электронной торговли. Доставка байтов и общий словарь не определяют деловую власть сообщения. RFC 3275 дал правила XML Signature, RFC 2246 защищал канал TLS. Сам RFC 3354 отмечал отсутствие собственной конфиденциальности IOTP: нужен TLS или IPsec, тогда как защита платежа зависит от выбранной платёжной системы.

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

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

RFC 3538 добавил SET-контекст к IOTP v1. RFC 3867 позже описал интерфейс между ядром приложения IOTP и платёжными модулями. Этот шов подчёркивал, что координация и исполнение сохраняют разные состояния, ошибки и квитанции. Ни один документ не доказывает, что требования v2 стали развёрнутым протоколом.

Историческая ценность RFC 3354 — в отказе смешивать гибкость с властью. Последовательность была планом, согласие на будущие покупки — ограниченной выдачей прав, сообщение об отправке — свидетельством события, подпись — аутентификацией выбранного материала, TLS — защитой канала. Платёжная система отдельно авторизовала, исполняла и рассчитывала, а Customer Care затем решала вопрос о возмещении.

Та же проблема возникает сейчас, когда логистический статус освобождает средства или расписание подписки начинает дебет. Чем легче компоновать процесс, тем важнее предъявлять полномочия в необратимой точке. Протокол волен предложить путь; деньги не должны пройти по нему без собственного доказательства.

Sources