1<s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
 2    (002)   <s:header>
 3    (003)     <wsa:messageid>
 4    (004)       uuid:6B29FC40-CA47-1067-B31D-00DD010662DA
 5    (005)     </wsa:messageid>
 6    (006)     <wsa:replyto>
 7    (007)       <wsa:address>http://business456.example/client1</wsa:address>
 8    (008)     </wsa:replyto>
 9    (009)     <wsa:to>http://fabrikam123.example/Purchasing</wsa:to>
10    (010)     <wsa:action>http://fabrikam123.example/SubmitPO</wsa:action>
11    (011)   </s:header>
12    (012)   <s:body>
13    (013)     ...
14    (014)   </s:body>
15    (015) </s:envelope>

1<xs:any></xs:any>

1<xs:anyattribute></xs:anyattribute>

1<service></service>

  1<wsdl:service> element. We expect solutions built on WSDL/1.1 to continue to utilize a service element. Moving forward we anticipate that endpoint references and WSDL will evolve coherently. The endpoint references may link to service elements in WSDL/1.1, and support additional scenarios in which the WSDL information is not known by a party processing a message. These scenarios may include dynamic messaging or limited capability message processors. 
  2
  3###  2.1 Information Model for Endpoint References 
  4
  5An endpoint reference consists of the following abstract properties: 
  6
  7**[address]** : URI (mandatory)      An address URI that identifies the endpoint. This may be a network address or a logical address.  **[reference properties]** : xs:any (0..unbounded).      A reference may contain a number of individual properties that are required to identify the entity or resource being conveyed. Reference identification properties are element information items that are named by QName and are required to properly dispatch messages to endpoints at the endpoint side of the interaction. Reference properties are provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to consuming applications. The interpretation of these properties (as the use of the endpoint reference in general) is dependent upon the protocol binding and data encoding used to interact with the endpoint. Section 2.3 below defines the default binding for the SOAP protocol. Consuming applications SHOULD assume that endpoints represented by endpoint references with different [reference properties] may accept different sets of messages or follow a different set of policies, and consequently may have different associated metadata (WSDL, XML Schema, and WS-Policy policies ). The relationship between reference properties and endpoint policies is further explained in Section 2.4.  **[reference parameters]** : xs:any (0..unbounded).      A reference may contain a number of individual parameters which are associated with the endpoint to facilitate a particular interaction. Reference parameters are element information items that are named by QName and are required to properly interact with the endpoint. Reference parameters are also provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to consuming applications. The use of reference parameters is dependent upon the protocol binding and data encoding used to interact with the endpoint. Section 2.3 describes the default binding for the SOAP protocol. Unlike [reference properties], the [reference parameters] of two endpoint references may differ without an implication that different XML Schema, WSDL or policies apply to the endpoints.  **[selected port type]** : QName (0..1)      The QName of the primary portType of the endpoint being conveyed.  **[service-port]** : (QName, NCName (0..1)) (0..1)      This is the QName identifying the WSDL service element that contains the definition of the endpoint being conveyed. The service name provides a link to a full description of the service endpoint. An optional non-qualified name identifies the specific port in the service that corresponds to the endpoint.  **[policy]** : wsp:policy (0..unbounded)      A variable number of XML policy elements as described in WS-Policy [ WS-Policy ] describing the behavior, requirements and capabilities of the endpoint. Policies may be included in an endpoint to facilitate easier processing by the consuming application, or because the policy was dynamically generated. However, embedded policies are not authoritative and may be stale or incoherent with the policies associated with the endpoint at the time when the interaction occurs. 
  8
  9###  2.2 Endpoint Reference XML Infoset Representation 
 10
 11This section defines an XML Infoset-based representation for an endpoint reference as both an XML type ( ` wsa:EndpointReferenceType ` ) and as an XML element ( ` <wsa:endpointreference> ` ). 
 12
 13The ` wsa:EndpointReferenceType ` type is used wherever a Web service endpoint is referenced. The following describes the contents of this type: 
 14    
 15    
 16    <wsa:endpointreference>
 17<wsa:address> _xs:anyURI_ </wsa:address>
 18<wsa:referenceproperties> ... </wsa:referenceproperties> ?
 19        <wsa:referenceparameters> ... </wsa:referenceparameters> ?
 20        <wsa:porttype> _xs:QName_ </wsa:porttype> ?
 21        <wsa:servicename ?="" portname=" _xs:NCName_ "> _xs:QName_ </wsa:servicename> ?
 22        <wsp:policy> _..._ </wsp:policy>*
 23    </wsa:endpointreference>
 24    
 25
 26The following describes the attributes and elements listed in the schema overview above: 
 27
 28_/wsa:EndpointReference_      This represents some element of type ` wsa:EndpointReferenceType ` . This example uses the predefined ` <wsa:endpointreference> ` element, but any element of type wsa:EndpointReferenceType may be used.  _/wsa:EndpointReference/wsa:Address_      This REQUIRED element (of type ` xs:anyURI ` ) specifies the [address] property of the endpoint reference. This address may be a logical address or identifier for the service endpoint.  _/wsa:EndpointReference/wsa:ReferenceProperties/_      This OPTIONAL element contains the elements that convey the [reference properties] of the reference.  _/wsa:EndpointReference/wsa:ReferenceProperties/{any}_      Each child element of ReferenceProperties represents an individual [reference property].  _/wsa:EndpointReference/wsa:ReferenceParameters/_      This OPTIONAL element contains the elements that convey the [reference parameters] of the reference.  _/wsa:EndpointReference/wsa:ReferenceParameters/{any}_      Each child element of ReferenceParameters represents an individual [reference parameter].  _/wsa:EndpointReference/wsa:PortType_      This OPTIONAL element (of type ` xs:Qname ` ) specifies the value of the [selected port type] property of the endpoint reference.  _/wsa:EndpointReference/wsa:ServiceName_      This OPTIONAL element (of type ` xs:QName ` ) specifies the ` <wsdl:service> ` definition that contains a WSDL description of the endpoint being referenced.  _/wsa:EndpointReference/wsa:ServiceName/@PortName_      This OPTIONAL attribute (of type ` xs:NCName ` ) specifies the name of the ` <wsdl:port> ` definition that corresponds to the endpoint being referenced.  _/wsa:EndpointReference/wsp:Policy_      This OPTIONAL element specifies a policy that is relevant to the interaction with the endpoint.  _/wsa:EndpointReference/{any}_      This is an extensibility mechanism to allow additional elements to be specified.  _/wsa:EndpointReference/@{any}_      This is an extensibility mechanism to allow additional attributes to be specified. 
 29
 30The following illustrates an endpoint reference. This element references the port of type "fabrikam:InventoryPortType" at the URI "http://www.fabrikam123.example/acct". 
 31    
 32    
 33    <wsa:endpointreference xmlns:fabrikam="..." xmlns:wsa="...">
 34<wsa:address>http://www.fabrikam123.example/acct</wsa:address>
 35<wsa:porttype>fabrikam:InventoryPortType</wsa:porttype>
 36</wsa:endpointreference>
 37
 38###  2.3 Binding Endpoint References 
 39
 40When a message needs to be addressed to the endpoint, the information contained in the endpoint reference is mapped to the message according to a transformation that is dependent on the protocol and data representation used to send the message. Protocol-specific mappings (or bindings) will define how the information in the endpoint reference is copied to message and protocol fields. This specification defines the SOAP binding for endpoint references. This mapping MAY be explicitly replaced by other bindings (defined as WSDL bindings or as policies); however, in the absence of an applicable policy stating that a different mapping must be used, the SOAP binding defined here is assumed to apply. To ensure interoperability with a broad range of devices, all conformant implementations MUST support the SOAP binding. 
 41
 42The SOAP binding for endpoint references is defined by the following two rules: 
 43
 44  * The [address] property in the endpoint reference is copied in the [destination] header field of the SOAP message. 
 45  * Each [reference property] and [reference parameter] element becomes a header block in the SOAP message. The element information item of each [reference property] or [reference parameter] (including all of its [children], [attributes] and [in-scope namespaces]) is to be added as a header block in the new message. 
 46
 47
 48
 49The next example shows how the default SOAP binding for endpoint references is used to construct a message addressed to the endpoint: 
 50    
 51    
 52    <wsa:endpointreference xmlns:fabrikam="..." xmlns:wsa="...">
 53<wsa:address>http://www.fabrikam123.example/acct</wsa:address>
 54<wsa:referenceproperties>
 55<fabrikam:customerkey>123456789</fabrikam:customerkey>
 56</wsa:referenceproperties>
 57<wsa:referenceparameters>
 58<fabrikam:shoppingcart>ABCDEFG</fabrikam:shoppingcart>
 59</wsa:referenceparameters>
 60</wsa:endpointreference>
 61
 62According to the mapping rules stated before, the address value is copied in the "To" header and the "CustomerKey" element should be copied literally as a header in a SOAP message addressed to this endpoint. The SOAP message would look as follows: 
 63    
 64    
 65    <s:envelope xmlns:fabrikam="... " xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="...">
 66<s:header>
 67         ...
 68         <wsa:to>http://www.fabrikam123.example/acct</wsa:to>
 69<fabrikam:customerkey>123456789</fabrikam:customerkey>
 70<fabrikam:shoppingcart>ABCDEFG</fabrikam:shoppingcart>
 71         ...
 72       </s:header>
 73<s:body>
 74         ...
 75       </s:body>
 76</s:envelope>
 77
 78###  2.4 Endpoint Reference Comparison 
 79
 80During the course of Web services interactions applications may receive multiple endpoint references describing the endpoints it needs to interact with. Different copies of an endpoint reference may also be received over time. 
 81
 82The following rules clarify the relation between the behaviors of the endpoints represented by two endpoint references with the same [address] and the same [reference properties]. 
 83
 84  * The two endpoints accept the same sets of messages, and follow and require the same set of policies. That is, the XML Schema, WSDL, and WS-Policy metadata applicable to the two references are the same. 
 85  * In particular, the policies applicable to the two endpoints are the same regardless of the values of the embedded [policy]. Embedded policies are not authoritative and may be stale or incoherent with the policies associated with the endpoint. 
 86
 87
 88
 89The [address] properties of two endpoint references are compared according to Section 6 of [ RFC 2396 ]. The [reference properties] of two endpoint references are equal if: 
 90
 91  * they contain the same number of individual properties; 
 92  * for each reference property in one endpoint reference there exists an equivalent reference property in the other. One [reference property] is equivalent to another [reference property] if their byte streams per Exclusive XML Canonicalization are equal. 
 93
 94
 95
 96Therefore, a consuming application should assume that different XML Schemas, WSDL definitions and policies apply to endpoint references whose address or reference properties differ. 
 97
 98##  3\. Message Information Headers 
 99
100This section defines the model and syntax of a message information header. 
101
102The message information headers collectively augment a message with the following abstract properties. These properties enable the identification and location of the endpoints involved in an interaction. The basic interaction pattern from which all others are composed is "one way". In this pattern a source sends a message to a destination without any further definition of the interaction. 
103
104"Request Reply" is a common interaction pattern that consists of an initial message sent by a source endpoint (the request) and a subsequent message sent from the destination of the request back to the source (the reply). A reply can be either an application message, a fault, or any other message. 
105
106The properties below support one way, request reply, and any other interaction pattern: 
107
108**[destination]** : URI (mandatory)      The address of the intended receiver of this message.  **[source endpoint]** : endpoint reference (0..1)      Reference of the endpoint where the message originated from.  **[reply endpoint]** : endpoint reference (0..1)      An endpoint reference that identifies the intended receiver for replies to this message. If a reply is expected, a message MUST contain a [reply endpoint]. The sender MUST use the contents of the [reply endpoint] to formulate the reply message as defined in Section 3.2. If the [reply endpoint] is absent, the contents of the [source endpoint] may be used to formulate a message to the source. This property MAY be absent if the message has no meaningful reply. If this property is present, the [message id] property is REQUIRED.  **[fault endpoint]** : endpoint reference (0..1)      An endpoint reference that identifies the intended receiver for faults related to this message. When formulating a fault message as defined in Section 3.2 and 4, the sender MUST use the contents of the [fault endpoint] of the message being replied to to formulate the fault message. If the [fault endpoint] is absent, the sender MAY use the contents of the [reply endpoint] to formulate the fault message. If both the [fault endpoint] and [reply endpoint] are absent, the sender MAY use the contents of the [source endpoint] to formulate the fault message. This property may be absent if the sender cannot receive fault messages (e.g., is a one-way application message). If this property is present, the [message id] property is REQUIRED.  **[action]** : URI (mandatory)      An identifier that uniquely (and opaquely) identifies the semantics implied by this message. 
109
110It is RECOMMENDED that value of the [action] property is a URI identifying an input, output, or fault message within a WSDL port type. An action may be explicitly or implicitly associated with the corresponding WSDL definition. Section 3.3 below describes the mechanisms of association. Finally, if in addition to the [action] property, a SOAP Action URI is encoded in a request, the URI of the SOAP Action MUST be the same as the one specified by the [action] property. 
111
112**[message id]** : URI (0..1)      A URI that uniquely identifies this message in time and space. No two messages with a distinct application intent may share a [message id] property. A message MAY be retransmitted for any purpose including communications failure and MAY use the same [message id] property. The value of this property is an opaque URI whose interpretation beyond equivalence is not defined in this specification. If a reply is expected, this property MUST be present.  **[relationship]** : (QName, URI) (0..unbounded)      A pair of values that indicate how this message relates to another message. The type of the relationship is identified by a QName. The related message is identified by a URI that corresponds to the related message's [message id] property. The message identifier URI may refer to a specific message, or be the following well-known URI that means "unspecified message:" 
113    
114    
115    http://schemas.xmlsoap.org/ws/2004/08/addressing/id/unspecified
116
117&gt; This specification has one predefined relationship type: 
118
119&gt; **QName**
120
121| 
122
123&gt; **Description**  
124  
125---|---  
126  
127&gt; wsa:Reply 
128
129| 
130
131&gt; Indicates that this is a reply to the message identified by the URI.   
132  
133&gt; A reply message MUST contain a [relationship] property consisting of wsa:Reply and the message id property of the request message. 
134
135The dispatching of incoming messages is based on two message properties. The mandatory "destination" and "action" fields identify the target processing location and the verb or intent of the message. 
136
137Due to the range of network technologies currently in wide-spread use (e.g., NAT, DHCP, firewalls), many deployments cannot assign a meaningful global URI to a given endpoint. To allow these "anonymous" endpoints to initiate message exchange patterns and receive replies, WS-Addressing defines the following well-known URI for use by endpoints that cannot have a stable, resolvable URI. 
138    
139    
140    http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
141
142Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this address MUST provide some out-of-band mechanism for delivering replies or faults (e.g. returning the reply on the same transport connection). This mechanism may be a simple request/reply transport protocol (e.g., HTTP GET or POST). This URI MAY be used as the [destination] for reply messages and SHOULD NOT be used as the [destination] in other circumstances. 
143
144###  3.1 Message Information Headers XML Infoset Representation 
145
146The message information header blocks provide end-to-end characteristics of a message that can be easily secured as a unit. The information in these headers is immutable and not intended to be modified along the message path. 
147
148The following describes the contents of the message information header blocks: 
149    
150    
151      <wsa:messageid> xs: _anyURI_ </wsa:messageid>
152<wsa:relatesto ?="" relationshiptype="..."> _xs:anyURI_ </wsa:relatesto>
153<wsa:to> _xs:anyURI_ </wsa:to>
154<wsa:action> _xs:anyURI_ </wsa:action>
155<wsa:from> _endpoint-reference_ </wsa:from>
156<wsa:replyto> _endpoint-reference_ </wsa:replyto>
157<wsa:faultto> _endpoint-reference_ </wsa:faultto>
158    
159
160The following describes the attributes and elements listed in the schema overview above: 
161
162_/wsa:MessageID_      This OPTIONAL element (of type ` xs:anyURI ` ) conveys the [message id] property. This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present.  _/wsa:RelatesTo_      This OPTIONAL (repeating) element information item contributes one abstract [relationship] property value, in the form of a (URI, QName) pair. The [children] property of this element (which is of type ` xs:anyURI ` ) conveys the [message id] of the related message. This element MUST be present if the message is a reply.  _/wsa:RelatesTo/@RelationshipType_      This OPTIONAL attribute (of type ` xs:QName ` ) conveys the relationship type as a QName. When absent, the implied value of this attribute is wsa:Reply.  _/wsa:ReplyTo_      This OPTIONAL element (of type ` wsa:EndpointReferenceType ` ) provides the value for the [reply endpoint] property. This element MUST be present if a reply is expected. If this element is present, wsa:MessageID MUST be present.  _/wsa:From_      This OPTIONAL element (of type ` wsa:EndpointReferenceType ` ) provides the value for the [source endpoint] property.  _/wsa:FaultTo_      This OPTIONAL element (of type ` wsa:EndpointReferenceType ` ) provides the value for the [fault endpoint] property. If this element is present, wsa:MessageID MUST be present.  _/wsa:To_      This REQUIRED element (of type ` xs:anyURI ` ) provides the value for the [destination] property.  _/wsa:Action_      This REQUIRED element of type ` xs:anyURI ` conveys the [action] property. The [children] of this element convey the value of this property. 
163
164###  3.2 Formulating a Reply Message 
165
166The reply to a WS-Addressing compliant request message MUST be compliant to WS-Addressing and be constructed according to the rules defined in this section. 
167
168The following example illustrates a request message using message information header blocks in a SOAP 1.2 message: 
169    
170    
171    <s:envelope xmlns:f123="http://www.fabrikam123.example/svc53" xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
172<s:header>
173<wsa:messageid>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
174        </wsa:messageid>
175<wsa:replyto>
176<wsa:address>http://business456.example/client1</wsa:address>
177</wsa:replyto>
178<wsa:to s:mustunderstand="1">mailto:joe@fabrikam123.example</wsa:to>
179<wsa:action>http://fabrikam123.example/mail/Delete</wsa:action>
180</s:header>
181<s:body>
182<f123:delete>
183<maxcount>42</maxcount>
184</f123:delete>
185</s:body>
186</s:envelope>
187
188This message would have the following property values: 
189
190&gt; **[destination]** The URI mailto:joe@fabrikam123.example 
191
192&gt; **[reply endpoint]** The endpoint with [address] http://business456.example/client1 
193
194&gt; **[action]** http://fabrikam123.example/mail/Delete 
195
196&gt; **[message id]** uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff 
197
198The following example illustrates a reply message using message information header blocks in a SOAP 1.2 message: 
199    
200    
201    <s:envelope xmlns:f123="http://www.fabrikam123.example/svc53" xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
202<s:header>
203<wsa:messageid>
204           uuid:aaaabbbb-cccc-dddd-eeee-wwwwwwwwwww
205        </wsa:messageid>
206<wsa:relatesto>
207           uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
208        </wsa:relatesto>
209<wsa:to s:mustunderstand="1">
210           http://business456.example/client1
211        </wsa:to>
212<wsa:action>http://fabrikam123.example/mail/DeleteAck</wsa:action>
213</s:header>
214<s:body>
215<f123:deleteack></f123:deleteack>
216</s:body>
217</s:envelope>
218
219This message would have the following property values: 
220
221&gt; **[destination]** http://business456.example/client1 
222
223&gt; **[action]** http://fabrikam123.example/mail/DeleteAck 
224
225&gt; **[message id]** uuid:aaaabbbb-cccc-dddd-eeee-wwwwwwwww 
226
227&gt; **[relationship]** (wsa:Reply, uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff) 
228
229###  3.3 Associating Action with WSDL Operations 
230
231WS-Addressing defines two mechanisms to associate an action with input, output and fault elements within a WSDL port type. 
232
233####  3.3.1 Explicit Association 
234
235The action may be explicitly associated using the wsa:Action attribute or in the absence of the attribute the action is defined by the rule in section 3.3.2. 
236
237For example consider the following WSDL excerpt: 
238    
239    
240    <definitions ...="" targetnamespace="http://andsky.com/stockquote">
241      ...
242      <porttype name="StockQuotePortType">
243<operation name="GetLastTradePrice">
244<input **="" **wsa:action="http://andsky.com/GetQuote" message="tns:GetTradePricesInput"/>
245<output **="" **wsa:action="http://andsky.com/Quote" message="tns:GetTradePricesOutput"></output>
246</operation>
247</porttype>
248      ...
249    </definitions>
250
251The action for the input of the ` GetLastTradePrice ` operation within the ` StockQuotePortType ` is explicitly defined to be ` http://andsky.com/GetQuote ` . The action for the output of this same operation is ` http://andsky.com/Quote ` . 
252
253####  3.3.2 Default Action Pattern 
254
255In the absence of the ` wsa:Action ` attribute, the following pattern is used to construct a default action for inputs and outputs. The general form of an action URI is as follows: 
256    
257    
258    [target namespace]/[port type name]/[input|output name]
259
260The "/" is a literal character to be included in the action. The values of the properties are as defined below. 
261
262[target namespace] is the target namespace (/definition/@targetNamespace). If [target namespace] ends with a "/" an additional "/" is not added. 
263
264[port type name] is the name of the port type (/definition/portType/@name). 
265
266[input|output name] is the name of the element as defined in Section 2.4.5 of WSDL 1.1. 
267
268For fault messages, this pattern is not applied. Instead, the following URI is the default action URI for fault messages: 
269    
270    
271    http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
272
273For example consider the following WSDL excerpt: 
274    
275    
276    <definitions ...="" targetnamespace="http://andsky.com/stockquote">
277      ...
278      <porttype name="StockQuotePortType">
279<operation name="GetLastTradePrice">
280<input message="tns:GetTradePricesInput" name="GetQuote"/>
281<output message="tns:GetTradePricesOutput" name="Quote"></output>
282</operation>
283</porttype>
284      ...
285    </definitions>
286
287&gt; **[targetNamespace]** = http://andsky.com/stockquote 
288
289&gt; **[port type name]** = StockQuotePortType 
290
291&gt; **[input name]** = GetQuote 
292
293&gt; **[output name]** = Quote 
294
295Applying the pattern above with these values we have: 
296
297&gt; input action = http://andsky.com/stockquote/StockQuotePortType/GetQuote 
298
299&gt; output action = http://andsky.com/stockquote/StockQuotePortType/Quote 
300
301WSDL defines rules for a default input or output name if the name attribute is not present. Consider the following example: 
302
303For example consider the following WSDL excerpt: 
304    
305    
306    <definitions ...="" targetnamespace="http://andsky.com/stockquote">
307      ...
308      <porttype name="StockQuotePortType">
309<operation name="GetLastTradePrice">
310<input message="tns:GetTradePricesInput"/>
311<output message="tns:GetTradePricesOutput"></output>
312</operation>
313</porttype>
314      ...
315    </definitions>
316
317&gt; **[targetNamespace]** = http://andsky.com/stockquote 
318
319&gt; **[port type name]** = StockQuotePortType 
320
321According to the rules defined in WSDL 2.4.5, if the name attribute is absent for the input of a request response operation the default value is the name of the operation "Request" appended. 
322
323&gt; **[input name]** = GetLastTradePriceRequest 
324
325Likewise, the output defaults to the operation name with "Response" appended. 
326
327&gt; **[output name]** = GetLastTradePriceResponse 
328
329Applying the pattern above with these values we have: 
330
331&gt; input action = 
332
333http://andsky.com/stockquote/StockQuotePortType/GetLastTradePriceRequest 
334
335&gt; output action = 
336
337http://andsky.com/stockquote/StockQuotePortType/GetLastTradePriceResponse 
338
339##  4\. Faults 
340
341The faults defined in this section are generated if the condition stated in the preamble in each subsection is met. They are sent to the [fault endpoint], if present and valid. Otherwise they are sent to the [reply endpoint] if present. If neither is present faults may be sent to the [source endpoint]. 
342
343Endpoints compliant with this specification MUST include required message information headers on all fault messages. Fault messages are correlated as replies using the [relationship] property as defined in Section 3. The [action] property below designates WS-Addressing fault messages (this URI is also used as default Action value for WSDL fault messages, as described in Section 3.3.2): 
344    
345    
346    http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
347
348The definitions of faults use the following properties: 
349
350&gt; **[Code]** The fault code. 
351
352&gt; **[Subcode]** The fault subcode. 
353
354&gt; **[Reason]** The English language reason element. 
355
356&gt; **[Detail]** The detail element. If absent, no detail element is defined for the fault. 
357
358The properties above bind to a SOAP 1.2 fault as follows: 
359    
360    
361    <s:envelope>
362<s:header>
363<wsa:action>
364          http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
365       </wsa:action>
366<!-- Headers elided for clarity.  -->
367</s:header>
368<s:body>
369<s:fault>
370<s:code>
371<s:value> **[Code]** </s:value>
372<s:subcode>
373<s:value> **[Subcode]** </s:value>
374</s:subcode>
375</s:code>
376<s:reason>
377<s:text xml:lang="en"> **[Reason]** </s:text>
378</s:reason>
379<s:detail>
380         **[Detail]**
381       </s:detail>
382</s:fault>
383</s:body>
384</s:envelope>
385
386The SOAP 1.1 fault is less expressive and map only [Subcode] and [Reason]. These the properties bind to a SOAP 1.1 fault as follows: 
387    
388    
389    <s11:envelope>
390<s11:body>
391<s11:fault>
392<faultcode> **[Subcode]** </faultcode>
393<faultstring xml:lang="en"> **[Reason]** </faultstring>
394</s11:fault>
395</s11:body>
396</s11:envelope>
397
398###  4.1 Invalid Message Information Header 
399
400A message information header cannot be processed. 
401
402&gt; **[Code]** S:Sender 
403
404&gt; **[Subcode]** wsa:InvalidMessageInformationHeader 
405
406&gt; **[Reason]** A message information header is not valid and the message cannot be processed. The validity failure can be either structural or semantic, e.g. a [destination] that is not a URI or a [relationship] to a [message id] that was never issued. 
407
408&gt; **[Detail]** [invalid header] 
409
410###  4.2 Message Information Header Required 
411
412A required message information header is absent. 
413
414&gt; **[Code]** S:Sender 
415
416&gt; **[Subcode]** wsa:MessageInformationHeaderRequired 
417
418&gt; **[Reason]** A required message information header, To, MessageID, or Action, is not present. 
419
420&gt; **[Detail]** [Missing Header QName] 
421
422###  4.3 Destination Unreachable 
423
424The no endpoint can be found capable of acting in the role of the [destination] property. 
425
426&gt; **[Code]** S:Sender 
427
428&gt; **[Subcode]** wsa:DestinationUnreachable 
429
430&gt; **[Reason]** No route can be determined to reach the destination role defined by the WS-Addressing To. 
431
432&gt; **[Detail]** empty 
433
434###  4.4 Action Not Supported 
435
436The [action] property in the message is not supported at this endpoint. 
437
438The contents of this fault are as follows: 
439
440&gt; **[Code]** S:Sender 
441
442&gt; **[Subcode]** wsa:ActionNotSupported 
443
444&gt; **[Reason]** The [action] cannot be processed at the receiver. 
445
446&gt; **[Detail]** [action] 
447
448###  4.5 Endpoint Unavailable 
449
450The endpoint is unable to process the message at this time either due to some transient issue or a permanent failure. 
451
452The endpoint may optionally include a RetryAfter parameter in the detail. The source should not retransmit the message until this duration has passed. 
453
454&gt; **[Code]** S:Receiver 
455
456&gt; **[Subcode]** wsa:EndpointUnavailable 
457
458&gt; **[Reason]** The endpoint is unable to process the message at this time. 
459
460&gt; **[Detail]**
461    
462    
463    <wsa:retryafter ...="">[xs:NonNegativeInteger]</wsa:retryafter>
464
465The following describes the attributes and elements listed above: 
466
467/wsa:RetryAfter      This element (of type ` xs:NonNegativeInteger ` ) is a suggested minimum duration in milliseconds to wait before retransmitting the message. If this element is omitted from the detail, the value is infinite.  /wsa:RetryAfter/@{any}      These optional extensibility attributes do not affect processing. 
468
469##  5\. Security Considerations 
470
471It is strongly recommended that the communication between services be secured using the mechanisms described in WS-Security [ WS-Security ]. In order to properly secure messages, the body and all relevant headers need to be included in the signature. Specifically, the message information headers described in this specification (e.g. <wsa:to>) need to be signed with the body in order to "bind" the two together. It should be noted that for messages traveling through intermediaries, it is possible that some or all of the message information headers may have multiple signatures when the message arrives at the ultimate receiver. It is strongly recommended that the initial sender include a signature to prevent any spoofing by intermediaries. 
472
473Whenever an address is specified (e.g. <wsa:from>, <wsa:replyto>, <wsa:faultto>, ...), the processor should ensure that a signature is provided with claims allowing it to speak for the specified target in order to prevent certain classes of attacks (e.g. redirects). As well, care should be taken if the specified endpoint contains resource properties or parameters as unverified endpoint references could cause certain classes of header insertion attacks. 
474
475The message information headers blocks may have their contents encrypted in order to obtain end-to-end privacy, but care should be taken to ensure that intermediary processors have access to required information (e.g. <wsa:to>). 
476
477Some processors may use message identifiers (<wsa:messageid>) as part of a uniqueness metric in order to detect replays of messages. Care should be taken to ensure that a unique identifier is actually used. For example, it may be appropriate in some scenarios to combine the message identifier with a timestamp. 
478
479The following list summarizes common classes of attacks that apply to this protocol and identifies the mechanism to prevent/mitigate the attacks: 
480
481  * Message alteration – Alteration is prevented by including signatures of the message information using WS-Security. 
482  * Message disclosure – Confidentiality is preserved by encrypting sensitive data using WS-Security. 
483  * Address spoofing – Address spoofing is prevented by ensuring that all address are signed by a party authorized to speak for (or on behalf of) the address. 
484  * Key integrity – Key integrity is maintained by using the strongest algorithms possible (by comparing secured policies – see WS-Policy [ WS-Policy ] and WS-SecurityPolicy [ WS-SecurityPolicy ]). 
485  * Authentication – Authentication is established using the mechanisms described in WS-Security and WS-Trust [ WS-Trust ]. Each message is authenticated using the mechanisms described in WS-Security. 
486  * Accountability – Accountability is a function of the type of and strength of the key and algorithms being used. In many cases, a strong symmetric key provides sufficient accountability. However, in some environments, strong PKI signatures are required. 
487  * Availability – All reliable messaging services are subject to a variety of availability attacks. Replay detection is a common attack and it is recommended that this be addressed by the mechanisms described in WS-Security and/or caching of message identifiers. Other attacks, such as network-level denial of service attacks are harder to avoid and are outside the scope of this specification. That said, care should be taken to ensure that minimal state is saved prior to any authenticating sequences. 
488  * Replay **** – Messages may be replayed for a variety of reasons. To detect and eliminate this attack, mechanisms should be used to identify replayed messages such as the timestamp/nonce outlined in WS-Security. Alternatively, and optionally, other technologies, such as sequencing, can also be used to prevent replay of application messages. 
489
490
491
492##  6\. Acknowledgements 
493
494Keith Ballinger, Microsoft; Michael Coulson, Microsoft; Giovanni Della-Libera, Microsoft; Christopher Ferris, IBM; Tom Freund, IBM; Steve Graham, IBM; Christoph Hofmann, SAP; Maryann Hondo, IBM; Efim Hudis, Microsoft; John Ibbotson, IBM; Gopal Kakivaya, Microsoft; Al Lee, Microsoft; Anthony Nadalin, IBM; Bill Nagy, IBM; Martin Nally, IBM; Henrik Frystyk Nielsen, Microsoft; Jeffrey Schlimmer, Microsoft; Vladimir Savchenko, SAP; Chris Sharp, IBM; Keith Stobie, Microsoft; Vladimir Videlov, SAP; Volker Wiechers, SAP; Hervey Wilson, Microsoft; 
495
496##  7\. References 
497
498**[ RFC 2119]**      S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119 , Harvard University, March 1997.  **[RFC 2396]**      T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax," RFC 2396bis , W3C/MIT, July 2004.  **[XML 1.0]**      W3C Recommendation " Extensible Markup Language (XML) 1.0 (Second Edition) ", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000  **[XML Namespaces]**      W3C Recommendation " Namespaces in XML ", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999  **[XML Infoset]**      W3C Recommendation " XML Information Set ", John Cowan, Richard Tobin, 24 October 2001  **[ XML Schema, Part 1]**      H. Thompson, et al, " XML Schema Part 1: Structures ," May 2001.  **[ XML Schema, Part 2]**      P. Biron, et al, " XML Schema Part 2: Datatypes ," May 2001.  **[SOAP 1.2]**      M. Gudgin, et al, " SOAP Version 1.2 Part 1: Messaging Framework ," June 2003.  **[ WSDL 1.1]**      E. Christensen, et al, " Web Services Description Language (WSDL) 1.1 ," March 2001.  **[ WS-Security]**      OASIS, " Web Services Security: SOAP Message Security ", March 2004.  **[ WS-SecurityPolicy]**      G. Della-Libera, et al, " Web Services Security Policy Language (WS-SecurityPolicy) ," December 2002.  **[ WS-Trust]**      S. Anderson, et al, " Web Services Trust Language (WS-Trust) ," May 2004.  **[WS-Policy]**      D. Box, et al, " Web Services Policy Framework (WS-Policy) ," May 2003.</wsa:messageid></wsa:to></wsa:faultto></wsa:replyto></wsa:from></wsa:to></wsdl:port></wsdl:service></wsa:endpointreference></wsa:endpointreference></wsdl:service>