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

Versions: 00 01 02 04 05 draft-ietf-stox-core

Network Working Group                                     P. Saint-Andre
Internet-Draft                                                     Cisco
Intended status: Informational                                  A. Houri
Expires: September 9, 2009                                           IBM
                                                           J. Hildebrand
                                                                   Cisco
                                                           March 8, 2009


   Interworking between the Session Initiation Protocol (SIP) and the
        Extensible Messaging and Presence Protocol (XMPP): Core
                   draft-saintandre-sip-xmpp-core-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 September 9, 2009.

Copyright Notice




Saint-Andre, et al.     Expires September 9, 2009               [Page 1]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   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.



































Saint-Andre, et al.     Expires September 9, 2009               [Page 2]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Architectural Assumptions  . . . . . . . . . . . . . . . . . .  4
   3.  Address Mapping  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  SIP to XMPP  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  XMPP to SIP  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Error Condition Mapping  . . . . . . . . . . . . . . . . . . .  9
     4.1.  XMPP to SIP  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  SIP to XMPP  . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13



































Saint-Andre, et al.     Expires September 9, 2009               [Page 3]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


1.  Introduction

   The IETF has worked on two signalling technologies that can be used
   for multimedia session negotiation, messaging, presence, capabilities
   discovery, notifications, and other application-level functionality:

   o  The Session Initiation Protocol [SIP], along with various SIP
      extensions developed within the SIP for Instant Messaging and
      Presence Leveraging Extensions (SIMPLE) Working Group.
   o  The Extensible Messaging and Presence Protocol [XMPP], along with
      various XMPP extensions developed by the IETF as well as by the
      XMPP Standards Foundation.

   Because these technologies are widely deployed, it is important to
   clearly define mappings between them for the sake of interworking.
   This document inaugurates a series of SIP-XMPP interworking
   specifications by defining the architectural assumptions underlying
   such mappings as well as the mapping of addresses and error
   conditions.

   Note: 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 RFC 2119 [TERMS].


2.  Architectural Assumptions

   Protocol translation between SIP and XMPP could occur in a number of
   different entities, depending on the architecture of presence and
   messaging deployments.  For example, protocol translation could occur
   within a multi-protocol server, within a multi-protocol client, or
   within a gateway that acts as a dedicated protocol translator.

   This document assumes that the protocol translation will occur within
   a gateway.  (This assumption not meant to discourage protocol
   translation within multi-protocol clients or servers; instead, this
   assumption is followed mainly to clarify the discussion and examples
   so that the protocol translation principles can be more easily
   understood and can be applied by client and server implementors with
   appropriate modifications to the examples and terminology.)
   Specifically, we assume that the protocol translation will occur
   within an "XMPP-to-SIP gateway" that translates XMPP syntax and
   semantics on behalf of an XMPP service when communicating with SIP
   services and/or within a "SIP-to-XMPP gateway" that translates SIP
   syntax and semantics on behalf of a SIP service when communicating
   with XMPP services.




Saint-Andre, et al.     Expires September 9, 2009               [Page 4]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   This document assumes that a gateway will translate directly from one
   protocol to the other.  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 a SIP service will be translated by a gateway within the trust
   domain of that SIP 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 trust domain:

   o  romeo@example.net -- a SIP user.
   o  example.net -- a SIP service.
   o  s2x.example.net -- a SIP-to-XMPP gateway.
   o  juliet@example.com -- an XMPP user.
   o  example.com -- an XMPP service.
   o  x2s.example.com -- an XMPP-to-SIP gateway.

   #####################################################################
   #                               #                                   #
   #         +-- s2x.example.net---#------------- example.com          #
   #         |                     #               |     |             #
   #  example.net -----------------#--- x2s.example.com  |             #
   #       |                       #                     |             #
   #       |                       #                     |             #
   #  romeo@example.net            #               juliet@example.com  #
   #                               #                                   #
   #####################################################################


3.  Address Mapping

3.1.  Overview

   The basic SIP address format is a "sip:" or "sips:" URI as specified
   in [SIP].  When a SIP entity supports extensions for instant
   messageing it may be identified by an 'im:' URI as specified in
   [CPIM] (see [SIP-IM]) and when a SIP entity spports extensions for
   presence it may be identified by a 'pres:' URI as specified in [CPP]
   (see [SIP-PRES]).

   The XMPP address format is specified in [XMPP]; as specified in
   [XMPP-IM], instant messaging and presence applications of XMPP must
   also support 'im:' and 'pres:' URIs as specified in [CPIM] and [CPP]
   respectively, although such support may simply involve leaving
   resolution of such addresses up to an XMPP server.



Saint-Andre, et al.     Expires September 9, 2009               [Page 5]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   In this document we describe mappings for addresses of the form
   <user@domain> only, ignoring (for the purpose of address mapping) any
   protocol-specific extensions such as SIP telephone numbers and
   passwords or XMPP resource identifiers.  In addition, we have ruled
   the mapping of domain names as out of scope for now since that is a
   matter for the Domain Name System; specifically, the issue for
   interworking between SIP and XMPP relates to the translation of fully
   internationalized domain names (which the SIP address format does not
   allow, but which the XMPP address format does allow via [IDNA]) into
   non-internationalized domain names.  Therefore, in the following
   sections we discuss local-part addresses only (these are called
   variously "usernames", "instant inboxes", "presentities", and "node
   identifiers" in the protocols at issue).

   The sip:/sips:, im:/pres:, and XMPP address schemes allow different
   sets of characters (although all three allow alphanumeric characters
   and disallow both spaces and control characters).  In some cases,
   characters allowed in one scheme are disallowed in others; these
   characters must be mapped appropriately in order to ensure
   interworking across systems.

   The local-part address in sip:/sips: URIs inherits from the
   "userinfo" rule in [URI] with several changes; here we discuss the
   SIP "user" rule only:

      user             =  1*( unreserved / escaped / user-unreserved )
      user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
      unreserved       =  alphanum / mark
      mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                          / "(" / ")"

   Here we make the simplifying assumption that the local-part address
   in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC2822]
   rather than the more complicated "local-part" rule:

      dot-atom-text =  1*atext *("." 1*atext)
      atext         =  ALPHA / DIGIT / ; Any character except controls,
                       "!" / "#" /     ;  SP, and specials.
                       "$" / "%" /     ;  Used for atoms
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"




Saint-Andre, et al.     Expires September 9, 2009               [Page 6]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   The local-part address in XMPP addresses allows any US-ASCII
   character except space, controls, and the " & ' / : < > @ characters.

   Therefore, following table lists the allowed and disallowed
   characters in the local-part addresses of each protocol (aside from
   the alphanumeric, space, and control characters), in order by
   hexadecimal character number (where the "A" row shows the allowed
   characters and the "D" row shows the disallowed characters).

   Table 1: Allowed and disallowed characters

   +---+----------------------------------+
   | SIP/SIPS CHARACTERS                  |
   +---+----------------------------------+
   | A | !  $ &'()*+,-./ ; = ?     _    ~ |
   | D |  "# %          : < > @[\]^ `{|}  |
   +---+----------------------------------+
   | IM/PRES CHARACTERS                   |
   +---+----------------------------------+
   | A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
   | D |  "     ()  , . :;< > @[\]        |
   +---+----------------------------------+
   | XMPP CHARACTERS                      |
   +---+----------------------------------+
   | A | ! #$%  ()*+,-.  ; = ? [\]^_`{|}~ |
   | D |  "   &'       /: < > @           |
   +---+----------------------------------+

   When transforming a local-part address from one scheme to another, an
   application SHOULD proceed as follows:

   1.  Unescape any escaped characters in the source address (e.g., from
       SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape
       "\27" to "'").
   2.  Leave unmodified any characters that are allowed in the
       destination scheme.
   3.  Escape any characters that are allowed in the source scheme but
       reserved in the destination scheme, as escaping is defined for
       the destination scheme.  In particular:
       *  Where the destination scheme is a URI (i.e., an im:, pres:,
          sip:, or sips: URI), each reserved character MUST be percent-
          encoded to "%hexhex" as specified in Section 2.6 of
          [URL-GUIDE] (e.g., when transforming from XMPP to SIP, encode
          "/" as "%2F").
       *  Where the destination scheme is a native XMPP address, each
          reserved character MUST be encoded to "\hexhex" as specified
          in [XEP-0106] (e.g., when transforming from SIP to XMPP,
          encode "'" as "\27").



Saint-Andre, et al.     Expires September 9, 2009               [Page 7]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


3.2.  SIP to XMPP

   The following is a high-level algorithm for mapping a sip:, sips:,
   im:, or pres: URI to an XMPP address:

   1.  Remove URI scheme.
   2.  Split at the first '@' character into local-part and hostname
       (mapping the latter is out of scope).
   3.  Translate %hexhex to equivalent octets.
   4.  Treat result as a UTF-8 string.
   5.  Translate "&" to "\26", "'" to "\27", and "/" to "\2f"
       respectively in order to properly handle the characters
       disallowed in XMPP addresses but allowed in sip:/sips: URIs and
       im:/pres: URIs as shown in Column 3 of Table 3 above (this is
       consistent with [XEP-0106]).
   6.  Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP])
       for canonicalization (OPTIONAL).
   7.  Recombine local-part with mapped hostname to form local@domain
       address.

3.3.  XMPP to SIP

   The following is a high-level algorithm for mapping an XMPP address
   to a sip:, sips:, im:, or pres: URI:

   1.  Split XMPP address into node identifier (local-part; mapping
       described in remaining steps), domain identifier (hostname;
       mapping is out of scope), and resource identifier (specifier for
       particular device or connection; discard this for cross-system
       interworking).
   2.  Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP])
       for canonicalization (OPTIONAL).
   3.  Translate "\26" to "&", "\27" to "'", and "\2f" to "/"
       respectively (this is consistent with [XEP-0106]).
   4.  Determine if the foreign domain supports im: and pres: URIs
       (discovered via [SRV] lookup as specified in [XMPP-IM]), else
       assume that the foreign domain supports sip:/sips: URIs.
   5.  If converting into im: or pres: URI, for each byte, if the byte
       is in the set (),.;[\] (i.e., the partial complement from Row 3,
       Column 2 of Table 3 above) or is a UTF-8 character outside the
       US-ASCII range then transform that byte to %hexhex.  If
       converting into sip: or sips: URI, for each byte, if the byte is
       in the set #%[\]^`{|} (i.e., the partial complement from Row 3,
       Column 1 of Table 3 above) or is a UTF-8 character outside the
       US-ASCII range then transform that byte to %hexhex.
   6.  Combine resulting local-part with mapped hostname to form
       local@domain address.




Saint-Andre, et al.     Expires September 9, 2009               [Page 8]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   7.  Prepend with 'im:' scheme (for XMPP <message/> stanzas) or
       'pres:' scheme (for XMPP <presence/> stanzas) if foreign domain
       supports these, else prepend with 'sip:' or 'sips:' scheme
       according to local service policy.


4.  Error Condition Mapping

   SIP response codes are specified in [SIP] and XMPP error conditions
   are specified in [XMPP].

4.1.  XMPP to SIP

   Table 8: Mapping of XMPP error conditions to SIP response codes

      +------------------------------+---------------------+
      |  XMPP Error Condition        |  SIP Response Code  |
      +------------------------------+---------------------+
      |  <bad-request/>              | 400                 |
      |  <conflict/>                 | 400                 |
      |  <feature-not-implemented/>  | 501                 |
      |  <forbidden/>                | 403                 |
      |  <gone/>                     | 410                 |
      |  <internal-server-error/>    | 500                 |
      |  <item-not-found/>           | 404                 |
      |  <jid-malformed/>            | 484                 |
      |  <not-acceptable/>           | 406                 |
      |  <not-allowed/>              | 405                 |
      |  <not-authorized/>           | 401                 |
      |  <payment-required/>         | 402                 |
      |  <recipient-unavailable/>    | 480                 |
      |  <redirect/>                 | 300                 |
      |  <registration-required/>    | 407                 |
      |  <remote-server-not-found/>  | 502                 |
      |  <remote-server-timeout/>    | 504                 |
      |  <resource-constraint/>      | 500                 |
      |  <service-unavailable/>      | 503                 |
      |  <subscription-required/>    | 407                 |
      |  <undefined-condition/>      | 400                 |
      |  <unexpected-request/>       | 491                 |
      +------------------------------+---------------------+

4.2.  SIP to XMPP

   The mapping of SIP response codes to XMPP error conditions SHOULD be
   as follows (note that XMPP does not include 100-series or 200-series
   response codes, only error conditions):




Saint-Andre, et al.     Expires September 9, 2009               [Page 9]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   Table 9: Mapping of SIP response codes to XMPP error conditions


















































Saint-Andre, et al.     Expires September 9, 2009              [Page 10]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


      +---------------------+------------------------------+
      |  SIP Response Code  |  XMPP Error Condition        |
      +---------------------+------------------------------+
      |  300                |  <redirect/>                 |
      |  301                |  <gone/>                     |
      |  302                |  <redirect/>                 |
      |  305                |  <redirect/>                 |
      |  380                |  <not-acceptable/>           |
      |  400                |  <bad-request/>              |
      |  401                |  <not-authorized/>           |
      |  402                |  <payment-required/>         |
      |  403                |  <forbidden/>                |
      |  404                |  <item-not-found/>           |
      |  405                |  <not-allowed/>              |
      |  406                |  <not-acceptable/>           |
      |  407                |  <registration-required/>    |
      |  408                |  <service-unavailable/>      |
      |  410                |  <gone/>                     |
      |  413                |  <bad-request/>              |
      |  414                |  <bad-request/>              |
      |  415                |  <bad-request/>              |
      |  416                |  <bad-request/>              |
      |  420                |  <bad-request/>              |
      |  421                |  <bad-request/>              |
      |  423                |  <bad-request/>              |
      |  480                |  <recipient-unavailable/>    |
      |  481                |  <item-not-found/>           |
      |  482                |  <not-acceptable/>           |
      |  483                |  <not-acceptable/>           |
      |  484                |  <jid-malformed/>            |
      |  485                |  <item-not-found/>           |
      |  486                |  <service-unavailable/>      |
      |  487                |  <service-unavailable/>      |
      |  488                |  <not-acceptable/>           |
      |  491                |  <unexpected-request/>       |
      |  493                |  <bad-request/>              |
      |  500                |  <internal-server-error/>    |
      |  501                |  <feature-not-implemented/>  |
      |  502                |  <remote-server-not-found/>  |
      |  503                |  <service-unavailable/>      |
      |  504                |  <remote-server-timeout/>    |
      |  505                |  <not-acceptable/>           |
      |  513                |  <bad-request/>              |
      |  600                |  <service-unavailable/>      |
      |  603                |  <service-unavailable/>      |
      |  604                |  <item-not-found/>           |
      |  606                |  <not-acceptable/>           |
      +---------------------+------------------------------+



Saint-Andre, et al.     Expires September 9, 2009              [Page 11]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


5.  Security Considerations

   Detailed security considerations for SIP are given in [SIP] and for
   XMPP in [XMPP].


6.  References

6.1.  Normative References

   [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.

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [URL-GUIDE]
              Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", RFC 4395,
              February 2006.

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

6.2.  Informative References

   [CPIM]     Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, August 2004.

   [CPP]      Peterson, J., "Common Profile for Presence (CPP)",
              RFC 3859, August 2004.

   [IDNA]     Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

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



Saint-Andre, et al.     Expires September 9, 2009              [Page 12]


Internet-Draft         SIP-XMPP Interworking: Core            March 2009


   [SIP-PRES]
              Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

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

   [STRINGPREP]
              Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("STRINGPREP")", RFC 3454,
              December 2002.

   [XEP-0106]
              Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF
              XEP 0106, May 2005.

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


Authors' Addresses

   Peter Saint-Andre
   Cisco

   Email: psaintan@cisco.com


   Avshalom Houri
   IBM
   Building 18/D, Kiryat Weizmann Science Park
   Rehovot  76123
   Israel

   Email: avshalom@il.ibm.com


   Joe Hildebrand
   Cisco

   Email: jhildebr@cisco.com








Saint-Andre, et al.     Expires September 9, 2009              [Page 13]


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