This text is the proposed revised replacement text for the 2nd last paragraph in part 1, section 2.6 which reads as follows:
If the SOAP node is a SOAP intermediary, the SOAP message pattern and
results of processing (e.g. no fault generated) MAY require that the SOAP
message be sent further along the SOAP message path. Such relayed SOAP
messages MUST contain all SOAP header blocks and the SOAP body from the
original SOAP message, in the original order, except that SOAP header
blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks
are removed regardless of whether they were processed or ignored).
Additional SOAP header blocks MAY be inserted at any point in the SOAP
message, and such inserted SOAP header blocks MAY be indistinguishable from
one or more just removed (effectively leaving them in place, but
emphasizing the need to reinterpret at each SOAP node along the SOAP
message path.)
The text builds on the proposed wording for resolving issue 137 by Noah and Henrik and discussion at the W3C f2f meeting in Cannes.
The idea here is to cast relaying as a feature - it builds on section 2.
As mentioned earlier in this section, SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see section 5 and 6). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.
The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary.
SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two type of intermediary are described below.
Forwarding intermediaries process the message according to the SOAP processing model defined in section 2.6. SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding (such SOAP blocks are removed regardless of whether they were processed or ignored).
It is the responsibility of the feature defining the SOAP forwarding to describe the required semantics including rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)
In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. I.e. they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing.
The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encryped some or all of the blocks found in the inbound message.
It is STRONGLY RECOMMENDED that features provided by active intermediaries be described in a manner that allows such modifications to be detected by the affected SOAP nodes. For example, an active intermediary may describe the processing performed by inserting header blocks into the outbound SOAP message that inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. The semantics of such inserted headers should also call for either the same or other headers to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with headers removed for encryption passes through a second intermediary (without the original headers being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.