Changeset 73


Ignore:
Timestamp:
11/03/14 23:05:26 (9 years ago)
Author:
stpeter@…
Message:

08

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-stox-im.xml

    r59 r73  
    77<?rfc toc="yes"?>
    88<?rfc tocdepth="1"?>
    9 <rfc category='std' docName='draft-ietf-stox-im-07' ipr='trust200902'>
     9<rfc category='std' docName='draft-ietf-stox-im-08' ipr='trust200902'>
    1010
    1111  <front>
    1212    <title abbrev="SIP-XMPP Interworking: IM">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging</title>
    1313    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
    14       <organization/>
     14      <organization>&amp;yet</organization>
    1515      <address>
     16        <postal>
     17          <street>P.O. Box 787</street>
     18          <city>Parker</city>
     19          <region>CO</region>
     20          <code>80134</code>
     21          <country>USA</country>
     22        </postal>
    1623        <email>ietf@stpeter.im</email>
    1724      </address>
     
    7178    </section>
    7279
     80    <section title="Intended Audience" anchor="audience">
     81      <t>The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP).  We assume that readers are familiar with the core specifications for both SIP <xref target='RFC3261'/> and XMPP <xref target='RFC6120'/>, with the base document for this series <xref target='I-D.ietf-stox-core'/>, and with the following IM-related specifications:</t>
     82      <t>
     83        <list style='symbols'>
     84          <t>Session Initiation Protocol (SIP) Extension for Instant Messaging <xref target='RFC3428'/></t>
     85          <t>Extensible Messaging and Presence Protocol: Instant Messaging and Presence <xref target='RFC6121'/></t>
     86        </list>
     87      </t>
     88    </section>
     89
    7390    <section title="Terminology" anchor="terms">
    7491      <t>A number of terms used here are explained in <xref target='RFC3261'/>, <xref target='RFC3428'/>, <xref target='RFC6120'/>, and <xref target='RFC6121'/>.</t>
    75       <t>Continuing the tradition of Shakespearean examples in XMPP documentation, the actors in this document are an XMPP user &lt;juliet@example.com&gt; and a SIP user &lt;romeo@example.net&gt;.</t>
    7692      <t>The 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 <xref target='RFC2119'/>.</t>
    7793    </section>
     
    8197      <t>When Juliet wants to send an instant message to Romeo, she interacts with her XMPP client, which generates an XMPP &lt;message/&gt; stanza.  The syntax of the &lt;message/&gt; stanza, including required and optional elements and attributes, is defined in <xref target="RFC6121"/> (for single instant messages, the value of the 'to' address SHOULD be a "bare JID" of the form "localpart@domainpart").  The following is an example of such a stanza:</t>
    8298      <figure>
    83         <preamble>Example 1: XMPP user sends message:</preamble>
     99        <preamble>Example 1: XMPP user sends message</preamble>
    84100        <artwork><![CDATA[
    85101|  <message from='juliet@example.com/balcony'
     
    89105        ]]></artwork>
    90106      </figure>
    91       <t>Upon receiving such a message stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures explained in Section 5 of <xref target='I-D.ietf-stox-core'/>.  Here we assume that the XMPP server has determined the domain is serviced by an IM-capable SIP server, that it contains or has available to it an XMPP-SIP gateway or connection manager (which enables it to speak natively to IM-capable SIP servers), and that it hands off the message stanza to the XMPP-SIP gateway.</t>
     107      <t>Upon receiving such a message stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures explained in Section 5 of <xref target='I-D.ietf-stox-core'/>.  If the domain is a SIP domain, the XMPP server will hand off the message stanza to an XMPP-to-SIP gateway or connection manager that natively communicates with IM-aware SIP servers.</t>
    92108      <t>The XMPP-SIP gateway is then responsible for translating the XMPP message stanza into a SIP MESSAGE request from the XMPP user to the SIP user:</t>
    93109      <figure>
    94         <preamble>Example 2: XMPP user sends message (SIP transformation):</preamble>
     110        <preamble>Example 2: XMPP user sends message (SIP transformation)</preamble>
    95111        <artwork><![CDATA[
    96112|  MESSAGE sip:romeo@example.net SIP/2.0
     
    109125      <t>The destination SIP server is responsible for delivering the message to the intended recipient, and the recipient is responsible for generating a response (e.g., 200 OK).</t>
    110126      <figure>
    111         <preamble>Example 3: SIP user agent indicates receipt of message:</preamble>
     127        <preamble>Example 3: SIP user agent indicates receipt of message</preamble>
    112128        <artwork><![CDATA[
    113129|  SIP/2.0 200 OK
     
    142158      <t>
    143159        <list style='numbers'>
    144           <t>As shown in the foregoing example and described in <xref target='I-D.ietf-stox-core'/>, the XMPP-SISIP gateway SHOULD map the full JID (localpart@domainpart/resourcepart) of the XMPP sender to the SIP From header and include the resourcepart as the GRUU portion <xref target='RFC5627'/> of the SIP URI.</t>
     160          <t>As shown in the foregoing example and described in <xref target='I-D.ietf-stox-core'/>, the XMPP-SIP gateway SHOULD map the full JID (localpart@domainpart/resourcepart) of the XMPP sender to the SIP From header and include the resourcepart as the GRUU portion <xref target='RFC5627'/> of the SIP URI.</t>
    145161          <t>Because there is no SIP header field that matches the meaning of the XMPP message 'type' values ("normal", "chat", "groupchat", "headline", "error"), no general mapping is possible here.</t>
    146162        </list>
     
    152168      <t>When Romeo wants to send an instant message to Juliet, he interacts with his SIP user agent, which generates a SIP MESSAGE request.  The syntax of the MESSAGE request is defined in <xref target="RFC3428"/>.  The following is an example of such a request:</t>
    153169      <figure>
    154         <preamble>Example 4: SIP user sends message:</preamble>
     170        <preamble>Example 4: SIP user sends message</preamble>
    155171        <artwork><![CDATA[
    156172|  MESSAGE sip:juliet@example.com SIP/2.0
     
    167183        ]]></artwork>
    168184      </figure>
    169       <t>Section 5 of <xref target="RFC3428"/> stipulates that a SIP User Agent presented with an im: URI should resolve it to a sip: or sips: URI.  Therefore we assume that the Request-URI of a request received by an IM-capable SIP-XMPP gateway will contain a sip: or sips: URI.  The SIP server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures explained in Section 5 of <xref target='I-D.ietf-stox-core'/>.  Here we assume that the SIP server has determined that the domain is serviced by an XMPP server, that it contains or has available to it an IM-aware SIP-to-XMPP gateway or connection manager (which enables it to speak natively to XMPP servers), and that it hands off the message to the gateway.</t>
     185      <t>Section 5 of <xref target="RFC3428"/> stipulates that a SIP User Agent presented with an im: URI should resolve it to a sip: or sips: URI.  Therefore we assume that the Request-URI of a request received by an IM-capable SIP-XMPP gateway will contain a sip: or sips: URI.  Upon receiving the MESSAGE, the SIP (MSRP) server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures explained in Section 5 of <xref target='I-D.ietf-stox-core'/>.  If the domain is an XMPP domain, the SIP server will hand off the MESSAGE to an associated SIP-XMPP gateway or connection manager that natively communicates with XMPP servers.</t>
    170186      <t>The SIP-to-XMPP gateway is then responsible for translating the request into an XMPP message stanza from the SIP user to the XMPP user and returning a SIP "200 OK" message to the sender:</t>
    171187      <figure>
    172         <preamble>Example 5: SIP user sends message (XMPP transformation):</preamble>
     188        <preamble>Example 5: SIP user sends message (XMPP transformation)</preamble>
    173189        <artwork><![CDATA[
    174190|  <message from='romeo@example.net/orchard'
     
    215231      <t>Both XMPP and SIP support the UTF-8 encoding <xref target='RFC3629'/> of Unicode characters <xref target='UNICODE'/> within messages, and signalling of the language for a particular message (in XMPP via the 'xml:lang' attribute and in SIP via the Content-Language header).  Several examples follow, using the "XML Notation" for Unicode characters outside the ASCII range described in <xref target='RFC3987'/>.</t>
    216232      <figure>
    217         <preamble>Example 6: SIP user sends message:</preamble>
     233        <preamble>Example 6: SIP user sends message</preamble>
    218234        <artwork><![CDATA[
    219235|  MESSAGE sip:juliet@example.com SIP/2.0
     
    233249      </figure>
    234250      <figure>
    235         <preamble>Example 7: SIP user sends message (XMPP transformation):</preamble>
     251        <preamble>Example 7: SIP user sends message (XMPP transformation)</preamble>
    236252        <artwork><![CDATA[
    237253|  <message from='romeo@example.net'
     
    271287    <organization />
    272288</author>
    273 <author initials='E' surname='Gavita' fullname='Eddy Gavita'>
    274     <organization />
    275 </author>
    276 <author initials='N' surname='Hossain' fullname='Nazin Hossain'>
    277     <organization />
    278 </author>
    279 <date month='December' day='10' year='2013' />
     289<date month='March' day='11' year='2014' />
    280290<abstract><t>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).</t></abstract>
    281291</front>
    282 <seriesInfo name='Internet-Draft' value='draft-ietf-stox-chat-04' />
     292<seriesInfo name='Internet-Draft' value='draft-ietf-stox-chat-06' />
    283293<format type='TXT'
    284         target='http://www.ietf.org/internet-drafts/draft-ietf-stox-chat-04.txt' />
     294        target='http://www.ietf.org/internet-drafts/draft-ietf-stox-chat-06.txt' />
    285295</reference>
    286296
     
    297307    <organization />
    298308</author>
    299 <date month='December' day='19' year='2013' />
     309<date month='February' day='11' year='2014' />
    300310<abstract><t>As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</t></abstract>
    301311</front>
    302 <seriesInfo name='Internet-Draft' value='draft-ietf-stox-core-09' />
     312<seriesInfo name='Internet-Draft' value='draft-ietf-stox-core-11' />
    303313<format type='TXT'
    304         target='http://www.ietf.org/internet-drafts/draft-ietf-stox-core-09.txt' />
     314        target='http://www.ietf.org/internet-drafts/draft-ietf-stox-core-11.txt' />
    305315</reference>
    306316
     
    571581</reference>
    572582
    573 <reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.2.0/">
     583<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.3.0/">
    574584  <front>
    575     <title>The Unicode Standard, Version 6.2</title>
     585    <title>The Unicode Standard, Version 6.3</title>
    576586    <author>
    577587      <organization>The Unicode Consortium</organization>
    578588    </author>
    579     <date year="2012" />
     589    <date year="2013" />
    580590  </front>
    581591</reference>
     
    584594
    585595    <section title="Acknowledgements" anchor="ack">
    586       <t>The authors wish to thank the following individuals for their feedback: Mary Barnes, Dave Cridland, Adrian Georgescu, Christer Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe.</t>
    587       <t>The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo as the sponsoring Area Director.</t>
     596      <t>The authors wish to thank the following individuals for their feedback: Mary Barnes, Dave Cridland, Dave Crocker, Adrian Georgescu, Christer Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe.</t>
     597      <t>The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.</t>
     598      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.</t>
    588599    </section>
    589600
Note: See TracChangeset for help on using the changeset viewer.