idnits 2.17.1 draft-ietf-simple-xcap-pidf-manipulation-usage-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 22, 2004) is 7098 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 (-12) exists of draft-ietf-simple-xcap-03 ** Obsolete normative reference: RFC 2617 (ref. '5') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (ref. '6') (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-simple-rpid-03 == Outdated reference: A later version (-07) exists of draft-ietf-simple-cipid-03 == Outdated reference: A later version (-07) exists of draft-ietf-simple-presence-data-model-00 == Outdated reference: A later version (-10) exists of draft-ietf-simple-prescaps-ext-01 == Outdated reference: A later version (-05) exists of draft-ietf-simple-future-02 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG M. Isomaki 3 Internet-Draft E. Leppanen 4 Expires: April 22, 2005 Nokia 5 October 22, 2004 7 An Extensible Markup Language (XML) Configuration Access Protocol 8 (XCAP) Usage for Manipulating Presence Document Contents 9 draft-ietf-simple-xcap-pidf-manipulation-usage-02 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 22, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document describes a usage of the Extensible Markup Language 45 (XML) Configuration Access Protocol (XCAP) for manipulating the 46 contents of Presence Information Data Format (PIDF) based presence 47 document. It is intended to be used in Session Initiation Protocol 48 (SIP) based presence systems, where the Event State Compositor can 49 use the XCAP-manipulated presence document as one of the inputs on 50 which it builds the overall presence state for the presentity. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Relationship with Presence State Published Using SIP 57 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Application Usage ID . . . . . . . . . . . . . . . . . . . . 6 59 5. Structure of Manipulated Presence Information . . . . . . . 6 60 6. Additional Constraints . . . . . . . . . . . . . . . . . . . 6 61 7. Resource Interdependencies . . . . . . . . . . . . . . . . . 6 62 8. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 6 63 9. Authorization Policies . . . . . . . . . . . . . . . . . . . 6 64 10. Example Document . . . . . . . . . . . . . . . . . . . . . . 6 65 11. Security Considerations . . . . . . . . . . . . . . . . . . 8 66 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 67 12.1 XCAP Application Usage ID . . . . . . . . . . . . . . . 8 68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 14.1 Normative References . . . . . . . . . . . . . . . . . . . 9 71 14.2 Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . 11 75 1. Introduction 77 The Session Initiation Protocol (SIP) for Instant Messaging and 78 Presence (SIMPLE) specifications allow a user, called a watcher, to 79 subscribe to another user, called a presentity, in order to learn 80 their presence information [7]. The presence data model has been 81 specified in [10]. The data model makes a clean separation between 82 person, service and device related information. 84 A SIP based mechanism, SIP PUBLISH method, has been defined for 85 publishing presence state [4]. Using SIP PUBLISH a Presence User 86 Agent (PUA) can publish its view of the presence state, independently 87 of and without the need to learn about the states set by other PUAs. 88 However, SIP PUBLISH has a limited scope and does not address all the 89 requirements for setting presence state. The main issue is that SIP 90 PUBLISH creates a soft state which expires after the negotiated 91 lifetime unless it is refreshed. This makes it unsuitable for cases 92 where the state should prevail without active devices capable of 93 refreshing the state. 95 There are three main use cases where setting of permanent presence 96 state that is independent of activeness of any particular device is 97 useful. The first case concerns setting person related state. The 98 presentity would often like to set its presence state even for 99 periods when it has no active devices capable of publishing 100 available. Good examples are traveling, vacations and so on. The 101 second case is about setting state for services that are open for 102 communication even if the presentity does not have a device running 103 that service on-line. Examples of this kind of services include 104 e-mail, MMS and SMS. In these services the presentity is provisioned 105 with a server that makes the service persistently available, at least 106 in certain form, and it would be good to be able to advertise this to 107 the watchers. Since it is not realistic to assume that all e-mail, 108 MMS or SMS servers can publish presence state on their own (and even 109 if this were possible, such state would almost never change), this 110 has to be done by some other device - and since the availability of 111 the service is not dependent on that device, it would be unpractical 112 to require that device to be constantly active just to publish such 113 availability. The third case concerns setting the default state of 114 person, any service or any device in the absence of any device 115 capable of actively publishing such state. For instance the 116 presentity might want to advertise that his or her voice service is 117 right now closed, just to let the watchers to know that such service 118 might be open at some point. Again, this type of default state is 119 independent of any particular device, and can be considered to be 120 rather persistent. 122 Even though SIP PUBLISH remains to be the main way of publishing 123 presence state in SIMPLE based presence systems and is espcially well 124 suited for publishing dynamic state (which presence mainly is), it 125 needs to be complemented by the mechanism described in this document 126 to address the use cases presented above. 128 XML Configuration Access Protocol (XCAP) [2] allows a client to read, 129 write and modify application configuration data, stored in XML format 130 on a server. The data has no expiration time, so it must be 131 explicitly inserted and deleted. The protocol allows multiple 132 clients to manipulate the data, provided that they are authorized to 133 do so. XCAP is already used in SIMPLE based presence systems for 134 manipulation of presence lists and presence authorization policies. 135 This makes XCAP an ideal choice for doing device independent presence 136 document manipulation. 138 This document defines an XML Configuration Access Protocol (XCAP) 139 application usage for manipulating the contents of presence document. 140 Presence Information Document Format (PIDF) [3] is used as the 141 presence document format, since event state compositor already has to 142 support it, as it is used in SIP PUBLISH. 144 Section 3 describes in more detail how the presence document 145 manipulated with XCAP is related to soft state publishing done with 146 SIP PUBLISH. 148 XCAP requires application usages to standardize several pieces of 149 information, including a unique application usage ID (AUID), and an 150 XML schema for the manipulated data. These are specified starting 151 from Section 4. 153 2. Conventions 155 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 156 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 157 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 158 and indicate requirement levels for compliant implementations. 160 Comprehensive terminology of presence and event state publishing is 161 provided in Session Initiation Protocol (SIP) Extension for Event 162 State Publication [4]. 164 3. Relationship with Presence State Published Using SIP PUBLISH 166 The framework for publishing presence state is described in Figure 1. 167 A central part of the framework is the event state compositor element 168 whose function is to compose presence information received from 169 several sources into a single coherent presence document. 171 The presence state manipulated with XCAP can be seen as one of the 172 information sources for the compositor to be combined with the soft 173 state information published using SIP PUBLISH. This is illustrated 174 in Figure 1. It is expected that in the normal case there can be 175 several PUAs publishing their separate views with SIP PUBLISH, but 176 only a single XCAP manipulated presence document. As shown in the 177 figure, there can be multiple XCAP clients (for instance in different 178 physical devices) manipulating the same document on the XCAP server, 179 but this still creates only one input to the event state compositor. 181 As individual inputs the presence states set by XCAP and SIP PUBLISH 182 are completely separated and it is not possible to directly 183 manipulate the state set by one mechanism with the other. How the 184 compositor treats XCAP based inputs with respect to SIP PUBLISH based 185 inputs is a matter of compositor policy, which is beyond the scope of 186 this specification. Since the SIP PUBLISH specification already 187 mandates the compositor to be able to construct the overall presence 188 state from multiple inputs which may contain non-orthogonal (or in 189 some ways even conflicting) information, this XCAP usage does not 190 impose any new requirements on the compositor functionality. 192 +---------------+ +------------+ 193 | Event State | | Presence |<-- SIP SUBSCRIBE 194 | Compositor +---------+ Agent |--> SIP NOTIFY 195 | | | (PA) | 196 +-------+-------+ +------------+ 197 ^ ^ ^ 198 | | | 199 | | | +---------------+ 200 +--------+ | +-------| XCAP server | 201 | | +-------+-------+ 202 | | ^ ^ 203 | SIP Publish | | XCAP | 204 | | | | 205 +--+--+ +--+--+ +-------+ +-------+ 206 | PUA | | PUA | | XCAP | | XCAP | 207 | | | | | client| | client| 208 +-----+ +-----+ +-------+ +-------+ 210 Figure 1: Framework for Presence Publishing and Event State 211 Composition 213 The protocol interface between XCAP server and the event state 214 compositor is not specified here. 216 4. Application Usage ID 218 XCAP requires application usages to define a unique application usage 219 ID (AUID) in either the IETF tree or a vendor tree. This 220 specification defines the 'pidf-manipulation' AUID within the IETF 221 tree, via the IANA registration in the Section 12. 223 5. Structure of Manipulated Presence Information 225 The XML Schema of the presence information (PIDF) is defined in CPIM 226 Presence Information Data Format [3]. The PIDF also defines a 227 mechanism for extending presence information. See [8], [9], [11] and 228 [12] for currently defined PIDF extensions and their XML Schemas. 230 The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf'. 232 6. Additional Constraints 234 There are no constraints on the document beyond those described in 235 the XML schemas (PIDF and its extensions) and in the description of 236 CPIM PIDF [3]. 238 7. Resource Interdependencies 240 There are no resource interdependencies beyond the possible 241 interdependencies defined in CPIM PIDF [3] and XCAP [2] that need to 242 be defined for this application usage. 244 8. Naming Conventions 246 There are no naming conventions beyond the possible conventions 247 defined in CPIM PIDF [3] that need to be defined for this application 248 usage. 250 9. Authorization Policies 252 This application usage does not modify the default XCAP authorization 253 policy, which allows only a user (owner) to read, write or modify 254 their own documents. A server can allow privileged users to modify 255 documents that they do not own, but the establishment and indication 256 of such policies is outside the scope of this document. 258 10. Example Document 260 The section provides an example of presence document provided by an 261 XCAP Client to an XCAP Server. The presence document illustrates the 262 situation where a (human) presentity has left for vacation, and 263 before that has set his presence information such that he is only 264 available via e-mail. In the absence of any published soft state 265 information, this would be the sole input to the compositor forming 266 the presence document. The example document contain PIDF extensions 267 specified in RPID: Rich Presence Extensions to the Presence 268 Information Data Format (PIDF) [8] and CIPID: Contact Information in 269 Presence Information Data Format [9]. 271 First, the presence document is created. 273 PUT http://xcap.example.com/services/pidf-manipulation/users/someone/pidf.xml 274 HTTP/1.1 275 Content type:appliation/pidf+xml 277 278 285 286 287 closed 288 289 290 auth-1 291 sip:user@example.com 292 I'm available only by e-mail. 293 2004-02-06T16:49:29Z 294 296 297 298 open 299 300 auth-1 301 mailto:someone@example.com 302 I'm reading mail a couple of times a week 303 305 306 auth-A 307 http://www.example.com/~someone 308 309 310 Vacation 311 313 314 316 318 HTTP/1.1 201 Created 319 Etag: "xyz" 321 Next, the note concerning the e-mail is changed. 323 PUT http://xcap.example.com/services/pidf-manipulation/users/someone/pidf.xml 324 /~~/presence/tuple%5b@id=%228eg92n%22%5d/note HTTP/1.1 325 If-Match: "xyz" 326 Content type:appliation/xcap-el+xml 328 I'm reading mails on Tuesdays and Fridays 330 HTTP/1.1 200 OK 331 Etag:"xyzz" 333 11. Security Considerations 335 A presence document may contain information that is highly sensitive. 336 Its delivery to watchers needs to happen strictly according to the 337 relevant authorization policies. It is also important that only 338 authorized clients are able to manipulate the presence information. 340 The XCAP base specification mandates that all XCAP servers MUST 341 implement HTTP Digest authentication specified in RFC 2617 [5]. 342 Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is 343 recommended that administrators of XCAP servers use an HTTPS URI as 344 the XCAP root services URI, so that the digest client authentication 345 occurs over TLS. By using these means, XCAP client and server can 346 ensure the confidentiality and integrity of the XCAP presence 347 document manipulation operations, and that only authorized clients 348 are allowed to perform them. 350 12. IANA Considerations 352 There is an IANA consideration associated with this specification. 354 12.1 XCAP Application Usage ID 356 This section registers a new XCAP Application Usage ID (AUID) 357 according to the IANA procedures defined in [2]. 359 Name of the AUID: pidf-manipulation 361 Description: Pidf-manipulation application usage defines how XCAP is 362 used to manipulate the contents of PIDF based presence documents. 364 13. Acknowledgements 366 The authors would like to thank Jonathan Rosenberg, Hisham Khartabil, 367 Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss, 368 Jose Costa-Requena, George Foti and Paul Kyzivat for their comments. 370 14. References 372 14.1 Normative References 374 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 375 Levels", BCP 14, RFC 2119, March 1997. 377 [2] Rosenberg, J., "The Extensible Markup Language (XML) 378 Configuration Access Protocol (XCAP)", 379 draft-ietf-simple-xcap-03 (work in progress), July 2004. 381 [3] Sugano, H., "CPIM presence information data format", 382 draft-ietf-impp-cpim-pidf-08, May 2003. 384 [4] Niemi, A., "An Event State Publication Extension for Session 385 Initiation Protocol (SIP)", draft-ietf-sip-publish-04.txt, May 386 2004. 388 [5] Franks, J., "HTTP Authentication: Basic and Digest Access 389 Authentication", RFC 2617, June 1999. 391 [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 393 14.2 Informative References 395 [7] Rosenberg, J., "A Presence Event Package for the Session 396 Initiation Protocol (SIP)", RFC 3856, August 2004. 398 [8] Schulzrinne, H., "RPID: Rich Presence Extensions to the 399 Presence Information Data Format (PIDF)", 400 draft-ietf-simple-rpid-03.txt (work in progress), March 2004. 402 [9] Schulzrinne, H., "CIPID: Contact Information in Presence 403 Information Data Format", draft-ietf-simple-cipid-03.txt (work 404 in progress), July 2004. 406 [10] Rosenberg, J., "A Data Model for Presence", 407 draft-ietf-simple-presence-data-model-00 (work in progress), 408 September 2004. 410 [11] Lonnfors, M., "User Agent Capability Extension to Presence 411 Information Data Format (PIDF)", 412 draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004. 414 [12] Schulzrinne, H., "Timed Presence Extensions to the Presence 415 Information Data Format (PIDF) to Indicate Presence Information 416 for Past and Future Time Intervals", 417 draft-ietf-simple-future-02 (work in progress), July 2004. 419 Authors' Addresses 421 Markus Isomaki 422 Nokia 423 P.O.BOX 100 424 00045 NOKIA GROUP 425 Finland 427 Phone: 428 EMail: markus.isomaki@nokia.com 430 Eva Leppanen 431 Nokia 432 P.O BOX 785 433 33101 Tampere 434 Finland 436 Phone: 437 EMail: eva-maria.leppanen@nokia.com 439 Intellectual Property Statement 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed to 443 pertain to the implementation or use of the technology described in 444 this document or the extent to which any license under such rights 445 might or might not be available; nor does it represent that it has 446 made any independent effort to identify any such rights. Information 447 on the procedures with respect to rights in RFC documents can be 448 found in BCP 78 and BCP 79. 450 Copies of IPR disclosures made to the IETF Secretariat and any 451 assurances of licenses to be made available, or the result of an 452 attempt made to obtain a general license or permission for the use of 453 such proprietary rights by implementers or users of this 454 specification can be obtained from the IETF on-line IPR repository at 455 http://www.ietf.org/ipr. 457 The IETF invites any interested party to bring to its attention any 458 copyrights, patents or patent applications, or other proprietary 459 rights that may cover technology that may be required to implement 460 this standard. Please address the information to the IETF at 461 ietf-ipr@ietf.org. 463 Disclaimer of Validity 465 This document and the information contained herein are provided on an 466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 468 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 469 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 470 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Copyright Statement 475 Copyright (C) The Internet Society (2004). This document is subject 476 to the rights, licenses and restrictions contained in BCP 78, and 477 except as set forth therein, the authors retain all their rights. 479 Acknowledgment 481 Funding for the RFC Editor function is currently provided by the 482 Internet Society.