idnits 2.17.1 draft-ietf-sip-guidelines-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1051. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2005) is 7002 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TEXT-UTF8-TRIM' on line 577 ** Obsolete normative reference: RFC 2732 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '10') (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '15') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '17') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '25') (Obsoleted by RFC 5226) == Outdated reference: A later version (-03) exists of draft-iab-model-02 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: August 17, 2005 H. Schulzrinne 4 Columbia University 5 February 16, 2005 7 Guidelines for Authors of Extensions to the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sip-guidelines-09 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 17, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The Session Initiation Protocol (SIP) is a flexible, yet simple tool 45 for establishing interactive connections across the Internet. Part 46 of this flexibility is the ease with which it can be extended. In 47 order to facilitate effective and interoperable extensions to SIP, 48 some guidelines need to be followed when developing SIP extensions. 50 This document outlines a set of such guidelines for authors of SIP 51 extensions. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Should I define a SIP Extension? . . . . . . . . . . . . . . 3 58 3.1 SIP's Solution Space . . . . . . . . . . . . . . . . . . . 4 59 3.2 SIP Architectural Model . . . . . . . . . . . . . . . . . 6 60 4. Issues to be Addressed . . . . . . . . . . . . . . . . . . . 8 61 4.1 Backwards Compatibility . . . . . . . . . . . . . . . . . 8 62 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4 Syntactic Issues . . . . . . . . . . . . . . . . . . . . . 11 65 4.5 Semantics, Semantics, Semantics . . . . . . . . . . . . . 14 66 4.6 Examples Section . . . . . . . . . . . . . . . . . . . . . 14 67 4.7 Overview Section . . . . . . . . . . . . . . . . . . . . . 14 68 4.8 IANA Considerations Section . . . . . . . . . . . . . . . 15 69 4.9 Document Naming Conventions . . . . . . . . . . . . . . . 16 70 4.10 Additional Considerations for New Methods . . . . . . . 16 71 4.11 Additional Considerations for New Header Fields or 72 Header Field Parameters . . . . . . . . . . . . . . . . 18 73 4.12 Additional Considerations for New Body Types . . . . . . 18 74 5. Interactions with SIP Features . . . . . . . . . . . . . . . 18 75 6. Security Considerations . . . . . . . . . . . . . . . . . . 19 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 80 9.2 Informative References . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 82 Intellectual Property and Copyright Statements . . . . . . . 23 84 1. Terminology 86 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 87 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 88 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 89 indicate requirement levels for compliant implementations. 91 2. Introduction 93 The Session Initiation Protocol (SIP) [2] is a flexible, yet simple 94 tool for establishing interactive connections across the Internet. 95 Part of this flexibility is the ease with which it can be extended 96 (with new methods, new header fields, new body types, and new 97 parameters), and there have been countless proposals that have been 98 made to do just that. An IETF process has been put into place which 99 defines how extensions are to be made to the SIP protocol [10]. That 100 process is designed to ensure that extensions are made which are 101 appropriate for SIP (as opposed to being done in some other 102 protocol), that these extensions fit within the model and framework 103 provided by SIP and are consistent with its operation, and that these 104 extensions solve problems generically rather than for a specific use 105 case. However, [10] does not provide the technical guidelines needed 106 to assist that process. This specification helps to meet that need. 108 This specification first provides a set of guidelines to help decide 109 whether a certain piece of functionality is appropriately done in 110 SIP. Assuming the functionality is appropriate, it then points out 111 issues which extensions should deal with from within their 112 specification. Finally, it discusses common interactions with 113 existing SIP features which often cause difficulties in extensions. 115 3. Should I define a SIP Extension? 117 The first question to be addressed when defining a SIP extension is: 118 is a SIP extension the best solution to my problem? SIP has been 119 proposed as a solution for numerous problems, including mobility, 120 configuration and management, QoS control, call control, caller 121 preferences, device control, third party call control, and MPLS path 122 setup, to name a few. Clearly, not every problem can be solved by a 123 SIP extension. More importantly, some problems that could be solved 124 by a SIP extension, probably shouldn't. 126 To assist engineers in determining whether a SIP extension is an 127 appropriate solution to their problem, we present two broad criteria. 128 First, the problem SHOULD fit into the general purview of SIP's 129 solution space. Secondly, the solution MUST conform to the general 130 SIP architectural model. 132 While the first criteria might seem obvious, we have observed that 133 numerous extensions to SIP have been proposed because some function 134 is needed in a device which also speaks SIP. The argument is 135 generally given that "I'd rather implement one protocol than many". 136 As an example, user agents, like all other IP hosts, need some way to 137 obtain their IP address. This is generally done through DHCP [11]. 138 SIP's multicast registration mechanisms might supply an alternate way 139 to obtain an IP address. This would eliminate the need for DHCP in 140 clients. However, we do not believe such extensions are appropriate. 141 We believe that protocols should be defined to provide specific, 142 narrow functions, rather than being defined based on all protocols 143 needed between a pair of devices. The former approach to protocol 144 design yields modular protocols with broad application. It also 145 facilitates extensibility and growth; single protocols can be removed 146 and changed without affecting the entire system. We observe that 147 this approach to protocol engineering mirrors object oriented 148 software engineering. 150 Our second criteria, that the extension must conform to the general 151 SIP architectural model, ensures that the protocol remains manageable 152 and broadly applicable. 154 3.1 SIP's Solution Space 156 In order to evaluate the first criteria, it is necessary to define 157 exactly what SIP's solution space is, and what it is not. 159 SIP is a protocol for initiating, modifying, and terminating 160 interactive sessions. This process involves the discovery of users, 161 (or more generally, entities that can be communicated with, including 162 services, such as voicemail or translation devices) wherever they may 163 be located, so that a description of the session can be delivered to 164 the user. It is assumed that these users or communications entities 165 are mobile, and their point of attachment to the network changes over 166 time. The primary purpose of SIP is a rendezvous function, to allow 167 a request initiator to deliver a message to a recipient wherever they 168 may be. Such rendezvous is needed to establish a session, but can be 169 used for other purposes related to communications, such as querying 170 for capabilities or delivery of an instant message. 172 Much of SIP focuses on this discovery and rendezvous component. Its 173 ability to fork, its registration capabilities, and its routing 174 capabilities are all present for the singular purpose of finding the 175 desired user wherever they may be. As such, features and 176 capabilities such as personal mobility, automatic call distribution, 177 and follow-me are well within the SIP solution space. 179 Session initiation also depends on the ability of the called party to 180 have enough information about the session itself in order to make a 181 decision on whether to join or not. That information includes data 182 about the caller, the purpose for the invitation, and parameters of 183 the session itself. For this reason, SIP includes this kind of 184 information. 186 Part of the process of session initiation is the communication of 187 progress and the final results of establishment of the session. SIP 188 provides this information as well. 190 SIP itself is independent of the session, and the session description 191 is delivered as an opaque body within SIP messages. Keeping SIP 192 independent of the sessions it initiates and terminates is 193 fundamental. As such, there are many functions that SIP explicitly 194 does not provide. It is not a session management protocol or a 195 conference control protocol. The particulars of the communications 196 within the session are outside of SIP. This includes features such 197 as media transport, voting and polling, virtual microphone passing, 198 chairman election, floor control, and feedback on session quality. 200 SIP is not a resource reservation protocol for sessions. This is 201 fundamentally because (1) SIP is independent of the underlying 202 session it establishes, and (2) the path of SIP messages is 203 completely independent from the path that session packets may take. 204 The path independence refers to paths within a provider's network and 205 the set of providers itself. For example, it is perfectly reasonable 206 for a SIP message to traverse a completely different set of 207 autonomous systems than the audio in a session SIP establishes. 209 SIP is not a general purpose transfer protocol. It is not meant to 210 send large amounts of data unrelated to SIP's operation. It is not 211 meant as a replacement for HTTP. This is not to say that carrying 212 payloads in SIP messages is never a good thing; in many cases, the 213 data is very much related to SIP's operation. In those cases, 214 congestion controlled transports end-to-end are critical. 216 SIP is not meant to be a general Remote Procedure Call (RPC) 217 mechanism. None of its user discovery and registration capabilities 218 are needed for RPC, neither are most of its proxy functions. 220 SIP is not meant to be used as a strict Public Switched Telephone 221 Network (PSTN) signaling replacement. It is not a superset of the 222 Integrated Services Digital Network (ISDN) User Part (ISUP). While 223 it can support gatewaying of PSTN signaling, and can provide many 224 features present in the PSTN, the mere existence of a feature or 225 capability in the PSTN is not a justification for its inclusion in 226 SIP. Extensions needed to support telephony MUST meet the other 227 criteria described here. 229 SIP is a poor control protocol. It is not meant to be used for one 230 entity to tell another to pick up or answer a phone, send audio using 231 a particular codec, or to provide a new value for a configuration 232 parameter. Control protocols have different trust relationships than 233 is assumed in SIP, and are more centralized in architecture than SIP, 234 which is a very distributed protocol. 236 There are many network layer services needed to make SIP function. 237 These include quality of service, mobility, and security, among 238 others. Rather than building these capabilities into SIP itself, 239 they SHOULD be developed outside of SIP, and then used by it. 240 Specifically, any protocol mechanisms that are needed by SIP, but are 241 also needed by many other application layer protocols, SHOULD NOT be 242 addressed within SIP. 244 3.2 SIP Architectural Model 246 We describe here some of the primary architectual assumptions which 247 underly SIP. Extensions which violate these assumptions should be 248 examined more carefully to determine their appropriateness for SIP. 250 Session independence: SIP is independent of the session it 251 establishes. This includes the type of session, be it audio, 252 video, game, chat session, or virtual reality. SIP operation 253 SHOULD NOT be dependent on some characteristic of the session. 254 SIP is not specific to voice only. Any extensions to SIP MUST 255 consider the application of SIP to a variety of different session 256 types. 258 SIP and Session Path Independence: We have already touched on this 259 once, but it is worth noting again. The set of routers and/or 260 networks and/or autonomous systems traversed by SIP messages are 261 unrelated to the set of routers and/or networks and/or autonomous 262 systems traversed by session packets. They may be the same in 263 some cases, but it is fundamental to SIP's architecture that they 264 need not be the same. Standards track extensions MUST NOT be 265 defined that work only when the signaling and session paths are 266 coupled. Non-standard P-header extensions [10] are required for 267 any extension which only works in such a case. 269 Multi-provider and Multi-hop: SIP assumes that its messages will 270 traverse the Internet. That is, SIP works through multiple 271 networks administered by different providers. It is also assumed 272 that SIP messages traverse many hops (where each hop is a proxy). 273 Extensions MUST NOT work only under the assumption of a single hop 274 or specialized network topology. They SHOULD avoid the assumption 275 of a single SIP provider (but see the use of P-Headers, RFC 3427 276 [10]). 278 Transactional: SIP is a request/response protocol, possibly enhanced 279 with intermediate responses. Many of the rules of operation in 280 SIP are based on general processing of requests and responses. 281 This includes the reliability mechanisms, routing mechanisms, and 282 state maintenance rules. Extensions SHOULD NOT add messages that 283 are not within the request-response model. 285 Proxies can ignore bodies: In order for proxies to scale well, they 286 must be able to operate with minimal message processing. SIP has 287 been engineered so that proxies can always ignore bodies. 288 Extensions SHOULD NOT require proxies to examine bodies. 290 Proxies don't need to understand the method: Processing of requests 291 in proxies does not depend on the method, except for the well 292 known methods INVITE, ACK, and CANCEL. This allows for 293 extensibility. Extensions MUST NOT define new methods which must 294 be understood by proxies. 296 INVITE messages carry full state: An initial INVITE message for a 297 session is nearly identical (the exception is the tag) to a 298 re-INVITE message to modify some characteristic of the session. 299 This full state property is fundamental to SIP, and is critical 300 for robustness of SIP systems. Extensions SHOULD NOT modify 301 INVITE processing such that data spanning multiple INVITEs must be 302 collected in order to perform some feature. 304 Generality over efficiency: Wherever possible, SIP has favored 305 general purpose components rather than narrow ones. If some 306 capability is added to support one service, but a slightly broader 307 capability can support a larger variety of services (at the cost 308 of complexity or message sizes), the broader capability SHOULD be 309 preferred. 311 The Request URI is the primary key for forwarding: Forwarding logic 312 at SIP servers depends primarily on the request URI (this is 313 different from request routing in SIP, which uses the Route header 314 fields to pass a request through intermediate proxies). It is 315 fundamental to the operation of SIP that the request URI indicate 316 a resource that, under normal operations, resolves to the desired 317 recipient. Extensions SHOULD NOT modify the semantics of the 318 request URI. 320 Heterogeneity is the norm: SIP supports hetereogeneous devices. It 321 has built in mechanisms for determining the set of overlapping 322 protocol functionalities. Extensions SHOULD NOT be defined which 323 only function if all devices support the extension. 325 4. Issues to be Addressed 327 Given an extension has met the litmus tests in the previous section, 328 there are several issues that all extensions should take into 329 consideration. 331 4.1 Backwards Compatibility 333 One of the most important issues to consider is whether the new 334 extension is backwards compatible with baseline SIP. This is tightly 335 coupled with how the Require, Proxy-Require, and Supported header 336 fields are used. 338 If an extension consists of new header fields or header field 339 parameters inserted by a user agent in a request with an existing 340 method, and the request cannot be processed reasonably by a proxy 341 and/or user agent without understanding the header fields or 342 parameters, the extension MUST mandate the usage of the Require 343 and/or Proxy-Require header fields in the request. These extensions 344 are not backwards compatible with SIP. The result of mandating usage 345 of these header fields means that requests cannot be serviced unless 346 the entities being communicated with also understand the extension. 347 If some entity does not understand the extension, the request will be 348 rejected. The UAC can then handle this in one of two ways. In the 349 first, the request simply fails, and the service cannot be provided. 350 This is basically an interoperability failure. In the second case, 351 the UAC retries the request without the extension. This will 352 preserve interoperability, at the cost of a "dual stack" 353 implementation in a UAC (processing rules for operation with and 354 without the extension). As the number of extensions increases, this 355 leads to an exponential explosion in the sets of processing rules a 356 UAC may need to implement. The result is excessive complexity. 358 Because of the possibility of interoperability and complexity 359 problems that result from the usage of Require and Proxy-Require, we 360 believe the following guidelines are appropriate: 362 o The usage of these header fields in requests for basic SIP 363 services (in particular, session initiation and termination) is 364 NOT RECOMMENDED. The less frequently a particular extension is 365 needed in a request, the more reasonable it is to use these header 366 fields. 368 o The Proxy-Require header field SHOULD be avoided at all costs. 369 The failure likelihood in an individual proxy stays constant, but 370 the path failure grows exponentially with the number of hops. On 371 the other hand, the Require header field only mandates that a 372 single entity, the UAS, support the extension. Usage of 373 Proxy-Require is thus considered exponentially worse than usage of 374 the Require header field. 376 o If either Require or Proxy-Require are used by an extension, the 377 extension SHOULD discuss how to fall back to baseline SIP 378 operation if the request is rejected with a 420 response. 380 Extensions which define new methods do not need to use the Require 381 header field. SIP defines mechanisms which allow a UAC to know 382 whether a new method is understood by a UAS. This includes both the 383 OPTIONS request, and the 405 (Method Not Allowed) response with the 384 Allow header field. It is fundamental to SIP that proxies do not 385 need to understand the semantics of a new method in order to process 386 it. If an extension defines a new method which must be understood by 387 proxies in order to be processed, a Proxy-Require header field is 388 needed. As discussed above, these kinds of extensions are frowned 389 upon. 391 In order to achieve backwards compatibility for extensions that 392 define new methods, the Allow header field is used. There are two 393 types of new methods - those that are used for established dialogs 394 (initiated by INVITE, for example), and those that are sent as the 395 initial request to a UA. Since INVITE and its response both SHOULD 396 contain an Allow header field, a UA can readily determine whether the 397 new method can be supported within the dialog. For example, once an 398 INVITE dialog is established, a user agent could determine if the 399 REFER method [12] is supported if it is present in an Allow header. 400 If it wasn't, the "transfer" button on the UI could be "greyed out" 401 once the call is established. 403 Another type of extension are those which require a proxy to insert 404 header fields or header field parameters into a request as it 405 traverses the network, or for the UAS to insert header fields or 406 header field parameters into a response. For some extensions, if the 407 UAC or UAS does not understand these header fields, the message can 408 still be processed correctly. These extensions are completely 409 backwards compatible. 411 Most other extensions of this type require that the server only 412 insert the header field or parameter if it is sure the client 413 understands it. In this case, these extensions will need to make use 414 of the Supported request header field mechanism. This mechanism 415 allows a server to determine if the client can understand some 416 extension, so that it can apply the extension to the response. By 417 their nature, these extensions may not always be able to be applied 418 to every response. 420 If an extension requires a proxy to insert a header field or 421 parameter into a request, and this header field or parameter needs to 422 be understood by both UAC and UAS to be executed correctly, a 423 combination of the Require and the Supported mechanism will need to 424 be used. The proxy can insert a Require header field into the 425 request, given the Supported header field is present. An example of 426 such an extension is the SIP Session Timer [13]. 428 Yet another type of extension is that which defines new body types to 429 be carried in SIP messages. According to the SIP specification, 430 bodies must be understood by user agents in order to process a 431 request. As such, the interoperability issues are similar to new 432 methods. However, the Content-Disposition header field has been 433 defined to allow a client or server to indicate that the message body 434 is optional [2]. Extensions that define or require new body types 435 SHOULD make them optional for the user agent to process. 437 When a body must be understood to properly process a request or 438 response, it is preferred that the sending entity know ahead of time 439 whether the new body is understood by the recipient. For requests 440 that establish a dialog, inclusion of Accept in the request and its 441 success responses is RECOMMENDED. This will allow both parties to 442 determine what body types are supported by their peers. Subsequent 443 messaging between the peers would then only include body types that 444 were indicated as being understood. 446 4.2 Security 448 Security is an important component of any protocol. Designers of SIP 449 extensions need to carefully consider if additional security 450 requirements are required over those described in RFC 3261. 451 Frequently authorization requirements, and requirements for 452 end-to-end integrity are the most overlooked. 454 SIP extensions MUST consider how (or if) they affect usage of the 455 general SIP security mechanisms. Most extensions should not require 456 any new security capabilities beyond general purpose SIP. If they 457 do, it is likely that the security mechanism has more general purpose 458 application, and should be considered an extension in its own right. 460 Overall system security requires that both the SIP signaling and the 461 media sessions it established be secured. The media sessions 462 normally use of their own security techniques that are quite distinct 463 by those used by SIP itself. Extensions should take care not to 464 conflate the two. However, specifications that define extensions 465 which impact the media sessions in any way SHOULD consider the 466 interactions between SIP and session security mechanisms. 468 4.3 Terminology 470 RFC 3261 has an extensive terminology section that defines terms like 471 caller, callee, user agent, header field, and so on. All SIP 472 extensions MUST conform to this terminology. They MUST NOT define 473 new terms that describe concepts already defined by a term in another 474 SIP specification. If new terminology is needed, it SHOULD appear in 475 a separate section towards the beginning of the document. 477 Careful attention must be paid to the actual usage of terminology. 478 Many documents misuse the terms header, header field, and header 479 field values, for example. Document authors SHOULD do a careful 480 review of their documents for proper usage of these terms. 482 4.4 Syntactic Issues 484 Extensions that define new methods SHOULD use all capitals for the 485 method name. Method names SHOULD be less than 10 characters, and 486 SHOULD attempt to convey the general meaning of the request. Method 487 names are case sensitive, and therefore, strictly speaking, they 488 don't have to be capitalized. However, using capitalized method 489 names keeps with a long-standing convention in SIP and many similar 490 protocols, such as HTTP [15] and RTSP [16] 492 Extensions that define new header fields that are anticipated to be 493 heavily used MAY define a compact form if those header fields are 494 more than six characters. "Heavily used" means that the percentage 495 of all emitted messages which contain that header field is over 496 thirty percent. Usage of compact forms in these cases is only a MAY 497 because there are better approaches for reducing message overhead 498 [20]. Compact header fields MUST be a single character. When all 26 499 characters are exhausted, new compact forms will no longer be 500 defined. Header field names are defined by the "token" production in 501 RFC 3261 Section 25.1, and thus include the upper and lowercase 502 letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.), 503 EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_), 504 PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). They 505 SHOULD be descriptive but reasonably brief. Although header field 506 names are case insensitive, a single common capitalization SHOULD be 507 used throughout the document. It is RECOMMENDED that each English 508 word present in the header field name have its first letter 509 capitalized. For example, "ThisIsANewHeader". 511 As an example, the following are poor choices for header field names: 513 ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName 514 --.!A 515 Function 517 Case sensitivity of parameters and values is a constant source of 518 confusion, a difficulty that plagued RFC 2543 [17]. This has been 519 made simple through the usage of the BNF constructs of RFC 2234 [5], 520 which have clear rules of case sensivitity and insensitivity. 521 Therefore, the BNF for an extension completely defines the matching 522 rules. 524 Extensions MUST be consistent with the SIP conventions for case 525 sensitivity. Methods MUST be case sensitive. Header field names 526 MUST be case insensitive. Header field parameter names MUST be case 527 insensitive. Header field values and parameter values are sometimes 528 case sensitive, and sometimes case insensitive. However, generally 529 they SHOULD be case insensitive. Definiting a case sensitive 530 component requires explicitly listing each character through its 531 ASCII code. 533 Extensions which contain freeform text MUST allow that text to be 534 UTF-8, as per the IETF policies on character set usage [3]. This 535 ensures that SIP remains an internationalized standard. As a general 536 guideline, freeform text is never needed by programs in order to 537 perform protocol processing. It is usually entered by and displayed 538 to the user. If an extension uses a parameter which can contain 539 UTF-8 encoded characters, and that extension requires a comparison to 540 be made of this parameter to other parameters, the comparison MUST be 541 case sensitive. Case insensitive comparison rules for UTF-8 text 542 are, at this time, impossible and MUST be avoided. 544 Extensions which make use of dates MUST use the SIP-Date BNF defined 545 in RFC 3261. No other date formats are allowed. However, the usage 546 of absolute dates in order to determine intervals (for example, the 547 time at which some timer fires) is NOT RECOMMENDED. This is because 548 it requires synchronized time between peers, and this is frequently 549 not the case. Therefore, relative times, expressed in numbers of 550 seconds, SHOULD be used. 552 Extensions which include network layer addresses SHOULD permit dotted 553 quad IPv4 addresses, IPv6 addresses in the format described in [4], 554 and domain names. 556 Extensions which have header fields containing URIs SHOULD be 557 explicit about which URI schemes can be used in that header field. 558 Header fields SHOULD allow the broadest set of URI schemes possible 559 that are a match for the semantics of the header field. 561 Header fields MUST follow the standard formatting for SIP, defined 562 as: 564 header = header-name HCOLON header-value 565 *(COMMA header-value) 566 header-name = token 567 header-value = value *(SEMI value-parameter) 568 value-parameter = token [EQUAL gen-value] 569 gen-value = token / host / quoted-string 570 value = token / host / quoted-string 572 In some cases, this form is not sufficient. That is the case for 573 header fields that express descriptive text meant for human 574 consumption. An example is the Subject header field in SIP [2]. In 575 this case, an alternate form is: 577 header = header-name HCOLON [TEXT-UTF8-TRIM] 579 Developers of extensions SHOULD allow for extension parameters in 580 their header fields. 582 Header fields that contain a list of URIs SHOULD follow the same 583 syntax as the Contact header field in SIP. Implementors are also 584 encouraged to always wrap these URI in angle brackets "<" and ">". 585 We have found this to be a frequently misimplemented feature. 587 Beyond compact form, there is no need to define compressed versions 588 of header field values. Compression of SIP messages SHOULD be 589 handled at lower layers, for example, using IP payload compression 590 [18] or signalling compression [20]. 592 Syntax for header fields is expressed in Augmented Backus-Naur Form 593 and MUST follow the format of RFC 2234 [5]. Extensions MUST make use 594 of the primitive components defined in RFC 3261 [2]. If the 595 construction for a BNF element is defined in another specification, 596 it is RECOMMENDED that the construction be referenced rather than 597 copied. The reference SHOULD include both the document and section 598 number. All BNF elements must be either defined or referenced. 600 It is RECOMMENDED that BNF be collected into a single section near 601 the end of the document. 603 All tokens and quoted strings are separated by explicit linear white 604 space. Linear white space, for better or worse, allows for line 605 folding. Extensions MUST NOT define new header fields that use 606 alternate linear white space rules. 608 All SIP extensions MUST verify that any BNF productions that they 609 define in their grammar do not conflict with any existing grammar 610 defined in other SIP standards track specifications. 612 4.5 Semantics, Semantics, Semantics 614 Developers of protocols often get caught up in syntax issues, without 615 spending enough time on semantics. The semantics of a protocol are 616 far more important. SIP extensions MUST clearly define the semantics 617 of the extensions. Specifically, the extension MUST specify the 618 behaviors expected of a UAC, UAS and proxy in processing the 619 extension. This is often best described by having separate sections 620 for each of these three elements. Each section SHOULD step through 621 the processing rules in temporal order of the most common messaging 622 scenario. 624 Processing rules generally specify actions to take (in terms of 625 messages to send, variables to store, rules to follow) on receipt of 626 messages and expiration of timers. If an action requires 627 transmission of a message, the rule SHOULD outline requirements for 628 insertion of header fields or other information in the message. 630 The extension SHOULD specify procedures to take in exceptional 631 conditions which are recoverable, or which require some kind of user 632 intervention. Recovering from unrecoverable problems generally does 633 not require specification. 635 4.6 Examples Section 637 The specification SHOULD contain a section that gives examples of 638 call flows and message formatting. Extensions which define 639 substantial new syntax SHOULD include examples of messages containing 640 that syntax. Examples of message flows should be given to cover 641 common cases and at least one failure or unusual case. 643 For an example of how to construct a good examples section, see the 644 message flows and message formatting defined in the Basic Call Flows 645 specification [21]. Note that complete messages SHOULD be used. Be 646 careful to include tags, Via header fields (with the branch ID 647 cookie), Max-Forwards, Content-Lengths, Record-Route and Route header 648 fields. Example INVITE messages MAY omit session descriptions, and 649 Content-Length values MAY be set to "..." to indicate that the value 650 is not provided. However, the specification MUST explicitly call out 651 the meaning of the "..." and explicitly indicate that session 652 descriptions were not included. 654 4.7 Overview Section 656 Too often, extension documents dive into detailed syntax and 657 semantics without giving a general overview of operation. This makes 658 understanding of the extension harder. It is RECOMMENDED that 659 extensions have a protocol overview section which discusses the basic 660 operation of the extension. Basic operation usually consists of the 661 message flow, in temporal order, for the most common case covered by 662 the extension. The most important processing rules for the elements 663 in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] 664 terminology in the overview section is NOT RECOMMENDED, and the 665 specification should explicitly state that the overview is tutorial 666 in nature only. This section SHOULD expand all acronyms, even those 667 common in SIP systems, and SHOULD be understandable to readers that 668 are not SIP experts. [27] provides additional guidance on writing 669 good overview sections. 671 4.8 IANA Considerations Section 673 Documents which define new SIP extensions will invariably have IANA 674 Considerations sections. 676 If your extension is defining a new event package, you MUST register 677 that package. RFC 3265 [6] provides the registration template. See 678 [22] for an example of the registration of a new event package. As 679 discussed in RFC 3427 [10], only standards track documents can 680 register new event-template packages. Both standards track and 681 informational specifications can register event packages. 683 If your extension is defining a new header field, you MUST register 684 that header field. RFC 3261 [2] provides a registration template. 685 See Section 8.2 of RFC 3262 [23] for an example of how to register 686 new SIP header fields. Both standards track and informational 687 P-header specifications can register new header fields [10]. 689 If your extension is defining a new response code, you MUST register 690 that response code. RFC 3261 [2] provides a registration template. 691 See Section 6.4 of RFC 3329 [19] for an example of how to register a 692 new response code. As discussed in RFC 3427 [10], only standards 693 track documents can register new response codes. 695 If your extension is defining a new SIP method, you MUST register 696 that method. RFC 3261 [2] provides a registration template. See 697 Section 10 of RFC 3311 [24] for an example of how to register a new 698 SIP method. As discussed in RFC 3427 [10], only standards track 699 documents can register new methods. 701 If your extension is defining a new SIP header field parameter, you 702 MUST register that header field parameter per the guidelines in RFC 703 3968 [7]. Section 4.1 of that specification provides a template. 704 Only IETF approved specifications can register new header field 705 parameters. However, there is no requirement that these be standards 706 track. 708 If your extension is defining a new SIP URI parameter, you MUST 709 register that URI parameter per the guidelines in RFC 3969 [8]. 710 Section 4.1 of that specification provides a template. Only 711 standards track documents can register new URI parameters. 713 Many SIP extensions make use of option tags, carried in the Require, 714 Proxy-Require and Supported header fields. Section 4.1 discusses 715 some of the issues involved in the usage of these header fields. If 716 your extension does require them, you MUST register an option tag for 717 your extension. RFC 3261 [2] provides a registration template. See 718 Section 8.1 of RFC 3262 [23] for an example of how to register an 719 option tag. Only standards track RFCs can register new option tags. 721 Some SIP extensions will require establishment of their own IANA 722 registries. RFC 2434 [25] provides guidance on how and when IANA 723 registries are established. For an example of how to set one up, see 724 Section 6 of RFC 3265 [6] for an example. 726 4.9 Document Naming Conventions 728 An important decision to be made about the extension is its title. 729 The title MUST indicate that the document is an extension to SIP. It 730 is RECOMMENDED that the title follow the basic form of "A [summary of 731 function] for the Session Initiation Protocol (SIP)", where the 732 summary of function is a one to three word description of the 733 extension. For example, if an extension defines a new header field, 734 called Make-Coffee, for making coffee, the title would read, "Making 735 Coffee with the Session Initiation Protocol (SIP)". It is 736 RECOMMENDED that these additional words be descriptive rather than 737 naming the header field. For example, the extension for making 738 coffee should not be named "The Make-Coffee Header for the Session 739 Initiation Protocol". 741 For extensions that define new methods, an acceptable template for 742 titles is "The Session Initiation Protocol (SIP) X Method" where X is 743 the name of the method. 745 Note that the acronymn SIP MUST be expanded in the titles of RFCs, as 746 per [26]. 748 4.10 Additional Considerations for New Methods 750 Extensions which define new methods SHOULD take into consideration, 751 and discuss, the following issues: 753 o Can it contain bodies? If so, what is the meaning of the presence 754 of those bodies? What body types are allowed? 756 o Can a transaction with this request method occur while another 757 transaction, in the same and/or reverse direction, is in progress? 759 o The extension MUST define which header fields can be present in 760 requests of that method. It is RECOMMENDED that this information 761 be represented as a new column of Table 2/3 of RFC 3261 [2]. The 762 table MUST contain rows for all header fields defined in standards 763 track RFCs at the time of writing of the extension. 765 o Can the request be sent within a dialog, or does it establish a 766 dialog? 768 o Is it a target refresh request? 770 o Extensions to SIP that define new methods MAY specify whether 771 offers and answers can appear in requests of that method or its 772 responses. However, those extensions MUST adhere to the protocol 773 rules specified in [28], and MUST adhere to the additional 774 constraints for offers and answers as specified in SIP [2]. 776 o Because of the nature of reliability treatment of requests with 777 new methods, those requests need to be answered immediately by the 778 UAS. Protocol extensions that require longer durations for the 779 generation of a response (such as a new method that requires human 780 interaction) SHOULD instead use two transactions - one to send the 781 request, and another in the reverse direction to convey the result 782 of the request. An example of that is SUBSCRIBE and NOTIFY [6]. 784 o The SIP specification [2] allows new methods to specify whether 785 transactions using that new method can be canceled using a CANCEL 786 request. Further study of the non-INVITE transaction [14] has 787 determined that non-INVITE transactions must complete as soon as 788 possible. New methods must not plan for the transaction to pend 789 long enough for CANCEL to be meaningful. Thus, new methods MUST 790 declare that transactions initiated by requests with that method 791 cannot be canceled. Future work may relax this restriction, at 792 which point these guidelines will be revised. 794 o New methods that establish a new dialog must discuss the impacts 795 of forking. The design of such new methods should follow the 796 pattern of requiring an immediate request in the reverse direction 797 from the request establishing a dialog, similar to the immediate 798 NOTIFY sent when a subscription is created per RFC 3265 [6]. 800 The reliability mechanisms for all new methods must be the same as 801 for BYE. The delayed response feature of INVITE is only available in 802 INVITE, never for new methods. The design of new methods must 803 encourage an immediate response. If the application being enabled 804 requires a delay, the design SHOULD follow a pattern using multiple 805 transactions similar to RFC 3265's use of NOTIFYs with different 806 Subscription-State header field values (pending and active in 807 particular) in response to SUBSCRIBE [6]. 809 4.11 Additional Considerations for New Header Fields or Header Field 810 Parameters 812 The most important issue for extensions that define new header fields 813 or header field parameters is backwards compatibility. See Section 814 4.1 for a discussion of the issues. The extension MUST detail how 815 backwards compatibility is addressed. 817 It is often tempting to avoid creation of a new method by overloading 818 an existing method through a header field or parameter. Header 819 fields and parameters are not meant to fundamentally alter the 820 meaning of the method of the request. A new header field cannot 821 change the basic semantic and processing rules of a method. There is 822 no shortage of method names, so when an extension changes the basic 823 meaning of a request, a new method SHOULD be defined. 825 For extensions that define new header fields, the extension MUST 826 define the request methods the header field can appear in, and what 827 responses it can be used in. It is RECOMMENDED that this information 828 be represented as a new row of Table 2/3 of RFC 3261 [2]. The table 829 MUST contain columns for all methods defined in standards track RFCs 830 at time of writing of the extension. 832 4.12 Additional Considerations for New Body Types 834 Because SIP can run over UDP, extensions that specify the inclusion 835 of large bodies (where large is several times the ethernet MTU) are 836 frowned upon unless end-to-end congestion controlled transport can be 837 guaranteed. If at all possible, the content SHOULD be included 838 indirectly [9] even if congestion controlled transports are 839 available. 841 Note that the presence of a body MUST NOT change the nature of the 842 message. That is, bodies cannot alter the state machinery associated 843 with processing a request of a particular method or a response. 844 Bodies enhance this processing by providing additional data. 846 5. Interactions with SIP Features 848 We have observed that certain capabilities of SIP continually 849 interact with extensions in unusual ways. Writers of extensions 850 SHOULD consider the interactions of their extensions with these SIP 851 capabilities, document any unusual interactions if they exist. The 852 most common causes of problems are: 854 Forking: Forking by far presents the most troublesome interactions 855 with extensions. This is generally because it can cause (1) a 856 single transmitted request to be received by an unknown number of 857 UASs, and (2) a single INVITE request to have multiple responses. 859 CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that 860 they are exceptions to many of the general request processing 861 rules. The main reason for this special status is that CANCEL and 862 ACK are always associated with another request. New methods 863 SHOULD consider the meaning of cancellation, as described above. 864 Extensions which defined new header fields in INVITE requests 865 SHOULD consider whether they also need to be included in ACK and 866 CANCEL. Frequently they do, in order to allow a stateless proxy 867 to route the CANCEL or ACK identically to the INVITE. 869 Routing: The presence of Route header fields in a request can cause 870 it to be sent through intermediate proxies. Requests that 871 establish dialogs can be record-routed, so that the initial 872 request goes through one set of proxies, and subsequent requests 873 through a different set. These SIP features can interact in 874 unusual ways with extensions. 876 Stateless Proxies: SIP allows a proxy to be stateless. Stateless 877 proxies are unable to retransmit messages and cannot execute 878 certain services. Extensions which depend on some kind of proxy 879 processing SHOULD consider how stateless proxies affect that 880 processing. 882 6. Security Considerations 884 The nature of this document is such that it does not introduce any 885 new security considerations. However, many of the principles 886 described in the document affect whether a potential SIP extension 887 design is likely to support the SIP security architecture. 889 7. IANA Considerations 891 There are no IANA considerations associated with this specification. 893 8. Acknowledgements 895 The authors would like to thank Rohan Mahy and Spencer Dawkins for 896 their comments. Robert Sparks contributed important text on CANCEL 897 issues. Thanks to Allison Mankin for her support. 899 9. References 901 9.1 Normative References 903 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 904 Levels", BCP 14, RFC 2119, March 1997. 906 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 907 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 908 Session Initiation Protocol", RFC 3261, June 2002. 910 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 911 BCP 18, RFC 2277, January 1998. 913 [4] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 914 IPv6 Addresses in URL's", RFC 2732, December 1999. 916 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 917 Specifications: ABNF", RFC 2234, November 1997. 919 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 920 Notification", RFC 3265, June 2002. 922 [7] Camarillo, G., "The Internet Assigned Number Authority (IANA) 923 Header Field Parameter Registry for the Session Initiation 924 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 926 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) 927 Uniform Resource Identifier (URI) Parameter Registry for the 928 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 929 2004. 931 [9] Burger, E., "A Mechanism for Content Indirection in Session 932 Initiation Protocol (SIP) Messages", 933 draft-ietf-sip-content-indirect-mech-05 (work in progress), 934 October 2004. 936 9.2 Informative References 938 [10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 939 Rosen, "Change Process for the Session Initiation Protocol 940 (SIP)", BCP 67, RFC 3427, December 2002. 942 [11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 943 March 1997. 945 [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer 946 Method", RFC 3515, April 2003. 948 [13] Donovan, S. and J. Rosenberg, "Session Timers in the Session 949 Initiation Protocol (SIP)", draft-ietf-sip-session-timer-15 950 (work in progress), August 2004. 952 [14] Sparks, R., "Problems identified associated with the Session 953 Initiation Protocol's non-INVITE Transaction", 954 draft-sparks-sip-nit-problems-02 (work in progress), January 955 2005. 957 [15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 958 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 959 HTTP/1.1", RFC 2616, June 1999. 961 [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 962 Protocol (RTSP)", RFC 2326, April 1998. 964 [17] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 965 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 967 [18] Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP 968 Payload Compression Protocol (IPComp)", RFC 3173, September 969 2001. 971 [19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. 972 Haukka, "Security Mechanism Agreement for the Session 973 Initiation Protocol (SIP)", RFC 3329, January 2003. 975 [20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. 976 and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, 977 January 2003. 979 [21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 980 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 981 Examples", BCP 75, RFC 3665, December 2003. 983 [22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 984 Package for Registrations", RFC 3680, March 2004. 986 [23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 987 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 988 2002. 990 [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 991 Method", RFC 3311, October 2002. 993 [25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 994 Considerations Section in RFCs", BCP 26, RFC 2434, October 995 1998. 997 [26] Reynolds, J. and R. Braden, "Instructions to Request for 998 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work 999 in progress), July 2004. 1001 [27] Rescorla, E., "Writing Protocol Models", draft-iab-model-02 1002 (work in progress), September 2004. 1004 [28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1005 Session Description Protocol (SDP)", RFC 3264, June 2002. 1007 Authors' Addresses 1009 Jonathan Rosenberg 1010 Cisco Systems 1011 600 Lanidex Plaza 1012 Parsippany, NJ 07054 1013 US 1015 Phone: +1 973 952-5000 1016 EMail: jdrosen@cisco.com 1017 URI: http://www.jdrosen.net 1019 Henning Schulzrinne 1020 Columbia University 1021 M/S 0401 1022 1214 Amsterdam Ave. 1023 New York, NY 10027 1024 US 1026 EMail: schulzrinne@cs.columbia.edu 1027 URI: http://www.cs.columbia.edu/~hgs 1029 Intellectual Property Statement 1031 The IETF takes no position regarding the validity or scope of any 1032 Intellectual Property Rights or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; nor does it represent that it has 1036 made any independent effort to identify any such rights. Information 1037 on the procedures with respect to rights in RFC documents can be 1038 found in BCP 78 and BCP 79. 1040 Copies of IPR disclosures made to the IETF Secretariat and any 1041 assurances of licenses to be made available, or the result of an 1042 attempt made to obtain a general license or permission for the use of 1043 such proprietary rights by implementers or users of this 1044 specification can be obtained from the IETF on-line IPR repository at 1045 http://www.ietf.org/ipr. 1047 The IETF invites any interested party to bring to its attention any 1048 copyrights, patents or patent applications, or other proprietary 1049 rights that may cover technology that may be required to implement 1050 this standard. Please address the information to the IETF at 1051 ietf-ipr@ietf.org. 1053 Disclaimer of Validity 1055 This document and the information contained herein are provided on an 1056 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1057 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1058 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1059 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1060 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1061 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1063 Copyright Statement 1065 Copyright (C) The Internet Society (2005). This document is subject 1066 to the rights, licenses and restrictions contained in BCP 78, and 1067 except as set forth therein, the authors retain all their rights. 1069 Acknowledgment 1071 Funding for the RFC Editor function is currently provided by the 1072 Internet Society.