idnits 2.17.1 draft-ietf-simple-partial-pidf-format-10.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. 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 (November 19, 2007) is 6002 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) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-simple-partial-notify-09 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG M. Lonnfors 3 Internet-Draft Nokia 4 Intended status: Standards Track E. Leppanen 5 Expires: May 22, 2008 Individual 6 H. Khartabil 7 Ericsson Australia 8 J. Urpalainen 9 Nokia 10 November 19, 2007 12 Presence Information Data format (PIDF) Extension for Partial Presence 13 draft-ietf-simple-partial-pidf-format-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 22, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The Presence Information Document Format (PIDF) specifies the 47 baseline XML based format for describing presence information. One 48 of the characteristic of the PIDF is that the document always needs 49 to carry all presence information available for the presentity. In 50 some environments where low bandwidth and high latency links can 51 exist it is often beneficial to limit the amount of transported 52 information over the network. This document introduces a new MIME 53 type which enables transporting of either only the changed parts or 54 the full PIDF based presence information. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Structure of PIDF diff documents . . . . . . . . . . . . . . . 3 61 3.1. 'version' attribute . . . . . . . . . . . . . . . . . . . 5 62 3.2. 'entity' attribute . . . . . . . . . . . . . . . . . . . . 5 63 4. Usage of 'application/pidf-diff+xml' . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. URN Sub-Namespace registration for 66 'urn:ietf:params:xml:ns:pidf-diff' . . . . . . . . . . . . 5 67 5.2. application/pidf-diff+xml MIME Type . . . . . . . . . . . 6 68 5.3. XML Schema Registration . . . . . . . . . . . . . . . . . 7 69 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. Interoperability Considerations . . . . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10. Internationalization Considerations . . . . . . . . . . . . . 13 74 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 13.1. Normative references . . . . . . . . . . . . . . . . . . . 14 78 13.2. Informative references . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 17 82 1. Introduction 84 The Presence Information Document Format (PIDF) [RFC3863] specifies 85 the baseline XML based format for describing presence information. 86 One of the characteristic of the PIDF is that the document always 87 needs to carry all presence information available for the presentity. 88 In some environments where low bandwidth and high latency links can 89 exist, it is often beneficial to limit the amount of transported 90 information over the network. 92 This document introduces a new MIME-Type 'application/pidf-diff+xml' 93 which enables transporting of either only the changed parts or the 94 full PIDF based presence information. The root element of the 95 document distinguishes whether the partial or full PIDF document 96 content was transported. 98 Note: With this new MIME-Type applications can easily negotiate 99 the support of partial updates of presence by using the Accept- 100 header. If PIDF had initially been designed for partial updates, 101 a new separate MIME-Type would have been unnecessary. 103 2. Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119] and 108 indicate requirement levels for compliant implementations. 110 This memo makes use of the vocabulary defined in RFC2778 [RFC2778]. 111 In addition, the following terms are defined: 113 Full presence document: A presence document that contains all the 114 presentity's presence information that is available to a 115 particular watcher. 117 Partial presence document: A presence document that represents a 118 fragment of the full presence document. A partial presence 119 documents can only be understood in the context of the full 120 presence document, i.e. a partial presence document modifies a 121 cached copy of the full presence document. 123 3. Structure of PIDF diff documents 125 The MIME type 'application/pidf-diff+xml' defines the new content 126 type for partial PIDF documents. 128 The XML Schema imports the PIDF [RFC3863] schema so that the full 129 PIDF document content with the addition of a 'version' attribute can 130 be transported. The root element of the document is then 131 and the 'version' attribute information can be included within it. 132 Otherwise the content of element is exactly the same as 133 what would have been if 'application/pidf+xml' content type had been 134 used. Although the XML Schema allows using also as the 135 document root element it is disallowed from applications utilizing 136 this document format. 138 When only the changes of the presence document are transported, the 139 model described in XML patch operations 140 [I-D.ietf-simple-xml-patch-ops] is used. The root element of the 141 document is then . The patch operation elements: , 142 and allow changing the partial content of the 143 cached local copy of the full presence document. The element 144 is used to add new content, the element updates and the 145 element removes existing content. 147 The optional 'version' attribute within the two possible document 148 root elements contains a sequence number which is incremented by one 149 between subsequent document updates, i.e. a more recent document 150 update has a higher 'version' value than the previous one. This 151 number can be used to ensure consistent updates as the recipient of 152 the document can use the 'version' number to properly order received 153 documents and to ensure that updates have not been lost. The usage 154 of this attribute thus allows "state delta" processing described in 155 [RFC3265]. Partial notification [I-D.ietf-simple-partial-notify] 156 uses similar model. This number increments independently regardless 157 of whether the or the content is transported. 158 In other words, a single version counter is maintained across and documents. 161 Implementations using this document format MUST follow guidelines 162 specified in the PIDF [RFC3863] and PIDF extension formats, for 163 example DataModel [RFC4479], RPID [RFC4480] and CIPID [RFC4482] and 164 MUST support the usage of the XML schema data type ID 165 [W3C.REC-xmlschema-2-20041028] of these listed RFCs. Specifically, 166 the XML document MUST be well formed and SHOULD be valid. This 167 specification makes use of XML namespaces for identifying presence 168 documents and document fragments. The namespace URI for elements 169 defined by this specification is a URN [RFC2141], using the namespace 170 identifier 'ietf' specified in RFC 2648 [RFC2648] and extended by 171 RFC3688 [RFC3688]. This URN is: 173 urn:ietf:params:xml:ns:pidf-diff 175 3.1. 'version' attribute 177 Every presence document compliant with this specification MAY contain 178 a 'version' attribute within the and element. 180 3.2. 'entity' attribute 182 Every presence document compliant with this specification MAY contain 183 an 'entity' attribute within the element. Its content, a 184 presentity URI MUST then be the same as the 'entity' attribute value 185 of the element described in [RFC3863]. The usage of this 186 presentity URI is described in more detail in section 3.1 of 187 [RFC4479]. 189 4. Usage of 'application/pidf-diff+xml' 191 The partial presence document SHOULD only contain those elements or 192 attributes that have changed. However, when there are a lot of 193 changes the full presence document content can then be transported 194 instead. 196 5. IANA Considerations 198 This memo calls for IANA to: 200 o register a new XML namespace URN per [RFC3688]. 202 o register a new MIME type 'application/pidf-diff+xml' according to 203 the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 204 [RFC3023]. 206 o register a new XML Schema according to the procedures of RFC 3688 207 [RFC3688]. 209 5.1. URN Sub-Namespace registration for 210 'urn:ietf:params:xml:ns:pidf-diff' 212 This specification registers a new XML namespace, as per the 213 guidelines in RFC 3688 [RFC3688]. 215 URI: 216 urn:ietf:params:xml:ns:pidf-diff 218 Description: 219 This is the XML namespace for XML elements defined by 220 [[[RFCXXXX]]] to describe the 'application/pidf-diff+xml' content 221 type for partial PIDF. 223 Registrant Contact: 224 IETF, SIMPLE working group, (simple@ietf.org) 225 Jari Urpalainen, (jari.urpalainen@nokia.com) 227 XML: 229 BEGIN 230 231 233 234 235 237 PIDF extension for partial PIDF 238 239 240

Namespace for PIDF extension for partial 241 notifications

242

urn:ietf:params:xml:ns:pidf-diff

243

See 244 RFCXXXX.

245 246 247 END 249 5.2. application/pidf-diff+xml MIME Type 251 MIME media type name: application 253 MIME subtype name: pidf-diff+xml 255 Mandatory parameters: none 257 Optional parameters: 258 Same as charset parameter of application/xml as specified in RFC 259 3023 [RFC3023]. Default value is UTF-8. 261 Encoding considerations: 262 Same as encoding considerations of application/xml as specified in 263 See RFC 3023 [RFC3023]. 265 Security considerations: 266 See Section 10 of RFC 3023 [RFC3023]. This content type is 267 designed to carry presence data, which may be considered private 268 information. Appropriate precautions should be adopted to limit 269 disclosure of this information. 271 Interoperability considerations: none 273 Published specification: [[[RFCXXXX]]] 275 Applications which use this media type: SIP-based presence systems 277 Additional information: 279 Magic Number: None 281 File Extension: .xml 283 Macintosh file type code: "TEXT" 285 Personal and email address for further information: Jari 286 Urpalainen, jari.urpalainen@nokia.com 288 Intended usage: LIMITED USE 290 Restrictions on usage: Presence [RFC3863] based systems. 292 Author: 293 This specification is a work item of the IETF SIMPLE working 294 group, with mailing list address . 296 Author/Change controller: the IETF. 298 5.3. XML Schema Registration 300 This section calls for IANA to register a new XML Schema, the sole 301 content of which can be found in Section 7. 303 URI: 304 urn:ietf:params:xml:schema:pidf-diff 306 Registrant Contact: 307 IETF, SIMPLE working group, 308 Jari Urpalainen, 310 6. Examples 312 An 'application/pidf-diff+xml' document that contains the full state 313 presence information: 315 316 325 326 327 open 328 329 330 true 331 true 332 false 333 334 tel:09012345678 335 337 338 339 open 340 341 im:pep@example.com 342 344 345 346 closed 347 348 http://example.com/~pep/ 349 http://example.com/~pep/icon.gif 350 http://example.com/~pep/card.vcd 351 sip:pep@example.com 352 354 Full state presence document 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 urn:esn:600b40c7 371 373 375 An example partial update document with the root element: 377 378 386 387 388 389 open 390 391 mailto:pep@example.com 392 This is a new tuple inserted 393 between the last tuple and person element 394 395 397 open 400 402 0.7 405 407 An updated local composition presence document after applying the 408 patches: 410 411 420 421 422 open 423 424 425 true 426 true 427 false 428 429 tel:09012345678 430 432 433 434 open 435 436 im:pep@example.com 437 439 440 441 open 442 443 http://example.com/~pep/ 444 http://example.com/~pep/icon.gif 445 http://example.com/~pep/card.vcd 446 sip:pep@example.com 447 449 450 451 open 452 453 mailto:pep@example.com 454 This is a new tuple inserted 455 between the last tuple and note element 457 459 Full state presence document 461 462 463 464 465 467 468 469 470 471 472 473 474 475 urn:esn:600b40c7 476 478 480 7. XML Schema 482 The XML schema for the 'application/pidf-diff+xml' data format. The 483 included schema "urn:ietf:params:xml:schema:xml-patch-ops" is defined 484 in [I-D.ietf-simple-xml-patch-ops] and the PIDF Schema "pidf.xsd" is 485 imported from [RFC3863]. 487 488 495 496 499 500 503 504 505 506 507 508 509 510 511 512 513 514 515 516 518 519 520 521 522 523 524 525 526 527 529 531 8. Interoperability Considerations 533 Systems compliant with CPP [RFC3859] will not be by default able to 534 use this specification. However, this will not cause any 535 interoperability problems because all endpoints and gateways must 536 support the default MIME type (application/pidf+xml) regardless if 537 they support this specification. Thus if a gateway or another end 538 point does not understand this specification it will not be used. In 539 SIMPLE based systems use of this MIME type is negotiated using SIP 540 content type negotiation mechanism as specified in partial 541 notification [I-D.ietf-simple-partial-notify]. 543 Other CPP compliant (other than SIP based) systems can also support 544 this specification if they have a mechanism to indicate support for 545 it. If they do it is possible to build a gateway which will preserve 546 end-to-end integrity with usage of partial PIDF. 548 9. Security Considerations 550 All security considerations identified for PIDF [RFC3863] apply 551 unchanged for this document as presence information may contain 552 highly sensitive information. Furthermore, the protocol SHOULD 553 provide authorization policies what presence information can be given 554 to which watchers, and when, see [I-D.ietf-simple-presence-rules]. 556 10. Internationalization Considerations 558 The PIDF [RFC3863] format is represented in XML which performs all 559 character processing in terms of the Universal Character Set (UCS). 560 Conformant XML processors MUST support both UTF-8 and UTF-16 561 encodings of the UCS. UTF-8 is the RECOMMENDED encoding of this 562 partial presence format. 564 If the character set of the initial document has been 565 accepted by a receiving application, it MUST continue to accept the 566 same character set with the subsequent documents. 567 However, it MUST NOT need to accept a possible character set change. 569 11. Error Handling 571 Error conditions MAY be indicated by errors defined in 572 [I-D.ietf-simple-xml-patch-ops]. This document doesn't define any 573 additional error elements. If the 'version' or 'entity' attributes 574 have incorrect content if MAY be indicated by the error element. 577 12. Acknowledgments 579 The authors would like to thank Jose Costa-Requena, Jyrki Aarnos, 580 Jonathan Rosenberg, Dean Willis, Miguel Garcia, Krisztian Kiss, Ben 581 Cambell, Robert Sparks, Anders Kristenssen, Aki Niemi, Jon Peterson, 582 Gonzalo Camarillo, Lars Eggert, Lakshminath Dondeti and Chris Newman 583 for their valuable comments and contributions. 585 13. References 587 13.1. Normative references 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 593 W., and J. Peterson, "Presence Information Data Format 594 (PIDF)", RFC 3863, August 2004. 596 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 598 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 599 August 1999. 601 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 602 January 2004. 604 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 605 Types", RFC 3023, January 2001. 607 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 608 Registration Procedures", BCP 13, RFC 4288, December 2005. 610 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 611 July 2006. 613 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 614 Rosenberg, "RPID: Rich Presence Extensions to the Presence 615 Information Data Format (PIDF)", RFC 4480, July 2006. 617 [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the 618 Presence Information Data Format", RFC 4482, July 2006. 620 [I-D.ietf-simple-xml-patch-ops] 621 Urpalainen, J., "An Extensible Markup Language (XML) Patch 622 Operations Framework Utilizing XML Path Language (XPath) 623 Selectors", draft-ietf-simple-xml-patch-ops-04 (work in 624 progress), November 2007. 626 [W3C.REC-xmlschema-2-20041028] 627 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 628 Second Edition", World Wide Web Consortium 629 Recommendation REC-xmlschema-2-20041028, October 2004, 630 . 632 13.2. Informative references 634 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 635 Presence and Instant Messaging", RFC 2778, February 2000. 637 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 638 Event Notification", RFC 3265, June 2002. 640 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 641 RFC 3859, August 2004. 643 [I-D.ietf-simple-partial-notify] 644 Lonnfors, M., "Session Initiation Protocol (SIP) extension 645 for Partial Notification of Presence Information", 646 draft-ietf-simple-partial-notify-09 (work in progress), 647 February 2007. 649 [I-D.ietf-simple-presence-rules] 650 Rosenberg, J., "Presence Authorization Rules", 651 draft-ietf-simple-presence-rules-10 (work in progress), 652 July 2007. 654 Authors' Addresses 656 Mikko Lonnfors 657 Nokia 658 Itamerenkatu 11-13 00180 659 Helsinki 660 Finland 662 Phone: +358 71 8008000 663 Email: mikko.lonnfors@nokia.com 664 Eva Leppanen 665 Individual 666 Lempaala 667 Finland 669 Email: eva.leppanen@saunalahti.fi 671 Hisham Khartabil 672 Ericsson Australia 673 P.O. Box 256c 674 Melbourne, VIC 3001 675 Australia 677 Email: hisham.khartabil@gmail.com 679 Jari Urpalainen 680 Nokia 681 Itamerenkatu 11-13 00180 682 Helsinki 683 Finland 685 Phone: +358 7180 37686 686 Email: jari.urpalainen@nokia.com 688 Full Copyright Statement 690 Copyright (C) The IETF Trust (2007). 692 This document is subject to the rights, licenses and restrictions 693 contained in BCP 78, and except as set forth therein, the authors 694 retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 700 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 701 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Intellectual Property 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Acknowledgment 730 Funding for the RFC Editor function is provided by the IETF 731 Administrative Support Activity (IASA).