case, the generic mechanism would be defined as a SIP extension and the concrete application of the generic mechanism to SDP and RSVP would be described in an informational document only. It's important to keep this in mind because although SIP can be used to establish all types of sessions, SIP development to date has been quite focused on Voice over IP (VoIP) applications. This kind of focus is not unusual in developing protocols, but we have to guard against the natural tendency to design extensions that will be applicable only in a VoIP context. Presently, SIP extensions are general enough to cover different types of ses- sions, even if their current use is a VoIP service. Do Not Change Method Semantics The purpose of a SIP request is defined by its method (for example, a BYE request is intended to terminate a session). Thus, it is possible to know the purpose of a request at first glance by inspecting its method. Headers and parameters give more information about the request, but the general pur- pose of the request is not changed by the contents of any header. This design rule remains when new SIP extensions are planned. Let us look at an example of an extension that would not be accepted by the IETF. The following extension breaks the rule of identifying the purpose of request by its method and therefore would be a bad idea. Extending SIP: The SIP Toolkit One might define a header called Real-Purpose to be carried in INVITE requests as follows: Real-Purpose: Tell me your capabilities An INVITE with this header would be used to query a remote system about its capabilities rather than to establish a session. However, the purpose of INVITE is not to query about capabilities. If a system wants to query about capabilities, it should use the OPTIONS method, which is defined specifically for that purpose. Therefore, whenever a request with a new functionality is needed, the SIP community creates a new method. They do not try to change the semantics of an existing one. Extensions to SIP We have already seen which 