[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                            M. Rose
Internet-Draft                              Dover Beach Consulting, Inc.
Expires: June 23, 2002                                 December 23, 2001


                       IM Simple Exchange (IMSX)
                     draft-mrose-simple-exchange-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 June 23, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The Common Presence and Instant Messaging profile (CPIM) is a set of
   syntax and semantics for instant messaging (IM) and online presence
   services, independent of the underlying transfer infrastructure.  The
   Session Initiation Protocol (SIP) negotiates session information for
   media streams.  This memo defines a BEEP profile, IMSX, for
   exchanging CPIM messages after SIP has performed signalling.









Rose                      Expires June 23, 2002                 [Page 1]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    IM Simple Exchange . . . . . . . . . . . . . . . . . . . . .  4
   2.1   The Session Model  . . . . . . . . . . . . . . . . . . . . .  4
   2.2   SDP Announcements for IMSX . . . . . . . . . . . . . . . . .  6
   2.3   SIP Interactions for IMSX  . . . . . . . . . . . . . . . . .  7
   2.4   BEEP Interactions for IMSX . . . . . . . . . . . . . . . . .  7
   2.5   Putting It All Together  . . . . . . . . . . . . . . . . . .  8
   3.    The IMSX Profile for BEEP  . . . . . . . . . . . . . . . . . 13
   3.1   Use of XML and MIME  . . . . . . . . . . . . . . . . . . . . 13
   3.2   Profile Identification and Initialization  . . . . . . . . . 14
   3.3   Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
   3.4   Message Semantics  . . . . . . . . . . . . . . . . . . . . . 15
   3.4.1 The Message Element  . . . . . . . . . . . . . . . . . . . . 15
   3.4.2 The Response Element . . . . . . . . . . . . . . . . . . . . 16
   4.    Initial Registrations  . . . . . . . . . . . . . . . . . . . 17
   4.1   Registration: The IMSX Profile . . . . . . . . . . . . . . . 17
   4.2   Registration: The System (Well-Known) TCP port number for
         IMSX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.3   Registration: The IMSX/TCP "proto" for SDP . . . . . . . . . 18
   4.4   Registration: The tuning "att-field" for SDP . . . . . . . . 18
   5.    The IMSX DTD . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 21
         References . . . . . . . . . . . . . . . . . . . . . . . . . 22
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
   B.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
   C.    Revision History . . . . . . . . . . . . . . . . . . . . . . 26
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 27





















Rose                      Expires June 23, 2002                 [Page 2]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


1. Introduction

   The Common Presence and Instant Messaging profile [1] (CPIM) is a set
   of syntax and semantics for instant messaging (IM) and online
   presence services, independent of the underlying transfer
   infrastructure.  CPIM is consistent with the requirements specified
   in RFC2779 [2], using a minimalist approach to allow the
   interoperation of a wide range of IM and presence systems.

   To support a "paging" model for IM, SIMPLE [3] defines an extension
   to the Session Initiation Protocol [4] (SIP).  SIP negotiates session
   information for media streams.  Using the SIMPLE extention, the IM
   content is piggyback'd in the SIP traffic, thereby eliminating the
   need for a separate stream for IM traffic.

   A "session" model for IM is also possible, wherein SIP performs the
   signalling necessary to negotiate the establishment of a media
   stream, which is realized by a second protocol.  This memo defines an
   "IM session" protocol for that purpose, termed the IM Simple Exchange
   (IMSX).  IMSX is realized as a BEEP profile [5].

   This memo is written with the expectation that the reader is familiar
   with the concepts presented in the CPIM, SIP, and BEEP
   specifications.



























Rose                      Expires June 23, 2002                 [Page 3]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


2. IM Simple Exchange

2.1 The Session Model

   In the "session" model, an IM application determines that it wishes
   to communicate with another IM application.  These applications,
   termed the initiating and responding applications (respectively), are
   conceptually identified using the IM URI, as specified in Section 5.1
   of [1].

   The initiating application determines that it will use IMSX to
   communicate with the responding application, so it uses the SIP URI
   for this purpose.  For example, if the IM application uses IMSX to
   communicate with an IM application identified as
   "im:barney@rubble.com" , the URI "sip:barney@rubble.com" is utilized
   for this purpose.

   The initiating application ensures that it is running a BEEP entity
   that implements the IMSX profile, and determines the transport
   information associated with the BEEP entity (typically IP address and
   TCP port number).  Then it constructs an announcement using the
   Session Description Protocol [6] (SDP), and sends the announcement in
   a SIP INVITE.  The initiating application then waits for a response.

   Ultimately, the responding application receives the invitation.  The
   responding application determines if it wishes to communicate with
   the initiating application.  If the invitation is declined, this is
   indicated a failure response code (from the 4xx, 5xx or 6xx series)
   and no further actions are taken by the responding application.

   Otherwise, the responding application ensures that it is running a
   BEEP entity that implements the IMSX profile, determines the
   transport information associated with the BEEP entity (typically IP
   address and TCP port number), and then sends its own announcement
   with a 200 response code.

   Ultimately, the initiating application receives the response and
   acknowledges it with a SIP ACK message.  If the response indicates
   failure, no further actions are taken by the initiating application.

   Otherwise, the initiating application activates its BEEP entity, and,
   using the transport information in the response, establishes a BEEP
   session.  If successful, the initiating appliation tunes the session
   as appropriate, and starts the IMSX profile.

   As with any model based on dynamic rendezvous, it is critically
   important that each application faithfully record the appropriate
   transport information in the corresponding SDP announcement.



Rose                      Expires June 23, 2002                 [Page 4]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   Note that with the introduction of middleboxes [7], such as firewalls
   and network address translators, it may be necessary for proxies to
   transparently rewrite the transport information in order to account
   for administratively-mandated media gateways or address translation.
   In a phrase, "res ipsa loquitur".














































Rose                      Expires June 23, 2002                 [Page 5]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


2.2 SDP Announcements for IMSX

   Consider this SDP announcement:

       v=0
       o=fred 2890844526 0 IN IP4 1.2.3.4
       s=example imsx session
       c=IN IP4 1.2.3.4
       t=0 0
       m=message 1024 IMSX/TCP cpim
       a=tuning:privacy

   Readers familiar with SDP will note only two new parameters, the use
   of "IMSX/TCP" as a media protocol, and the use of "tuning" as an
   attribute.

   For readers less familiar with SDP, let's examine all the information
   conveyed by this announcement:

      v=0 => The announcement conforms to version "0" of SDP.

      o=fred => The originator of the session.

      o= ...  2890844526 ...  IN IP4 1.2.3.4 => The unique
         identification of the session.

      o= ...  0 ...  => The instance-identifier for the session.

      s=example imsx session => The textual name of the session.

      c=IN IP4 1.2.3.4 / m= ...  1024 .../TCP => The transport
         information associated with the application's BEEP entity.

      t=0 0 => The (unbounded) start and stop times of the session.

      m=message ...  cpim => The media type being advertised (in this
         case "message/cpim" [8]).

      m=message ...  IMSX/TCP ...  => The protocol used to realize the
         media stream (cf., Section 4.3).

      a=tuning:privacy => The BEEP session must be tuned for privacy
         before starting the IMSX profile (cf., Section 4.4).








Rose                      Expires June 23, 2002                 [Page 6]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


2.3 SIP Interactions for IMSX

   The mechanisms defined in [4] are used directly, no changes to the
   SIP interaction model is required for IMSX.

2.4 BEEP Interactions for IMSX

   Although the SDP announcement indicates what the desired tuning for
   the BEEP session, the "greetings" exchanged by the BEEP peers
   indicate which tuning profiles are available:

      a=tuning:privacy  If tuning for privacy is requested, then the
         initiating application examines the profiles advertised in the
         responding application's greeting to see which is most
         appropriate.  This may be either:

            *  a transport security profile; or,

            *  a user authentication profile that also supports
               transport privacy.

      a=tuning:integrity  If tuning for message integrity is requested,
         then the initiating application examines the profiles
         advertised in the responding application's greeting to see
         which is most appropriate, i.e., a user authentication profile
         that also supports message integrity.

      a=tuning:authentication  If tuning for user authentication is
         requested, then the initiating application examines the
         profiles advertised in the responding application's greeting to
         see which is most appropriate.

      a=tuning:all  If tuning for user authentication, message
         integrity, and privacy is requested, then the initiating
         application examines the profiles advertised in the responding
         application's greeting to see which are most appropriate.
         These may be either:

            *  a transport security profile supporting bi-directional
               certification;

            *  a user authentication profile that also supports
               transport privacy; or,

            *  a transport security profile followed by a user
               authentication profile.





Rose                      Expires June 23, 2002                 [Page 7]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


2.5 Putting It All Together

   The IM application known as "im:fred@example.com" determines that it
   wishes to communicate with the IM application known as
   "im:barney@example.com".

   The initiating application ensures that it is running a BEEP entity
   that implements the IMSX profile, and determines that its BEEP entity
   is using IP address "1.2.3.4" and TCP port "1024".  It then sends a
   session invitation to the "sip.rubble.com" proxy.

   The invitation looks something like this:

       INVITE sip:barney@rubble.com SIP/2.0
       Via: SIP/2.0/UDP 1.2.3.4
       From: Fred <sip:fred@example.com>;tag=5567
       To: Barney <sip:barney@rubble.com>
       Call-ID: 283e0@1.2.3.4
       CSeq: 98770 INVITE
       Content-Type: application/sdp
       Content-Length: 166

       v=0
       o=fred 2890844526 0 IN IP4 1.2.3.4
       s=example imsx session
       c=IN IP4 1.2.3.4
       t=0 0
       m=message 1024 IMSX/TCP cpim
       a=tuning:none

   The initiating application then waits for a response.




















Rose                      Expires June 23, 2002                 [Page 8]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   The "sip.rubble.com" proxy forwards the session invitation to the
   responding application.  The responding application ensures that it
   is running a BEEP entity that implements the IMSX profile, and
   determines that its BEEP entity is using IP address "5.6.7.8" and TCP
   port "65535".  It then sends its response, which looks something like
   this, back to the SIP proxy:

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP sip.rubble.com
       Via: SIP/2.0/UDP 1.2.3.4
       From: Fred <sip:fred@example.com>;tag=5567
       To: Barney <sip:barney@rubble.com>;tag=998a87
       Call-ID: 283e0@1.2.3.4
       CSeq: 98770 INVITE
       Content-Type: application/sdp
       Content-Length: 166

       v=0
       o=fred 2890844526 0 IN IP4 5.6.7.8
       s=example imsx session
       c=IN IP4 5.6.7.8
       t=0 0
       m=message 65535 IMSX/TCP cpim
       a=tuning:privacy

   The responding appliation then waits for an incoming BEEP session.

   Ultimately, the initiating application receives the response to the
   session invitation.  The initiating application acknowledges the
   response, and then establishes a BEEP session using TCP from port
   "1024" on IP address "1.2.3.4" to port "65535" on IP address
   "5.6.7.8".



















Rose                      Expires June 23, 2002                 [Page 9]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   The BEEP peers begin with the traditional exchange of greetings (in
   resplendent native costume):

       L: <wait for incoming connection>
       I: <open connection>
       L: RPY 0 0 . 0 285
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/TLS' />
       L:    <profile uri='http://iana.org/beep/transient/simple/imsx' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END































Rose                      Expires June 23, 2002                [Page 10]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   Because the responding application's response indicated that tuning
   for privacy is necessary, the initiating application starts a
   transport security profile:

       I: MSG 0 1 . 52 158
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/TLS'>
       I:        <![CDATA[<ready />]]>
       I:    </profile>
       I: </start>
       I: END
       L: RPY 0 1 . 285 121
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/TLS'>
       L:     <![CDATA[<proceed />]]>
       L: </profile>
       L: END

           ... successful transport security negotiation ...

       L: RPY 0 0 . 0 238
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/transient/simple/imsx' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END














Rose                      Expires June 23, 2002                [Page 11]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   With the session tuned, the initiating application starts the IMSX
   profile for BEEP:

       I: MSG 0 1 . 52 176
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/transient/simple/imsx' />
       I: </start>
       I: END
       L: RPY 0 1 . 238 138
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/transient/simple/imsx' />
       L: END




































Rose                      Expires June 23, 2002                [Page 12]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


3. The IMSX Profile for BEEP

   Section 4.1 contains the BEEP profile registration for IMSX.

3.1 Use of XML and MIME

   Each BEEP payload exchanged via IMSX consists of an XML document and
   possibly an arbitrary MIME content.

   If only an XML document is sent in the BEEP payload, then the mapping
   to a BEEP payload is straight-forward, e.g.,

       S: RPY 1 0 . 0 81
       S: Content-Type: application/beep+xml
       S:
       S: <response status='success' />
       S: END

   Otherwise, if an arbitrary MIME content is present, it is indicated
   by a URI-reference [9] in the XML control document.  The URI-
   reference may contain an absolute-URI (and possibly a fragment-
   identifier), or it may be a relative-URI consisting only of a
   fragment-identifier.  Arbitrary MIME content is included in the BEEP
   payload by using a "multipart/related" [10], identified using a "cid"
   URL [11], and the XML control document occurs as the start of the
   "multipart/related", e.g.,

       C: MSG 1 0 . 0 1234
       C: Content-Type: multipart/related; boundary='boundary';
       C:               start='<1@example.com>';
       C:               type='application/beep+xml'
       C:
       C: --boundary
       C: Content-Type: application/beep+xml
       C: Content-ID: <1@example.com>
       C:
       C: <message source='im:fred@example.com'
       C:          destination='im:barney@example.com'
       C:          content='cid:2@example.com' />
       C: --boundary
       C: Content-Type: message/cpim
       C: Content-Transfer-Encoding: binary
       C: Content-ID: <2@example.com>
       C:
       C: ...
       C: --boundary--
       C: END




Rose                      Expires June 23, 2002                [Page 13]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   Because BEEP provides an 8bit-wide path, a "transformative" Content-
   Transfer-Encoding (e.g., "base64" or "quoted-printable") should not
   be used.  Further, note that MIME [12] requires that the value of the
   "Content-ID" header be globally unique.

   If the arbitrary MIME content is itself an XML document, it may be
   contained within the control document directly as a "data-content"
   element, and identified using a URI-reference consisting of only a
   fragment-identifier, e.g.,

       C: MSG 1 0 . 0 1234
       C: Content-Type: application/beep+xml
       C:
       C: <message source='im:fred@example.com'
       C:          destination='im:barney@example.com'
       C:          content='#Content'>
       C:     <data-content Name='Content'>
       C:         ...
       C:     </data-content>
       C: </message>
       C: END


3.2 Profile Identification and Initialization

   The IMSX is identified as:

       http://iana.org/beep/transient/simple/imsx

   in the BEEP "profile" element during channel creation.

   No elements are required to be exchanged during channel creation;
   however, the initiator may choose to piggyback its first operation,
   e.g.,

       <start number='1'>
           <profile uri='http://iana.org/beep/transient/simple/imsx'>
               <![CDATA[<message> ... </message>]]>
           </profile>
       </start>

   Note that Section 2.3.1.2 of [5] limits the amount of piggyback'd
   data to 4K octets.








Rose                      Expires June 23, 2002                [Page 14]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


3.3 Message Syntax

   Sections 6 and 7 of [1] define the abstract syntax for CPIM
   messaging.  Accordingly, Section 5 defines the IMSX payloads that are
   CPIM-conformant.

3.4 Message Semantics

   Section 2.4 of [1] defines the abstract semantics for the
   communications between an application and the IM service.  In
   contrast, IMSX is concerned with the semantics for the communications
   between two IM applications.  Accordingly, the remainder of this
   section, while similar in nature to CPIM's behavior, deals solely
   with IM exchanges between end-users.

3.4.1 The Message Element

   The "message" element has a "source" attribute, a "destination"
   attribute, a "content" attribute, and, optionally, a "data-content"
   element:

      o  the "source" attribute refers to the application sending the
         message, and contains an IM URI;

      o  the "destination" attribute refers to the application receiving
         the message, and also contains an IM URI; and,

      o  the "content" attribute is a URI-reference that specifies the
         contents of the data (cf., Section 3.1).

   Note that the "message" element does not contain SIP URIs -- the
   messages exchanged are independent of the fact that SIP is used to
   negotiate the establishment of an IMSX media stream.

   When an application receives the "message" element:

      1.  It verifies that it corresponds to the identity specified in
          the "destination" attribute, if not, it returns a "response"
          element with the "status" attribute set to "failure", and
          performs no further processing for that element.

      2.  Otherwise, it returns a "response" element with the "status"
          attribute set to "success", and performs any further
          processing in an application-specific manner.







Rose                      Expires June 23, 2002                [Page 15]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


3.4.2 The Response Element

   The "response" element has a "status" attribute, an optional
   "xml:lang" attribute, and may contain arbitrary textual content:

      o  the "status" element is either "success", "failure", or
         "indeterminant"; and,

      o  the "xml:lang" attribute, if present, specifies the language
         that the element's content is written in; and,

      o  the textual content is a diagnostic (possibly multiline) which
         is meaningful to implementers, perhaps administrators, and
         possibly even users.





































Rose                      Expires June 23, 2002                [Page 16]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


4. Initial Registrations

4.1 Registration: The IMSX Profile

      Profile Identification: http://iana.org/beep/transient/simple/imsx

      Messages exchanged during Channel Creation: message, response

      Messages starting one-to-one exchanges: message

      Messages in positive replies: response

      Messages in negative replies: none

      Messages in one-to-many exchanges: none

      Message Syntax: cf., Section 5

      Message Semantics: cf., Section 3.4

      Contact Information: cf., the "Authors' Addresses" section of this
         memo


4.2 Registration: The System (Well-Known) TCP port number for IMSX

      Protocol Number: TCP

      Message Formats, Types, Opcodes, and Sequences: Section 5

      Functions: Section 3.4

      Use of Broadcast/Multicast: none

      Proposed Name: IM Simple Exchange

      Short name: imsx

      Contact Information: cf., the "Authors' Addresses" section of this
         memo











Rose                      Expires June 23, 2002                [Page 17]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


4.3 Registration: The IMSX/TCP "proto" for SDP

      SDP Parameter Type: proto

      Registered Name: IMSX/TCP

      Long-Form Name: The IMSX profile for BEEP running over TCP

      Description: cf., this memo

      Contact Information: cf., the "Authors' Addresses" section of this
         memo


4.4 Registration: The tuning "att-field" for SDP

      SDP Parameter Type: att-field

      Registered Name: tuning

      Long-Form Name: Tuning parameters for media streams implemented
         over BEEP

      Type of Attribute: Media level

      Possible Values of Attribute: "none", "authentication",
         "integrity", "privacy", or "all".

      Description: cf., Section 2.4

      Contact Information: cf., the "Authors' Addresses" section of this
         memo



















Rose                      Expires June 23, 2002                [Page 18]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


5. The IMSX DTD

   <!--
     DTD for IMSX, as of 2001-12-19


     Refer to this DTD as:

       <!ENTITY % IMSX PUBLIC "-//IETF//DTD IMSX//EN" "">
       %IMSX;
     -->


   <!--
     include the common service DTD from CPIM (Section 6)
     -->

   <!ENTITY % IMCOMMON PUBLIC "-//IETF//DTD IM COMMON//EN" "">
   %IMCOMMON;


   <!--
     IMSX messages, exchanged as application/beep+xml

        role       MSG         RPY         ERR
       ======      ===         ===         ===
       I or L      message     reply
     -->


   <!-- cf., Section 5.1 of CPIM -->
   <!ENTITY %INBOX       "CDATA">

   <!--
     similar to the "message" element found in Section 7 of CPIM
     -->
   <!ELEMENT message     (data-content?)>
   <!ATTLIST message
             source      %INBOX;           #REQUIRED
             destination %INBOX;           #REQUIRED
             content     %URI;             #REQUIRED>

   <!ELEMENT data-content
                         ANY>
   <!ATTLIST Name        ID                #REQUIRED>






Rose                      Expires June 23, 2002                [Page 19]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


   <!--
     similar to the "response" element found in Section 6 of CPIM
     -->
   <!ELEMENT response     (#PCDATA)>
   <!ATTLIST response
             status       (success|failure|indeterminant)
                                           #REQUIRED
             xml:lang     %LANG;           #IMPLIED>











































Rose                      Expires June 23, 2002                [Page 20]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


6. Security Considerations

   Consult [1]'s Section 4 for a discussion of CPIM-specific security
   issues.  In particular, note that If authentication or
   confidentiality of individial instant messages is desired, the
   "message/cpim" format [8] is designed for this purpose.

   Consult [2]'s Section 5 for a discussion of IM-specific security
   issues.

   Consult [4]'s Section 13 for a discussion of SIP-specific security
   issues.

   Consult [6]'s Section 7 for a discussion of SDP-specific security
   issues.

   Consult [5]'s Section 9 for a discussion of BEEP-specific security
   issues.

   Although use of the tuning attribute in the SDP announcement is a
   policy matter, At a minimum, all IMSX implementations must provide
   the following tuning profiles:

        tuning value                  profile
       --------------    ------------------------------------
       authentication    http://iana.org/beep/SASL/DIGEST-MD5

            integrity    http://iana.org/beep/SASL/DIGEST-MD5

              privacy    http://iana.org/beep/TLS using the
                         TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher

                  all    http://iana.org/beep/TLS using the
                         TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher
                         and client-side certificates
















Rose                      Expires June 23, 2002                [Page 21]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


References

   [1]   Crocker, D., "Common Presence and Instant Messaging (CPIM)",
         draft-ietf-impp-cpim-02 (work in progress), November 2001.

   [2]   Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
         Presence Protocol Requirements", RFC 2779, February 2000.

   [3]   Rosenberg, J., "SIP Extensions for Instant Messaging", draft-
         ietf-simple-im-01 (work in progress), July 2001.

   [4]   Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [5]   Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.

   [6]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [7]   Rosenberg, J., Srisuresh, P., Molitor, A., Rayhan, A. and J.
         Kuthan, "Middlebox Communication Architecture and framework",
         draft-ietf-midcom-framework-06 (work in progress), December
         2001.

   [8]   Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
         Message Format", draft-ietf-impp-cpim-msgfmt-04 (work in
         progress), November 2001.

   [9]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [10]  Levinson, E., "The MIME Multipart/Related Content-type", RFC
         2387, August 1998.

   [11]  Levinson, E., "Content-ID and Message-ID Uniform Resource
         Locators", RFC 2392, August 1998.

   [12]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.









Rose                      Expires June 23, 2002                [Page 22]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Author's Address

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268
   US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us









































Rose                      Expires June 23, 2002                [Page 23]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Appendix A. Acknowledgements

   The author gratefully acknowledge the contributions of: Jon Peterson.
















































Rose                      Expires June 23, 2002                [Page 24]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Appendix B. IANA Considerations

   If the IESG approves this memo for publication, then the IANA
   registers the profile specified in Section 4.1, and selects an IANA-
   specific URI, e.g.,

       http://iana.org/beep/imsx

   The IANA registers "imsx" as a TCP port number, as specified in
   Section 4.2.

   The IANA registers "IMSX/TCP" as a SDP "proto", as specified in
   Section 4.3.

   The IANA registers "tuning" as a SDP "att-field", as specified in
   Section 4.4.



































Rose                      Expires June 23, 2002                [Page 25]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Appendix C. Revision History

   Note to RFC editor: please remove this entire appendix, and the
   corresponding entries in the table of contents, prior to publication.

   tbd...













































Rose                      Expires June 23, 2002                [Page 26]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rose                      Expires June 23, 2002                [Page 27]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/