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 .

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 XML Infoset ).

Namespace names of the general form http://example.org/... and http://example.com/... represent application or context-dependent URIs (see RFC 2396 ).

This specification uses the Extended Backus-Naur Form (EBNF) as described in XML 1.0 .

With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 SOAP Features):

The SOAP Request MEP defines a pattern for the exchange of a SOAP message acting as a request optionally followed by a non-SOAP binding specific response. In the absence of failure in the underlying protocol, this MEP consists of one SOAP message and one optional binding specific message:

Abnormal operation during a Request message exchange might be caused by a failure to transfer the request message, a failure at the responding SOAP node to process the request message, or failure to transfer the optional binding-specific response message. Such failures might be silent at either or both of the requesting and recieving SOAP nodes involved, or might result in the generation of a SOAP or binding-specific fault (see ). Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.

The scope of a Request MEP is limited to the exchange of a request message between one requesting and one responding SOAP node and the exchange of an optional binding specific response message. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

The Request MEP defines a set of properties described in .

To initiate a message exchange conforming to the Request MEP, the requesting SOAP node instantiates a local message exchange context. describes how the context is initialized.

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of the http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a base URI value carried in the http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/Role property of the local message exchange context.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. describes the properties that the binding initializes as part of the context's instantiation.

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. and describe these updates for the requesting and the responding SOAP nodes, respectively.

Bindings that implement this MEP MAY provide for streaming of responses. That is, responding SOAP nodes MAY begin transmission of a binding-specific response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:

During the operation of the Request MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the recieiving SOAP node while it is in the Receiving state, the SOAP fault is made available in http://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the Fail state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see ).

The One-way SOAP HTTP binding provides a binding of SOAP to HTTP. The binding conforms to the SOAP Protocol Binding Framework (see SOAP 1.2 Part 1 SOAP Protocol Binding Framework) and supports the message exchange patterns and features described in .

This binding is identified by the URI (see SOAP 1.2 Part 1 SOAP Protocol Binding Framework):

An implementation of the WS-Addressing One-way SOAP HTTP binding MUST support at least ONE of the following message exchange patterns (MEPs):

An implementation of the WS-Addressing One-way SOAP HTTP binding MUST support the following features:

For binding instances conforming to this specification:

The remainder of this section describes the MEP state machine and its relation to the HTTP protocol. In the state tables below, the states are defined as values of the property http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State (see and ), and are of type xs:anyURI. For brevity, relative URIs are used, the base URI being the value of http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role.

The message exchange pattern in use is not indicated in this binding. This information SHOULD be conveyed by a mechanism outside of this binding.

The One-way SOAP HTTP Binding (see ) can be considered as an extension of the HTTP application protocol. As such, all of the security considerations identified and described in section 15 of the HTTP specification apply to the WS-Addressing One-way SOAP HTTP binding in addition to those described in SOAP 1.2 Part 1 Security Considerations. Implementors of the WS-Addressing One-way SOAP HTTP binding should carefully review this material.