📄 rfc3859 common profile for presence (cpp).txt
字号:
Network Working Group J. Peterson
Request for Comments: 3859 NeuStar
Category: Standards Track August 2004
Common Profile for Presence (CPP)
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 (2004).
Abstract
At the time this document was written, numerous presence protocols
were in use (largely as components of commercial instant messaging
services), and little interoperability between services based on
these protocols has been achieved. This specification defines common
semantics and data formats for presence to facilitate the creation of
gateways between presence services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Presence Service . . . . . . . . . . . . . . . . . . 4
3.1. Overview of the Presence Service . . . . . . . . . . . . 4
3.2. Identification of PRESENTITIES and WATCHERS . . . . . . 6
3.2.1. Address Resolution . . . . . . . . . . . . . . . 6
3.3. Format of Presence Information . . . . . . . . . . . . . 6
3.4. The Presence Service . . . . . . . . . . . . . . . . . . 7
3.4.1. The Subscribe Operation . . . . . . . . . . . . 7
3.4.2. The Notify Operation . . . . . . . . . . . . . . 8
3.4.3. Subscribe Operation (with Zero Duration) . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. The PRES URI Scheme . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Peterson Standards Track [Page 1]
RFC 3859 Common Profile for Presence August 2004
A. PRES URI IANA Registration Template . . . . . . . . . . . . . 12
A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 12
A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 12
A.3. Character Encoding Considerations . . . . . . . . . . . 12
A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 12
A.5. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.6. Interoperability Considerations . . . . . . . . . . . . 13
A.7. Security Considerations . . . . . . . . . . . . . . . . 13
A.8. Relevant Publications . . . . . . . . . . . . . . . . . 13
A.9. Person & Email Address to Contact for Further
Information. . . . . . . . . . . . . . . . . . . . . . . 13
A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13
A.11. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13
B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 13
B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 13
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Presence is defined in RFC2778 [5]. At the time this document was
written, numerous presence protocols are in use (largely as
components of commercial instant messaging services), and little
interoperability between services based on these protocols has been
achieved. This specification defines semantics and data formats for
common services of presence to facilitate the creation of gateways
between presence services: a common profile for presence (CPP).
Service behavior is described abstractly in terms of operations
invoked between the consumer and provider of a service. Accordingly,
each presence service must specify how this behavior is mapped onto
its own protocol interactions. The choice of strategy is a local
matter, providing that there is a clear relation between the abstract
behaviors of the service (as specified in this memo) and how it is
faithfully realized by a particular presence service. For example,
one strategy might transmit presence information as key/value pairs,
another might use a compact binary representation, and a third might
use nested containers.
The parameters for each operation are defined using an abstract
syntax. Although the syntax specifies the range of possible data
values, each presence service must specify how well-formed instances
of the abstract representation are encoded as a concrete series of
bits.
Peterson Standards Track [Page 2]
RFC 3859 Common Profile for Presence August 2004
In order to provide a means for the preservation of end-to-end
features (especially security) to pass through presence
interoperability gateways, this specification also provides
recommendations for presence document formats that could be employed
by presence protocols.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
This memos makes use of the vocabulary defined in RFC 2778 [5].
Terms such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in
the same meaning as defined therein.
The term 'gateway' used in this document denotes a network element
responsible for interworking between diverse presence protocols.
Although the presence protocols themselves are diverse, under the
model in this document these protocols can carry a common payload
that is relayed by the gateway. Whether these interworking
intermediaries should be called 'gateways' or 'relays' is therefore
somewhat debatable; for the purposes of this document, they are
called 'CPP gateways'.
The term 'presence service' also derives from RFC 2778, but its
meaning changes slightly due to the existence of gateways in the CPP
model. When a client sends an operation to a presence service, that
service might either be an endpoint or an intermediary such as a CPP
gateway - in fact, the client should not have to be aware which it is
addressing, as responses from either will appear the same.
This document defines operations and attributes of an abstract
presence protocol. In order for a compliant protocol to interface
with a presence gateway, it must support all of the operations
described in this document (i.e., the presence protocol must have
some message or capability that provides the function described by
all given operations). Similarly, the attributes defined for these
operations must correspond to information available in the presence
protocol in order for the protocol to interface with gateways defined
by this specification. Note that these attributes provide only the
minimum possible information that needs to be specified for
interoperability - the functions in a presence protocol that
correspond to the operations described in this document can contain
additional information that will not be mapped by CPP.
Peterson Standards Track [Page 3]
RFC 3859 Common Profile for Presence August 2004
3. Abstract Presence Service
3.1. Overview of the Presence Service
When an application wants to subscriber to the presence information
associated with a PRESENTITY (in order to receive periodic
notifications of presence information), it invokes the subscribe
operation, e.g.,
+-------+ +-------+
| | | |
| appl. | -- subscribe ----> | pres. |
| | | svc. |
+-------+ +-------+
The subscribe operation has the following attributes: watcher,
target, duration, SubscriptID and TransID. The 'watcher' and
'target' identify the WATCHER and PRESENTITY, respectively, using the
identifiers described in Section 3.2. The duration specifies the
maximum number of seconds that the SUBSCRIPTION should be active
(which may be zero, in which case this is a one-time request for
presence information). The SubscriptID creates a reference to the
SUBSCRIPTION that is used when unsubscribing. The TransID is a
unique identifier used to correlate the subscribe operation with a
response operation. Gateways should be capable of handling TransIDs
and SubscriptIDs up to 40 bytes in length.
Upon receiving a subscribe operation, the service immediately
responds by invoking the response operation containing the same
TransID, e.g.,
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
The response operation has the following attributes: status, TransID,
and duration. 'status' indicates whether the subscribe operation has
succeeded or failed. The TransID of the response operation
corresponds to the TransID of the subscription operation to which it
is responding. The 'duration' attribute specifies the number of
seconds for which the subscription will be active (which may differ
from the value requested in the subscribe operation).
Peterson Standards Track [Page 4]
RFC 3859 Common Profile for Presence August 2004
If the response operation indicates success, the service immediately
invokes the notify operation to communicate the presence information
to the WATCHER, e.g.,
+-------+ +-------+
| | | |
| appl. | <------- notify -- | pres. |
| | | svc. |
+-------+ +-------+
The notify operation has the following attributes: watcher, target,
and TransID. The values of 'watcher' and 'target' are identical to
those given in the subscribe operation that triggered this notify
operation. The TransID is a unique identifier for this notification.
The notify operation also has content, namely PRESENCE INFORMATION.
Content details are specified in Section 3.3.
If the duration parameter is non-zero, then for up to the specified
duration, the service invokes the notify operation whenever there are
any changes to the PRESENTITY's presence information. Otherwise,
exactly one notify operation is invoked, achieving a one-time poll of
the presence information. Regardless, there is no application
response to the notify operation (i.e., the application does not
invoke a response operation when a notify operation occurs) defined
in CPP.
The application may prematurely cancel a subscription by re-invoking
the subscribe operation (as described above) with a duration of 0 and
the same SubscriptID as the original subscribe operation , e.g.,
+-------+ +-------+
| | | |
| appl. | -- subscribe 0 --> | pres. |
| | | svc. |
+-------+ +-------+
Note that a notify operation will be invoked when a subscription is
prematurely canceled in this fashion; this notification may be
discarded by the watcher.
Peterson Standards Track [Page 5]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -