Guaranteed Hops, Guaranteed Routes

Guaranteed Hops
While travelling down a route, a SOAP message may use several different underlying "Guaranteed Hop Protocols", that is, protocols that either succeed or fail in moving a message from one node to another via a single hop. Examples of Guaranteed Hop Protocols include HTTP and SMTP. Now, neither of these protocols are considered reliable in that that they don't keep re-trying until the message is successfully transferred. Rather, the guarantee isn't to succeed, the guarantee is to to tell you which one happened (success or failure). Also note that the emphasis is on moving the message forward a single hop rather than the entire route. In Web Services, WS-Routing is used to faciliate moving the message the entire route, while Hop Protocols (usually guaranteed) are used to move from one node to another.

Guaranteed Routes
If I have a multi-hop route and all hops have the ability to provide a guaranteed hop, can the requesting client be granted a guaranteed route?
Answer: No. A SOAP router is a stateless device that does not predefine a message path or create a virtual circuit. Thus, the initiator is not aware of the level of guarantees or reliability of the SOAP routers in the path. Thus, the fact that all the routers in the path have the ability to provide guarantees does not give the initiator any guarantee. In addition, the WS-Routing specification clearly states that the return of a fault is optional in section 5.2:
If there is a reverse message path present in the faulty WS-Routing message then the WS-Routing fault SHOULD be returned to the initial WS-Routing sender. If the message path is not bidirectional then the fault message SHOULD be discarded.

The key here is the use of the IETF "SHOULD" - meaning, "No, the route is not guaranteed. However, if you and all the routers along the path implement faulting AND you specify a return path, a guarantee can be expected."

Side Note: I can't figure out why they didn't upgrade the SHOULD to a MUST... one reason might be on the lingering questions around non-guaranteed hop protocol bindings - as stated in section 7.2, "Editor Note The UDP binding described in this section is preliminary and is likely to change before requesting a well-known port from IANA."