ISO/IEC 29361:2008

SLOVENSKI STANDARD
01-julij-2007
,QIRUPDFLMVNDWHKQRORJLMD2VQRYQLSURILOUD]OLþLFD
Information technology — Basic Profile Version 1.1
Technologies de l'information — Version 1.1 de profil de base
Ta slovenski standard je istoveten z:
ICS:
35.100.05 9HþVORMQHXSRUDEQLãNH Multilayer applications
UHãLWYH
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT INTERNATIONAL STANDARD ISO/IEC 29361
Attributed to ISO/IEC JTC 1 by the Central Secretariat (see page iii)

Voting begins on Voting terminates on
2006-12-18 2007-06-18
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION • МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ • ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОММИСИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE

PUBLICLY AVAILABLE SPECIFICATION PROCEDURE
Information technology — Basic Profile Version 1.1
Technologies de l'information — Version 1.1 de profil de base
ICS 35.100.05
In accordance with the provisions of Council Resolution 21/1986 this DIS is circulated in the
English language only.
Conformément aux dispositions de la Résolution du Conseil 21/1986, ce DIS est distribué en
version anglaise seulement.
This Publicly Available Specification (PAS) is being submitted for Fast-track processing in
accordance with the provisions of ISO/IEC JTC 1 Directives.

THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE
REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME
STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.
International Organization for Standardization, 2006
©
International Electrotechnical Commission, 2006

ISO/IEC DIS 29361
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO/IEC 2006 — All rights reserved

ISO/IEC DIS 29361
NOTE FROM ITTF
This draft International Standard is submitted for JTC 1 national body vote under the Fast-Track Procedure.
In accordance with Resolution 30 of the JTC 1 Berlin Plenary 1993, the proposer of this document recommends
assignment of ISO/IEC 29361 to JTC 1.
See also explanatory report.
“FAST-TRACK” PROCEDURE
1  Any P-member and any Category A liaison organization of ISO/IEC JTC 1 may propose that an existing
standard from any source be submitted directly for vote as a DIS. The criteria for proposing an existing
standard for the fast-track procedure are a matter for each proposer to decide.
2  The proposal shall be received by the ITTF which will take the following actions.
2.1  To settle the copyright and/or trade mark situation with the proposer, so that the proposed text can be
freely copied and distributed within JTC 1 without restriction.
2.2  To assess in consultation with the JTC 1 secretariat which SC is competent for the subject covered by
the proposed standard and to ascertain that there is no evident contradiction with other International
Standards.
2.3  To distribute the text of the proposed standard as a DIS. In case of particularly bulky documents the ITTF
may demand the necessary number of copies from the proposer.
3  The period for combined DIS voting shall be six months. In order to be accepted the DIS must be
supported by 75 % of the votes cast (abstention is not counted as a vote) and by two-thirds of the P-members
voting of JTC 1.
4  At the end of the voting period, the comments received, whether editorial only or technical, will be dealt
with by a working group appointed by the secretariat of the relevant SC.
5  If, after the deliberations of this WG, the requirements of 3 above are met, the amended text shall be sent
to the ITTF by the secretariat of the relevant SC for publication as an International Standard.
If it is impossible to agree to a text meeting the above requirements, the proposal has failed and the procedure
is terminated.
In either case the WG shall prepare a full report which will be circulated by the ITTF.
6  If the proposed standard is accepted and published, its maintenance will be handled by JTC 1.

© ISO/IEC 2006 — All rights reserved iii

Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Basic Profile Version 1.1
Final Material
2006-04-10
This version:
http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html
Latest version:
http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Errata for this Version:
http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2006-04-10.html
Editors:
Keith Ballinger, Microsoft (1.0)
David Ehnebuske, IBM (1.0)
Christopher Ferris, IBM
Martin Gudgin, Microsoft (1.0)
Canyang Kevin Liu, SAP
Mark Nottingham, BEA Systems
Prasad Yendluri, webMethods
Administrative contact:
secretary@ws-i.org
Members. All Rights Reserved.
Abstract
This document defines the WS-I Basic Profile 1.1, consisting of a set of non-proprietary Web
services specifications, along with clarifications, refinements, interpretations and amplifications of
those specifications which promote interoperability
Status of this Document
This is a final specification. Please refer to the errata, which may include normative corrections to it.
Notice
The material contained herein is not a license, either expressly or impliedly, to any intellectual
property owned or controlled by any of the authors or developers of this material or WS-I. The
material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by
1 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and
developers of this material and WS-I hereby disclaim all other warranties and conditions, either
express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or
conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of
responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO,
THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH
REGARD TO THIS MATERIAL.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE
TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR
SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR
ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY
HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
Feedback
If there are areas in this specification that could be clearer, or if errors or omissions are identified,
WS-I would like to be notified in order to provide the best possible interoperability guidance.
By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an
individual, and your company if you are providing Feedback on behalf of the company) will be
deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your
Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license
to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner
whatsoever the Feedback you provide regarding the work. You acknowledge that you have no
expectation of confidentiality with respect to any Feedback you provide. You represent and warrant
that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a
company, you represent and warrant that you have the rights to provide Feedback on behalf of your
company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any
way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all
of your Feedback in a future version of the work, it may, but is not obligated to include your name
(or, if you are identified as acting on behalf of your company, the name of your company) on a list of
contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf
you are acting, please do not provide any Feedback.
Feedback on this document should be directed to wsbasic_comment@ws-i.org.
Table of Contents
1. Introduction
1.1. Relationships to Other Profiles
1.2. Changes from Basic Profile Version 1.0
1.3. Guiding Principles
1.4. Notational Conventions
1.5. Profile Identification and Versioning
2. Profile Conformance
2.1. Conformance Requirements
2.2. Conformance Targets
2.3. Conformance Scope
2.4. Claiming Conformance
3. Messaging
2 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
3.1. SOAP Envelopes
3.1.1. SOAP Envelope Structure
3.1.2. SOAP Envelope Namespace
3.1.3. SOAP Body Namespace Qualification
3.1.4. Disallowed Constructs
3.1.5. SOAP Trailers
3.1.6. SOAP encodingStyle Attribute
3.1.7. SOAP mustUnderstand Attribute
3.1.8. xsi:type Attributes
3.1.9. SOAP1.1 attributes on SOAP1.1 elements
3.2. SOAP Processing Model
3.2.1. Mandatory Headers
3.2.2. Generating mustUnderstand Faults
3.2.3. SOAP Fault Processing
3.3. SOAP Faults
3.3.1. Identifying SOAP Faults
3.3.2. SOAP Fault Structure
3.3.3. SOAP Fault Namespace Qualification
3.3.4. SOAP Fault Extensibility
3.3.5. SOAP Fault Language
3.3.6. SOAP Custom Fault Codes
3.4. Use of SOAP in HTTP
3.4.1. HTTP Protocol Binding
3.4.2. HTTP Methods and Extensions
3.4.3. SOAPAction HTTP Header
3.4.4. HTTP Success Status Codes
3.4.5. HTTP Redirect Status Codes
3.4.6. HTTP Client Error Status Codes
3.4.7. HTTP Server Error Status Codes
3.4.8. HTTP Cookies
4. Service Description
4.1. Required Description
4.2. Document Structure
4.2.1. WSDL Schema Definitions
4.2.2. WSDL and Schema Import
4.2.3. WSDL Import location Attribute Structure
4.2.4. WSDL Import location Attribute Semantics
4.2.5. Placement of WSDL import Elements
4.2.6. XML Version Requirements
4.2.7. XML Namespace declarations
4.2.8. WSDL and the Unicode BOM
4.2.9. Acceptable WSDL Character Encodings
4.2.10. Namespace Coercion
4.2.11. WSDL documentation Element
4.2.12. WSDL Extensions
4.3. Types
4.3.1. QName References
4.3.2. Schema targetNamespace Structure
4.3.3. soapenc:Array
4.3.4. WSDL and Schema Definition Target Namespaces
4.4. Messages
4.4.1. Bindings and Parts
4.4.2. Bindings and Faults
4.4.3. Declaration of part Elements
4.5. Port Types
4.5.1. Ordering of part Elements
3 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
4.5.2. Allowed Operations
4.5.3. Distinctive Operations
4.5.4. parameterOrder Attribute Construction
4.5.5. Exclusivity of type and element Attributes
4.6. Bindings
4.6.1. Use of SOAP Binding
4.7. SOAP Binding
4.7.1. Specifying the transport Attribute
4.7.2. HTTP Transport
4.7.3. Consistency of style Attribute
4.7.4. Encodings and the use Attribute
4.7.5. Multiple Bindings for portType Elements
4.7.6. Operation Signatures
4.7.7. Multiple Ports on an Endpoint
4.7.8. Child Element for Document-Literal Bindings
4.7.9. One-Way Operations
4.7.10. Namespaces for soapbind Elements
4.7.11. Consistency of portType and binding Elements
4.7.12. Describing headerfault Elements
4.7.13. Enumeration of Faults
4.7.14. Type and Name of SOAP Binding Elements
4.7.15. name Attribute on Faults
4.7.16. Omission of the use Attribute
4.7.17. Default for use Attribute
4.7.18. Consistency of Envelopes with Descriptions
4.7.19. Response Wrappers
4.7.20. Part Accessors
4.7.21. Namespaces for Children of Part Accessors
4.7.22. Required Headers
4.7.23. Allowing Undescribed Headers
4.7.24. Ordering Headers
4.7.25. Describing SOAPAction
4.7.26. SOAP Binding Extensions
4.8. Use of XML Schema
5. Service Publication and Discovery
5.1. bindingTemplates
5.2. tModels
6. Security
6.1. Use of HTTPS
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Defined Terms
Appendix D: Acknowledgements
1. Introduction
This document defines the WS-I Basic Profile 1.1 (hereafter, "Profile"), consisting of a set of
non-proprietary Web services specifications, along with clarifications, refinements, interpretations
and amplifications of those specifications which promote interoperability.
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
4 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
subsections that address individual parts of the component specifications. Note that there is no
relationship between the section numbers in this document and those in the referenced
specifications.
1.1 Relationships to Other Profiles
This Profile is derived from the Basic Profile 1.0 by incorporating any errata to date and separating
out those requirements related to the serialization of envelopes and their representation in
messages. Such requirements are now part of the Simple SOAP Binding Profile 1.0, identified with a
separate conformance claim. This separation is made to facilitate composability of Basic Profile 1.1
with any profile that specifies envelope serialization, including the Simple SOAP Binding Profile 1.0
and the Attachments Profile 1.0. A combined claim of conformance to both the Basic Profile 1.1 and
the Simple SOAP Binding Profile 1.0 is roughly equivalent to a claim of conformance to the Basic
Profile 1.0 plus published errata.
This Profile, composed with the Simple SOAP Binding Profile 1.0 supercedes the Basic Profile 1.0.
The Attachments Profile 1.0 adds support for SOAP with Attachments, and is intended to be used in
combination with this Profile.
1.2 Changes from Basic Profile Version 1.0
This specification is derived from the Basic Profile Version 1.0, and incorporates published errata
against that specification. The most notable changes are:
MESSAGE conformance target - Some requirements that had a MESSAGE conformance
target in BP1.0 now use a new target, ENVELOPE. This facilitates alternate serialisations of
the message, such as that described in the Attachments Profile.
SOAP Binding - Requirements relating to the SOAP binding's serialization of the message
have been moved to the Simple SOAP Binding Profile to facilitate other serializations.
1.3 Guiding Principles
The Profile was developed according to a set of principles that, together, form the philosophy of the
Profile, as it relates to bringing about interoperability. This section documents these guidelines.
No guarantee of interoperability
It is impossible to completely guarantee the interoperability of a particular service. However,
the Profile does address the most common problems that implementation experience has
revealed to date.
Application semantics
Although communication of application semantics can be facilitated by the technologies that
comprise the Profile, assuring the common understanding of those semantics is not addressed
by it.
Testability
When possible, the Profile makes statements that are testable. However, such testability is not
required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts
"on the wire").
Strength of requirements
The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there
are legitimate cases where such a requirement cannot be met, conditional requirements (e.g.,
SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce
ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the requirements of referenced specifications, the Profile may restrict them,
5 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
but does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced specification allows multiple mechanisms to be used interchangeably, the
Profile selects those that are well-understood, widely implemented and useful. Extraneous or
underspecified mechanisms and extensions introduce complexity and therefore reduce
interoperability.
Future compatibility
When possible, the Profile aligns its requirements with in-progress revisions to the
specifications it references. This aids implementers by enabling a graceful transition, and
assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue
in a specification it references, this information is communicated to the appropriate body to
assure its consideration.
Compatibility with deployed services
Backwards compatibility with deployed Web services is not a goal for the Profile, but due
consideration is given to it; the Profile does not introduce a change to the requirements of a
referenced specification unless doing so addresses specific interoperability issues.
Focus on interoperability
Although there are potentially a number of inconsistencies and design flaws in the referenced
specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP
messages) rather than the producing or consuming software's behaviors or roles. Artifacts are
concrete, making them easier to verify and therefore making conformance easier to
understand and less error-prone.
Lower-layer interoperability
The Profile speaks to interoperability at the application layer; it assumes that interoperability of
lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and well-understood. Similarly,
statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only made
when there is an issue affecting Web services specifically; WS-I does not attempt to assure
the interoperability of these protocols as a whole. This assures that WS-I's expertise in and
focus on Web services standards is used effectively.
1.4 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 described 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:
Rnnnn Statement 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
6 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
C
upon implementations. For convenience, clarifications are annotated in the following manner:
Some requirements are derived from ongoing standardization work on the referenced
specification(s). For convenience, such forward-derived statements are annotated in the following
xxxx
manner: , 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:
Ennnn Extensibility 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/"
uddi - "urn:uddi-org:api_v2"
1.5 Profile Identification and Versioning
This document is identified by a name (in this case, Basic Profile) and a version number (here, 1.1).
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.
2 Profile Conformance
Conformance to the Profile is defined by adherence to the set of requirements defined for a specific
target, within the scope of the Profile. This section explains these terms and describes how
conformance is defined and used.
7 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
2.1 Conformance Requirements
Requirements state the criteria for conformance to the Profile. They typically refer to an existing
specification and embody refinements, amplifications, interpretations and clarifications to it in order
to improve interoperability. All requirements in the Profile are considered normative, and those in the
specifications it references that are in-scope (see "Conformance Scope") should likewise be
considered normative. When requirements in the Profile and its referenced specifications contradict
each other, the Profile 's requirements take precedence for purposes of Profile conformance.
Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of
the requirement and its impact on conformance. Each requirement is individually identified (e.g.,
R9999) for convenience.
For example;
R9999 WIDGETs SHOULD be round in shape.
This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a
conditional requirement upon widgets; i.e., although this requirement must be met to maintain
conformance in most cases, there are some situations where there may be valid reasons for it not
being met (which are explained in the requirement itself, or in its accompanying text).
Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one
conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold
text (e.g. "MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly
for their definition and NOT as a conformance target. Additional text may be included to illuminate a
requirement or group of requirements (e.g., rationale and examples); however, prose surrounding
requirement statements must not be considered in determining conformance.
Definitions of terms in the Profile are considered authoritative for the purposes of determining
conformance.
None of the requirements in the Profile, regardless of their conformance level, should be interpreted
as limiting the ability of an otherwise conforming implementation to apply security countermeasures
in response to a real or perceived threat (e.g., a denial of service attack).
2.2 Conformance Targets
Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry
data) or parties (e.g., SOAP processor, end user) requirements apply to.
This allows for the definition of conformance in different contexts, to assure unambiguous
interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g.,
SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service
(e.g., clients and service instances).
Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and
avoid ambiguity.
The following conformance targets are used in the Profile:
MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
ENVELOPE - the serialization of the soap:Envelope element and its content
DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and
data format bindings, and the network access points associated with Web services (e.g.,
WSDL descriptions) (from Basic Profile 1.0)
INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate (from Basic
8 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Profile 1.0)
CONSUMER - software that invokes an INSTANCE (from Basic Profile 1.0)
SENDER - software that generates a message according to the protocol(s) associated with it
(from Basic Profile 1.0)
RECEIVER - software that consumes a message according to the protocol(s) associated with
it (e.g., SOAP processors) (from Basic Profile 1.0)
REGDATA - registry elements that are involved in the registration and discovery of Web
services (e.g. UDDI tModels) (from Basic Profile 1.0)
2.3 Conformance Scope
The scope of the Profile delineates the technologies that it addresses; in other words, the Profile
only attempts to improve interoperability within its own scope. Generally, the Profile's scope is
bounded by the specifications referenced by it.
The Profile's scope is further refined by extensibility points. Referenced specifications often provide
extension mechanisms and unspecified or open-ended configuration parameters; when identified in
the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the
Profile, and its use or non-use is not relevant to conformance.
Note that the Profile may still place requirements on the use of an extensibility point. Also, specific
uses of extensibility points may be further restricted by other profiles, to improve interoperability
when used in conjunction with the Profile.
Because the use of extensibility points may impair interoperability, their use should be negotiated or
documented in some fashion by the parties to a Web service; for example, this could take the form
of an out-of-band agreement.
The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the
extensibility points in Appendix B.
2.4 Claiming Conformance
Claims of conformance to the Profile can be made using the following mechanisms, as described in
Conformance Claim Attachment Mechanisms, when the applicable Profile requirements associated
with the listed targets have been met:
WSDL 1.1 Claim Attachment Mechanism for Web Services Instances - MESSAGE
DESCRIPTION INSTANCE RECEIVER
WSDL 1.1 Claim Attachment Mechanism for Description Constructs - DESCRIPTION
UDDI Claim Attachment Mechanism for Web Services Instances - MESSAGE
DESCRIPTION INSTANCE RECEIVER
UDDI Claim Attachment Mechanism for Web Services Registrations - REGDATA
The conformance claim URI for this Profile is "http://ws-i.org/profiles/basic/1.1" .
3. Messaging
This section of the Profile incorporates the following specifications by reference, and defines
extensibility points within them:
Simple Object Access Protocol (SOAP) 1.1
Extensibility points:
E0001 - Header blocks - Header blocks are the fundamental extensibility mechanism in
SOAP.
E0002 - Processing order - The order of processing of a SOAP envelope's components
9 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
(e.g., headers) is unspecified, and therefore may need to be negotiated out-of-band.
E0003 - Use of intermediaries - SOAP Intermediaries is an underspecified mechanism
in SOAP 1.1, and their use may require out-of-band negotiation. Their use may also
necessitate careful consideration of where Profile conformance is measured.
E0004 - soap:actor values - Values of the soap:actor attribute, other than the special uri
'http://schemas.xmlsoap.org/soap/actor/next' , represent a private agreement between
parties of the web service.
E0005 - Fault details - the contents of a Fault's detail element are not prescribed by
SOAP 1.1.
E0006 - Envelope serialization - The Profile does not constrain some aspects of how
the envelope is serialized into the message.
RFC2616: Hypertext Transfer Protocol -- HTTP/1.1
Extensibility points:
E0007 - HTTP Authentication - HTTP authentication allows for extension schemes,
arbitrary digest hash algorithms and parameters.
E0008 - Unspecified Header Fields - HTTP allows arbitrary headers to occur in
messages.
E0009 - Expect-extensions - The Expect/Continue mechanism in HTTP allows for
expect-extensions.
E0010 - Content-Encoding - The set of content-codings allowed by HTTP is
open-ended and any besides 'gzip', 'compress', or 'deflate' are an extensibility point.
E0011 - Transfer-Encoding - The set of transfer-encodings allowed by HTTP is
open-ended.
E0012 - Upgrade - HTTP allows a connection to change to an arbitrary protocol using
the Upgrade header.
E0024 - Namespace Attributes - Namespace attributes on soap:Envelope and
soap:Header elements
E0025 - Attributes on soap:Body elements - Neither namespaced nor local attributes
are constrained by SOAP 1.1.
RFC2965: HTTP State Management Mechanism
3.1 SOAP Envelopes
The following specifications (or sections thereof) are referred to in this section of the Profile :
SOAP 1.1, Section 4
SOAP 1.1 defines a structure for composing messages, the envelope. The Profile mandates the use
of that structure, and places the following constraints on its use:
3.1.1 SOAP Envelope Structure
R9980 An ENVELOPE MUST conform to the structure specified in SOAP 1.1
Section 4, "SOAP Envelope" (subject to amendment by the Profile).
R9981 An ENVELOPE MUST have exactly zero or one child elements of the
soap:Body element.
While the combination of R2201 and R2210 (below) clearly imply that there may be at most one
child element of the soap:Body, there is no explicit requirement in the Profile that articulates this
constraint, leading to some confusion.
3.1.2 SOAP Envelope Namespace
SOAP 1.1 states that an envelope with a document element whose namespace name is other than
"http://schemas.xmlsoap.org/soap/envelope/" should be discarded. The Profile requires that a fault
be generated instead, to assure unambiguous operation.
10 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
R1015 A RECEIVER MUST generate a fault if they encounter an envelope whose
document element is not soap:Envelope.
3.1.3 SOAP Body Namespace Qualification
The use of unqualified element names may cause naming conflicts, therefore qualified names must
be used for the children of soap:Body.
R1014 The children of the soap:Body element in an ENVELOPE MUST be
namespace qualified.
3.1.4 Disallowed Constructs
XML DTDs and PIs may introduce security vulnerabilities, processing overhead and semantic
ambiguity when used in envelopes. As a result, certain XML constructs are disallowed by section 3
of SOAP 1.1.
Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata) allows
the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace" to appear, some
older processors considered such a declaration to be an error. These requirements ensure that
conformant artifacts have the broadest interoperability possible.
C
R1008 An ENVELOPE MUST NOT contain a Document Type Declaration.
C
R1009 An ENVELOPE MUST NOT contain Processing Instructions.
R1033 An ENVELOPE SHOULD NOT contain the namespace declaration
C
xmlns:xml="http://www.w3.org/XML/1998/namespace".
R1034 A DESCRIPTION SHOULD NOT contain the namespace declaration
C
xmlns:xml="http://www.w3.org/XML/1998/namespace".
3.1.5 SOAP Trailers
The interpretation of sibling elements following the soap:Body element is unclear. Therefore, such
elements are disallowed.
R1011 An ENVELOPE MUST NOT have any element children of soap:Envelope
following the soap:Body element.
This requirement clarifies a mismatch between the SOAP 1.1 specification and the SOAP 1.1 XML
Schema.
For example,
INCORRECT:





Here is some data with the message


CORRECT:




Here is some data with the message


11 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html


3.1.6 SOAP encodingStyle Attribute
The soap:encodingStyle attribute is used to indicate the use of a particular scheme in the
encoding of data into XML. However, this introduces complexity, as this function can also be served
by the use of XML Namespaces. As a result, the Profile prefers the use of literal, non-encoded XML.
R1005 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on
any of the elements whose namespace name is
"http://schemas.xmlsoap.org/soap/envelope/".
R1006 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on
any element that is a child of soap:Body.
R1007 An ENVELOPE described in an rpc-literal binding MUST NOT contain
soap:encodingStyle attribute on any element that is a grandchild of
soap:Body.
3.1.7 SOAP mustUnderstand Attribute
The soap:mustUnderstand attribute has a restricted type of "xsd:boolean" that takes only "0" or
"1". Therefore, only those two values are allowed.
R1013 An ENVELOPE containing a soap:mustUnderstand attribute MUST only
C
use the lexical forms "0" and "1".
3.1.8 xsi:type Attributes
In many cases, senders and receivers will share some form of type information related to the
envelopes being exchanged.
R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in
envelopes except as required in order to indicate a derived type (see XML
Schema Part 1: Structures, Section 2.6.1).
3.1.9 SOAP1.1 attributes on SOAP1.1 elements
R1032 The soap:Envelope, soap:Header, and soap:Body elements in an
ENVELOPE MUST NOT have attributes in the namespace
"http://schemas.xmlsoap.org/soap/envelope/".
3.2 SOAP Processing Model
The following specifications (or sections thereof) are referred to in this section of the Profile:
SOAP 1.1, Section 2
SOAP 1.1 defines a model for the processing of envelopes. In particular, it defines rules for the
processing of header blocks and the envelope body. It also defines rules related to generation of
faults. The Profile places the following constraints on the processing model:
3.2.1 Mandatory Headers
SOAP 1.1's processing model is underspecified with respect to the processing of mandatory header
blocks. Mandatory header blocks are those children of the soap:Header element bearing a
soap:mustUnderstand attribute with a value of "1".
R1025 A RECEIVER MUST handle envelopes in such a way that it appears that all
12 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
checking of mandatory header blocks is performed before any actual
SOAP12
processing.
This requirement guarantees that no undesirable side effects will occur as a result of noticing a
mandatory header block after processing other parts of the message.
3.2.2 Generating mustUnderstand Faults
The Profile requires that receivers generate a fault when they encounter header blocks targeted at
them, that they do not understand.
R1027 A RECEIVER MUST generate a "soap:MustUnderstand" fault when an
envelope contains a mandatory header block (i.e., one that has a
soap:mustUnderstand attribute with the value "1") targeted at the
SOAP12
receiver (via soap:actor) that the receiver does not understand.
3.2.3 SOAP Fault Processing
When a fault is generated, no further processing should be performed. In request-response
exchanges, a fault message will be transmitted to the sender of the request, and some application
level error will be flagged to the user.
Both SOAP and this Profile use the term 'generate' to denote the creation of a SOAP Fault. It is
important to realize that generation of a Fault is distinct from its transmission, which in some cases
is not required.
R1028 When a fault is generated by a RECEIVER, further processing SHOULD
NOT be performed on the SOAP envelope aside from that which is
necessary to rollback, or compensate for, any effects of processing the
SOAP12
envelope prior to the generation of the fault.
R1029 Where the normal outcome of processing a SOAP envelope would have
resulted in the transmission of a SOAP response, but rather a fault is
generated instead, a RECEIVER MUST transmit a fault in place of the
SOAP12
response.
R1030 A RECEIVER that generates a fault SHOULD notify the end user that a fault
has been generated when practical, by whatever means is deemed
SOAP12
appropriate to the circumstance.
3.3 SOAP Faults
3.3.1 Identifying SOAP Faults
Some consumer implementations erroneously use only the HTTP status code to determine the
presence of a Fault. Because there are situations where the Web infrastructure changes the HTTP
status code, and for general reliability, the Profile requires that they examine the envelope. A Fault is
an envelope that has a single child element of the soap:Body element, that element being a
soap:Fault element.
R1107 A RECEIVER MUST interpret a SOAP message as a Fault when the
soap:Body of the message has a single soap:Fault child.
3.3.2 SOAP Fault Structure
The Profile restricts the content of the soap:Fault element to those elements explicitly described
in SOAP 1.1.
R1000 When an ENVELOPE is a Fault, the soap:Fault element MUST NOT
have element children other than faultcode, faultstring,
faultactor and detail.
13 of 46 7/10/2006 10:24 PM
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
For example,
INCORRECT:

soap:Client
Invalid message format
http://example.org/someactor
There were lots of elements in the message
that I did not understand


Severe


CORRECT:

soap:Client
Invalid message format
http://example.org/someactor


There were lots of elements in
the message that I did not understand


Severe



3.3.3 SOAP Fault Namespace Qualification
The children of the soap:Fault element are local to that element, therefore namespace
qualification is unnecessary.
R1001 When an ENVELOPE is a Fault, the element children of the soap:Fault
element MUST be unqualified.
For example,
INCORRECT:

soap:Client
Invalid message format
http://example.org/someactor


There were lots of elements in the message that
I did not understand



CORRECT:
xmlns='' >
soap:Client
Invalid message format
...