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 RFC 2119 [].

When describing abstract data models, this specification uses the notational convention used by the XML Infoset []. Specifically, abstract property names always appear in square brackets (e.g., [some property]).

When describing concrete XML schemas [, ], this specification uses the notational convention of WS-Security []. Specifically, each member of an element's [children] or [attributes] property is described using an XPath-like notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates the presence of an element wildcard (<xs:any/>). The use of @{any} indicates the presence of an attribute wildcard (<xs:anyAttribute/>).

This specification uses a number of namespace prefixes throughout; they are listed in . Note that the choice of any namespace prefix is arbitrary and not semantically significant (see []).

The working group intends to update the value of the Web Services Addressing 1.0 - WSDL Binding namespace URI each time a new version of this document is published until such time that the document reaches Candidate Recommendation status. Once it has reached Candidate Recommendation status, the working group intends to maintain the value of the Web Services Addressing 1.0 - WSDL Binding namespace URI that was assigned in the Candidate Recommendation unless significant changes are made that impact the implementation of the specification.

WS-Addressing is defined in terms of the XML Information Set []. WS-Addressing may be used with SOAP [] as described in Web Services Addressing 1.0 - SOAP Binding[]. The examples in this specification use an XML 1.0 [] representation but this is not a requirement.

All information items defined by this specification are identified by the XML namespace URI [] "http://www.w3.org/2006/02/addressing/wsdl". A normative XML Schema [, ] document can be obtained by dereferencing the XML namespace URI.

The WSDL binding of Web Services Addressing introduces the following element and attribute information items for referencing WSDL metadata from an EPR's metadata section:

The element information items defined above are used in an EPR's metadata section. The following shows an example endpoint reference. This references the interface named "fabrikam:Inventory" at the endpoint IRI "http://example.com/www.fabrikam/acct". Note the use of the WSDL[] wsdlLocation attribute.

WSDL 2.0 or, for backwards compatibility, 1.1 definitions can be embedded in the metadata section of an EPR to provide a consuming application with WSDL information that applies to the referenced endpoint. To do so, the creator of an EPR MAY include a WSDL 2.0 description element (or a WSDL 1.1 definitions element) in the metadata property of the EPR. The semantics of the embedded WSDL is as defined by the WSDL 2.0 or 1.1 specifications.

In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint. The alternatives are provided by the different endpoints of the embedded service. In the case of WSDL 1.1, additional ports may be conveyed by the WSDL 1.1 service definition which are not alternative access channels to the endpoint. In that case, if the InterfaceName or ServiceName elements are also included in the metadata section of the EPR, only the ports with the same interface as that specified are to be considered alternative access channels.

If the ServiceName element appears in the EPR’s [metadata] and an embedded WSDL service component is also provided inside a descriptions or definitions component, then the ServiceName SHOULD match the name of (one or more of) the WSDL service(s) included therein; the endpoint (port) name SHOULD match as well if present. The behavior of an EPR consumer when the ServiceName doesn’t match an embedded description is undefined.

WS-Addressing defines an empty global element, wsaw:UsingAddressing, that may be used to indicate that an endpoint conforms to the WS-Addressing specification. The wsdl:required attribute MAY be used to indicate whether WS-Addressing Message Addressing Properties are required in messages received from service requesters. outlines the requirements on messages sent from an endpoint based on the contents of any preceding input message and how the use of addressing is indicated in the WSDL.

If WS-A is engaged, use of the message addressing properties MUST be fully compliant with this specification; in particular, senders MUST use all message addressing properties mandated by the Web Services Addressing 1.0 - Core[], applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 - SOAP Binding[]), and this specification, and MUST follow all applicable WS-Addressing normative requirements.

The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only.

The inclusion of the wsaw:UsingAddressing element indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[].The presence of this element may extend the semantics of the endpoint's WSDL binding.

WS-Addressing defines a wsaw:Anonymous element that may only be used in conjunction with wsaw:UsingAddressing (or its equivalent wsoap:module) element. The usage of wsaw:Anonymous element is associated with the usage constraints specified for the wsaw:UsingAddressing element. Hence, it MUST NOT contain the wsdl:required attribute.

The inclusion of wsaw:Anonymous without inclusion of wsaw:UsingAddressing has no normative meaning and is only informational. In other words, the inclusion of wsaw:Anonymous element in WSDL alone does not imply a requirement on clients to use Message Addressing Properties in messages it sends to the service. A client, however, MAY include Message Addressing Properties in the messages it sends, either on its own initiative or as described by other elements of the service contract, regardless of the presence or absence of a wsaw:UsingAddressing element.

The wsaw:Anonymous element MAY have three distinct values that indicate three different levels of support for handling anonymous addresses in EPRs. In the following text, the term response endpoint EPR refers to the [reply endpoint] and [fault endpoint] message addressing properties collectively.

This element MAY appear as a child of an operation element in a binding element in WSDL 1.1, or as a binding operation extension element in WSDL 2.0.

In WSDL 2.0, the wsoap:module construct may be used to declare the use of the WS-Addressing 1.0 Module for the SOAP binding. The meaning of such a wsoap:module declaration is semantically equivalent to wsaw:UsingAddressing in this case. Note that this module is not meaningful when used on WSDL constructs where wsaw:UsingAddressing is not allowed.

The WS-Addressing 1.0 SOAP Module is described in Web Services Addressing 1.0 - SOAP Binding[] and is identified with the following URI: http://www.w3.org/2005/08/addressing/module

In the absence of additional runtime information, the value of the [destination] message addressing property for a message sent to an endpoint MUST match the value of the {address} property of the endpoint component (WSDL 2.0) or the address value provided by the relevant port extension (WSDL 1.1). For a SOAP 1.1 port described using WSDL 1.1, the value is provided by the location attribute of the soap11:address extension element.

Additional runtime information could override the value of the [destination] message addressing property for messages sent to an endpoint, e.g. a runtime exchange might result in a redirection to a different EPR. Note that WS-Addressing does not define any normative mechanism for such redirection.

WS-Addressing defines two mechanisms to associate a value of the [action] property with input, output and fault elements within a WSDL description: explicit and defaulting. Explicit association is described in section ; action defaulting (where a unique value for the [action] property is automatically generated) is described in section for WSDL 1.1 and section for WSDL 2.0.

Ensuring that there is sufficient information within a message to distinguish which WSDL operation it is associated with is specified as a best practice in WSDL 2.0. The [action] property provides a mechanism to fulfill that best practice.

The wsa:ReferenceParameters element (see Web Services Addressing 1.0 - Core[]) MAY be used as an extension child element of the wsdl20:endpoint or wsdl11:port elements. When present, the value of the [reference parameters] message addressing property for a message sent to an endpoint MUST include the contents of the wsa:ReferenceParameters WSDL extension element.

For backwards compatibility, this section describes which of the core message properties are mandatory or optional for messages in the various MEPs defined by WSDL 1.1.

This section describes which of the core message properties are mandatory or optional for messages in the various MEPs defined by WSDL 2.0 [].