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

Versions: 00 01

Network Working Group                                          D. Mierla
Internet-Draft                                          Fraunhofer FOKUS
Expires: April 22, 2004                                 October 23, 2003


                        SIMPLE-XMPP Interworking
                draft-mierla-simple-xmpp-interworking-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document describes the behavior for the logical entity named the
   SIMPLE-XMPP Interworking Function (SIMPLE-XMPP IWF) that allows 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. It refers to the conversion of the message
   format from one to the other protocol.









Mierla                   Expires April 22, 2004                 [Page 1]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 . . . . . . . . . . . . . . . . . . . . . . . 12

   A.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 12
   A.1 Changes from draft-mierla-simple-xmpp-interworking-00  . . . . 12

   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12

   C.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12

       Intellectual Property and Copyright Statements . . . . . . . . 14






Mierla                   Expires April 22, 2004                 [Page 2]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 3]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 4]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 5]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 6]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 7]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                 [Page 8]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 xmppserver.com
      - xmpp.sipserver.com is a DNS alias for SIP server
      - sip.xmppserver.com is a DNS alias for XMPP server
      - all SIP messages for xmpp.sipserver.com will be processed by IWF
      - all XMPP messages for sip.xmppserver.com will be processed by
      IWF
      - address mapping between SIMPLE and XMPP
      The XMPP address 'xuser@xmppserver.com' is mapped by SIMPLE server
      as 'xuser*xmppserver.com@xmpp.sipserver.com'.
      The SIP address 'suser@sipserver.com' is mapped by XMPP server as
      'suser*sipserver.com@sip.xmmpserver.com'.



Mierla                   Expires April 22, 2004                 [Page 9]


Internet-Draft          SIMPLE-XMPP Interworking            October 2003


   a) Sample Instant Messaging message


      Example of a SIMPLE message for an XMPP endpoint

      |  MESSAGE sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0
      |  Via: SIP/2.0/UDP xmmp.sipserver.com;branch=as42tbK14rfaFhxzi
      |  From: <sip:suser@sipserver.com>;tag=49394
      |  To: <sip:xuser*xmppserver.com@xmpp.sipserver.com>
      |  Call-ID: arnskGnska@1.2.3.4
      |  CSeq: 1 MESSAGE
      |  Content-Type: text/plain
      |  Content-Length: 6
      |
      |  Hello!


      The appropriate XMPP message generated by IWF

      |  <message id='1'
      |        from='suser*server.com@sip.xmppserver.com'
      |        to='xuser@xmppserver.com'>
      |    <body>hello!</body>
      |  </message>

      Example of an XMPP message for a SIMPLE endpoint

      |  <message id='1'
      |        from='xuser@xmppserver.com'
      |        to='suser*server.com@sip.xmppserver.com'>
      |    <body>hi!</body>
      |  </message>

      The appropriate SIMPLE message generated by IWF

      |  MESSAGE sip:suser@sipserver.com SIP/2.0
      |  Via: SIP/2.0/UDP xmpp.sipserver.com;branch=ld82682JUgskF12ed
      |  From: <sip:xuser*xmppserver.com@xmpp.sipserver.com>;tag=49394
      |  To: <sip:suser@sipserver.com>
      |  Call-ID: sgRTk893HG@5.6.7.8i
      |  CSeq: 1 MESSAGE
      |  Content-Type: text/plain
      |  Content-Length: 3
      |
      |  Hi!


                                Figure 4



Mierla                   Expires April 22, 2004                [Page 10]


Internet-Draft          SIMPLE-XMPP Interworking            October 2003


   b) Sample Presence messages


      SIMPLE message

      |  NOTIFY sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0
      |  Via: SIP/2.0/UDP xmpp.sipserver.com;branch=as42tbK14rfaFhxzi
      |  From: <sip:suser@sipserver.com>;tag=49394
      |  To: <sip:xuser*xmppserver.com@xmpp.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]

      XMPP message

      |  <presence id='1'
      |        from='suser*sipserver.com@sip.xmppserver.com'
      |        to='xuser@xmppserver.com'>


      SIMPLE message

      |  SUBSCRIBE sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0
      |  Via: SIP/2.0/UDP xmpp.sipserver.com;branch=as42tbK14rfaFhxzi
      |  From: <sip:suser@sipserver.com>;tag=49394
      |  To: <sip:xuser*xmppserver.com@xmpp.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

      |  <presence id='1'
      |        from='suser*sipserver.com@sip.xmppserver.com'
      |        to='xuser@xmppserver.com'
      |        type='subscribe'/>





Mierla                   Expires April 22, 2004                [Page 11]


Internet-Draft          SIMPLE-XMPP Interworking            October 2003


                                Figure 5



Author's Address

   Daniel-Constantin Mierla
   Fraunhofer FOKUS
   Kaiserin-Augusta-Allee 31
   Berlin  10589
   Germany

   EMail: mierla@fokus.fraunhofer.de

Appendix A. Revision History

A.1 Changes from draft-mierla-simple-xmpp-interworking-00

   - Abstract adjusted.

   - The word Jabber is now refered only in the abstract, otherwise it
   was replaced with XMPP.

   - New examples with XMPP to SIMPLE request conversion.

   - The address translation within IWF is more intuitive in the sample
   scenario.

Appendix B. 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
   implementation of these specifications.

Appendix C. References

   [1]  B. Campbell et al. , "Session Initiation Protocol Extension for
   Instant Messaging", RFC 3428, December 2002.

   [2]  P. Saint-Andre and J. Miller, "XMPP Core", Internet-Draft
   "draft-ietf-xmpp-core-18", September 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.



Mierla                   Expires April 22, 2004                [Page 12]


Internet-Draft          SIMPLE-XMPP Interworking            October 2003


   [4]  J. Rosenberg "A Presence Event Package for the Session
   Initiation Protocol (SIP)", Internet Draft
   "draft-ietf-simple-presence-10", 2003.

   [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]  P. Saint-Andre and T. Bamonti, "XMPP CPIM Mapping",
   Internet-Draft "draft-ietf-xmpp-cpim-02", August 2003.

   [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 April 22, 2004                [Page 13]


Internet-Draft          SIMPLE-XMPP Interworking            October 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 April 22, 2004                [Page 14]


Internet-Draft          SIMPLE-XMPP Interworking            October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Mierla                   Expires April 22, 2004                [Page 15]


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