A Data Model for Presence
RFC 4479
Document | Type | RFC - Proposed Standard (July 2006; Errata) | |
---|---|---|---|
Author | Jonathan Rosenberg | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4479 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group J. Rosenberg Request for Comments: 4479 Cisco Systems Category: Standards Track July 2006 A Data Model for Presence 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 Internet Society (2006). Abstract This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. Rosenberg Standards Track [Page 1] RFC 4479 Presence Data Model July 2006 Table of Contents 1. Introduction ....................................................2 2. Definitions .....................................................3 3. The Model .......................................................5 3.1. Presentity URI .............................................6 3.2. Person .....................................................7 3.3. Service ....................................................8 3.3.1. Characteristics .....................................9 3.3.2. Reach Information ..................................10 3.3.3. Relative Information ...............................13 3.3.4. Status .............................................13 3.4. Device ....................................................15 3.5. Modeling Ambiguity ........................................17 3.6. The Meaning of Nothing ....................................19 3.7. Status vs. Characteristics ................................19 3.8. Presence Document Properties ..............................20 4. Motivation for the Model .......................................21 5. Encoding .......................................................22 5.1. XML Schemas ...............................................24 5.1.1. Common Schema ......................................24 5.1.2. Data Model .........................................25 6. Extending the Presence Model ...................................26 7. Example Presence Document ......................................26 7.1. Basic IM Client ...........................................27 8. Security Considerations ........................................29 9. Internationalization Considerations ............................29 10. IANA Considerations ...........................................30 10.1. URN Sub-Namespace Registration ...........................30 10.2. XML Schema Registrations .................................31 10.2.1. Common Schema .....................................31 10.2.2. Data Model ........................................31 11. Acknowledgements ..............................................31 12. References ....................................................32 12.1. Normative References .....................................32 12.2. Informative References ...................................32 1. Introduction Presence conveys the ability and willingness of a user to communicate across a set of devices. RFC 2778 [10] defines a model and terminology for describing systems that provide presence information. RFC 3863 [1] defines an XML [5] [6] [7] document format for representing presence information. In these specifications, presence information is modeled as a series of tuples, each of which contains a status, communications address, and other markup. However, neither specification gives guidance on exactly what a tuple is meant to model, or how to map real-world communications systems (and in Rosenberg Standards Track [Page 2] RFC 4479 Presence Data Model July 2006 particular, those built around the Session Initiation Protocol (SIP) [11]) into a presence document. In particular, several important concepts are not clearly modeled or well delineated by RFCs 2778 and 3863. These are the following: Service: A communications service, such as instant messaging (IM) or telephony, is a system for interaction between users that provides certain modalities or content. Device: A communications device is a physical component that a userShow full document text