idnits 2.17.1 draft-ietf-sipping-gruu-reg-event-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 675. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([3], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 6, 2007) is 6111 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) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-14 -- Obsolete informational reference (is this intentional?): RFC 3455 (ref. '6') (Obsoleted by RFC 7315) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipping P. Kyzivat 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track July 6, 2007 5 Expires: January 7, 2008 7 Registration Event Package Extension for Session Initiation Protocol 8 (SIP) Globally Routable User Agent URIs (GRUUs) 9 draft-ietf-sipping-gruu-reg-event-09 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 January 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 RFC 3680 defines a Session Initiation Protocol (SIP)[5] event package 43 for registration state. This package allows a watcher to learn about 44 information stored by a SIP registrar, including its registered 45 contact. 47 However, the registered contact is frequently unreachable and thus 48 not useful for watchers. The Globally Routable User Agent URI 49 (GRUU), defined in RFC YYYY [3], is a URI that is capable of reaching 50 a particular contact. However this URI is not included in the 51 document format defined in RFC 3680. This specification defines an 52 extension to the registration event package to include GRUUs assigned 53 by the registrar. 55 [[NOTE TO RFC-EDITOR/IANA: Please replace YYYY throughout this 56 document with the RFC number assigned to the referenced draft [3] 57 when it is published.]] 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4 65 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4 66 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5 67 6.1. Managing Temporary GRUU Lifetime . . . . . . . . . . . . . 5 68 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 6 69 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 7 71 8.2. Example: Implicit Registration . . . . . . . . . . . . . . 8 72 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12 75 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. Introduction 86 RFC 3680 [2] defines a Session Initiation Protocol (SIP) event 87 package for registration state. This package allows a watcher to 88 learn about information stored by a SIP registrar, including the 89 registered contacts. 91 However, a registered contact is frequently unreachable from hosts 92 outside of the domain of the user agent. It is commonly a private 93 address, or even when public direct access to it may be blocked by 94 firewalls. 96 The Globally Routable User Agent URI (GRUU), defined in RFC YYYY [3], 97 is a URI that reaches a particular UA instance, but is reachable by 98 any host on the Internet. GRUUs assigned by the registrar represent 99 additional registration state. However, GRUUs assigned by the 100 registrar are not included in the notifications provided by RFC 3680. 101 For many applications of the registration event package, a GRUU is 102 needed, and not the registered contact. 104 For example, the Welcome Notices example in [2] will only operate 105 correctly if the contact address in the "reg" event notification is 106 reachable by the sender of the welcome notice. When the registering 107 device is using the GRUU extension, it is likely that the registered 108 contact address will not be globally addressable, and a GRUU should 109 be used as the target address for the MESSAGE. 111 Another case where this feature may be helpful is within the 3GPP IP 112 Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER 113 of a contact address to one Address of Record (AOR) causes the 114 implicit registration of the same contact to other associated AORs. 115 If GRUUs are requested and obtained as part of the registration 116 request, then additional GRUUs will also be needed for the implicit 117 registrations. While assigning the additional GRUUs is 118 straightforward, informing the registering UA of them is not. In 119 IMS, UAs typically subscribe to the "reg" event, and subscriptions to 120 the "reg" event for an AOR result in notifications containing 121 registration state for all the associated AORs. The proposed 122 extension provides a way to easily deliver the GRUUs for the 123 associated AORs. 125 As specified in RFC YYYY [3], temporary GRUUs are invalidated when 126 contact address bindings for the corresponding AOR and instance id 127 are not refreshed, or when a registration to the AOR and instance id 128 is performed with a new Call-Id. A UA cannot always determine with 129 certainty which temporary GRUUs are valid based solely on the 130 response to the REGISTER requests it has issued, or from 131 notifications according to RFC 3680 [2]. The herein defined 132 extension provides sufficient information for a UA to determine which 133 temporary GRUUs are valid. 135 The "reg" event package has provision for including extension 136 elements within the element. This document defines new 137 elements that may be used in that context to deliver the public and 138 temporary GRUUs corresponding to the contact. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. [1] 146 3. Description 148 Two new elements ( and ) are defined, each of 149 which contains a GRUU. The element also identifies the 150 oldest temporary gruu that is currently valid. 152 These optional elements may be included within the body of a NOTIFY 153 for the "reg" event package when GRUUs are associated with the 154 contact. The contact URI and the GRUUs are then all available to the 155 watcher. 157 4. Notifier Processing of SUBSCRIBE Requests 159 Unchanged from RFC 3680 [2]. 161 5. Notifier Generation of NOTIFY Requests 163 A notifier for the "reg" event package [2] SHOULD include the element when a contact has an Instance ID and a public GRUU is 165 associated with the combination of the AOR and the Instance ID. When 166 present, the element MUST be be positioned as a child of 167 the element. 169 A notifier for the "reg" event package [2] MAY include the element when a contact has an Instance ID and a temporary GRUU 171 is associated with the combination of the AOR and the Instance ID. 172 This element SHOULD be included if the subscriber is also authorized 173 to register to the AOR. This element SHOULD NOT be included if the 174 subscriber is not authorized to register to the AOR, unless there is 175 an explicitly configured policy directing that it be included. When 176 present, the element MUST be be positioned as a child of 177 the element. 179 Note that it is possible for multiple registered contacts to share 180 the same instance ID. In such a case, each element will 181 have child and elements, and those child 182 elements of each element will be identical. Since a 183 particular contact can not be associated with more than one instance 184 ID, a element will never have more than one and 185 one child element. 187 If the notifier includes the element it MUST populate the 188 element with the public GRUU that is associated with the instance ID 189 and AOR of the registered contact. 191 If the notifier includes the element it MUST populate the 192 element with the most recently assigned temporary GRUU that is 193 associated with the instance ID and AOR of the registered contact. 194 It MUST also populate the element with the CSeq value of the first 195 currently active temporary GRUU that is associated with the instance 196 ID and AOR of the registered contact. The CSeq value is the CSeq of 197 the REGISTER request that caused that temporary GRUU to be assigned. 199 6. Subscriber Processing of NOTIFY Requests 201 When a subscriber receives a "reg" event notification with a 202 containing a it MAY associate the public GRUU 203 with corresponding AOR and Instance ID. Any previously received 204 public GRUU for the same AOR and Instance ID MUST be discarded. (It 205 will no longer function.) 207 When a subscriber receives a "reg" event notification with a 208 containing a it MAY associate the temp GRUU, 209 together with the "callid" and "cseq" attributes, with the 210 corresponding AOR and Instance ID. 212 Subscribers that are unaware of this extension will, as required by 213 [2], ignore the and elements. 215 6.1. Managing Temporary GRUU Lifetime 217 Section 4.2 of RFC YYYY [3] gives guidance for developers of UAs on 218 how to ensure that only valid temporary GRUUs are retained and used 219 by the UA. A UA cannot always determine with certainty which 220 temporary GRUUs are valid based solely on the response to the 221 REGISTER requests it has issued, or from notifications according to 222 RFC 3680 [2]. The herein defined extensions to RFC 3680 provide 223 added information to help with that process. The following are steps 224 that the UA MAY take to ensure it only retains valid GRUUs: 225 o The UA should subscribe to the "reg" event package for the AOR it 226 is registering. 227 o When a UA receives a 2xx response to a REGISTER request, it may 228 extract and retain temporary GRUUs from the response for future 229 use as long as they remain valid. Appropriate GRUUs to retain are 230 those corresponding to the Contact address and instance ID it has 231 registered. (Typically the UA will register only one Contact 232 address, and so receive at most one temporary GRUU.) 233 o The UA may add the temporary GRUU to the set of valid temporary 234 GRUUs associated with the AOR. (The To-address of the REGISTER 235 request.) To aid in tracking validity the UA should also remember 236 the Call-ID and CSeq values of the REGISTER response containing 237 the temporary GRUU. 238 o If the UA receives a "reg" event notification with an AOR that it 239 supports and a , for a contact address and instance ID it 240 has registered, that contains a it may update its set 241 of valid temporary GRUUs associated with the AOR, as follows: 242 * It may add the temporary GRUU to the set. To aid in tracking 243 validity the UA should also remember the "callid" and "cseq" 244 attributes of the . 245 * It should remove any temporary GRUUs with a callid value 246 different from that in the value of the "callid" attribute of 247 the , or with a cseq value less than the value of the 248 "first-cseq" attribute of the . 249 o If the UA receives a "reg" event notification with an AOR that it 250 supports, and there are no entries for its instance ID, 251 then it should discard all the temporary GRUUs it has saved for 252 that AOR. 254 7. Sample reginfo Document 256 Note: This example and others in the following section are 257 indented for readability by the addition of a fixed amount of 258 whitespace to the beginning of each line. This whitespace is not 259 part of the example. The conventions of [7] are used to describe 260 representation of long message lines. 262 The following is an example registration information document 263 including the new element: 265 266 269 271 275 sip:user@192.0.2.1 276 277 278 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 279 280 281 282 284 285 286 288 289 290 291 293 8. Examples 295 Note: In the following examples the SIP messages have been 296 simplified, removing headers that are not pertinent to the example. 298 When the value of the Content-Length header field is "..." this means 299 that the value should be whatever the computed length of the body is. 301 8.1. Example: Welcome Notice 303 Consider the Welcome Notices example in [2]. When the application 304 server receives a notification of a new registration containing the 305 reginfo shown in Section 7 it should address messages using the 306 contained public GRUU as follows: 308 MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0 309 To: 310 From: "SIPland Notifier" ;tag=7xy8 311 Content-Type: text/plain 312 Content-Length: ... 314 Welcome to SIPland! 315 Blah, blah, blah. 317 8.2. Example: Implicit Registration 319 In an 3GPP IMS setting, a UA may send a single register message, 320 requesting assignment of GRUUs, as follows: 322 REGISTER sip:example.net SIP/2.0 323 From: ;tag=5ab4 324 To: 325 Call-Id: faif9a@ua.example.com 326 CSeq: 23001 REGISTER 327 Contact: 328 ;expires=3600 329 ;+sip.instance="" 330 Supported: path, gruu 331 Content-Length: 0 333 The response reports success of the registration and returns the 334 GRUUs assigned for the combination of AOR, Instance ID, and Contact. 335 It also indicates (via the P-Associated-URI header [6]) that there 336 are two other associated AORs that may have been implicitly 337 registered using the same contact. Each of those implicitly 338 registered AORs will have unique GRUUs assigned. The REGISTER 339 response will not include those GRUUs; it will only include the GRUUs 340 for the AOR and instance ID explicitly included in the registration. 342 SIP/2.0 200 OK 343 From: ;tag=5ab4 344 To: ;tag=373392 345 Call-Id: faif9a@ua.example.com 346 CSeq: 23001 REGISTER 347 Path: 348 Service-Route: 349 Contact: 350 ;expires=3600 351 ;+sip.instance="" 352 ;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a" 353 ;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr" 354 P-Associated-URI: , 355 357 Content-Length: 0 359 The UA then subscribes to the "reg" event package as follows: 361 SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 362 From: ;tag=27182 363 To: 364 Call-Id: gbjg0b@ua.example.com 365 CSeq: 45001 SUBSCRIBE 366 Route: 367 Event: reg 368 Expires: 3600 369 Accept: application/reginfo+xml 370 Contact: 371 Content-Length: 0 373 (The successful response to the subscription is not shown.) Once the 374 subscription is established an initial notification is sent giving 375 registration status. In IMS deployments the response includes, in 376 addition to the status for the requested URI, the status for the 377 other associated URIs. 379 NOTIFY sip:user_aor_1@example.net;gr=hha9s8d-999a SIP/2.0 380 From: ;tag=27182 381 To: ;tag=262281 382 Call-Id: gbjg0b@ua.example.com 383 CSeq: 633 NOTIFY 384 Subscription-State: active;expires=3600 385 Event: reg 386 Content-Type: application/reginfo+xml 387 Contact: 388 Content-Length: ... 390 391 394 396 399 400 sip:ua.example.com 401 402 403 404 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 405 406 407 408 410 411 412 414 415 416 417 419 422 423 sip:ua.example.com 424 425 426 427 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 428 429 430 431 433 434 435 437 438 439 440 444 447 448 sip:ua.example.com 449 450 451 452 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 453 454 455 456 458 459 460 462 463 464 465 467 The status indicates that the associated URIs all have the same 468 contact registered. It also includes the unique GRUUs that have been 469 assigned to each. The UA may then retain those GRUUs for use when 470 establishing dialogs using the corresponding AORs. 472 9. XML Schema Definition 474 The and elements are defined within a new XML 475 namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". 476 The schema for these elements is: 478 479 484 485 487 488 489 490 491 494 495 496 497 498 500 502 10. IANA Considerations 504 There are two IANA considerations associated with this specification. 506 10.1. URN Sub-Namespace Registration 508 This section registers a new XML namespace, per the guidelines in 509 [4]. 511 URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo 513 Registrant Contact: IETF, SIPPING working group, , 514 Paul Kyzivat 516 XML: 518 BEGIN 519 520 522 523 524 526 Reg Information GRUU Extension Namespace 527 528 529

Namespace for Reg Information GRUU Extension

530

urn:ietf:params:xml:ns:gruuinfo

531

See RFCXXXX [[NOTE 532 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 533 this specification]].

534 535 536 END 538 10.2. XML Schema Registration 540 This section registers an XML schema per the procedures in [4]. 542 URI: urn:ietf:params:xml:schema:gruuinfo. 544 Registrant Contact: IETF, SIPPING working group, , 545 Paul Kyzivat 546 The XML for this schema can be found in Section 9. 548 11. Security Considerations 550 Security considerations for the registration event package are 551 discussed in RFC 3680 [2], and those considerations apply here. 553 If a contact address obtained via subscription to the registration 554 event package is not reachable by the subscriber then its disclosure 555 may arguably be considered a minimal security risk. In that case the 556 inclusion of a GRUU may be considered to increase the risk by 557 providing a reachable address. On the other hand requests addressed 558 to a GRUU are always first processed by the servicing proxy before 559 they reach the intended user agent. The proxy may control access as 560 desired, just as it may for the AOR. For instance, the proxy 561 servicing a GRUU may accept requests from senders whose identity 562 appears on a white list, and reject other requests. In this respect 563 disclosing a GRUU presents no more risk than disclosing the AOR. 565 Temporary GRUUs have an additional security consideration. The 566 intent of the temporary GRUU is to provide a contact address that 567 cannot be correlated to the identity of the calling party. The 568 recipient of a call using a temporary GRUU may guess the identity of 569 the calling party and then attempt to obtain the temporary GRUUs 570 assigned to that caller to confirm the conjecture. Two possible 571 approaches to obtaining the temporary GRUUs are: 573 o Send a REGISTER request to a conjectured caller. 574 o Send a SUBSCRIBE request for the "reg" event package to the 575 conjectured caller. 577 Typically REGISTER is restricted to devices or users that are 578 authorized to originate and received calls with the AOR. Anonymity 579 among users of the same AOR is hard to achieve and typically 580 unnecessary. It is recommended (see Section 5) that the 581 authorization policy for the "reg" event package permit only those 582 subscribers authorized to register to the AOR to receive temporary 583 GRUUs. With this policy, the confidentiality of the temporary GRUU 584 will be the same with and without the "reg" event package. User 585 agents that use a temporary GRUU should note that confidentiality 586 does not extend to parties that are permitted to register to the AOR 587 or obtain the temporary GRUU when subscribing the "reg" event 588 package. 590 12. Acknowledgements 592 The author would like to thank Jonathan Rosenberg for help with this 593 draft, and Jari Urpalainen for assistance with the XML. 595 13. References 597 13.1. Normative References 599 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 600 Levels", BCP 14, RFC 2119, March 1997. 602 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 603 Package for Registrations", RFC 3680, March 2004. 605 [3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 606 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 607 draft-ietf-sip-gruu-14 (work in progress), June 2007. 609 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 610 January 2004. 612 13.2. Informative References 614 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 615 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 616 Session Initiation Protocol", RFC 3261, June 2002. 618 [6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header 619 (P-Header) Extensions to the Session Initiation Protocol (SIP) 620 for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, 621 January 2003. 623 [7] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. 624 Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 625 Messages", RFC 4475, May 2006. 627 Author's Address 629 Paul H. Kyzivat 630 Cisco Systems, Inc. 631 1414 Massachusetts Avenue 632 Boxborough, MA 01719 633 USA 635 Email: pkyzivat@cisco.com 637 Full Copyright Statement 639 Copyright (C) The IETF Trust (2007). 641 This document is subject to the rights, licenses and restrictions 642 contained in BCP 78, and except as set forth therein, the authors 643 retain all their rights. 645 This document and the information contained herein are provided on an 646 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 647 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 648 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 649 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 650 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 651 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 653 Intellectual Property 655 The IETF takes no position regarding the validity or scope of any 656 Intellectual Property Rights or other rights that might be claimed to 657 pertain to the implementation or use of the technology described in 658 this document or the extent to which any license under such rights 659 might or might not be available; nor does it represent that it has 660 made any independent effort to identify any such rights. Information 661 on the procedures with respect to rights in RFC documents can be 662 found in BCP 78 and BCP 79. 664 Copies of IPR disclosures made to the IETF Secretariat and any 665 assurances of licenses to be made available, or the result of an 666 attempt made to obtain a general license or permission for the use of 667 such proprietary rights by implementers or users of this 668 specification can be obtained from the IETF on-line IPR repository at 669 http://www.ietf.org/ipr. 671 The IETF invites any interested party to bring to its attention any 672 copyrights, patents or patent applications, or other proprietary 673 rights that may cover technology that may be required to implement 674 this standard. Please address the information to the IETF at 675 ietf-ipr@ietf.org. 677 Acknowledgment 679 Funding for the RFC Editor function is provided by the IETF 680 Administrative Support Activity (IASA).