From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4827.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc4827.txt (limited to 'doc/rfc/rfc4827.txt') 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 + ... + + + + + + + closed + + idle + auth-1 + sip:user@example.com + I'm available only by e-mail. + 2004-02-06T16:49:29Z + + + + + + + +Isomaki & Leppanen Standards Track [Page 7] + +RFC 4827 XCAP for Manipulating Presence Document May 2007 + + + open + + auth-1 + mailto:someone@example.com + I'm reading mail a couple of times a week + + + + auth-A + http://www.example.com/~someone + + + + + + + + + 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 + ... + + I'm reading mails on Tuesdays and Fridays + +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] + -- cgit v1.2.3