ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

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

Функциональная совместимость веб-служб

Профиль вложений WS-1 Версия 1.0

ISO/IEC 29362:2008 Information technology - Web Services Interoperability — WS-I Attachments

Profile Version 1.0

(IDT)

Издание официальное

Москва

Стандартинформ

2014

Предисловие

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

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. № 1540-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 29362:2008 «Информационная технология. Функциональная совместимость веб-служб. Профиль вложений WS-I. Версия 1.0» (ISO/IEC 29362:2008 «Information technology - Web Services Interoperability — WS-I Attachments Profile Version 1.0»)

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8) Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты». а официальный текст изменений и поправок - в ежемесячном информационном указателе «Национальные стандарты» В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

О Стандартинформ, 2014

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

Содержание

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

2    Соответствие профилю...................................................................................................2

3    Упаковка вложения..........................................................................................................4

4    Описание вложений.........................................................................................................9

Приложение А. Ссылки на спецификации......................................................................22

Приложение В: Возможные расширения........................................................................23

Приложение С. Нормативные ссылки.............................................................................24

Приложение D: Определения терминов.........................................................................25

Приложение Е: Благодарности........................................................................................26

ГОСТ Р ИСО/МЭК 29362—2013

Введение

Настоящий международный стандарт определяет профиль вложений WS-I 1.0 (далее «Профиль»), состоящий из набора открытых спецификаций Веб-служб вместе с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости. Этот профиль дополняет основной профиль WS-I 1.1, обеспечивая поддержку передачи сообщений SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) с вложениями, соответствующими спецификации «Сообщения SOAP с вложениями».

ИСО/МЭК 29362 был подготовлен Организацией функциональной совместимости Веб-служб -Web Services Interoperability Organization (WS-I) и был принят Объединенным Техническим Комитетом СТК 1 ИСО/МЭК «Информационные технологии» в соответствии с процедурой для опубликованных технических спецификаций параллельно с его одобрением национальными органами ИСО и МЭК.

IV

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

Информационная технология Функциональная совместимость веб - служб Профиль вложений WS-1. Версия 1.0

Information technology - Web Services Interoperability — WS-l Attachments Profile Version 1 0

Дата введения — 2015—01—01

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

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

Настоящий международный стандарт определяет профиль вложений WS-I 1.0 (далее «профиль»), состоящий из набора открытых спецификаций Веб-служб вместе с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости. Этот профиль дополняет основной профиль WS-I 1.1, обеспечивая поддержку передачи сообщений SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) с вложениями, соответствующими спецификации «Сообщения SOAP с вложениями».

Сообщения SOAP с вложениями (SwA) определяют составную/связанную структуру MIME (Multipurpose Internet Mail Extensions— Многоцелевое расширение возможностей почты в сети Интернет) для упаковки вложений с сообщениями SOAP. Данный профиль дополняет основной профиль WS-I 1.1, добавляя поддержку передачи вложений на базе SwA. обеспечивающих функциональную совместимость с сообщениями SOAP.

В разделе 1 приводится описание профиля и объясняется его отношения с другими профилями.

Раздел 2 «Соответствие профилю» объясняет, что значит быть совместимым с профилем

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

1.2    Отношения с другими профилями

Этот профиль добавляет поддержку SOAP с вложениями и привязку MIME (MIME binding) и предназначен для использования в комбинации с основным профилем 1 1.

1 3 Условные ОООЗНЗЧ6НИЯ

Ключевые слова «ДОЛЖЕН» (MUST). «НЕ ДОЛЖЕН» (MUST NOT). «ТРЕБУЕМЫЙ» (REQUIRED). «БУДЕТ» (SHALL). «НЕ БУДЕТ» (SHALL NOT). «СЛЕДУЕТ» (SHOULD). «НЕ СЛЕДУЕТ» (SHOULD NOT),    «РЕКОМЕНДУЕМЫЙ»    (RECOMMENDED).    «МОЖЕТ»    (MAY)    и

«ДОПОЛНИТЕЛЬНЫЙ» (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC2119

Нормативные положения для требований профиля (те. которые влияют на соответствие, как описано в «Требованиях соответствия»), представлены следующим способом:

Rnnnn Текст положения

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

Таким образом, идентификаторы требований могут рассматриваться, как квалифицированное пространство имен, совместимое с QNames из Пространства имен в XML. Если идентификатор требования не содержит никакого явного префикса пространства имен (например. «R9999» в отличие от «bp10:R9999»), то он должен рассматриваться как принадлежащий пространству имен, определяемому соответствующим универсальным идентификатором ресурса (URI) раздела документа, в котором он присутствует. Если эти условия соблюдены, то префикс следует интерпретировать согласно фактическим отображениям пространства имен, как показано далее.

Некоторые требования используются для пояснения соответствующих спецификаций, но не накладывают дополнительных ограничений на реализацию. Для удобства такие пояснения обозначаются следующим способом: С

Отдельные требования являются результатом постоянно продолжающейся работы по стандартизации спецификаций, на которые они ссылаются Для удобства такие положения, которые

Издание официальное

могут претерпеть изменения, обозначаются как: хххх, где хххх является идентификатором спецификации (например. «WSDL20» для версии 2.0 WSDL). Необходимо отметить, что поскольку эта работа не была завершена на момент публикации данного документа, спецификация, к которой относится требование, может измениться, и данная информация приводится только для удобства разработчиков.

Возможные расширения в базовых спецификациях (см. «Область соответствия») представлены следующим образом:

Епппл Название возможного расширения - Описание.

где nnnn заменятся числом, которое уникально среди возможных расширений в профиле. Аналогично требованиям. идентификаторы расширений можно рассматривать как квалифицированные имена в пространстве имен.

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

•    soap - http://schemas xmlsoap.org/soap/envelope/»

•    xsi - http://www.w3.org/2001/XMLSchema-instance»

•    xsd - http://www.w3.org/2001/XMLSchema»

•    soapenc - http://schemas.xmlsoap.org/soap/encoding/»

•    wsdl - http://schemas.xmlsoap.org/wsdl/»

•    soapbind - http://schemas.xmlsoap.org/wsdl/soap/»

•    mime - http://schemas.xmlsoap.org/wsdl/mime/»

•    uddi - um:uddi-org:api_v2»

•    wsi - http://www.ws-i.org/schemas/conformanceClaim»

•    ref - http://ws-i.0rg/prof1les/basic/l . 1/xsd»

1.4 Идентификация профиля и управление версиями

Данный документ идентифицирован наименованием (в данном случае. «Профиль вложений») и номером версии (здесь, 1.0). В совокупности они идентифицируют конкретный экземпляр профиля

Номера версий составлены из основной и дополнительной частей в форме «основной дополнительный». Они могут использоваться, чтобы определить приоритет экземпляра профиля; больший номер версии (с учетом и основного, и дополнительного компонентов) указывает, что данный экземпляр новее, и поэтому заменяет более ранние экземпляры.

Для экземпляров профилей с одинаковыми именами (например. «Пример Профиля 1.1» и «Пример Профиля 5.0») проблемы функциональной совместимости рассматриваются в одной и той же общей области действия, хотя при некоторых разработках может потребоваться, чтобы точная область действия профиля была различна для различных экземпляров

Данная информация может также быть использована, чтобы определить, являются ли два экземпляра профиля обратно совместимыми, т.е. можно ли считать, что соответствие более раннему экземпляру профиля подразумевает соответствие более позднему. Экземпляры профиля с одним тем же именем и номером основной версии (например, «Пример Профиля 1.0» и «Пример Профиля 1.1»), МОГУТ считаться совместимым. Совместимость в другом направлении не подразумевается, т.е. нельзя предполагать, что соответствие более позднему экземпляру профиля подразумевает соответствие более раннему.

2 Соответствие профилю

Соответствие профилю определено точным выполнением набора требований, определенных в рамках области применения профиля для определенной цели. Настоящий раздел обьясняет эти термины и описывает, как определяется и используется соответствие.

2.1 Требования соответствия

Требования устанавливают критерии соответствия профилю. Они обычно ссылаются на существующую спецификацию и добавляют усовершенствования, усиления, интерпретации и разъяснения к ней. чтобы улучшить функциональную совместимость. Все требования в профиле считаются нормативными. Требования в спецификациях, на которые профиль ссылается в области применения (см. «Область соответствия») также должны рассматриваться как нормативные. В случае, если требования в профиле и спецификациях, на которые он ссылаются, противоречат друг другу, требования профиля имеют приоритет с целью обеспечения соответствия профиля.

ГОСТ Р ИСО/МЭК 29362—2013

Уровни обязательности требования, обозначенные в соответствии с RFC2119 (ДОЛЖЕН, МОЖЕТ. СЛЕДУЕТ и т.п.), указывают на природу требования и его воздействие на соответствие. Для удобства каждое требование имеет индивидуальный идентификатор (например, R9999).

Пример - R9999 Виджетам (WIDGETs) СЛЕДУЕТ (SHOLUD) быть круглой формы.

Это требование, идентифицированное как «R9999». применяется к целевому ВИДЖЕТУ (WIDGET) (см. далее), и предъявляет условное требование к совокупности виджетов, т е. хотя это требование в большинстве случаев должно быть удовлетворено, чтобы реализация соответствовала профилю, имеются отдельные ситуации, когда могут быть уважительные причины нарушения требования. Такие причины объясняются непосредственно в требовании или в сопровождающем его тексте.

Каждое положение требований содержит одно и только одно ключевое слово уровня обязательности требования (например. «ДОЛЖЕН» (MUST)), и одно ключевое слово цели соответствия (например. «СООБЩЕНИЕ» (MESSAGE)). Ключевое слово цели соответствия показано жирным шрифтом (например. «СООБЩЕНИЕ» (MESSAGE)). Другие цели соответствия, показанные не жирным шрифтом, используются строго для их определения, а НЕ для цели соответствия. Для объяснения требования или группы требований может быть включен дополнительный текст (например, обоснование и примеры); однако, текст, не входящий непосредственно в положения требований, не должен рассматриваться при определении соответствия.

Определения терминов профиля считаются надежными для целей определения соответствия.

Ни одно из требований профиля, независимо от уровня его обязательности, не должно быть истолковано как ограничивающее возможность реализации соответствующих контрмер безопасности в ответ на реальные или предполагаемые угрозы (например, на атаку отказа в обслуживании).

2.2    Цели соответствия

Цели соответствия определяют, к каким артефактам применяются требования. Примерами целей являются: сообщение SOAP (Simple Object Access Protocol— простой протокол доступа к объектам), описание WSDL (Web Services Description Language — язык описания Веб-служб и доступа к ним), данные реестра UDDI (Universal Description Discovery & Integration — инструмент для расположения описаний Веб-служб) или стороны, например, процессор SOAP, конечный пользователь.

Это позволяет определить соответствие в различных контекстах для гарантии однозначной интерпретации применимости требований и обеспечения проверки артефактов (например, сообщений SOAP и описаний WSDL) и функциональных возможностей различных сторон на соответствие Веб-службе (например, конкретным клиентам и службам).

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

В профиле используются следующие цели соответствия:

•    СООБЩЕНИЕ (MESSAGE) - элементы протокола, посредством которых осуществляется передача КОНВЕРТА (например, сообщение SOAP/HTTP) (см ИСО/МЭК 29361);

•    КОНВЕРТ (ENVELOPE) - преобразование в сериализованную форму элемента soap:Envelope и его содержимого (см. ИСО/МЭК 29361);

•    ОПИСАНИЕ (DESCRIPTION) - описания типов, сообщений, интерфейсов и их конкретных протоколов, привязки форматов данных, и сетевых точек доступа, связанных с Веб-сервисами (например, описания WSDL) (см. ИСО/МЭК 29361);

•    РЕАЛИЗАЦИЯ (INSTANCE) - программное обеспечение, которое осуществляет выполнение связывания wsdl.port или uddi:bindingTemplate (см. ИСО/МЭК 29361);

•    ПОЛЬЗОВАТЕЛЬ (CONSUMER) - программное обеспечение, которое обращается к РЕАЛИЗАЦИИ (см. ИСО/МЭК 29361);

•    ОТПРАВИТЕЛЬ (SENDER) - программное обеспечение, которое генерирует сообщение в соответствии со связанными с ним протоколом или протоколами (см. ИСО/МЭК 29361);

•    ПОЛУЧАТЕЛЬ (RECEIVER) - программное обеспечение, которое использует сообщение в соответствии со связанными с ним протоколом или протоколами (например, процессоры SOAP) (см. ИСО/МЭК 29361).

2.3    Область соответствия

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

Область применения профиля уточняется далее возможными расширениями. Технические спецификации зачастую обеспечивают механизмы расширения и неопределенные или открытые параметры конфигурации. В том случае, если в профиле определено возможное расширение, то

такой механизм или параметр не входит в область применения профиля, и его использование или неиспользование выходит за рамки требований соответствия.

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

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

Область применения профиля определена техническими условиями, перечисленными в Приложении А. и уточняется возможными расширениями, указанными в Приложении В.

2.4 Декларация о соответствии

Декларации о соответствии профилю могут быть сделаны с использованием механизмов, описанных в спецификации «Механизмы вложения деклараций о соответствии», в случае, если были удовлетворены применимые требования профиля, связанные со следующими целями:

•    WSDL 1.1 Механизм вложения деклараций для реализаций Веб-служб (Claim Attachment Mechanism for Web Services Instances) -

ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ:

•    WSDL 1.1 Механизм вложения деклараций для конструкций описания (Claim Attachment Mechanism for Description Constructs) -

ОПИСАНИЕ;

•    UDDI Механизм вложения деклараций для конкретных Веб-служб (Claim Attachment Mechanism for Web Services Instances -

ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ.

URI декларации о соответствии для этого профиля -«http://wsi.Org/profiles/attachments/1.0».

3 Упаковка вложения

Данный раздел профиля включает следующие ссылки на спецификации и определяет возможные в них расширения:

•    Сообщения SOAP с вложениями (SOAP Messages with Attachments)_ Возможные расширения:

о Е0001 - части MIME - Сообщения SOAP с вложениями не накладывают никаких ограничений на тип некорневой части составных / связанных сообщений.

•    Расширяемый язык разметки (XML) 1.0 (Вторая Редакция) (Extensible Markup Language (XML) 1.0 (Second Edition)).

•    Пространства имен e XML 1.0 (Namespaces in XML 1.0).

•    RFC2557    Инкапсуляция    составных    документов    MIME, таких как HTML (MHTML) (RFC2557

MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)).

•    RFC2045    Многоцелевое    расширение возможностей почты в сети Интернет (MIME). Часть 1:

Формат интернет-сообщений (RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies).

•    RFC2046    Многоцелевое    расширение возможностей почты в сети Интернет (MIME). Часть 2:

Типы медиа (RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types).

•    RFC2392    Единые    указатели    ресурсов    идентификатора    контента    и    идентификатора

сообщения (RFC2392 Content-ID and Message-ID Uniform Resource Locators).

Сообщения SOAP с вложениями определяют составную/связанную (multipart/related) структуру MIME, предназначенную для формирования конверта SOAP с вложениями. Профиль требует использования этой структуры и ставит приведенные далее ограничения на ее использование:

3.1 Корневая часть

R2931 Собственно тело корневой части составного/связанного СООБЩЕНИЯ ДОЛЖНО быть soapEnvelope.

R2945 Значение поля Content-Type HTTP-заголовка в СООБЩЕНИИ ДОЛЖНО быть либо «multipart/related». либо «text/xml». С

R2932 Если в значении Content-Type HTTP-заголовка СООБЩЕНИЯ указан тип медиа (media-type) «multipart/related», то в значении Content-Type HTTP-заголовка ДОЛЖЕН присутствовать параметр type со значением «text/xml». С

Любая часть MIME может содержать soap:Envelope, однако только собственно тело корневой части пакета MIME обрабатывается как основной конверт SOAP. Некорневые части рассматриваются как вложения.

4

ГОСТ Р ИСО/МЭК 29362—2013

Пример:

ПРАВИЛЬНО

В показанном далее сообщении в значении поля Content-Type HTTP-заголовка указан тип медиа (media-type) «multiparl/related», и параметр type имеет значение кtext/xml».

MIME-Version: 1.0

Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;

Content-Description. This is the optional message description.

~MIME_boundary

Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com>

<?xml version-1 O' ?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV= «http://schemas.xmlsoap.org/soap/envelope/»>

</SOAP-ENV:Envelope>

-MIME_boundary

~MIME_boundary«

3.2    Кодирование корневой части

R2915 Собственно тело корневой части составного/связанного СООБЩЕНИЯ ДОЛЖНО быть преобразовано в сериализованную форму с использованием кодировки символов UTF-8 или UTF-16.

R2916 Для некорневых частей составного/связанного СООБЩЕНИЯ МОЖЕТ быть использована любая кодировка символов.

3.3    Тип Mepna(media-type) сообщения

R2925 Если в описании WSDL упомянута хотя бы одна некорневая часть MIME, то в значении поля Content-Type HTTP-заголовка соответствующего СООБЩЕНИЯ тип медиа (media-type) ДОЛЖЕН быть «multipart/related».

3.4    Сообщения без вложений

Если получатель ожидает ноль или более вложений в сообщении, то отправитель этого сообщения может использовать для сообщения без каких-либо вложений тип медиа text/xml.

R2917 СООБЩЕНИЕ, содержащее ноль частей вложения. ДОЛЖНО быть отправлено, с использованием типа контента или «text/xml», если использовалось HTTP-связывание SOAP, или «multipart/related» в случае, если описание WSDL для сообщения определяет элемент mime: multi part Related в соответствующем элементе wsdl.input или wsdioutput в его привязке wsdlbinding

R2902 ОТПРАВИТЕЛЬ НЕ ДОЛЖЕН посылать сообщения с использованием SOAP с вложениями, если соответствующий элемент wsdlinput или wsdioutput в wsdl binding не определяет привязку WSDL MIME.

Это может произойти только в случае, если описание WSDL определяет mime.multipartRelated. у которого есть только один дочерний элемент mime part, содержащий soapbind.body.

Пример:

ПРАВИЛЬНО:

Результатом следующего описания WSDL:

<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soapr xmlns:wsdl="http7/schemas. xmlsoap.org/wsd IT xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdr xmlns:tns="http7/example.conVmimewsdr>

<wsdl:binding name="aBinding" type=tns:aPortType">

<soapbind:binding style=’rpc"

transport=”http7/schemas. xmlsoap.org/soap/http7>

<wsdl:operation name="anOperation">

<soap:operation soapAction="http://example.com/soapaction7>

<wsdl:input>

<mime:multipartRelated>

<mime:part>

5

ГОСТ Р ИСО/МЭК 29362—2013

<soapbind:body use="literal" namespace=^Hhttp://example.com/mimetypes7>

</mime:part>

</mime:multipartRelated>

</wsdl:input>

<wsdl:output>

<soapbind:body use=’literar

namespace="http://example.com/mimetypes’7>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

</wsdl:defmitions>

может быть входящее сообщение, которое использует HTTP-связывание SOAP следующим образом:

<?xml version-1.0* ?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=^Mhttp://schemas. xmlsoap.org/soap/enveloper> <SOAP-ENV:Body xmlns:types="http://example conVmimetypes“>

<types:anOperation>

</types:anOperation>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

но не должно быть исходящее сообщение, которое использует следующее связывание MIME:

MIME-Version: 1.0

Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;

start=“<rootpa rt@example.com>’

Content-Description: This is the optional message description.

-MIME_boundary

Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com>

<?xml version='1 O' ?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas xmlsoap.org/soap/enveloper>

<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes‘>

<types:anOperationResponse>

</types:anOpertionResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

-MIME_boundary-

3.5 Разрешение ссылок вложений

Приложения, использующие Веб-службы, могут использовать URI различными способами, включая и средства извлечения контента из сети. Хотя вложения и могут быть использованы для обеспечения контента, который идентифицирован соответствующим URI, не требуется, чтобы реализации оказывали предпочтение присоединенному контенту, использовали бы его исключительно или использовали его вообще. Таким же образом приложения могут игнорировать указанную функцию разрешения ссылок URI (например, загрузку контента из сети) и использовать только присоединенный контент. При использовании схемы идентификации контента (Content-ID. CID) в URI применяются синтаксис и правила, определенные в RFC 2392

R2918 ПОЛУЧАТЕЛЬ МОЖЕТ игнорировать ссылку URI на вложение в конверте (envelope)

6