idnits 2.17.1 draft-procter-bliss-call-park-extension-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 21, 2008) is 5665 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS M. Procter 3 Internet-Draft VoIP.co.uk 4 Intended status: Informational October 21, 2008 5 Expires: April 24, 2009 7 Implementing Call Park and Retrieve using the Session Initiation 8 Protocol (SIP) 9 draft-procter-bliss-call-park-extension-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 24, 2009. 36 Abstract 38 Call Park and Call Retrieve are useful telephony services that are 39 familiar to many users. Existing implementations using the Session 40 Initiation Protocol (SIP) show that a variety of approaches can be 41 taken, with varying degrees of interoperability. This draft 42 discusses a number of feature variations, and how they may be 43 implemented using existing techniques. An additional URI parameter 44 is also described, which enables further common use-cases to be 45 implemented. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Parking a call . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Parking a call without an orbit . . . . . . . . . . . . . 5 52 2.2. Parking a call with an orbit specified by the UA . . . . . 5 53 2.3. Parking a call with an orbit specified by the Park 54 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.4. A failed attempt to park a call . . . . . . . . . . . . . 9 56 3. Retrieving a Parked Call . . . . . . . . . . . . . . . . . . . 9 57 4. User Agent Considerations . . . . . . . . . . . . . . . . . . 12 58 5. Park Server Considerations . . . . . . . . . . . . . . . . . . 13 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . . . 16 68 1. Overview 70 Call Park is a feature that enables UAs to make a call inactive but 71 not terminated, in such a way as to allow the call to be resumed by 72 the UA that parked the call, or by a different UA. 74 This feature is typically used when User A wishes to transfer a call 75 in progress to User B, but doesn't necessarily know how to reach User 76 B's UA directly. In this situation, User A parks the call, and then 77 tells User B where the call is parked. User B may then retrieve the 78 call using a convenient UA. 80 Other uses include allowing multiple calls to be parked at the same 81 'location', and forming a queue. In this way, a simple 'ACD' 82 (Automatic Call Distribution) system can be implemented that permits 83 calls to be initially sorted and placed in one of a number of queues, 84 ready to be handled when an appropriate agent becomes available (and 85 retrieves the next call from the queue). 87 In all cases, the parked call is subsequently identifiable by a short 88 (typically 3 or 4 digit) label known as an 'orbit'. This orbit is 89 often allocated by the user parking the call, but some environments 90 favour allocation of the orbit by a Park Server. Both approaches are 91 described in this document. 93 Multiple Park Servers can be beneficial in some enviroments for a 94 variety of reasons including load-sharing and administrative 95 policies. This document shows how support for multiple servers can 96 easily be achieved whilst still permitting a single 'well-known' Park 97 Server URI to be advertised for configuration. 99 2. Parking a call 101 A basic call flow for Call Park is given in 102 [I-D.ietf-sipping-service-examples] (section 2.15), and this forms 103 the basis of the feature. The flow shows Alice and Bob in a call, 104 when Bob decides to park the call by sending a REFER to the Park 105 Server. 107 It is worth noting that whilst the flow is conceptually similar to an 108 Unattended Transfer [I-D.ietf-sipping-service-examples] (section 109 2.4), the REFER is sent to different endpoints in the two cases. For 110 Unattended Transfer, the Transferor sends the REFER to the 111 Transferee, instructing him to call the Transfer Target. For Call 112 Park, the Transferor (Bob) sends the REFER to the Transfer Target 113 (Park Server), instructing it to call the Transferee (Alice). 115 By following the Call Park model, we ensure that Bob has visibility 116 over the success or failure of the park attempt. We also ensure that 117 Bob does not rely on Alice to correctly pass the orbit parameter back 118 from the Park Server for the centrally-allocated orbit number 119 situation. Finally, because Bob sends the REFER to the Park Server, 120 we give the Park Server the opportunity to challenge Bob and ensure 121 that appropriate authorisation exists for the feature. 123 Alice Bob Park Server Carol 124 | | | | 125 | INVITE F1 | | | 126 |------------->| | | 127 |180 Ringing F2| | | 128 |<-------------| | | 129 | 200 OK F3 | | | 130 |<-------------| | | 131 | ACK F4 | | | 132 |------------->| | | 133 | RTP Media | | | 134 |<============>| | | 135 | Bob Parks Call | | 136 | | REFER Refer-To: A F5 | 137 | |------------->| | 138 | | 202 F6 | | 139 | |<-------------| | 140 | | NOTIFY F7 | | 141 | |<-------------| | 142 | | 200 F8 | | 143 | |------------->| | 144 | INVITE F9 Replaces: B | | 145 |<----------------------------| | 146 | 200 OK F10 | | 147 |---------------------------->| | 148 | ACK F11 | | 149 |<----------------------------| | 150 |(Music-on-Hold or other RTP?)| | 151 |<===========================>| | 152 | BYE F12 | | | 153 |------------->| NOTIFY F14 | | 154 | 200 OK F13 |<-------------| | 155 |<-------------| 200 OK F15 | | 156 | |------------->| | 158 The basic call flow described above uses the SIP dialog ID between 159 the parked endpoint and the Park Server itself as the unique parked 160 call identifier. Using the dialog ID has a number of advantages 161 since it is unique and allocated by both the parked user and the Park 162 Server. However, it is also long, which can lead to problems when 163 trying to identify parked calls by verbal or human-written 164 mechanisms. 166 Traditional PBX users have become accustomed to calls being parked 167 against a short number (typically 3 or 4 digits), and then using this 168 identifier to communicate to the retrieving party which call to 169 retrieve. This information may be passed verbally, or by means of 170 small paper notes. Whilst collisions may occur, they are generally 171 avoided satisfactorily by administrative policies. 173 This draft attempts to reconcile these two models by allowing a short 174 label to be attached to a parked call (the 'orbit'). The retrieving 175 party can then use the same label to locate the relevant dialog ID in 176 order to retrieve the parked call. Note that the orbit may be 177 allocated by the User Agent parking the call or centrally by the Park 178 Server. 180 2.1. Parking a call without an orbit 182 Certain environments do not require an 'orbit' to be used, either 183 because calls are parked in a single queue, or the dialog identifiers 184 are readily passed between concerned UAs. In this scenario, the flow 185 described in [I-D.ietf-sipping-service-examples] (section 2.15) is 186 followed without deviation. 188 2.2. Parking a call with an orbit specified by the UA 190 The message flow of parking a call in this scenario is identical to 191 that illustrated in [I-D.ietf-sipping-service-examples] (section 192 2.15). The difference that this document introduces is in the REFER 193 message to the Park Server. 195 In this scenario, it is assumed that Bob has entered a parking orbit 196 in some manner appropriate to his UA. Once this is done, the REFER 197 is sent to the URI instead 198 of simply directing the request to the URI 199 . The addition of the orbit parameter 200 to the URI effectively labels the parked call with a short memorable 201 code entered by the user. 203 F5 REFER Bob -> Park Server 205 REFER sips:park@server.example.com;orbit=1234 SIP/2.0 206 Via: SIP/2.0/TLS client.biloxi.example.com:5061 207 ;branch=z9hG4bKnashds9 208 Max-Forwards: 70 209 From: Bob ;tag=02134 210 To: Park Server 211 Call-ID: 4802029847@biloxi.example.com 212 CSeq: 1 REFER 213 214 Refer-To: 217 218 Referred-By: 219 Contact: 220 Content-Length: 0 222 2.3. Parking a call with an orbit specified by the Park Server 224 Sometimes an orbit number assignment policy needs to be implemented. 225 This may be to ensure that all orbit numbers are a particular length, 226 or have a form that means that they can be dialled directly (given 227 suitable extensions to an Application Server). It may also be 228 implemented to eliminate the problem of trying to park more than one 229 call on the same orbit. 231 To enforce a policy, we ensure that the orbit number is not allocated 232 by the UA (entered by the user, or by configuration etc.) but is 233 instead allocated by the Park Server, and relayed to the UA. The 234 approach taken here is analogous to the Conference Factory approach 235 described in [RFC4579]. Bob sends a REFER to the preconfigured Park 236 Server URI, but without any 'orbit' parameter added. The Park Server 237 then responds by redirecting Bob to the correct orbit by using a '302 238 Moved Temporarily' response. The orbit can then be found by 239 inspecting this new target. 241 Alice Bob Park Server Carol 242 | | | | 243 | Active Call | | | 244 |<============>| | | 245 | Bob Parks Call | | 246 | | REFER Refer-To: A F5 | 247 | |------------->| | 248 | |302 Orbit allocated F6 | 249 | |<-------------| | 250 | | REFER Refer-To: A F7 | 251 | |------------->| | 252 | |202 Accepted F8 | 253 | |<-------------| | 254 | | NOTIFY | | 255 | |<-------------| | 256 | | 200 OK | | 257 | |------------->| | 259 F5 REFER Bob -> Park Server 261 REFER sips:park@server.example.com SIP/2.0 262 Via: SIP/2.0/TLS client.biloxi.example.com:5061 263 ;branch=z9hG4bKnashdsB 264 Max-Forwards: 70 265 From: Bob ;tag=22134 266 To: Park Server 267 Call-ID: 4802029847@biloxi.example.com 268 CSeq: 1 REFER 269 270 Refer-To: 273 274 Referred-By: 275 Contact: 276 Content-Length: 0 277 F6 302 Orbit Allocated Park Server -> Bob 279 SIP/2.0 202 Orbit Allocated 280 Via: SIP/2.0/TLS client.biloxi.example.com:5061 281 ;branch=z9hG4bKnashdsB 282 ;received=192.0.2.105 283 From: Bob ;tag=22134 284 To: Park Server ;tag=56324 285 Call-ID: 4802029848@biloxi.example.com 286 CSeq: 1 REFER 287 Contact: 288 Content-Length: 0 290 This is also the means by which multiple Park Servers can be 291 deployed. A REFER to might result in 292 a 302 response, nominating 293 as the desired target. 295 Different network architectures may result in different behaviours as 296 seen by Bob. In particular, whether Bob sees the 302 response will 297 depend on whether or not an intermediate proxy recurses on it. 298 Therefore, Bob's UA must be prepared to extract the orbit parameter 299 from either the 302 response (if one is seen) or the Contact header 300 of the 2xx response to his REFER. 302 Since this technique may also be used to resolve the problem of 303 parking multiple calls on the same orbit, Bob's UA must be prepared 304 to extract the orbit even if it provided one in the initial request. 305 If the orbit differs to the one requested, the extracted orbit should 306 be rendered to Bob in an appropriate manner. 308 F8 202 Accepted Park Server -> Bob 310 SIP/2.0 202 Accepted 311 Via: SIP/2.0/TLS client.biloxi.example.com:5061 312 ;branch=z9hG4bKnashds9 313 ;received=192.0.2.105 314 From: Bob ;tag=02134 315 To: Park Server ;tag=56323 316 Call-ID: 4802029847@biloxi.example.com 317 Contact: 318 CSeq: 1 REFER 319 Content-Length: 0 321 This variation is only possible on Park Servers capable of generating 322 Contact URIs of the correct form, i.e. with an 'orbit' URI parameter, 323 in either a 302 response, or in a 2xx response to the REFER. Park 324 Servers unable to generate URIs of this form are therefore confined 325 to environments that don't require centrally allocated parking 326 orbits. 328 2.4. A failed attempt to park a call 330 A Park Server may choose to reject a park attempt for many reasons, 331 including prohibiting multiple calls being parked against the same 332 orbit, or prohibiting certain users from parking calls on certain 333 orbits. Whatever the reason, the response sent to Bob will enable 334 Bob to take appropriate action. The following example shows the Park 335 Server rejecting a call due to the orbit already being in use. 337 Alice Bob Park Server Carol 338 | | | | 339 | INVITE F1 | | | 340 |------------->| | | 341 |180 Ringing F2| | | 342 |<-------------| | | 343 | 200 OK F3 | | | 344 |<-------------| | | 345 | ACK F4 | | | 346 |------------->| | | 347 | RTP Media | | | 348 |<============>| | | 349 | Bob Parks Call | | 350 | | REFER Refer-To: A F5 | 351 | |------------->| | 352 | |486 Busy Here | | 353 | |<-------------| | 355 When Bob's parking attempt is rejected, Bob may choose to attempt to 356 park the call again, but using a different orbit number. The ability 357 for Bob to recover from failed parking attempts such as this without 358 dropping the call to Alice is an important consequence of Bob sending 359 the REFER to the Park Server, rather than sending the REFER to Alice 360 so that she can park herself. 362 3. Retrieving a Parked Call 364 In order to retrieve a parked call, Carol needs to obtain the dialog 365 identifiers for the dialog between Alice and wherever Alice is 366 parked. 368 The dialog identifiers can be obtained by issuing a SUBSCRIBE for the 369 dialog event package [RFC4235]. The resulting NOTIFY will contain 370 details of all pertinent calls, including the dialog identifiers. 371 Carol may (if presented with multiple dialogs) choose which call to 372 retrieve. Many implementations choose the first dialog listed, 373 although some use the element to identify which call has 374 been parked for the longest time. Obtaining the dialog information 375 in this way follows the flow described in 376 [I-D.ietf-sipping-service-examples] (section 2.15). 378 By subscribing to the dialog event package [RFC4235] at the same URI 379 used for parking the call, i.e. 380 , all the information that 381 is required for the call to be retrieved by C is delivered in the 382 corresponding NOTIFY. 384 Similarly, if the call was parked in an environment that does not 385 require 'orbit' parameters, subscribing to the URI used for parking 386 the call, i.e. , will still result in 387 the necessary information being provided for the call to be 388 retrieved. 390 Alice Bob Park Server Carol 391 | | | | 392 | | | SUBSCRIBE F1 | 393 | | |<-------------| 394 | | | 200 OK F2 | 395 | | |------------->| 396 | | | NOTIFY F3 | 397 | | |------------->| 398 | | | 200 OK F4 | 399 | | |<-------------| 400 | | | | 401 | | | | 402 | INVITE Replaces: Park Server F5 | 403 |<-------------------------------------------| 404 | | | 200 F6 | 405 |------------------------------------------->| 406 | | | ACK F7 | 407 |<-------------------------------------------| 408 | RTP Media | 409 |<==========================================>| 410 | BYE F8 | | 411 |---------------------------->| | 412 | 200 OK F9 | | 413 |<----------------------------| | 415 F1 SUBSCRIBE Carol -> Park Server 417 SUBSCRIBE sips:park@server.example.com;orbit=1234 SIP/2.0 418 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 419 Max-Forwards: 70 420 From: Carol ;tag=8672349 421 To: 422 Call-ID: xt4653gs2ham@chicago.example.com 423 CSeq: 1 SUBSCRIBE 424 Contact: 425 Event: dialog 426 Subscription-State: active;expires=0 427 Accept: application/dialog-info+xml 428 Content-Length: 0 430 F2 200 OK Park Server -> Carol 432 SIP/2.0 200 OK 433 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 434 ;received=192.0.2.114 435 Max-Forwards: 70 436 From: Carol ;tag=8672349 437 To: ;tag=1234567 438 Call-ID: xt4653gs2ham@chicago.example.com 439 CSeq: 1 SUBSCRIBE 440 Content-Length: 0 441 F3 NOTIFY Park Server -> Carol 443 NOTIFY sips:carol@client.chicago.example.com SIP/2.0 444 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 445 Max-Forwards: 70 446 To: Carol ;tag=8672349 447 From: ;tag=1234567 448 Call-ID: xt4653gs2ham@chicago.example.com 449 CSeq: 2 NOTIFY 450 Contact: 451 Event: dialog 452 Subscription-State: terminated 453 Content-Type: application/dialog-info+xml 454 Content-Length: ... 456 457 460 464 confirmed 465 466 468 F4 200 OK Carol -> Park Server 470 SIP/2.0 200 OK 471 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 472 To: Carol ;tag=8672349 473 From: ;tag=1234567 474 Call-ID: xt4653gs2ham@chicago.example.com 475 CSeq: 2 NOTIFY 476 Contact: 477 Content-Length: 0 479 The remainder of the frames are the same as the corresponding frames 480 from [I-D.ietf-sipping-service-examples], since the required dialog 481 ID has been obtained through the SUBSCRIBE / NOTIFY cycle from the 482 Park Server. 484 4. User Agent Considerations 486 For Bob and Carol to be able to park and retrieve calls using a Park 487 Server, both need to be configured with the URI of the Park Server. 488 In addition, Bob and Carol should be configured to understand whether 489 or not an orbit will be required for park and retrieve. Finally, Bob 490 also needs to be configured to determine whether Bob should provide 491 the orbit or whether the orbit will be allocated by the Park Server. 493 Any orbit received from the Park Server, either in the Contact URI of 494 a 302 or 2xx response to REFER, should be rendered to the user in an 495 appropriate manner, even if an orbit was provided in the initial 496 REFER. *** UNLESS it is the same as requested? This is to allow Park 497 Servers to implement various policy decisions and allocate orbits as 498 required. Failure to do this may lead to a call being parked on a 499 different orbit to the expected one, and hence being effectively 500 lost. 502 If the UA provided an orbit in the REFER request, and no orbit is 503 received from the Park Server, then the UA may assume that the call 504 has been parked against the requested orbit correctly. 506 5. Park Server Considerations 508 It is expected that Park Servers will not necessarily support all the 509 feature variations described in this document, at least not 510 simultaneously. Therefore Park Servers should offer the set that is 511 most appropriate for the target environment. For example, some Park 512 Servers may offer centrally allocated orbits, some may not, and some 513 may be configurable. Other policy-related decisions include how to 514 handle more than one call being parked on a particular orbit. *** 515 FIXME more! 517 6. Acknowledgements 519 The following individuals were part of the Call Park Design Team, and 520 have helped to shape this document: 522 Francois Audet, Jason Fischl, Derek Macdonald, Shida Schubert, Sanjay 523 Sinha, Dale Worley and Theo Zourzouvillys. 525 7. Security Considerations 527 None. 529 8. IANA Considerations 531 Open issue: presumably need to define the new uri-parameter 'orbit'. 533 According to [RFC3969], defining a URI parameter can only be done in 534 a standards-track RFC. That doesn't sound like the sort of thing 535 this document will do, nor the sort of thing BLISS will do either. 536 However, [RFC4240] ('netann') defines values that are included in the 537 current registry, and it is most definately 'Informational'. 539 9. References 541 9.1. Normative References 543 [I-D.ietf-sipping-service-examples] 544 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 545 K. Summers, "Session Initiation Protocol Service 546 Examples", draft-ietf-sipping-service-examples-15 (work in 547 progress), July 2008. 549 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 550 Initiated Dialog Event Package for the Session Initiation 551 Protocol (SIP)", RFC 4235, November 2005. 553 9.2. Informative References 555 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 556 (SIP) Call Control - Conferencing for User Agents", 557 BCP 119, RFC 4579, August 2006. 559 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 560 (IANA) Uniform Resource Identifier (URI) Parameter 561 Registry for the Session Initiation Protocol (SIP)", 562 BCP 99, RFC 3969, December 2004. 564 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 565 Media Services with SIP", RFC 4240, December 2005. 567 Author's Address 569 Michael Procter 570 VoIP.co.uk 571 Commerce House 572 Telford Road 573 Bicester, Oxfordshire OX26 4LD 574 UK 576 Email: michael@voip.co.uk 577 URI: http://voip.co.uk 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2008). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org.