summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4827.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4827.txt')
-rw-r--r--doc/rfc/rfc4827.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4827.txt b/doc/rfc/rfc4827.txt
new file mode 100644
index 0000000..437281b
--- /dev/null
+++ b/doc/rfc/rfc4827.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group M. Isomaki
+Request for Comments: 4827 E. Leppanen
+Category: Standards Track Nokia
+ May 2007
+
+
+An Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
+ Usage for Manipulating Presence Document Contents
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes a usage of the Extensible Markup Language
+ (XML) Configuration Access Protocol (XCAP) for manipulating the
+ contents of Presence Information Data Format (PIDF) based presence
+ documents. It is intended to be used in Session Initiation Protocol
+ (SIP) based presence systems, where the Event State Compositor can
+ use the XCAP-manipulated presence document as one of the inputs on
+ which it builds the overall presence state for the presentity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 1]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Relationship with Presence State Published Using SIP
+ PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Application Usage ID . . . . . . . . . . . . . . . . . . . . . 6
+ 5. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6. Structure of Manipulated Presence Information . . . . . . . . . 6
+ 7. Additional Constraints . . . . . . . . . . . . . . . . . . . . 6
+ 8. Resource Interdependencies . . . . . . . . . . . . . . . . . . 6
+ 9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 6
+ 10. Authorization Policies . . . . . . . . . . . . . . . . . . . . 6
+ 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
+ 13.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
+ 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 15.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 15.2. Informative References . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 2]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+1. Introduction
+
+ The Session Initiation Protocol (SIP) for Instant Messaging and
+ Presence (SIMPLE) specifications allow a user, called a watcher, to
+ subscribe to another user, called a presentity, in order to learn its
+ presence information [7]. The presence data model has been specified
+ in [10]. The data model makes a clean separation between person-,
+ service-, and device-related information.
+
+ A SIP-based mechanism, SIP PUBLISH method, has been defined for
+ publishing presence state [4]. Using SIP PUBLISH, a Presence User
+ Agent (PUA) can publish its view of the presence state, independently
+ of and without the need to learn about the states set by other PUAs.
+ However, SIP PUBLISH has a limited scope and does not address all the
+ requirements for setting presence state. The main issue is that SIP
+ PUBLISH creates a soft state that expires after the negotiated
+ lifetime unless it is refreshed. This makes it unsuitable for cases
+ where the state should prevail without active devices capable of
+ refreshing the state.
+
+ There are three main use cases where setting of permanent presence
+ state that is independent of activeness of any particular device is
+ useful. The first case concerns setting person-related state. The
+ presentity would often like to set its presence state even for
+ periods when it has no active devices capable of publishing
+ available. Good examples are traveling, vacations, and so on. The
+ second case is about setting state for services that are open for
+ communication, even if the presentity does not have a device running
+ that service online. Examples of these kinds of services include
+ e-mail, Multimedia Messaging Service (MMS), and Short Message Service
+ (SMS). In these services, the presentity is provisioned with a
+ server that makes the service persistently available, at least in
+ certain forms, and it would be good to be able to advertise this to
+ the watchers. Since it is not realistic to assume that all e-mail,
+ MMS, or SMS servers can publish presence state on their own (and even
+ if this were possible, such state would almost never change), this
+ has to be done by some other device. And since the availability of
+ the service is not dependent on that device, it would be impractical
+ to require that device to be constantly active just to publish such
+ availability. The third case concerns setting the default state of
+ any person, service, or device in the absence of any device capable
+ of actively publishing such state. For instance, the presentity
+ might want to advertise that his or her voice service is currently
+ closed, just to let the watchers know that such service might be open
+ at some point. Again, this type of default state is independent of
+ any particular device and can be considered rather persistent.
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 3]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+ Even though SIP PUBLISH remains the main way of publishing presence
+ state in SIMPLE-based presence systems and is especially well-suited
+ for publishing dynamic state (which presence mainly is), it needs to
+ be complemented by the mechanism described in this document to
+ address the use cases presented above.
+
+ XML Configuration Access Protocol (XCAP) [2] allows a client to read,
+ write, and modify application configuration data stored in XML format
+ on a server. The data has no expiration time, so it must be
+ explicitly inserted and deleted. The protocol allows multiple
+ clients to manipulate the data, provided that they are authorized to
+ do so. XCAP is already used in SIMPLE-based presence systems for
+ manipulation of presence lists and presence authorization policies.
+ This makes XCAP an ideal choice for doing device-independent presence
+ document manipulation.
+
+ This document defines an XML Configuration Access Protocol (XCAP)
+ application usage for manipulating the contents of presence document.
+ Presence Information Document Format (PIDF) [3] is used as the
+ presence document format, since the event state compositor already
+ has to support it, as it is used in SIP PUBLISH.
+
+ Section 3 describes in detail how the presence document manipulated
+ with XCAP is related to soft state publishing done with SIP PUBLISH.
+
+ XCAP requires application usages to standardize several pieces of
+ information, including a unique application usage ID (AUID) and an
+ XML schema for the manipulated data. These are specified starting
+ from Section 4.
+
+2. Conventions
+
+ In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
+ 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
+ and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and
+ indicate requirement levels for compliant implementations.
+
+ Comprehensive terminology of presence and event state publishing is
+ provided in "Session Initiation Protocol (SIP) Extension for Event
+ State Publication" [4].
+
+3. Relationship with Presence State Published Using SIP PUBLISH
+
+ The framework for publishing presence state is described in Figure 1.
+ A central part of the framework is the event state compositor
+ element, whose function is to compose presence information received
+ from several sources into a single coherent presence document.
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 4]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+ The presence state manipulated with XCAP can be seen as one of the
+ information sources for the compositor to be combined with the soft
+ state information published using SIP PUBLISH. This is illustrated
+ in Figure 1. It is expected that, in the normal case, there can be
+ several PUAs publishing their separate views with SIP PUBLISH, but
+ only a single XCAP manipulated presence document. As shown in the
+ figure, multiple XCAP clients (for instance, in different physical
+ devices) can manipulate the same document on the XCAP server, but
+ this still creates only one input to the event state compositor. The
+ XCAP server stores the XCAP manipulated presence document under the
+ "users" tree in the XCAP document hierarchy. See Section 9 for
+ details and Section 11 for an example.
+
+ As individual inputs, the presence states set by XCAP and SIP PUBLISH
+ are completely separated, and it is not possible to directly
+ manipulate the state set by one mechanism with the other. How the
+ compositor treats XCAP-based inputs with respect to SIP PUBLISH-based
+ inputs is a matter of compositor policy, which is beyond the scope of
+ this specification. Since the SIP PUBLISH specification already
+ mandates the compositor to be able to construct the overall presence
+ state from multiple inputs, which may contain non-orthogonal (or in
+ some ways even conflicting) information, this XCAP usage does not
+ impose any new requirements on the compositor functionality.
+
+ +---------------+ +------------+
+ | Event State | | Presence |<-- SIP SUBSCRIBE
+ | Compositor +---------+ Agent |--> SIP NOTIFY
+ | | | (PA) |
+ +-------+-------+ +------------+
+ ^ ^ ^
+ | | |
+ | | | +---------------+
+ +--------+ | +-------| XCAP server |
+ | | +-------+-------+
+ | | ^ ^
+ | SIP Publish | | XCAP |
+ | | | |
+ +--+--+ +--+--+ +-------+ +-------+
+ | PUA | | PUA | | XCAP | | XCAP |
+ | | | | | client| | client|
+ +-----+ +-----+ +-------+ +-------+
+
+
+ Figure 1: Framework for Presence Publishing and Event State
+ Composition
+
+ The protocol interface between XCAP server and the event state
+ compositor is not specified here.
+
+
+
+Isomaki & Leppanen Standards Track [Page 5]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+4. Application Usage ID
+
+ XCAP requires application usages to define a unique application usage
+ ID (AUID) in either the IETF tree or a vendor tree. This
+ specification defines the 'pidf-manipulation' AUID within the IETF
+ tree, via the IANA registration in Section 13.
+
+5. MIME Type
+
+ The MIME type for this application usage is 'application/pidf+xml'.
+
+6. Structure of Manipulated Presence Information
+
+ The XML Schema of the presence information is defined in the Presence
+ Information Data Format (PIDF) [3]. The PIDF also defines a
+ mechanism for extending presence information. See [8], [9], [11],
+ and [12] for currently defined PIDF extensions and their XML Schemas.
+
+ The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf' which is
+ also the XCAP default document namespace.
+
+7. Additional Constraints
+
+ There are no constraints on the document beyond those described in
+ the XML schemas (PIDF and its extensions) and in the description of
+ PIDF [3].
+
+8. Resource Interdependencies
+
+ There are no resource interdependencies beyond the possible
+ interdependencies defined in PIDF [3] and XCAP [2] that need to be
+ defined for this application usage.
+
+9. Naming Conventions
+
+ The XCAP server MUST store only a single XCAP manipulated presence
+ document for each user. The presence document MUST be located under
+ the "users" tree, using filename "index". See an example in
+ Section 11.
+
+10. Authorization Policies
+
+ This application usage does not modify the default XCAP authorization
+ policy, which allows only a user (owner) to read, write, or modify
+ their own documents. A server can allow privileged users to modify
+ documents that they do not own, but the establishment and indication
+ of such policies is outside the scope of this document.
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 6]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+11. Example
+
+ The section provides an example of a presence document provided by an
+ XCAP Client to an XCAP Server. The presence document illustrates the
+ situation where a (human) presentity has left for vacation, and
+ before that, has set his presence information so that he is only
+ available via e-mail. In the absence of any published soft state
+ information, this would be the sole input to the compositor forming
+ the presence document. The example document contains PIDF extensions
+ specified in "RPID: Rich Presence Extensions to the Presence
+ Information Data Format (PIDF)" [8] and "CIPID: Contact Information
+ in Presence Information Data Format" [9].
+
+ It is assumed that the presentity is a SIP user with Address-of-
+ Record (AOR) sip:someone@example.com. The XCAP root URI for
+ example.com is assumed to be http://xcap.example.com. The XCAP User
+ Identifier (XUI) is assumed to be identical to the SIP AOR, according
+ to XCAP recommendations. In this case, the presence document would
+ be located at http://xcap.example.com/pidf-manipulation/users/
+ sip:someone@example.com/index.
+
+ The presence document is created with the following XCAP operation:
+
+ PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1
+ Host: xcap.example.com
+ Content-Type: application/pidf+xml
+ ...
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
+ xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
+ xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
+ entity="sip:someone@example.com">
+
+ <tuple id="x8eg92m">
+ <status>
+ <basic>closed</basic>
+ </status>
+ <rp:user-input>idle</rp:user-input>
+ <rp:class>auth-1</rp:class>
+ <contact priority="0.5">sip:user@example.com</contact>
+ <note>I'm available only by e-mail.</note>
+ <timestamp>2004-02-06T16:49:29Z</timestamp>
+ </tuple>
+
+ <tuple id="x8eg92n">
+ <status>
+
+
+
+Isomaki & Leppanen Standards Track [Page 7]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+ <basic>open</basic>
+ </status>
+ <rp:class>auth-1</rp:class>
+ <contact priority="1.0">mailto:someone@example.com</contact>
+ <note>I'm reading mail a couple of times a week</note>
+ </tuple>
+
+ <dm:person id="p1">
+ <rp:class>auth-A</rp:class>
+ <ci:homepage>http://www.example.com/~someone</ci:homepage>
+ <rp:activities>
+ <rp:vacation/>
+ </rp:activities>
+ </dm:person>
+
+ </presence>
+
+
+ When the user wants to change the note related to e-mail service,
+ it is done with the following XCAP operation:
+
+ PUT /pidf-manipulation/users/sip:someone@example.com/index/
+ ~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1
+ If-Match: "xyz"
+ Host: xcap.example.com
+ Content-Type: application/xcap-el+xml
+ ...
+
+ <note>I'm reading mails on Tuesdays and Fridays</note>
+
+12. Security Considerations
+
+ A presence document may contain information that is highly sensitive.
+ Its delivery to watchers needs to happen strictly according to the
+ relevant authorization policies. It is also important that only
+ authorized clients are able to manipulate the presence information.
+
+ The XCAP base specification mandates that all XCAP servers MUST
+ implement HTTP Digest authentication specified in RFC 2617 [5].
+ Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is
+ recommended that administrators of XCAP servers use an HTTPS URI as
+ the XCAP root services' URI, so that the digest client authentication
+ occurs over TLS. By using these means, XCAP client and server can
+ ensure the confidentiality and integrity of the XCAP presence
+ document manipulation operations, and that only authorized clients
+ are allowed to perform them.
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 8]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+13. IANA Considerations
+
+ There is an IANA consideration associated with this specification.
+
+13.1. XCAP Application Usage ID
+
+ This section registers a new XCAP Application Usage ID (AUID)
+ according to the IANA procedures defined in [2].
+
+ Name of the AUID: pidf-manipulation
+
+ Description: Pidf-manipulation application usage defines how XCAP is
+ used to manipulate the contents of PIDF-based presence documents.
+
+14. Acknowledgements
+
+ The authors would like to thank Jari Urpalainen, Jonathan Rosenberg,
+ Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu,
+ Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for
+ their comments.
+
+15. References
+
+15.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Rosenberg, J., "The Extensible Markup Language (XML)
+ Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
+
+ [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
+ J. Peterson, "Presence Information Data Format (PIDF)",
+ RFC 3863, August 2004.
+
+ [4] Niemi, A., "Session Initiation Protocol (SIP) Extension for
+ Event State Publication", RFC 3903, October 2004.
+
+ [5] Franks, J., "HTTP Authentication: Basic and Digest Access
+ Authentication", RFC 2617, June 1999.
+
+ [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+15.2. Informative References
+
+ [7] Rosenberg, J., "A Presence Event Package for the Session
+ Initiation Protocol (SIP)", RFC 3856, August 2004.
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 9]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+ [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
+ "RPID: Rich Presence Extensions to the Presence Information
+ Data Format (PIDF)", RFC 4480, July 2006.
+
+ [9] Schulzrinne, H., "CIPID: Contact Information for the Presence
+ Information Data Format", RFC 4482, July 2006.
+
+ [10] Rosenberg, J., "A Data Model for Presence", RFC 4479,
+ July 2006.
+
+ [11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP)
+ User Agent Capability Extension to Presence Information Data
+ Format (PIDF)", Work in Progress, July 2006.
+
+ [12] Schulzrinne, H., "Timed Presence Extensions to the Presence
+ Information Data Format (PIDF) to Indicate Status Information
+ for Past and Future Time Intervals", RFC 4481, July 2006.
+
+Authors' Addresses
+
+ Markus Isomaki
+ Nokia
+ P.O. BOX 100
+ 00045 NOKIA GROUP
+ Finland
+
+ EMail: markus.isomaki@nokia.com
+
+
+ Eva Leppanen
+ Nokia
+ P.O. BOX 785
+ 33101 Tampere
+ Finland
+
+ EMail: eva-maria.leppanen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 10]
+
+RFC 4827 XCAP for Manipulating Presence Document May 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Isomaki & Leppanen Standards Track [Page 11]
+