Кратко

  • RFC 1865 предлагал заменить коммуникационные компоненты между существующими EDI-системами интернет-почтой. Прямая гарантированная SMTP-доставка завершалась в системе партнёра, а двустороннее соглашение сохранялось.
  • RFC 1767 переносил X12, EDIFACT и EDI-consent в MIME, не меняя их синтаксис и смысл и не добавляя защиту сам по себе.
  • RFC 3335 и RFC 4130 связали Message-ID, MIC, подпись и MDN. Подписанная квитанция могла сообщать об ошибке, а действительность сделки по-прежнему решали партнёры.

Сервер получил байты, компания ещё не дала согласия

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

RFC 1865 вышел в январе 1996 года как Informational FAQ для EDI-сообщества, ещё осваивавшего Интернет. Документ сохранял деловые программы и EDI-переводчики. Интернет-модули занимали место коммуникационных компонентов.

При выделенном SMTP-соединении информация, согласно FAQ, поступала прямо в систему торгового партнёра и доставка была гарантирована. В режиме хранения и пересылки целостность зависела от посредников. Это содержательное различие между путями передачи. Оно не подтверждает обработку деловой системой и не выражает волю организации.

Стандартизованный объект не равнялся всему электронному бизнесу

RFC 1865 определял EDI как обмен стандартизованной деловой информацией между приложениями. Электронная коммерция была шире: туда входили общение людей, перевод денег и общие информационные ресурсы. Заказ в стандартном формате оставался входом в процесс, а не его итогом.

Двусторонние соглашения торговых партнёров также не исчезли. Интернет-адрес мог заменить имя в закрытом почтовом ящике, но идентичность, сроки, повторная отправка, последствия и разрешение споров требовали договорённости. RFC 1767 разрешал EDI-consent только при явном двустороннем соглашении.

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

MIME отвечал за оболочку

RFC 1767 установил MIME-типы для EDI-X12, EDIFACT и EDI-consent. На отправляющей стороне деловая программа передавала объект EDI-переводчику, затем MIME-обработчику, почтовой подаче и SMTP. Получатель снимал оболочку, переводил EDI и лишь потом запускал деловую обработку.

RFC прямо не менял синтаксис и семантику EDI и сам не обеспечивал безопасность. MIME помогал назвать и перенести вид объекта. Он не доказывал правильность содержимого, происхождение, неизменность, полномочие или принятие.

Именно после успешной совместимости появляется соблазн назвать весь процесс завершённым. Схема RFC оставляет видимыми задачи по обе стороны транспортного участка.

Подписанная квитанция могла честно зафиксировать отказ

RFC 3335 добавил подпись, шифрование и подписанный MDN. Исходный Message-ID связывал ответ с отправкой, MIC представлял полученное содержимое, подпись относила ответ к получателю в пределах правил ключа и сертификата. Отправитель затем проверял квитанцию.

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

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

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

Показанное не обязательно прочитано

RFC 3798 позволял получателю проигнорировать запрос MDN и предупреждал: disposition displayed не гарантирует, что содержание прочитано или понято.

Автоматизации нужна та же осторожность. SMTP-ответ не равен обработке EDI. MDN не равен подтверждению приложения. Подпись не равна коммерческому мандату. Функциональное подтверждение не всегда равно договорному принятию.

Надёжная история хранит точный исходный объект, приём или доставку почты, связанный MDN и MIC, результат EDI-переводчика, подтверждение приложения и решение уполномоченного коммерческого процесса. Названия и число артефактов могут различаться; полномочия одного уровня не должны незаметно переходить к другому.

Распределённая перевозка и двусторонняя ответственность

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

Партнёры всё ещё выбирали адреса, сертификаты, сроки квитанций, правила дублей, хранение и способы спора. Децентрализовался путь, но не ответственность.

Официальные источники не подтверждают конкретное внедрение, принятый заказ, оплату или судебное решение. Они показывают более узкий прогресс: MIME переносил объект, подпись и MIC усиливали доказательство получения, а коммерческая власть оставалась за пределами почтовой системы.

Источники