 that reason, it is recommended that TCP should be used as a transport protocol when S/MIME tunneling is employed [18]. 22.3.4.2.3.1 SIP URIs Using TLS on all segments of a request path requires that the terminating UAS must be reachable over TLS (perhaps registering with a SIP URI as a contact address) [20]. This is the preferred use of SIP. Much valid architecture, however, use TLS to secure part of the request path, but rely on a different mechanism for the final hop to a UAS. Thus SIP cannot guarantee that using TLS will be truly end-to-end. In essence since many UAs will not accept incoming TLS connections, therefore even those UAs which do support TLS may be required to maintain persistent TLS connections. Ensuring that TLS is used for all of the request segments up to the tar- get domain is complex. The possibility that noncompliant cryptographically authenticated proxy servers along the route that are compromized, may choose to disregard the forwarding rules associated with SIP. Hence malicious inter- mediaries could, for example, retarget a request from a SIP URI to a different SIP URI in an attempt to downgrade security. Alternatively, an intermediary might legitimately retarget a request from a SIP to a SIP URI. Recipients of a request whose Request-URI uses the SIP URI scheme thus cannot assume on the basis of the Request-URI alone that SIP was used for the entire request path (from the client onwards) [20]. To address these concerns, it is recommended that recipients of a request whose Request-URI contains a SIP or SIP URI inspect the 'To' header field value to see if it contains a SIP URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the 'To' header field). Although clients may choose to populate the Request-URI and 'To' header field of a request differently, when SIP is used this disparity could be interpreted as a possible security violation, and the request could consequently be rejected by its recipient. Recipien