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).