idnits 2.17.1 draft-rosenberg-sip-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 204: '... RECOMMENDED....' RFC 2119 keyword, line 238: '... MUST mandate the usage of the Requi...' RFC 2119 keyword, line 261: '... RECOMMENDED. The less freque...' RFC 2119 keyword, line 265: '...y-Require header SHOULD be avoided at ...' RFC 2119 keyword, line 284: '...obing" mechanism SHOULD generally be d...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (March 10, 2000) is 8813 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) -- Missing reference section? '1' on line 537 looks like a reference -- Missing reference section? '2' on line 541 looks like a reference -- Missing reference section? '3' on line 545 looks like a reference -- Missing reference section? '4' on line 549 looks like a reference -- Missing reference section? '5' on line 552 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J.Rosenberg,H.Schulzrinne 4 draft-rosenberg-sip-guidelines-00.txt dynamicsoft,Columbia U. 5 March 10, 2000 6 Expires: September, 2000 8 Guidelines for Authors of SIP Extensions 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Session Initiation Protocol (SIP) is a flexible, yet simple tool 34 for establishing interactive connections across the Internet. Part of 35 this flexibility is the ease with which it can be extended. In order 36 to facilitate effective and interoperable extensions to SIP, some 37 guidelines need to be followed when developing SIP extensions. This 38 document outlines a set of such guidelines for authors of SIP 39 extensions. 41 1 Introduction 43 The Session Initiation Protocol (SIP) [1] is a flexible, yet simple 44 tool for establishing interactive connections across the Internet. 45 Part of this flexibility is the ease with which it can be extended. 46 SIP can be extended in numerous ways. New methods can be defined, new 47 headers can be added, new body types can be used, and new parameters 48 for existing headers can be added. This flexibility also means that 49 caution should be exercised when defining extensions, in order to 50 ensure interoperability. 52 In order to facilitate interoperability, this document serves as a 53 set of guidelines for authors of SIP extensions. It points out issues 54 to consider when deciding whether a SIP extension is the right answer 55 for a specific problem. It then points out issues which extensions 56 should deal with from within the specification. Finally, it discusses 57 common interactions with existing SIP features which often cause 58 difficulties in extensions. 60 2 Should I define a SIP Extension? 62 The first question to be addressed when defining a SIP extension is: 63 is a SIP extension the best solution to my problem? SIP has been 64 proposed as a solution for numerous problems, including mobility, 65 configuration and management, QoS control, call control, caller 66 preferences, device control, third party call control, and MPLS path 67 setup, to name a few. Clearly, not every problem can be solved by a 68 SIP extension. More importantly, some problems that could be solved 69 by a SIP extension, probably shouldn't. 71 To assist engineers in determining whether a SIP extension is an 72 appropriate solution to their problem, we present two broad criteria. 73 First, the problem should fit into the general purvey of SIPs 74 solution space. Secondly, the solution must conform to the general 75 SIP architectural model. 77 While the first criteria might seem obvious, we have observed that 78 numerous extensions to SIP have been proposed because some function 79 is needed in a device which also speaks SIP. The argument is 80 generally given that "I'd rather implement one protocol than many". 81 As an example, user agents, like all other IP hosts, need some way to 82 obtain their IP address. This is generally done through DHCP [2]. 83 SIPs multicast registration mechanisms might supply an alternate way 84 to obtain an IP address. This would eliminate the need for DHCP in 85 clients. However, we do not believe such extensions are appropriate. 86 We believe that protocols should be defined to provide specific, 87 narrow functions, rather than being defined based on all 88 communications requirements between a pair of devices. The latter 89 approach to protocol design yields modular protocols with broad 90 application. It also facilitates extensibility and growth; single 91 protocols can be removed and changed without affecting the entire 92 system. We observe that this approach to protocol engineering mirrors 93 object oriented software engineering. 95 Our second criteria, that the extension must conform to the general 96 SIP architectural model, ensures that the protocol remains manageable 97 and broadly applicable. 99 2.1 SIP's Solution Space 101 In order to evaluate the first criteria, it is necessary to define 102 exactly what SIPs solution space is, and what it is not. 104 SIP is a protocol for initiating, modifying, and terminating 105 interactive sessions. This process involves the discovery of a user 106 wherever they may be located, so that a description of the session 107 can be delivered to the user. SIP itself is independent of the 108 session, and the session description is delivered as an opaque body. 109 Much of SIP focuses on this discovery component. Its ability to fork, 110 its registration capabilities, and its routing capabilities are all 111 present for the singular purpose of finding the called user wherever 112 they may be. As such, features and capabilities such as personal 113 mobility, automatic call distribution, and follow-me are well within 114 the SIP solution space. 116 Session initiation also depends on the ability of the called party to 117 have enough information about the session itself in order to make a 118 decision on whether to join or not. That information includes data 119 about the caller, the purpose for the invitation, and parameters of 120 the session itself. For this reason, SIP includes this kind of 121 information. 123 Part of the process of session initiation is the communication of 124 progress and the final results of establishment of the session. SIP 125 provides this information as well. 127 There are many functions that SIP explicitly does not provide. It is 128 not a session management protocol or a conference control protocol. 129 The particulars of the communications within the session are outside 130 of SIP. This includes features such as media transport, voting and 131 polling, virtual microphone passing, chairman election, floor 132 control, and feedback on session quality. 134 SIP is not a resource reservation protocol for sessions. This is 135 fundamentally because (1) SIP is independent of the underlying 136 session it establishes, and (2) the path of SIP messages is 137 completely independent from the path that packets for a session may 138 take. The path independence refers to paths within a providers 139 network, and the set of providers itself. For example, it is 140 perfectly reasonable for a SIP message to traverse a completely 141 different set of autonomus systems than the audio in a session SIP 142 establishes. 144 SIP is not a transfer protocol. It is not meant to send large amounts 145 of data unrelated to SIPs operation. It is not meant as a replacement 146 for HTTP. This is for numerous reasons, one of which is that SIP's 147 recommended mode of operation is over UDP. Sending large messages 148 over SIP can lead to fragmentation at the IP layer and thus poor 149 performance in even mildly lossy networks. This is not to say that 150 carrying payloads in SIP messages is never a good thing; in many 151 cases, the data is very much related to SIPs operation. However, SIP 152 is not meant to carry large amounts of data unrelated to SIPs general 153 function. 155 2.2 SIP Architectural Model 157 We describe here some of the primary architectual assumptions which 158 underly SIP. Extensions which violate these assumptions should be 159 examined more carefully to determine their appropriateness for SIP. 161 Session independence: SIP is independent of the session it 162 establishes. This includes the type of session, be it 163 audio, video, game, chat session, or virtual reality. SIP 164 operation should never be dependent on some characteristic 165 of the session. 167 SIP and Session Path Independence: We have already touched on 168 this once, but it is worth noting again. The set of routers 169 and/or networks and/or autonomous systems traversed by SIP 170 messages and the packets in the session are unrelated. They 171 may be the same in some cases, bit it is fundamental to 172 SIPs architecture that they need not be the same. 173 Extensions which only work under some assumption of overlap 174 are not generally applicable to SIPs operation and should 175 be scrutinized carefully. 177 Multi-provider and Multi-hop: SIP assumes that its messages will 178 traverse the "Big I". That is, SIP works through multiple 179 networks administered by different providers. It is also 180 assumed that SIP messages traverse many hops (where each 181 hop is a proxy). Extensions which only work in single hop 182 or single provider networks may not be appropriate for SIP. 184 Transactional: SIP is a request/response protocol. Many of the 185 rules of operation in SIP are based on general processing 186 of requests and responses. This includes the reliability 187 mechanisms, routing mechanisms, and state maintenance 188 rules. Extensions which add new messages that are not 189 within the request-response model will likely break many 190 aspects of SIP. 192 Proxies can ignore bodies: In order for proxies to scale well, 193 they must be able to operate with minimal message 194 processing. SIP has been engineered so that proxies can 195 always ignore bodies. Extensions which require proxies to 196 examine bodies in order to work will likely lead to serious 197 scaling problems. 199 Proxies don't need to understand the method: Processing of 200 requests in proxies does not depend on the method, except 201 for the well known methods INVITE, ACK, and CANCEL. This 202 allows for extensibility. Extensions that define new 203 methods which must be understood by proxies are NOT 204 RECOMMENDED. 206 INVITE messages carry full state: An initial INVITE message for 207 a session is nearly identical (the exception is the tag) to 208 a re-INVITE message to modify some characteristic of the 209 session. This is strongly coupled to the idempotency of SIP 210 requests, but is a different characteristic. Extensions 211 which modify INVITE processing such that data spanning 212 multiple INVITEs must be collected in order to perform some 213 feature, are frowned upon. 215 Generality over efficiency: Wherever possible, SIP has favored 216 general purpose components rather than narrow ones. If some 217 capability is added to support one service, but a slightly 218 broader capability can support a larger variety of services 219 (at the cost of complexity or message sizes), the broader 220 capability is generally preferred. 222 3 Issues to be Addressed 224 Given an extension has met the litmus tests in the previous section, 225 there are several issues that all extension should take into 226 consideration. 228 3.1 Backwards Compatibility 230 One of the most important issues to consider is whether the new 231 extension is backwards compatible with baseline SIP. This is tightly 232 coupled with how the Require, Proxy-Require, and Supported [3] 233 headers are used. 235 If an extension consists of new headers inserted by a user agent in a 236 request, and the request cannot be processed reasonably by a proxy 237 and/or user agent without understanding the headers, the extension 238 MUST mandate the usage of the Require and/or Proxy-Require headers in 239 the request. These extensions are not backwards compatible with SIP. 241 The result of mandating usage of these headers means that requests 242 cannot be serviced unless the entities being communicated with also 243 understand the extension. If some entity does not understand the 244 extension, the request will be rejected. The UAC can then handle this 245 in one of two ways. In the first, the request simply fails, and the 246 service cannot be provided. This is basically an interoperability 247 failure. In the second case, the UAC retries the request without the 248 extension. This will preserve interoperability, at the cost of a 249 "dual stack" implementation in a UAC (processing rules for operation 250 with and without the extension). As the number of extensions 251 increases, this leads to an exponential explosion in the sets of 252 processing rules a UAC may need to implement. The result is excessive 253 complexity. 255 Because of the possibility of interoperability and complexity 256 problems that result from the usage of Require and Proxy-Require, we 257 believe the following guidelines are appropriate: 259 o The usage of these headers in requests for basic SIP services 260 (in particular, session initiation and termination) is NOT 261 RECOMMENDED. The less frequently a particular extension is 262 needed in a request, the more reasonable it is to use these 263 headers. 265 o The Proxy-Require header SHOULD be avoided at all costs. As 266 the number of hops for a request increases, the likelihood a 267 particular proxy doesn't support some extension increases 268 exponentially. On the other hand, the Require header only 269 mandates that a single entity, the UAS, support the extension. 270 Usage of Proxy-Require is thus considered exponentially worse 271 than usage of the Require header. 273 Extensions which define new methods do not need to use the Require 274 header. SIP defines mechanisms which allow a UAC to know whether a 275 new method is understood by a UAS. This includes both the OPTIONS 276 request, and the 405 (Method Not Allowed) response with the Accept 277 header. It is fundamental to SIP that proxies do not need to 278 understand the semantics of a new method in order to process it. If 279 an extension defines a new method which must be understood by proxies 280 in order to be processed, a Proxy-Require header is needed. As 281 discussed above, these kinds of extensions are frowned upon. 283 In order to achieve backwards compatibility for extensions that 284 define new methods, a "probing" mechanism SHOULD generally be defined 285 as an integral component of the extension. In this mechanism, some 286 header is included by the UAC in a standard SIP request. The UAS 287 places some information in the response if it understands this header 288 (and thus, the extension). If the UAC sees this information in the 289 response, it knows it is safe to send a request with the new method. 291 Another type of extension are those which require a proxy to insert 292 headers into a request as it traverses the network, or for the UAS to 293 insert headers into a response. Some extensions can simply insert 294 these headers. If the UAC or UAS does not understand them, the 295 message can still be processed correctly. These extensions are 296 completely backwards compatible. 298 Most other extensions of this type will need to make use of the 299 Supported request header mechanism. This mechanism allows a server to 300 determine if the client can understand some extension applied to the 301 response. If an extension is such that it requires a server to insert 302 information into a response which must be understood in order for the 303 response to be correctly processed, that extension SHOULD make use of 304 [3]. By their nature, these extensions may not always be able to be 305 applied to every response. 307 If an extension requires a proxy to insert a header into a request, 308 and this header needs to be understood by both UAC and UAS to be 309 executed correctly, a combination of the probing mechanism above, and 310 the Supported mechanism will need to be used. An example of such an 311 extension is the SIP Session Timer [4]. 313 Yet another type of extension are those which define new body types 314 to be carried in SIP messages. If the body type is to be conveyed in 315 a request without usage of multipart, the compatibility issues mirror 316 those of new methods. A probing mechanism is RECOMMENDED to determine 317 if the body type is understood. If a body type is to be conveyed in a 318 response, that type MUST only be sent if support for it was indicated 319 in an Accept header in the request. If the body type is to be 320 conveyed in a request with multipart, that body can either be 321 mandatory or optional. Mandatory implies that the request cannot be 322 processed unless the body is understood. Optional implies that the 323 request can be processed if the body is understood. It is RECOMMENDED 324 that extensions specify optional bodies if at all possible. 326 We note that there is no defined way right now through MIME 327 headers to indicate whether a body is mandatory or 328 optional. This can be accomplished through a Require 329 header, but a MIME parameter somehow seems more appropriate 331 3.2 Security 333 Security is an important component of any protocol. SIP extensions 334 SHOULD consider how (or if) they affect usage of the general SIP 335 security mechanisms. Most extensions should not require any new 336 security capabilities beyond general purpose SIP. If they do, it is 337 likely that the security mechanism has more general purpose 338 application, and should be considered an extension in its own right. 340 3.3 Usage Guidelines 342 All SIP extensions MUST contain guidelines defining when the 343 extension is to be used. 345 For new headers, the extension MUST define the request methods the 346 header can appear in, and what responses it can be used in. It is 347 RECOMMENDED that this information be represented as a new row of 348 Table 4 of RFC 2543 [1]. The extension SHOULD specify which entities 349 (UAC, UAS, proxy, redirect, registrar) are allowed to insert the 350 header. 352 3.4 Syntactic Issues 354 Extensions that define new methods SHOULD use all capitals for the 355 method name. Method names SHOULD be less than 10 characters, and 356 SHOULD attempt to convey the general meaning of the request. 358 Extensions that define new headers SHOULD define a compact form 359 representation if the non-compact header is more than four 360 characters. 362 Case sensitivity of parameters and values is a constant source of 363 confusion. SIP extensions MUST clearly indicate the case sensitivity 364 or insensitivity of every parameter, value or field they define. In 365 general, case sensitivity is preferred because of the reduced 366 processing requirements. 368 Extensions which contain freeform text MUST allow that text to be 369 UTF-8. This ensures that SIP remains an internationalized standard. 370 As a general guideline, freeform text is never needed by programs in 371 order to perform protocol processing. It is usually entered by and 372 displayed to the user. If an extension uses a parameter which can 373 contain UTF-8 encoded characters, and that extension requires a 374 comparison to be made of this parameter to other parameters, the 375 comparison MUST be case sensitive. Case insensitive comparison rules 376 for UTF-8 text are extremely complicated and are to be avoided. 378 Extensions which make use of dates and times MUST use the SIP-Date 379 BNF defined in RFC 2543. No other date formats are allowed. 381 Extensions which include network layer addresses SHOULD permit dotted 382 quad IPv4 addresses, IPv6 addresses in the format described in , and 383 domain names. 385 Extensions which have headers containing URLs SHOULD allow any URI, 386 not just SIP URLs. 388 3.5 Semantics, Semantics, Semantics 390 Developers of protocols often get caught up in syntax issues, without 391 spending enough time on semantics. The semantics of a protocol are 392 far more important. SIP extensions MUST clearly define the semantics 393 of the extensions. Specifically, the extension MUST specify the 394 behaviors expected of a UAC, UAS and proxy in processing the 395 extension. This is often best described by having separate sections 396 for each of these three elements. Each section SHOULD step through 397 the processing rules in temporal order of the most common messaging 398 scenario. 400 Processing rules generally specify actions to take (in terms of 401 messages to send, variables to store, rules to follow) on receipt of 402 messages and expiration of timers. If an action requires transmission 403 of a message, the rule SHOULD outline requirements for insertion of 404 headers or other information in the message. 406 The extension SHOULD specify procedures to take in exceptional 407 conditions. This usually includes receipt of messages that are not 408 expected, expiration of timers that handle timeouts, and presence of 409 headers in messages when they are not expected. 411 3.6 Examples Section 413 Presence of sections in the extension giving examples of call flows 414 and message formatting is RECOMMENDED. Extensions which define 415 substantial new syntax SHOULD include examples of messages containing 416 that syntax. Examples of message flows SHOULD be given to cover 417 common cases and at least one failure or unusual case. 419 3.7 Overview Section 421 Too often, extension documents dive into detailed syntax and 422 semantics without giving a general overview of operation. This makes 423 understanding of the extension harder. It is RECOMMENDED that 424 extensions have a protocol overview section which discusses the basic 425 operation of the extension. Basic operation usually consists of the 426 message flow, in temporal order, for the most common case covered by 427 the extension. The most important processing rules for the elements 428 in the call flow SHOULD be mentioned. Usage of the RFC 2119 [5] 429 terminology in the overview section is RECOMMENDED. 431 3.8 Additional Considerations for New Methods 432 Extensions which define new methods SHOULD take into consideration, 433 and discuss, the following issues: 435 o Can it contain bodies? If so, what is the meaning of the 436 presence of those bodies? What body types are allowed? 438 o Can a transaction with this request method occur while another 439 transaction, in the same and/or reverse direction, is in 440 progress? 442 o What headers are allowed in requests of this method? It is 443 recommended that this information be presented through a 444 column of Table 4 in RFC 2543 [1]. 446 o All SIP requests can generally be cancelled. However, an 447 extension MAY mandate that a new method not be cancelled. In 448 either case, handling of CANCEL SHOULD be described. In 449 particular, the rules a UAS should follow upon cancellation of 450 an unanswered request SHOULD be described. 452 o Can the request be sent within a call or not? In this context, 453 within means that the request is sent with the same Call-ID, 454 To and From field as an INVITE that was sent or received 455 previously. For, example, the REGISTER method is not 456 associated with a call, whereas the BYE method is. 458 3.9 Additional Considerations for New Headers or Header Parameters 460 The most important issue for extensions that define new headers is 461 backwards compatibility. See Section 3.1 for a discussion of the 462 issues. The extension MUST detail how backwards compatibility is 463 addressed. 465 It is often tempting to avoid creation of a new method by overloading 466 an existing method through a header. Headers are not meant to 467 fundamentally alter the meaning of the method of the request. A new 468 header SHOULD NOT change the basic semantic and processing rules of a 469 method. 471 3.10 Additional Considerations for New Body Types 473 Because SIP can run over UDP, extensions that specify the inclusion 474 of large bodies are frowned upon. If at all possible, the content 475 should be included indirectly through an http URL. 477 4 Interactions with SIP Features 479 We have observed that certain capabilities of SIP continually 480 interact with extensions in unusual ways. Writers of extensions 481 SHOULD consider the interactions of their extensions with these SIP 482 capabilities, document any unusual interactions if they exist. The 483 most common causes of problems are: 485 Forking: Forking by far presents the most troublesome 486 interactions with extensions. This is generally because it 487 can cause (1) a single transmitted request to be received 488 by an unknown number of UASs, and (2) a single request to 489 have multiple responses. 491 Tags: Tags are used to uniquely identify call legs. Their 492 presence is neccesitated as a result of forking. They are 493 an unfortunate exception to many SIP processing rules. 494 Extensions should carefully consider their effect. 496 CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in 497 that they are exceptions to many of the general request 498 processing rules. That is because CANCEL and ACK are always 499 associated with another request. New methods SHOULD 500 consider the meaning of cancellation. New headers in INVITE 501 requests SHOULD consider whether they also need to be 502 included in ACK. 504 Routing: The Route, Record-Route and Via headers are used to 505 support message routing. New request methods SHOULD 506 carefully consider how these headers are used. 508 Stateless Proxies: SIP allows a proxy to be stateless. Stateless 509 proxies are unable to retransmit messages and cannot 510 execute certain services. Extensions which depend on some 511 kind of proxy processing SHOULD consider how stateless 512 proxies affect that processing. 514 5 Security Considerations 516 The nature of this document is such that it does not introduce any 517 new security considerations. 519 6 Authors Addresses 521 Jonathan Rosenberg 522 dynamicsoft 523 200 Executive Drive 524 Suite 120 525 West Orange, NJ 07052 526 email: jdrosen@dynamicsoft.com 528 Henning Schulzrinne 529 Columbia University 530 M/S 0401 531 1214 Amsterdam Ave. 532 New York, NY 10027-7003 533 email: schulzrinne@cs.columbia.edu 535 7 Bibliography 537 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 538 session initiation protocol," Request for Comments (Proposed 539 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 541 [2] R. Droms, "Dynamic host configuration protocol," Request for 542 Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar. 543 1997. 545 [3] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support 546 by servers," Internet Draft, Internet Engineering Task Force, Jan. 547 2000. Work in progress. 549 [4] S. Donovan, "SIP session timer," Internet Draft, Internet 550 Engineering Task Force, Oct. 1999. Work in progress. 552 [5] S. Bradner, "Key words for use in RFCs to indicate requirement 553 levels," Request for Comments (Best Current Practice) 2119, Internet 554 Engineering Task Force, Mar. 1997. 556 Full Copyright Statement 558 Copyright (c) The Internet Society (2000). All Rights Reserved. 560 This document and translations of it may be copied and furnished to 561 others, and derivative works that comment on or otherwise explain it 562 or assist in its implementation may be prepared, copied, published 563 and distributed, in whole or in part, without restriction of any 564 kind, provided that the above copyright notice and this paragraph are 565 included on all such copies and derivative works. However, this 566 document itself may not be modified in any way, such as by removing 567 the copyright notice or references to the Internet Society or other 568 Internet organizations, except as needed for the purpose of 569 developing Internet standards in which case the procedures for 570 copyrights defined in the Internet Standards process must be 571 followed, or as required to translate it into languages other than 572 English. 574 The limited permissions granted above are perpetual and will not be 575 revoked by the Internet Society or its successors or assigns. 577 This document and the information contained herein is provided on an 578 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 579 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 580 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 581 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 582 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.