📄 rfc4479 a data model for presence.txt
字号:
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 user
interacts with in order to make or receive communications.
Examples are a phone, PDA, or PC.
Person: A person is the end user, and for the purposes of presence,
is characterized by states, such as "busy" or "sad", that impact
their ability and willingness to communicate.
This specification defines these concepts more fully by means of a
presence data model, and concretely defines how to take real-world
systems and map them into presence documents using that model. This
data model is defined in terms of an extension to RFC 3863.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [9].
This document makes use of many additional terms beyond those defined
in RFC 2778 and RFC 3863. These new terms are as follows:
Device: A device models the physical environment in which services
manifest themselves for users. Devices have characteristics that
are useful in allowing a user to make a choice about which
communications service to use.
Service: A service models a form of communication that can be used
to interact with the user.
Person: A person models the human user and their states that are
relevant to presence systems.
Occurrence: A single description of a particular service, a
particular device, or a person. There may be multiple occurrences
for a particular service or device, or multiple person occurrences
in a Presence Information Data Format (PIDF) document, in cases
where there is ambiguity that is best resolved by the watcher.
Rosenberg Standards Track [Page 3]
RFC 4479 Presence Data Model July 2006
Presentity: A presentity combines devices, services, and person
information for a complete picture of a user's presence status on
the network.
Presentity URI: A URI that acts as a unique identifier for a
presentity and provides a handle for obtaining presence
information about that presentity.
Data Component: One of the device, service, or person parts of a
presence document.
Status: Presence information about a service, person, or device that
typically changes over time, in contrast to characteristics, which
are generally static.
Characteristics: Presence information about a service, person, or
device that is usually fixed over time, and descriptive in nature.
Characteristics are useful in providing context that identifies
the service or device as different from another service or device.
Attribute: A status or characteristic. It represents a single piece
of presence information.
Presence Attribute: A synonym for attribute.
Composition: The act of combining a set of presence and event data
about a presentity into a coherent picture of the state of that
presentity.
Rosenberg Standards Track [Page 4]
RFC 4479 Presence Data Model July 2006
3. The Model
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -