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

Versions: 00

Network Working Group                                     P. Saint-Andre
Internet-Draft                                 XMPP Standards Foundation
Intended status: Informational                                 E. Gavita
Expires: May 14, 2008                                         N. Hossain
                                                               S. Loreto
                                                                Ericsson
                                                       November 11, 2007


  Interworking between the Extensible Messaging and Presence Protocol
          (XMPP) and the Message Session Relay Protocol (MSRP)
                   draft-saintandre-xmpp-msrp-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 May 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a bidirectional protocol mapping for use by
   gateways that enable the exchange of messages in the context of a
   chat session between a system that implements the Extensible
   Messaging and Presence Protocol (XMPP) and a system that implements



Saint-Andre, et al.       Expires May 14, 2008                  [Page 1]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   the Session Initiation Protocol (SIP), specifically for the latter
   session-mode messages that use the Message Session Relay Protocol
   (MSRP).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Architectural Assumptions  . . . . . . . . . . . . . . . .  4
     1.3.  Connection Maintenance . . . . . . . . . . . . . . . . . .  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  6
   2.  Message Sessions . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  XMPP Formal Chat Session to MSRP . . . . . . . . . . . . .  7
       2.2.1.  Initiating a Formal Session  . . . . . . . . . . . . .  8
       2.2.2.  Accepting a Formal Session . . . . . . . . . . . . . . 11
       2.2.3.  Terminating a Formal Session . . . . . . . . . . . . . 14
       2.2.4.  Canceling the Negotiation  . . . . . . . . . . . . . . 16
       2.2.5.  Rejecting a Formal Session . . . . . . . . . . . . . . 17
     2.3.  XMPP Informal Session to MSRP  . . . . . . . . . . . . . . 18
     2.4.  MSRP to XMPP formal session  . . . . . . . . . . . . . . . 18
       2.4.1.  Initiating a Session . . . . . . . . . . . . . . . . . 19
       2.4.2.  Accepting a Session  . . . . . . . . . . . . . . . . . 22
       2.4.3.  Completing the Transaction . . . . . . . . . . . . . . 23
       2.4.4.  Send a Message . . . . . . . . . . . . . . . . . . . . 23
       2.4.5.  Terminating a Session  . . . . . . . . . . . . . . . . 24
       2.4.6.  Cancel the transaction . . . . . . . . . . . . . . . . 26
       2.4.7.  Rejecting a transaction  . . . . . . . . . . . . . . . 27
     2.5.  MSRP to an XMPP Informal Session . . . . . . . . . . . . . 28
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     4.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
     4.2.  Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 31














Saint-Andre, et al.       Expires May 14, 2008                  [Page 2]


Internet-Draft           XMPP-MSRP Interworking            November 2007


1.  Introduction

1.1.  Overview

   Within the IETF, work on instant messaging has proceeded on two
   technologies that conform to the requirements defined in [IMP-REQS]:

   o  The Extensible Messaging and Presence Protocol [XMPP], which
      consists of a formalization of the core XML streaming protocols
      developed originally by the Jabber open-source community; the
      relevant specifications are [XMPP] for the XML streaming layer and
      [XMPP-IM] for basic presence and instant messaging extensions,
      including both single messages via XMPP <message/> stanzas of type
      "normal" and messaging sessions via XMPP <message/> stanzas of
      type "chat".
   o  Various extensions to the Session Initiation Protocol [SIP] for
      instant messaging and presence, as developed within the SIP for
      Instant Messaging and Presence Leveraging Extensions (SIMPLE)
      Working Group; the relevant specifications for instant messaging
      are [SIP-MSG] for single messages (also called "pager-mode"
      messaging) and [MSRP] for messaging sessions (also called
      "session-mode" messaging).

   Because both of these technologies have been implemented and deployed
   over the Internet, it is important to clearly define bidirectional
   mappings between them.  Work on such mappings began with
   [XMPP-SIMPLE], which defines mappings for addresses, presence, and
   single messages.  This document extends that work by defining a
   mapping for one-to-one chat or messaging sessions.

   Both XMPP and SIP/SIMPLE technologies enable end users to send
   "instant messages" to other end users.  The term "instant message"
   usually refers to messages sent between two end-users for delivery in
   close to real time (rather than messages that are stored and
   forwarded to the intended recipient upon request).  Generally, there
   are three kinds of instant messages:

   1.  Single messages, which are sent from the sender to the recipient
       outside the context of any one-to-one chat session or multi-user
       text conference.  The message is immediately delivered and not
       stored in an inbox.  In XMPP a single message is a <message/>
       stanza of type "normal" as specified in [XMPP-IM].  In SIP/SIMPLE
       a single message is sent via the MESSAGE method as specified in
       [MSRP].
   2.  One-to-one chat messages, which are sent from the sender to the
       recipient (i.e., one-to-one) in the context of a "chat session"
       between the two entities.  In XMPP a chat message is a <message/>
       stanza of type "chat".  In SIP/SIMPLE a chat message is sent



Saint-Andre, et al.       Expires May 14, 2008                  [Page 3]


Internet-Draft           XMPP-MSRP Interworking            November 2007


       using an MSRP session.
   3.  Groupchat messages, which are sent from a sender to multiple
       recipients (i.e., 2 or more) in the context of a "multi-user chat
       session" or "text conference".  In XMPP a groupchat message is a
       <message/> stanza of type "groupchat" that is reflected from the
       sender to multiple recipients by a multi-user chat service as
       defined in [XEP-0045].  In SIP/SIMPLE a groupchat message is
       reflected from the sender to multiple recipients by a conference
       server that uses MSRP to handle groupchat sessions.

   This document only covers the scenario #2 above for converting XMPP
   messages of type "chat" to their corresponding SIP INVITE - MSRP
   message types on the SIP/SIMPLE side.

   As in [XMPP-SIMPLE], the approach taken here is to directly map
   syntax and semantics from one protocol to another.  One-to-one chat
   sessions using XMPP message stanzas of type "chat" are specified in
   [XMPP-IM], and a method for formally negotiating such a session is
   specified in [XEP-0155].  One-to-one chat sessions using the SIP
   MESSAGE method, the SIP INVITE method, and the Message Session Relay
   Protocol (MSRP) are specified in [SIP-MSG] and [MSRP].  In
   particular, this document defines a mapping between XMPP chat
   sessions (as specified in [XMPP-IM] and [XEP-0155]) and the Message
   Session Relay Protocol (as specified in [MSRP]).

1.2.  Architectural Assumptions

   In this section we remind the reader of the Architectural Assumptions
   already presented in [XMPP-SIMPLE], with some small changes necessary
   to support the MSRP scenario.

   XMPP IM technologies consist of three element types: Clients, Servers
   and Gateways.  Each client can source and sink messages.  Each Server
   relays messages between Clients and from/to Gateways and handles
   presence information.  The Gateway provides transformations between
   XMPP and other IM protocols.

   SIP/SIMPLE technologies employ four element types: Clients, Proxies,
   Presence Servers and Gateways.  Each Client can source and sink
   messages.  A Proxy server relays messages between Clients and/or
   Gateways.  SIMPLE defines separable Presence Servers to maintain
   presence about Client users.  Gateways provide transformations
   between SIMPLE and other IM protocols.

   Protocol mapping between XMPP and SIP SIMPLE may occur in a number of
   different entities, depending on the architecture of messaging
   deployments.  For instance, protocol translation could occur within a
   multi-protocol server, within a multi-protocol client, or within a



Saint-Andre, et al.       Expires May 14, 2008                  [Page 4]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   gateway that acts as a dedicated protocol translator.  This document
   assumes that the protocol translation will occur within a gateway.
   Specifically, we assume that the protocol translation will occur
   within an "XMPP-to-MSRP gateway" that translates XMPP syntax and
   semantics on behalf of an XMPP service when communicating with SIP
   SIMPLE services and/or within an "MSRP-to-XMPP gateway" that
   translates SIP syntax and semantics on behalf of a SIP SIMPLE service
   when communicating with XMPP services.

   We further assume that protocol translation will occur within a
   gateway in the source domain, so that messages and presence
   information generated by the user of an XMPP service will be
   translated by a gateway within the trust domain of that XMPP service,
   and messages and presence information generated by the user of an
   MSRP service will be translated by a gateway within the trusted
   domain of that MSRP service.

   An architectural diagram for a typical gateway deployment is shown
   below, where the entities have the following significance and the "#"
   character is used to show the boundary of a trusted domain:

   o  juliet@example.com -- an XMPP user.
   o  example.com -- a XMPP service.
   o  x2m.example.com -- an XMPP-to-MSRP gateway.
   o  romeo@example.net -- an MSRP user.
   o  example.net -- an MSRP service.
   o  m2x.example.net -- an MSRP-to-XMPP gateway.

   #####################################################################
   #                               #                                   #
   #         +-- m2x.example.net---#------------- example.com          #
   #         |                     #              |      |             #
   #  example.net------------------#--- x2m.example.com  |             #
   #       |                       #                     |             #
   #       |                       #                     |             #
   #  romeo@example.net            #              juliet@example.com   #
   #                               #                                   #
   #####################################################################

1.3.  Connection Maintenance

   XMPP makes use of long-lived TCP connections.  If mobility affecting
   Layer 3 causes a dropped connection, the connection must be re-
   established.  If mobility preserves the IP address, the TCP
   connection will be dropped.  Any TLS session and SASL associations
   must be re-established if the TCP connection is dropped.  XMPP binds
   directly to TCP in the core specification, so the TCP session must
   remain open for the entire duration of the chat/conversation.  The



Saint-Andre, et al.       Expires May 14, 2008                  [Page 5]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   XMPP Standards Foundation does define protocol extensions enabling
   transport of XMPP traffic over HTTP (refer to [XEP-0124] and
   [XEP-0206]), so that individual messages are carried using HTTP and
   are more robust in environments such as mobile networks, allowing for
   better recovery if a TCP session is broken.

   SIMPLE is similar when using MSRP.  The Message Session Relay
   Protocol [MSRP] is a protocol for transmitting instant messages (IM)
   in the context of a session.  The protocol specification describes
   how the session can be negotiated and established with an offer or
   answer [OFFER] using the Session Description Protocol [SDP].  In
   SIMPLE, this exchange is carried using SIP as the signaling protocol.
   After the TCP connection is established, if it fails for any reason,
   then an MSRP endpoint MAY choose to re-create such session using a
   new SDP exchange in a SIP re-INVITE.  SIMPLE also uses MESSAGE
   request for transporting instant messaging outside the context of a
   session.  The MESSAGE request is sent inside the signaling path
   without establishing any dedicate connection.

1.4.  Terminology

   This document inherits terminology from [MSRP], [SIP], [XMPP], and
   [XMPP-IM].

   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [TERMS].

1.5.  Acknowledgements

   Some text in this document was borrowed from [XMPP-SIMPLE] and from
   [XEP-0155].


2.  Message Sessions

2.1.  Overview

   The traditional model for one-to-one chat "session" in Jabber/XMPP is
   for a user to simply send a message to a contact with a thread ID,
   but without any formal negotiation of session parameter.

   This informal approach to session initiation in XMPP can be mapped
   both to SIP pager-mode messaging using the SIP MESSAGE method (as
   documented in [XMPP-SIMPLE]) and to a MSRP chat session.  How the
   Gateway chooses to map the XMPP chat session in the SIP side is a
   matter of the implementation.



Saint-Andre, et al.       Expires May 14, 2008                  [Page 6]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   However, in XMPP it also possibile to formally request a chat session
   and negotiate its parameters (e.g., security, privacy, message
   logging) before beginning the session.  The protocol for doing so is
   defined in [XEP-0155].  In this case, the XMPP chat session should be
   translated into a MSRP session.

   This document covers the mapping of both informal and formally-
   negotiated XMPP chat session into a MSRP session.

2.2.  XMPP Formal Chat Session to MSRP

   XMPP Protocol offers two ways an XMPP user can initiate a 1-1 chat:
   the first approach doesn't establish a session (this method is
   referred to the "informal session" approach); the second approach
   instead involves explicit negotiation of a session (this method is
   referred to the "formal session" approach).

   This section describes how to map an XMPP "formal session" to an MSRP
   session.

   The XMPP formal session is based on the protocol described in
   [XEP-0155], which enable the initiation, renegotiation, and
   termination of a format chat session on the XMPP side.  This approach
   maps to the semantic of the SIP INVITE and BYE methods.



























Saint-Andre, et al.       Expires May 14, 2008                  [Page 7]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   XMPP User                   X2M GW                    SIP User
       |                          |                          |
       |(F1) (XMPP) Stanza session request                   |
       |------------------------->|                          |
       |                          |(F2) (SIP) INVITE         |
       |                          |------------------------->|
       |                          |(F3) (SIP) 200 OK         |
       |                          |<-------------------------|
       |(F4) (XMPP) Stanza session acceptance                |
       |<-------------------------|                          |
       |                          |(F5) (SIP) ACK            |
       |                          |------------------------->|
       |(F6) (XMPP) Stanza session completion                |
       |------------------------->|                          |
       |                          |(F7) (MSRP) SEND          |
       |                          |------------------------->|
       |(F8) (XMPP) Stanza session termination               |
       |------------------------->|                          |
       |                          |(F9) (SIP) BYE            |
       |                          |------------------------->|
       |                          |(F10) (SIP) 200 OK        |
       |                          |<-------------------------|
       |(F11) (XMPP) Stanza acknoledgment                    |
       |             session termination                     |
       |<-------------------------|                          |

2.2.1.  Initiating a Formal Session

   When the XMPP user ("Juliet") wants to initiate a negotiated session
   with a SIP user ("Romeo"), she sends a <message/> stanza to Romeo
   containing a <feature/> child qualified by the
   'http://jabber.org/protocol/feature-neg' namespace.  The <message/>
   stanza must not contain a <body/< child (as specified in [XMPP-IM]),
   since thhat child element is used for human-readable text.  The
   <message/> stanza type should be "normal".  The stanza must contain a
   <thread/> element for tracking purposes (where the newly-generated
   ThreadID is unique to the proposed session).  The encapsulated data
   form shall contain a FORM_TYPE field whose type is "hidden" and whose
   value is "urn:xmpp:ssn"; it must also contain a boolean field named
   "accept".

   The XMPP user may request a session with a specific resource of the
   contact.  However in this document the resource identifier will be
   ignored and discarded for cross-system interworking.







Saint-Andre, et al.       Expires May 14, 2008                  [Page 8]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F1) Juliet starts a formal session:

   <message type='normal'
           from='juliet@example.com'
           to='romeo@example.net'>
    <thread>711609sa</thread>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
     <x xmlns='jabber:x:data' type='form'>
      <title>Open chat with Juliet?</title>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:ssn</value>
      </field>
      <field label='Accept this session?' type='form' var='accept'>
        <value>true</value>
        <required/>
      </field>
      <field label='Primary written language of the chat'
        type='list-single' var='language'>
         <value>en</value>
         <option label='English'><value>en</value></option>
         <option label='Italiano'><value>it</value></option>
      </field>
     </x>
   </feature>
   </message>

   Upon receiving such a session request, the XMPP server to which
   Juliet has authenticated attempts to deliver the request to a local
   user or attempts to route the request to the foreign domain that
   services the hostname in the 'to' attribute.  Naturally, in this
   document we assume that the hostname in the 'to' attribute is an IM-
   aware SIP service hosted by a separate server.

   As specified in [XMPP-IM], the XMPP server needs to determine the
   identity of the foreign domain, which it does by performing one or
   more [DNS-SRV] lookups.  For message stanzas, the order of lookups
   recommended by [XMPP-IM] is to first try the "_xmpp-server" service
   as specified in [XMPP] and to then try the "_im" service as specified
   in [IMP-SRV].  Here we assume that the first lookup will fail but
   that the second lookup will succeed and return a resolution
   "_im._simple.example.net.", since we have already assumed that the
   example.net hostname is running a SIP instant messaging service.
   (Note: The XMPP server may have previously determined that the
   foreign domain is a SIMPLE server, in which case it would not need to
   perform the SRV lookups; the caching of such information is a matter
   of implementation and local service policy, and is therefore out of
   scope for this document.)




Saint-Andre, et al.       Expires May 14, 2008                  [Page 9]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Once the XMPP server has determined that the foreign domain is
   serviced by a SIMPLE server, it must determine how to proceed.  We
   here assume that the XMPP server contains or has available to it an
   XMPP-MSRP gateway.  The XMPP server would then deliver the message
   stanza to the XMPP-MSRP gateway.

   The XMPP-MSRP gateway is then responsible for translating the XMPP
   session into an MSRP session.

   Example: (F2) Juliet starts a formal session (SIP transformation):

   INVITE sip:romeo@example.net SIP/2.0
   To: <sip:romeo@example.net>
   From: <sip:juliet@example.com>;tag=786
   Subject: Open chat with Juliet?
   Call-ID: 711609sa
   Content-Type: application/sdp

   c=IN IP4 x2m.example.com
   m=message 7654 TCP/MSRP *
   a=accept-types:text/plain
   a=lang:en
   a=lang:it
   a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp

   There is no direct mapping for the MSRP URIs.  In fact MSRP URIs
   identify a session of instant message at a particular device; they
   are ephemeral and have not meaning outside the scope of that session.
   The authority component of the MSRP URI MUST contain the XMPP-MSRP
   gateway hostname or numeric IP address and an explicit port number.

   Native XMPP supports text (i.e., UTF-8) only, so the "accept-types"
   attribute that follows an MSRP media line MUST indicate text/plain as
   the only media-type that is acceptable to the endpoint.

   As specified in [XMPP-SIMPLE], the mapping of XMPP syntax elements to
   SIP and SDP syntax elements SHOULD be as shown in the following
   table.  (Mappings for elements not mentioned are undefined).













Saint-Andre, et al.       Expires May 14, 2008                 [Page 10]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Table 1: Message syntax mapping from XMPP to SIP/SDP

   +-----------------------------+-----------------------------+
   |  XMPP Element or Attribute  |  SIP Header or SDP Contents |
   +-----------------------------+-----------------------------+
   |  <thread/>                  |  Call-ID                    |
   |  from                       |  From                       |
   |  to                         |  To                         |
   |  <title/>                   |  Subject                    |
   |  xml:lang                   |  a=lang:<language tag>      |
   |  -                          |  a=accept-types:text/plain  |
   +-----------------------------+-----------------------------+

2.2.2.  Accepting a Formal Session

   The SIP user agent Romeo receiving the SIP invitation, containing an
   offered session description that includes a session of MSRP, accepts
   the invitation and includes an answer session description that
   acknowledges the choice of media.

   Example: (F3) Romeo accepts the request

   SIP/2.0 200 OK
   To: <sip:romeo@example.net>;tag=087js
   From: <sip:juliet@example.com>;tag=786
   Call-ID: 711609sa
   Content-Type: application/sdp

   c=IN IP4 example.net
   m=message 12763 TCP/MSRP *
   a=accept-types:text/plain
   a=lang:it
   a=path:msrp://example.net:12763/kjhd37s2s20w2a;tcp

   Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember
   that this is a response to a SIP transaction related to an XMPP-MSRP
   translation.  The gateway is responsible for translating the response
   into an XMPP message stanza and deliver it from the SIP user back to
   the XMPP user deliver.

   The MSRP-XMPP gateway MUST include in the response translation values
   for all the fields that the XMPP request indicated are required.









Saint-Andre, et al.       Expires May 14, 2008                 [Page 11]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F4) Romeo accepts the request (XMPP translation)

   <message type='normal'
            from='romeo@example.net'
            to='juliet@example.com'>
     <thread>711609sa</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>true</value></field>
         <field var='language'><value>it</value></field>
       </x>
     </feature>
   </message>

   The gateway MUST also send a SIP ACK to the SIP user.

   Example: (F5) The GW sends the ACK to Romeos UA:

   ACK sip:romeo@example.com SIP/2.0
   To: <sip:romeo@example.net>;tag=087js
   From: <sip:juliet@example.com>;tag=786
   Call-ID: 711609sa

   If Romeo accepted the session Juliet MUST either complete or cancel
   the stanza session negotiation.  The user's client SHOULD verify that
   the selected values of the fields are acceptable before completing
   the stanza session negotiation -- and confirming that the session is
   open -- by replying with the form 'type' attribute set to 'result'.
   The form MUST contain the FORM_TYPE field and the "accept" field set
   to "1" or "true".  The user MAY include other content "e.g., a
   <body/> element in the confirmation stanza:

















Saint-Andre, et al.       Expires May 14, 2008                 [Page 12]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F6) Juliet completes negotiation, confirms session is open
   and send a message.

   <message type='normal'
            from='juliet@example.com'
            to='romeo@example.net'>
     <thread>711609sa</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='result'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>true</value></field>
       </x>
     </feature>
   </message>

   Upon receiving such stanza completing the session negotiation, the
   XMPP server MUST not send any confirmation to the SIP side.

   The XMPP-MSRP gateway must create a transaction identifier and use
   this and the SEND method to create an MSRP request start line.

   The XMPP 'id' attribute is not required in the protocol and there is
   not a way to enforce its use for messages.  It is RECOMMENDED to add
   it as a negotiable item in the XEP-0155, however it may not be
   present within the <message/> stanza, in this case the XMPP-MSRP MUST
   generate a new unique Message-ID.

   Note: If the XMPP user has not explicitly requested message receipts
   during the negotiation, it is RECOMMENDED that the XMPP-MSRP inserts
   a Failure-Report header field value of "no" during the creation of a
   SEND request.  The XMPP user can include the requested for message
   receipts using the Message Receipts XMPP protocol extension
   [XEP-0184].

   As specified in [XMPP-SIMPLE], the mapping of XMPP syntax elements to
   MSRP syntax elements SHOULD be as shown in the following table.
   (Mappings for elements not mentioned are undefined).












Saint-Andre, et al.       Expires May 14, 2008                 [Page 13]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Table 2: Message syntax mapping from XMPP Message to MSRP

   +-----------------------------+-----------------------------+
   |  XMPP Element or Attribute  |  MSRP Header                |
   +-----------------------------+-----------------------------+
   |  to                         |  To-Path                    |
   |  from                       |  From-Path                  |
   |  <body/>                    |  body of the SEND request   |
   |  -                          |  Content-Type: text/plain   |
   |  id                         |  Message-ID                 |
   +-----------------------------+-----------------------------+

   Upon receiving the SEND request, if the request either contains a
   Failure-Report header field value of "yes" or does not contain a
   Failure-Report header at all, Alice's client MUST immediately
   generate and send a response.

   MSRP d93kswow 200 OK
   To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp
   -------d93kswow$

   The XML character data of an XMPP message is not limited by the
   protocol, but is sometimes limited in deployment.  However messages
   sent using MSRP can be delivered in several SEND requests, so when
   the XMPP-MSRP gateway receives a message longer then 2048, it is
   STRONGLY RECOMMENDED it delivers this message using as few chunks (at
   least 2048 octets long) as possible.

2.2.3.  Terminating a Formal Session

   If Juliet decides to terminate the negotiated chat session, her
   client sends a <message/> stanza to Romeo containing a data form of
   type "submit".  The <message/> stanza MUST contain a <thread/>
   element with the same XML character data as the original initiation
   request.  The data form containing a boolean field named "terminate"
   set to a value of "1" or "true".














Saint-Andre, et al.       Expires May 14, 2008                 [Page 14]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F8) Juliet terminates the chat session

   <message type='normal'
            from='juliet@example.com'
            to='romeo@example.net'>
     <thread>711609sa</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='terminate'><value>1</value></field>
       </x>
     </feature>
   </message>

   Upon receiving such stanza terminating the chat session, the gateway
   terminates the SIP session by sending a SIP BYE to tear down the MSRP
   session with Romeo's client.  Romeo's SIP client then responds with a
   200 OK.

   Example: (F9) Juliet terminates the chat session (SIP translation)

   BYE romeo@example.com sip: SIP/2.0
   Max-Forwards: 70
   From: <sip:juliet@example.com>;tag=786
   To: <sip:romeo@example.net>;tag=087js
   Call-ID: 711609sa
   Cseq: 1 BYE
   Content-Length: 0

   Example: (F10) Romeo terminates the chat session

   SIP/2.0 200 OK
   From: <sip:juliet@example.com>;tag=786
   To: <sip:romeo@example.net>; tag=087js
   Call-ID: 711609sa
   CSeq: 1 BYE
   Content-Length: 0

   Upon receiving the 200 OK, the GW acknowledges the termination of the
   chat session on the XMPP side by sending a <message/> containing a
   data form of type "result", and the value of the "terminate" field
   set to "1" or "true".  The client must mirror the <thread/> value it
   received.






Saint-Andre, et al.       Expires May 14, 2008                 [Page 15]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F11) Romeo terminates the chat session (XMPP translation)

   <message type='normal'
            from='romeo@example.net'
            to=='juliet@example.com'>
    <thread>711609sa</thread>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE'>
          <value>urn:xmpp:ssn</value>
        </field>
        <field var='terminate'><value>1</value></field>
        </x>
    </feature>
   </message>

2.2.4.  Canceling the Negotiation

   XMPP User                   X2M GW                    SIP User
       |                          |                          |
       |(F1) (XMPP) Stanza session request                   |
       |------------------------->|                          |
       |                          |(F2) (SIP) INVITE         |
       |                          |------------------------->|
       |                          |(F3) (SIP) 200 OK         |
       |                          |<-------------------------|
       |(F4) (XMPP) Stanza session acceptance                |
       |<-------------------------|                          |
       |                          |(F5) (SIP) ACK            |
       |                          |------------------------->|
       |(F6) (XMPP) Stanza session canceling                 |
       |------------------------->|                          |
       |                          |(F7) (SIP) BYE            |
       |                          |------------------------->|
       |                          |(F8) (SIP) 200 OK         |
       |                          |<-------------------------|

   If Romeo accepted the session, but Juliet decides to cancel the
   stanza session negotiation, the client must reply with a data form
   containing the FORM_TYPE field and the "accept" field set to "0" or
   "false":










Saint-Andre, et al.       Expires May 14, 2008                 [Page 16]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F6) User cancels stanza session negotiation

   <message type='normal'
            from='juliet@example.com'
            to='romeo@example.net'>
    <thread>711609sa</thread>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE'>
          <value>urn:xmpp:ssn</value>
        </field>
        <field var='accept'><value>0</value></field>
       </x>
     </feature>
   </message>

   Upon receiving such stanza canceling the session negotiation, the
   XMPP-MSRP Gateway MUST send a SIP BYE.  Once the XMPP-MSRP receives
   the 200 OK, the internal session data is removed and the session is
   officially canceled also in the gateway.

2.2.5.  Rejecting a Formal Session

   XMPP User                   X2M GW                    SIP User
       |                          |                          |
       |(F1) (XMPP) Stanza session request                   |
       |------------------------->|                          |
       |                          |(F2) (SIP) INVITE         |
       |                          |------------------------->|
       |                          |(F3) (SIP) 4xx/6xx        |
       |                          |<-------------------------|
       |(F4) (XMPP) Stanza session decline                   |
       |<-------------------------|                          |

   A common scenario occurs when the SIP UA is currently not willing or
   able to accept a formal session.  The SIP UA declining an offer
   contained in an INVITE SHOULD return a 4xx or a 6xx response.  Such
   response SHOULD include a Warning header field value explaining why
   the offer was rejected.

   Upon receiving the error response for the SIP INVITE, the XMPP-MSRP
   GW will send back a "Session Reject" message back to the XMPP Client.
   The data form MUST contain the FORM_TYPE field and the "accept" field
   set to "0" or "false".  It is reccomended that the form does not
   contain any other field even if the request indicated they are
   required.  The client MAY include a reason in the <body/> child of
   the <message/> stanza.




Saint-Andre, et al.       Expires May 14, 2008                 [Page 17]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   The content of the Warning header field present in the SIP response
   SHOULD be copied in the <body/> child of the <message/> stanza.  If
   the Warning header it is not present then the descriptive phrase of
   the SIP response can be used.

   Example: (F4) User declines offer and specifies reason

   <message type='normal'
            from='romeo@example.net'
            to='juliet@example.com'>
     <thread>711609sa</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>0</value></field>
       </x>
     </feature>
   </message>

2.3.  XMPP Informal Session to MSRP

   The "informal session" approach is to simply send someone a <message
   type='chat'/> without start any session negotiation before (as
   described in [XMPP-IM]).  The XMPP "informal session" approach maps
   very well into a SIP MESSAGE request, as described in [XMPP-SIMPLE].
   Although the mapping to a SIP Message is straightforward, it is also
   possible to map an informal session to an MSRP session.  The mapping
   will be provided in a future version of this specification.

2.4.  MSRP to XMPP formal session

   Unlike the XMPP protocol, the MSRP protocol only offers one way to
   initiate a Chat session, that is typically initiated using the
   Session Description Protocol [SDP] via the SIP offer/answer mechanism
   [OFFER].

   This section will describe how to map a MSRP Chat session to either a
   formal or informal XMPP session.











Saint-Andre, et al.       Expires May 14, 2008                 [Page 18]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   SIP User                  M2X GW                    XMPP User
      |                         |                          |
      |(F1)(SIP) INVITE         |                          |
      |------------------------>|                          |
      |                         |(F2)(XMPP) Stanza session request
      |                         |------------------------->|
      |                         |(F3)(XMPP) Stanza session acceptance
      |                         |<-------------------------|
      |(F4)(SIP) 200 OK         |                          |
      |<------------------------|                          |
      |(F5)(SIP) ACK            |                          |
      |------------------------>|                          |
      |                         |(F6)(XMPP) Stanza session completion
      |                         |------------------------->|
      |(F7)(MSRP) SEND          |                          |
      |------------------------>|                          |
      |                         |(F8)(XMPP) Stanza message |
      |                         |------------------------->|
      |(F9)(SIP) BYE            |                          |
      |------------------------>|                          |
      |                         |(F10)(XMPP) Stanza session termination
      |                         |------------------------->|
      |                         |(F11)(XMPP) Stanza acknowledgment
      |                         |            session termination
      |                         |<-------------------------|
      |(F12)(SIP) 200 OK        |                          |
      |<------------------------|                          |

2.4.1.  Initiating a Session

   When Romeo wants to start an MSRP message session with Juliet, he
   first has to start the SIP session by sending out a SIP INVITE
   request containing an offered session description that includes an
   MSRP media line accompanied by a mandatory "path" attribute and
   corresponding URIs.  The MSRP media line is also accompanied by an
   "accept-types" attribute used to specify the only media-types
   acceptable for Romeo (i.e., text/plain).

   In addition to plain text messages, MSRP is able to carry arbitrary
   (binary) Multipurpose Internet Mail Extensions [MIME] compliant
   content, such as images or video clips.










Saint-Andre, et al.       Expires May 14, 2008                 [Page 19]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F1) SIP user starts the session:

   INVITE sip:juliet@example.com SIP/2.0
   To: <sip:juliet@example.com>
   From: <sip:romeo@example.net>;tag=576
   Subject: Open chat with Romeo?
   Call-ID: 742507no
   Content-Type: application/sdp

   c=IN IP4 example.net
   m=message 7313 TCP/MSRP *
   a=accept-types:text/plain
   a=lang:en
   a=lang:it
   a=path:msrp://example.net:7313/ansp71weztas;tcp

   Upon receiving the INVITE, the MSRP-XMPP gateway needs to determine
   the identity of the foreign domain, which it does by performing one
   or more DNS SRV lookups [DNS-SRV].  The gateway SHOULD resolve the
   address present in the To header of the INVITE to an im, then follow
   the rules in [IMP-SRV] regarding the "_im" SRV service for the target
   domain contained in the To header.  If SRV address resolution fails
   for the "_im" service, the gateway MAY attempt a lookup for the
   "_xmpp-server" service as specified in [XMPP] or MAY return an error
   to the sender (i.e. 502 Bad Gateway).

   If SVR address resolution succeeds, the gateway is responsible for
   translating the request into an XMPP message stanza to initiate a
   negotiated session from the SIP user to the XMPP user.






















Saint-Andre, et al.       Expires May 14, 2008                 [Page 20]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F2) SIP user starts the session (XMPP transformation):

   <message type='normal'
           from='romeo@example.net'
           to='juliet@example.com'>
     <thread>742507no</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='form'>
         <title>Open chat with Romeo?</title>
         <field var='FORM_TYPE' type='hidden'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field label='Accept this session?' type='form' var='accept'>
           <value>true</value>
           <required/>
         </field>
         <field label='Primary written language of the chat'
                type='list-single'
                var='language'>
           <value>en</value>
           <option label='English'><value>en</value></option>
           <option label='Italiano'><value>it</value></option>
         </field>
       </x>
     </feature>
   </message>

   The mapping of SIP and SDP syntax elements to XMPP syntax elements
   SHOULD be as shown in the following table.  (Mappings for elements
   not mentioned in the foregoing table are undefined).

   Table 3: Message syntax mapping from SIP to XMPP

   +-----------------------------+-----------------------------+
   |  SIP Header or SDP Contents |  XMPP Element or Attribute  |
   +-----------------------------+-----------------------------+
   |  Call-ID                    |  <thread/>                  |
   |  From                       |  from                       |
   |  To                         |  to                         |
   |  Subject                    |  <title/>                   |
   |  accept-types               |  -                          |
   |  a=lang                     |  xml:lang                   |
   |  To                         |  to                         |
   +-----------------------------+-----------------------------+







Saint-Andre, et al.       Expires May 14, 2008                 [Page 21]


Internet-Draft           XMPP-MSRP Interworking            November 2007


2.4.2.  Accepting a Session

   If the request is accepted then Juliets client MUST include all the
   fields that were marked as required in the request message.

   In the example below, we assume that Juliet accepts the session and
   specifies that she prefers to speak Italian with Romeo.

   Example: (F3) Juliet accepts session and specifies parameters:

   <message type='normal'
            from='juliet@example.com'
            to='romeo@example.net'>
     <thread>742507no</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>true</value></field>
         <field var='language'><value>it</value></field>
       </x>
     </feature>
   </message>

   Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember
   that this is a response to a stanza related to an MSRP-XMPP
   translation.  The gateway is responsible for translating the response
   into a SIP response and deliver it from the XMPP user back to the SIP
   user.

   Example: (F4) Juliet accepts session (SIP translation)

   SIP/2.0 200 OK
   To: <sip:juliet@example.com>;tag=534
   From: <sip:romeo@example.net>;tag=576
   Call-ID: 742507no
   Content-Type: application/sdp

   c=IN IP4 m2x.example.net
   m=message 8763 TCP/MSRP *
   a=accept-types:text/plain
   a=lang:it
   a=path:msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp







Saint-Andre, et al.       Expires May 14, 2008                 [Page 22]


Internet-Draft           XMPP-MSRP Interworking            November 2007


2.4.3.  Completing the Transaction

   In this case, the 200 OK is routed back and is received by Romeo UA.
   Finally, Romeos client sends an acknowledgment message, ACK, to
   Juliets client to confirm the reception of the final response (200
   OK).

   Example: (F5) Romeo sends the ACK:

   ACK sip:juliet@example.com SIP/2.0
   To: <sip:juliet@example.com>;tag=534
   From: <sip:romeo@example.net>;tag=576
   Call-ID: 742507no

   Upon receiving the ACK, the MSRP-XMPP gateway SHOULD remember this is
   an acknowledgment to an XMPP formal session.  The gateway is
   responsible for translating the acknowledgment into a confirmation
   stanza, without inserting other content (e.g. a <body/> element can
   not be inserted).

   Example: (F6) Romeo sends the ACK (XMPP translation)

   <message type='normal'
            from='romeo@example.net'
            to='juliet@example.com'>
     <thread>742507no</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='result'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>true</value></field>
       </x>
     </feature>
   </message>

2.4.4.  Send a Message

   When Romeo wants to send a message, he creates an MSRP SEND request
   that contains message.











Saint-Andre, et al.       Expires May 14, 2008                 [Page 23]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F7) Romeo send a message.

   MSRP ad49kswow SEND
   To-Path: msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp
   From-Path: msrp://example.net:7313/ansp71weztas;tcp
   Message-ID: 44921zaqwsx
   Byte-Range: 1-32/32
   Failure-Report: no
   Content-Type: text/plain

   I forgot what I wanted to say!
   -------ad49kswow$

   Upon receiving the MSRP SEND request, the MSRP-XMPP gateway SHOULD
   remember that the message is for an XMPP user.  The gateway is
   responsible for translating the MSRP SEND request in an XMPP message
   stanza.

   Example: (F8) Romeo sends a message (XMPP translation).

   <message type='normal'
            from='romeo@example.net'
            to='juliet@example.com'>
     <thread>742507no</thread>
     <body>I forgot what I wanted to say!</body>
   </message>

   The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be
   as shown in the following table.  (Mappings for elements not
   mentioned are undefined).

   Table 4: Message syntax mapping from MSRP Message to XMPP

   +-----------------------------+-----------------------------+
   | MSRP Header                 |  XMPP Element or Attribute  |
   +-----------------------------+-----------------------------+
   |  To-Path                    |  to                         |
   |  From-Path                  |  from                       |
   |  body of the SEND request   |  <body/>                    |
   |  Content-Type: text/plain   |  -                          |
   |  Message-ID                 |  id                         |
   +-----------------------------+-----------------------------+

2.4.5.  Terminating a Session

   When Romeo wants to terminate the Session, he is required to send a
   SIP BYE request.




Saint-Andre, et al.       Expires May 14, 2008                 [Page 24]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F9) Romeo terminates the session

   BYE juliet@example.com sip: SIP/2.0
   Max-Forwards: 70
   From: <sip:romeo@example.net>;tag=576
   To: <sip:juliet@example.com>;tag=534
   Call-ID: 742507no
   Cseq: 1 BYE
   Content-Length: 0

   Upon receiving the SIP BYE request, the GW SHOULD translate the
   request to a <message/> stanza containing a data form of type
   "submit".  The <message/> element MUST contain a <thread/> element
   with the same XML character data as the original initiation request.
   The data form containing a boolean field named "terminate" should be
   set to a value of "1" or "true".

   Example: (F10) Romeo terminates the session (XMPP translation)

   <message type='normal'
            from='romeo@example.net'
            to='juliet@example.com'>
     <thread>742507no</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='terminate'><value>1</value></field>
       </x>
     </feature>
   </message>

   Juliet explicitly acknowledges the termination of the chat session on
   the XMPP side by sending a <message/> containing a data form of type
   "result", and the value of the "terminate" field set to "1" or
   "true".  The client MUST mirror the <thread/> value it received.














Saint-Andre, et al.       Expires May 14, 2008                 [Page 25]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Example: (F11) Juliet acknowledges the termination of the session.

   <message type='normal'
            from='juliet@example.com'
            to=='romeo@example.net'>
    <thread>742507no</thread>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE'>
          <value>urn:xmpp:ssn</value>
        </field>
        <field var='terminate'><value>1</value></field>
        </x>
    </feature>
   </message>

   Upon receiving the acknowledgment message, the GW SHOULD translate it
   to a SIP answer 200 OK.

   Example: (F12) Juliet acknowledges the termination of the session
   (SIP translation)

   SIP/2.0 200 OK
   From: <sip:romeo@example.net>;tag=576
   To: <sip:juliet@example.com>;tag=534
   Call-ID: 742507no
   CSeq: 1 BYE

2.4.6.  Cancel the transaction

   SIP User                   M2X GW                    XMPP User
      |                        |                          |
      |(F1)(SIP) INVITE        |                          |
      |----------------------->|                          |
      |                        |(F2)(XMPP) Stanza session request
      |                        |------------------------->|
      |(F3)(SIP) CANCEL        |                          |
      |----------------------->|                          |
      |                        |(F4)(XMPP) Stanza session termination
      |                        |------------------------->|
      |                        |(F5)(XMPP) Stanza acknowledgment
      |                        |            session termination
      |                        |<-------------------------|
      |(F6)(SIP) 200 OK        |                          |
      |<-----------------------|                          |

   A common scenario occurs when the SIP user issues an invitation to
   set up a Chat session with an XMPP user and immediately after the SIP



Saint-Andre, et al.       Expires May 14, 2008                 [Page 26]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   invitation is sent, the SIP user decides to cancel it.  The XMPP-MSRP
   GW will receive the CANCEL request and using the the Call-ID, To,
   From and CSeq (sequence number only) header field values as a guide,
   will issue an XMPP Stanza session termination request to the XMPP
   user to cancel the XMPP formal session (assuming that it was already
   set up).  Once the XMPP-MSRP GW receives an ACK stanza message for
   the session termination, the XMPP-MSRP GW will respond with a status
   of 200 (OK) back to the SIP user.  It is important to note that if
   the SIP session transaction does not exist, the XMPP-MSRP GW will
   return a status of 481 (Transaction Does Not Exist) back to the SIP
   User.

2.4.7.  Rejecting a transaction

   SIP User                      M2X GW                    XMPP User
       |                           |                          |
       |(F1)(SIP) INVITE           |                          |
       |-------------------------->|                          |
       |                           |(F2)(XMPP) Stanza session request
       |                           |------------------------->|
       |                           |(F3)(XMPP) Stanza session decline
       |                           |<-------------------------|
       |(F4)(SIP) 4xx/6xx          |                          |
       |<--------------------------|                          |

   Another common scenario occurs when the XMPP UA is currently not
   willing or able to accept a formal session request.  The XMPP UA
   SHOULD decline the invitation.  The data form MUST contain the
   FORM_TYPE field and the "accept" field set to "0" or "false".  It is
   RECOMMENDED that the form does not contain any other fields even if
   the request indicated they are required.  The client MAY include a
   reason in the <body/> child of the <message/> stanza:

   Example: (F3) User declines offer and specifies reason

   <message type='normal'
            from='juliet@example.com'
            to='romeo@example.net'>
     <thread>742507no</thread>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE'>
           <value>urn:xmpp:ssn</value>
         </field>
         <field var='accept'><value>0</value></field>
       </x>
     </feature>
   </message>



Saint-Andre, et al.       Expires May 14, 2008                 [Page 27]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   Upon receiving the declined response for the XMPP formal session
   request, the XMPP-MSRP GW SHOULD return a 4xx or a 6xx SIP response
   back to the SIP client.  Any content that is contained in the <body/>
   child of the <message/>. stanza SHOULD be copied into the response
   Warning header field which explains why the offer was rejected.

2.5.  MSRP to an XMPP Informal Session

   To follow.


3.  Security Considerations

   To follow.


4.  References

4.1.  Normative References

   [IMP-SRV]  Peterson, J., "Address Resolution for Instant Messaging
              and Presence", RFC 3861, August 2004.

   [MSRP]     Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

   [OFFER]    Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [SIP]      Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [TERMS]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [XEP-0155]
              Paterson, I. and P. Saint-Andre, "Stanza Session
              Negotiation", XSF XEP 0155, March 2007.

   [XMPP]     Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [XMPP-IM]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.



Saint-Andre, et al.       Expires May 14, 2008                 [Page 28]


Internet-Draft           XMPP-MSRP Interworking            November 2007


   [XMPP-SIMPLE]
              Saint-Andre, P., "Basic Messaging and Presence
              Interworking between the Extensible Messaging  and
              Presence Protocol (XMPP) and Session Initiation Protocol
              (SIP) for Instant Messaging and Presence Leveraging
              Extensions (SIMPLE)", draft-saintandre-xmpp-simple-10
              (work in progress), August 2007.

4.2.  Informative References

   [DNS-SRV]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [IMP-REQS]
              Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
              Messaging / Presence Protocol Requirements", RFC 2779,
              February 2000.

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

   [SDP]      Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [SIP-MSG]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [XEP-0045]
              Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
              April 2007.

   [XEP-0124]
              Paterson, I., Smith, D., and P. Saint-Andre,
              "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
              XEP 0124, February 2007.

   [XEP-0184]
              Saint-Andre, P. and J. Hildebrand, "Message Receipts", XSF
              XEP 0184, September 2007.

   [XEP-0206]
              Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007.






Saint-Andre, et al.       Expires May 14, 2008                 [Page 29]


Internet-Draft           XMPP-MSRP Interworking            November 2007


Authors' Addresses

   Peter Saint-Andre
   XMPP Standards Foundation
   P.O. Box 1641
   Denver, CO  80201
   USA

   Email: stpeter@jabber.org
   URI:   https://stpeter.im/


   Eddy Gavita
   Ericsson
   Decarie Boulevard
   Town of Mount Royal, Quebec
   Canada

   Email: eddy.gavita@ericsson.com


   Nazin Hossain
   Ericsson
   Decarie Boulevard
   Town of Mount Royal, Quebec
   Canada

   Email: Nazin.Hossain@ericsson.com


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Salvatore.Loreto@ericsson.com














Saint-Andre, et al.       Expires May 14, 2008                 [Page 30]


Internet-Draft           XMPP-MSRP Interworking            November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Saint-Andre, et al.       Expires May 14, 2008                 [Page 31]


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