Internet Engineering Task Force SIP WG Internet Draft J. Rosenberg dynamicsoft H. Schulzrinne Columbia U.
draft-ietf-sip-guidelines-05.txt June 6,draft-ietf-sip-guidelines-06.txt November 4, 2002 Expires: December 2002May 2003 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP(SIP) STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. Table of Contents 1 Terminology ......................................... 3 2 Introduction ........................................ 3 3 Should I define a SIP Extension? ................... 3 3.1 SIP's Solution Space ................................ 4 3.2 SIP Architectural Model ............................. 6 4 Issues to be Addressed .............................. 8 4.1 Backwards Compatibility ............................. 8 4.2 Security ............................................ 10 4.3 Usage Guidelines ....................................Terminology ......................................... 10 4.4 Syntactic Issues .................................... 1011 4.5 Semantics, Semantics, Semantics ..................... 1213 4.6 Examples Section .................................... 1314 4.7 Overview Section .................................... 1314 4.8 IANA Considerations Section ......................... 15 4.9 Document Naming Conventions ......................... 13 4.915 4.10 Additional Considerations for New Methods ........... 14 4.1016 4.11 Additional Considerations for New HeadersHeader Fields or Header Field Parameters .............................................. 15 4.11........................................ 17 4.12 Additional Considerations for New Body Types ........ 1517 5 Interactions with SIP Features ...................... 1618 6 Security Considerations ............................. 1618 7 IANA Considerations ................................. 1619 8 Acknowledgements .................................... 19 9 Authors Addresses ................................... 17 919 10 Normative References ................................ 17 1019 11 Informative References .............................. 1720 1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119  and indicate requirement levels for compliant SIP guidelinesimplementations. 2 Introduction The Session Initiation Protocol (SIP)  is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended (with new methods, new headers,header fields, new body types, and new parameters), and there have been countless proposals that have been made to do just that. An IETF process has been put into place which defines how extensions are to be made to the SIP protocol .. That process is designed to ensure that extensions are made which are appropriate for SIP (as opposed to being done in some other protocol), that these extensions fit within the model and framework provided by SIP and are consistent with its operation, and that these extensions solve problems generically rather than for a specific use case. However,  does not provide the technical guidelines needed to assist that process. This draftspecification helps to meet that need. This draftspecification first provides a set of guidelines to help decide whether a certain piece of functionality is appropriately done in SIP. Assuming the functionality is appropriate, it then points out issues which extensions should deal with from within their specification. Finally, it discusses common interactions with existing SIP features which often cause difficulties in extensions. 3 Should I define a SIP Extension? The first question to be addressed when defining a SIP extension is: is a SIP extension the best solution to my problem? SIP has been proposed as a solution for numerous problems, including mobility, configuration and management, QoS control, call control, caller preferences, device control, third party call control, and MPLS path setup, to name a few. Clearly, not every problem can be solved by a SIP extension. More importantly, some problems that could be solved by a SIP extension, probably shouldn't. To assist engineers in determining whether a SIP extension is an appropriate solution to their problem, we present two broad criteria. First, the problem SHOULD fit into the general purvey of SIPsSIP's solution space. Secondly, the solution MUST conform to the general SIP architectural model. While the first criteria might seem obvious, we have observed that numerous extensions to SIP have been proposed because some function is needed in a device which also speaks SIP. The argument is generally given that "I'd rather implement one protocol than many". As an example, user agents, like all other IP hosts, need some way to obtain their IP address. This is generally done through DHCP . SIPs. SIP's multicast registration mechanisms might supply an alternate way to obtain an IP address. This would eliminate the need for DHCP in clients. However, we do not believe such extensions are appropriate. We believe that protocols should be defined to provide specific, narrow functions, rather than being defined based on all communications requirements between a pair of devices. The latter approach to protocol design yields modular protocols with broad application. It also facilitates extensibility and growth; single protocols can be removed and changed without affecting the entire system. We observe that this approach to protocol engineering mirrors object oriented software engineering. Our second criteria, that the extension must conform to the general SIP architectural model, ensures that the protocol remains manageable and broadly applicable. 3.1 SIP's Solution Space In order to evaluate the first criteria, it is necessary to define exactly what SIPsSIP's solution space is, and what it is not. SIP is a protocol for initiating, modifying, and terminating interactive sessions. This process involves the discovery of users, (or more generally, entities that can be communicated with, including services, such as voicemail or translation devices) wherever they may be located, so that a description of the session can be delivered to the user. It is assumed that these users or communications entities are mobile, and their point of attachment to the network changes over time. The primary purpose of SIP is a rendezvous function, to allow a request initiator to deliver a message to a recipient wherever they may be. Such rendezvous is needed to establish a session, but can be used for other purposes related to communications, such as querying for capabilities or delivery of an instant message. Much of SIP focuses on this discovery and rendezvous component. Its ability to fork, its registration capabilities, and its routing capabilities are all present for the singular purpose of finding the desired user wherever they may be. As such, features and capabilities such as personal mobility, automatic call distribution, and follow-me are well within the SIP solution space. Session initiation also depends on the ability of the called party to have enough information about the session itself in order to make a decision on whether to join or not. That information includes data about the caller, the purpose for the invitation, and parameters of the session itself. For this reason, SIP includes this kind of information. Part of the process of session initiation is the communication of progress and the final results of establishment of the session. SIP provides this information as well. SIP itself is independent of the session, and the session description is delivered as an opaque body within SIP messages. Keeping SIP independent of the sessions it initiates and terminates is fundamental. As such, there are many functions that SIP explicitly does not provide. It is not a session management protocol or a conference control protocol. The particulars of the communications within the session are outside of SIP. This includes features such as media transport, voting and polling, virtual microphone passing, chairman election, floor control, and feedback on session quality. SIP is not a resource reservation protocol for sessions. This is fundamentally because (1) SIP is independent of the underlying session it establishes, and (2) the path of SIP messages is completely independent from the path that session packets may take. The path independence refers to paths within a providers network, and the set of providers itself. For example, it is perfectly reasonable for a SIP message to traverse a completely different set of autonomous systems than the audio in a session SIP establishes. SIP is not a general purpose transfer protocol. It is not meant to send large amounts of data unrelated to SIPsSIP's operation. It is not meant as a replacement for HTTP. This is not to say that carrying payloads in SIP messages is never a good thing; in many cases, the data is very much related to SIPsSIP's operation. In those cases, congestion controlled transports end-to-end are critical. SIP is not meant to be a general RPCRemote Procedure Call (RPC) mechanism. None of its user discovery and registration capabilities are needed for RPC, neither are most of its proxy functions. SIP is not meant to be used as a strict PSTN signaling replacement. It is not a superset of ISUP. While it can support gatewaying of PSTN signaling, and can provide many features present in the PSTN, the mere existence of a feature or capability in the PSTN is not a justification for its inclusion in SIP. Extensions needed to support telephony MUST meet the other criteria described here. SIP is a poor control protocol. It is not meant to be used for one entity to tell another to pick up or answer a phone, send audio using a particular codec, or changeto provide a new value for a configuration parameter. Control protocols have different trust relationships than is assumed in SIP, and are more centralized in architecture than SIP, which is a very distributed protocol. There are many network layer services needed to make SIP function. These include quality of service, mobility, and security, among others. Rather than building these capabilities into SIP itself, they SHOULD be developed outside of SIP, and then used by it. Specifically, any protocol mechanisms that are needed by SIP, but are also needed by many other application layer protocols, SHOULD NOT be addressed within SIP. 3.2 SIP Architectural Model We describe here some of the primary architectual assumptions which underly SIP. Extensions which violate these assumptions should be examined more carefully to determine their appropriateness for SIP. Session independence: SIP is independent of the session it establishes. This includes the type of session, be it audio, video, game, chat session, or virtual reality. SIP operation SHOULD NOT be dependent on some characteristic of the session. SIP is not specific to VoIP only. Any extensions to SIP MUST consider the application of SIP to a variety of different session types. SIP and Session Path Independence: We have already touched on this once, but it is worth noting again. The set of routers and/or networks and/or autonomous systems traversed by SIP messages are unrelated to the set of routers and/or networks and/or autonomous systems traversed by session packets. They may be the same in some cases, but it is fundamental to SIPsSIP's architecture that they need not be the same. Extensions which only work under some assumption of overlap are not generally applicable to SIPsSIP's operation and should be scrutinized carefully. Multi-provider and Multi-hop: SIP assumes that its messages will traverse the Internet. That is, SIP works through multiple networks administered by different providers. It is also assumed that SIP messages traverse many hops (where each hop is a proxy). Extensions SHOULD NOT work only under the assumption of a single hop or single provider. Transactional: SIP is a request/response protocol, possibly enhanced with intermediate responses. Many of the rules of operation in SIP are based on general processing of requests and responses. This includes the reliability mechanisms, routing mechanisms, and state maintenance rules. Extensions SHOULD NOT add messages that are not within the request-response model. Proxies can ignore bodies: In order for proxies to scale well, they must be able to operate with minimal message processing. SIP has been engineered so that proxies can always ignore bodies. Extensions SHOULD NOT require proxies to examine bodies. Proxies don't need to understand the method: Processing of requests in proxies does not depend on the method, except for the well known methods INVITE, ACK, and CANCEL. This allows for extensibility. Extensions MUST NOT define new methods which must be understood by proxies. INVITE messages carry full state: An initial INVITE message for a session is nearly identical (the exception is the tag) to a re-INVITE message to modify some characteristic of the session. This full state property is fundamental to SIP, and is critical for robustness of SIP systems. Extensions SHOULD NOT modify INVITE processing such that data spanning multiple INVITEs must be collected in order to perform some feature. Generality over efficiency: Wherever possible, SIP has favored general purpose components rather than narrow ones. If some capability is added to support one service, but a slightly broader capability can support a larger variety of services (at the cost of complexity or message sizes), the broader capability SHOULD be preferred. The Request URI is the primary key for forwarding: Forwarding logic at SIP servers depends primarily on the request URI (this is different from request routing in SIP, which uses the Route headersheader fields to pass a request through intermediate proxies). It is fundamental to the operation of SIP that the request URI indicate a resource that, under normal operations, resolves to the desired recipient. Extensions SHOULD NOT use other components of the SIP message as the primary forwarding key, and SHOULD NOT modify the semantics of the request URI. Heterogeneity is the norm: SIP supports hetereogeneous devices. It has built in mechanisms for determining the set of overlapping protocol functionalities. Extensions SHOULD NOT be defined which only function if all devices support the extension. 4 Issues to be Addressed Given an extension has met the litmus tests in the previous section, there are several issues that all extensions should take into consideration. 4.1 Backwards Compatibility One of the most important issues to consider is whether the new extension is backwards compatible with baseline SIP. This is tightly coupled with how the Require, Proxy-Require, and Supported headersheader fields are used. If an extension consists of new headersheader fields or header field parameters inserted by a user agent in a request with an existing method, and the request cannot be processed reasonably by a proxy and/or user agent without understanding the headers,header fields or parameters, the extension MUST mandate the usage of the Require and/or Proxy-Require headersheader fields in the request. These extensions are not backwards compatible with SIP. The result of mandating usage of these headersheader fields means that requests cannot be serviced unless the entities being communicated with also understand the extension. If some entity does not understand the extension, the request will be rejected. The UAC can then handle this in one of two ways. In the first, the request simply fails, and the service cannot be provided. This is basically an interoperability failure. In the second case, the UAC retries the request without the extension. This will preserve interoperability, at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). As the number of extensions increases, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. The result is excessive complexity. Because of the possibility of interoperability and complexity problems that result from the usage of Require and Proxy-Require, we believe the following guidelines are appropriate: o The usage of these headersheader fields in requests for basic SIP services (in particular, session initiation and termination) is NOT RECOMMENDED. The less frequently a particular extension is needed in a request, the more reasonable it is to use these headers.header fields. o The Proxy-Require header field SHOULD be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. On the other hand, the Require header field only mandates that a single entity, the UAS, support the extension. Usage of Proxy-Require is thus considered exponentially worse than usage of the Require header.header field. o If either Require or Proxy-Require are used by an extension, the extension SHOULD discuss how to fall back to baseline SIP operation if the request is rejected with a 420 response. Extensions which define new methods do not need to use the Require header.header field. SIP defines mechanisms which allow a UAC to know whether a new method is understood by a UAS. This includes both the OPTIONS request, and the 405 (Method Not Allowed) response with the Allow header.header field. It is fundamental to SIP that proxies do not need to understand the semantics of a new method in order to process it. If an extension defines a new method which must be understood by proxies in order to be processed, a Proxy-Require header field is needed. As discussed above, these kinds of extensions are frowned upon. In order to achieve backwards compatibility for extensions that define new methods, the Allow header field is used. There are two types of new methods - those that are used for established dialogs (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULD contain an Allow header,header field, a UA can readily determine whether the new method can be supported within the dialog. For example, ifonce an INVITE dialog is established, a newuser agent could determine if the REFER method for a mid-dialog feature, such as hold, were to be defined, is supported if it is present in an Allow header. If it was, the hold"transfer" button on the UI could be "greyed out" once the call is established, if the new method were not listed in the Allow header.established. Another type of extension are those which require a proxy to insert headersheader fields or header field parameters into a request as it traverses the network, or for the UAS to insert headersheader fields or header field parameters into a response. For some extensions, if the UAC or UAS does not understand these headers,header fields, the message can still be processed correctly. These extensions are completely backwards compatible. Most other extensions of this type require that the server only insert the header field or parameter if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header field mechanism. This mechanism allows a server to determine if the client can understand some extension, so that it can apply the extension to the response. By their nature, these extensions may not always be able to be applied to every response. If an extension requires a proxy to insert a header field or parameter into a request, and this header field or parameter needs to be understood by both UAC and UAS to be executed correctly, a combination of the Require and the Supported mechanism will need to be used. The proxy can insert a Require header field into the request, given the Supported header field is present. An example of such an extension is the SIP Session Timer .. Yet another type of extension is that which defines new body types to be carried in SIP messages. According to the SIP specification, bodies must be understood in order to process a request. As such, the interoperability issues are similar to new methods. However, the Content-Disposition header field has been defined to allow a client or server to indicate that the message body is optional . Usage of optional bodies, as opposed to mandatory ones, is RECOMMENDED wherever possible. When a body must be understood to properly process a request or response, it is preferred that the sending entity know ahead of time whether the new body is understood by the recipient. For requests that establish a dialog, inclusion of Accept in the request and its success responses is RECOMMENDED. This will allow both parties to determine what body types are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood. 4.2 Security Security is an important component of any protocol. Designers of SIP extensions SHOULDneed to carefully consider if additional security requirements are required over those described in RFC3261. Frequently authorization requirements, and requirements for end-to-end integrity are the most overlooked. SIP extensions MUST consider how (or if) they affect usage of the general SIP security mechanisms. Most extensions should not require any new security capabilities beyond general purpose SIP. If they do, it is likely that the security mechanism has more general purpose application, and should be considered an extension in its own right. 4.3 Usage GuidelinesTerminology RFC 3261 has an extensive terminology section that defines terms like caller, callee, user agent, header field, and so on. All SIP extensions must contain guidelines defining when the extension isMUST conform to be used. For extensions thatthis terminology. They MUST NOT define new headers,terms that describe concepts already defined by a term in another SIP specification. If new terminology is needed, it SHOULD appear in a separate section towards the extension MUST definebeginning of the request methodsdocument. Careful attention must be paid to the actual usage of terminology. Many documents misuse the terms header, header can appear in,field, and what responses it can be used in. It is recommended that this information be represented asheader field values, for example. Document authors SHOULD do a new rowcareful review of Table 4their documents for proper usage of RFC BBBB . The extension SHOULD specify which entities (UAC, UAS, proxy, redirect, registrar) are allowed to insert the header.these terms. 4.4 Syntactic Issues Extensions that define new methods SHOULD use all capitals for the method name. Method names SHOULD be less than 10 characters, and SHOULD attempt to convey the general meaning of the request. Method names are case sensitive, and therefore there is no requirement that they be capitalized. However, using capitalized method names keeps with a long-standing convention in SIP and many similar protocols, such as HTTP  and RTSP . Extensions that define new headersheader fields that are anticipated to be heavily used SHOULD define a compact form if those headersheader fields are more than four characters. Compact headersheader fields MUST be a single character. When all 26 characters are exhausted, new compact forms will no longer be defined. Header field names SHOULD usebe composed primarily of ASCII characters.characters and marks. They SHOULD be descriptive but reasonably brief. Although header field names are case insensitive, a single common capitalization SHOULD be used throughout the document. It is RECOMMENDED that this be camel case. As an example, the following are poor choices for header field names: ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function Case sensitivity of parameters and values is a constant source of confusion. SIP extensions MUST clearly indicateconfusion, a difficulty that plagued RFC 2543 . This has been made simple through the case sensitivity or insensitivityusage of every parameter, value or field they define. However, it is RECOMMENDED that these extensions be consistent with baseline SIP, which uses case insensitive parameters, consistent withthe grammarBNF constructs of RFC 2234 ., which have clear rules of case sensivitity and insensitivity. Therefore, the BNF for an extension completely defines the matching rules. Extensions MUST be consistent with the SIP conventions for sensitivity. Methods MUST be case sensitive. Header field names MUST be case insensitive. Header field parameter names MUST be case insensitive. Header field values and parameter values are sometimes case sensitive, and sometimes case insensitive. However, generally they SHOULD be case insensitive. Definiting a case sensitive component requires explicitly listing each character through its ASCII code. Extensions which contain freeform text MUST allow that text to be UTF-8, as per the IETF policies on character set usage . This ensures that SIP remains an internationalized standard. As a general guideline, freeform text is never needed by programs in order to perform protocol processing. It is usually entered by and displayed to the user. If an extension uses a parameter which can contain UTF-8 encoded characters, and that extension requires a comparison to be made of this parameter to other parameters, the comparison MUST be case sensitive. Case insensitive comparison rules for UTF-8 text are extremely complicatedare, at this time, impossible and are toMUST be avoided. Extensions which make use of dates MUST use the SIP-Date BNF defined in RFC BBBB3261 . No other date formats are allowed. However, the usage of absolute dates in order to determine intervals (for example, the time at which some timer fires) is NOT RECOMMENDED. This is because it requires synchronized time between peers, and this is frequently not the case. Therefore, relative times, expressed in numbers of seconds, SHOULD be used. Extensions which include network layer addresses SHOULD permit dotted quad IPv4 addresses, IPv6 addresses in the format described in , and domain names. Extensions which have headersheader fields containing URIs SHOULD allow any URI, not just SIP URIs. Headers SHOULD followHeader fields MUST follow the standard formatting for SIP, defined as: header = header-name HCOLON header-value *(COMMA header-value) header-name = token header-value = value *(SEMI value-parameter) value-parameter = token [EQUAL gen-value] gen-value = token / host / quoted-string value = token / host / quoted-string In some cases, this form is not sufficient. That is the case for headersheader fields that express descriptive text notmeant for human consumption. An example is the Subject header field in SIP . In this case, an alternate form is: header = header-name HCOLON [TEXT-UTF8-TRIM] Developers of extensions SHOULD allow for extension parameters in their headers. Headersheader fields. Header Fields that contain a list of URIs SHOULD follow the same syntax as the Contact header field in SIP. Implementors are also encouraged to always wrap these URI in angle brackets "<" and ">". We have found this to be a frequently misimplemented feature. Beyond compact form, there is no need to define compressed versions of header field values. Compression of SIP messages SHOULD be handled at lower layers, for example, using IP payload compression  or signalling compression .. Syntax for headersheader fields is expressed in Augmented Backus-Naur Form and MUST follow the format of RFC 2234 . Extensions MUST make use of the primitive components defined in RFC BBBB3261 . If the construction for a BNF element is defined in another specification, it is RECOMMENDED that the construction be referenced rather than copied. The reference SHOULD include both the document and section number. All BNF elements must be either defined or referenced. It is RECOMMENDED that BNF be collected into a single section near the end of the document. All tokens and quoted strings are separated by explicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions SHOULDMUST NOT define new headersheader fields that use alternate linear white space rules. All SIP extensions MUST verify that any BNF productions that they define in their grammar do not conflict with any existing grammar defined in other SIP standards track specifications. 4.5 Semantics, Semantics, Semantics Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULD step through the processing rules in temporal order of the most common messaging scenario. Processing rules generally specify actions to take (in terms of messages to send, variables to store, rules to follow) on receipt of messages and expiration of timers. If an action requires transmission of a message, the rule SHOULD outline requirements for insertion of headersheader fields or other information in the message. The extension SHOULD specify procedures to take in exceptional conditions which are recoverable, or which require some kind of user intervention. Recovering from unrecoverable problems generally does not require specification. 4.6 Examples Section The specification SHOULD contain a section that gives examples of call flows and message formatting. Extensions which define substantial new syntax SHOULD include examples of messages containing that syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case. For an example of how to construct a good examples section, see the message flows and message formatting defined in the Basic Call Flows Examplespecification .. Note that complete messages SHOULD be used. Be careful to include tags, Via headersheader fields (with the branch ID cookie), Max-Forwards, Content-Lengths, Record-Route and Route headers.header fields. Example INVITE messages MAY omit session descriptions, and Content-Length values MAY be set to "..." to indicate that the value is not provided. However, the specification MUST explicitly call out the meanining of the "..." and explicitly indicate that session descriptions were not included. 4.7 Overview Section Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDED that extensions have a protocol overview section which discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULD be mentioned. Usage of the RFC 2119  terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. 4.8 Document Naming Conventions An important decision to be made about theIANA Considerations Section Documents which define new SIP extensions will invariably have IANA Considerations sections. If your extension is its title. The titledefining a new event package, you MUST indicateregister that package. RFC 3265  provides the document isregistration template. See  for an extension to SIP. It is RECOMMENDED that the title follow the basic formexample of "An Extension tothe Session Initiation Protocol for X", where Xregistration of a new event package. If your extension is defining a 1-3 word descriptionnew header field, you MUST register that header field. RFC 3261  provides a registration template. See Section 8.2 of the extension. For example, ifRFC 3262  for an example of how to register new SIP header fields. If your extension definesis defining a new header, called Make-Coffee,response code, you MUST register that response code. RFC 3261  provides a registration template. See  for making coffee, the title would read, "An Extenstionan example of how to the Session Initiation Protocol for Making Coffee". Itregister a new response code. If your extension is RECOMMENEDdefining a new SIP method, you MUST register that these additional words be descriptive rather than naming the header. For example, the extension for makingmethod. RFC 3261  provides a registration template. See Section 10 of RFC 3311  for an example of how to register a new SIP method. Many SIP extensions make use of option tags, carried in the Require, Proxy-Require and Supported header fields. Section 4.1 discusses some of the issues involved in the usage of these header fields. If your extension does require them, you MUST register an option tag for your extension. RFC 3261  provides a registration template. See Section 8.1 of RFC 3262  for an example of how to register an option tag. Some SIP extensions will require establishment of their own IANA registries. RFC 2434  provides guidance on how and when IANA registries are established. For an example of how to set one up, see Section 6 of RFC 3265  for an example. 4.9 Document Naming Conventions An important decision to be made about the extension is its title. The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of "A [summary of function] for the Session Initiation Protocol (SIP)", where the summary of function is a one to three word description of the extension. For example, if an extension defines a new header field, called Make-Coffee, for making coffee, the title would read, "Making Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENED that these additional words be descriptive rather than naming the header field. For example, the extension for making coffee should not be named "An Extension to"The Make-Coffee Header for the Session Initiation Protocol for Make-Coffee".Protocol". For extensions that define new methods, an acceptable template for titles is "The Session Initiation Protocol (SIP) X Method" where X is the name of the method. 4.9Note that the acronymn SIP MUST be expanded in the titles of RFCs, as per . 4.10 Additional Considerations for New Methods Extensions which define new methods SHOULD take into consideration, and discuss, the following issues: o Can it contain bodies? If so, what is the meaning of the presence of those bodies? What body types are allowed? o Can a transaction with this request method occur while another transaction, in the same and/or reverse direction, is in progress? o What headers are allowedThe extension MUST define which header fields can be present in requests of this method?that method. It is RECOMMENDED that this information be presented throughrepresented as a new column of Table 2 in2/3 of RFC BBBB3261 . The table MUST contain rows for all header fields defined in standards track RFCs at the time of writing of the extension. o Can the request be sent within a dialog, or does it establish a dialog? o Is it a target refresh request? o Extensions to SIP that define new methods MAY specify whether offers and answers can appear in requests of that method or its responses. However, those extensions MUST adhere to the protocol rules specified in ,, and MUST adhere to the additional constraints for offers and answers as specified in SIP . o Because of the nature of reliability treatment of requests with new methods, those requests need to be answered immediately by the UAS. Protocol extensions that require longer durations for the generation of a response (such as a new method that does requirerequires human interaction) SHOULD instead use two transactions - one to send the request, and another in the reverse direction to convey the result of the request. An example of that is SUBSCRIBE and NOTIFY . o The CANCEL request can be used for a particular extension method on a method-by-method basis. SIP  only allows cancellation of INVITE. Extensions that define new methods MUST state whether or not transactions initiated by requests with that method can be cancelled. Furthermore, the rules a UAS should follow upon cancellation of an unanswered request MUST be described. Note that, since non-INVITE requests are generally answered immediately, cancellation ususally serves no purpose. Note that the reliability mechanisms for all new methods must be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. This means requests with new SIP methods need to be responded to within short time periods (on the order of seconds). 4.104.11 Additional Considerations for New HeadersHeader Fields or Header Field Parameters The most important issue for extensions that define new headersheader fields or header field parameters is backwards compatibility. See Section 4.1 for a discussion of the issues. The extension MUST detail how backwards compatibility is addressed. It is often tempting to avoid creation of a new method by overloading an existing method through a header. Headersheader field or parameter. Header fields and parameters are not meant to fundamentally alter the meaning of the method of the request. A new header field cannot change the basic semantic and processing rules of a method. There is no shortage of method names, so when an extension changes the basic meaning of a request, a new method SHOULD be defined. SpecificationsFor extensions that define new headersheader fields, the extension MUST include a table with identical columns todefine the request methods the header field can appear in, and what responses it can be used in. It is RECOMMENDED that this information be represented as a new row of Table 22/3 of RFC BBBB  with a row for each new header. Furthermore, the3261 . The table MUST include a columncontain columns for anyall methods defined in any otherstandards track extensions that have reached RFC status. 4.11RFCs at time of writing of the extension. 4.12 Additional Considerations for New Body Types Because SIP can run over UDP, extensions that specify the inclusion of large bodies are frowned upon unless end-to-end congestion controlled transport can be guaranteed. If at all possible, the content SHOULD be included indirectly through an URI even if congestion controlled transports are available. Note that the presence of a body MUST NOT change the nature of the message. That is, bodies cannot alter the state machinery associated with processing a request of a particular method or a response. Bodies enhance this processing by providing additional data. 5 Interactions with SIP Features We have observed that certain capabilities of SIP continually interact with extensions in unusual ways. Writers of extensions SHOULD consider the interactions of their extensions with these SIP capabilities, document any unusual interactions if they exist. The most common causes of problems are: Forking: Forking by far presents the most troublesome interactions with extensions. This is generally because it can cause (1) a single transmitted request to be received by an unknown number of UASs, and (2) a single INVITE request to have multiple responses. CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that they are exceptions to many of the general request processing rules. The main reason for this special status is that CANCEL and ACK are always associated with another request. New methods SHOULD consider the meaning of cancellation, as described above. Extensions which defined new headersheader fields in INVITE requests SHOULD consider whether they also need to be included in ACK.ACK and CANCEL. Frequently they do, in order to allow a stateless proxy to route the CANCEL or ACK identically to the INVITE. Routing: The presence of Route headersheader fields in a request can cause it to be sent through intermediate proxies. Requests that establish dialogs can be record-routed, so that the initial request goes through one set of proxies, and subsequent requests through a different set. These SIP features can interact in unusual ways with extensions. Stateless Proxies: SIP allows a proxy to be stateless. Stateless proxies are unable to retransmit messages and cannot execute certain services. Extensions which depend on some kind of proxy processing SHOULD consider how stateless proxies affect that processing. 6 Security Considerations The nature of this document is such that it does not introduce any new security considerations. 7 IANA Considerations There are no IANA considerations associated with this specification. 8 Acknowledgements The authors would like to thank Rohan Mahy for his comments. 9 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ 07936 email: firstname.lastname@example.org Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: email@example.com 910 Normative References  S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.  J. Rosenberg, H. Schulzrinne, et al. ,G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Sessionsession initiation protocol," Internet Draft,RFC 3261, Internet Engineering Task Force, Feb.June 2002. Work in progress. D. Crocker, Ed., and P. Overell,"Augmented BNF for syntax specifications: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 1997.  H. Alvestrand, "IETF policy on character sets and languages," RFC 2277, Internet Engineering Task Force, Jan. 1998.  R. Hinden, B. Carpenter, and L. Masinter, "Format for literal IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, Dec. 1999.  A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002.  T. Narten and H. Alvestrand, "Guidelines for writing an IANA considerations section in RFCs," RFC 2434, Internet Engineering Task Force, Oct. 1998.  J. Rosenberg and H. Schulzrinne, "An offer/answer model with SDP," Internet Draft,session description protocol (SDP)," RFC 3264, Internet Engineering Task Force, Feb.June 2002. Work in progress. 1011 Informative References  A. Mankin, S. Bradner, and R. Mahy, A. Mankin, et al. , "SIP change process,""Change process for the session initiation protocol (SIP)," Internet Draft, Internet Engineering Task Force, Mar.Aug. 2002. Work in progress.  R. Droms, "Dynamic host configuration protocol," RFC 2131, Internet Engineering Task Force, Mar. 1997.  R. Sparks, "The SIP refer method," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress.  S. Donovan and J. Rosenberg, "SIP"Session initiation protocol extension for session timer," Internet Draft, Internet Engineering Task Force, Oct. 2001.July 2002. Work in progress.  R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999.  H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998.  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," RFC 2543, Internet Engineering Task Force, Mar. 1999.  A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload compression protocol (ipcomp)," RFC 2393, Internet Engineering Task Force, Dec. 1998.  R. Price, H. Hannu,Price et al. , "Signaling compression," Internet Draft, Internet Engineering Task Force, MayJune 2002. Work in progress.  A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis,Johnston et al. , "Session initiation protocol basic call flow examples," Internet Draft, Internet Engineering Task Force, Aug. 2002. Work in progress.  J. Rosenberg, K. Summers,"A sip event package for registration state," Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in progress.  J. Rosenberg and H. Schulzrinne, "SIP telephony call flow examples,""Reliability of provisional responses in session initiation protocol (SIP)," RFC 3262, Internet Engineering Task Force, June 2002.  J. Rosenberg, "The session initiation protocol (SIP) UPDATE method," RFC 3311, Internet Engineering Task Force, Oct. 2002.  J. Reynolds and B. Braden, "Instructions to request for comments (RFC) authors," Internet Draft, Internet Engineering Task Force, Apr. 2001.2002. Work in progress.  S. Olson, "Requirements for content indirection in SIP messages," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.