"ГОСТ Р ИСО/МЭК 40230-2014. Национальный стандарт Российской Федерации. Информационные технологии. Механизм оптимизации передачи сообщения W3C SOAP"
(утв. и введен в действие Приказом Росстандарта от 11.06.2014 N 554-ст)

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

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

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

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

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

/template/go.php?url=https://www.w3/org/2003/03/Translations/by Technology?technology=soap 12-mtom.

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

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

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

В настоящем документе описываются абстрактная функция оптимизации формата транспортного уровня и/или уровня приложений сообщений 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).

Описанная в разделе 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].

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

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

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

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

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

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

- /template/go.php?url=https://www.w3.org/2004/08/soap/features/abstract-optimization.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При отправлении сообщения 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".

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

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

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

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

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

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

/template/go.php?url=https://www.w3.org/2004/08/soap/features/http-optimization.

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

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

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

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

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

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

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

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

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

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

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

Следует обратить внимание на то, что такие конверты 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, заключаются в следующем:

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

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

[1] ИСО/МЭК 40210:2011 Information technology - W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) (Информационные технологии - W3C SOAP - Версия 1.2 Часть 1: Основы обмена сообщениями (Вторая редакция)) <1>

--------------------------------

<1> В разработке.

[2] ИСО/МЭК 40220:2011 Information technology - W3C SOAP Version 1.2 Part 2: Adjuncts (Second Edition) (SOAP версии 1.2 Часть 2: Дополнения (Вторая редакция).

[3] W3C Recommendation XML-binary Optimized Packaging (Оптимизированная двоичная упаковка XML).

[4] W3C Working Group Note SOAP 1.2 Attachment Feature (SOAP 1.2 Функция вложений).

[5] W3C Working Draft SOAP Optimized Serialization Use Cases and Requirements (Варианты использования и требования оптимизированной сериализации SOAP).

[6] W3C Recommendation Resource Representation SOAP Header Block (Представление ресурсов блока заголовка SOAP).

[7] W3C Working Draft Assigning Media Types to Binary Data in XML (Присвоение типов медиа двоичным данным в XML).

[8] W3C Recommendation Extensible Markup Language (XML) 1.0 (Third Edition) (Расширяемый язык разметки (XML) 1.0 (Третья редакция)).

[9] Namespaces in XML World Wide Web Consortium 14-January-1999 (Пространства имен в XML).

[10] W3C Recommendation XML Information Set (Second Edition) Набор информации XML (вторая редакция), Редакторы: Ричард Тобин и Джон Коуон, Консорциум World Wide Web, 4 февраля 2004.

[11] W3C Recommendation XML Schema Part 1: Structures Second Edition (XML-схемы - Часть 1: Структуры. Вторая редакция), Редакторы: Дэвид Бич, Мюррей Мэлони, Генри С. Томпсон, и Ноа Мендельсон, Консорциум World Wide Web, 28 октября 2004.

[12] W3C Recommendation XML Schema Part 2: Datatypes Second Edition (XML-схемы - Часть 2: Типы данных Вторая редакция). Редакторы: Ашок Мэлхотра и Пол В. Бирон, Консорциум World Wide Web, 28 октября 2004.

[13] RFC 2119 Key words for use in RFCs to Indicate Requirement Levels Ключевые слова, используемые в RFCs, чтобы указать на уровни требования. Редактор: С. Брэднер, IETF, март 1997/

[14] RFC 2387 The MIME Multipart/Related Content-type (MIME-Тип контента Multipart/Related). Редактор: Э. Левинсон, IETF, август 1998.

[15] RFC 2396 Uniform Resource Identifiers (URI): Общий синтаксис. Редакторы: Т. Бернерс-Ли, Р. Филдинг и Л. Мэзинтер, IETF, август 1998.

[16] RFC 3023 XML Media Types (XML - типы медиа). Редакторы: М. Мурэта, S. Св. Лорент и Д. Кон, IETF, январь 2001.

[17] PASWA Proposed Infoset Addendum to SOAP Messages with Attachments (Предложенное приложение для инфо-набора сообщений SOAP с вложениями), AT&T, Системы BEA, Canon, Microsoft Corporation, SAP AG и Tibco Software, апрель 2003.