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 XML Infoset []. Specifically, abstract property names always appear in square brackets (e.g., [some property]).

When describing concrete XML information items, 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/> in XML Schema 1.0 for XML 1.0 serialization). The use of @{any} indicates the presence of an attribute wildcard (<xs:anyAttribute/> in XML Schema 1.0 for an XML 1.0 serialization).

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 []).

WS-Addressing is defined in terms of the XML Information Set []. WS-Addressing is conformant to the SOAP 1.2 [] processing model and is also compatible with SOAP 1.1[] for backwards compatibility. WS-Addressing may be used with WSDL [] described services as described in &wsa-wsdl.title;[]. 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 [] &nsuri;. A normative XML Schema [, ] document for XML 1.0 serialization can be obtained by dereferencing the XML namespace URI.

The SOAP 1.2 Addressing 1.0 Feature is named using the following URI:

The SOAP 1.2 Addressing 1.0 Feature provides a SOAP-specific expression of the abstract message addressing properties defined by &wsa-core.title;[].

This feature may be used with any SOAP MEP. A binding that supports this feature MUST provide a means to transmit the properties listed below with a message and to reconstitute their values on receipt of a message.

The SOAP 1.2 Addressing 1.0 Feature defines the following properties:

If the http://www.w3.org/2003/05/soap/features/action/Action property of the SOAP Action feature[] has a value, then the value of the &nsuri;/feature/Action property of the SOAP 1.2 Addressing 1.0 feature MUST be identical to it. Failure to have an identical value results in an Invalid Addressing Header fault (see .

The SOAP 1.2 Addressing 1.0 Module is identified using the following URI:

The SOAP 1.2 Addressing 1.0 Feature (see ) defines a set of SOAP properties and their correspondence to the abstract message addressing properties defined by &wsa-core.title;[]. The SOAP 1.2 Addressing 1.0 Module defines SOAP headers corresponding to the XML Infoset representation of the abstract message addressing properties defined in &wsa-core.title;.

When sending a message each property is represented using the appropriate element information item as a SOAP header block. By default, the resulting header blocks are targeted at the ultimate recipient in the SOAP message path (note that extensions to WS-Addressing could be written to specify different targetting). describes additional processing required when binding message addressing properties to SOAP header blocks.

When receiving a message, the abstract properties are populated from their corresponding element information items in the message. A message MUST NOT contain more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted at a recipient. A recipient MUST generate a wsa:InvalidAddressingHeader (see ) fault if such a message is received.

The SOAP 1.2 Addressing 1.0 Module defines the following additional XML Infoset items:

When a message is to be addressed to an endpoint, the XML Infoset representation of each message addressing property that has been assigned a value is inserted into the message as a SOAP header block subject to the following additional constraints:

The following example shows how the SOAP 1.2 Addressing 1.0 Module is used to construct a message addressed to the endpoint:

The address value is copied in the "To" header block and the "CustomerKey" and "ShoppingCart" elements are copied literally as a header blocks in a SOAP message addressed to this endpoint. The resulting SOAP message would look as follows:

The SOAP 1.1 Addressing 1.0 Extension is identified using the following URI:

The SOAP 1.2 Addressing 1.0 Feature (see ) defines a set of SOAP properties and their correspondence to the abstract message addressing properties defined by &wsa-core.title;[]. The SOAP 1.1 Addressing 1.0 Extension uses the XML Infoset representation of the abstract message addressing properties defined in &wsa-core.title; and binds each element information item to a SOAP header block. The SOAP 1.1 Addressing 1.0 Extension operates as described in with the following exceptions:

The fault properties bind to a SOAP 1.2 fault as follows:

The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only [Subcode], [Reason] and [Detail]. These the properties bind to a SOAP 1.1 fault as follows:

A header representing a WS-Addressing 1.0 Message Addressing Property is invalid and cannot be processed. The validity failure can be either structural or semantic, e.g. a [destination] that is not an IRI or a [relationship] to a [message id] that was never issued.

[Code] a QName representing the value S:Sender

[Subcode] a QName representing the value wsa:InvalidAddressingHeader

[Reason] the string: "A header representing a Message Addressing Property is not valid and the message cannot be processed"

[Detail] a <wsa:InvalidAddressingHeader> element

The following describes the <wsa:InvalidAddressingHeader> element:

A required header representing a Message Addressing Property is absent.

[Code] a QName representing the value S:Sender

[Subcode] a QName representing the value wsa:MessageAddressingHeaderRequired

[Reason] the string: "A required header representing a Message Addressing Property is not present"

[Detail] a <wsa:MessageAddressingHeaderRequired> element

The following describes the <wsa:MessageAddressingHeaderRequired> element:

The endpoint identified by the value of [destination] property cannot be reached.

[Code] a QName representing the value S:Sender

[Subcode] a QName representing the value wsa:DestinationUnreachable

[Reason] the string: "No route can be determined to reach [destination]"

[Detail] (empty)

The [action] property in the message is not supported at this endpoint.

[Code] a QName representing the value S:Sender

[Subcode] a QName representing the value wsa:ActionNotSupported

[Reason] the string: "The [action] cannot be processed at the receiver"

[Detail] a <wsa:ActionNotSupported> element

The following describes the <wsa:ActionNotSupported> element:

The endpoint is unable to process the message at this time either due to some transient issue or a permanent failure.

The endpoint may optionally include a RetryAfter parameter in the detail. The source SHOULD NOT retransmit the message until this duration has passed.

[Code] a QName representing the value S:Receiver

[Subcode] a QName representing the value wsa:EndpointUnavailable

[Reason] the string "The endpoint is unable to process the message at this time"

[Detail] a <wsa:RetryAfter> element

The following describes the <wsa:RetryAfter> element:

To avoid breaking signatures, intermediaries MUST NOT change the XML representation of WS-Addressing headers when relaying those headers. Specifically, intermediaries MUST NOT remove XML content that explicitly indicates otherwise-implied content, and intermediaries MUST NOT insert XML content to make implied values explicit. For instance, if a RelationshipType attribute is present with a value of &nsuri;/reply, an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute, an intermediary MUST NOT add one.