From: http://www.ietf.org/internet-drafts/draft-mierla-simple-xmpp-interworking-00.txt Title: SIMPLE-XMPP Interworking Date: April 23, 2003 --------------------------------------------------------------------------- Network Working Group D. Mierla Internet-Draft Fraunhofer FOKUS Expires: October 22, 2003 April 23, 2003 SIMPLE-XMPP Interworking draft-mierla-simple-xmpp-interworking-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 22, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the behavior for the logical entity known as the SIMPLE-XMPP Interworking Function (SIMPLE-XMPP IWF) that will allow the interworking between the SIMPLE (Session initiation protocol for Instant Messaging and Presence Leveraging Extensions) and XMPP (eXtensible Messaging and Presence Protocol - also known as Jabber protocol) protocols. Mierla Expires October 22, 2003 [Page 1] Internet-Draft SIMPLE-XMPP Interworking April 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 IWF (InterWorking Function) . . . . . . . . . . . . . . . . . 3 3.2 SIMPLE Server . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 XMPP Server . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.4 EndPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.5 'Non Signaling' message . . . . . . . . . . . . . . . . . . . 4 3.6 'Signaling' message . . . . . . . . . . . . . . . . . . . . . 4 4. Functional Requirements and Behaviour of the SIMPLE-XMPP IWF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Basic Configuration . . . . . . . . . . . . . . . . . . . . . 4 4.2 Advanced Configuration . . . . . . . . . . . . . . . . . . . . 4 4.3 Functionality . . . . . . . . . . . . . . . . . . . . . . . . 4 5. General Interworking Requirements . . . . . . . . . . . . . . 5 6. Mapping between SIMPLE and XMPP . . . . . . . . . . . . . . . 6 6.1 General Procedures . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Message Type Conversion . . . . . . . . . . . . . . . . . . . 6 6.3 Presence Specific Attributes Conversion . . . . . . . . . . . 7 7. Managing the message flow . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Examples and scenarios . . . . . . . . . . . . . . . . . . . . 8 9.1 Basic Instant Messaging sequence . . . . . . . . . . . . . . . 9 9.2 Sample message conversion . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 B. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Mierla Expires October 22, 2003 [Page 2] Internet-Draft SIMPLE-XMPP Interworking April 2003 1. Introduction SIMPLE [1] extends the Session Initiation Protocol with Instant Messaging and Presence functionality. The Session Initiation Protocol (SIP) [3] was designed to initiate and manipulate media 'sessions' between communicating parties. XMPP is an XML-based streaming protocol designed for Instant Messaging and Presence [2]. The primary objective of a SIMPLE-XMPP Interworking function (IWF) is to provide protocol conversion between SIMPLE and XMPP protocols. The document describes the requirements and behavior of the SIMPLE-XMPP Interworking function for conversion of the SIMPLE and XMPP protocols. How to use SIP to initiate XMPP chat sessions [9] or how to initiate sessions over XMPP [11] are not the subject of the present document. 2. Conventions Used in this Document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and indicate requirement levels for the protocol. 3. Definitions 3.1 IWF (InterWorking Function) Performs interworking between SIMPLE and XMPP protocols. 3.2 SIMPLE Server This can be either a SIP proxy, redirect or registrar server [3] that supports SIMPLE. 3.3 XMPP Server Any entity that acts according to the definition of entity 'Server' for XMPP protocol [2]. 3.4 EndPoint An endpoint can send and can receive instant messages. An endpoint is an entity from which the instant message originates or terminates. An endpoint can either be a SIMPLE client or an XMPP client. Mierla Expires October 22, 2003 [Page 3] Internet-Draft SIMPLE-XMPP Interworking April 2003 3.5 'Non Signaling' message Any message which does not change the state of IWF within an Instant Messaging sequence. 3.6 'Signaling' message Any message which changes the state of IWF within an Instant Messaging sequence. 4. Functional Requirements and Behaviour of the SIMPLE-XMPP IWF SIMPLE-XMPP IWF can be designed in various ways. This may include coexistence of SIMPLE Servers and/or XMPP Servers with IWF. The co-location of the SIMPLE server and/or XMPP server in conjunction with the IWF is a matter of implementation and not a protocol issue. There shall be no assumptions made for the optional elements and components present in either SIMPLE or XMPP networks. The solution provided here shall work for a minimum configuration required for both protocols. There may be recommendations for other configurations, which include optional components. 4.1 Basic Configuration SIMPLE EndPoint <---------> IWF <---------> XMPP EndPoint 4.2 Advanced Configuration SIMPLE EP <---> SIMPLE Srv <---> IWF <---> XMPP Srv <---> XMPP EP 4.3 Functionality Therefore, an IWF must contain the following functions: a) Instant Messaging flow management between SIMPLE and XMPP protocols. The incoming Instant Messaging message from any endpoint must be delivered to the other endpoint after the protocol conversion. b) Address resolution for the two protocols. The IWF should contain the following functions: a) Presence flow management between SIMPLE and XMPP protocols. The incoming presence message from any endpoint must be delivered to the other endpoint after the protocol conversion. The IWF may contain the following functions: Mierla Expires October 22, 2003 [Page 4] Internet-Draft SIMPLE-XMPP Interworking April 2003 a) Interoperability Service reservation and release. The IWF may reserve some messages to act as 'Signaling' messages, but these messages must be known by all parts involved in usage of IWF (e.g., the SIMPLE SUBSCRIBE message intended for a XMPP conference may be interpreted by IWF as 'joining' the conference and act according to). The IWF may release any resource that was not released by any of the parts involved in an IM sequence and is no longer in use (e.g., when an IM sequence is ended and for unknown reasons one part does not close the connection established with the IWF, the IWF may release any resource related to it). b) Ability to provide the state of the Interoperability Service. The IWF may inform the endpoints about the state of IWF, like stop, restart and so on. c) Ability to process the messages for supplementary services (file transfer, ...) if the service is supported by the all parts of the Instant Messaging flow. 5. General Interworking Requirements The IWF shall provide the seamless interworking of the two protocols. The functioning of IWF must not involve any modification to the SIMPLE and XMPP protocols, but may involve specific profiles of these protocols. The IWF should: a) Follow the mandatory requirements as defined by SIMPLE protocol and XMPP protocol b) Support all the addressing schemes of both SIMPLE and XMPP protocols. c) Release any related resources on the detection of the end of the Instant Messaging flow between two parts. d) Not make any assumptions about the capabilities of either SIMPLE client or XMPP client. The IWF may: a) Have a look-up table for resolving the addresses. b) Use any type of data storage for keeping address resolution information. c) Use DNS for address resolution Mierla Expires October 22, 2003 [Page 5] Internet-Draft SIMPLE-XMPP Interworking April 2003 d) Define a set of 'Signaling' messages without changing the SIMPLE protocol or XMPP protocol 6. Mapping between SIMPLE and XMPP To convert SIP messages to XMPP messages and vice-versa the IWF must follow the general mapping procedures. 6.1 General Procedures a) A clear mapping between SIMPLE and XMPP addresses shall be provided to support all the addressing schemes of both SIMPLE and XMPP protocols. b) A clear mapping between SIMPLE and XMPP messages shall be provided to reflect similar meaning in the Instant Messaging sequence. c) For a given message of a given protocol, there may not be a corresponding message of the other protocol that may appear to be equivalent. The IWF needs to create a mapping between the messages or generate error messages based on common understanding of an agreed upon standard. d) A clear mapping between SIMPLE and XMPP message attributes shall be provided to reflect similar meaning in the two protocols. e) All attributes used in each message on one side may not match exactly the corresponding message of the other side. In this situation, some manipulations need to be done by the IWF so that an agreed-upon standard can be created based on common under-standing although all attributes do not exactly match. f) The messages that do not have a match on the other side should be terminated on the IWF, and IWF should take the necessary action on them (e.g, silently discard of any unknown message). g) In case the IWF is required to generate a message on its own in any of the sides, IWF should follow the mandatory requirements as defined by SIMPLE protocol or XMPP protocol. 6.2 Message Type Conversion The message types of the two protocols are to be converted as follows: Mierla Expires October 22, 2003 [Page 6] Internet-Draft SIMPLE-XMPP Interworking April 2003 +----------------+--------------+ | SIMPLE Message | XMPP Message | +================+==============+ | MESSAGE | MESSAGE | |----------------|--------------| | SUBSCRIBE | PRESENCE | | NOTIFY | | |----------------|--------------| | REGISTER | IQ | +----------------+--------------+ Figure 1 The common attributes of the messages of the two protocols are to be converted as follows +------------------+----------------+ | SIMPLE Attribute | XMPP Attribute | +==================+================+ | From | from | |------------------|----------------| | To | to | |------------------|----------------| | Call-ID | thread | |------------------|----------------| | CSeq | id | |------------------|----------------| | Message body | body | +------------------+----------------+ Figure 2 Any other attribute from any of the two protocols may be converted into an attribute of the other protocol if the meaning of the attribute is not changed. Any attribute which does not have a similar meaning attribute in the other protocol must be silently discarded. 6.3 Presence Specific Attributes Conversion SIMPLE uses PIDF [10] format to carry the presence information and the XMPP presence attributes must be converted to satisfy the PIDF format and meaning. Other details are subject for further discussions. 7. Managing the message flow The management of the messages shall follow the following guidelines: Mierla Expires October 22, 2003 [Page 7] Internet-Draft SIMPLE-XMPP Interworking April 2003 a) Unexpected messages in a particular state of the Instant Messaging sequence shall be treated as 'Error' messages. b) All messages which do not change the state of the Instant Messaging sequence shall be treated as 'Non Signaling' messages. c) All messages which expect a change in state of the Instant Messaging sequence shall be treated as 'Signaling' messages. d) The content of all 'Non Signaling' messages must be delivered with no change to the destination. e) The 'Signaling' messages may end at IWF or may be delivered to the destination in the appropriate meaning form. 8. Security Considerations A security scheme should be enabled in the IWF. A simple security scheme may be when the IWF will accept only requests from a pre-configured set of SIMPLE Servers or XMPP server only and it will reject all other requests. All other security requirements are for further discussion. Assumptions for the endpoints: a) All endpoints trying to use IWF are authorized with the respective SIMPLE servers or XMPP servers. Required for the endpoints: a) All endpoints trying to make open an Instant Messaging flow using IWF are respectively permitted to do so from IWF, as long as their messages pass an accepted SIMPLE or XMPP server first. Required for IWF a) Procedures for preventing denial of service security attacks. b) Maintaining persistent data for authorized endpoints for future verifications. 9. Examples and scenarios This section describes some examples of Instant Messaging scenarios that will show primarily the input and output messages of the IWF for interworking between SIMPLE and XMPP. Mierla Expires October 22, 2003 [Page 8] Internet-Draft SIMPLE-XMPP Interworking April 2003 9.1 Basic Instant Messaging sequence The 'Signaling' messages (control messages) may be represented by the Presence Messages, if the Presence is supported by the EndPoint. SIMPLE XMPP EP IWF EP | | | | SIMPLE Ctrl Msg | | |------------------>| XMPP Ctrl Msg | | 200 OK |<--------------->| |<------------------| | | | | | ............... | ............. | | | | | SIMPLE IM Msg | XMPP IM Msg | |------------------>|---------------->| | 202 Accepted | | |<------------------| | | | | | ............... | ............. | | | | | SIMPLE IM Msg | XMPP IM Msg | |<------------------|<----------------| | 200 OK | | |------------------>| | | | | | ............... | ............. | | | | Figure 3 9.2 Sample message conversion Scenario: - SIP server with SIMPLE support is sipserver.com - XMPP server is jabberserver.com - jabber.sipserver.com is a DNS alias for SIP server - all SIP messages for jabber.sipserver.com will be processed by IWF - address mapping between SIMPLE and XMPP Mierla Expires October 22, 2003 [Page 9] Internet-Draft SIMPLE-XMPP Interworking April 2003 The XMPP address 'juser@jabberserver.com' is mapped by SIMPLE server as 'juser*jabberserver.com@jabber.sipserver.com' a) Sample Instant Messaging message SIMPLE message | MESSAGE sip:juser*jabberserver.com@jabber.sipserver.com SIP/2.0 | Via: SIP/2.0/UDP sipserver.com;branch=as42tbK14rfaFhxzi | From: sip:suser@sipserver.com;tag=49394 | To: sip:juser*jabberserver.com@jabber.sipserver.com | Call-ID: arnskGnska@1.2.3.4 | CSeq: 1 MESSAGE | Content-Type: text/plain | Content-Length: 6 | | Hello! XMPP message | | hello! | Figure 4 b) Sample Presence messages SIMPLE message | NOTIFY sip:juser*jabberserver.com@jabber.sipserver.com SIP/2.0 | Via: SIP/2.0/UDP sipserver.com;branch=as42tbK14rfaFhxzi | From: sip:suser@sipserver.com;tag=49394 | To: sip:juser*jabberserver.com@jabber.sipserver.com | Call-ID: 3nedu3e0@1.2.3.4 | CSeq: 1 NOTIFY | Event: presence | Subscription-State: active;expires=1800 | Max-Forwards: 20 | Content-Type: application/cpim-pidf+xml | Content-Length: ... | | [PIDF Document] Mierla Expires October 22, 2003 [Page 10] Internet-Draft SIMPLE-XMPP Interworking April 2003 XMPP message | SIMPLE message | SUBSCRIBE sip:juser*jabberserver.com@jabber.sipserver.com SIP/2.0 | Via: SIP/2.0/UDP sipserver.com;branch=as42tbK14rfaFhxzi | From: sip:suser@sipserver.com;tag=49394 | To: sip:juser*jabberserver.com@jabber.sipserver.com | Call-ID: 4tqsdf430@1.2.3.4 | CSeq: 1 SUBSCRIBE | Max-Forwards: 20 | Event: presence | Accept: application/cpim-pidf+xml | Expires: 1800 | Content-Length: 0 XMPP message | Figure 5 Author's Address Daniel-Constantin Mierla Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 Berlin 10589 Germany EMail: mierla@fokus.fraunhofer.de Appendix A. Acknowledgments I would like to acknowledge to Dorgham Sisalem and Jiri Kuthan from Fraunhofer FOKUS Institute for their support for this work and to Peter Saint-Andre from Jabber Software Foundation for reviewing the document. Also, I would like to thank "Sip Express Router - SER" development team and the iptel.org for providing support with first Mierla Expires October 22, 2003 [Page 11] Internet-Draft SIMPLE-XMPP Interworking April 2003 implementation of these specifications. Appendix B. References [1] B. Campbell et al. , "Session Initiation Protocol Extension for Instant Messaging", RFC 3428, December 2002. [2] Miller, J. and P. Saint-Andre, "XMPP Core", Internet-Draft "draft-ietf-xmpp-core-10", April 2003. [3] 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. [4] J. Rosenberg, D. Willis, H. Schulzrinne, C. Huitema, B. Aboba, D. Gurle, D. Oran, "Session Initiation Protocol (SIP) Extensions for Presence", Internet Draft "draft-ietf-simple-presence-07", May 2002. [5] B. Campbell, J. Rosenberg, "CPIM Mapping of SIMPLE Presence and Instant Messaging", Internet Draft "draft-ietf-simple-cpim-mapping-01", June 2002. [6] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging", Internet-Draft "draft-ietf-xmpp-im-09", April 2003. [7] Miller, J. and P. Saint-Andre, "XMPP CPIM Mapping", Internet-Draft "draft-miller-xmpp-cpim-00", June 2002. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] R. Sparks, "Establishing Jabber Messaging Sessions with the Session Initiation Protocol", Internet-Draft "draft-sparks-simple-jabber-sessions-00", October 2002. [10] H. Sugano et al., "Common Presence and Instant Messaging (CPIM) Presence Information Data Format", Internet-Draft "draft-ietf-impp-cpim-pidf-07", December 2002. [11] J. Hildebrand, "CTINS: A Transport for Initiating and Negotiating Sessions using SDPng over XMPP", Internet-Draft "draft-hildebrand-xmpp-sdpng-00", February 2003. Mierla Expires October 22, 2003 [Page 12] Internet-Draft SIMPLE-XMPP Interworking April 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Mierla Expires October 22, 2003 [Page 13] Internet-Draft SIMPLE-XMPP Interworking April 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mierla Expires October 22, 2003 [Page 14]