sion description), possibly followed by a negotiation. SIP should be used for applications that leverage the user mobility, object delivery, and negotiation provided by SIP. All other applications fall outside of the scope of SIP. If we tried to use SIP to resolve every problem it might solve, the protocol would quickly become huge and complex, which is the opposite of the IETF phi- losophy that created it in all its elegance. The IETF standardization process ensures that SIP is kept simple and manageable. Peer-to-Peer Relationship SIP entities usually have a peer-to-peer relationship. When a server receives a request from a client, it performs some tasks and then returns a response with the result of the request. The client does not continuously send orders to the server telling it how to proceed. Thus, SIP is not really effective in a master/slave architecture where the master has a lot of con- trol over the slave. SIP extensions should not be used to provide such control functionality, which is already provided by more suitable protocols such as H.248 Chapter 6 [RFC3015]. The peer-to-peer relationship between SIP entities, conversely, makes the protocol highly suitable for inter-domain communications. Master/slave protocols have been proven ineffective for inter-domain com- munications, where domain owners typically want to prevent the owner of a different domain from controlling their resources. Independence from Session Type SIP separates session establishment from session description. This separa- tion has to be maintained whenever extensions are added to the core pro- tocol in order to ensure that extensions will be future-proof (that is, in SIP's case, capable of handling any type of session). For example, a new extension should define how SIP interacts with generic Quality of Service (QoS) mech- anisms, but should not define how SIP can be used in conjunction with SDP and ReSerVation Protocol (RSVP) in order to provide QoS. That's not to say that the latter wouldn't be useful in some cases, but in every 