< draft-ietf-impp-pres-03.txt   draft-ietf-impp-pres-04.txt >
IMPP WG J. Peterson IMPP WG J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Expires: November 17, 2003 May 19, 2003 Expires: February 12, 2004 August 14, 2003
Common Profile for Presence (CPP) Common Profile for Presence (CPP)
draft-ietf-impp-pres-03 draft-ietf-impp-pres-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 17, 2003. This Internet-Draft will expire on February 12, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Presence is defined in RFC2778 [5]. Today, numerous presence At the time this document was written, numerous presence protocols
protocols are in use (largely as components of commercial instant are in use (largely as components of commercial instant messaging
messaging services), and little interoperability between services services), and little interoperability between services based on
based on these protocols has been achieved. This specification these protocols has been achieved. This specification defines common
defines common semantics and data formats for presence to facilitate semantics and data formats for presence to facilitate the creation of
the creation of gateways between presence services. gateways between presence services.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Presence Service . . . . . . . . . . . . . . . . . 4 3. Abstract Presence Service . . . . . . . . . . . . . . . . . 4
3.1 Overview of the Presence Service . . . . . . . . . . . . . . 4 3.1 Overview of the Presence Service . . . . . . . . . . . . . . 4
3.2 Identification of PRESENTITIES and WATCHERS . . . . . . . . 6 3.2 Identification of PRESENTITIES and WATCHERS . . . . . . . . 6
3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 7
3.3 Format of Presence Information . . . . . . . . . . . . . . . 7 3.3 Format of Presence Information . . . . . . . . . . . . . . . 7
3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 7 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 7
3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 7 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 7
3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 8 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 8
3.4.3 Subscribe Operation (with Zero Duration) . . . . . . . . . . 8 3.4.3 Subscribe Operation (with Zero Duration) . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 10 5.1 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 10
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
A. PRES URI IANA Registration Template . . . . . . . . . . . . 11 A. PRES URI IANA Registration Template . . . . . . . . . . . . 11
A.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . 11 A.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . 12
A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 11 A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 12
A.3 Character encoding considerations . . . . . . . . . . . . . 12 A.3 Character encoding considerations . . . . . . . . . . . . . 12
A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 12 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 12
A.5 Applications and/or protocols which use this URI scheme A.5 Applications and/or protocols which use this URI scheme
name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.6 Interoperability considerations . . . . . . . . . . . . . . 12 A.6 Interoperability considerations . . . . . . . . . . . . . . 12
A.7 Security considerations . . . . . . . . . . . . . . . . . . 12 A.7 Security considerations . . . . . . . . . . . . . . . . . . 12
A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 12 A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 13
A.9 Person & email address to contact for further information . 12 A.9 Person & email address to contact for further information . 13
A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 13 A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 13
A.11 Applications and/or protocols which use this URI scheme A.11 Applications and/or protocols which use this URI scheme
name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 13 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 13
B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 13 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 13
B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 13 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . 11
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Presence is defined in RFC2778 [5]. Today, numerous presence Presence is defined in RFC2778 [5]. At the time this document was
protocols are in use (largely as components of commercial instant written, numerous presence protocols are in use (largely as
messaging services), and little interoperability between services components of commercial instant messaging services), and little
based on these protocols has been achieved. This specification interoperability between services based on these protocols has been
defines semantics and data formats for common services of presence to achieved. This specification defines semantics and data formats for
facilitate the creation of gateways between presence services: a common services of presence to facilitate the creation of gateways
common profile for presence (CPP). between presence services: a common profile for presence (CPP).
Service behavior is described abstractly in terms of operations Service behavior is described abstractly in terms of operations
invoked between the consumer and provider of a service. Accordingly, invoked between the consumer and provider of a service. Accordingly,
each presence service must specify how this behavior is mapped onto each presence service must specify how this behavior is mapped onto
its own protocol interactions. The choice of strategy is a local its own protocol interactions. The choice of strategy is a local
matter, providing that there is a clear relation between the abstract matter, providing that there is a clear relation between the abstract
behaviors of the service (as specified in this memo) and how it is behaviors of the service (as specified in this memo) and how it is
faithfully realized by a particular presence service. For example, faithfully realized by a particular presence service. For example,
one strategy might transmit presence information as key/value pairs, one strategy might transmit presence information as key/value pairs,
another might use a compact binary representation, and a third might another might use a compact binary representation, and a third might
skipping to change at page 9, line 41 skipping to change at page 9, line 41
described in [4]) is supported by the protocols interfacing with the described in [4]) is supported by the protocols interfacing with the
CPP gateway. CPP gateway.
When end-to-end security is required, the notify operation MUST use When end-to-end security is required, the notify operation MUST use
PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with
encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS
SignedData). SignedData).
The S/MIME algorithms are set by CMS [9]. The AES [10] algorithm The S/MIME algorithms are set by CMS [9]. The AES [10] algorithm
should be preferred, as it is expected that AES best suits the should be preferred, as it is expected that AES best suits the
capabilities of many platforms. However, an IETF specificationfor capabilities of many platforms. Implementations MAY use AES as an
this is still incomplete as of the time of this writing. encryption algorithm, but are REQUIRED to support only the baseline
algorithms mandated by S/MIME and CMS.
When PRES URIs are placed in presence protocols, they convey the When PRES URIs are used in presence protocols, they convey the
identity of the sender and/or the recipient. In some cases, identity of watchers and/or presentities. Certificates that are used
anonymous messaging may be desired. Such a capability is beyond the for S/MIME presence operations SHOULD, for the purposes of reference
scope of this specification. integrity, contain a subjectAltName field containing the PRES URI of
their subject. Note that such certificates may also contain other
identifiers, including those specific to particular presence
protocols. In order to further facilitate interoperability of secure
presence services through CPP gateways, users and service providers
are encouraged to employ trust anchors for certificates that are
widely accepted rather than trust anchors specific to any particular
presence service or provider.
In some cases, anonymous presence services may be desired. Such a
capability is beyond the scope of this specification.
5. IANA Considerations 5. IANA Considerations
The IANA assigns the "pres" URI scheme. The IANA assigns the "pres" URI scheme.
5.1 The PRES URI Scheme 5.1 The PRES URI Scheme
The Presence (PRES) URI scheme designates an Internet resource, The Presence (PRES) URI scheme designates an Internet resource,
namely a PRESENTITY or WATCHER. namely a PRESENTITY or WATCHER.
skipping to change at page 11, line 17 skipping to change at page 11, line 29
Services", RFC 2846, June 2000. Services", RFC 2846, June 2000.
[8] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- [8] Ramsdell, B., "S/MIME Version 3 Message Specification", draft-
ietf-smime-rfc2633bis-03 (work in progress), January 2003. ietf-smime-rfc2633bis-03 (work in progress), January 2003.
[9] Housley, R., "Cryptographic Message Syntax", RFC 3369, August [9] Housley, R., "Cryptographic Message Syntax", RFC 3369, August
2002. 2002.
Informative References Informative References
[10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm [10] Schaad, J., "Use of the Advanced Encryption Standard (AES)
and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 Encryption Algorithm and in Cryptographic Message Syntax
(work in progress), January 2003. (CMS)", RFC 3565, July 2003.
Author's Address Author's Address
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
 End of changes. 12 change blocks. 
32 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/