CAN/CSA-ISO/IEC 29362:18

1.1 Scope This International Standard defines the WS-I Attachments Profile 1.0 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications that are intended to promote interoperability. This profile complements the WS-I Basic Profile 1.1 to add support for conveying interoperable SOAP Messages with Attachments-based attachments with SOAP messages. SOAP Messages with Attachments (SwA) defines a MIME multipart/related structure for packaging attachments with SOAP messages. This profile complements the WS-I Basic Profile 1.1 to add support for conveying interoperable SwA-based attachments with SOAP messages. Section 1 introduces the Profile, and explains its relationships to other profiles. Section 2, "Profile Conformance," explains what it means to be conformant to the Profile. Each subsequent section addresses a component of the Profile, and consists of two parts: an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. 1.2 Relationship to other Profiles This Profile adds support for SOAP with Attachments and MIME bindings, and is intended to be used in combination with the Basic Profile 1.1. 1.3 Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as in RFC2119. Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in "Conformance Requirements") are presented in the following manner: RnnnnStatement text here. where "nnnn" is replaced by a number that is unique among the requirements in the Profile, thereby forming a unique requirement identifier. Requirement identifiers can be considered to be namespace qualified, in such a way as to be compatible with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed to "bp10:R9999"), it should be interpreted as being in the namespace identified by the conformance URI of the document section it occurs in. If it is qualified, the prefix should be interpreted according to the namespace mappings in effect, as documented below. Some requirements clarify the referenced specification(s), but do not place additional constraints upon implementations. For convenience, clarifications are annotated in the following manner: C Some requirements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "WSDL20" for WSDL Version 2.0). Note that because such work was not complete when this document was published, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers. Extensibility points in underlying specifications (see "Conformance Scope") are presented in a similar manner: EnnnnExtensibility Point Name - Description where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As with requirement statements, extensibility statements can be considered namespace-qualified. This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant. • 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 - "urn:uddi-org:api_v2" • wsi - "http://www.ws-i.org/schemas/conformanceClaim" • ref - "http://ws-i.org/profiles/basic/1.1/xsd" 1.4 Profile Identification and Versioning This document is identified by a name (in this case, Attachments Profile) and a version number (here, 1.0). Together, they identify a particular profile instance. Version numbers are composed of a major and minor portion, in the form "major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances. Instances of profiles with the same name (e.g., "Example Profile 1.1" and "Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances). One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g., "Example Profile 1.0" and "Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.