idnits 2.17.1 draft-ietf-sipping-pending-additions-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 722. 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 (February 15, 2008) is 5908 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 564, but not defined ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-04) exists of draft-ietf-simple-xml-patch-ops-02 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING G. Camarillo 3 Internet-Draft Ericsson 4 Intended status: Standards Track February 15, 2008 5 Expires: August 18, 2008 7 The Session Initiation Protocol (SIP) Pending Additions Event Package 8 draft-ietf-sipping-pending-additions-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 18, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines the SIP Pending Additions event package. This 42 event package is used by SIP relays to inform user agents about the 43 consent-related status of the entries to be added to a resource list. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 50 4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 3 51 5. Pending Additions Event Package Definition . . . . . . . . . . 5 52 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 53 5.1.1. Event Package Parameters . . . . . . . . . . . . . . . 5 54 5.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 5 55 5.1.3. Subscription Duration . . . . . . . . . . . . . . . . 5 56 5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 5 57 5.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 6 58 5.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 6 59 5.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 6 60 5.1.8. Handling of Forked Requests . . . . . . . . . . . . . 6 61 5.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 7 62 5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Partial Notifications . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Generation of Partial Notifications . . . . . . . . . . . 8 66 6.2. Processing of Partial Notifications . . . . . . . . . . . 9 67 6.3. XML Schema for Partial Notifications . . . . . . . . . . . 9 68 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. SIP Event Package Registration . . . . . . . . . . . . . . 12 71 7.2. URN Sub-Namespace Registration: consent-status . . . . . . 12 72 7.3. XML Schema Registration: consent-status . . . . . . . . . 13 73 7.4. XML Schema Registration: resource-lists . . . . . . . . . 13 74 7.5. MIME type Registration: 75 application/resource-lists-diff+xml . . . . . . . . . . . 13 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 17 82 1. Introduction 84 The framework for consent-based communications in SIP 85 [I-D.ietf-sip-consent-framework] identifies the need for users 86 manipulating the translation logic at a relay (e.g., adding a new 87 recipient) to be informed about the consent-related status of the 88 recipients of a given translation. That is, the user manipulating 89 the translation logic needs to know which recipients have given the 90 relay permission to send them SIP requests. 92 This document defines a SIP event package whereby user agents can 93 subscribe to the consent-related state of the resources that are 94 being added to a resource list that defines a translation. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User 103 Agent), or some hybrid, that receives a request, translates its 104 Request-URI into one or more next-hop URIs (i.e., recipient URIs), 105 and delivers the request to those URIs. 107 3. Overview of Operation 109 A user agent subscribes to a relay using the Pending Additions event 110 package. NOTIFY requests within this event package can carry an XML 111 document in the "application/resource-lists+xml" format [RFC4826] or 112 in the "application/resource-lists-diff+xml" format, which is based 113 on XML patch operations [I-D.ietf-simple-xml-patch-ops]. 115 A document in the "application/resource-lists+xml" format provides 116 the user agent with the whole list of resources being added to a 117 resource list along with the consent-related status of those 118 resources. A document in the "application/resource-lists-diff+xml" 119 format provides the user agent with the changes the list of resources 120 being added has experimented since the last notification sent to the 121 user agent. 123 4. XML Schema Definition 125 This section defines the element, which provides 126 consent-related information about a resource to be added to a relay's 127 translation logic. 129 A consent-status document is an XML document that MUST be well-formed 130 and SHOULD be valid. Consent-status documents MUST be based on XML 131 1.0 and MUST be encoded using UTF-8. This specification makes use of 132 XML namespaces for identifying consent-status documents. The 133 namespace URI for elements defined for this purpose is a URN, using 134 the namespace identifier 'ietf'. This URN is: 136 urn:ietf:params:xml:ns:consent-status 138 139 144 145 146 147 148 149 150 151 152 153 154 155 157 The element can take on the following values: 159 Pending: the relay has received a request to add a resource to its 160 translation logic and will ask for permission to do so. 162 Waiting: the relay has requested permission to add the resource to 163 its translation logic but has not gotten any answer from the 164 resource yet. 166 Error: the relay has requested permission to add the resource to its 167 translation logic and has received an error response (e.g., a SIP 168 error response to the MESSAGE request send to request permission). 169 That is, the permission document requesting permission could not 170 be delivered to the resource. 172 Denied: the resource has denied the relay permission to add the 173 resource to the relay's translation logic. 175 Granted: the resource has granted the relay permission to add the 176 resource to the relay's translation logic. 178 Section 5.1.11 contains an example of an "application/ 179 resource-lists+xml" document that carries consent-related state 180 information using elements. 182 5. Pending Additions Event Package Definition 184 This section provides the details for defining a SIP [RFC3261] event 185 notification package, as specified by [RFC3265]. 187 5.1. Event Package Name 189 The name of this event package is "consent-pending-additions". This 190 package name is carried in the Event and Allow-Events header, as 191 defined in [RFC3265]. 193 5.1.1. Event Package Parameters 195 This package does not define any event package parameters. 197 5.1.2. SUBSCRIBE Bodies 199 A SUBSCRIBE for Pending Additions events MAY contain a body. This 200 body would serve the purpose of filtering the subscription. The 201 definition of such a body is outside the scope of this specification. 203 A SUBSCRIBE for the Pending Additions event package MAY be sent 204 without a body. This implies that the default session policy 205 filtering policy has been requested. The default policy is that 206 notifications are generated every time there is any change in the 207 state of a resource in the list. 209 5.1.3. Subscription Duration 211 The default expiration time for a subscription is one hour (3600 212 seconds). 214 5.1.4. NOTIFY Bodies 216 In this event package, the body of the notifications contains a 217 resource list document. This document describes the resources being 218 added as recipients to a translation operation. All subscribers and 219 notifiers MUST support the "application/resource-lists+xml" data 220 format [RFC4826] and its extension to carry consent-related state 221 information, which is specified in Section 4. The SUBSCRIBE request 222 MAY contain an Accept header field. If no such header field is 223 present, it has a default value of "application/resource-lists+xml". 224 If the header field is present, it MUST include "application/ 225 resource-lists+xml", and MAY include any other types capable of 226 representing consent-related state. 228 Additionally, all subscribers and notifiers SHOULD support the 229 "application/resource-lists-diff+xml" format. Section 6 discusses 230 the usage of the Pending Additions event package with this format. 232 5.1.5. Notifier Processing of SUBSCRIBE Requests 234 The state of the resources to be added to a relay's translation logic 235 can reveal sensitive information. Therefore, all subscriptions 236 SHOULD be authenticated and then authorized before approval. 237 Authorization policy is at the discretion of the administrator. 239 5.1.6. Notifier Generation of NOTIFY Requests 241 A notifier for the Pending Additions event package SHOULD include the 242 element, which is defined in Section 4. The 243 element MUST be positioned as an instance of the 244 element within the element. 246 Notifications SHOULD be generated for the Pending Additions package 247 whenever there is a change in the consent-related state of a 248 resource. When a resource moves to the error, denied, or granted 249 states, and once a NOTIFY request is sent, the resource is removed 250 from further notifications. 252 5.1.7. Subscriber Processing of NOTIFY Requests 254 NOTIFY requests contain full state. The subscriber does not need to 255 perform any type of information aggregation. Section 6 discusses the 256 use of the Pending Additions event package with partial 257 notifications. 259 5.1.8. Handling of Forked Requests 261 The state of a given resource list is normally handled by a server 262 and stored in a repository. Therefore, there is usually a single 263 place where the resource-list state is resident. This implies that a 264 subscription for this information is readily handled by a single 265 element with access to this repository. There is, therefore, no 266 compelling need for a subscription to pending additions information 267 to fork. As a result, a subscriber MUST NOT create multiple dialogs 268 as a result of a single subscription request. The required 269 processing to guarantee that only a single dialog is established is 270 described in Section 4.4.9 of [RFC3265]. 272 5.1.9. Rate of Notifications 274 For reasons of congestion control, it is important that the rate of 275 notifications not become excessive. As a result, it is RECOMMENDED 276 that the server does not generate notifications for a single 277 subscriber at a rate faster than once every 5 seconds. 279 5.1.10. State Agents 281 State agents have no role in the handling of this package. 283 5.1.11. Example 285 The following is an example of an "application/resource-lists+xml" 286 document that carries consent-related state information using 287 elements: 289 290 292 293 294 Bill Doe 295 pending 296 297 298 Joe Smith 299 pending 300 301 302 Nancy Gross 303 granted 304 305 306 308 6. Partial Notifications 310 The lists of resources reported by this event package may contain 311 many resources. When the "application/resource-lists+xml" format is 312 used and there is a change in the consent-related status of a 313 resource, the server generates a notification with the whole list. 314 Generating large notifications to report small changes does not meet 315 the efficiency requirements of some bandwidth-constrained 316 environments. The partial notifications mechanism specified in this 317 section is a more efficient way to report changes in the status of 318 resources. 320 Subscribers signal support for partial notifications by including the 321 "application/resource-lists-diff+xml" format in the Accept header 322 field of the SUBSCRIBE requests they generate. If a client 323 subscribing to the Pending Additions event package generates an 324 Accept header field that includes the MIME type "application/ 325 resource-lists-diff+xml", the server has the option of returning 326 documents in this format (instead of in the "application/ 327 resource-list+xml" format). 329 6.1. Generation of Partial Notifications 331 Once a subscription is accepted and installed, the server MUST 332 deliver full state in its first notification. To report full state, 333 the server uses the regular format for resource lists. Consequently, 334 the server MUST set the Content-Type header field to the value 335 'application/resource-lists+xml'. 337 In order to deliver a partial notification, the server MUST set the 338 Content-Type header field to the value 'application/ 339 resource-lists-diff+xml'. When the server generates a partial 340 notification, the server SHOULD only include the information that has 341 changed compared to the previous notification. It is up to the 342 server's local policy to determine what is considered as a change to 343 the previous state. 345 The server MUST construct partial notifications according to the 346 following logic: all the information that has been added to the 347 document is listed inside elements. All information that has 348 been removed from the document is listed inside elements and 349 all information that has been changed is listed under 350 elements. 352 The server MUST NOT send a new NOTIFY request with a partial 353 notification until it has received a final response from the 354 subscriber for the previous one or the previous NOTIFY request has 355 timed out. 357 When the server receives a SUBSCRIBE request (refresh or termination) 358 within the associated subscription, it SHOULD send a NOTIFY request 359 containing the full document using the 'application/ 360 resource-lists+xml' content type. 362 If the server has used a content type other than 'application/ 363 resource-lists+xml' in notifications within the existing subscription 364 and changes to deliver partial notifications, the server MUST deliver 365 full state using the 'application/resource-lists+xml' content type 366 before generating its first partial notification. 368 6.2. Processing of Partial Notifications 370 When a subscriber receives the first notification containing full 371 state in a 'application/resource-lists+xml' MIME body, the subscriber 372 MUST store the received full document as its local copy. 374 When the subscriber receives a subsequent notification, the 375 subscriber MUST modify its locally-stored information according to 376 the following logic: 378 o If the notification carries a 'application/resource-lists+xml' 379 document, the subscriber MUST replace its local copy of the 380 document with the document received in notification. 382 o If the notification carries a 'application/ 383 resource-lists-diff+xml' document, the subscriber MUST apply the 384 changes indicated in the received 'application/ 385 resource-lists-diff+xml' document to its local copy of the full 386 document. 388 If subscriber encounters a processing error while processing a 389 'application/resource-lists-diff+xml' encoded document, the 390 subscriber SHOULD renew its subscription. A subscriber can fall back 391 to normal operations by not including the "application/ 392 resource-list-diff+xml' format in a new SUBSCRIBE request. 394 If the server changes the content type used in notifications within 395 the existing subscription, the subscriber MUST discard all the 396 previously received information and process the new content as 397 specified for that content type. 399 6.3. XML Schema for Partial Notifications 401 This is the XML schema for the "application/resource-lists-diff+xml" 402 data format. The "urn:ietf:params:xml:schema:xml-patch-ops" schema 403 is defined in [I-D.ietf-simple-xml-patch-ops]. 405 406 412 413 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 454 6.4. Examples 456 Section 5.1.11 contains and example of an 'application/ 457 resource-lists+xml' document, which carries full state. The 458 following is an 'application/resource-lists-diff+xml' partial update 459 document: 461 462 465 granted 469 471 The following is the resulting 'application/resource-lists+xml' 472 document after applying the partial update: 474 475 477 478 479 Bill Doe 480 granted 481 482 483 Joe Smith 484 pending 485 486 487 Nancy Gross 488 granted 489 490 491 493 7. IANA Considerations 495 There are five IANA considerations associated with this 496 specification. 498 7.1. SIP Event Package Registration 500 This specification registers a SIP event package per the procedures 501 in [RFC3265]. 503 Package name: consent-pending-additions 505 Type: package 507 Contact: Gonzalo Camarillo 509 Published Specification: RFC XXXX. (Note to the RFC Editor: Please 510 replace XXXX with the RFC Number of this specification.) 512 7.2. URN Sub-Namespace Registration: consent-status 514 This section registers a new XML namespace per the procedures in 515 [RFC3688]. 517 URI: The URI for this namespace is 518 urn:ietf:params:xml:ns:consent-status 520 Registrant Contact: IETF SIPPING working group, , 521 Gonzalo Camarillo 523 XML: 525 526 528 529 530 532 Pending Additions Extension Namespace 533 534 535

Namespace for Consent-related Status Information Extension

536

urn:ietf:params:xml:ns:consent-status

537

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

540 541 543 7.3. XML Schema Registration: consent-status 545 This section registers an XML schema per the procedures in [RFC3688]. 547 URI: urn:ietf:params:xml:schema:consent-status. 549 Registrant Contact: IETF SIPPING working group, , 550 Gonzalo Camarillo 552 The XML for this schema can be found in Section 4. 554 7.4. XML Schema Registration: resource-lists 556 This section registers an XML schema per the procedures in [RFC3688]. 557 This XML schema is an extension to the XML schema (whose ID is 558 resource-list) defined in [RFC4826]. The IANA is requested to add a 559 row in the XML schema registry with the following values: 561 ID: resource-list-diff 562 URI: urn:ietf:params:xml:schema:resource-lists-diff 563 Filename: resource-lists-diff 564 Reference [RFCxxxx] 566 (Note to the RFC Editor: Please replace XXXX with the RFC Number of 567 this specification.) 569 Registrant Contact: IETF SIPPING working group, , 570 Gonzalo Camarillo 572 The XML for this schema can be found in Section 6.3. 574 7.5. MIME type Registration: application/resource-lists-diff+xml 576 This section registers the 'application/resource-lists-diff+xml' MIME 577 type. 579 MIME media type name: application 580 MIME subtype name: resource-lists-diff+xml 581 Mandatory parameters: none 582 Optional Parameters: Same as charset parameter application/xml as 583 specified in [RFC3023]. 584 Encoding considerations: Same as encoding considerations of 585 application/xml as specified in [RFC3023]. 586 Security considerations: Security considerations: See Section 10 of 587 [RFC3023] and Section 7 of [RFC4826]. 589 Interoperability considerations: none 590 Published specification: RFC xxxx (Note to the RFC Editor: Please 591 replace XXXX with the RFC Number of this specification.) 592 Applications that use this media type: This document type has been 593 defined to support partial notifications in subscriptions to 594 resource lists. 596 Additional Information: 598 Magic Number: none 599 File extension: .rld 600 Macintosh file type code: "TEXT" 601 Personal and email address for further information: Gonzalo 602 Camarillo 603 Intended usage: COMMON 604 Author/Change controller: The IETF. 606 8. Security Considerations 608 The Framework for Consent-based Communications in the Session 609 Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses 610 security-related issues that are related to this specification. 612 Subscriptions to the Pending Additions even package can reveal 613 sensitive information. For this reason, it is RECOMMENDED that 614 relays use strong means for authentication and information 615 confidentiality. Additionally, attackers may attempt to modify the 616 contents of the notifications sent by a relay to its subscribers. 617 Consequently, it is RECOMMENDED that relays use a strong means for 618 information integrity protection. 620 It is RECOMMENDED that relays authenticate subscribers using the 621 normal SIP authentication mechanisms, such as Digest, as defined in 622 [RFC3261]. 624 The mechanism used for conveying information to subscribers SHOULD 625 ensure the integrity and confidentially of the information. In order 626 to achieve these, an end-to-end SIP encryption mechanism, such as 627 S/MIME, as described in [RFC3261], SHOULD be used. 629 If strong end-to-end security means (such as above) is not available, 630 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS 631 URIs, as described in [RFC3261], is used. 633 9. Acknowledgements 635 Jonathan Rosenberg provided useful ideas on this document. Ben 636 Campbell and Mary Barnes performed a thorough review of this 637 document. Jari Urpalainen helped improve the partial notifications 638 mechanism. 640 10. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 646 Types", RFC 3023, January 2001. 648 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 649 A., Peterson, J., Sparks, R., Handley, M., and E. 650 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 651 June 2002. 653 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 654 Event Notification", RFC 3265, June 2002. 656 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 657 January 2004. 659 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 660 for Representing Resource Lists", RFC 4826, May 2007. 662 [I-D.ietf-simple-xml-patch-ops] 663 Urpalainen, J., "An Extensible Markup Language (XML) Patch 664 Operations Framework Utilizing XML Path Language (XPath) 665 Selectors", draft-ietf-simple-xml-patch-ops-02 (work in 666 progress), March 2006. 668 [I-D.ietf-sip-consent-framework] 669 Rosenberg, J., "A Framework for Consent-Based 670 Communications in the Session Initiation Protocol (SIP)", 671 draft-ietf-sip-consent-framework-01 (work in progress), 672 November 2006. 674 Author's Address 676 Gonzalo Camarillo 677 Ericsson 678 Hirsalantie 11 679 Jorvas 02420 680 Finland 682 Email: Gonzalo.Camarillo@ericsson.com 684 Full Copyright Statement 686 Copyright (C) The IETF Trust (2008). 688 This document is subject to the rights, licenses and restrictions 689 contained in BCP 78, and except as set forth therein, the authors 690 retain all their rights. 692 This document and the information contained herein are provided on an 693 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 694 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 695 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 696 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 697 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 698 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 700 Intellectual Property 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed to 704 pertain to the implementation or use of the technology described in 705 this document or the extent to which any license under such rights 706 might or might not be available; nor does it represent that it has 707 made any independent effort to identify any such rights. Information 708 on the procedures with respect to rights in RFC documents can be 709 found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository at 716 http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. Please address the information to the IETF at 722 ietf-ipr@ietf.org. 724 Acknowledgment 726 Funding for the RFC Editor function is provided by the IETF 727 Administrative Support Activity (IASA).