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

Versions: 00 01

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


                       IM Simple Exchange (IMSX)
                     draft-mrose-simple-exchange-01

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 1, 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 1, 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
   C.1   Changes from draft-mrose-simple-exchange-00  . . . . . . . . 26
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 27




















Rose                      Expires June 1, 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 extension, 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 1, 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 application 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 1, 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 to rewrite the
   transport information in order to account for administratively-
   mandated media gateways or address translation.  Accordingly, SIP
   user agents are responsible for either directly rewriting the
   transport information, or, sending the SDP announcement through the
   appropriate intermediaries that will transparently rewrite the
   transport information.  In a phrase, "res ipsa loquitur".











































Rose                      Expires June 1, 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 1, 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 1, 2002                  [Page 7]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


2.5 Putting It All Together

   In the examples which follow, the following notation is used: "I"
   refers to the BEEP peer that initiates a connection, whilst "L"
   refers to the BEEP peer that listens for connections; similarly, "C"
   refers to the BEEP peer that begins an exchange, whilst "S" refers to
   the BEEP peer that responds.

   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 1, 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 application 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 1, 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 1, 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 1, 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 1, 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 1, 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.  However, the value of the
   "Content-ID" header is referenced only from within the "multipart/
   related" itself (i.e., from the multipart's "start" attribute, or
   from a "cid" URL contained within the multipart).

   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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 2002                 [Page 23]


Internet-Draft          IM Simple Exchange (IMSX)          December 2001


Appendix A. Acknowledgements

   The author gratefully acknowledge the contributions of: Rohan Mahy,
   Eamon O'Tuathail, and Jon Peterson.















































Rose                      Expires June 1, 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 1, 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.

C.1 Changes from draft-mrose-simple-exchange-00

   o  Clarified text regarding middleboxes and proxies.

   o  Added definition of "I:", "L:", "C:", and "S:".

   o  Added reminder text that "Content-ID:" headers are referenced only
      within the multipart.






































Rose                      Expires June 1, 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 1, 2002                 [Page 27]


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