idnits 2.17.1 draft-ietf-sipping-dialogusage-01.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1124. ** 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) 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 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 2, 2006) is 6628 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) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-06 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Estacado Systems 4 Expires: September 3, 2006 March 2, 2006 6 Multiple Dialog Usages in the Session Initiation Protocol 7 draft-ietf-sipping-dialogusage-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 3, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Several methods in the Session Initiation Protocol can create an 41 association between endpoints known as a dialog. Some of these 42 methods can also create a different, but related, association within 43 an existing dialog. These multiple associations, or dialog usages, 44 require carefully coordinated processing as they have independent 45 life-cycles, but share common dialog state. 47 This memo argues that multiple dialog usages should be avoided. It 48 discusses alternatives to their use and clarifies essential behavior 49 for elements that cannot currently avoid them. 51 This is an informative document and makes no normative statements of 52 any kind. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 3 58 2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5 60 3. Usage Creation and Destruction . . . . . . . . . . . . . . . . 8 61 3.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 8 63 4. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 8 64 4.1. A survey of the effect of failure responses on usages 65 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 15 67 4.3. Matching requests to usages . . . . . . . . . . . . . . . 15 68 4.4. Target refresh requests . . . . . . . . . . . . . . . . . 16 69 4.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17 70 4.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 17 71 4.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 17 72 5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 17 73 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 75 8. Informative References . . . . . . . . . . . . . . . . . . . . 23 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 77 A.1. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 24 78 A.2. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 24 79 A.3. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 24 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 Intellectual Property and Copyright Statements . . . . . . . . . . 26 83 1. Introduction 85 Several methods in SIP can establish a dialog. When they do so, they 86 also establish an association between the endpoints within that 87 dialog. This assocation has been known for some time as a "dialog 88 usage" in the developer community. A dialog initiated with an INVITE 89 request has an invite usage. A dialog initiated with a SUBSCRIBE 90 request has a subscribe usage. A dialog initiated with a REFER 91 request has a subscribe usage. 93 Dialogs with multiple usages arise when a usage-creating action 94 occurs inside an existing dialog. Susch actions include accepting a 95 REFER or SUBSCRIBE issued inside a dialog established with an INVITE 96 request. Multiple REFERs within a dialog create multiple 97 subscriptions, each of which is a new dialog usage sharing common 98 dialog state. 100 The common state in the dialog shared by any usages is exactly: 101 o the Call-ID 102 o the local Tag 103 o the remote Tag 104 o the local CSeq 105 o the remote CSeq 106 o the Route-set 107 o the local contact 108 o the remote target 110 Usages have state that is not shared in the dialog. For example, a 111 subscription has a duration. Multiple subscriptions in the same 112 dialog each have thier own duration. 114 A dialog comes into existence with the creation of the first usage, 115 and continues to exist until the last usage is terminated (reference 116 counting). Unfortunately, many of the usage management aspects of 117 SIP, such as authentication, were originally designed with the 118 implicit assumption that there was one usage per dialog. The 119 resulting mechanisms have mixed effects, some influencing the usage, 120 and some influencing the entire dialog. 122 The current specifications define two usages, invite and subscribe. 123 A dialog can share up to one invite usage and arbitrarily many 124 subscribe usages. The pseudo-dialog behavior of REGISTER could be 125 considered a third usage. Fortunately, no existing implementations 126 have attempted to mix a registration usage with any other usage. 128 2. Examples of Multiple Usages 129 2.1. Transfer 131 In Figure 1, Alice transfers a call she received from Bob to Carol. 132 A dialog (and an invite dialog usage) between Alice and Bob came into 133 being with the 200 OK labeled F1. A second usage (a subscription to 134 event refer) springs into being with the NOTIFY labeled F2. This 135 second usage ends when the subscription is terminated by the NOTIFY 136 transaction labeled F3. The dialog still has one usage (the invite 137 usage), which lasts until the BYE transaction labeled F4. At this 138 point, the dialog has no remaining usages, so it ceases to exist. 140 Alice Bob Carol 141 | INVITE | | 142 |<----------------| | 143 Dialog 1 Usage 1 | 200 OK (F1) | | 144 -start- -start- ----------->|---------------->| | 145 | | | ACK | | 146 | | |<----------------| | 147 | | | reINVITE/200/ACK| | 148 | | | (hold) | | 149 | | |---------------->| | 150 | | | REFER | | 151 | | Dialog 1 |---------------->| | 152 | | Usage 2 | NOTIFY (F2) | | 153 | | -start- -->|<----------------| INVITE | 154 | | | | 200 NOTIFY |----------->| 155 | | | |---------------->| 200 OK | 156 | | | | 200 REFER |<-----------| 157 | | | |<----------------| ACK | 158 | | | | NOTIFY (F3) |----------->| 159 | | | |<----------------| | 160 | | | | 200 | . | 161 | | -end- -->|---------------->| . | 162 | | | BYE (F4) | Dialog 2 | 163 | | |<----------------| proceeds | 164 | | | 200 | . | 165 -end- -end- ------------>|---------------->| . | 167 Message Details (abridged to show only dialog or usage details) 168 F1 169 SIP/2.0 200 OK 170 Call-ID: dialog1@bob.example.com 171 CSeq: 100 INVITE 172 To: ;tag=alicetag1 173 From: ;tag=bobtag1 174 Contact: 176 F2 177 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 178 Event: refer 179 Call-ID: dialog1@bob.example.com 180 CSeq: 101 NOTIFY 181 To: ;tag=alicetag1 182 From: ;tag=bobtag1 183 Contact: 185 F3 186 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 187 Event: refer 188 Subscription-State: terminated;reason=noresource 189 Call-ID: dialog1@bob.example.com 190 CSeq: 102 NOTIFY 191 To: ;tag=alicetag1 192 From: ;tag=bobtag1 193 Contact: 194 Content-Type: message/sipfrag 196 SIP/2.0 200 OK 198 F4 200 BYE sip:aliceinstance@alice.example.com SIP/2.0 201 Call-ID: dialog1@bob.example.com 202 CSeq: 103 BYE 203 To: ;tag=alicetag1 204 From: ;tag=bobtag1 205 Contact: 207 Figure 1 209 2.2. Reciprocal Subscription 211 In Figure 2, Alice subscribes to Bob's presence. For simplicity, 212 assume Bob and Alice are both serving their presence from their 213 endpoints instead of a presence server. For space, the figure leaves 214 out any rendezvous signaling through which Alice discovers Bob's 215 endpoint. 217 Bob is interested in Alice's presence too, so he subscribes to Alice 218 (in most deployed presence/IM systems, people watch each other). He 219 decides skip the rendezvous step since he's already in a dialog with 220 Alice, and sends his SUBSCRIBE inside that dialog (a few early SIMPLE 221 clients behaved exactly this way). 223 The dialog and its first usage comes into being at F1, which 224 establishes Alice's subscription to Bob. Its second usage begins at 225 F2, which establishes Bob's subscription to Alice. These two 226 subscriptions are independent - they have distinct and different 227 expirations, but they share all the dialog state. 229 The first usage ends when Alice decides to unsubscribe at F3. Bob's 230 subscription to Alice, and thus the dialog, continues to exist. 231 Alice's UA must maintain this dialog state even though the 232 subscription that caused it to exist in the first place is now over. 233 The second usage ends when Alice decides to terminate Bob's 234 subscription at F4 (she's probably going to reject any attempt on 235 Bob's part to resubscribe until she's ready to subscribe to Bob 236 again). Since this was the last usage, the dialog also terminates. 238 Alice Bob 239 | | 240 | SUBSCRIBE | 241 |------------------->| 242 Dialog Usage 1 | NOTIFY (F1) | 243 -start- -start- --------->|<-------------------| 244 | | | 200 SUBSCRIBE | 245 | | |<-------------------| 246 | | | 200 NOTIFY | 247 | | |------------------->| 248 | | | SUBSCRIBE | 249 | | |<-------------------| 250 | | Usage 2 | NOTIFY (F2) | 251 | | -start- -->|------------------->| 252 | | | | 200 SUBSCRIBE 253 | | | |------------------->| 254 | | | | 200 NOTIFY | 255 | | | |<-------------------| 256 | | | | : | 257 | | | | : | 258 | | | | (un)SUBSCRIBE (F3) | 259 | | | |------------------->| 260 | | | | 200 | 261 | -end- ---------->|<-------------------| 262 | | | NOTIFY | 263 | | |<-------------------| 264 | | | 200 | 265 | | |------------------->| 266 | | | : | 267 | | | : | 268 | | | NOTIFY (F4) | 269 | | | (Terminated) | 270 | | |------------------->| 271 | | | 200 | 272 -end- -end- -->|<-------------------| 273 | | 275 Message Details (abridged to show only dialog or usage details) 276 F1 277 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 278 Event: presence 279 Subscription-State: active;expires=600 280 Call-ID: alicecallid1@alice.example.com 281 From: ;tag=bobtag2 282 To: ;tag=alicetag2 283 CSeq: 100 NOTIFY 284 Contact: 286 F2 287 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 288 Event: presence 289 Subscription-State: active;expires=1200 290 Call-ID: alicecallid1@alice.example.com 291 To: ;tag=bobtag2 292 From: ;tag=alicetag2 293 CSeq: 500 NOTIFY 294 Contact: 296 F3 297 SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0 298 Event: presence 299 Expires: 0 300 Call-ID: alicecallid1@alice.example.com 301 To: ;tag=bobtag2 302 From: ;tag=alicetag2 303 CSeq: 501 SUBSCRIBE 304 Contact: 306 F4 307 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 308 Event: presence 309 Subscription-State: terminated;reason=deactivated 310 Call-ID: alicecallid1@alice.example.com 311 To: ;tag=bobtag2 312 From: ;tag=alicetag2 313 CSeq: 502 NOTIFY 314 Contact: 316 Figure 2 318 3. Usage Creation and Destruction 320 Dialogs come into existance along with their first usage. Dialogs 321 terminate when their last usage is destroyed. The messages that 322 create and destroy usages vary per usage. This section provides a 323 high-level categorization of those messages. The section does not 324 attempt to explore the REGISTER pseudo-dialog. 326 3.1. Invite usages 327 Created by: non-100 provisional responses to INVITE; 200 response to 328 INVITE 329 Destroyed by: 200 responses to BYE; certain failure responses to 330 INVITE, UPDATE, PRACK, or INFO; anything that destroys a dialog 331 and all its usages 333 3.2. Subscribe usages 334 Created by: 200 class responses to SUBSCRIBE; 200 class responses to 335 REFER; NOTIFY requests 336 Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or 337 refresh-SUBSCRIBE request timeout; certain failure responses to 338 NOTIFY or SUBSCRIBE; anything that destroys a dialog and all its 339 usages 341 4. Proper Handling of Multiple Usages 343 The examples in Section 2 show straightforward cases where it is 344 fairly obvious when the dialog begins and ends. Unfortunately, there 345 are many scenarios where such clarity is not present. For instance, 346 in Figure 1, what would it mean if the response to the NOTIFY (F2) 347 were a 481? Does that simply terminate the refer subscription, or 348 does it destroy the entire dialog? This section explores the problem 349 spots with multiple usages that have been identified to date. 351 4.1. A survey of the effect of failure responses on usages and dialogs 353 For this survey, consider a subscribe usage inside a dialog 354 established with an invite usage. Unless stated otherwise, we'll 355 discuss the effect on each usage and the dialog when a client issuing 356 a NOTIFY inside the subscribe usage receives a failure response (such 357 as a transferee issuing a NOTIFY to event refer). Further, unless 358 otherwise stated, the conclusions apply to arbitrary multiple-usages. 360 This survey is written from the perspective of a client receiving the 361 error response. The effect on dialogs and usages at the server 362 issuing the response is the same. 364 3xx responses: Redirection mid-dialog is not well understood in SIP, 365 but whatever effect it has impacts the entire dialog and all of 366 its usages equally. In our example scenario, both the 367 subscription and the invite usage would be redirected by this 368 single response. 370 400 and unrecognized 4xx responses: These responses affect only the 371 NOTIFY transaction, not the subscription, the dialog it resides in 372 (beyond affecting the local CSeq), or any other usage of that 373 dialog. In general, the response is a complaint about this 374 transaction, not the usage or dialog the transaction occurs in. 376 401 Unauthorized ,407 Proxy Authentication Required: This request, 377 not the subscription or dialog, is being challenged. The usages 378 and dialog are not terminated. 380 402 Payment Required: This is a reserved response code. If 381 encountered, it should be treated as an unrecognized 4xx. 383 403 Forbidden: This response terminates the usage, but has no effect 384 on any other usages of the dialog. In our example scenario, the 385 subscription is terminated, but the invite usage continues to 386 exist. Similarly, if the 403 came in response to a reINVITE, the 387 invite usage would be terminated, but not the subscription. 389 404 Not Found: This response destroys the dialog and all usages 390 sharing it. The Request-URI that is being 404ed is the remote 391 target set by the Contact provided by the peer. Getting this 392 response means something has gone fundamentally wrong with the 393 dialog state. 395 405 Method Not Allowed: In our example scenario, this response 396 destroys the subscription, but not the invite usage or the dialog. 397 It's an aberrant case for NOTIFYs to receive a 405 since they only 398 come as a result to something that creates subscription. In 399 general, a 405 within a given usage affects only that usage, but 400 does not affect other usages of the dialog. 402 406 Not Acceptable: These responses concern details of the message in 403 the transaction. Subsequent requests in this same usage may 404 succeed. Neither the usage nor dialog is terminated, other usages 405 sharing this dialog are unaffected. 407 408 Request Timeout: Receiving a 408 will have the same effect on 408 usages and dialogs as a real transaction timeout as described in 409 Section 4.2. 411 410 Gone: This response destroys the dialog and all usages sharing 412 it. The Request-URI that is being rejected is the remote target 413 set by the Contact provided by the peer. Similar to 404, getting 414 this response means something has gone fundamentally wrong with 415 the dialog state, its slightly less aberrant in that the other 416 endpoint recognizes that this was once a valid URI that it isn't 417 willing to respond to anymore. 419 412 Conditional Request Failed: 420 413 Request Entity Too Large: 421 414 Request-URI Too Long: 422 415 Unsupported Media Type: These responses concern details of the 423 message in the transaction. Subsequent requests in this same 424 usage may succeed. Neither the usage nor dialog is terminated, 425 other usages sharing this dialog are unaffected. 427 416 Unsupported URI Scheme: Similar to 404 and 410, this response 428 came to a request whose Request-URI was provided by the peer in a 429 Contact header field. Something has gone fundamentally wrong, and 430 the dialog and all of its usages are destroyed. 432 417 Uknown Resource-Priority: The effect of this response on usages 433 and dialogs is analgous to that for 420 and 488. The usage is not 434 affected. The dialog is only affected by a change in its local 435 CSeq. No other usages of the dialog are affected. 437 420 Bad Extension, 421 Extension Required: These responses are 438 objecting to the request, not the usage. The usage is not 439 affected. The dialog is only affected by a change in its local 440 CSeq. No other usages of the dialog are affected. 442 422 Session Interval Too Small: This repsonse will not be returned to 443 a NOTIFY in our example scenario. This response is non-sensical 444 for any mid-usage request. If it is received, an element in the 445 path of the request is violating protocol, and the recipient 446 should treat this as it would an unknown 4xx response. If the 447 response came to a request that was attempting to establish a new 448 usage in an existing dialog, no new usage is created and existing 449 usages are unaffected. 451 423 Interval Too Brief: This response won't happen in our example 452 scenario, but if it came in response to a reSUBSCRIBE, the 453 subscribe usage is not destroyed (or otherwise affected). No 454 other usages of the dialog are affected. 456 428 Use Identity Header: This response objects to the request, not 457 the usage. The usage is not affected. The dialog is only 458 affected by a change in its local CSeq. No other usages of the 459 dialog are affected. 461 429 Provide Referrer Identity: This response won't be returned to a 462 NOTIFY as in our example scenario, but when it is returned to a 463 REFER, it is objecting to the REFER request itself, not any usage 464 the REFER occurs within. The usage is unaffected. Any other 465 usages sharing this dialog are unaffected. The dialog is only 466 affected by a change in its local CSeq. 468 436 Bad Identity-Info, 437 Unsupported Certificate, 438 Invalid 469 Identity Header These responses object to the request, not the usage. 470 The usage is not affected. The dialog is only affected by a 471 change in its local CSeq. No other usages of the dialog are 472 affected. 474 480 Temporarily Unavailable: RFC 3261 is unclear on what this 475 response means for mid-usage requests. Clarifications will be 476 made to show that this response affects only the usage in which 477 the request occurs. No other usages are affected. If the 478 response included a Retry-After header field, further requests in 479 that usage should not be sent until the indicated time has past. 480 Requests in other usages may still be sent at any time. 482 481 Call/Transaction Does Not Exist: This response indicates that the 483 peer has lost its copy of the dialog usage state. The dialog 484 itself should not be destroyed unless this was the last usage. 485 The effects of a 481 on a dialog and its usages are the most 486 ambiguous of any final response. There are implementations that 487 have chosen the meaning recommended here, and others that destroy 488 the entire dialog without regard to the number of outstanding 489 usages. Going forward with this clarification will allow those 490 deployed implementations that assumed only the usage was destroyed 491 to work with a wider number of implementations. Those that made 492 the other choice will continue to function as they do now, 493 suffering at most the same extra messages needed for a peer to 494 discover that that other usages have gone away that they currently 495 do. However, the necessary clarification to RFC 3261 needs to 496 make it very clear that the ability to terminate usages 497 independently from the overall dialog using a 481 is not 498 justification for designing new applications that count on 499 multiple usages in a dialog. 501 482 Loop Detected: This response is aberrant mid-dialog. It will 502 only occur if the Record-Route header field was improperly 503 constructed by the proxies involved in setting up the dialog's 504 initial usage, or if a mid-dialog request forks and merges (which 505 should never happen). Future requests using this dialog state 506 will also fail. The dialog and any usages sharing it are 507 destroyed. 509 483 Too Many Hops: Similar to 482, receiving this mid-dialog is 510 aberrant. Unlike 482, recovery may be possible by increasing Max- 511 Forwards (assuming that the requester did something strange like 512 using a smaller value for Max-Forwards in mid-dialog requests than 513 it used for an initial request). If the request isn't tried with 514 an increased Max-Forwards, then the agent should attempt to 515 gracefully terminate this usage and all other usages that share 516 its dialog. 518 484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these 519 responses came to a request whose Request-URI was provided by the 520 peer in a Contact header field. Something has gone fundamentally 521 wrong, and the dialog and all of its usages are destroyed. 523 486 Busy Here: This response is non-sensical in our example scenario, 524 or in any scenario where this response comes inside an established 525 usage. If it occurs in that context, it should be treated as an 526 unknown 4xx response. The usage, and any other usages sharing its 527 dialog are unaffected. The dialog is only affected by the change 528 in its local CSeq. If this response is to a request that is 529 attempting to establish a new usage within an existing dialog 530 (such as an INVITE sent within a dialog established by a 531 subscription), the request fails, no new usage is created, and no 532 other usages are affected. 534 487 Request Terminated: This response speaks to the disposition of a 535 particular request (transaction). The usage in which that request 536 occurs is not affected by this response (it may be affected by 537 another associated request within that usage). No other usages 538 sharing this dialog are affected. 540 488 Not Acceptable Here: This response is objecting to the request, 541 not the usage. The usage is not affected. The dialog is only 542 affected by a change in its local CSeq. No other usages of the 543 dialog are affected. 545 489 Bad Event: In our example scenario, [3] declares that the 546 subscription usage in which the NOTIFY is sent is terminated. The 547 invite usage is unaffected and the dialog continues to exist. 548 This response is only valid in the context of SUBSCRIBE and 549 NOTIFY. UAC behavior for receiving this response to other methods 550 is not specified, but treating it as an unknown 4xx is a 551 reasonable practice. 553 491 Request Pending: This response addresses in-dialog request glare. 554 Its affect is scoped to the request. The usage in which the 555 request occurs is not affected. The dialog is only affected by 556 the change in its local CSeq. No other usages sharing this dialog 557 are affected. 559 493 Undecipherable: This response objects to the request, not the 560 usage. The usage is not affected. The dialog is only affected by 561 a change in its local CSeq. No other usages of the dialog are 562 affected. 564 494 Security Agreement Required: This response is objecting to the 565 request, not the usage. The usage is not affected. The dialog is 566 only affected by a change in its local CSeq. No other usages of 567 the dialog are affected. 569 500 and 5xx unrecognized responses: These responses are complaints 570 against the request (transaction), not the usage. If the response 571 contains a Retry-After header field value, the server thinks the 572 condition is temporary and the request can be retried after the 573 indicated interval. This usage, and any other usages sharing the 574 dialog are unaffected. If the response does not contain a Retry- 575 After header field value, the UA may decide to retry after an 576 interval of its choosing or attempt to gracefully terminate the 577 usage. Whether or not to terminate other usages depends on the 578 application. If the UA receives a 500 (or unrecognized 5xx) in 579 response to an attempt to gracefully terminate this usage, it can 580 treat this usage as terminated. If this is the last usage sharing 581 the dialog, the dialog is also terminated. 583 501 Not Implemented: This would be a degenerate response in our 584 example scenario since the NOTIFY is being sent as part of an 585 established subscribe usage. In this case, the UA knows the 586 condition is unrecoverable and should stop attempting to send 587 NOTIFYs on this usage. (It may or may not destroy the usage. If 588 it remembers the bad behavior, it can reject any refresh 589 subscription). In general, this response may or may not affect 590 the usage (a 501 to an unknown method or an INFO will not end an 591 invite usage). It will never affect other usages sharing this 592 usage's dialog. 594 502 Bad Gateway: This response is aberrant mid-dialog. It will only 595 occur if the Record-Route header field was improperly constructed 596 by the proxies involved in setting up the dialog's initial usage. 597 Future requests using this dialog state will also fail. The 598 dialog and any usages sharing it are destroyed. 600 503 Service Unavailable: As per [2], the logic handling locating SIP 601 servers for transactions may handle 503 requests (effectively 602 sequentially forking at the endpoint based on DNS results). If 603 this process does not yield a better response, a 503 may be 604 returned to the transaction user. Like a 500 response, the error 605 is a complaint about this transaction, not the usage. Because 606 this response occurred in the context of an established usage 607 (hence an existing dialog), the route-set has already been formed 608 and any opportunity to try alternate servers (as recommended in 609 [1] has been exhausted by the RFC3263 logic. The response should 610 be handled as described for 500 earlier in this memo. 612 504 Server Time-out: It is not obvious under what circumstances this 613 response would be returned to a request in an existing dialog. If 614 it occurs it should have the same affect on the dialog and its 615 usages as described for unknown 5xx responses. 617 505 Version Not Supported, 513 Message Too Large: These responses are 618 objecting to the request, not the usage. The usage is not 619 affected. The dialog is only affected by a change in its local 620 CSeq. No other usages of the dialog are affected. 622 580 Precondition Failure: This response is objecting to the request, 623 not the usage. The usage is not affected. The dialog is only 624 affected by a change in its local CSeq. No other usages of the 625 dialog are affected. 627 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 628 response code says something about the recipient user, not the 629 request that was made. This end user is stating an unwillingness 630 to communicate. If the response contains a Retry-After header 631 field value, the user is indicating willingness to communicate 632 later and the request can be retried after the indicated interval. 633 This usage, and any other usages sharing the dialog are 634 unaffected. If the response does not contain a Retry-After header 635 field value, the UA may decide to retry after an interval of its 636 choosing or attempt to gracefully terminate the usage. Whether or 637 not to terminate other usages depends on the application. If the 638 UA receives a 600 (or unrecognized 6xx) in response to an attempt 639 to gracefully terminate this usage, it can treat this usage as 640 terminated. If this is the last usage sharing the dialog, the 641 dialog is also terminated. 643 603 Decline: This response declines the action indicated by the 644 associated request. It can be used, for example, to decline a 645 hold or transfer attempt. Receiving this response does NOT 646 terminate the usage it occurs in. Other usages sharing the dialog 647 are unaffected. 649 604 Does Not Exist Anywhere: Like 404, this response destroys the 650 dialog and all usages sharing it. The Request-URI that is being 651 604ed is the remote target set by the Contact provided by the 652 peer. Getting this response means something has gone 653 fundamentally wrong with the dialog state. 655 606 Not Acceptable: This response is objecting to aspects of the 656 associated request, not the usage the request appears in. The 657 usage is unaffected. Any other usages sharing the dialog are 658 unaffected. The only affect on the dialog is the change in the 659 local CSeq. 661 4.2. Transaction timeouts 663 [1] states that a UAC should terminate a dialog (by sending a BYE) if 664 no response is received for a request sent within a dialog. This 665 recommendation should have been limited to the invite usage instead 666 of the whole dialog. [3] states that a timeout for a NOTIFY removes a 667 subscription, but a SUBSCRIBE that fails with anything other than a 668 481 does not. Given these statements, it is unclear whether a 669 refresh SUBSCRIBE issued in a dialog shared with an invite usage 670 destroys either usage or the dialog if it times out. 672 Generally, a transaction timeout should affect only the usage in 673 which the transaction occurred. Other uses sharing the dialog should 674 not be affected. In the worst case of timeout due to total transport 675 failure, it may require multiple failed messages to remove all usages 676 from a dialog (at least one per usage). 678 There are some mid-dialog messages that never belong to any usage. 679 If they timeout, they will have no effect on the dialog or its 680 usages. 682 4.3. Matching requests to usages 684 For many mid-dialog requests, identifying the usage they belong to is 685 obvious. A dialog can have at most one invite usage, so any INVITE, 686 UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The 687 usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER 688 requests belong to can be determined from the Event header field of 689 the request. REGISTER requests within a (pseudo)-dialog belong to 690 the registration usage. (As mentioned before, implementations aren't 691 mixing registration usages with other usages, so this document isn't 692 exploring the consequences of that bad behavior). 694 According to [1], "an OPTIONS request received within a dialog 695 generates a 200 OK response that is identical to one constructed 696 outside a dialog and does not have any impact on that dialog". Thus 697 OPTIONS does not belong to any usage. Only those failures discussed 698 in Section 4.1 and Section 4.2 that destroy entire dialogs will have 699 any effect on the usages sharing the dialog with a failed OPTIONS 700 request. 702 MESSAGE requests are not currently allowed inside a dialog (though 703 some implementations use it that way, against the standard 704 recommendation). As it is not meant to be part of any given dialog, 705 it cannot be part of any given usage. A failed MESSAGE request 706 should have similar effects on a dialog and its usages as a failed 707 OPTIONS request. 709 Mid-dialog requests with unknown methods cannot be matched with a 710 usage. Servers will return a failure response (likely a 501). The 711 effect on the dialog and its usages at either the client or the 712 server should be similar to that of a failed OPTIONS request. 714 These guidelines for matching messages to usages (or determining 715 there is no usage) apply equally when acting as a UAS, a UAC, or any 716 third party tracking usage and dialog state by inspecting all 717 messages between two endpoints. 719 4.4. Target refresh requests 721 Target refresh requests update the remote target of a dialog when 722 they are successfully processed. The currently defined target 723 refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified 724 in a bug against RFC3565) and REFER (clarified in a bug against 725 RFC3515 [4]). 727 The remote target is part of the dialog state. When a target refresh 728 request affects it, it affects it for ALL usages sharing that dialog. 729 If a subscription and invite usage are sharing a dialog, sending a 730 refresh SUBSCRIBE with a different contact will cause reINVITEs from 731 the peer to go to that different contact. 733 A UAS will only update the remote target if it sends a 200 class 734 response to a target refresh request. A UAC will only update the 735 remote target if it receives a 200 class response to a target refresh 736 request. Again, any update to a dialog's remote target affects all 737 usages of that dialog. 739 4.5. Refreshing and Terminating Usages 741 Subscription and registration usages expire over time and must be 742 refreshed (with a refresh SUBSCRIBE for example). This expiration is 743 usage state, not dialog state. If several subscriptions share a 744 dialog, refreshing one of them has no effect on the expiration of the 745 others. 747 Normal termination of a usage has no effect on other usages sharing 748 the same dialog. For instance terminating a subscription with a 749 NOTIFY/Subscription-State: terminated will not terminate an invite 750 usage sharing its dialog. Likewise, ending an invite usage with a 751 BYE does not terminate any active Event: refer subscriptions 752 established on that dialog. 754 Abnormal termination can effect all usages on a dialog. Rejecting a 755 NOTIFY with a 481 (incorrectly recommended in the past as an 756 inexpensive way to terminate a REFER subscription) destroys the 757 dialog and all of its usages. 759 4.6. Refusing new usages 761 As the survey of the effect of failure responses shows, care must be 762 taken when refusing a new usage inside an existing dialog. Choosing 763 the wrong response code will terminate the dialog and all of its 764 usages. Generally, returning a 603 Decline is the safest way to 765 refuse a new usage. 767 4.7. Replacing usages 769 [6] defines a mechanism through which one usage can replace another. 770 It can be used, for example, to associate the two dialogs a transfer 771 target is involved in during an attended transfer. It is written 772 using the term "dialog", but its intent was to only affect the invite 773 usage of the dialog it targets. Any other usages inside that dialog 774 are unaffected. For some applications, the other usages may no 775 longer make sense, and the application may terminate them as well. 777 However, the interactions between Replaces and multiple dialog usages 778 have not been well explored. More discussion of this topic is 779 needed. Implementers should avoid this scenario completely. 781 5. Avoiding Multiple Usages 782 Processing multiple usages correctly is not completely understood. 783 What is understood is difficult to implement and is very likely to 784 lead to interoperability problems. The best way to avoid the trouble 785 that comes with such complexity is to avoid it altogether. 787 When designing new applications that use SIP dialogs, do not 788 construct multiple usages. If a peer attempts to create a second 789 usage inside a dialog, refuse it. 791 Unfortunately, there are existing applications, like transfer, that 792 currently entail multiple usages, so the simple solution of "don't do 793 it" will require some transitional work. This section looks at the 794 pressures that led to these existing multiple usages and suggests 795 alternatives. 797 When executing a transfer, the transferor and transferee currently 798 share an invite usage and a subscription usage within the dialog 799 between them. This is a result of sending the REFER request within 800 the dialog established by the invite usage. Implementations were led 801 to this behavior by two primary pressures: 802 1. There was no way to ensure that a REFER on a new dialog would 803 reach the particular endpoint involved in a transfer. Many 804 factors, including details of implementations and changes in 805 proxy routing between an INVITE and a REFER could cause the REFER 806 to be sent to the wrong place. Sending the REFER down the 807 existing dialog ensured it got to the endpoint we were already 808 talking to. 809 2. It was unclear how to associate an existing invite usage with a 810 REFER arriving on a new dialog, where it was completely obvious 811 what the association was when the REFER came on the invite 812 usage's dialog. 813 3. There were concerns with authorizing out-of-dialog REFERs. The 814 authorization policy for REFER in most implementations piggybacks 815 on the authorization policy for INVITE (which is, in most cases, 816 based simply on "I placed or answered this call"). 818 GRUUs [7] have been defined specifically to address problem 1. 819 Problem 2 can be addressed using a GRUU's grid parameter. However, 820 this approach requires endpoints to create and maintain a GRUU per 821 dialog, something the working group is not comfortable recommending. 823 The Join [5] and Replaces [6] mechanisms address problem 1 824 differently. Here, a new request is sent outside any dialog with the 825 expectation that it will fork to possibly many endpoints, including 826 the one we're interested in. This request contains a header field 827 listing the dialog identifiers of a dialog in progress. Only the 828 endpoint holding a dialog matching those identifiers will accept the 829 request. The other endpoints the request may have forked to will 830 respond with an error. This mechanism is reasonably robust, failing 831 only when the routing logic for out-of-dialog requests changes such 832 that the new request does not arrive at the endpoint holding the 833 dialog of interest. 835 The reachability aspects of using a GRUU to address problem 1 can be 836 combined with the association-with-other-dialogs aspects of the Join/ 837 Replaces solution. A REFER request sent out-of-dialog can be sent 838 towards a GRUU, and identify an existing dialog as part of the 839 context the receiver should use. A new header, Target-Dialog: 840 perhaps, would be included in the REFER listing the dialog this REFER 841 is associated with. Figure 3 sketches how this could be used to 842 acheive transfer without reusing a dialog. 844 Alice Bob Carol 845 | | | 846 | F1 INVITE (Bob's AOR) | | 847 | Call-ID: (call-id-one) | | 848 | Contact: (Alice's-GRUU) | | 849 |------------------------------->| | 850 | F2 200 OK | | 851 | To: <>;tag=totag1 | | 852 | From: <>;tag=fromtag1 | | 853 | Call-ID: (call-id one) | | 854 | Contact: (Bob's-GRUU) | | 855 |<-------------------------------| | 856 | ACK | | 857 |------------------------------->| | 858 | : | | 859 | (Bob places Alice on hold) | | 860 | : | F3 INVITE (Carol's AOR) | 861 | | Call-ID: (call-id two) | 862 | | Contact: (Bob's-GRUU) | 863 | |----------------------------->| 864 | | F4 200 OK | 865 | | To: <>;tag=totag2 | 866 | | From: <>;tag=fromtag2 | 867 | | Call-ID: (call-id two) | 868 | | Contact: (Carol's-GRUU) | 869 | |<-----------------------------| 870 | | ACK | 871 | |----------------------------->| 872 | | : | 873 | | (Bob places Carol on hold) | 874 | F5 REFER (Alice's-GRUU) | : | 875 | Call-ID: (call-id three) | | 876 | Refer-To: (Carol's-GRUU) | | 877 | Target-Dialog: (call-id one,totag1,fromtag1) | 878 | Contact: (Bob's-GRUU) | | 879 |<-------------------------------| | 880 | 202 Accepted | | 881 |------------------------------->| | 882 | NOTIFY (Bob's-GRUU) | | 883 | Call-ID: (call-id three) | | 884 |------------------------------->| | 885 | 200 OK | | 886 |<-------------------------------| | 887 | | | 888 | F6 INVITE (Carol's-GRUU) | 889 | Call-ID: (call-id-four) | 890 | Contact: (Alice's-GRUU) | 891 |-------------------------------------------------------------->| 892 | 200 OK | 893 | Contact: (Carol's-GRUU) | 894 |<--------------------------------------------------------------| 895 | ACK | 896 |-------------------------------------------------------------->| 897 | | | 898 | F7 NOTIFY (Bob's-GRUU) | | 899 | Call-ID: (call-id three) | | 900 |------------------------------->| | 901 | 200 OK | | 902 |<-------------------------------| | 903 | BYE (Alice's-GRUU) | | 904 | Call-ID: (call-id one) | | 905 |<-------------------------------| BYE (Carol's-GRUU) | 906 | | Call-ID: (call-id two) | 907 | 200 OK |----------------------------->| 908 |------------------------------->| 200 OK | 909 | |<-----------------------------| 910 | | | 912 Figure 3: Transfer without dialog reuse 914 In message F1, Alice invites Bob indicating support for GRUUs (and 915 offering a GRUU for herself): 917 Message F1 (abridged, detailing pertinent fields) 919 INVITE sip:bob@example.com SIP/2.0 920 Call-ID: 13jfdwer230jsdw@alice.example.com 921 Supported: gruu 922 Contact: 924 Message F2 lets Alice know that Bob understands GRUUs. If Bob did 925 not indicate this support, the original multi-usage approach to 926 transfer would have to be used. 928 Message F2 (abridged, detailing pertinent fields) 930 SIP/2.0 200 OK 931 Supported: gruu 932 To: ;tag=totag1 933 From: ;tag=fromtag1 934 Contact: 936 Bob decides to try to transfer Alice to Carol, so he puts Alice on 937 hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU 938 support similar to what happened in F1 and F2. 940 Message F3 (abridged, detailing pertinent fields) 942 INVITE sip:carol@example.com SIP/2.0 943 Supported: gruu 944 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 945 Contact: 947 Message F4 (abridged, detailing pertinent fields) 949 SIP/2.0 200 OK 950 Supported: gruu 951 To: ;tag=totag2 952 From: ;tag=fromtag2 953 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 954 Contact: 956 After consulting Carol, Bob places her on hold and refers Alice to 957 her using message F5. Notice that the Refer-To URI is Carol's GRUU, 958 and that this is on a different Call-ID than message F1. (The URI in 959 the Refer-To header is line-broken for readability in this draft, it 960 would not be valid to break the URI this way in a real message) 961 Message F5 (abridged, detailing pertinent fields) 963 REFER sip:aanewmr203raswdf@example.com SIP/2.0 964 Call-ID: 39fa99r0329493asdsf3n@bob.example.com 965 Refer-To: 968 Target-Dialog: 13jfdwer230jsdw@alice.example.com; 969 local-tag=fromtag1;remote-tag=totag1 970 Supported: gruu 971 Contact: 973 Alice uses the information in the Target-Dialog header field to 974 determine that this REFER is associated with the dialog she already 975 has in place with Bob. Alice is now in a position to use the same 976 admission policy she used for in-dialog REFERs: "Do I have a call 977 with this person?". She accepts the REFER. sends Bob the obligatory 978 immediate NOTIFY, and proceeds to INVITE Carol with message F6. 980 Message F6 (abridged, detailing pertinent fields) 982 INVITE sip:c239fniuweorw9sdfn@example.com SIP/2.0 983 Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com 984 Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; 985 to-tag=totag2;from-tag=fromtag2 986 Supported: gruu 987 Contact: 989 Carol accepts Alice's invitation to replace her dialog (invite usage) 990 with Bob and notifies him that the REFERenced INVITE succeeded with 991 F7: 993 Message F7 (abridged, detailing pertinent fields) 995 NOTIFY sip:boaiidfjjereis@example.com SIP/2.0 996 Subscription-State: terminated;reason=noresource 997 Call-ID: 39fa99r0329493asdsf3n@bob.example.com 998 Contact: 999 Content-Type: message/sipfrag 1001 SIP/2.0 200 OK 1003 Bob then ends his invite usages with both Alice and Carol using BYEs. 1005 6. Conclusion 1007 Handling multiple usages within a single dialog is complex and 1008 introduces scenarios where the right thing to do is not clear. 1009 Implementations should avoid entering into multiple usages whenever 1010 possible. New applications should be designed to never introduce 1011 multiple usages. 1013 There are some accepted SIP practices, including transfer, that 1014 currently require multiple usages. Recent work, most notably GRUU, 1015 makes those practices unnecessary. The standardization of those 1016 practices and the implementations should be revised as soon as 1017 possible to use only single-usage dialogs. 1019 7. Acknowledgments 1021 The ideas in this draft have been refined over several IETF meetings 1022 with many participants. Significant contribution was provided by 1023 Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan 1024 Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate 1025 project also shared their difficulties and discoveries while 1026 implementing multiple-usage dialog handlers. 1028 8. Informative References 1030 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1031 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1032 Session Initiation Protocol", RFC 3261, June 2002. 1034 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1035 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1037 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1038 Notification", RFC 3265, June 2002. 1040 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1041 Method", RFC 3515, April 2003. 1043 [5] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1044 "Join" Header", RFC 3911, October 2004. 1046 [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1047 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1049 [7] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 1050 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 1051 draft-ietf-sip-gruu-06 (work in progress), October 2005. 1053 Appendix A. Change Log 1055 RFC-EDITOR: Please remove this entire Change Log section while 1056 formatting this document for publication. 1058 A.1. draft-ietf-00->draft-ietf-01 1060 o Changed 481 to only affect the usage the response occured in, 1061 closing the last open issue. Added some text justifying this 1062 recommendation. 1063 o Added 422 Session Interval Too Small 1064 o Added 417 Uknown Resource-Priority 1065 o Added 428 Use Identity Header 1066 o Added 436 Bad Identity-Info 1067 o Added 437 Unsupported Certificate 1068 o Added 438 Invalid Identity header 1069 o Added a section categorizing messages that create and destroy 1070 usages 1071 o Made sure all descriptions in Section 4 addressed the generic 1072 multi-usage case. 1073 o Clarified that the mechanics described in matching messages to 1074 usages applied equally to UACs and UASs. 1075 o More explicitly noted that REFER creates a subscribe-usage 1077 A.2. draft-sparks-01->draft-ietf-00 1078 o Draft rename 1080 A.3. draft-sparks-00->01 1081 o Changed 480 to affect only the usage the response occured in. 1082 o Closed the open issue on 482. Usages and dialogs are destroyed 1083 even though there is an edge condition in which the response is 1084 only stimuted by certain methods (due to method specific routing 1085 rules). 1086 o Closed the open issue on 483. Usages are not terminated since the 1087 request might succeed if retried with a greater initial Max- 1088 Forwards 1089 o Closed the open issue on 502, accepting -00s suggestion that the 1090 same reasoning used for 482 applies. 1091 o Redid the transfer example to not require a GRUU per usage, but 1092 instead leverage the target-dialog concepts common to Join and 1093 Replaces. 1095 Author's Address 1097 Robert J. Sparks 1098 Estacado Systems 1100 Email: RjS@estacado.net 1102 Intellectual Property Statement 1104 The IETF takes no position regarding the validity or scope of any 1105 Intellectual Property Rights or other rights that might be claimed to 1106 pertain to the implementation or use of the technology described in 1107 this document or the extent to which any license under such rights 1108 might or might not be available; nor does it represent that it has 1109 made any independent effort to identify any such rights. Information 1110 on the procedures with respect to rights in RFC documents can be 1111 found in BCP 78 and BCP 79. 1113 Copies of IPR disclosures made to the IETF Secretariat and any 1114 assurances of licenses to be made available, or the result of an 1115 attempt made to obtain a general license or permission for the use of 1116 such proprietary rights by implementers or users of this 1117 specification can be obtained from the IETF on-line IPR repository at 1118 http://www.ietf.org/ipr. 1120 The IETF invites any interested party to bring to its attention any 1121 copyrights, patents or patent applications, or other proprietary 1122 rights that may cover technology that may be required to implement 1123 this standard. Please address the information to the IETF at 1124 ietf-ipr@ietf.org. 1126 Disclaimer of Validity 1128 This document and the information contained herein are provided on an 1129 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1130 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1131 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1132 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1133 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1134 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1136 Copyright Statement 1138 Copyright (C) The Internet Society (2006). This document is subject 1139 to the rights, licenses and restrictions contained in BCP 78, and 1140 except as set forth therein, the authors retain all their rights. 1142 Acknowledgment 1144 Funding for the RFC Editor function is currently provided by the 1145 Internet Society.