ГОСТ Р ИСО/МЭК 40230-2014 Информационные технологии. Механизм оптимизации передачи сообщения W3C SOAP

ГОСТ Р ИСО/МЭК 40230-2014

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

МЕХАНИЗМ ОПТИМИЗАЦИИ ПЕРЕДАЧИ СООБЩЕНИЯ W3C SOAP

Information technologies. W3C SOAP message transmission optimization mechanism

ОКС 35.080

Дата введения 2015-06-01

Предисловие

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО "ИАВЦ") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 11 июня 2014 г. N 554-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 40230:2011* "Информационные технологии. Механизм оптимизации передачи сообщения W3C SOAP" (ISO/IEC 40230:2011 "Information technology - W3C SOAP message transmission optimization mechanism", IDT)
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Январь 2019 г.


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

Этот документ был разработан рабочей группой (WG) протокола XML как часть деятельности по Веб-службам W3C. Английская версия данной спецификации является единственной официальной нормативной версией. Переводы этого документа можно найти по адресу:

hhtp://www.w3/org/2003/03/Translations/by Technology?technology=soap 12-mtom.

Об ошибках в этом документе, пожалуйста, сообщайте по адресу: xmlp-comments@w3/org (архив). Список опечаток для данной редакции можно найти по адресу: http://www/w3/org/2005/01/soap12-mtom-errata.

Основой для этого документа является предложенная рекомендация механизма оптимизации передачи сообщения SOAP от 16 ноября 2004. Отзывы, полученные в процессе обсуждения, не вызвали каких-либо изменений документа. Свидетельство функциональной совместимости, по крайней мере, двух реализаций настоящей спецификации приводится в сводке реализации. Различия двух версий описаны в протоколе различий.

Этот документ соответствует Текущей патентной практике СРР от 24 января 2002 с учетом исправлений процедуры перехода патентной политики W3C. Если кто-либо обладает действительным знанием о патенте, который удовлетворяет существенным требованиям, то он должен раскрыть эту информацию в соответствии с разделом 6 патентной политики W3C. Список патентов, имеющих отношение к настоящей спецификации, можно найти на странице раскрытия патентов рабочей группы.

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

В настоящем стандарте описываются абстрактная функция оптимизации формата транспортного уровня и/или уровня приложений сообщений SOAP и ее конкретная реализация. Конкретная реализация основывается на формате передачи сообщений SOAP, опубликованном по адресу: [Оптимизированная двоичная упаковка XML].

Раздел 4 этого стандарта описывает абстрактную функцию для оптимизации формата сообщений SOAP для передачи уровня представления или транспортного уровня и/или уровня приложений [SOAP версии 1.2 Часть 1: Основы обмена сообщениями], которая осуществляет выборочное кодирование частей сообщения и которая в то же время предоставляет приложению SOAP инфонабор XML.

Абстрактная функция оптимизации передачи SOAP - это соглашение между двумя последовательными узлами SOAP на пути следования сообщения SOAP; функция не определяет обязательные соглашения для оптимизации передачи SOAP через промежуточные узлы. В действительности функция обеспечивает дополнительные средства, с помощью которых реализации привязки МОГУТ способствовать повышению эффективности сквозной передачи оптимизированных данных, содержащихся в заголовках и передаваемых посредником (см. пункт 4.3.4). Для реализации многоэтапной (multi-hop) функции оптимизации на основе представленных в настоящем стандарте механизмов возможна разработка дополнительных спецификаций.

В разделе 5 описывается оптимизированная сериализация MIME Multipart/Related сообщений SOAP для реализации абстрактной функции оптимизации передачи SOAP независимо от привязки. Эта реализация основывается на формате рекомендации W3C [Оптимизированная двоичная упаковка XML].

Раздел 6 использует приведенную в предыдущем разделе оптимизированную сериализацию MIME Multipart/Related сообщений SOAP для описания реализации абстрактной функции оптимизации передачи для привязки SOAP 1.2 к HTTP (см. ИСО/МЭК 40220 "Информационные технологии - SOAP версии 1.2. Часть 2: Дополнения (Вторая редакция) пункт 7).

2 Связь с другими спецификациями

Описанная в разделе 6 функция оптимизации передачи SOAP HTTP, которая является реализацией абстрактной функции оптимизации передачи SOAP для привязки SOAP 1.2 к HTTP, предназначена для того, чтобы улучшить привязку SOAP к HTTP, описанную в ИСО/МЭК 40220:2011 Information technology - W3C SOAP Version 1.2 Part 2: Adjuncts (Second Edition) (SOAP. Версия 1.2. Часть 2: Дополнения (Вторая редакция); ИСО/МЭК 40210:2011 Information technology - W3C SOAP Version 1.2. Part 1: Messaging Framework (Second Edition) [Информационные технологии - W3C SOAP. Версия 1.2. Часть 1. Основы обмена сообщениями (Вторая редакция)].

Этот документ так же, как и рекомендации W3C XML-binary Optimized Packaging (Оптимизированная двоичная упаковка XML) и SOAP Representation Header (Заголовок представления SOAP), был разработан с учетом требований, изложенных в документе W3C [W3C.soap-attachment-req].

3 Обозначения и сокращения

Ключевые слова "ДОЛЖЕН" (MUST), "HE ДОЛЖЕН" (MUST NOT), "ТРЕБУЕМЫЙ" (REQUIRED), "БУДЕТ" (SHALL), "HE БУДЕТ" (SHALL NOT), "СЛЕДУЕТ" (SHOULD), "HE СЛЕДУЕТ" (SHOULD NOT), "РЕКОМЕНДУЕМЫЙ" (RECOMMENDED), "МОЖЕТ" (MAY) и "ДОПОЛНИТЕЛЬНЫЙ" (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC2119 [RFC 2119].

В данной спецификации используется множество префиксов пространства имен - они перечислены в таблице 1. Необходимо отметить, что выбор любого префикса пространства имен произволен и не является семантически существенным (см. рекомендацию W3C [Информационный набор XML (XML InfoSet)]).


Таблица 1 - Префиксы и пространства имен, используемые в данной спецификации

4 Абстрактная функция оптимизации передачи SOAP

4.1 Общая информация

Абстрактная функция оптимизации передачи SOAP позволяет привязке SOAP оптимизировать формат транспортного уровня и/или уровня приложений сообщений SOAP путем выборочного кодирования частей сообщения и, в то же время, предоставляет приложению SOAP инфонабор XML. Оптимизация возможна только для содержимого элементов, представленных в каноническом лексическом представлении данных типа хs:bаse64Вinary (см. рекомендацию W3C [Часть 2: Типы данных XML - схемы Вторая редакция] 3.2.16 base64Binary.

Примечание - В связи с тем, что между такими каноническими представлениями и значениями в пространстве значений xs:base64Binary имеется взаимно-однозначное соответствие, в реализациях МТОМ оптимизация, как правило, достигается посредством передачи компактного представления значений вместо менее компактной символьной последовательности. При этом получатель может при необходимости восстановить символьную форму.


В соответствии с требованием к привязке SOAP передавать инфоабор конверта без каких-либо изменений, реализации этой функции НЕ ДОЛЖНЫ заменять канонические представления неканоническими или вносить какие-либо другие изменения в содержимое оптимизируемого элемента.

4.2 Имя абстрактной функции оптимизации передачи SOAP

Данная абстрактная функция оптимизации передачи SOAP идентифицируется посредством следующего URI:

- http://www.w3.org/2004/08/soap/features/abstract-optimization.

4.3 Обработка абстрактной функции оптимизации передачи SOAP

4.3.1 Отправка сообщения

Если при отправке сообщения SOAP абстрактная функция оптимизации передачи используется в сочетании с шаблоном обмена сообщениями SOAP "Запрос-Ответ" (см. ИСО/МЭК 40220, пункт 6.2) или шаблоном обмена сообщениями SOAP "Ответ" (см. ИСО/МЭК 40220, пункт 6.3), то свойство http://www.w3.org/2003/05/soap/mep/OutboundMessage является инфонабором предназначенного для отправки сообщения SOAP. Аналогичные правила должны применяться и для других шаблонов МЕР.

Назначением абстрактной функции оптимизации передачи SOAP является оптимизация передачи данных в кодировке base64. Для того, чтобы быть оптимизированными, символы, представляющие дочерние элементы [children] информационного объекта-элемента, ДОЛЖНЫ быть в канонической форме xs:base64Binary (см. рекомендацию W3C [XML - схемы. Часть 2: Типы данных. Вторая редакция], пункт 3.2.16), и не ДОЛЖНЫ содержать предшествующих, внутренних или последующих пробельных символов для отличного от пробелов содержания.

Примечание - Средства идентификации информационных объектов, которые содержат данные в кодировке base64 в канонической лексической форме, зависят от конкретной реализации. Некоторые реализации могут идентифицировать такие информационные объекты по конструкции (например, потому что определенные API могут создать только канонические формы); другие могут проверить символы до отправки, третьи могут опираться на информацию в описании, такую как наличие и/или значение аннотации схемы xmlmime:expectedMediaType (см. рекомендацию W3C [Присвоение типа медиа двоичным данным в ХМL]), при условии, что схема доступна. Из-за необходимости точно сохранить символы в переданном инфо-наборе, не канонические представления НЕ ДОЛЖНЫ быть оптимизированы реализациями данной функции.

4.3.2 Получение сообщения

При получении сообщения SOAP, оптимизированного путем использования реализации абстрактной функции оптимизации передачи SOAP узлом SOAP, который не поддерживает либо данную реализацию, либо абстрактную функцию оптимизации передачи SOAP вообще, узел ДОЛЖЕН генерировать отказ.

Приняв оптимизированное сообщение SOAP принимающий узел ДОЛЖЕН восстановить инфонабор конверта из оптимизированного сообщения SOAP. Затем узел-получатель ДОЛЖЕН выполнить обработку SOAP восстановленного инфонабора (см. ИСО/МЭК 40210 раздел 2). Полученный инфонабор во всех случаях ДОЛЖЕН точно совпадать с тем, который был передан отправителем.

Конкретная реализация может либо восстановить только необходимые для обработки части, либо представить информацию из сообщения в форме, удобной для эффективной обработки. Например, значение, отправленное в оптимизированной форме (допустим в двоичной), МОЖЕТ быть представлено в такой форме, а также в кодированном символьном формате base64.

Если данная функция используется в сочетании с шаблоном обмена сообщениями SOAP "Запрос-Ответ" (см. ИСО/МЭК 40220, пункт 6.2) или с шаблоном обмена сообщениями SOAP "Ответ" (см. ИСО/МЭК 40220, пункт 6.3), то инфонабор, содержащийся в свойстве http://www.w3.org/2003/05/soap/mep/lnboundMessage, является инфонабором восстановленного конверта SOAP. Аналогичные правила применяются для других шаблонов МЕР соответственно.

4.3.3 Посредники

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

Однако посредник, реализующий абстрактную функцию оптимизации передачи SOAP, ДОЛЖЕН все же следовать правилам, связанным с использованием реализации абстрактной функции оптимизации передачи при получении сообщения (см. пункт 4.3.2), и связанным с использованием реализации абстрактной функции оптимизации передачи SOAP при отправлении сообщения (см. пункт 4.3.1). В частности, посредник ДОЛЖЕН выполнять правила передачи сообщения SOAP (см. ИСО/МЭК 40210 пункт 2.7).

4.3.4 Оптимизация привязки в посредниках

Как описано в пункте 2.7 ИСО/МЭК 40210, от посредника SOAP может требоваться, чтобы он передавал нетронутыми определенные заголовки или повторно вставлял заголовки, идентичные полученным и удаленным в процессе обработки. Кроме того, многие посредники передадут неизмененным содержимое тела SOAP. Во всех этих случаях части переданного сообщения имеют содержимое, идентичное содержимому соответствующих частей входящего сообщения.

Абстрактная функция оптимизации передачи SOAP не требует какого-либо определенного соответствия между оптимизацией входящего сообщения и исходящим сообщением даже в том случае, если оптимизированные части входящего сообщения переданы нетронутыми или повторно вставлены в том же виде в инфонабор конверта. Тем не менее, реализация привязки, используемой при получении, и привязки, используемой для передачи пересылаемого сообщения, МОГУТ взаимодействовать для обеспечения эффективного транзита. Например, если входящая и исходящая привязки используют одно и то же представление для оптимизированного двоичного содержимого, то реализации МОГУТ действовать взаимосвязано с тем, чтобы передать оптимизированную форму непосредственно из входящей привязки в исходящую. Выбор того, осуществлять такое взаимодействие или нет, как и выбор используемых для этого средств, определяется спецификацией (спецификациями) привязки и/или реализацией привязки.

Примечание - Следствием этой архитектуры является факт, что нет никаких инвариантных правил определения степени того, насколько оптимизация сохранятся по мере прохождения сообщения через посредников. Отдельная исходящая привязка может быть неспособна к какой-либо оптимизации и поэтому в любом случае передаст неоптимизированные формы. Другие привязки могут быть способны оптимизировать, но могут или не могут выбрать оптимизацию тех же самых частей (если таковые имеются), которые были оптимизированы во входящем сообщении. Такая привязка, возможно, следуя логике, представленной в модулях SOAP, или как следствие соглашений, реализованных в привязке, способна оптимизировать те части входящего сообщения, которые не были оптимизированы, или которые были оптимизированы с использованием других методов.

5 Оптимизированная сериализация MIME Multipart/Related сообщений SOAP

5.1 Общая информация

Оптимизированная сериализация MIME Multipart/Related расширяет абстрактную функцию оптимизации передачи SOAP, определяя части реализации этой функции, используя в качестве основы формат [Оптимизированной двоичной упаковки XML]. Хотя эта спецификация не определяет полную реализацию функции, она обеспечивает поддержку для разработки полной реализации абстрактной функции оптимизации передачи SOAP. В частности, эта спецификация не определяет использования какого-либо транспорта для сообщения SOAP. Полная реализация на основе этой спецификации описана в пункте 6.2.

Оптимизированная сериализация MIME Multipart/Related обеспечивает основу для реализации абстрактной функции оптимизации передачи, определяя, как сериализировать конверт SOAP оптимизированным способом, используя при этом формат [Оптимизированной двоичной упаковки XML] и упаковку MIME Multipart/Related ([RFC 2387]).

Именно инфонабор конверта SOAP передается как пакет ХОР MIME Multipart/Related (см. рекомендацию W3C [Оптимизированная двоичная упаковка XML] и пункт 4.1 этого документа). Для сохранения инфонабора ХОР, созданного из инфонабора конверта SOAP, в пакете ХОР MIME Multipart/Related можно использовать любую версию уровня рекомендации W3C XML. Однако, необходимо отметить, что инфонабор конверта SOAP ДОЛЖЕН быть сериализован как ХМL 1.0.

5.2 Сериализация сообщения SOAP

При отправлении сообщения SOAP с использованием сериализации MIME Multipart/Related инфонабор конверта SOAP сериализуется в соответствии с рекомендацией W3C [Оптимизированной двоичной упаковки XML] и пункта 3.2 этой рекомендации.

В частности:

- тип содержимого внешнего пакета ДОЛЖЕН быть Multipart/Related;

- параметр type заголовка content-type внешнего пакета ДОЛЖЕН иметь значение application/xop+xml (см. рекомендацию W3C [Оптимизированная двоичная упаковка XML] и пункт 4.1 этой рекомендации);

- параметр startinfo заголовка content-type внешнего пакета ДОЛЖЕН определять тип содержимого для корневой части как application/soap+xml.

- content-type корневой части ДОЛЖЕН быть application/xop+xml (см. рекомендацию W3C [Оптимизированная двоичная упаковка XML] и пункт этой рекомендации).

- параметр type заголовка content-type корневой части ДОЛЖЕН определять тип содержимого как application/soap+xml.

Результатом является ХОР-пакет MIME Multipart/Related (см. рекомендацию W3C [Оптимизированная двоичная упаковка XML]: одна часть тела которого - корень содержит представление XML модифицированного конверта SOAP, а другая, дополнительная часть, содержит двоичное представление каждого элемента, который был оптимизирован.

5.3 Десериализация сообщения SOAP

При получении сообщения SOAP с использованием данной оптимизированной сериализации MIME Multipart/Related инфонабор конверта SOAP восстанавливается из пакета ХОР MIME Multipart/Related путем выполнения действий, определенных в рекомендации W3C [Оптимизированная двоичная упаковка XML] и пункт 3.2 этой рекомендации.

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

6 Функция оптимизации передачи SOAP HTTP

6.1 Общая информация

Функция оптимизации передачи SOAP HTTP является реализацией абстрактной функции оптимизации передачи SOAP на уровне привязки для привязки к HTTP. Данная функция оптимизации передачи SOAP HTTP основывается на оптимизированной сериализации MIME Multipart/Related, описанной в разделе 5 настоящего документа.

Такая функция оптимизации передачи SOAP HTTP опирается на текущую привязку к HTTP (см. ИСО/МЭК 40220 и раздел 7 данного документа), улучшая ее поддержкой абстрактной функции оптимизации передачи SOAP. Во всех аспектах, не упомянутых в данном разделе, правила привязки к HTTP остаются без изменений.

6.2 HTTP имя функции оптимизации передачи SOAP

6.2 HTTP-имя функции оптимизации передачи SOAP

Данная функция оптимизации передачи SOAP HTTP идентифицирована следующим URI:

http://www.w3.org/2004/08/soap/features/http-optimization.

6.3 Реализация

Для реализации абстрактной функции оптимизации передачи SOAP функция оптимизации передачи SOAP HTTP использует оптимизированную сериализацию MIME Multipart/Related (см. пункт 5). На передающей стороне это функция сериализует сообщение SOAP, как описано в пункте 5.2, и помещает заголовки полученного в результате сериализации пакета ХОР MIME Multipart/Related в виде HTTP-заголовков, а оставшиеся части пакета - в тело HTTP. На стороне получателя данная функция извлекает заголовки MIME из HTTP-заголовков и оставшуюся часть пакета ХОР MIME Multipart/Related из тела HTTP и десериализует, как описано в пункте 5.3.

6.3.1 Отправка сообщения SOAP

При отправке сообщения SOAP функция оптимизации передачи SOAP HTTP изменяет работу привязки (см. раздел 7 ИСО/МЭК 40220). В данном разделе описываются отклонения от пункта 7.5.1 ИСО/МЭК 40220, которые являются результатом использования функции оптимизации передачи SOAP HTTP. Ниже приводятся лишь те аспекты, которые имеют отличия от обычной работы привязки к HTTP. Все не упомянутые аспекты ее работы остаются неизменными.

6.3.1.1 Бизнес-контекст, связанный со средой приложения

В состоянии "Init" запрос HTTP сформирован, и инициируется передача запроса. При использовании функции оптимизации передачи SOAP HTTP оформление запроса, как это показано в (Поля запроса HTTP), отличается от оформления, описанного в пункте 7.5.1.1 ИСО/МЭК 40220.


Таблица 2 - Поля запроса HTTP

Пакет ХОР создается, как описано в разделе 5, со следующими ограничениями:

- инфонабор ХОР ДОЛЖЕН быть сериализирован, как application/xop+xml в корневой части пакета, в соответствии с разделом 5 рекомендации W3C [Оптимизированная двоичная упаковка XML];

- каждый оптимизированный узел ДОЛЖЕН генерировать в получающемся пакете только одну извлеченную двоичную часть, то есть на извлекаемые двоичные части НЕ ДОЛЖНО быть нескольких ссылок хор:Include в части сообщения SOAP;

- каждая часть MIME, на которую имеется ссылка xop:lnclude, ДОЛЖНА в заголовке иметь поле Content-Transfer-Encoding.

Следует отметить, что это не исключает включения в пакет MIME Multipart/Related дополнительных частей, на которые нет ссылок элемента xop:lnclude. Подобные дополнительные части не являются частью инфонабора сообщения SOAP и не включены в модель обработки SOAP.

При реализации такой привязки ДОЛЖНО выполняться ограничение, которое заключается в том, что ХОР не должен использоваться с инфонаборами, которые содержат информационные объекты - элементы с именем xop:lnclude (см. [Оптимизированная двоичная упаковка XML] 3. Логическая структура инфо-наборов ХОР). В каждом случае, если необходимо отправить конверт SOAP, содержащий такой информационный объект-элемент, привязка ДОЛЖНА выполнить одно из следующих действий:

- вернуться к использованию типа медиа application/soap+xml или любого другого подходящего типа медиа, то есть отправить конверт SOAP, не используя функцию оптимизации передачи SOAP HTTP;

- создать отказ SOAP, специфичный для привязки.

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

6.3.2 Получение сообщения SOAP

Получая сообщение SOAP, реализация привязки SOAP к HTTP (см. ИСО/МЭК 40220) определит, использовалась ли функция оптимизации передачи SOAP HTTP путем проверки наличия типа медиа application/xop+xml (см. рекомендацию W3C [Оптимизированная двоичная упаковка XML], пункт 5.1). Если тип медиа сообщения HTTP является multipart/related и тип медиа корневой части пакета MIME multipart/related является application/xop+xml, а параметр start-info указывает на тип содержимого application/soap+xml, то это означает, что, полученное сообщение SOAP было передано с использованием функции оптимизации передачи SOAP HTTP и ДОЛЖНО быть обработано соответствующим образом.

При приеме сообщения SOAP функция оптимизации передачи SOAP HTTP изменяет работу привязки SOAP к HTTP (см. раздел 7 ИСО/МЭК 40220). Отклонения поведения отвечающего узла SOAP (см. пункт 7.5.1 ИСО/МЭК 40220), которые являются результатом использования функции оптимизации передачи SOAP HTTP, заключаются в следующем:

- при создании абстракции сообщения запроса, доступного как http://www.w3.org/2003/05/soap/mep/lnboundMessage, привязка к HTTP ДОЛЖНА восстановить инфонабор конверта SOAP, как это описано в пункте 5.3.

Все другие аспекты работы привязки к HTTP остаются неизменными.

Библиография

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2019