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.