idnits 2.17.1 draft-jesske-sipping-tispan-requirements-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 561. ** 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-jesske-sipping-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-jesske-sipping-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-jesske-sipping-', but the file name used is 'draft-jesske-sipping-tispan-requirements-00' == There is 1 instance of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([32]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 2005) is 6921 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'REQ-1' on line 238 -- Looks like a reference, but probably isn't: 'REQ-2' on line 238 -- Looks like a reference, but probably isn't: 'REQ-3' on line 244 -- Looks like a reference, but probably isn't: 'REQ-4' on line 250 -- Looks like a reference, but probably isn't: 'REQ-5' on line 259 -- Looks like a reference, but probably isn't: 'REQ-6' on line 324 -- Looks like a reference, but probably isn't: 'REQ-8' on line 359 -- Looks like a reference, but probably isn't: 'REQ-7' on line 354 -- Looks like a reference, but probably isn't: 'REQ-9' on line 365 -- Looks like a reference, but probably isn't: 'REQ-10' on line 372 -- Looks like a reference, but probably isn't: 'REQ-11' on line 224 -- Looks like a reference, but probably isn't: 'REQ-12' on line 228 == Missing Reference: '1' is mentioned on line 362, but not defined == Missing Reference: '2' is mentioned on line 363, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '32' Summary: 6 errors (**), 1 flaw (~~), 7 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Sipping 2 Internet Draft Jesske Roland 3 Document: Document: draft-jesske-sipping- Deutsche Telekom 4 tispan-requirements-00.txt Denis Alexeitsev 5 Deutsche Telekom 6 Miguel Garcia 7 Nokia 8 Expires: 24.November 2005 24.May 2005 10 Requirements for the Extensions to the Session Initiation 11 Protocol (SIP) for the TISPAN simulation services 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 43 This document describes a set of requirements and proposed 44 extensions for endorsing the Session Initiation Protocol. 45 used by the TISPAN NGN Project. These endorsements are needed to be 46 included into the 3GPP IMS specification on SIP (TS24.229 [32]) for 47 supporting the simulation services. 49 Table of Contents 51 1. Overview 52 2. Requirements for supporting simulation services within SIP 53 2.1 Simulation Services supported by TISPAN in Release1 54 2.2 Requirements to support the TISPAN Simulation Services. 55 3. Proposed SIP extensions 56 3.1 ACR[REQ-1] and [REQ-2] 57 3.2 TIP/TIR [REQ-3] 58 3.3 AOC [REQ-4] 59 3.4 CCBS [REQ-5] 60 3.5 MCID [REQ-6] 61 3.6 CW [REQ-7 62 3.7 CDIV [REQ-8] 63 4. Security Considerations 64 5. IANA Considerations 66 1. Overview 67 ETSI TISPAN is defining the release 1 of the TISPAN NGN. Generally 68 the TISPAN NGN bases on the 3GPP IMS Release 7 provided by 3GPP in 69 2005. 70 The TISPAN NGN Project has selected SIP profiled by 3GPP for their 71 IMS as the protocol used to establish and tear down multimedia 72 sessions in the context of its NGN. One requirement is that the 3GPP 73 core SIP defined in TS24.229 [32] shall be used for the TISPAN IMS 74 The goal for TISPAN is that only one IMS core specification is 75 defined for wire-line and wire-less multimedia applications. 76 While defining multimedia applications it is also needed to support 77 existing ISDN/PSTN supplementary services based on IMS. These 78 services used within the TISPAN IMS are called simulation services, 79 because they can not fulfill 100% of the capabilities of the 80 ISDN/PSTN equivalent. The 3GPP TS24.229 [32] is used to simulate the 81 regarding services but to fulfill the 82 requirements defined within TISPAN NGN Release 1 some further SIP 83 elements are needed. 85 This document defines some Requirements on the simulation services 86 with regard to extensions needed in SIP and proposes such SIP 87 elements. This document does not define the SIP elements in detail. 89 2. Requirements for supporting simulation services within SIP 91 2.1 Simulation Services supported by TISPAN in Release1 93 The following services are supported by TISPAN Release 1 95 -Communication DIVersion (CDIV). This simulation service allows the 96 diversion 97 of communications and the regarding service interworking with the 98 PSTN/ISDN network. 100 -CONFerence (CONF). This simulation service provides the possibility 101 to hold conferences with 3 or more users. 103 - Message Waiting Indication (MWI). This simulation service supports 104 an indication sent to the user to provide him with information about 105 the status of a voice/video/multimedia mail box. 107 -Originating Indication Presentation (OIP)/Originating Indication 108 Restriction (OIR). These simulation services support the 109 presentation or restriction of an identity to the terminating user. 110 They are the simulation of the ISDN/PSTN CLIP/CLIR services. 112 -Terminating Indication Presentation (TIP)/Terminating Indication 113 Restriction (TIR). These simulation services support the 114 presentation or restriction of a identity of the terminating user to 115 the originating user. They are the simulation of the ISDN/PSTN 116 COLP/COLR services. 118 -Communication Waiting (CW). This simulation service provides the 119 ability to the terminating user to be informed at the time a 120 communication is coming in, and that no resources are available for 121 that incoming communication. The terminating user has then the 122 choice of accepting, rejecting or ignoring the incoming 123 communication. The originating user will be informed that his 124 communication is waiting. 126 -Communication HOLD (HOLD). This simulation service supports the 127 possibility of suspending the communication (on hold) while for 128 example another communication with another user is to be done. 130 -Anonymous Communication Rejection (ACR). This simulation service 131 supports that communications with anonymous originating identity can 132 be rejected. 134 -Advice of Charge (AoC). This simulation service supports the 135 displaying of tariff information to the originating user. 137 -Communication Completion on Busy Subscriber (CCBS). This simulation 138 service supports the ability to complete a requested communication 139 to a user without having to make a new communication attempt when 140 the destination B becomes not busy anymore. 142 -Communication Completion on non Reply (CCNR). This simulation 143 service supports the ability to complete a requested communication 144 to a user without having to make a new communication attempt when 145 the destination B showed activity (a communication attempt was 146 done). 148 -Malicious Communication IDentification (MCID). This simulation 149 service enables an incoming communication to be identified and 150 registered. 152 -Concerning the simulation services CONF, MWI, OIP, OIR and HOLD no 153 further SIP elements are needed. With regard to the other above 154 mentioned services extensions of SIP are needed. 156 2.2 Requirements to support the TISPAN Simulation Services. 158 [REQ-1] 159 For supporting the ACR simulation service it is needed inform the 160 originating party that the communication was rejected due to this 161 service. 163 [REQ-2] 164 It shall be possible for authorities to override an ACR service 165 offered to a terminating user. 167 [REQ-3] 168 For supporting the seamless interworking of PBX with SIP based PBX 169 terminals it is needed to identify the private extension of a PBX 170 users. This identity is required for the TIP service. 172 [REQ-4] 173 For the AoC simulation service a possibility is needed that the AoC 174 simulation service is requested by the originating 175 user. This request is sent when initializing the communication. 177 [REQ-5] 178 As part of the AoC simulation service a mechanism is needed to 179 asynchronously transport the charging information 181 [REQ-6] 182 The CCBS simulation service requires specific service logic on both 183 the originating and terminating side of the network. This service 184 logic is managed by Application Servers. In order to assure that end 185 to end functionality of the service is possible, an indication that 186 CCBS is possible sent by the terminating side to the originating 187 side is required. 189 Also additional status information CCBS user busy/free and the 190 Service status CCBS Suspend, Recall and Resume for the service is 191 required. 193 [REQ-7] 194 For the MCID simulation service it is needed to request information 195 if the 196 address of the originating user is missing. It shall be possible to 197 request MCID on a per Call basis. 198 For interoperability reasons a Request-Response mechanism. 200 [REQ-8] 201 For CW simulation service it is required that terminating user shall 202 be informed that a Communication is 203 aiting. It shall be possible to inform the originating user, that 204 the 205 Communication is a waiting communication. 207 [REQ-9] 208 For interoperability reasons and service compatibility it is 209 required that for CDIV that the call history (forwarding users, 210 reasons and number of redirections)shall be send in forward and 211 backward direction to the originating and terminating side. 212 Additionally it is required that a the originating user may be 213 informed if a communication diversion appears and shows or restrict 214 the indication of the diverting user. 216 [REQ-10] 217 For CCNR simulation service it is needed that the terminating side 218 can indicate the support of CCNR. 219 Also additional status information regarding the CCNR user no- 220 reply/busy/free and the Service status CCBS Suspend, Recall and 221 Resume is also needed. This is also needed for interoperability 222 reasons. 224 [REQ-11] 225 For TIP the terminating side needes to get the information "TIP 226 requested" that the originating side is requesting the TIP service. 228 [REQ-12] 229 For all simulation services interoperability with the PSTN/ISDN is 230 needed. 232 3. Proposed SIP extensions 234 The following section could be seen as collected thoughts what 235 possibilities are given to fulfill the above mentioned requierements. 236 This section show ideas and the authoe is happy for further proposals. 238 3.1 ACR[REQ-1] and [REQ-2] 240 For this simulation service a privacy indication is needed to 241 indicate that the network restricts the P-Asserted-ID and that the 242 Reason header can be included in Responses. 244 3.2 TIP/TIR [REQ-3] 246 For this simulation service an additional Identity header is needed 247 that is send from the connected SIP user like the From header from 248 the originating user. 250 3.3 AOC [REQ-4] 252 For the AOC simulation a P-Header or a XML MIME could be used to 253 request a AOC information (tariff information how much a call will 254 be billed). 256 A MIME has to be defined for providing the Charging information to 257 the user. 259 3.4 CCBS [REQ-5] 261 With regard to discussions take place in ETSI TISPAN the following 262 approach to propose a CCBS Event Package was discussed: 264 Proposed CCBS Event Package 266 The CCBS event package aims at managing subscriptions to CCBS 267 service, and especially targets queues management, according to the 268 previously described mechanism. 269 Specifically, the CCBS event package carries the following 270 information that concurs to build a subscription target: 272 caller : the subscriber to the CCBS service. When the subscription 273 is handled by the caller AS on behalf of the actual caller, then 274 this information is added to the Event: header as a �caller� 275 parameter; while when the caller is directly handling the 276 subscription, this parameter can be omitted. 278 callee: the user which the caller asked the CCBS service for. It is 279 the target user already contained in the To: header 281 queue: this information is needed for the CCBS Event Server to know 282 whether to put this new subscription in the queue or not. Such 283 information is an Event Header parameter.Possible values are 284 "true","false", "suspend" (to suspend its place in queue), "resume" 285 to resume its place in queue. 287 Hence, the CCBS Event: header will look like, for example 289 To start CCBS subscription: 290 Event: ccbs;queue=true;caller=sip:+390112285111@example.com 292 To suspend CCBS service (for instance, if caller is busy ): 293 Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com 295 To resume CCBS service: 296 Event: ccbs;queue=resume;caller= sip:+390112285111@example.com 298 Since the main difference between the "ccbs" event package and the 299 "dialog" event package lies in the way subscriptions and 300 notifications are handled, there is no need to change the contents 301 of the XML documents exchanged therein, so CCBS Event Package 302 notifications should contain a Dialog Information document, 303 according to the same rules described in "draft-ietf-sipping-dialog- 304 package-05.txt", for example: 306 307 310 311 confirmed 312 313 315 This allows to "tunnel" Dialog Information documents contained in 316 dialog package notifications originated by endpoints into ccbs 317 package notifications sent by application server. 319 From discussion point of view there are thoughts that the inclusion 320 of the allow-event header in all responses is useful for the CCBS 321 case to indicate a CCBS possible. This is at the moment not possible 322 as mentioned in RFC 3265. 324 3.5 MCID [REQ-6] 326 For MCID an event package shall be defined to request MCID and 327 request missing numbers. 329 Several solutions are possible like a new event package (as shown 330 below) or extending existing event packages or using a XML Mime 331 Body. 333 Example new Event Package: 334 package name: mcid-request-info 335 Body Format Syntax 336 mcid-request = mcid-request-line CRLF 337 mcid-request-line = "MCID-Request" HCOLON mcid-request; mcid- 338 holding-request 339 mcid-request = "MCID requested" / "MCID not requested" 340 mcid-holding-status= "holding not provided"/ "holding provided" 341 originating-URI = TEL-URI / SIP-URI / SIPS-URI / absolute URI 343 package name: mcid-response-info 344 Body Format Syntax 345 mcid-information = mcid-status-line CRLF 346 [originating-URI CRLF] 348 mcid-status-line = "MCID-Info" HCOLON mcid-info-status; mcid- 349 holding-status 350 mcid-info-status = "MCID included"/ "MCID not included" 351 mcid-holding-status= "holding not provided"/ "holding provided" 352 originating-URI = TEL-URI / SIP-URI / SIPS-URI / absoluteURI 354 3.6 CW [REQ-7] 356 For supporting this requirement a P-header or an MIME with XML 357 information is needed. 359 3.7 CDIV [REQ-8] 361 For supporting CDIV the approval of the drafts draft-ietf-sip- 362 history-info-06 [1] and draft-elwell-sipping-redirection-reason-01 363 [2] is needed. 365 3.8 CCNR [REQ-9] 367 For CCNR an event package shall be defined to indicate the CCNR 368 status information, call status and possibility of CCNR. 370 The same solution as proposed in section 3.4 could be done. 372 3.9 TIP [REQ-10] 374 For indicating that user A wants to have TIP a P-header or an XML- 375 MIME is needed. 377 4. Security Considerations 379 The requirements in this document are intended to result in a 380 mechanism with general applicability for the NGN TISPAN and NOT on 381 the Internet. 383 Use of this mechanism in any other context has serious security 384 shortcomings, namely that there is absolutely no guarantee that the 385 information has not been modified, or was even correct in the first 386 place. 388 5. IANA Considerations 390 This document does not have any implications for IANA. 392 References 394 [1]IETF An Extension to the Session Initiation Protocol for Request 395 History Information; draft-ietf-sip-history-info-06.txt; Expires: 396 April 21, 2005 397 [2]Elwell; "draft-elwell-sipping-redirection-reason-01.txt"; SIP 398 Reason header extension for indicating redirection reasons 399 [5]ETSI EN 300 089 (V3.1.1): "Integrated Services Digital Network 400 (ISDN); Calling Line Identification Presentation (CLIP) 401 supplementary service; Service description". 402 [6]ETSI EN 300 090 (V1.2.1): "Integrated Services Digital Network 403 (ISDN); Calling Line Identification Restriction (CLIR) 404 supplementary service; Service description". 405 [7]ETSI ETS 300 200 (Edition 1): "Integrated Services Digital 406 Network (ISDN); Call Forwarding Unconditional (CFU) supplementary 407 service; Service description". 408 [8]ETSI EN 300 199 (V1.2.1): "Integrated Services Digital Network 409 (ISDN); Call Forwarding Busy (CFB) supplementary service; Service 410 description". 411 [9]ETSI EN 300 201 (V1.2.1): "Integrated Services Digital Network 412 (ISDN); Call Forwarding No Reply (CFNR) supplementary service; 413 Service description". 415 [10]ETSI ETS 300 202 (Edition 1): "Integrated Services Digital 416 Network (ISDN); Call Deflection (CD) supplementary service; 417 Service description". 418 [11]ETSI ETS 300 056 (Edition 1): "Integrated Services Digital 419 Network (ISDN); Call Waiting (CW) supplementary service; Service 420 description". 421 [12]ETSI ETS 300 139 (Edition 1): "Integrated Services Digital 422 Network (ISDN); Call Hold (HOLD) supplementary service; Service 423 description". 424 [13]ETSI ETS 300 128 (Edition 1): "Integrated Services Digital 425 Network (ISDN); Malicious Call Identification (MCID) 426 supplementary service; Service description". 427 [14]ETSI ETS 300 186 (Edition 1): "Integrated Services Digital 428 Network (ISDN); Three-Party (3PTY) supplementary service; Service 429 description". 430 [15]ETSI ETS 300 183 (Edition 1): "Integrated Services Digital 431 Network (ISDN); Conference call, add-on (CONF) supplementary 432 service; Service description". 433 [16]ETSI ETS 300 164 (Edition 1): "Integrated Services Digital 434 Network (ISDN); Meet-Me Conference (MMC) supplementary service; 435 Service description". 436 [17]ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network 437 (ISDN); Completion of Calls to Busy Subscriber (CCBS) 438 supplementary service; Service description". 439 [18]ETSI ETS 300 178 (Edition 1): "Integrated Services Digital 440 Network (ISDN); Advice of Charge: charging information at call 441 set-up time (AOC-S) supplementary service; Service description". 442 [19]ETSI ETS 300 179 (Edition 1): "Integrated Services Digital 443 Network (ISDN); Advice of Charge: charging information during the 444 call (AOC-D) supplementary service; Service description". 445 [20]ETSI ETS 300 180 (Edition 1): "Integrated Services Digital 446 Network (ISDN); Advice of Charge: charging information at the end 447 of the call (AOC-E) supplementary service; Service description". 448 [21]ETSI ETS 300 136 (Edition 1): "Integrated Services Digital 449 Network (ISDN); Closed User Group (CUG) supplementary service; 450 Service description". 451 [22]ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network 452 (ISDN); Message Waiting Indication (MWI) supplementary service; 453 Service description". 454 [23]ETSI EN 300 062: "Integrated Services Digital Network 455 (ISDN);Direct Dialling In (DDI) supplementary service; Service 456 Description". 457 [24]ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network 458 (ISDN);Explicit Call Transfer (ECT) supplementary service; 459 Service description". 460 [25]ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced 461 Networks (SPAN);Anonymous Call Rejection (ACR) Supplementary 462 Service; Service description". 463 [26]ETSI DTR/AT-030031: "Simultaneous Voice and Text Announcements". 465 [27]ETS 300 648 (1997): "Public Switched Telephone Network (PSTN); 466 Calling Line Identification Presentation (CLIP) supplementary 467 service; Service description". 468 [28]EN 300 659-1 (V1.2): "Public Switched Telephone Network (PSTN); 469 Subscriber line protocol over the local loop for display (and 470 related) services; Part 1: On-hook data transmission". 471 [29]EN 300 659-2 (V1.2): "Public Switched Telephone Network (PSTN); 472 Subscriber line protocol over the local loop for display (and 473 related) services; Part 2: Off-hook data transmission". 474 [30]EN 300 659-3 (V1.2): "Public Switched Telephone Network (PSTN); 475 Subscriber line protocol over the local loop for display (and 476 related) services; Part 3: Data link message and parameter 477 codings". 478 [31]ETS 300 649 (1997): "Public Switched Telephone Network (PSTN); 479 Calling Line Identification Restriction (CLIR) supplementary 480 service; Service description". 481 [32] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on 482 SIP and SDP". 484 Contributors 485 Keith Drage 486 Lucent Technologies 487 GSM OPTIMUS HOUSE 488 SN5 6PP SWINDON 489 United Kingdom 490 Phone: +44 1793 897312 491 Email: drage@lucent.com 493 Acknowledgments 495 Anna Martinez with comments and editing, the people of TISPAN WG3 496 bringing in the comments. 498 Author's Addresses 500 Roland Jesske 501 Deutsche Telekom 502 Am Kavalleriesand 3 503 64307 Darmstadt 504 Germany 505 Phone: +496151835940 506 Email: r.jesske@t-com.net 507 Denis Alexeitsev 508 Deutsche Telekom 509 Am Kavalleriesand 3 510 64307 Darmstadt 511 Germany 512 Phone: +496151832130 513 Email: d.alexeitsev@t-com.net 515 Miguel Garcia 516 NOKIA Corporation 517 Itaemerenkatu 11-13 518 00180 Helsinki 519 Finland 520 Phone: +358504804586 521 Email: miguel.an.garcia@nokia.com 523 Full Copyright Statement 525 Copyright (C) The Internet Society (2005). 527 This document is subject to the rights, licenses and restrictions 528 contained in BCP 78, and except as set forth therein, the authors 529 retain all their rights. 531 This document and the information contained herein are provided on 532 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 533 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 534 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 535 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 536 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 537 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Intellectual Property 541 The IETF takes no position regarding the validity or scope of any 542 Intellectual Property Rights or other rights that might be claimed 543 to pertain to the implementation or use of the technology described 544 in this document or the extent to which any license under such 545 rights might or might not be available; nor does it represent that 546 it has made any independent effort to identify any such rights. 547 Information on the procedures with respect to rights in RFC 548 documents can be found in BCP 78 and BCP 79. 550 Copies of IPR disclosures made to the IETF Secretariat and any 551 assurances of licenses to be made available, or the result of an 552 attempt made to obtain a general license or permission for the use 553 of such proprietary rights by implementers or users of this 554 specification can be obtained from the IETF on-line IPR repository 555 at http://www.ietf.org/ipr. 557 The IETF invites any interested party to bring to its attention any 558 copyrights, patents or patent applications, or other proprietary 559 rights that may cover technology that may be required to implement 560 this standard. Please address the information to the IETF at ietf- 561 ipr@ietf.org. 563 Acknowledgement 565 Funding for the RFC Editor function is currently provided by the 566 Internet Society.