Открыть сервис
Главная → Блог → RFC 6017

RFC 6017

RFC 6017 — это информационный документ (Request for Comments) серии RFC, опубликованный в декабре 2010 года под названием «Electronic Data Interchange — Internet Integration (EDI-INT) Functional Specifications for the Transport of Electronic Data Interchange (EDI) Data over the Internet». Документ был разработан рабочей группой IETF EDI-INT (Electronic Data Interchange — Internet Integration) и определяет функциональные спецификации для безопасной и надёжной передачи данных электронного обмена данными (EDI) через Интернет с использованием протокола HTTP и криптографических средств защиты.

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

В конце 1990-х — начале 2000-х годов электронный обмен данными (EDI) стал стандартом де-факто для автоматизации бизнес-транзакций между организациями (заказы, счета, отгрузочные документы). Однако традиционные сети EDI (например, Value Added Networks, VAN) были дорогими, закрытыми и не обеспечивали прямого взаимодействия через Интернет. Для решения этой проблемы IETF сформировала рабочую группу EDI-INT, которая выпустила серию RFC, начиная с RFC 1767 (1995 год) и RFC 3335 (2002 год). RFC 6017 стал эволюционным развитием этих спецификаций, уточняя требования к транспортировке EDI-данных через HTTP.

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

Основные положения RFC 6017

1. Область применения

RFC 6017 определяет функциональные требования для передачи EDI-данных (в форматах X12, EDIFACT, XML и других) через Интернет с использованием протокола HTTP (версии 1.1). Документ не описывает конкретные реализации, а задаёт обязательные и опциональные механизмы, которые должны поддерживать системы, претендующие на соответствие спецификации.

2. Требования к безопасности

Ключевым элементом является обеспечение конфиденциальности, целостности и аутентификации передаваемых данных. RFC 6017 предписывает использование:

  • S/MIME (Secure/Multipurpose Internet Mail Extensions) — для шифрования и цифровой подписи EDI-сообщений. Сообщение должно быть упаковано в MIME-контейнер с применением алгоритмов шифрования (например, AES) и подписи (RSA, DSA).
  • HTTPS (HTTP over TLS) — для защиты канала передачи. Рекомендуется использование TLS версии 1.0 или выше (на момент публикации).
  • Цифровые сертификаты X.509 — для аутентификации отправителя и получателя.

3. Протокол передачи

Документ детализирует использование HTTP-методов:

  • POST — для отправки EDI-сообщения от отправителя к получателю.
  • GET — для запроса статуса обработки или получения подтверждения.
  • PUT — для обновления или повторной отправки.

Важным нововведением стало требование поддержки HTTP-заголовка Content-Transfer-Encoding для указания кодировки (например, base64 или binary), а также использование MIME-типов, таких как application/edi-x12 или application/edifact.

4. Подтверждения (Acknowledgments)

RFC 6017 вводит обязательное требование к подтверждению получения сообщения. Для этого используется:

  • MDN (Message Disposition Notification) — стандарт RFC 3798, адаптированный для EDI. MDN содержит информацию о статусе обработки (успешно/ошибка) и может быть подписан цифровой подписью.
  • HTTP-статус-коды — например, 200 OK для успешной доставки, 202 Accepted для асинхронной обработки.

5. Обработка ошибок

Спецификация определяет сценарии обработки ошибок:

  • Ошибки аутентификации (недействительный сертификат).
  • Ошибки целостности (несовпадение хэша).
  • Ошибки формата (некорректный EDI-файл).

В таких случаях отправитель должен получить MDN с кодом ошибки.

Классификация и виды

RFC 6017 относится к категории функциональных спецификаций, а не протокольных стандартов. Его можно классифицировать по следующим признакам:

  • По типу документа: информационный (Informational) — не является стандартом, но описывает лучшие практики.
  • По области применения: транспортный уровень для EDI.
  • По зависимости от других RFC: базируется на RFC 1767, RFC 3335, RFC 3798, RFC 3851 (S/MIME), RFC 5246 (TLS).

Применение и значение

1. Практическое использование

RFC 6017 широко применяется в корпоративных системах B2B (business-to-business), особенно в отраслях с высокими требованиями к безопасности:

  • Розничная торговля (заказы, инвойсы).
  • Логистика (отгрузочные документы).
  • Финансовый сектор (платёжные поручения).
  • Здравоохранение (медицинские счета, рецепты).

2. Преимущества перед VAN

  • Снижение затрат на передачу данных (нет платы за трафик VAN).
  • Прямое взаимодействие между партнёрами без посредников.
  • Возможность использования существующей интернет-инфраструктуры.

3. Ограничения

  • Требует настройки сертификатов и криптографии.
  • Не решает проблему совместимости различных EDI-стандартов (X12 vs EDIFACT).
  • Не поддерживает потоковую передачу больших файлов (рекомендуется разбиение на части).

Критика и развитие

Некоторые эксперты отмечали, что RFC 6017 недостаточно детализирует вопросы:

  • Маршрутизации — не описывает, как выбирать получателя при нескольких адресатах.
  • Повторной отправки — не определяет стратегии retry при временных ошибках.
  • Сжатия — не требует поддержки сжатия данных (хотя это может быть реализовано на уровне HTTP).

В последующие годы IETF выпустила обновления, такие как RFC 6362 (2011 год), который уточняет использование MDN, и RFC 8487 (2018 год), который добавляет поддержку асинхронной обработки.

Интересные факты

  • RFC 6017 был одним из первых документов, который явно предписывал использование HTTPS для EDI, что стало стандартом де-факто для B2B-интеграции.
  • Документ активно цитируется в коммерческих решениях (например, IBM Sterling B2B Integrator, SAP PI/PO).
  • Несмотря на возраст, RFC 6017 остаётся актуальным для систем, где требуется высокая надёжность и аудит передаваемых данных.

Источники

  1. RFC 6017 — «Electronic Data Interchange — Internet Integration (EDI-INT) Functional Specifications for the Transport of Electronic Data Interchange (EDI) Data over the Internet» (декабрь 2010).
  2. RFC 3335 — «MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet» (сентябрь 2002).
  3. RFC 1767 — «MIME Encapsulation of EDI Objects» (март 1995).
  4. RFC 3798 — «Message Disposition Notification» (май 2004).
  5. RFC 3851 — «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification» (июль 2004).
  6. RFC 5246 — «The Transport Layer Security (TLS) Protocol Version 1.2» (август 2008).

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

На главную BFOmetr →

Похожие материалы