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

Versions: 00 01 02 03                                                   
Network Working Group                                     P. Saint-Andre
Internet-Draft                                 XMPP Standards Foundation
Intended status: Informational                          January 16, 2008
Expires: July 19, 2008


 Interdomain Presence Scaling Analysis for the Extensible Messaging and
                        Presence Protocol (XMPP)
               draft-saintandre-xmpp-presence-analysis-03

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 July 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document analyzes the network impact of presence sharing between
   domains that federate using the Extensible Messaging and Presence
   Protocol (XMPP).







Saint-Andre               Expires July 19, 2008                 [Page 1]


Internet-Draft           XMPP Presence Analysis             January 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Initial Stanzas  . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  State-Change Stanzas . . . . . . . . . . . . . . . . . . .  7
     4.4.  Termination Stanzas  . . . . . . . . . . . . . . . . . . .  7
     4.5.  Bottom Line  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Enterprises in Different Industries  . . . . . . . . . . .  8
     5.2.  Enterprises in the Same Industry . . . . . . . . . . . . .  9
     5.3.  Medium-Sized Service Providers . . . . . . . . . . . . . . 10
     5.4.  Large Service Providers  . . . . . . . . . . . . . . . . . 12
     5.5.  Very Large Service Providers . . . . . . . . . . . . . . . 13
   6.  Optimizations  . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Comparison With Other Presence Technologies  . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Copying Conditions  . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17



























Saint-Andre               Expires July 19, 2008                 [Page 2]


Internet-Draft           XMPP Presence Analysis             January 2008


1.  Introduction

   Presence is information about the network availability of an
   individual (or, more precisely, of a presence address of the kind
   that is often but not necessarily associated with an individual).  As
   typically designed and deployed, presence is shared only with
   authorized entities, where the authorization takes the form of a
   subscription.  (In this document, we employ the term "user" to
   signify an account that generates presence information and the term
   "contact" to signify an annount that is subscribed to the user's
   presence.)

   The sharing of basic presence information can result in a large
   volume of traffic as users log on or off throughout the life of a
   presence session, especially for users with large numbers of contacts
   (e.g., the author of this document has over 1,700 contacts in his
   presence-enabled contact list).  The volume is increased by
   communication of information beyond basic on-off network
   availability, such as availability substates (e.g., "away" and "do
   not disturb").  The volume is further increased if the presence
   "transport" is used to communicate information such as device
   capabilities, geolocation, mood, activity, even the music to which a
   user is listening.

   Such traffic may be a concern even in a standalone presence domain.
   However, when presence is shared across domain boundaries through
   presence "federation", then such traffic may introduce a more
   significant impact on the functioning of the Internet as a whole.
   Therefore it is important to analyze the traffic generated during
   interdomain communication of presence information.  This document
   provides such an analysis regarding the Extensible Messaging and
   Presence Protocol (XMPP) as defined in [XMPP-CORE] and [XMPP-IM].


2.  Assumptions

   The XMPP presence model is based on the following assumptions:

   1.   A user shares presence only with a contact whom the user has
        explicitly authorized via a presence subscription.
   2.   Presence subscriptions are long-lived: they last across presence
        sessions and indeed as long as the user and contact maintain
        their XMPP accounts (until and unless the subscription is
        cancelled by one of the parties).
   3.   The typical subscription state is a bidirectional subscription
        from the contact to the user and from the user to the contact
        (so that both entities can view each other's presence).




Saint-Andre               Expires July 19, 2008                 [Page 3]


Internet-Draft           XMPP Presence Analysis             January 2008


   4.   Users have presence sessions, i.e., times in which they
        advertise their network availability to their contacts.
   5.   Not all registered users have an active presence session at any
        one time.  In typical usage patterns, the number of online users
        is some percentage of the number of registered users.  Within an
        organization, the precentage might be as high as 50%.  At a
        consumer-oriented provider of presence-enabled communication
        services, the percentage might be 10% or less.
   6.   A presence session is initiated when a user's client sends an
        initial presence notification to its server, expressing network
        availability.
   7.   Upon receiving the initial presence notification, a user's
        server broadcasts that presence notification to all of the
        user's contacts and also sends a presence probe to all of the
        user's contacts.
   8.   Upon receiving a presence probe, a contact's server checks the
        contact's authorization policies and, if the user is authorized
        and the contact is online, sends a presence notification to the
        probing user.
   9.   During the life of the user's presence session, any subsequent
        changes to the user's presence information are broadcasted via
        presence notifications sent by the user's server to the user's
        online contacts.
   10.  Presence notifications are not acknowledged by the recipient.
   11.  Presence notifications are generated by a user's client only to
        advertise on-off network availability, availability sub-states
        (e.g., "away" or "do not disturb") as defined in [XMPP-IM], or
        information related to the communication capabilities of the
        user's XMPP client (see [CAPS]).  Any other real-time
        notifications (a user's activity or mood, the music to which a
        user is listening, the games a user is playing, etc.) are not
        sent via the XMPP presence "transport" but instead are published
        using non-presence technologies such as the XMPP Publish-
        Subscribe extension [PUBSUB], in particular the Personal
        Eventing profile thereof (see [PEP]).
   12.  A presence session is terminated when a user's client sends an
        unavailable presence notification to its server or the server
        detects that the client is no longer online; in either case the
        user's server broadcasts an unavailable presence notification to
        all of the user's online contacts.


3.  Protocol Flows

   A user (in these examples romeo@example.net) initiates a presence
   session by sending an initial presence notification.  To provide a
   realistic example, this presence notification includes entity
   capabilities information as defined in [CAPS].



Saint-Andre               Expires July 19, 2008                 [Page 4]


Internet-Draft           XMPP Presence Analysis             January 2008


   User sends initial presence notification (200 bytes):

   <presence from='romeo@example.net/orchard'>
     <priority>5</priority>
     <c xmlns='http://jabber.org/protocol/caps'
        hash='sha-1'
        node='http://www.chatopus.com'
        ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
   </presence>

   Upon receiving the initial presence notification, the user's server
   sends an XMPP presence stanza of type "probe" to the contact (in
   these examples juliet@example.com).

   User's server sends presence probe to contact (82 bytes):

   <presence
       from='romeo@example.net/orchard'
       to='juliet@example.com'
       type='probe'/>

   If the contact's server determines that the user is authorized to see
   the contact's presence, the contact's server returns the contact's
   current presence state to the user.  Here again the presence
   notification includes entity capabilities information.

   Contact's server sends presence notification to user (311 bytes):

   <presence
       from='juliet@example.com/balcony'
       to='romeo@example.net/orchard'
       xml:lang='en'>
     <show>away</show>
     <status>be right back</status>
     <priority>0</priority>
     <c xmlns='http://jabber.org/protocol/caps'
        hash='sha-1'
        node='http://code.google.com/p/exodus'
        v='0.9.1'
        ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
   </presence>

   If the contact subsequently changes her presence, the contact's
   server sends an updated presence notification to the user.







Saint-Andre               Expires July 19, 2008                 [Page 5]


Internet-Draft           XMPP Presence Analysis             January 2008


   Contact's server sends updated presence to user (301 bytes):

   <presence
       from='juliet@example.com/balcony'
       to='romeo@example.net/orchard'
       xml:lang='en'>
     <show>xa</show>
     <status>bbiab</status>
     <priority>0</priority>
     <c xmlns='http://jabber.org/protocol/caps'
        hash='sha-1'
        node='http://code.google.com/p/exodus'
        v='0.9.1'
        ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
   </presence>

   A presence session can include any number of subsequent presence
   changes.

   When the user goes offline, the user's server sends a presence stanza
   of type "unavailable" to the contact.

   User's server sends unavailable presence to contact (96 bytes):

   <presence
       from='romeo@example.net/orchard'
       to='juliet@example.com/balcony'
       type='unavailable'/>

   Naturally, similar protocol flows are generated by the contact during
   her presence session.


4.  Analysis

   Traffic calculations are based on the following inputs and formulae.

4.1.  Constants

   o  (C1) Presence session lifetime in hours -- assumed to be 8 hours
      in all scenarios.
   o  (C2) Presence state changes per hour -- assumed to be 3 times per
      hour in most scenarios.
   o  (C3) Total federated contacts per user -- varies according to the
      scenario.
   o  (C4) Number of online contacts -- varies according to the
      scenario.




Saint-Andre               Expires July 19, 2008                 [Page 6]


Internet-Draft           XMPP Presence Analysis             January 2008


   o  (C5) Number of federated users -- varies according to the
      scenario.
   o  (C6) Number of online users -- varies according to the scenario.
   o  (C7) Size of presence probe sent by user's server upon receipt of
      initial outbound presence notification -- 100 bytes.
   o  (C8) Size of presence notifications sent by users and contacts --
      300 bytes.
   o  (C9) Size of unavailable presence notifications -- 100 bytes.

4.2.  Initial Stanzas

   When a user initiates a presence session, the following presence
   stanzas are exchanged.

   o  (I1) Number of outbound presence notifications = 1 per federated
      contact (C3).
   o  (I2) Size of outbound presence notifications = (C3*C8).
   o  (I3) Number of presence probes = one per federated contact (C3).
   o  (I4) Size of presence probes = (C3*C7).
   o  (I5) Number of inbound presence notifications = 1 per online
      contact (C4).
   o  (I6) Size of inbound presence notifications = (C4*C8).
   o  (I7) Total number of initial stanzas = (I1+I3+I5).
   o  (I8) Total size of initial stanzas = (I2+I4+I6).

4.3.  State-Change Stanzas

   During the life of a user's presence session, the following presence
   stanzas are exchanged as a result of changes in the user's
   availability.

   o  (S1) Number of presence state changes per user = (C1*C2)-2).
   o  (S2) Number of outbound presence notifications = (S1*C4).
   o  (S3) Size of presence notifications = (S2*C8).

4.4.  Termination Stanzas

   When a user terminates a presence session, the following presence
   stanzas are exchanged.

   o  (T1) Number of unavailable presence notifications = 1 per online
      contact (C4).
   o  (T2) Size of unavailable presence notifications = (C4*C9).

4.5.  Bottom Line

   The foregoing assumptions result in the following number and size of
   stanzas exchanged per user per presence session.



Saint-Andre               Expires July 19, 2008                 [Page 7]


Internet-Draft           XMPP Presence Analysis             January 2008


   o  (B1) Number of stanzas exchanged per presence session =
      (I7+S2+T1).
   o  (B2) Size of stanzas exchanged per presence session = (I8+S3+T2).

   Therefore the total number and size of stanzas exchanged between two
   federated domains is as follows (i.e., summed for all online users).

   o  (B3) Total number of stanzas exchanged = (B1*C6).
   o  (B4) Total size of stanzas exchanged = (B2*C6).
   o  (B5) Total stanzas exchanged per second = (B3/(C1*3600)).
   o  (B6) Total bytes exchanged per second = (B4/(C1*3600)).


5.  Scenarios

5.1.  Enterprises in Different Industries

   This scenario assumes two domains, each with 20,000 users, where each
   user has 4 contacts in the other domain, each user changes presence 3
   times per hour during an 8-hour presence session, and 50% of the
   users are online at any one time.  Such a scenario might be
   applicable to presence federation between two medium-sized
   enterprises in different industries.




























Saint-Andre               Expires July 19, 2008                 [Page 8]


Internet-Draft           XMPP Presence Analysis             January 2008


   CONSTANTS
   (C1) Presence session lifetime (hours) ....................... 8
   (C2) Presence state changes per hour ......................... 3
   (C3) Total federated contacts per user ....................... 4
   (C4) Number of online contacts per user ...................... 2
   (C5) Number of federated users .......................... 40,000
   (C6) Number of online users ............................. 20,000
   (C7) Size of presence probes ............................... 100
   (C8) Size of presence notifications ........................ 300
   (C9) Size of unavailable presence notification ............. 100

   INITIAL STANZAS
   (I1) Number of outbound presence notifications ............... 4
   (I2) Size of outbound presence notifications ............. 1,200
   (I3) Number of presence probes per user ...................... 4
   (I4) Size of presence probes per user ...................... 400
   (I5) Number of inbound presence notifications ................ 2
   (I6) Size of inbound presence notifications ................ 600
   (I7) Total number of initial stanzas ........................ 10
   (I8) Total size of initial stanzas ....................... 2,200

   STATE CHANGE STANZAS
   (S1) Number of state changes per user ....................... 22
   (S2) Number of outbound presence notifications .............. 44
   (S3) Size of outbound presence notifications ............ 13,200

   TERMINATION MESSAGES
   (T1) Number of unavailable presence notifications ............ 2
   (T2) Size of unavailable presence notifications ............ 200

   BOTTOM LINE
   (B1) Number of stanzas per presence session ................. 56
   (B2) Size of stanzas per presence session ............... 15,600
   (B3) Total number of stanzas exchanged ............... 1,120,000
   (B4) Total size of stanzas exchanged ............... 312,000,000
   (B5) Total stanzas exchanged per second ..................... 39
   (B6) Total bytes exchanged per second ................... 10,833

   With compression as described under Section 6, the bytes per second
   might be as low as 1,083.

5.2.  Enterprises in the Same Industry

   This scenario assumes two domains, each with 20,000 users, where each
   user has 20 contacts in the other domain, each user changes presence
   3 times per hour during an 8-hour presence session, and 50% of the
   users are online at any one time.  Such a scenario might be
   applicable to presence federation between two medium-sized



Saint-Andre               Expires July 19, 2008                 [Page 9]


Internet-Draft           XMPP Presence Analysis             January 2008


   enterprises in the same industry.

   CONSTANTS
   (C1) Presence session lifetime (hours) ....................... 8
   (C2) Presence state changes per hour ......................... 3
   (C3) Total federated contacts per user ...................... 20
   (C4) Number of online contacts per user ..................... 10
   (C5) Number of federated users .......................... 40,000
   (C6) Number of online users ............................. 20,000
   (C7) Size of presence probes ............................... 100
   (C8) Size of presence notifications ........................ 300
   (C9) Size of unavailable presence notification ............. 100

   INITIAL STANZAS
   (I1) Number of outbound presence notifications .............. 20
   (I2) Size of outbound presence notifications ............. 6,000
   (I3) Number of presence probes per user ..................... 20
   (I4) Size of presence probes per user .................... 2,000
   (I5) Number of inbound presence notifications ............... 10
   (I6) Size of inbound presence notifications .............. 3,000
   (I7) Total number of initial stanzas ........................ 50
   (I8) Total size of initial stanzas ...................... 11,000

   STATE CHANGE STANZAS
   (S1) Number of state changes per user ....................... 22
   (S2) Number of outbound presence notifications ............. 220
   (S3) Size of outbound presence notifications ............ 66,000

   TERMINATION MESSAGES
   (T1) Number of unavailable presence notifications ........... 10
   (T2) Size of unavailable presence notifications .......... 1,000

   BOTTOM LINE
   (B1) Number of stanzas per presence session ................ 280
   (B2) Size of stanzas per presence session ............... 78,000
   (B3) Total number of stanzas exchanged ............... 5,600,000
   (B4) Total size of stanzas exchanged ............. 1,560,000,000
   (B5) Total stanzas exchanged per second .................... 194
   (B6) Total bytes exchanged per second ................... 54,167

   With compression as described under Section 6, the bytes per second
   might be as low as 5,417.

5.3.  Medium-Sized Service Providers

   This scenario assumes two domains, each with 60,000 users, where each
   user has 10 contacts in the other domain, each user changes presence
   3 times per hour during an 8-hour presence session, and 10% of the



Saint-Andre               Expires July 19, 2008                [Page 10]


Internet-Draft           XMPP Presence Analysis             January 2008


   users are online at any one time.  Such a scenario might be
   applicable to presence federation between two medium-sized service
   providers.

   CONSTANTS
   (C1) Presence session lifetime (hours) ....................... 8
   (C2) Presence state changes per hour ......................... 3
   (C3) Total federated contacts per user ...................... 10
   (C4) Number of online contacts per user ...................... 1
   (C5) Number of federated users ......................... 120,000
   (C6) Number of online users ............................. 60,000
   (C7) Size of presence probes ............................... 100
   (C8) Size of presence notifications ........................ 300
   (C9) Size of unavailable presence notification ............. 100

   INITIAL STANZAS
   (I1) Number of outbound presence notifications .............. 10
   (I2) Size of outbound presence notifications ............. 3,000
   (I3) Number of presence probes per user ..................... 10
   (I4) Size of presence probes per user .................... 1,000
   (I5) Number of inbound presence notifications ................ 1
   (I6) Size of inbound presence notifications ................ 300
   (I7) Total number of initial stanzas ........................ 21
   (I8) Total size of initial stanzas ....................... 4,300

   STATE CHANGE STANZAS
   (S1) Number of state changes per user ....................... 22
   (S2) Number of outbound presence notifications .............. 22
   (S3) Size of outbound presence notifications ............. 6,600

   TERMINATION MESSAGES
   (T1) Number of unavailable presence notifications ............ 1
   (T2) Size of unavailable presence notifications ............ 100

   BOTTOM LINE
   (B1) Number of stanzas per presence session ................. 44
   (B2) Size of stanzas per presence session ............... 11,000
   (B3) Total number of stanzas exchanged ............... 2,640,000
   (B4) Total size of stanzas exchanged ............... 660,000,000
   (B5) Total stanzas exchanged per second ..................... 92
   (B6) Total bytes exchanged per second ................... 22,917

   With compression as described under Section 6, the bytes per second
   might be as low as 2,292.







Saint-Andre               Expires July 19, 2008                [Page 11]


Internet-Draft           XMPP Presence Analysis             January 2008


5.4.  Large Service Providers

   This scenario assumes two domains, each with 300,000 users, where
   each user has 20 contacts in the other domain, each user changes
   presence 3 times per hour during an 8-hour presence session, and 10%
   of the users are online at any one time.  Such a scenario might be
   applicable to presence federation between two large service
   providers.

   CONSTANTS
   (C1) Presence session lifetime (hours) ....................... 8
   (C2) Presence state changes per hour ......................... 3
   (C3) Total federated contacts per user ...................... 20
   (C4) Number of online contacts per user ...................... 2
   (C5) Number of federated users ......................... 600,000
   (C6) Number of online users ............................ 300,000
   (C7) Size of presence probes ............................... 100
   (C8) Size of presence notifications ........................ 300
   (C9) Size of unavailable presence notification ............. 100

   INITIAL STANZAS
   (I1) Number of outbound presence notifications .............. 20
   (I2) Size of outbound presence notifications ............. 6,000
   (I3) Number of presence probes per user ..................... 20
   (I4) Size of presence probes per user .................... 2,000
   (I5) Number of inbound presence notifications ................ 2
   (I6) Size of inbound presence notifications ................ 600
   (I7) Total number of initial stanzas ........................ 42
   (I8) Total size of initial stanzas ....................... 8,600

   STATE CHANGE STANZAS
   (S1) Number of state changes per user ....................... 22
   (S2) Number of outbound presence notifications .............. 44
   (S3) Size of outbound presence notifications ............ 13,200

   TERMINATION MESSAGES
   (T1) Number of unavailable presence notifications ............ 2
   (T2) Size of unavailable presence notifications ............ 200

   BOTTOM LINE
   (B1) Number of stanzas per presence session ................. 88
   (B2) Size of stanzas per presence session ............... 22,000
   (B3) Total number of stanzas exchanged .............. 26,400,000
   (B4) Total size of stanzas exchanged ............. 6,600,000,000
   (B5) Total stanzas exchanged per second .................... 917
   (B6) Total bytes exchanged per second .................. 229,167

   With compression as described under Section 6, the bytes per second



Saint-Andre               Expires July 19, 2008                [Page 12]


Internet-Draft           XMPP Presence Analysis             January 2008


   might be as low as 22,917.

5.5.  Very Large Service Providers

   This scenario assumes two domains, each with 10,000,000 users, where
   each user has 100 contacts in the other domain, each user changes
   presence 6 times per hour during an 8-hour presence session, and 20%
   of the users are online at any one time.  Such a scenario might be
   applicable to presence federation between two very large service
   providers.

   CONSTANTS
   (C1) Presence session lifetime (hours) ....................... 8
   (C2) Presence state changes per hour ......................... 6
   (C3) Total federated contacts per user ..................... 100
   (C4) Number of online contacts per user ..................... 20
   (C5) Number of federated users ...................... 20,000,000
   (C6) Number of online users .......................... 4,000,000
   (C7) Size of presence probes ............................... 100
   (C8) Size of presence notifications ........................ 300
   (C9) Size of unavailable presence notification ............. 100

   INITIAL STANZAS
   (I1) Number of outbound presence notifications ............. 100
   (I2) Size of outbound presence notifications ............ 30,000
   (I3) Number of presence probes per user .................... 100
   (I4) Size of presence probes per user ................... 10,000
   (I5) Number of inbound presence notifications ............... 20
   (I6) Size of inbound presence notifications .............. 6,000
   (I7) Total number of initial stanzas ....................... 220
   (I8) Total size of initial stanzas ...................... 46,000

   STATE CHANGE STANZAS
   (S1) Number of state changes per user ....................... 46
   (S2) Number of outbound presence notifications ............. 920
   (S3) Size of outbound presence notifications ........... 276,000

   TERMINATION MESSAGES
   (T1) Number of unavailable presence notifications ........... 20
   (T2) Size of unavailable presence notifications .......... 2,000

   BOTTOM LINE
   (B1) Number of stanzas per presence session .............. 1,160
   (B2) Size of stanzas per presence session .............. 324,000
   (B3) Total number of stanzas exchanged ........... 4,640,000,000
   (B4) Total size of stanzas exchanged ......... 1,296,000,000,000
   (B5) Total stanzas exchanged per second ................ 161,111
   (B6) Total bytes exchanged per second ............... 45,000,000



Saint-Andre               Expires July 19, 2008                [Page 13]


Internet-Draft           XMPP Presence Analysis             January 2008


   With compression as described under Section 6, the bytes per second
   might be as low as 4,500,000.


6.  Optimizations

   This document does not focus on optimizations that can be applied to
   XMPP traffic.  The main such optimization is compression of XML
   streams.  There are several reasons why stream compression can yield
   significant reductions in the network impact of XMPP traffic,
   especially in the case of interdomain federation:

   1.  XMPP uses long-lived TCP connections in which (typically) a
       single XML parser instance is used to parse the incoming and
       outgoing XML stanzas.
   2.  The fact that XMPP stanzas are XML means that the same strings
       are repeatedly communicated over the stream (e.g., the string
       "<presence from='>), resulting in effective use of compression
       dictionaries.

   Compression of XML streams can be provided via native TLS compression
   at the transport layer (see [XMPP-CORE]) or via XMPP stream
   compression at the application layer (see [COMPRESS]).  Based on both
   testing and real-world experience, it appears that these compression
   methods can result in compressed traffic that is 10% the size of pre-
   compressed traffic.


7.  Comparison With Other Presence Technologies

   This document does not provide a formal comparison of XMPP to other
   presence technologies.  A similar analysis for presence systems based
   on the Session Initiation Protocol [SIP] as defined in [SIP-PRES] is
   provided in [PROBLEM].


8.  Security Considerations

   This document introduces and addresses no security concerns above and
   beyond those already defined in [XMPP-CORE] and [XMPP-IM].


9.  Informative References

   [CAPS]     Hildebrand, J., Saint-Andre, P., and R. Troncon, "Entity
              Capabilities", XSF XEP 0115, August 2007.

   [COMPRESS]



Saint-Andre               Expires July 19, 2008                [Page 14]


Internet-Draft           XMPP Presence Analysis             January 2008


              Hildebrand, J. and P. Saint-Andre, "Stream Compression",
              XSF XEP 0138, September 2007.

   [PEP]      Saint-Andre, P. and K. Smith, "Personal Eventing via
              Pubsub", XSF XEP 0163, September 2007.

   [PROBLEM]  Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
              and H. Schulzrinne, "Presence Interdomain Scaling Analysis
              for SIP/SIMPLE",
              draft-ietf-simple-interdomain-scaling-analysis-03 (work in
              progress), November 2007.

   [PUBSUB]   Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
              Subscribe", XSF XEP 0060, September 2007.

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

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

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

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


Appendix A.  Copying Conditions

   The Contributor grants third parties the irrevocable right to copy,
   use and distribute the Contribution, with or without modification, in
   any medium, without royalty, provided that, unless separate
   permission is granted, redistributed modified works:

   1.  do not contain misleading author, version, name of work, or
       endorsement information, and
   2.  do not claim endorsement of the modified work by the Contributor,
       or any organization the Contributor belongs to, the Internet
       Engineering Task Force (IETF), Internet Research Task Force
       (IRTF), Internet Engineering Steering Group (IESG), Internet
       Architecture Board (IAB), Internet Assigned Numbers Authority
       (IANA), Internet Society (ISOC), Request For Comments (RFC)



Saint-Andre               Expires July 19, 2008                [Page 15]


Internet-Draft           XMPP Presence Analysis             January 2008


       Editor, or any combination or variation of such terms (including
       without limitation the IETF "4 diamonds" logo), or any terms that
       are confusingly similar thereto, and
   3.  remove any claims of status as an Internet Standard, including
       without limitation removing the RFC boilerplate.

   The IETF suggests that any citation or excerpt of unmodified text
   reference the RFC or other document from which the text is derived.


Author's Address

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

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































Saint-Andre               Expires July 19, 2008                [Page 16]


Internet-Draft           XMPP Presence Analysis             January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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               Expires July 19, 2008                [Page 17]