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 can 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/05/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 "ghns:reservationInterface" at the endpoint IRI "http://greath.example.com/2004/reservation". 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 can 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 can 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 can extend the semantics of the endpoint's WSDL binding.

WS-Addressing defines a wsaw:Anonymous element that is only used in conjunction with wsaw:UsingAddressing (or its equivalent wsoap:module, see section ) 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.

A WSDL or policy based service description that includes the wsaw:UsingAddressing but no wsaw:Anonymous marker makes no assertion regarding a requirement or a constraint in the use of the anonymous URI in EPRs contained in messages sent to the endpoint. In this cases, endpoint service descriptions have to rely on additional metadata, such as WSDL bindings or additional policy assertions, to indicate any requirements or restrictions on the use of the anonymous URI by clients. However, in the absence of additional metadata, clients of the endpoint MAY assume that the service endpoint follows the behavior indicated by the 'optional' value of the wsaw:Anonymous marker. An endpoint SHOULD send a wsa:OnlyAnonymousAddressSupported or a wsa:OnlyNonAnonymousAddressSupported fault back to the client if a message received includes a response epr with an [address] that is unsupported by the endpoint.

The wsaw:Anonymous element, if present, MUST have one of 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, a SOAP Module component can be used to declare the use of the WS-Addressing 1.0 Module for the SOAP binding. The meaning of the use of such a SOAP Module component is semantically equivalent to the {addressing} property defined in section . Note that this module is only meaningful when used on WSDL components where the {addressing} property is allowed, i.e. as a member of the {soap modules} property of a Binding component.

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

A wsdl20:endpoint or wsdl11:port element MAY be extended using a child wsa:EndpointReference element. When extended this way, the [address] property of the child EPR MUST match the {address} property of the endpoint component (WSDL 2.0) or the address value provided by the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1 port described using WSDL 1.1, the location attribute of a soap11:address element (if present) would have the same value as the wsa:Address child element of the wsa:EndpointReference element.

The value of the [destination] message addressing property for a message sent to an endpoint typically matches the value of the {address} property of the endpoint component (WSDL 2.0) or the address value (if any) 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. For an endpoint or port extended with an EPR (see ), the value is provided by the [address] property of the EPR.

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.

When a wsa:EndpointReference element is present in a wsdl20:endpoint or a wsdl11:port element (see ), the value of the [reference parameters] message addressing property for a message sent to an endpoint MUST include the contents of the wsa:ReferenceParameters element, if one exists within that EPR.

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.

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

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