SIMPLE                                                      J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Informational                                  A. Houri
Expires: January 15, 2009                                            IBM
                                                                C. Smyth
                                                                   Avaya
                                                           July 14, 2008


 Models for Intra-Domain Presence and Instant Messaging (IM) Federation
              draft-ietf-simple-intradomain-federation-01

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 January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   Presence and Instant Messaging (IM) federation involves the sharing
   of presence information and exchange of IM across multiple systems.
   Most often, presence and IM federation is assumed to be between
   different organizations, such as between two enterprises or between
   and enterprise and a service provider.  However, federation can occur



Rosenberg, et al.       Expires January 15, 2009                [Page 1]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   within a single organization or domain.  This can be the result of a
   multi-vendor network, or a consequence of a large organization that
   requires partitioning.  This document examines different use cases
   and models for intra-domain presence and IM federation.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Intra-Domain Federation vs. Clustering . . . . . . . . . . . .  7
   3.  Use Cases for Intra-Domain Federation  . . . . . . . . . . . .  8
     3.1.  Scale  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Organizational Structures  . . . . . . . . . . . . . . . .  8
     3.3.  Multi-Vendor Requirements  . . . . . . . . . . . . . . . .  8
     3.4.  Specialization . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Considerations for Federation Models . . . . . . . . . . . . .  9
   5.  Partitioned  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Centralized Database . . . . . . . . . . . . . . . . . 12
       5.2.2.  Routing Proxy  . . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  Subdomaining . . . . . . . . . . . . . . . . . . . . . 14
       5.2.4.  Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . 16
       5.2.5.  Forking  . . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.6.  Provisioned Routing  . . . . . . . . . . . . . . . . . 16
     5.3.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.4.  Presence Data  . . . . . . . . . . . . . . . . . . . . . . 17
     5.5.  Conversation Consistency . . . . . . . . . . . . . . . . . 17
   6.  Exclusive  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . . 18
       6.1.1.  Centralized Database . . . . . . . . . . . . . . . . . 19
       6.1.2.  Routing Proxy  . . . . . . . . . . . . . . . . . . . . 19
       6.1.3.  Subdomaining . . . . . . . . . . . . . . . . . . . . . 19
       6.1.4.  Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . 20
       6.1.5.  Forking  . . . . . . . . . . . . . . . . . . . . . . . 20
     6.2.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.3.  Presence Data  . . . . . . . . . . . . . . . . . . . . . . 21
     6.4.  Conversation Consistency . . . . . . . . . . . . . . . . . 21
   7.  Unioned  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     7.1.  Hierarchical Model . . . . . . . . . . . . . . . . . . . . 25
       7.1.1.  Routing  . . . . . . . . . . . . . . . . . . . . . . . 27
       7.1.2.  Policy and Identity  . . . . . . . . . . . . . . . . . 28
         7.1.2.1.  Root Only  . . . . . . . . . . . . . . . . . . . . 28
         7.1.2.2.  Distributed Provisioning . . . . . . . . . . . . . 30
         7.1.2.3.  Central Provisioning . . . . . . . . . . . . . . . 32
         7.1.2.4.  Centralized PDP  . . . . . . . . . . . . . . . . . 34
       7.1.3.  Presence Data  . . . . . . . . . . . . . . . . . . . . 36
       7.1.4.  Conversation Consistency . . . . . . . . . . . . . . . 36



Rosenberg, et al.       Expires January 15, 2009                [Page 2]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


     7.2.  Peer Model . . . . . . . . . . . . . . . . . . . . . . . . 37
       7.2.1.  Routing  . . . . . . . . . . . . . . . . . . . . . . . 39
       7.2.2.  Policy . . . . . . . . . . . . . . . . . . . . . . . . 40
       7.2.3.  Presence Data  . . . . . . . . . . . . . . . . . . . . 40
       7.2.4.  Conversation Consistency . . . . . . . . . . . . . . . 40
   8.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   9.  Future Considerations  . . . . . . . . . . . . . . . . . . . . 41
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 41
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
   13. Informative References . . . . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
   Intellectual Property and Copyright Statements . . . . . . . . . . 44






































Rosenberg, et al.       Expires January 15, 2009                [Page 3]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


1.  Introduction

   Presence refers to the ability, willingness and desire to communicate
   across differing devices, mediums and services [RFC2778].  Presence
   is described using presence documents [RFC3863] [RFC4479], exchanged
   using a Session Initiation Protocol (SIP) [RFC3261] based event
   package [RFC3856]

   Presence federation refers to the sharing of presence information
   across multiple presence systems.  This interconnection involves
   passing of subscriptions from one system to another, and then the
   passing of notifications in the opposite direction.

   Similarly, instant messaging refers to the exchange of real-time
   text-oriented messaging between users.  SIP defines two mechanisms
   for IM - pager mode [RFC3428] and session mode [RFC4975].  IM
   federation refers to the exchange of IM between users in different IM
   systems.

   Most often, presence and IM federation is considered in the context
   of interconnection between different domains, also known as inter-
   domain federation
   [I-D.ietf-speermint-consolidated-presence-im-usecases].  For example,
   consider the network of Figure 1, which shows one model for inter-
   domain presence federation.  In this network, Alice belongs to the
   example.org domain, and Bob belongs to the example.com domain.  Alice
   subscribes to her buddy list on her presence server (which is also
   acting as her Resource List Server (RLS) [RFC4662]), and that list
   includes bob@example.com.  Alice's presence server generates a back-
   end subscription on the federated link between example.org and
   example.com.  The example.com presence server authorizes the
   subscription, and if permitted, generates notifications back to
   Alice's presence server, which are in turn passed to Alice.


















Rosenberg, et al.       Expires January 15, 2009                [Page 4]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


     .............................     ..............................
     .                           .     .                            .
     .                           .     .                            .
     .     alice@example.org     .     .      bob@example.com       .
     .      +------------+   SUB .     .      +------------+        .
     .      |            |   Bob .     .      |            |        .
     .      |  Presence  |------------------->|  Presence  |        .
     .      |   Server   |       .     .      |   Server   |        .
     .      |            |       .     .      |            |        .
     .      |            |<-------------------|            |        .
     .      |            |     NOTIFY  .      |            |        .
     .      +------------+       .     .      +------------+        .
     .          ^    |           .     .             ^              .
     .      SUB |    |           .     .             |PUB           .
     .    Buddy |    |NOTIFY     .     .             |              .
     .     List |    |           .     .             |              .
     .          |    |           .     .             |              .
     .          |    V           .     .             |              .
     .         +-------+         .     .        +-------+           .
     .         |       |         .     .        |       |           .
     .         |       |         .     .        |       |           .
     .         |       |         .     .        |       |           .
     .         +-------+         .     .        +-------+           .
     .                           .     .                            .
     .           Alice's         .     .           Bob's            .
     .             PC            .     .            PC              .
     .                           .     .                            .
     .............................     ..............................

              example.org                       example.com


                   Figure 1: Inter-Domain Presence Model

   Similarly, inter-domain IM federation would look like the model shown
   in Figure 2:















Rosenberg, et al.       Expires January 15, 2009                [Page 5]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


     .............................     ..............................
     .                           .     .                            .
     .                           .     .                            .
     .     alice@example.org     .     .      bob@example.com       .
     .      +------------+   INV .     .      +------------+        .
     .      |            |   Bob .     .      |            |        .
     .      |            |------------------->|            |        .
     .      |     IM     |       .     .      |      IM    |        .
     .      |   Server   |       .     .      |    Server  |        .
     .      |            |<------------------>|            |        .
     .      |            |       IM           |            |        .
     .      +------------+       Content      +------------+        .
     .          ^    ^           .     .          ^    |            .
     .   INVITE |    |           .     .   IM     |    |INV         .
     .   Bob    |    | IM        .     .   Content|    |Bob         .
     .          |    | Content   .     .          |    |            .
     .          |    |           .     .          |    |            .
     .          |    V           .     .          V    V            .
     .         +-------+         .     .        +-------+           .
     .         |       |         .     .        |       |           .
     .         |       |         .     .        |       |           .
     .         |       |         .     .        |       |           .
     .         +-------+         .     .        +-------+           .
     .                           .     .                            .
     .           Alice's         .     .           Bob's            .
     .             PC            .     .            PC              .
     .                           .     .                            .
     .............................     ..............................

              example.org                       example.com

                      Figure 2: Inter-Domain IM Model

   In this model, example.org and example.com both have an "IM server".
   This would typically be a SIP proxy or B2BUA responsible for handling
   both the signaling and the IM content (as these are separate in the
   case of session mode).  The IM server would handle routing of the IM
   along with application of IM policy.

   Though both of these pictures show federation as being between
   domains, it can happen within a domain as well.  We define intra-
   domain federation as the interconnection of presence and IM servers
   within a single domain, where domain refers explicity to the right
   hand side of the @-sign in the SIP URI.

   This document considers the architectural models and different
   problems that arise when performing intra-domain presence and IM
   federation.  Though presence and IM are quite distinct functions,



Rosenberg, et al.       Expires January 15, 2009                [Page 6]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   this document considers both since the architectural models and
   issues are common between the two.  The document first clarifies the
   distinction between intra-domain federation and clustering.  It
   defines the primary issues that arise in intra-domain presence and IM
   federation, and then goes on to define the three primary models for
   it - partitioned, unioned and exclusive.


2.  Intra-Domain Federation vs. Clustering

   Intra-domain federation is the interconnection of servers within a
   single domain.  This is very similar to clustering, which is the
   tight coupling of a multiplicity of physical servers to realize scale
   and/or high availability.  Consequently, it is important to clarify
   the differences.

   Firstly, clustering implies a tight coupling of components.
   Clustering usually involves proprietary information sharing, such as
   database replication and state sharing, which in turn are tightly
   bound with the internal implementation of the product.  Intra-domain
   federation, on the other hand, is a loose coupling.  There is never
   database replication or state replication across federated systems
   (though a database and DB replication might be used within a
   component providing routing functions to facilitate federation).

   Secondly, clustering always occurs amongst components from the same
   vendor.  This is due to the tight coupling described above.  Intra-
   domain federation, on the other hand, can occur between servers from
   different vendors.  As described below, this is one of the chief use
   cases for intra-domain federation.

   Thirdly, clustering is almost always invisible to users.
   Communications between users within the same cluster almost always
   have identical functionality to communications between users on the
   same server within the cluster.  The cluster boundaries are
   invisible; indeed the purpose of a cluster is to build a system which
   behaves as if it were a single monolithic entity, even though it is
   not.  Federation, on the other hand, is often visible to users.
   There will frequently be loss of functionality when crossing a
   cluster.  Though this is not a hard and fast rule, it is a common
   differentiator.

   Fourthly, connections between federated systems almost always involve
   standards, whereas communications within a cluster often involves
   proprietary mechanisms.  Standards are needed for federation because
   the federated systems can be from different vendors, and thus
   agreement is needed to enable interoperation.




Rosenberg, et al.       Expires January 15, 2009                [Page 7]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   Finally, a cluster will often have an upper bound on its size and
   capacity, due to some kind of constraint on the coupling between
   nodes in the cluster.  However, there is typically no limit, or a
   much larger limit, on the number of federated systems that can be put
   into a domain.  This is a consequence to their loose coupling.

   Though these rules are not hard and fast, they give general
   guidelines on the differences between clustering and intra-domain
   federation.


3.  Use Cases for Intra-Domain Federation

   There are several use cases that drive intra-domain federation.

3.1.  Scale

   One common use case for federation is an organization that is just
   very large, and their size exceeds the capacity that a single server
   or cluster can provide.  So, instead, the domain breaks its users
   into partitions (perhaps arbitrarily) and then uses intra-domain
   federation to allow the overall system to scale up to arbitrary
   sizes.  This is common practice today for service providers and large
   enterprises.

3.2.  Organizational Structures

   Another use case for intra-domain federation is a multi-national
   organization with regional IT departments, each of which supports a
   particular set of nationalities.  It is very common for each regional
   IT department to deploy and run its own servers for its own
   population.  In that case, the domain would end up being composed of
   the presence servers deployed by each regional IT department.
   Indeed, in many organizations, each regional IT department might end
   up using different vendors.  This can be a consequence of differing
   regional requirements for features (such as compliance or
   localization support), differing sales channels and markets in which
   vendors sell, and so on.

3.3.  Multi-Vendor Requirements

   Another use case for intra-domain federation is an organization that
   requires multiple vendors for each service, in order to avoid vendor
   lock in and drive competition between its vendors.  Since the servers
   will come from different vendors, a natural way to deploy them is to
   partition the users across them.  Such multi-vendor networks are
   extremely common in large service provider networks, many of which
   have hard requirements for multiple vendors.



Rosenberg, et al.       Expires January 15, 2009                [Page 8]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   Typically, the vendors are split along geographies, often run by
   different local IT departments.  As such, this case is similar to the
   organizational division above.

3.4.  Specialization

   Another use case is where certain vendors might specialize in
   specific types of clients.  For example, one vendor might provide a
   mobile client (but no desktop client), while another provides a
   desktop client but no mobile client.  It is often the case that
   specific client applications and devices are designed to only work
   with their corresponding servers.  In an ideal world, clients would
   all implement to standards and this would not happen, but in
   practice, the vast majority of presence and IM endpoints work only
   (or only work well) with the server from the same vendor.  A domain
   might want each user to have both a mobile client and a desktop
   client, which will require servers from each vendor, leading to
   intra-domain federation.

   Similarly, presence can contain rich information, including
   activities of the user (such as whether they are in a meeting or on
   the phone), their geographic location, and their mood.  This presence
   state can be determined manually (where the user enters and updates
   the information), or automatically.  Automatic determination of these
   states is far preferable, since it puts less burden on the user.
   Determination of these presence states is done by taking "raw" data
   about the user, and using it to generate corresponding presence
   states.  This raw data can come from any source that has information
   about the user, including their calendaring server, their VoIP
   infrastructure, their VPN server, their laptop operating system, and
   so on.  Each of these components is typically made by different
   vendors, each of which is likely to integrate that data with their
   presence servers.  Consequently, presence servers from different
   vendors are likely to specialize in particular pieces of presence
   data, based on the other infrastructure they provide.  The overall
   network will need to contain servers from those vendors, composing
   together the various sources of information, in order to combine
   their benefits.  This use case is specified to presence, and results
   in intra-domain federation.


4.  Considerations for Federation Models

   When considering architectures for intra-domain presence and IM
   federation, several issues need to be considered.  The first two of
   these apply to both IM and presence (and indeed to any intra-domain
   communications, including voice).  The latter two are specific to
   presence and IM respectively:



Rosenberg, et al.       Expires January 15, 2009                [Page 9]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   Routing:  How are subscriptions and IMs routed to the right presence
      and IM server(s)?  This issue is more complex in intra-domain
      models, since the right hand side of the @-sign cannot be used to
      perform this routing.

   Policy and Identity:  Where do user policies reside, and what
      presence and IM server(s) are responsible for executing that
      policy?  What identities does the user have in each system and how
      do they relate?

   Presence Data Ownership:  Which presence servers are responsible for
      which pieces of presence information, and how are those pieces
      composed to form a coherent and consistent view of user presence?

   Conversation Consistency:  When considering instant messaging, if IM
      can be delivered to multiple servers, how do we make sure that the
      overall conversation is coherent to the user?

   The sections below describe several different models for intra-domain
   federation.  Each model is driven by a set of use cases, which are
   described in an applicability subsection for each model.  Each model
   description also discusses how routing, policy, presence data
   ownership and conversation consistency work.


5.  Partitioned

   In the partitioned model, a single domain has a multiplicity of
   servers, each of which manages a non-overlapping set of users.  That
   is, for each user in the domain, their presence data, policy and IM
   handling reside on a single server.  Each "single server" may in fact
   be a cluster.

   Another important facet of the partitioned model is that, even though
   users are partitioned across different servers, they each share the
   same domain name in the right hand side of their URI, and this URI is
   what those users use when communicating with other users both inside
   and outside of the domain.  There are many reasons why a domain would
   want all of its users to share the same right-hand side of the @-sign
   even though it is partitioned internally:

   o  The partitioning may reflect organizational or geographical
      structures that a domain admistrator does not want to reflect
      externally.

   o  If each partition had a separate domain name (i.e.,
      engineering.example.com and sales.example.com), if a user changed
      organizations, this would necessitate a change in their URI.



Rosenberg, et al.       Expires January 15, 2009               [Page 10]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   o  For reasons of vanity, users often like to have their URI (which
      appear on business cards, email, and so on), to be brief and
      short.

   o  If a watcher wants to add a presentity based on username and does
      not want to know, or does not know, which subdomain or internal
      department the presentity belongs to, a single domain is needed.

   This model is illustrated in Figure 3.  As the model shows, the
   domain example.com has six users across three servers, each of which
   is handling two of the users.


   .....................................................................
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .   joe@example.com      alice@example.com     padma@example.com    .
   .   bob@example.com      zeke@example.com      hannes@example.com   .
   .    +-----------+        +-----------+       +-----------+         .
   .    |           |        |           |       |           |         .
   .    |   Server  |        |   Server  |       |   Server  |         .
   .    |     1     |        |     2     |       |     3     |         .
   .    |           |        |           |       |           |         .
   .    +-----------+        +-----------+       +-----------+         .
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .                           example.com                             .
   .....................................................................

                        Figure 3: Partitioned Model

5.1.  Applicability

   The partitioned model arises naturally in larger domains, such as an
   enterprise or service provider, where issues of scale, organizational
   structure, or multi-vendor requirements cause the domain to be
   managed by a multiplicity of independent servers.

   In cases where each user has an AoR that directly points to its
   partition (for example, us.example.com), that model becomes identical
   to the inter-domain federated model and is not treated here further.

5.2.  Routing

   The partitioned intra-domain model works almost identically to an
   inter-domain federated model, with the primary difference being



Rosenberg, et al.       Expires January 15, 2009               [Page 11]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   routing.  In inter-domain federation, the domain part of the URI can
   be used to route presence subscriptions and IM messages from one
   domain to the other.  This is no longer the case in an intra-domain
   model.  Consider the case where Joe subscribes to his buddy list,
   which is served by his presence server (server 1 in Figure 3).  Alice
   is a member of Joe's buddy list.  How does server 1 know that the
   back-end subscription to Alice needs to get routed to server 2?

   There are several techniques that can be used to solve this problem,
   which are outlined in the subsections below.

5.2.1.  Centralized Database


   .....................................................................
   .                         +-----------+                             .
   .           alice?        |           |                             .
   .       +---------------> |  Database |                             .
   .       |   server 2      |           |                             .
   .       |   +-------------|           |                             .
   .       |   |             +-----------+                             .
   .       |   |                                                       .
   .       |   |                                                       .
   .       |   |                                                       .
   .       |   |                                                       .
   .       |   |                                                       .
   .       |   |                                                       .
   .       |   V                                                       .
   .   joe@example.com      alice@example.com     padma@example.com    .
   .   bob@example.com      zeke@example.com      hannes@example.com   .
   .    +-----------+        +-----------+       +-----------+         .
   .    |           |        |           |       |           |         .
   .    |   Server  |        |   Server  |       |   Server  |         .
   .    |     1     |        |     2     |       |     3     |         .
   .    |           |        |           |       |           |         .
   .    +-----------+        +-----------+       +-----------+         .
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .                           example.com                             .
   .....................................................................


                         Figure 4: Centralized DB

   One solution is to rely on a common, centralized database that
   maintains mappings of users to specific servers, shown in Figure 4.
   When Joe subscribes to his buddy list that contains Alice, server 1



Rosenberg, et al.       Expires January 15, 2009               [Page 12]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   would query this database, asking it which server is responsible for
   alice@example.com.  The database would indicate server 2, and then
   server 1 would generate the backend SUBSCRIBE request towards server
   2.  Similarly, when Joe sends an INVITE to establish an IM session
   with Padma, he would send the IM to his IM server, an it would query
   the database to find out that Padma is supported on server 3.  This
   is a common technique in large email systems.  It is often
   implemented using internal sub-domains; so that the database would
   return alice@central.example.com to the query, and server 1 would
   modify the Request-URI in the request to reflect this.

   Routing database solutions have the problem that they require
   standardization on a common schema and database protocol in order to
   work in multi-vendor environments.  For example, LDAP and SQL are
   both possibilities.  There is variety in LDAP schema; one possibility
   is H.350.4, which could be adapted for usage here [RFC3944].

5.2.2.  Routing Proxy


   .....................................................................
   .                         +-----------+                             .
   .        SUB/INV alice    |           |                             .
   .       +---------------> |  Routing  |                             .
   .       |                 |   Proxy   |                             .
   .       |                 |           |                             .
   .       |                 +-----------+                             .
   .       |                       |                                   .
   .       |                       |                                   .
   .       |                       |                                   .
   .       |                       |SUB/INV alice                      .
   .       |                       |                                   .
   .       |                       |                                   .
   .       |                       V                                   .
   .   joe@example.com      alice@example.com     padma@example.com    .
   .   bob@example.com      zeke@example.com      hannes@example.com   .
   .    +-----------+        +-----------+       +-----------+         .
   .    |           |        |           |       |           |         .
   .    |   Server  |        |   Server  |       |   Server  |         .
   .    |     1     |        |     2     |       |     3     |         .
   .    |           |        |           |       |           |         .
   .    +-----------+        +-----------+       +-----------+         .
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .                           example.com                             .
   .....................................................................




Rosenberg, et al.       Expires January 15, 2009               [Page 13]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


                          Figure 5: Routing Proxy

   A similar solution is to rely on a routing proxy or B2BUA.  Instead
   of a centralized database, there would be a centralized SIP proxy
   farm.  Server 1 would send requests (SUBSCRIBE, INVITE, etc.) for
   users it doesn't serve to this server farm, and the servers would
   lookup the user in a database (which is now accessed only by the
   routing proxy), and the resulting requests are sent to the correct
   server.  A redirect server can be used as well, in which case the
   flow is very much like that of a centralized database, but uses SIP.

   Routing proxies have the benefit that they do not require a common
   database schema and protocol, but they do require a centralized
   server function that sees all subscriptions and IM requests, which
   can be a scale challenge.  For IM, a centralized proxy is very
   challenging when using pager mode, since each and every IM is
   processed by the central proxy.  For session mode, the scale is
   better, since the proxy handles only the initial INVITE.

5.2.3.  Subdomaining

   In this solution, each user is associated with a subdomain, and is
   provisioned as part of their respective server using that subdomain.
   Consequently, each server thinks it is its own, separate domain.
   However, when a user adds a presentity to their buddy list without
   the subdomain, they first consult a shared database which returns the
   subdomained URI to subscribe or IM to.  This sub-domained URI can be
   returned because the user provided a search criteria, such as "Find
   Alice Chang", or provided the non-subdomained URI
   (alice@example.com).  This is shown in Figure 6





















Rosenberg, et al.       Expires January 15, 2009               [Page 14]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   .....................................................................
   .                         +-----------+                             .
   .    who is Alice?        |           |                             .
   . +---------------------->|  Database |                             .
   . |  alice@b.example.com  |           |                             .
   . | +---------------------|           |                             .
   . | |                     +-----------+                             .
   . | |                                                               .
   . | |                                                               .
   . | |                                                               .
   . | |                                                               .
   . | |                                                               .
   . | |                                                               .
   . | |                                                               .
   . | | joe@a.example.com   alice@b.example.com  padma@c.example.com  .
   . | | bob@a.example.com   zeke@b.example.com   hannes@c.example.com .
   . | |  +-----------+        +-----------+       +-----------+       .
   . | |  |           |        |           |       |           |       .
   . | |  |   Server  |        |   Server  |       |   Server  |       .
   . | |  |     1     |        |     2     |       |     3     |       .
   . | |  |           |        |           |       |           |       .
   . | |  +-----------+        +-----------+       +-----------+       .
   . | |                            ^                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                     +-----------+                             .
   . | +-------------------->|           |                             .
   . |                       |  Client   |                             .
   . |                       |           |                             .
   . +-----------------------|           |                             .
   .                         +-----------+                             .
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .                           example.com                             .
   .....................................................................



                          Figure 6: Subdomaining

   Subdomaining puts the burden of routing within the client.  The
   servers can be completely unaware that they are actually part of the
   same domain, and integrate with each other exactly as they would in
   an inter-domain model.  However, the client is given the burden of



Rosenberg, et al.       Expires January 15, 2009               [Page 15]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   determining the subdomained URI from the original URI or buddy name,
   and then subscribing or IMing directly to that server, or including
   the subdomained URI in their buddylist.  The client is also
   responsible for hiding the subdomain structure from the user and
   storing the mapping information locally for extended periods of time.
   In cases where users have buddy list subscriptions, the client will
   need to resolve the buddy name into the sub-domained version before
   adding to their buddy list.

5.2.4.  Peer-to-Peer

   Another model is to utilize a peer-to-peer network amongst all of the
   servers, and store URI to server mappings in the distributed hash
   table it creates.  This has some nice properties but does require a
   standardized and common p2p protocol across vendors, which does not
   exist today.

5.2.5.  Forking

   Yet another solution is to utilize forking.  Each server is
   provisioned with the domain names or IP addresses of the other
   servers, but not with the mapping of users to each of those servers.
   When a server needs to handle a request for a user it doesn't have,
   it forks the request to all of the other servers.  This request will
   be rejected with a 404 on the servers which do not handle that user,
   and accepted on the one that does.  The approach assumes that servers
   can differentiate inbound requests from end users (which need to get
   passed on to other servers - for example via a back-end subscription)
   and from other servers (which do not get passed on).  This approach
   works very well in organizations with a relatively small number of
   servers (say, two or three), and becomes increasingly ineffective
   with more and more servers.

5.2.6.  Provisioned Routing

   Yet another solution is to provision each server with each user, but
   for servers that don't actually serve the user, the provisioning
   merely tells the server where to proxy the request.  This solution
   has extremely poor operational properties, requiring multiple points
   of provisioning across disparate systems.

5.3.  Policy

   A fundamental characteristic of the partitioned model is that there
   is a single point of policy enforcement (authorization rules and
   composition policy) for each user.





Rosenberg, et al.       Expires January 15, 2009               [Page 16]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


5.4.  Presence Data

   Another fundamental characteristic of the partitioned model is that
   the presence data for a user is managed authoritatively on a single
   server.  In the example of Figure 3, the presence data for Alice
   lives on server 2 alone (recall that server two may be physically
   implemented as a multiplicity of boxes from a single vendor, each of
   which might have a portion of the presence data, but externally it
   appears to behave as if it were a single server).  A subscription
   from Bob to Alice may cause a transfer of presence information from
   server 2 to server 1, but server 2 remains authoritative and is the
   single root source of all data for Alice.

5.5.  Conversation Consistency

   Since the IM for a particular user are always delivered through a
   particular server that handles the user, it is relatively easy to
   achieve conversation consistency.  That server receives all of the
   messages and readily pass them onto the user for rendering.
   Furthermore, a coherent view of message history can be assembled by
   the server, since it sees all messages.  If a user has multiple
   devices, there are challenges in constructing a consistent view of
   the conversation with page mode IM.  However, those issues exist in
   general with page mode and are not worsened by intra-domain
   federation.


6.  Exclusive

   In the former (static) partitioned model, the mapping of a user to a
   specific server is done by some off-line configuration means.  The
   configuration assigns a user to a specific server and in order to use
   a different server, the user needs to change (or request the
   administrator to do so) the configuration.

   In some environments, this restriction of a user to use a particular
   server may be a limitation.  Instead, it is desirable to allow users
   to freely move back and forth between systems, though using only a
   single one at a time.  This is called Exclusive Federation.

   Some use cases where this can happen are:

   o  The organization is using multiple systems where each system has
      its own characteristics.  For example one server is tailored to
      work with some CAD (Computer Aided Design) system and provide
      presence and IM functionality along with the CAD system.  The
      other server is the default presence and IM server of the
      organization.  Users wish to be able to work with either system



Rosenberg, et al.       Expires January 15, 2009               [Page 17]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


      when they wish to, they also wish to be able to see the presence
      and IM with their buddies no matter which system their buddies are
      currently using.

   o  An enterprise wishes to test presence servers from two different
      vendors.  In order to do so they wish to install a server from
      each vendor and see which of the servers is better.  In the static
      partitioned model, a user will have to be statically assigned to a
      particular server and could not compare the features of the two
      servers.  In the dynamic partitioned model, a user may choose on
      whim which of the servers that are being tested to use.  They can
      move back and forth in case of problems.

   o  An enterprise is currently using servers from one vendor, but has
      decided to add a second.  They would like to gradually migrate
      users from one to the other.  In order to make a smooth
      transition, users can move back and forth over a period of a few
      weeks until they are finally required to stop going back, and get
      deleted from their old system.

   o  A domain is using multiple clusters from the same vendor.  To
      simplify administration, users can connect to any of the clusters,
      perhaps one local to their site.  To accomplish this, the clusters
      are connected using exclusive federation.

6.1.  Routing

   Due to its nature, routing in the Exclusive federation model is more
   complex than the routing in the partitioned model.

   Association of a user to a server can not be known until the user
   publishes a presence document to a specific server or registers to
   that server.  Therefore, when Alice subscribes to Bob's presence
   information, or sends him an IM, Alice's server will not easily know
   the server that has Bob's presence and is handling his IM.

   In addition, a server may get a subscription to a user, or an IM
   targeted at a user, but the user may not be connected to any server
   yet.  In the case of presence, once the user appears in one of the
   servers, the subscription should be sent to that server.

   A user may use two servers at the same time and have hers/his
   presence information on two servers.  This should be regarded as a
   conflict and one of the presence clients should be terminated or
   redirected to the other server.

   Fortunately, most of the routing approaches described for partitioned
   federation, excepting provisioned routing, can be adapted for



Rosenberg, et al.       Expires January 15, 2009               [Page 18]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   exclusive federation.

6.1.1.  Centralized Database

   A centralized database can be used, but will need to support a test-
   and-set functionality.  With it, servers can check if a user is
   already in a specific server and set the user to the server if the
   user is not on another server.  If the user is already on another
   server a redirect (or some other error message) will be sent to that
   user.

   When a client sends a subscription request for some target user, and
   the target user is not associated with a server yet, the subscription
   must be 'held' on the server of the watcher.  Once the target user
   connects and becomes bound to a server, the database needs to send a
   change notification to the watching server, so that the 'held'
   subscription can be extended to the server which is now handling
   presence for the user.

6.1.2.  Routing Proxy

   The routing proxy mechanism can be used for exclusive federation as
   well.  However, it requires signaling from each server to the routing
   proxy to indicate that the user is now located on that server.  This
   can be done by having each server send a REGISTER request to the
   routing proxy, for that user, and setting the contact to itself.  The
   routing proxy would have a rule which allows only a single registered
   contact per user.  Using the registration event package [RFC3680],
   each server subscribes to the registration state at the routing proxy
   for each user it is managing.  If the routing proxy sees a duplicate
   registration, it allows it, and then uses a reg-event notification to
   the other server to de-register the user.  Once the user is de-
   registered from that server, it would terminate any subscriptions in
   place for that user, causing the watching server to reconnect the
   subscription to the new server.  Something similar can be done for
   in-progress IM sessions; however this may have the effect of causing
   a disruption in ongoing sessions.

6.1.3.  Subdomaining

   Subdomaining is just a variation on the centralized database.
   Assuming the database supports a test-and-set mechanism, it can be
   used for exclusive federation.

   However, the principle challenge in applying subdomaining to
   exclusive federation is database change notifications.  When a user
   moves from one server to another, that change needs to be propagated
   to all clients which have ongoing sessions (presence and IM) with



Rosenberg, et al.       Expires January 15, 2009               [Page 19]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   that user.  This requires a large-scale change notification mechanism
   - to each client in the network.

6.1.4.  Peer-to-Peer

   Peer-to-peer routing can be used for routing in exclusive federation.
   Essentially, it provides a distributed registrar function that maps
   each AoR to the particular server that they are currently registered
   against.  When a UA registers to a particular server, that
   registration is written into the P2P network, such that queries for
   that user are directed to that presence server.

   However, change notifications can be troublesome.  When a user
   registered on server 1 now registers on server 2, server 2 needs to
   query the p2p network, discover that server 1 is handling the user,
   and then tell server 1 that the user has moved.  Server 1 then needs
   to terminate its ongoing subscriptions and send the to server 2.

   Furthermore, P2P networks do not inherently provide a test-and-set
   primitive, and consequently, it is possible for race conditions to
   occur where there is an inconsistent view on where the user is
   currently registered.

6.1.5.  Forking

   The forking model can be applied to exclusive federation.  When a
   user registers with a server or publishes a presence document to a
   server, and that server is not serving the user yet, that server
   begins serving the user.  Furthermore, it needs to propagate a change
   notification to all of the other servers.  This can be done using a
   registration event package; basically each server would subscribe to
   every other server for reg-event notifications for users they serve.

   When subscription or IM request is received at a server, and that
   server doesn't serve the target user, it forks the subscription or IM
   to all other servers.  If the user is currently registered somewhere,
   one will accept, and the others will reject with a 404.  If the user
   is registered nowhere, all others generate a 404.  If the request is
   a subscription, the server that received it would 'hold' the
   subscription, and then subscribe for the reg-event package on every
   other server for the target user.  Once the target user registers
   somewhere, the server holding the subscription gets a notification
   and can propagate it to the new target server.

   Like the P2P solution, the forking solution lacks an effective test-
   and-set mechanism, and it is therefore possible that there could be
   inconsistent views on which server is handling a user.




Rosenberg, et al.       Expires January 15, 2009               [Page 20]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


6.2.  Policy

   In the exclusive federation model, policy becomes more complicated.
   In the partitioned model, a user had their presence and IM managed by
   the same server all of the time.  Thus, their policy can be
   provisioned and excecuted there.  With exclusive federation, a user
   can freely move back and forth between servers.  Consequently, the
   policy for a particular user may need to execute on multiple
   different servers over time.

   The simplest solution is just to require the user to separately
   provision and manage policies on each server.  In many of the use
   cases above, exclusive federation is a transient situation that
   eventually settles into partitioned federation.  Thus, it may not be
   unreasonable to require the user to manage both policies during the
   transition.  It is also possible that each server provides different
   capabilities, and thus a user will receive different service
   depending on which server they are connected to.  Again, this may be
   an acceptable limitation for the use cases it supports.

6.3.  Presence Data

   As with the partitioned model, in the exclusive model, the presence
   data for a user resides on a single server at any given time.  This
   server owns all composition policies and procedures for collecting
   and distributing presence data.

6.4.  Conversation Consistency

   Because a user receives all of their IM on a single server at a time,
   there aren't issues with seeing a coherent conversation for the
   duration that a user is associated with that server.

   However, if a user has sessions in progress while they move from one
   server to another, it is possible that IM's can be misrouted or
   dropped, or delivered out of order.  Fortunately, this is a transient
   event, and given that its unlikely that a user would actually have
   in-progress IM sessions when they change servers, this may be an
   acceptable limitation.

   However, conversation history may be more troubling.  IM message
   history is often stored both in clients (for context of past
   conversations, search, etc.) and in servers (for the same reasons, in
   addition to legal requirements for data retention).  If a user
   changes servers, some of their past conversations will be stored on
   one server, and some on another.  Any kind of search or query
   facility provided amongst the server-stored messages would need to
   search amongst all of the servers to find the data.



Rosenberg, et al.       Expires January 15, 2009               [Page 21]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


7.  Unioned

   In the unioned model, each user is actually served by more than one
   presence server at a time.  In this case, "served" implies two
   properties:

   o  A user is served by a server when that user is provisioned on that
      server, and

   o  That server is authoritative for some piece of presence state
      associated with that user or responsible for some piece of
      registration state associated with that user, for the purposes of
      IM delivery

   In essence, in the unioned model, a user's presence and registration
   data is distributed across many presence servers, while in the
   partitioned and exclusive models, its centralized in a single server.
   Furthermore, it is possible that the user is provisioned with
   different identifiers on each server.

   This definition speaks specifically to ownership of dynamic data -
   presence and registration state - as the key property.  This rules
   out several cases which involve a mix of servers within the
   enterprise, but do not constitute intra-domain unioned federation:

   o  A user utilizes an outbound SIP proxy from one vendor, which
      connects to a presence server from another vendor.  Even though
      this will result in presence subscriptions, notifications, and IM
      requests flowing between servers, and the user is potentially
      provisioned on both, there is no authoritative presence or
      registration state in the outbound proxy, and so this is not
      intra-domain federation.

   o  A user utilizes a Resource List Server (RLS) from one vendor,
      which holds their buddy list, and accesses presence data from a
      presence server from another vendor.  This case is actually the
      partitioned case, not the unioned case.  Effectively, the buddy
      list itself is another "user", and it exists entirely on one
      server (the RLS), while the actual users on the buddy list exist
      entirely within another.  Consequently, this case does not have
      the property that a single presence resource exists on multiple
      servers at the same time.

   o  A user subscribes to the presence of a presentity.  This
      subscription is first passed to their presence server, which acts
      as a proxy, and instead sends the subscription to the UA of the
      user, which acts as a presence edge server.  In this model, it may
      appear as if there are two presence servers for the user (the



Rosenberg, et al.       Expires January 15, 2009               [Page 22]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


      actual server and their UA).  However, the server is acting as a
      proxy in this case - there is only one source of presence
      information.  For IM, there is only one source of registration
      state - the server.  Thus, this model is partitioned, but with
      different servers owning IM and presence.

   The unioned models arise naturally when a user is using devices from
   different vendors, each of which has their own respective servers, or
   when a user is using different servers for different parts of their
   presence state.  For example, Figure 7 shows the case where a single
   user has a mobile client connected to server one and a desktop client
   connected to server two.


             alice@example.com           alice@example.com
              +------------+              +------------+
              |            |              |            |
              |            |              |            |
              |   Server   |--------------|   Server   |
              |     1      |              |     2      |
              |            |              |            |
              |            |              |            |
              +------------+              +------------+
                 \                                /
                  \                              /
                   \                            /
                    \                           /
                     \                         /
                      \                       /
                       \...................../.......
                        \                    /      .
                        .\                  /       .
                        . \  |         +--------+   .
                        .    |         |+------+|   .
                        .   +---+      ||      ||   .
                        .   |+-+|      ||      ||   .
                        .   |+-+|      |+------+|   .
                        .   |   |      +--------+   .
                        .   |   |      /------ /    .
                        .   +---+     /------ /     .
                        .            --------/      .
                        .                           .
                        .............................

                                  Alice

                         Figure 7: Unioned Case 1




Rosenberg, et al.       Expires January 15, 2009               [Page 23]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   As another example, a user may have two devices from the same vendor,
   both of which are asociated with a single presence server, but that
   presence server has incomplete presence state about the user.
   Another presence server in the enterprise, due to its access to state
   for that user, has additional data which needs to be accessed by the
   first presence server in order to provide a comprehensive view of
   presence data.  This is shown in Figure 8.  This use case tends to be
   specific to presence.



             alice@example.com           alice@example.com
              +------------+              +------------+
              |            |              |            |
              |  Presence  |              |  Presence  |
              |   Server   |--------------|   Server   |
              |     1      |              |     2      |
              |            |              |            |
              |            |              |            |
              +------------+              +------------+
                    ^                      |         |
                    |                      |         |
                    |                      |         |
              ///-------\\\                |         |
           ||| specialized |||             |         |
            || state       ||              |         |
              \\\-------///                |         |
                                   .............................
                                   .       |         |         .
                                   .     | |       +--------+  .
                                   .     |         |+------+|  .
                                   .    +---+      ||      ||  .
                                   .    |+-+|      ||      ||  .
                                   .    |+-+|      |+------+|  .
                                   .    |   |      +--------+  .
                                   .    |   |      /------ /   .
                                   .    +---+     /------ /    .
                                   .             --------/     .
                                   .                           .
                                   .                           .
                                   .............................
                                              Alice


                         Figure 8: Unioned Case 2

   Another use case for unioned federation are subscriber moves.
   Consider a domain which uses multiple servers, typically running in a



Rosenberg, et al.       Expires January 15, 2009               [Page 24]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   partitioned configuration.  The servers are organized regionally so
   that each user is served by a server handling their region.  A user
   is moving from one region to a new job in another, while retaining
   their SIP URI.  In order to provide a smooth transition, ideally the
   system would provide a "make before break" functionality, allowing
   the user to be added onto the new server prior to being removed from
   the old.  During the transition period, especially if the user had
   multiple clients to be moved, they can end up with state existing on
   both servers at the same time.

   Another use case for unioned federation is multiple providers.
   Consider a user in an enterprise, alice@example.com.  Example.com has
   a presence server deployed for all of its users.  In addition, Alice
   uses a public IM and presence provider.  Alice would like that users
   who connect to the public provider see presence state that comes from
   example.com, and vice-a-versa.  Interestingly, this use case isn't
   intra-domain federation at all, but rather, unioned inter-domain
   federation.

7.1.  Hierarchical Model

   The unioned intra-federation model can be realized in one of two ways
   - using a hierarchical structure or a peer structure.

   In the hierarchical model, presence subscriptions and IM requests for
   the target are always routed first to one of the servers - the root.
   In the case of presence, the root has the final say on the structure
   of the presence document delivered to watchers.  It collects presence
   data from its child presence servers (through notifications or
   publishes received from them) and composes them into the final
   presence document.  In the case of IM, the root applies IM policy and
   then passes the IM onto the children for delivery.  There can be
   multiple layers in the hierarchical model.  This is shown in Figure 9
   for presence.

















Rosenberg, et al.       Expires January 15, 2009               [Page 25]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


                              +-----------+
            *-----------*     |           |
            |Auth and   |---->|  Presence | <--- root
            |Composition|     |   Server  |
            *-----------*     |           |
                              |           |
                              +-----------+
                                 /       ---
                                /           ----
                               /                ----
                              /                     ----
                             V                          -V
                   +-----------+                      +-----------+
                   |           |                      |           |
   *-----------*   |  Presence |      *-----------*   |  Presence |
   |Auth and   |-->|   Server  |      |Auth and   |-->|   Server  |
   |Composition|   |           |      |Composition|   |           |
   *-----------*   |           |      *-----------*   |           |
                   +-----------+                      +-----------+
                      |    ---
                      |       -----
                      |            -----
                      |                 -----
                      |                      -----
                      |                           -----
                      V                                --V
                   +-----------+                      +-----------+
                   |           |                      |           |
   *-----------*   |  Presence |      *-----------*   |  Presence |
   |Auth and   |-->|   Server  |      |Auth and   |-->|   Server  |
   |Composition|   |           |      |Composition|   |           |
   *-----------*   |           |      *-----------*   |           |
                   +-----------+                      +-----------+

                       Figure 9: Hierarchical Model

   Its important to note that this hierarchy defines the sequence of
   presence composition and policy application, and does not imply a
   literal message flow.  As an example, consider once more the use case
   of Figure 7.  Assume that presence server 1 is the root, and presence
   server 2 is its child.  When Bob's PC subscribes to Bob's buddy list
   (on presence server 2), that subscription will first go to presence
   server 2.  However, that presence server knows that it is not the
   root in the hierarchy, and despite the fact that it has presence
   state for Alice (who is on Bob's buddy list), it creates a back-end
   subscription to presence server 1.  Presence server 1, as the root,
   subscribes to Alice's state at presence server 2.  Now, since this
   subscription came from presence server 1 and not Bob directly,



Rosenberg, et al.       Expires January 15, 2009               [Page 26]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   presence server 2 provides the presence state.  This is received at
   presence server 1, which composes the data with its own state for
   Alice, and then provides the results back to presence server 2,
   which, having acted as an RLS, forwards the results back to Bob.
   Consequently, this flow, as a message sequence diagram, involves
   notifications passing from presence server 2, to server 1, back to
   server 2.  However, in terms of composition and policy, it was done
   first at the child node (presence server 2), and then those results
   used at the parent node (presence server 1).

7.1.1.  Routing

   In the hierarchical model, each server needs to be provisioned with
   the root, its parent and its children servers for each user it
   handles.  These relationships could in fact be different on a user-
   by-user basis; however, this is complex to manage.  In all
   likelihood, the parent and child relationships are identical for each
   user.  The overall routing algorithm can be described thusly:

   o  If a SUBCRIBE is received from the parent node for this
      presentity, perform subscriptions to each child node for this
      presentity, and then take the results, apply composition and
      authorization policies, and propagate to the parent.  If a node is
      the root, the logic here applies regardless of where the request
      came from.

   o  If an IM request is received from the parent node for a user,
      perform IM processing and then proxy the request to each child IM
      server for this user.  If a node is the root, the logic here
      applies regardless of where the request came from.

   o  If a request is received from a node that is not the parent node
      for this presentity, proxy the request to the parent node.  This
      includes cases where the node that sent the request is a child
      node.

   This routing rule is relatively simple, and in a two-server system is
   almost trivial to provision.  Interestingly, it works in cases where
   some users are partitioned and some are unioned.  When the users are
   partitioned, this routing algorithm devolves into the forking
   algorithm of Section 5.2.5.  This points to the forking algorithm as
   a good choice since it can be used for both partitioned and unioned.

   An important property of the routing in the hierarchical model is
   that the sequence of composition and policy operations for any IM or
   presence session is identical, regardless of the watcher or sender of
   the IM.  The result is that the overall presence state provided to a
   watcher, and overall IM behavior, is always consistent and



Rosenberg, et al.       Expires January 15, 2009               [Page 27]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   independent of the server the client is connected to.  We call this
   property the *consistency property*, and it is an important metric in
   assessing the correctness of a federated presence and IM system.

7.1.2.  Policy and Identity

   Policy and identity are a clear challenge in the unioned model.

   Firstly, since a user is provisioned on many servers, it is possible
   that the identifier they utilize could be different on each server.
   For example, on server 1, they could be joe@example.com, whereas on
   server 2, they are joe.smith@example.com.  In cases where the
   identifiers are not equivalent, a mapping function needs to be
   provisioned.  This ideally happens on root server.

   Secondly, the unioned model will result in back-end subscriptions
   extending from one presence server to another presence server.  These
   subscriptions, though made by the presence server, need to be made
   on-behalf-of the user that originally requested the presence state of
   the presentity.  Since the presence server extending the back-end
   subscription will not often have credentials to claim identity of the
   watcher, asserted identity using techniques like P-Asserted-ID
   [RFC3325] are required, along with the associated trust relationships
   between servers.  Optimizations, such as view sharing
   [I-D.ietf-simple-view-sharing] can help improve performance.  The
   same considerations apply for IM.

   The principle challenge in a unioned model is policy, including both
   authorization and composition policies.  There are three potential
   solutions to the administration of policy in the hierarchical model
   (only two of which apply in the peer model, as we'll discuss below).
   These are root-only, distributed provisioned, and central
   provisioned.

7.1.2.1.  Root Only

   In the root-only policy model, authorization policy, IM policy, and
   composition policy are applied only at the root of the tree.  This is
   shown in Figure 10.












Rosenberg, et al.       Expires January 15, 2009               [Page 28]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


                              +-----------+
            *-----------*     |           |
            |           |---->|           | <--- root
            |  Policy   |     |   Server  |
            *-----------*     |           |
                              |           |
                              +-----------+
                                 /       ---
                                /           ----
                               /                ----
                              /                     ----
                             V                          -V
                   +-----------+                      +-----------+
                   |           |                      |           |
                   |           |                      |           |
                   |   Server  |                      |   Server  |
                   |           |                      |           |
                   |           |                      |           |
                   +-----------+                      +-----------+
                      |    ---
                      |       -----
                      |            -----
                      |                 -----
                      |                      -----
                      |                           -----
                      V                                --V
                   +-----------+                      +-----------+
                   |           |                      |           |
                   |           |                      |           |
                   |   Server  |                      |   Server  |
                   |           |                      |           |
                   |           |                      |           |
                   +-----------+                      +-----------+


                           Figure 10: Root Only

   As long as a subscription request came from its parent, every child
   presence server would automatically accept the subscription, and
   provide notifications containing the full presence state it is aware
   of.  Similarly, any IM received from a parent would be simply
   propagated onwards towards children.  Any composition performed by a
   child presence server would need to be lossless, in that it fully
   combines the source data without loss of information, and also be
   done without any per-user provisioning or configuration, operating in
   a default or administrator-provisioned mode of operation.

   The root-only model has the benefit that it requires the user to



Rosenberg, et al.       Expires January 15, 2009               [Page 29]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   provision policy in a single place (the root).  However, it has the
   drawback that the composition and policy processing may be performed
   very poorly.  Presumably, there are multiple presence servers in the
   first place because each of them has a particular speciality.  That
   speciality may be lost in the root-only model.  For example, if a
   child server provides geolocation information, the root presence
   server may not have sufficient authorization policy capabilities to
   allow the user to manage how that geolocation information is provided
   to watchers.

7.1.2.2.  Distributed Provisioning

   The distributed provisioned model looks exactly like the diagram of
   Figure 9.  Each server is separately provisioned with its own
   policies, including what users are allowed to watch, what presence
   data they will get, how it will be composed, what IMs get blocked,
   and so on.

   One immediate concern is whether the overall policy processing, when
   performed independently at each server, is consistent, sane, and
   provides reasonable degrees of privacy.  It turns out that it can, if
   some guidelines are followed.

   For presence, consider basic "yes/no" authorization policies.  Lets
   say a presentity, Alice, provides an authorization policy in server 1
   where Bob can see her presence, but on server 2, provides a policy
   where Bob cannot.  If presence server 1 is the root, the subscription
   is accepted there, but the back-end subscription to presence server 2
   would be rejected.  As long as presence server 1 then rejects the
   subscription, the system provides the correct behavior.  This can be
   turned into a more general rule:

   o  To guarantee privacy safety, if the back-end subscription
      generated by a presence server is denied, that server must deny
      the triggering subscription in turn, regardless of its own
      authorization policies.  This means that a presence server cannot
      send notifications on its own until it has confirmed subscriptions
      from downstream servers.

   For IM, basic yes/no authorization policies work in a similar way.
   If any one of the servers has a policy that says to block an IM, the
   IM is not propagated further down the chain.  Whether the overall
   system blocks IMs from a sender depends on the topology.  If there is
   no forking in the hierarchy, the system has the property that, if a
   sender is blocked at any server, the user is blocked overall.
   However, in tree structures where there are multiple children, it is
   possible that an IM could be delivered to some downstream clients,
   and not others.



Rosenberg, et al.       Expires January 15, 2009               [Page 30]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   Things get more complicated when one considers presence authorization
   policies whose job is to block access to specific pieces of
   information, as opposed to blocking a user completely.  For example,
   lets say Alice wants to allow Bob to see her presence, but not her
   geolocation information.  She provisions a rule on server 1 that
   blocks geolocation information, but grants it on server 2.  The
   correct mode of operation in this case is that the overall system
   will block geolocation from Bob. But will it?  In fact, it will, if a
   few additional guidelines are followed:

   o  If a presence server adds any information to a presence document
      beyond the information received from its children, it must provide
      authorization policies that govern the access to that information.

   o  If a presence server does not understand a piece of presence data
      provided by its child, it should not attempt to apply its own
      authorization policies to access of that information.

   o  A presence server should not add information to a presence
      document that overlaps with information that can be added by its
      parent.  Of course, it is very hard for a presence server to know
      whether this information overlaps.  Consequently, provisioned
      composition rules will be required to realize this.

   If these rules are followed, the overall system provides privacy
   safety and the overall policy applied is reasonable.  This is because
   these rules effectively segment the application of policy based on
   specific data, to the servers that own the corresponding data.  For
   example, consider once more the geolocation use case described above,
   and assume server 2 is the root.  If server 1 has access to, and
   provides geolocation information in presence documents it produces,
   then server 1 would be the only one to provide authorization policies
   governing geolocation.  Server 2 would receive presence documents
   from server 1 containing (or not) geolocation, but since it doesn't
   provide or control geolocation, it lets that information pass
   through.  Thus, the overall presence document provided to the watcher
   will contain gelocation if Alice wanted it to, and not otherwise, and
   the controls for access to geolocation would exist only on server 1.

   The second major concern on distributed provisioning is that it is
   confusing for users.  However, in the model that is described here,
   each server would necessarily be providing distinct rules, governing
   the information it uniquely provides.  Thus, server 2 would have
   rules about who is allowed to see geolocation, and server 1 would
   have rules about who is allowed to subscribe overall.  Though not
   ideal, there is certainly precedent for users configuring policies on
   different servers based on the differing services provided by those
   servers.  Users today provision block and allow lists in email for



Rosenberg, et al.       Expires January 15, 2009               [Page 31]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   access to email servers, and separately in IM and presence
   applications for access to IM.

7.1.2.3.  Central Provisioning

   The central provisioning model is a hybrid between root-only and
   distributed provisioning.  Each server does in fact execute its own
   authorization and composition policies.  However, rather than the
   user provisioning them independently in each place, there is some
   kind of central portal where the user provisions the rules, and that
   portal generates policies for each specific server based on the data
   that the corresponding server provides.  This is shown in Figure 11.







































Rosenberg, et al.       Expires January 15, 2009               [Page 32]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


                         +---------------------+
                         |provisioning portal  |
                         +---------------------+
                           .  .    .     .   .
                           .  .    .     .   .
                           .  .    .     .   .......................
 ...........................  .    .     .                         .
 .                            .    .     .                         .
 .                            .    .     .                         .
 .  ...........................    .     .............             .
 .  .                              .                 .             .
 .  .         ......................                 .             .
 .  .         V            +-----------+             .             .
 .  .    *-----------*     |           |             .             .
 .  .    |Auth and   |---->|  Presence | <--- root   .             .
 .  .    |Composition|     |   Server  |             .             .
 .  .    *-----------*     |           |             .             .
 .  .                      |           |             .             .
 .  .                      +-----------+             .             .
 .  .                        |      ----             .             .
 .  .                        |          -------      .             .
 .  .                        |                 -------             .
 .  .                        |                       .-------      .
 .  .                        V                       .       ---V  V
 .  .                    +-----------+               .      +-----------+
 .  .                    |           |               V      |           |
 .  .    *-----------*   |  Presence |      *-----------*   |  Presence |
 .  ....>|Auth and   |-->|   Server  |      |Auth and   |-->|   Server  |
 .       |Composition|   |           |      |Composition|   |           |
 .       *-----------*   |           |      *-----------*   |           |
 .                       +-----------+                      +-----------+
 .                         /       --
 .                        /          ----
 .                       /               ---
 .                      /                   ----
 .                     /                        ---
 .                    /                            ----
 .                   V                                 -V
 .              +-----------+                      +-----------+
 V              |           |                      |           |
*-----------*   |  Presence |      *-----------*   |  Presence |
|Auth and   |-->|   Server  |      |Auth and   |-->|   Server  |
|Composition|   |           |      |Composition|   |           |
*-----------*   |           |      *-----------*   |           |
                +-----------+                      +-----------+

                      Figure 11: Central Provisioning




Rosenberg, et al.       Expires January 15, 2009               [Page 33]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   Centralized provisioning brings the benefits of root-only (single
   point of user provisioning) with those of distributed provisioning
   (utilize full capabilities of all servers).  Its principle drawback
   is that it requires another component - the portal - which can
   represent the union of the authorization policies supported by each
   server, and then delegate those policies to each corresponding
   server.

   The other drawback of centralized provisioning is that it assumes
   completely consistent policy decision making on each server.  There
   is a rich set of possible policy decisions that can be taken by
   servers, and this is often an area of differentiation.

7.1.2.4.  Centralized PDP

   The centralized provisioning model assumes that there is a single
   point of policy administration, but that there is independent
   decision making at each presence and IM server.  This only works in
   cases where the decision function - the policy decision point - is
   identical in each server.

   An alternative model is to utilize a single point of policy
   administration and a single point of policy decisionmaking.  Each
   presence server acts solely as an enforcement point, asking the
   policy server (through a policy protocol of some sort) how to handle
   the presence or IM.  The policy server then comes back with a policy
   decision - whether to proceed with the subscription or IM, and how to
   filter and process it.  This is shown in Figure 12.


         +------------+      +---------------+
         |Provisioning|=====>|Policy Decision|
         |   Portal   |      |   Point (PDP) |
         +------------+      +---------------+
                              # #   #  #   #
            ################### #   #  #   ###########################
            #                   #   #  #                             #
            #            ########   #  ####################          #
            #            #    +-----------+               #          #
            #            #    |           |               #          #
            #            #    |           | .... root     #          #
            #            #    |   Server  |               #          #
            #            #    |           |               #          #
            #            #    |           |               #          #
            #            #    +-----------+               #          #
            #            #       /       ---              #          #
            #            #      /           ----          #          #
            #            #     /                ----      #          #



Rosenberg, et al.       Expires January 15, 2009               [Page 34]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


            #            #    /                     ----  #          #
            #            #   V                          -V#          #
            #      +-----------+                      +-----------+  #
            #      |           |                      |           |  #
            #      |           |                      |           |  #
            #      |   Server  |                      |   Server  |  #
            #      |           |                      |           |  #
            #      |           |                      |           |  #
            #      +-----------+                      +-----------+  #
            #         |    ---                                       #
            #         |       -----                                  #
            #         |            -----                             #
            #         |                 -----                        #
            #         |                      -----                   #
            #         |                           -----              #
            #         V                                --V           #
            #      +-----------+                      +-----------+  #
            #      |           |                      |           |  #
            #######|           |                      |           |  #
                   |   Server  |                      |   Server  |###
                   |           |                      |           |
                   |           |                      |           |
                   +-----------+                      +-----------+





        ===== Provisioning Protocol

        ##### Policy Protocol

        ----- SIP


                          Figure 12: Central PDP

   The centralized PDP has the benefits of central provisioning, and
   consistent policy operation, and decouples policy decision making
   from presence and IM processing.  This decoupling allows for multiple
   presence and IM servers, but still allows for a single policy
   function overall.  The individual presence and IM servers don't need
   to know about the policies themselves, or even know when they change.
   Of course, if a server is caching the results of a policy decision,
   change notifications are required from the PDP to the server,
   informing it of the change (alternatively, traditional TTL-based
   expirations can be used if delay in updates are acceptable).




Rosenberg, et al.       Expires January 15, 2009               [Page 35]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   For the centralized and distributed provisioning approaches, and the
   centralized decision approach, the hierarchical model suffers overall
   from the fact that the root of the policy processing may not be tuned
   to the specific policy needs of the device that has subscribed.  For
   example, in the use case of Figure 7, presence server 1 may be
   providing composition policies tuned to the fact that the device is
   wireless with limited display.  Consequently, when Bob subscribes
   from his mobile device, is presence server 2 is the root, presence
   server 2 may add additional data and provide an overall presence
   document to the client which is not optimized for that device.  This
   problem is one of the principal motivations for the peer model,
   described below.

7.1.3.  Presence Data

   The hierarhical model is based on the idea that each presence server
   in the chain contributes some unique piece of presence information,
   composing it with what it receives from its child, and passing it on.
   For the overall presence document to be reasonable, several
   guidelines need to be followed:

   o  A presence server must be prepared to receive documents from its
      peer containing information that it does not understand, and to
      apply unioned composition policies that retain this information,
      adding to it the unique information it wishes to contribute.

   o  A user interface rendering some presence document provided by its
      presence server must be prepared for any kind of presence document
      compliant to the presence data model, and must not assume a
      specific structure based on the limitations and implementation
      choices of the server to which it is paired.

   If these basic rules are followed, the overall system provides
   functionality equivalent to the combination of the presence
   capabilities of the servers contained within it, which is highly
   desirable.

7.1.4.  Conversation Consistency

   Unioned federation introduces a particular challenge for conversation
   consistency.  A user with multiple devices attached to multiple
   servers could potentially try to participate in the conversation on
   multiple devices at once.  This would clearly pose a challenge.
   There are really two approaches that produce a sensible user
   experience.

   The first approach simulates the "phone experience" with IM.  When a
   user (say Alice) sends an IM to Bob, and Bob is a unioned user with



Rosenberg, et al.       Expires January 15, 2009               [Page 36]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   two devices on two servers, Bob receives that IM on both devices.
   However, when he "answers" by typing a reply from one of those
   devices, the conversation continues only on that device.  The other
   device on the other server receives no further IMs for this session -
   either from Alice or from Bob. Indeed, the IM window on Bob's
   unanswered device may even disappear to emphasize this fact.

   This mode of operation, which we'll call uni-device IM, is only
   feasible with session mode IM, and its realization using traditional
   SIP signaling is described in [RFC4975].

   The second mode of operation, called multi-device IM, is more of a
   conferencing experience.  The initial IM from Alice is delivered to
   both Bob's devices.  When Bob answers on one, that response is shown
   to ALice but is also rendered on Bob's other device.  Effectively, we
   have set up an IM conference where each of Bob's devices is an
   independent participant in the conference.  This model is feasible
   with both session and pager mode IM; however conferencing works much
   better overall with session mode.

   A related challenge is conversation history.  In the uni-device IM
   mode, this past history for a user's conversation may be distributed
   amongst the different servers, depending on which clients and servers
   were involved in the conversation.  As with the exclusive model, IM
   search and retrieval services may need to access all of the servers
   on which a user might be located.  This is easier for the unioned
   case than the exclusive one, since in the unioned case, the user's
   location is on a fixed number of servers based on provisioning.  This
   problem is even more complicated in IM page mode when multiple
   devices are present, due to the limitation of page mode in these
   configurations.

7.2.  Peer Model

   In the peer model, there is no one root.  When a watcher subscribes
   to a presentity, that subscription is processed first by the server
   to which the watcher is connected (effectively acting as the root),
   and then the subscription is passed to other child presence servers.
   The same goes for IM; when a client sends an IM, the IM is processed
   first by the server associated with the sender (effectively acting as
   the root), and then the IM is passed to the child IM servers.  In
   essence, in the peer model, there is a per-client hierarchy, with the
   root being a function of the client.  Consider the use case in
   Figure 7 If Bob has his buddy list on presence server 1, and it
   contains Alice, presence server 1 acts as the root, and then performs
   a back-end subscription to presence server 2.  However, if Joe has
   his buddy list on presence server 2, and his buddy list contains
   Alice, presence server 2 acts as the root, and performs a back-end



Rosenberg, et al.       Expires January 15, 2009               [Page 37]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   subscription to presence server 1.  Similarly, if Bob sends an IM to
   Alice, it is processed first by server 1 and then server 2.  If Joe
   sends an IM to Alice, it is first processed by server 2 and then
   server 1.  This is shown in Figure 13.



           alice@example.com           alice@example.com
            +------------+              +------------+
            |            |<-------------|            |<--------+
            |            |              |            |         |
    Connect |   Server   |              |   Server   |         |
     Alice  |     1      |              |     2      | Connect |
      +---->|            |------------->|            |  Alice  |
      |     |            |              |            |         |
      |     +------------+              +------------+         |
      |        \                                /              |
      |         \                              /               |
      |          \                            /                |
      |           \                           /                |
      |            \                         /                 |
      |             \                       /                  |
   ...|........      \...................../.......   .........|........
   .          .       \                    /      .   .                .
   .          .       .\                  /       .   .    +--------+  .
   .   |      .       . \  |         +--------+   .   .    |+------+|  .
   .   |      .       .    |         |+------+|   .   .    ||      ||  .
   .  +---+   .       .   +---+      ||      ||   .   .    ||      ||  .
   .  |+-+|   .       .   |+-+|      ||      ||   .   .    |+------+|  .
   .  |+-+|   .       .   |+-+|      |+------+|   .   .    +--------+  .
   .  |   |   .       .   |   |      +--------+   .   .    /------ /   .
   .  |   |   .       .   |   |      /------ /    .   .   /------ /    .
   .  +---+   .       .   +---+     /------ /     .   .  --------/     .
   .          .       .            --------/      .   .                .
   .          .       .                           .   .                .
   ............       .............................   ..................

      Bob                       Alice                       Joe


                           Figure 13: Peer Model

   Whereas the hierarchical model clearly provides the consistency
   property, it is not obvious whether a particular deployment of the
   peer model provides the consistency property.  When policy decision
   making is distributed amongst the servers, it ends up being a
   function of the composition policies of the individual servers.  If
   Pi() represents the composition and authorization policies of server



Rosenberg, et al.       Expires January 15, 2009               [Page 38]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   i, and takes as input one or more presence documents provided by its
   children, and outputs a presence document, the overall system
   provides consistency when:


                Pi(Pj()) = Pj(Pi())

   which is effectively the commutativity property.

7.2.1.  Routing

   Routing in the peer model works similarly to the hierarchical model.
   Each server would be configured with the children it has when it acts
   as the root.  The overall presence routing algorithm then works as
   follows:

   o  If a presence server receives a subscription for a presentity from
      a particular watcher, and it already has a different subscription
      (as identified by dialog identifiers) for that presentity from
      that watcher, it rejects the second subscription with an
      indication of a loop.  This algorithm does rule out the
      possibility of two instances of the same watcher subscribing to
      the same presentity.

   o  If a presence server receives a subscription for a presentity from
      a watcher and it doesn't have one yet for that pair, it processes
      it and generates back end subscriptions to each configured child.
      If a back-end subscription generates an error due to loop, it
      proceeds without that back-end input.

   The algorithm for IM routing works almost identically.

   For example, consider Bob subscribing to Alice.  Bob's client is
   supported by server 1.  Server 1 has not seen this subscription
   before, so it acts as the root and passes it to server 2.  Server 2
   hasn't seen it before, so it accepts it (now acting as the child),
   and sends the subscription to its child, which is server 1.  Server 1
   has already seen the subscription, so it rejects it.  Now server 2
   basically knows its the child, and so it generates documents with
   just its own data.

   As in the hierarchical case, it is possible to intermix partitioned
   and peer models for different users.  In the partitioned case, the
   routing for hierarchical devolves into the forking routing described
   in Section 5.2.5.  However, intermixing peer and exclusive federation
   for different users is challenging.  [[OPEN ISSUE: need to think
   about this more.]]




Rosenberg, et al.       Expires January 15, 2009               [Page 39]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


7.2.2.  Policy

   The policy considerations for the peer model are very similar to
   those of the hierarchical model.  However, the root-only policy
   approach is non-sensical in the peer model, and cannot be utilized.
   The distributed and centralized provisioning approaches apply, and
   the rules described above for generating correct results provide
   correct results in the peer model as well.

   However, the centralized PDP model works particularly well in concert
   with the peer model.  It allows for consistent policy processing
   regardless of the type of rules, and has the benefit of having a
   single point of provisioning.  At the same time, it avoids the need
   for defining and having a single root; indeed there is little benefit
   for utilizing the hierarchical model when a centralized PDP is used.

   However, the distributed processing model in the peer model
   eliminates the problem described in Section 7.1.2.3.  The problem is
   that composition and authorization policies may be tuned to the needs
   of the specific device that is connected.  In the hierarchical model,
   the wrong server for a particular device may be at the root, and the
   resulting presence document poorly suited to the consuming device.
   This problem is alleviated in the peer model.  The server that is
   paired or tuned for that particular user or device is always at the
   root of the tree, and its composition policies have the final say in
   how presence data is presented to the watcher on that device.

7.2.3.  Presence Data

   The considerations for presence data and composition in the
   hierarchical model apply in the peer model as well.  The principle
   issue is consistency, and whether the overall presence document for a
   watcher is the same regardless of which server the watcher connects
   from.  As mentioned above, consistency is a property of commutativity
   of composition, which may or may not be true depending on the
   implementation.

   Interestingly, in the use case of Figure 8, a particular user only
   ever has devices on a single server, and thus the peer and
   hierarchical models end up being the same, and consistency is
   provided.

7.2.4.  Conversation Consistency

   The hierarchical and peer models have no impact on the issue of
   conversation consistency; the problem exists identically for both
   approaches.




Rosenberg, et al.       Expires January 15, 2009               [Page 40]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


8.  Summary

   This document doesn't make any recommendation as to which models is
   best.  Each model has different areas of applicability and are
   appropriate in a particular deployment.


9.  Future Considerations

   There are some additional concepts that can be considered, which have
   not yet been explored.  One of them is routing of PUBLISH requests
   between systems.  This can be used as part of the unioned models and
   requires further discussion.

   Another big issue is data federation.  For the unioned models in
   particular, there is typically a desire to be able to add a buddy on
   one system and have it appear on another, or to add a user to a
   whitelist on one system and have that reflect in the other.  This
   requires some kind of standardized data interfaces and is for further
   consideration.


10.  Acknowledgements

   The author would like to thank Paul Fullarton, David Williams, Sanjay
   Sinha, and Paul Kyzivat for their comments.


11.  Security Considerations

   The principle issue in intra-domain federation is that of privacy.
   It is important that the system meets user expectations, and even in
   cases of user provisioning errors or inconsistencies, it provides
   appropriate levels of privacy.  This is an issue in the unioned
   models, where user privacy policies can exist on multiple servers at
   the same time.  The guidelines described here for authorization
   policies help ensure that privacy properties are maintained.


12.  IANA Considerations

   There are no IANA considerations associated with this specification.


13.  Informative References

   [RFC2778]  Day, M., Rosenberg, J., and H. Sugano, "A Model for
              Presence and Instant Messaging", RFC 2778, February 2000.



Rosenberg, et al.       Expires January 15, 2009               [Page 41]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
              W., and J. Peterson, "Presence Information Data Format
              (PIDF)", RFC 3863, August 2004.

   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
              July 2006.

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

   [RFC4662]  Roach, A., Campbell, B., and J. Rosenberg, "A Session
              Initiation Protocol (SIP) Event Notification Extension for
              Resource Lists", RFC 4662, August 2006.

   [RFC3944]  Johnson, T., Okubo, S., and S. Campos, "H.350 Directory
              Services", RFC 3944, December 2004.

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.

   [RFC3680]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
              Package for Registrations", RFC 3680, March 2004.

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

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

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

   [I-D.ietf-speermint-consolidated-presence-im-usecases]
              Houri, A., "Presence & Instant Messaging Peering Use
              Cases",
              draft-ietf-speermint-consolidated-presence-im-usecases-04
              (work in progress), February 2008.

   [I-D.ietf-simple-view-sharing]
              Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
              Federated Presence with View Sharing",
              draft-ietf-simple-view-sharing-00 (work in progress),
              February 2008.



Rosenberg, et al.       Expires January 15, 2009               [Page 42]


Internet-Draft   Intra-Domain Presence and IM Federation       July 2008


Authors' Addresses

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Avshalom Houri
   IBM
   Science Park, Rehovot
   Israel

   Email: avshalom@il.ibm.com


   Colm Smyth
   Avaya
   Dublin 18, Sandyford Business Park
   Ireland

   Email: smythc@avaya.com

























Rosenberg, et al.       Expires January 15, 2009               [Page 43]


Internet-Draft   Intra-Domain Presence and IM Federation       July 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).





Rosenberg, et al.       Expires January 15, 2009               [Page 44]