Network Working Group D.H. Crocker
Internet-Draft Brandenburg Consulting
Expires: February 19, 2001 A. Diacakis
F. Mazzoldi
Network Projects Inc.
C. Huitema
Microsoft Corporation
G. Klyne
Content Technologies Limited
M.T. Rose
Invisible Worlds, Inc.
J. Rosenberg
R. Sparks
dynamicsoft
H. Sugano
Fujitsu Laboratories Ltd.
August 21, 2000
A Common Profile for Instant Messaging (CPIM)
draft-mrose-impp-common-00
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 February 19, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Crocker, et. al. Expires February 19, 2001 [Page 1]
Internet-Draft CPIM August 2000
This memo describes a common set of Instant Messaging formats and
services, independent of underlying IM infrastructure. The profile
meets the requirements specified in RFC 2779 using a minimalist
approach allowing interoperation of a wide range of IM systems.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 A Note on The Examples . . . . . . . . . . . . . . . . . . 3
2. Abstract Messaging Service . . . . . . . . . . . . . . . . 4
2.1 Overview of the Messaging Service . . . . . . . . . . . . 4
2.2 Addressing of INSTANT INBOXes . . . . . . . . . . . . . . 5
2.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . 5
2.2.1.1 Domain Name Lookup . . . . . . . . . . . . . . . . . . . . 5
2.2.1.2 Processing SRV RRs . . . . . . . . . . . . . . . . . . . . 6
2.2.1.3 Processing Multiple Addresses . . . . . . . . . . . . . . 6
2.3 Format of Instant Messages . . . . . . . . . . . . . . . . 7
2.4 The Messaging Service . . . . . . . . . . . . . . . . . . 8
2.4.1 The Message Operation . . . . . . . . . . . . . . . . . . 8
3. Abstract Presence Service . . . . . . . . . . . . . . . . 10
3.1 Overview of the Presence Service . . . . . . . . . . . . . 10
3.2 Addressing of PRESENTITIES . . . . . . . . . . . . . . . . 13
3.3 Format of Presence Information . . . . . . . . . . . . . . 14
3.4 The Presence Service . . . . . . . . . . . . . . . . . . . 15
3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 15
3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 17
3.4.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 20
5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . 20
5.2 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . 20
6. The Common Service DTD . . . . . . . . . . . . . . . . . . 21
7. The Messaging Service DTD . . . . . . . . . . . . . . . . 23
8. The Presence Service DTD . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 26
A. Issues of Interest . . . . . . . . . . . . . . . . . . . . 29
A.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . 29
A.1.1 Source-Route Mapping . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . 30
Crocker, et. al. Expires February 19, 2001 [Page 2]
Internet-Draft CPIM August 2000
1. Introduction
To achieve interoperation of IM systems that are compliant with RFC
2779[1], 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 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
behavior 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 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 IM service.
1.1 Terminology
This memos makes use of the vocabulary defined in RFC 2778[2]. Terms
such as 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 which 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.
Crocker, et. al. Expires February 19, 2001 [Page 3]
Internet-Draft CPIM August 2000
2. Abstract 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' />
Crocker, et. al. Expires February 19, 2001 [Page 4]
Internet-Draft CPIM August 2000
2.2 Addressing of INSTANT INBOXes
An INSTANT INBOX is specified using the IM URI (Section 5.1) scheme.
Briefly, the "addr-spec" syntax of RFC 822[3] (i.e., "local@domain")
is used, where the local-part MUST be interpreted and assigned
semantics only by the host specified in the domain part of the
address.
2.2.1 Address Resolution
A client determines the address of an appropriate host running a
server by resolving a destination domain name to either an
intermediate relay host or a final target host.
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[4] or A RRs).
2.2.1.1 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[5]. 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; otherwise, 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
host.
Crocker, et. al. Expires February 19, 2001 [Page 5]
Internet-Draft CPIM August 2000
2.2.1.2 Processing SRV RRs
To process an IM URI, a lookup is performed for SRVs for the target
domain and a desired IM transport protocol.
For example, if the destination INSTANT INBOX is
"im:fred@example.com", and the sender wishes to use an IM transport
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 transport 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 seperate RR for a gateway must be
present for each transport protocol and domain pair that it serves.
2.2.1.3 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 host addresses: multiple SRV records, and multihomed
hosts.
Multiple SRV records contain a preference indication that MUST be
used in sorting. Lower numbers are preferrable 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 host (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.
Crocker, et. al. Expires February 19, 2001 [Page 6]
Internet-Draft CPIM August 2000
2.3 Format of Instant Messages
An INSTANT MESSAGE comprises a MIME[6] content.
Note that the IETF provides numerous technologies that allow
end-users to exchange authenticated and private messages formatted
as MIME objects, c.f., PGP-MIME[7] and S/MIME[8].
Crocker, et. al. Expires February 19, 2001 [Page 7]
Internet-Draft CPIM August 2000
2.4 The Messaging Service
Section 6 and Section 7 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:
o the source parameter specifies the INSTANT INBOX on whose behalf
this message is sent (using an IM URI);
o the destination parameter specifies the INSTANT INBOX that the
message should be delivered to (using an IM URI);
o the transID parameter specifies the transaction-identifier
associated with this operation; and,
o the message to be sent.
Crocker, et. al. Expires February 19, 2001 [Page 8]
Internet-Draft CPIM August 2000
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:
1. If the service is able to successfully deliver the message,
a response operation having status "success" is invoked.
2. If the service is unable to successfully deliver the
message, a response operation having status "failure" is
invoked.
3. 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.
4. 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.
Crocker, et. al. Expires February 19, 2001 [Page 9]
Internet-Draft CPIM August 2000
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.
Crocker, et. al. Expires February 19, 2001 [Page 10]
Internet-Draft CPIM August 2000
If the response operation indicates success, then for up to the
specified duration, the service invokes the notify operation
whenever there are any changes to the PRESENTITY's presence
information, 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 zero-valued, 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' />
Crocker, et. al. Expires February 19, 2001 [Page 11]
Internet-Draft CPIM August 2000
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' />
Crocker, et. al. Expires February 19, 2001 [Page 12]
Internet-Draft CPIM August 2000
3.2 Addressing of PRESENTITIES
A PRESENTITY is specified using the PRES URI (Section 5.2) scheme.
Briefly, the "addr-spec" syntax of RFC 822[3] (i.e., "local@domain")
is used, where the local-part MUST be interpreted and assigned
semantics only by the host specified in the domain part of the
address.
To resolve addresses associated with the Presence service, the
mechanism defined in Section 2.2.1 is used, except that the
processing of a PRES URI is performed by looking up SRV RRs for a
desired presence transport protocol.
For example, if the destination PRESENTITY is
"pres:fred@example.com", and the sender wishes to use a presence
transport protocol called "PEPP", then a SRV lookup is performed for:
_pres._pepp.example.com.
Crocker, et. al. Expires February 19, 2001 [Page 13]
Internet-Draft CPIM August 2000
3.3 Format of Presence Information
Section 8 defines the abstract syntax for presence information using
an XML DTD. Note that this memo does not require that XML be used
between the application and the service. Accordingly, each IM system
must define how well-formed presence information is encoded in
transit.
Each PRESENTITY's presence information contains an "entityInfo"
attribute, and contains one or more "tuple" elements:
o the "entityInfo" attribute specifies arbitrary information about
the PRESENTITY (using a URI); and,
o each "tuple" element specifies information associated with the
PRESENTITY.
Each "tuple" element has a "destination" attribute, a "status"
attribute, and contains arbitrary content:
o the "destination" attribute specifies a URI;
o the "status" attribute is either OPEN or CLOSED; and,
o the content of the "tuple" element contains arbitrary information
about the tuple.
Crocker, et. al. Expires February 19, 2001 [Page 14]
Internet-Draft CPIM August 2000
3.4 The Presence Service
Section 6 and Section 8 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:
o the watcher parameter specifies the WATCHER associated with the
subscription;
o the target parameter specifies the PRESENTITY associated with the
presence information;
o the duration parameter specifies the maximum number of seconds
that the SUBSCRIPTION should be active; and,
o the transID parameter specifies the transaction-identifier
associated with this operation.
Crocker, et. al. Expires February 19, 2001 [Page 15]
Internet-Draft CPIM August 2000
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:
1. 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.)
2. A notify operation, corresponding to the target's presence
information, is immediately invoked for the watcher.
3. 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.
Crocker, et. al. Expires February 19, 2001 [Page 16]
Internet-Draft CPIM August 2000
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:
o the watcher parameter specifies the WATCHER associated with the
subscription;
o the target parameter specifies the PRESENTITY associated with the
presence information;
o the transID parameter specifies the transaction-identifier
associated with this operation; and,
o the presence information for the PRESENTITY.
There is no application response to the notify operation.
Crocker, et. al. Expires February 19, 2001 [Page 17]
Internet-Draft CPIM August 2000
3.4.3 The Unsubscribe Operation
When an application wants to terminate a subscription, it invokes
the unsubscribe operation.
The unsubscribe operations has these parameters:
o the watcher parameter specifies the WATCHER associated with the
subscription;
o the target parameter specifies the PRESENTITY associated with the
presence information; and,
o the transID parameter specifies the transaction-identifier
associated with a subscription.
When the service is informed of the unsubscribe operation, it
performs these steps:
1. If the wather and target parameters do not refer to an
in-progress subscribe operation for the application, a response
operation having status "failure" is invoked.
2. Otherwise, the in-progress subscribe operation for the
application is terminated, and a response operation having
status "success" is invoked by the service.
Note that following a successful unsubscribe operation, the WATCHER
may receive further notifications. Although the service will no
longer invoke the notify operation after successfully processing a
unsubscribe operation, earlier notify operations may still be in
progress.
Crocker, et. al. Expires February 19, 2001 [Page 18]
Internet-Draft CPIM August 2000
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 for
IM systems.
Crocker, et. al. Expires February 19, 2001 [Page 19]
Internet-Draft CPIM August 2000
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.
Crocker, et. al. Expires February 19, 2001 [Page 20]
Internet-Draft CPIM August 2000
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>
Crocker, et. al. Expires February 19, 2001 [Page 21]
Internet-Draft CPIM August 2000
Crocker, et. al. Expires February 19, 2001 [Page 22]
Internet-Draft CPIM August 2000
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>
Crocker, et. al. Expires February 19, 2001 [Page 23]
Internet-Draft CPIM August 2000
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>
Crocker, et. al. Expires February 19, 2001 [Page 24]
Internet-Draft CPIM August 2000
<!--
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>
Crocker, et. al. Expires February 19, 2001 [Page 25]
Internet-Draft CPIM August 2000
References
[1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[3] Crocker, D., "Standard for the format of ARPA Internet text
messages", RFC 822, STD 11, Aug 1982.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[5] Mockapetris, P.V., "Domain names - concepts and facilities",
RFC 1034, STD 13, Nov 1987.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[7] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[8] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
2632, June 1999.
[9] Allocchio, C., "GSTN Address Element Extensions in E-mail
Services", RFC 2846, June 2000.
Authors' Addresses
David H. Crocker
Brandenburg Consulting
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Crocker, et. al. Expires February 19, 2001 [Page 26]
Internet-Draft CPIM August 2000
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
Content Technologies Limited
1220 Parkview
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 930 1300
EMail: gk@acm.org
Crocker, et. al. Expires February 19, 2001 [Page 27]
Internet-Draft CPIM August 2000
Marshall T. Rose
Invisible Worlds, Inc.
1179 North McDowell Boulevard
Petaluma, CA 94954-6559
US
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
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
Crocker, et. al. Expires February 19, 2001 [Page 28]
Internet-Draft CPIM August 2000
Appendix A. Issues of Interest
This appendix briefly discusses issues that may be of interest when
designing an interoperation gateway.
A.1 Address Mapping
When mapping the service described in this memo, mappings which
place special information into the IM address local part SHOULD use
the meta-syntax defined in RFC 2486[9].
A.1.1 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.
The transformation 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 preferrable to hide this mapping
from end-users -- if possible, the mapping should be performed
automatically by the underlying software.
Crocker, et. al. Expires February 19, 2001 [Page 29]
Internet-Draft CPIM August 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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
Funding for the RFC editor function is currently provided by the
Internet Society.
Crocker, et. al. Expires February 19, 2001 [Page 30]