An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
RFC 4827

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