idnits 2.17.1 draft-ietf-simple-partial-publish-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 677. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 19, 2008) is 5909 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) == Outdated reference: A later version (-10) exists of draft-ietf-simple-prescaps-ext-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG A. Niemi 3 Internet-Draft M. Lonnfors 4 Intended status: Standards Track Nokia 5 Expires: August 22, 2008 E. Leppanen 6 Individual 7 February 19, 2008 9 Publication of Partial Presence Information 10 draft-ietf-simple-partial-publish-07 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Session Initiation Protocol (SIP) Extension for Event State 44 Publication describes a mechanism with which a presence user agent is 45 able to publish presence information to a presence agent. Using the 46 Presence Information Data Format (PIDF), each presence publication 47 contains full state, regardless of how much of that information has 48 actually changed since the previous update. As a consequence, 49 updating a sizeable presence document with small changes bears a 50 considerable overhead and is therefore inefficient. Especially with 51 low bandwidth and high latency links, this can constitue a 52 considerable burden to the system. This memo defines a solution that 53 aids in reducing the impact of those constraints and increases 54 transport efficiency by introducing a mechanism that allows for 55 publication of partial presence information. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions and Document Conventions . . . . . . . . . . . . . 3 61 3. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Presence Publication . . . . . . . . . . . . . . . . . . . 4 63 3.2. Partial Presence Publication . . . . . . . . . . . . . . . 4 64 4. Client and Server Operation . . . . . . . . . . . . . . . . . 5 65 4.1. Content-type for Partial Publications . . . . . . . . . . 5 66 4.2. Generation of Partial Publications . . . . . . . . . . . . 6 67 4.3. Processing of Partial Publications . . . . . . . . . . . . 7 68 4.3.1. Processing . . . . . . . . . . . . . . . . 8 69 4.3.2. Processing . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . . . 16 79 1. Introduction 81 Session Initiation Protocol (SIP) Extension for Event State 82 Publication [RFC3903] allows Presence User Agents ('PUA') to publish 83 presence information of a user ('presentity'). The Presence Agent 84 ('PA') collects publications from one or several presence user 85 agents, and generates the composite event state of the presentity. 87 The baseline format for presence information is defined in the 88 Presence Information Data Format (PIDF) [RFC3863] and is by default 89 used in presence publication. The PIDF uses Extensible Markup 90 Language (XML) [W3C.REC-xml], and groups data into elements called 91 tuples. In addition, [RFC4479], [RFC4480], [RFC4481], [RFC4482] and 92 [I-D.ietf-simple-prescaps-ext] define extension elements that provide 93 various additional features to PIDF. 95 Presence publication by default uses the PIDF document format, and 96 each publication contains full state regardless of how much of the 97 presence information has actually changed since the previous update. 98 As a consequence, updating a sizeable presence document especially 99 with small changes bears a considerable overhead and is therefore 100 inefficient. Publication of information over low bandwidth and high 101 latency links further exacerbates this inefficiency. 103 This memo specifies a mechanism with which the PUA is after an 104 initial full state publication able to publish only those parts of 105 the presence document that have changed since the previous update. 106 This is accomplished using the partial PIDF 107 [I-D.ietf-simple-partial-pidf-format] document format to communicate 108 a set of presence document changes to the PA, who then applies the 109 changes in sequence to its version of the presence document. 111 This memo is structured in the following way: Section 3 gives an 112 overview of the partial publication mechanism; Section 4 includes the 113 detailed specification; Section 5 includes discussion of security 114 considerations; and Section 6 includes examples of partial 115 publication. 117 2. Definitions and Document Conventions 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14 122 [RFC2119], and indicate requirement levels for compliant 123 implementations. 125 This document makes use of the vocabulary defined in the Model for 126 Presence and Instant Messaging [RFC2778], the Event State Publication 127 Extension to SIP [RFC3903], and the PIDF Extension for Partial 128 Presence [I-D.ietf-simple-partial-pidf-format]. 130 3. Overall Operation 132 This section introduces the baseline functionality for presence 133 publication, and gives an overview of the partial publication 134 mechanism. This section is informational in nature. It does not 135 contain any normative statements. 137 3.1. Presence Publication 139 Event state publication is specified in [RFC3903]. 141 The publication of presence information consists of a presence user 142 agent sending a SIP PUBLISH request [RFC3903] targeted to the 143 address-of-record of the presentity, and serviced by a presence agent 144 or compositor. The body of the PUBLISH request carries full event 145 state in the form of a presence document. 147 The compositor processes the PUBLISH request and stores the presence 148 information. It also assigns an entity-tag that is used to identify 149 the publication. This entity-tag is returned to the PUA in the 150 response to the PUBLISH request. 152 The PUA uses the entity-tag in the following PUBLISH request for 153 identifying the publication that the request is meant to refresh, 154 modify or remove. Presence information is stored in an initial 155 publication, and maintained using the refreshing and modifying 156 publications. Presence information disappears either by expilicitly 157 removing it or when it meets its expiration time. 159 3.2. Partial Presence Publication 161 The partial publication mechanism enables the PUA to update only 162 parts of its presence information, namely those sections of the 163 presence document that have changed. The initial publication always 164 carries full state. However, successive modifying publications to 165 this initial presence state can communicate state deltas, i.e., one 166 or more changes to the presence information since the previous 167 update. Versioning of these partial publications is necessary to 168 guarantee that the changes are applied in the correct order. The 169 PUBLISH method [RFC3903] already accomplishes this using entity-tags 170 and conditional requests, which guarantee correct ordering of 171 publication updates. 173 Note that the partial PIDF format 174 [I-D.ietf-simple-partial-pidf-format] contains the 'version' 175 attribute that could be used for versioning as well. However, we 176 chose not to introduce an additional versioning mechanism to 177 partial publish, since that would only add ambiguity and a 178 potential undefined error case if the two versioning mechanisms 179 were to somehow contradict. 181 To initialize its publication of presence information, the PUA first 182 publishes a full state initial publication. The consequent modifying 183 publications can carry either state deltas or full state. Both 184 initial and modifying partial presence publications are accomplished 185 using the 'application/pidf-diff+xml' content type 186 [I-D.ietf-simple-partial-pidf-format], with the former using the 187 root element, and the latter using the or 188 root elements, respectively. 190 While the encapsulates a regular PIDF document, the 191 can contain one or more operations for adding new 192 elements or attributes ( elements), replacing elements or 193 attributes whose content has changed ( elements), or 194 indications of removal of certain elements or attributes ( 195 elements). The PUA is free to decide the granularity by which 196 changes in presence information are communicated to the composer. It 197 may very well happen that there are enough changes to be communicated 198 that it is more efficient to send a full state publication instead of 199 a set of state deltas. 201 When the presence compositor receives a partial publication it 202 applies the included patch operations in sequence. The resulting 203 changed (or patched) presence document is then submitted to the 204 composition logic in the same manner as with a full state presence 205 publication. Similarly, any changes to the publication expiration 206 apply to the full, patched presence publication. In other words, 207 there is no possibility to roll back to an earlier version, except by 208 submitting a full state publication. 210 4. Client and Server Operation 212 Unless otherwise specified in this document, the presence user agent 213 and presence agent behavior are as defined in [RFC3903]. 215 4.1. Content-type for Partial Publications 217 The entities supporting the partial publication extension described 218 in this document MUST support the 'application/pidf-diff+xml' content 219 type defined in the partial PIDF format 221 [I-D.ietf-simple-partial-pidf-format], in addition to the baseline 222 'application/pidf+xml' content type defined in [RFC3863]. 224 Listing the partial PIDF content type in the Accept header field of a 225 SIP response is an explicit indication of support for the partial 226 publication mechanism. The PUA can learn server support either as a 227 result of an explicit query, i.e., in a response to an OPTIONS 228 request; or by trial-and-error, i.e., after an 415 error response is 229 returned to an attempted partial publication. 231 4.2. Generation of Partial Publications 233 Whenever a PUA decides to begin publication of partial presence 234 information, it first needs to make an initial publication. This 235 intial publication always carries full state. After the initial 236 publication, presence information can be updated using modifying 237 publications; the modifications can carry state deltas as well as 238 full state. Finally, the publication can be terminated by explicit 239 removal, or by expiration. 241 Both the initial and modifying publications make use of the partial 242 presence document format [I-D.ietf-simple-partial-pidf-format], and 243 all follow the normal rules for creating publications, as defined in 244 RFC 3903 [RFC3903], Section 4. 246 If the initial PUBLISH request returns a 415 (Unsupported Media 247 Type), it means that the compositor did not understand the partial 248 publication format. In this case, the PUA MUST follow normal 249 precedures for handling a 400-class response, as specified in Section 250 8.1.3.5 of [RFC3261]. Specifically, the PUA SHOULD retry the 251 publication using the default PIDF content type, namely 'application/ 252 pidf+xml'. In addition, to find out a priori whether a specific 253 presence compositor supports partial presence publication, the PUA 254 MAY use the OPTIONS method, as described in [RFC3261]. 256 To construct a full-state publication, the PUA uses the following 257 process: 259 o The Content-Type header field in the PUBLISH request MUST be set 260 to the value 'application/pidf-diff+xml'. 262 o The document in the body of the request is populated with a root element that includes the 'entity' attribute set to 264 identify the presentity. 266 o Under the root element exists all of the children of a 267 PIDF [RFC3863] element. This document contains the 268 full state of which the PUA is aware, and MAY include elements 269 from any extension namespace. 271 To construct a partial publication the following process is followed: 273 o The Content-Type header field in the PUBLISH request MUST be set 274 to the value 'application/pidf-diff+xml' 276 o The document in the body of the request is populated with a root element that includes the 'entity' attribute 278 identifying the presentity. 280 o Under the root element exists a set of patch 281 operations that communicate the changes to the presentity's 282 presence information. These operations MUST be constructed in 283 sequence, and as defined in the partial PIDF format 284 [I-D.ietf-simple-partial-pidf-format]. 286 The PUA is free to decide the granularity by which changes in the 287 presentity's presence information are communicated to the presence 288 compositor. In order to reduce unnecessary network traffic, the PUA 289 SHOULD batch several patch operations in a single PUBLISH request. 291 A reasonable granularity might be to batch state changes resulting 292 from related UI events together in a single PUBLISH request. For 293 example, when the user sets their status to "Away", several things 294 including freetext notes, service availability, and activities 295 might change as a result. 297 If the size of the delta state becomes more than the size of the full 298 state, the PUA SHOULD instead send a modifying publication carrying 299 full state, unless this size comparison is not possible. 301 To an implementation that generates state deltas directly out of 302 its internal events, it may not be trivial to determine the size 303 of the corresponding full state. 305 4.3. Processing of Partial Publications 307 For each resource, the compositor maintains a record for each of the 308 publications. These are indexed using the entity-tag of the 309 publications. 311 Processing of publications generally follows the guidelines set in 312 [RFC3903]. In addition, processing PUBLISH requests that contain 313 'application/pidf-diff+xml' require some extra processing that is 314 dependant on whether the request contains full or partial state. 316 4.3.1. Processing 318 If the value of the Content-Type header field is 'application/ 319 pidf-diff+xml', and the document therein contains a root 320 element, the publication contains full presence information, and the 321 next step applies: 323 o The compositor MUST take the received presence document under the 324 as the local presence document, replacing any previous 325 publications. 327 If any errors are encountered before the entire publication is 328 completely processed, the compositor MUST reject the request with a 329 500 (Server Internal Error) response, and revert back to its 330 original, locally stored presence information. 332 4.3.2. Processing 334 If the value of the Content-Type header field is 'application/ 335 pidf-diff+xml', and the document in the body contains a 336 root element, the publication contains partial presence information 337 (state delta), and the next steps apply: 339 o If the publication containing the root element is a 340 modifying publication (i.e., contains an If-Match header field 341 with a valid entity-tag), the compositor MUST apply the included 342 patch operations in sequence against its locally stored presence 343 document. 345 o Else, the publication is an initial publication, for which only 346 is allowed. Therefore the publication MUST be 347 rejected with an appropriate error response, such as a 400 348 (Invalid Partial Publication). 350 If a publication carrying partial presence information expires 351 without the PUA refreshing it, the compositor MUST clear the entire, 352 full state publication. 354 This means that the compositor does not keep a record of the 355 applied patches, and consequently (unlike some versioning 356 systems), the compositor does not roll back to an earlier version 357 if a particular partial publication were to expire. 359 If the compositor encounters errors while processing the 360 'application/pidf-diff+xml' document, it MUST reject the request with 361 a 400 (Bad Request) response. In addition, the compositor MAY 362 include diagnostics information in the body of the response, using an 363 appropriate error condition element defined in Section 5.1. of 365 [I-D.ietf-simple-xml-patch-ops]. 367 If any other errors are encountered before the entire partial 368 publication is completely processed, including all of the patch 369 operations in the 'application/pidf-diff+xml' body, the compositor 370 MUST reject the request with a 500 (Server Internal Error) response, 371 and revert back to its original, locally stored presence information. 373 5. Security Considerations 375 This specification relies on protocol behavior defined in [RFC3903]. 376 General event state publication related security considerations are 377 extensively discussed in that specification and all the identified 378 security considerations apply to this document in entirety. In 379 addition, this specification adds no new security considerations. 381 6. Examples 383 The following message flow (Figure 1) shows an example of a presence 384 system that applies the partial publication mechanism. 386 First, the PUA sends an initial publication that contains full state. 387 In return, it receives a 200 OK response containing an entity-tag. 388 This entity-tag serves as a reference with which the initial full 389 state can be updated using partial publications containing state 390 deltas. 392 Then at some point the resource state changes, and the PUA assembles 393 these changes into a set of patch operations. It then sends a 394 modifying publication containing the patch operations, using the 395 entity-tag as a reference to the publication against which the 396 patches are to be applied. The compositor applies the received patch 397 operations to its local presence document in sequence, and returns a 398 200 OK which includes a new entity-tag. 400 Presence Agent / 401 PUA Compositor 402 | (M1) PUBLISH | 403 |---------------------------->| 404 | (M2) 200 OK | 405 |<----------------------------| 406 | | 407 | | 408 | | 409 | (M3) PUBLISH | 410 |---------------------------->| 411 | (M4) 200 OK | 412 |<----------------------------| 413 | | 414 _|_ _|_ 416 Figure 1: Partial Publication Message Flow 418 Message details: 420 (M1): PUA -> Compositor 422 PUBLISH sip:resource@example.com SIP/2.0 423 ... 424 Event: presence 425 Expires: 3600 426 Content-Type: application/pidf-diff+xml 427 Content-Length: 1457 429 430 436 437 438 open 439 assistant 440 441 442 true 443 false 444 true 445 446 tel:09012345678 447 448 449 450 open 451 452 im:pep@example.com 453 455 456 457 closed 458 meeting 459 460 http://example.com/~pep/ 461 http://example.com/~pep/icon.gif 462 http://example.com/~pep/card.vcd 463 sip:pep@example.com 464 466 Full state presence document 468 469 470 471 472 473 474 475 477 478 479 480 481 482 483 484 485 486 487 489 491 (M2): Compositor -> PUA 493 SIP/2.0 200 OK 494 ... 495 SIP-ETag: 61763862389729 496 Expires: 3600 497 Content-Length: 0 499 (M3): PUA -> Compositor 501 PUBLISH sip:resource@example.com SIP/2.0 502 ... 503 Event: presence 504 SIP-If-Match: 61763862389729 505 Expires: 3600 506 Content-Type: application/pidf-diff+xml 507 Content-Length: 778 509 510 515 516 517 open 518 519 mailto:pep@example.com 520 This is a new tuple inserted 521 between the last tuple and note element 522 524 525 open 528 530 0.7 533 535 (M4): Compositor -> PUA 537 SIP/2.0 200 OK 538 ... 539 SIP-ETag: 18764920981476 540 Expires: 3600 541 Content-Length: 0 543 7. Acknowledgements 545 The authors would like to thank Atle Monrad, Christian Schmidt, 546 George Foti, Fridy Sharon-Fridman and Avshalom Houri for review 547 comments. 549 8. References 551 8.1. Normative references 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 557 for Event State Publication", RFC 3903, October 2004. 559 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 560 W., and J. Peterson, "Presence Information Data Format 561 (PIDF)", RFC 3863, August 2004. 563 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 564 A., Peterson, J., Sparks, R., Handley, M., and E. 565 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 566 June 2002. 568 [I-D.ietf-simple-partial-pidf-format] 569 Lonnfors, M., Leppanen, E., Khartabil, H., and J. 570 Urpalainen, "Presence Information Data format (PIDF) 571 Extension for Partial Presence", 572 draft-ietf-simple-partial-pidf-format-10 (work in 573 progress), November 2007. 575 [I-D.ietf-simple-xml-patch-ops] 576 Urpalainen, J., "An Extensible Markup Language (XML) Patch 577 Operations Framework Utilizing XML Path Language (XPath) 578 Selectors", draft-ietf-simple-xml-patch-ops-04 (work in 579 progress), November 2007. 581 8.2. Informative references 583 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 584 Presence and Instant Messaging", RFC 2778, February 2000. 586 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 587 July 2006. 589 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 590 Rosenberg, "RPID: Rich Presence Extensions to the Presence 591 Information Data Format (PIDF)", RFC 4480, July 2006. 593 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 594 Presence Information Data Format (PIDF) to Indicate Status 595 Information for Past and Future Time Intervals", RFC 4481, 596 July 2006. 598 [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the 599 Presence Information Data Format", RFC 4482, July 2006. 601 [I-D.ietf-simple-prescaps-ext] 602 Lonnfors, M. and K. Kiss, "Session Initiation Protocol 603 (SIP) User Agent Capability Extension to Presence 604 Information Data Format (PIDF)", 605 draft-ietf-simple-prescaps-ext-08 (work in progress), 606 September 2007. 608 [W3C.REC-xml] 609 Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 610 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 611 xml, October 2000, . 613 Authors' Addresses 615 Aki Niemi 616 Nokia 617 P.O. Box 407 618 NOKIA GROUP, FIN 00045 619 Finland 621 Phone: +358 71 8008000 622 Email: aki.niemi@nokia.com 623 Mikko Lonnfors 624 Nokia 625 Itamerenkatu 11-13 626 Helsinki 627 Finland 629 Phone: +358 71 8008000 630 Email: mikko.lonnfors@nokia.com 632 Eva Leppanen 633 Individual 634 Lempaala 635 Finland 637 Email: eva.leppanen@saunalahti.fi 639 Full Copyright Statement 641 Copyright (C) The IETF Trust (2008). 643 This document is subject to the rights, licenses and restrictions 644 contained in BCP 78, and except as set forth therein, the authors 645 retain all their rights. 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 650 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 651 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 652 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 Intellectual Property 657 The IETF takes no position regarding the validity or scope of any 658 Intellectual Property Rights or other rights that might be claimed to 659 pertain to the implementation or use of the technology described in 660 this document or the extent to which any license under such rights 661 might or might not be available; nor does it represent that it has 662 made any independent effort to identify any such rights. Information 663 on the procedures with respect to rights in RFC documents can be 664 found in BCP 78 and BCP 79. 666 Copies of IPR disclosures made to the IETF Secretariat and any 667 assurances of licenses to be made available, or the result of an 668 attempt made to obtain a general license or permission for the use of 669 such proprietary rights by implementers or users of this 670 specification can be obtained from the IETF on-line IPR repository at 671 http://www.ietf.org/ipr. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights that may cover technology that may be required to implement 676 this standard. Please address the information to the IETF at 677 ietf-ipr@ietf.org. 679 Acknowledgment 681 Funding for the RFC Editor function is provided by the IETF 682 Administrative Support Activity (IASA).