Network Working Group D. Crocker
Internet-Draft Brandenburg InternetWorking
Expires: May, 2002 A. Diacakis
F. Mazzoldi
Network Projects Inc.
C. Huitema
Microsoft Corporation
G. Klyne
Baltimore Technologies
J. Rosenberg
R. Sparks
dynamicsoft
H. Sugano
Fujitsu Laboratories Ltd.
November 2001
Common Presence and Instant Messaging (CPIM)
draft-ietf-impp-cpim-02
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of
RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to
use Internet-Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
HTTP://WWW.IETF.ORG/IETF/1ID-ABSTRACTS.TXT.
The list of Internet-Draft Shadow Directories can be
accessed at HTTP://WWW.IETF.ORG/SHADOW.HTML.
This Internet-Draft will expire on October 30, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights
Reserved.
Abstract
Semantics and data formats for common services of
Instant Messaging and online Presence, independent of
underlying transfer infrastructure, are described. The
CPIM profile meets the requirements specified in RFC
2779 using a minimalist approach allowing interoperation
of a wide range of IM and Presence systems.
Table of Contents
1. Introduction
1.1. Terminology
1.2. A Note on The Examples
2. Abstract Instant Messaging Service
2.1. Overview of the Messaging Service
2.2. Identification of INSTANT INBOXes
2.3. Format of Instant Messages
2.4. The Messaging Service
3. Abstract Presence Service
3.1. Overview of the Presence Service
3.2. Identification of PRESENTITIES
3.3. Format of Presence Information
3.4. The Presence Service
4. Security Considerations
4.1. Threats
4.2. Hop-by-hop security
4.3. End-to-end security
5. IANA Considerations
5.1. The IM URI Scheme
5.2. The PRES URI Scheme
6. The Common Service DTD
7. The Messaging Service DTD
8. The Presence Service DTD
9. The Presence Information DTD
10. References
11. Authors' Addresses
Appendix A. Message/CPIM Profile for Instant Messaging
Appendix B. Message/CPIM for Presence
Appendix C. IM URL IANA Registration Template
C.1. URL scheme name
C.2. URL scheme syntax
C.3. Character encoding considerations
C.4. Intended usage
C.5. Applications and/or protocols which use this URL
scheme name
C.6. Interoperability considerations
C.7. Security considerations
C.8. Relevant publications
C.9. Person & email address to contact for further
information
C.10. Author/Change controller
C.11.Applications and/or protocols which use this URL
scheme name
Appendix D. PRES URL IANA Registration Template
D.1. URL scheme name
D.2. URL scheme syntax
D.3. Character encoding considerations
D.4. Intended usage
D.5. Applications and/or protocols which use this URL
scheme name
D.6. Interoperability considerations
D.7. Security considerations
D.8. Relevant publications
D.9. Person & email address to contact for further
information
D.10. Author/Change controller
D.11.Applications and/or protocols which use this URL
scheme name
Appendix E. Issues of Interest
E.1. Address Mapping
E.2. Source-Route Mapping
Full Copyright Statement
Acknowledgement
1. Introduction
To achieve interoperation of IM and Presence systems
that are compliant with RFC 2779[10], there must be a
common agreement on both Instant Messaging and Presence
services. This memo defines such an agreement according
to the philosophy that there must be no loss of
information between IM systems that are minimally
conformant to RFC2779.
This memo focuses on interoperation. Accordingly only
those aspects of Presence and IM that require
interoperation are discussed. For example, the "open
instant inbox" operation is not applicable as this
operation occurs within a single IM system and not
across systems.
Service behavior is described abstractly in terms of
operations invoked between the consumer and provider of
a service. Accordingly, each IM 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
IM service.
The parameters for each operation are defined using an
abstract syntax. Although the syntax specifies the range
of possible data values, each Presence and IM service
must specify how well-formed instances of the abstract
representation are encoded as a concrete series of bits.
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 choice of strategy is a local
matter, providing that there is a clear relation between
the abstract syntax (as specified in this memo) and how
it is faithfully encoded by an particular Presence or IM
service.
1.1. Terminology
This memos makes use of the vocabulary defined in RFC
2778[9]. Terms such as CLOSED, INSTANT INBOX, INSTANT
MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY,
SUBSCRIPTION, and WATCHER are used in the same meaning
as defined therein.
1.2. A Note on The Examples
In the examples that follow, this memo uses time-
sequence diagrams annotated with XML fragments to
illustrate operations and their parameters. The use of
XML is an artifact of this memo's presentation style and
does not imply any requirement for the use of XML in an
IM system.
2. Abstract Instant Messaging Service
2.1. Overview of the Messaging Service
When an application wants to send a message to an
INSTANT INBOX, it invokes the message operation, e.g.,
+-------+ +-------+
| | | |
| appl. | -- message ------> | IM |
| | | svc. |
+-------+ +-------+
<message source='im:fred@example.com'
destination='im:barney@example.com'
transID='1' />
...
Content-Type: text/plain; charset="us-ascii" Yabba,
dabba, doo!
The service immediately responds by invoking the
response operation containing the same transaction-
identifier, e.g.,
+-------+ +-------+
| | | |
| appl. | <----- response -- | IM |
| | | svc. |
+-------+ +-------+
<response status='success' transID='1' />
2.2. Identification of INSTANT INBOXes
An INSTANT INBOX is specified using RFC 2822[2] (i.e.,
"local@domain") is, where the local-part MUST be
interpreted and assigned semantics only by the system
specified in the domain part of the identifier.
Representation of non-ASCII character sets in local-part
strings is limited to the standard methods provided as
extensions to RFC 2822[2]
2.2.1. Address Resolution
A client determines the address of an appropriate system
running a server by resolving the destination domain
name that is part of the identifier to either an
intermediate relay system or a final target system.
Only resolvable, fully-qualified, domain names (FQDNs)
are permitted when domain names are used in the
messaging service (i.e., domain names that can be
resolved to SRV[11] or A RRs).
2.2.2. Domain Name Lookup
A client lexically identifies a domain to which instant
messages will be delivered for processing, a DNS lookup
MUST be performed to resolve the DOMAIN[3]. The names
MUST be fully-qualified domain names (FQDNs) -ù
mechanisms for inferring FQDNs from partial names or
local aliases are a local matter.
The lookup first attempts to locate SRV RRs associated
with the domain. If a CNAME RR is found instead, the
resulting domain is processed as if it were the initial
domain.
If one or more SRV RRs are found for a given domain, a
sender MUST NOT utilize any A RRs associated with that
domain unless they are located using the SRV RRs. If no
SRV RRs are found, but an A RR is found, then the A RR
is treated as if it was associated with an implicit SRV
RR, with a preference of 0, pointing to that domain.
2.2.3. Processing SRV RRs
To process an IM URI, a lookup is performed for SRVs for
the target domain and a desired IM transfer protocol.
For example, if the destination INSTANT INBOX is
"im:fred@example.com", and the sender wishes to use an
IM transfer protocol called "SIP", then a SRV lookup is
performed for:
_im._sip.example.com.
The returned RRs, if any, specify the next-hop server.
The choice of IM transfer protocol is a local
configuration option for each system.
Using this mechanism, seamless routing of IM traffic is
possible, regardless of whether a gateway is necessary
for interoperation. To achieve this transparency, a
separate RR for a gateway must be present for each
transfer protocol and domain pair that it serves.
2.2.4. Processing Multiple Addresses
When the lookup succeeds, the mapping can result in a
list of alternative delivery addresses rather than a
single address, because of multiple SRV records,
multihoming, or both. For reliable operations, the
client MUST be able to try each of the relevant
addresses in this list in order, until a delivery
attempt succeeds. However, there MAY also be a
configurable limit on the number of alternate addresses
that can be tried. In any case, the client SHOULD try at
least two addresses. Two types of information are used
to rank the domain addresses: multiple SRV records, and
multihomed domains.
Multiple SRV records contain a preference indication
that MUST be used in sorting. Lower numbers are
preferable to higher ones. If there are multiple
destinations with the same preference, and there is no
clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender MUST randomize
them to spread the load across multiple servers for a
specific destination.
The destination domain (perhaps taken from the preferred
SRV record) may be multihomed, in which case the
resolver will return a list of alternative IP addresses.
It is the responsibility of the resolver to have ordered
this list by decreasing preference if necessary, and the
sender MUST try them in the order presented.
2.3. Format of Instant Messages
An INSTANT MESSAGE comprises a MIME
Type="message/cpim,profile=im" object, as defined in
XML/MIME[6] and MESSAGE/CPIM PROFILE FOR INSTANT
MESSAGING. Representation of non-ASCII character sets in
MIME is a standard feature of MIME.
2.4. The Messaging Service
THE COMMON SERVICE DTD and THE MESSAGING SERVICE DTD
define the abstract syntax of the operations invoked
with the service.
Note that the transaction-identifier parameters used
with the service are potentially long-lived.
Accordingly, the values of transaction-identifiers
should appear to be unpredictable.
2.4.1. The Message Operation
When an application wants to send an INSTANT MESSAGE, it
invokes the message operation.
The message operation has these parameters:
* The source parameter specifies the INSTANT INBOX on whose
behalf this message is sent (using an IM URI);
* The destination parameter specifies the INSTANT INBOX that
the message should be delivered to (using an IM URI);
* The transID parameter specifies the transaction-identifier
associated with this operation; and,
* The message to be sent.
When the service is informed of the message operation,
it performs these steps:
1. If the source or destination does not refer to a valid
INSTANT INBOX, a response operation having status "failure" is
invoked.
2. If access control does not permit the application to request
this operation, a response operation having status "failure" is
invoked.
3. Otherwise:
a) If the service is able to successfully deliver the message,
a response operation having status "success" is invoked.
b) If the service is unable to successfully deliver the
message, a response operation having status "failure" is invoked.
c) If the service must delegate responsibility for delivery,
and if the delegation will not result in a future authoritative
indication to the service, a response operation having status
"indeterminant" is invoked.
d) If the service must delegate responsibility for delivery,
and if the delegation will result in a future authoritative
indication to the service, then a response operation is invoked
immediately after the indication is received.
When the service invokes the response operation, the
transID parameter is identical to the value found in the
message operation invoked by the application.
2.4.2. Looping
The dynamic routing of instant messages can result in
looping of a message through a relay. Detection of loops
is not always obvious, since aliasing and group list
expansions can legitimately cause a message to pass
through a relay more than one time.
Instant messaging uses a hop count mechanism, for
detecting looping.
3. Abstract Presence Service
3.1. Overview of the Presence Service
When an application wants to (periodically) receive the
presence information associated with a PRESENTITY, it
invokes the subscribe operation, e.g.,
+-------+ +-------+
| | | |
| appl. | -- subscribe ----> | pres. |
| | | svc. |
+-------+ +-------+
<subscribe watcher='pres:wilma@example.com'
target='pres:fred@example.com'
duration='86400' transID='2' />
The service immediately responds by invoking the
response operation containing the same transaction-
identifier, e.g.,
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
<response status='success' transID='2' duration='3600'
/>
A WATCHER may have at most one subscription for a
PRESENTITY.
If the response operation indicates success, the service
immediate invokes the notify operation to communicate
the presence information to the WATCHER, e.g.,
+-------+ +-------+
| | | |
| appl. | <------- notify -- | pres. |
| | | svc. |
+-------+ +-------+
<notify watcher='pres:wilma@example.com'
target='pres:fred@example.com'
transID='1234'>
<presence entityInfo='http://www.example.com/fred/'>
<tuple destination='im:fred@example.com' status='open'
/>
</presence>
</notify>
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).
The application may prematurely cancel a subscription by
invoking the unsubscribe operation, e.g.,
+-------+ +-------+
| | | |
| appl. | -- unsubscribe --> | pres. |
| | | svc. |
+-------+ +-------+
<unsubscribe watcher='pres:wilma@example.com'
target='pres:fred@example.com'
transID='3' />
The service immediately responds by invoking the
response operation containing the same transaction-
identifier, e.g.,
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
<response status='success' transID='3' />
3.2. Identification of PRESENTITIES
A PRESENTITY is specified using the PRES URI scheme.
Briefly, the "addr-spec" syntax of RFC 822[1] (i.e.,
"local@domain") is used, where the local-part MUST be
interpreted and assigned semantics only by the domain
specified in the domain part of the identifier.
Representation of non-ASCII character sets in local-part
strings is limited to the standard methods provided as
extensions to RFC 822[1]
To resolve identifiers associated with the Presence
service, the mechanism defined in ADDRESS RESOLUTION is
used, except that the processing of a PRES URI is
performed by looking up SRV RRs for a desired presence
transfer protocol.
For example, if the destination PRESENTITY is
"pres:fred@example.com", and the sender wishes to use a
presence transfer protocol called "PEPP", then a SRV
lookup is performed for:
_pres._pepp.example.com.
3.3. Format of Presence Information
The format of a Presence message is a MIME
"Message/cpim,profile=pres" object, as defined in
MESSAGE/CPIM PROFILE FOR PRESENCE and XML/MIME[6].
Representation of non-ASCII character sets in MIME is a
standard feature of MIME.
3.4. The Presence Service
THE COMMON SERVICE DTD and THE PRESENCE SERVICE DTD
define the abstract syntax of the operations invoked
with the service.
An implementation of the service must maintain
information about both presence information and in-
progress operations in persistent storage.
Note that the transaction-identifier parameter used with
the service is potentially long-lived. Accordingly, the
values generated for this parameter should appear to be
unpredictable.
3.4.1. The Subscribe Operation
When an application wants to (periodically) receive the
presence information associated with an PRESENTITY, it
invokes the subscribe operation.
The subscribe operation has these parameters:
* The watcher parameter specifies the WATCHER associated with
the subscription;
* The target parameter specifies the PRESENTITY associated
with the presence information;
* The duration parameter specifies the maximum number of
seconds that the SUBSCRIPTION should be active; and,
* The transID parameter specifies the transaction-identifier
associated with this operation.
When the service is informed of the subscribe operation,
it performs these steps:
1. If the watcher or target parameter does not refer to a valid
PRESENTITY, a response operation having status "failure" is
invoked.
2. If access control does not permit the application to request
this operation, a response operation having status "failure" is
invoked.
3. If the duration parameter is non-zero, and if the watcher
and target parameters refer to an in-progress subscribe operation
for the application, a response operation having status "failure"
is invoked.
4. Otherwise:
a) A response operation having status "success" is immediately
invoked. (If the service chooses a different duration for the
subscription then it conveys this information in the response
operation.)
b) A notify operation, corresponding to the target's presence
information, is immediately invoked for the watcher.
c) For up to the amount of time indicated by the duration
parameter, if the target's presence information changes, and if
access control allows, a notify operation is invoked for the
watcher.
Note that if the duration parameter is zero-valued,
then the subscribe operation is making a one-time
poll of the presence information. Accordingly, Step
4.3 above does not occur.
When the service invokes a response operation as a
result of this processing, the transID parameter is
identical to the value found in the subscribe operation
invoked by the application.
3.4.2. The Notify Operation
The service invokes the notify operation whenever the
presence information associated with a PRESENTITY
changes and there are subscribers to that information.
The notify operation has these parameters:
* The watcher parameter specifies the WATCHER associated with
the subscription;
* The target parameter specifies the PRESENTITY associated
with the presence information;
* The transID parameter specifies the transaction-identifier
associated with this operation; and,
* The presence information for the PRESENTITY.
There is no application response to the notify
operation.
3.4.3. The Unsubscribe Operation
When an application wants to terminate a subscription,
it issues a SUBSCRIBE 0 with the ID of an existing
subscription.
There is no explicit UNSUBSCRIBE command.
3.4.4. The Fetch Operation
When an application wants to directly request presence
information to be supplied immediately, it issues a
SUBSCRIBE 0 with a new subscription ID.
There is no explicit FETCH command.
4. Security Considerations
This memo makes no specific requirements on security
procedures for interoperation between IM systems.
Accordingly, trust between interconnected IM systems is
determined in a bilateral matter.
However this memo does require that each IM system
control access to its Instant Messaging and Presence
services. Consult both RFC 2778 and RFC2779 for a
discussion of security considerations for IM systems.
4.1. Threats
Attacks, of concern for instant messaging, include
access, deletion, insertion, reordering and modification
of messages by unauthorized principals. Replay is a
combination of a subset of these attacks.
These attacks can take place in the communication links
between sending client and its server, between two
servers, between the receiving client and its server, or
by attacking any of the hosts involved. This document,
not being concerned with client-server interchanges,
only addresses threats aimed at server-server
communication.
Countermeasures against unauthorized access are
encrypted communication and encrypted messages.
Countermeasures against insertion of false messages are
authentication and authorization of sending servers and
strongly signed messages.
Countermeasures against reordered messages are date-
stamped or serial-numbered messages, coupled with
digital signatures that include the date or serial
number, if modification is not otherwise guarded
against.
Countermeasures against replayed messages are date
stamps and unique message IDs, coupled with digital
signatures that include the date or serial number, if
modification is not otherwise guarded against.
Countermeasures against deletion of messages are
integrity-protected connections between servers where
the server's identity is verified. Serial-numbered
messages can also be useful in detecting deleted
messages.
Attacks that target the server hosts rather than the
communication channels can successfully defeat all
countermeasures that depend on host security. Digital
signatures and encrypted messages do not depend on host
security, for intermediate systems, but cannot by
themselves guard against deletion or reordering of
messages.
For presence, the attacks include giving presence
information to unauthorized watchers, not reporting
watcher information back to a presentity, and insertion,
modification, deletion and replay of presence update
messages. The same set of countermeasures is relevant.
Instant messaging and presence systems can provide
security at two levels: hop-by-hop and/or end-to-end.
4.2. Hop-by-hop security
A useful but imperfect level of security can be provided
on a hop-by-hop basis, with all aspects of the
communication including message content and originator
verification, using transfer level security between
servers. The main drawback of this approach is that it
requires that each server that handles message or
presence information must be trusted. But it is
relatively easy to deploy, because it depends only on
bilateral arrangements between directly communicating
servers.
The underlying principles for using hop-by-hop security
are:
a) Each server and/or domain must keep their own house in
order, ensuring that operations and information accesses are
allowed only to appropriately authorized parties, and
b) Each server and/or domain must make its own choices about
the levels of trust to be established to any other server and/or
domain with which they directly communicate.
When passing IM and presence information between
services using different protocols, a gateway system
MUST be capable of using security mechanisms appropriate
to each of the protocols concerned, and must have access
to keys needed to authenticate any other system with
which it needs to directly communicate in a secure
fashion.
4.3. End-to-end security
End-to-end security is widely regarded as being more
satisfactory than hop-by-hop security, as the need to
trust intermediate parties is reduced. However, some
aspects of end-to-end security are difficult to achieve
because they need bilateral arrangement between any pair
of communicating parties about acceptable security
standards to use, and key exchange. Reliance on
bilateral agreements does not scale well. A moderating
alternative is a third-party certification service and
this approach, so far, has not found large-scale use.
The two IETF standards for end-to-end MIME object
security are OpenPGP[7] and S/MIME[8]. They require a
public key operation for each message. For repeated,
short transactions, this overhead can be onerous. A
version of these specifications, which permitted re-use
of the public key across multiple messages, would
greatly reduce instant messaging overhead.
4.3.1. Instant messages
End to end security for instant messages can be provided
using any of the MIME-based security mechanisms (S/MIME
[8], OpenPGP [7]), as instant message payload content is
not interpreted or reformatted in transit.
This specification allows any pair of communicating
parties to use any MIME-based security framework for
instant messages (c.f. section 2.3), but mechanisms for
establishing the required bilateral arrangements and key
exchange are not specified here.
4.3.2. Presence service
The situation regarding end-to-end security for presence
services is unclear, as there is no common encapsulation
framework specified for presence, and the presence data
itself is not invariant across different IM services.
[[[NOTE: this raises a case for fixing the presence
information to a specific format if end-to-end security
capability is to be a requirement.]]]
5. IANA Considerations
The IANA assigns the "im" and "pres" URL schemes.
5.1. The IM URI Scheme
The Instant Messaging (IM) URI scheme designates an
Internet resource, namely an INSTANT INBOX.
The syntax of an IM URL has the form:
"im:" addr-spec
where "addr-spec" is defined in RFC 822.
5.2. The PRES URI Scheme
The Presence (PRES) URI scheme designates an Internet
resource, namely a PRESENTITY or WATCHER.
The syntax of a PRES URL has the form:
"pres:" addr-spec
where "addr-spec" is defined in RFC 822.
6. The Common Service DTD
<!-- DTD for the IM common profile, as of 2000-08-16
Refer to this DTD as:
<!ENTITY % IMCOMMON PUBLIC "-//Blocks//DTD IM
COMMON//EN"
"http://xml.resource.org/syntaxes/IM/im-common.dtd">
%IMCOMMON; -->
<!-- DTD data types: entity syntax/reference example
=============================
a language tag LANG c.f., [RFC-1766] "en", "en-US",
etc. seconds SECONDS 0..2147483647 600
unique-identifier UNIQID 1..2147483647 42 authoritative
identity URI c.f., [RFC-2396] http://invisible.net/ -->
<!ENTITY % LANG "NMTOKEN">
<!ENTITY % SECONDS "CDATA">
<!ENTITY % UNIQID "CDATA"> <!ENTITY % URI "CDATA">
<!-- Abstract syntax for the response operation -->
<!ELEMENT response (#PCDATA)>
<!ATTLIST response status (success | failure |
indeterminant)
#REQUIRED transID %UNIQID;
#REQUIRED duration %SECONDS;
#IMPLIED xml:lang %LANG;
#IMPLIED >
7. The Messaging Service DTD
<!-- DTD for the abstract IM messaging service, as of
2000-08-16 Refer to this DTD as:
!ENTITY % IMMESSAGING PUBLIC "-//Blocks//DTD IM
MESSAGING//EN"
"http://xml.resource.org/syntaxes/IM/im-messaging.dtd">
%IMMESSAGING; -->
<!ENTITY % IMCOMMON PUBLIC "-//Blocks//DTD IM
COMMON//EN"
"http://xml.resource.org/syntaxes/IM/im-common.dtd">
%IMCOMMON; <!-- DTD data types: entity syntax/reference
example
=============================
INBOX c.f., Section 5.1 im:fred@example.com -->
<!ENTITY % INBOX "CDATA">
<!-- Abstract syntax for the message operation -->
<!ELEMENT message (#PCDATA)>
<!ATTLIST message source %INBOX;
#REQUIRED destination %INBOX;
#REQUIRED transID %UNIQID;
#REQUIRED >
8. The Presence Service DTD
<!-- DTD for the abstract IM presence service, as
of 2000-08-16 Refer to this DTD as:
<!ENTITY % IMPRESENCE PUBLIC "-//Blocks//DTD IM
PRESENCE//EN"
"http://xml.resource.org/syntaxes/IM/im-presence.dtd">
%IMPRESENCE; -->
<!ENTITY % IMCOMMON PUBLIC "-//Blocks//DTD IM
COMMON//EN"
"http://xml.resource.org/syntaxes/IM/im-common.dtd">
%IMCOMMON;
<!-- DTD data types: entity syntax/reference example
=============================
PRESENTITY c.f., Section 5.2 pres:fred@example.com -->
<!ENTITY % PRESENTITY "CDATA">
<!-- Abstract syntax for presence information -->
<!ELEMENT presence (tuple+)>
<!ATTLIST presence entityInfo %URI; "" >
<!ELEMENT tuple (#PCDATA)>
<!ATTLIST tuple destination %URI;
#REQUIRED status (open | closed)
#REQUIRED >
<!-- Abstract syntax for the subscribe operation -->
<!ELEMENT subscribe EMPTY>
<!ATTLIST subscribe watcher %PRESENTITY; #REQUIRED
target %PRESENTITY;
#REQUIRED duration %SECONDS;
#REQUIRED transID %UNIQID;
#REQUIRED >
<!-- Abstract syntax for the notify operation -->
<!ELEMENT notify (presence)>
<!ATTLIST notify watcher %PRESENTITY;
#REQUIRED target %PRESENTITY;
#REQUIRED transID %UNIQID;
#REQUIRED>
<!-- Abstract syntax for the unsubscribe operation -->
<!ELEMENT unsubscribe EMPTY>
<!ATTLIST unsubscribe watcher %PRESENTITY;
#REQUIRED target %PRESENTITY;
#REQUIRED transID %UNIQID;
#REQUIRED >
9. The Presence Information DTD
<!-- DTD the IM presence information of 2000-11-6 Refer
to this DTD as:
<!ENTITY % IMPRESENCEINFO PUBLIC "-//Blocks//DTD IM
PRESENCE//EN"
"http://xml.resource.org/syntaxes/IM/im-presence-
info.dtd"> %IMPRESENCEINFO; -->
<!ENTITY % IMCOMMON PUBLIC "-//Blocks//DTD IM
COMMON//EN"
"http://xml.resource.org/syntaxes/IM/im-common.dtd">
%IMCOMMON;
<!-- DTD data types: entity syntax/reference example
=============================
PRESENTITY c.f., Section 5.2 pres:Fred@example.com -->
<!ENTITY % PRESENTITY "CDATA">
<!-- Abstract syntax for presence information -->
<!ELEMENT presence (tuple+)>
<!ATTLIST presence entityInfo %URI; "" >
<!ELEMENT tuple (#PCDATA)>
<!ATTLIST tuple destination %URI;
#REQUIRED status (open | closed)
#REQUIRED >
10. References
[1] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES", RFC 822, STD 11, Aug 1982.
[2] Resnick, P., "INTERNET MESSAGE FORMAT", RFC 2822, STD 11,
April 2001.
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, STD 13, Nov 1987.
[4] FREED, N. and N. BORENSTEIN, "MULTIPURPOSE INTERNET MAIL
EXTENSIONS (MIME) PART ONE: FORMAT OF INTERNET MESSAGE
BODIES", RFC 2045, November 1996.
[5] CALLAS, J., DONNERHACKE, L., FINNEY, H. and R. THAYER,
"OPENPGP MESSAGE FORMAT", RFC 2440, November 1998.
[6] Klyne, G., "XML coding of RFC822 messages", I-D draft-klyne-
message-rfc822-xml-00.txt, November 2001.
[7] Sugano, H., "CPIM Presence Information Data Format", I-D
draft-ietf-impp-cpim-pidf-00.txt, August 2001.
[8] RAMSDELL, B., "S/MIME VERSION 3 CERTIFICATE HANDLING", RFC
2632, June 1999.
[9] DAY, M., ROSENBERG, J. and H. SUGANO, "A MODEL FOR PRESENCE
AND INSTANT MESSAGING", RFC 2778, February 2000.
[10] DAY, M., AGGARWAL, S. and J. VINCENT, "INSTANT MESSAGING /
PRESENCE PROTOCOL REQUIREMENTS", RFC 2779, February 2000.
[11] GULBRANDSEN, A., VIXIE, P. and L. ESIBOV, "A DNS RR FOR
SPECIFYING THE LOCATION OF SERVICES (DNS SRV)", RFC 2782,
February 2000.
[12] Allocchio, C., "GSTN ADDRESS ELEMENT EXTENSIONS IN E-MAIL
SERVICES", RFC 2846, June 2000.
11. Authors' Addresses
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone: +1 408 246 8253
EMail: DCROCKER@BRANDENBURG.COM
Athanassios Diacakis
Network Projects Inc.
4516 Henry Street
Suite 113
Pittsburgh, PA 15213
US
Phone: +1 412 681 6950 x202
EMail: THANOS@NETWORKPROJECTS.COM
Florencio Mazzoldi
Network Projects Inc.
4516 Henry Street
Suite 113
Pittsburgh, PA 15213
US
Phone: +1 412 681 6950
EMail: FLO@NETWORKPROJECTS.COM
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US
EMail: HUITEMA@MICROSOFT.COM
Graham Klyne
Baltimore Technologies
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 903 8000
EMail: GK@ACM.ORG
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
US
EMail: JDROSEN@DYNAMICSOFT.COM
Robert Sparks
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
US
EMail: RSPARKS@DYNAMICSOFT.COM
Hiroyasu Sugano
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555
JP
EMail: SUGA@FLAB.FUJITSU.CO.JP
Appendix A. Message/CPIM Profile for Instant Messaging
<<This section contains detail that creates a profile of
Content-Type=Message/CPIM, to cover use for Instant
Messaging. Text to be partly extracted from draft-klyne-
message-rfc822-xml-00.txt.>>
Appendix B. Message/CPIM for Presence
<<<This section contains detail that creates a profile
of Content-Type=Message/CPIM, to cover use for Presence
transactions. Text to be partly extracted from draft-
ietf-impp-cpim-pidf-00.txt.>>>
Appendix C. IM URL IANA Registration Template
This section provides the information to register the
im: instant messaging URL.
C.1. URL scheme name
im
C.2. URL scheme syntax
The syntax replicates the existing mailto: URL syntax
specified in RFC2368. The ABNF is:
IM-URL = "im:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
C.3. Character encoding considerations
Representation of non-ASCII character sets in local-part
strings is limited to the standard methods provided as
extensions to RFC 822[1]
C.4. Intended usage
Use of the im: URL follows closely usage of the mailto:
URL. That is, invocation of an IM URL will cause the
user's instant messaging application to start, with
destination address and message headers fill-in
according to the information supplied in the URL.
C.5. Applications and/or protocols which use this URL scheme name
It is anticipated that protocols compliant with RFC2779,
and meeting the interoperability requirements specified
here, will make use of this URL scheme name.
C.6. Interoperability considerations
The underlying exchange protocol used to send an instant
message may vary from service to service. Therefore
complete, Internet-scale interoperability cannot be
guaranteed. However, a service conforming to this
specification permits gateways to achieve
interoperability sufficient to the requirements of
RFC2779.
C.7. Security considerations
When IM URLs are placed in instant messaging protocols,
they convey the identity of the sender and/or the
recipient. In some cases, anonymous messaging may be
desired. Such a capability is beyond the scope of this
specification.
C.8. Relevant publications
RFC2779, RFC2778
C.9. Person & email address to contact for further information
Dave Crocker<dcrocker@brandenburg.com>
C.10. Author/Change controller
This scheme is registered under the IETF tree. As such,
IETF maintains change control.
C.11. Applications and/or protocols which use this URL scheme
name
Instant messaging service; presence service
Appendix D. PRES URL IANA Registration Template
This section provides the information to register the
pres: presence URL .
D.1. URL scheme name
pres
D.2. URL scheme syntax
The syntax replicates the existing mailto: URL syntax
specified in RFC2368. The ABNF is:
PRES-URL = "pres:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
D.3. Character encoding considerations
Representation of non-ASCII character sets in local-part
strings is limited to the standard methods provided as
extensions to RFC 822[1]
D.4. Intended usage
Use of the pres: URL follows closely usage of the
mailto: URL. That is, invocation of an PRES URL will
cause the user's instant messaging application to start,
with destination address and message headers fill-in
according to the information supplied in the URL.
D.5. Applications and/or protocols which use this URL scheme name
It is anticipated that protocols compliant with RFC2779,
and meeting the interoperability requirements specified
here, will make use of this URL scheme name.
D.6. Interoperability considerations
The underlying exchange protocol used for presence may
vary from service to service. Therefore complete,
Internet-scale interoperability cannot be guaranteed.
However, a service conforming to this specification
permits gateways to achieve interoperability sufficient
to the requirements of RFC2779.
D.7. Security considerations
When PRES URLs are placed in presence protocols, they
convey the identity of the sender and/or the recipient.
In some cases, anonymous messaging may be desired. Such
a capability is beyond the scope of this specification.
D.8. Relevant publications
RFC2779, RFC2778
D.9. Person & email address to contact for further information
Dave Crocker<dcrocker@brandenburg.com>
D.10. Author/Change controller
This scheme is registered under the IETF tree. As such,
IETF maintains change control.
D.11. Applications and/or protocols which use this URL scheme
name
Instant messaging service; presence service
Appendix E. Issues of Interest
This appendix briefly discusses issues that may be of
interest when designing an interoperation gateway.
E.1. Address Mapping
When mapping the service described in this memo,
mappings that place special information into the im:
address local-part MUST use the meta-syntax defined in
RFC 2486[12].
E.2. Source-Route Mapping
The easiest mapping technique is a form of source-
routing and usually is the least friendly to humans
having to type the string. Source-routing also has a
history of operational problems.
Use of source-routing for exchanges between different
services is by a transformation that places the entire,
original address string into the im: address local part
and names the gateway in the domain part.
For example, if the destination INSTANT INBOX is
"pepp://example.com/fred", then, after performing the
necessary character conversions, the resulting mapping
is:
im:pepp=example.com/fred@relay-domain
where "relay-domain" is derived from local configuration
information.
Experience shows that it is vastly preferable to hide
this mapping from end-users Ãù if possible, the
underlying software should perform the mapping
automatically.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, this document itself may not
be modified in any way, such as by removing the
copyright notice or references to the Internet Society
or other Internet organizations, except as needed for
the purpose of developing Internet standards in which
case the procedures for copyrights defined in the
Internet Standards process must be followed, or as
required to translate it into languages other than
English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
The Internet Society currently provides funding for the
RFC Editor function.
Datatracker
Report a datatracker bug
draft-ietf-impp-cpim-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |