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

Versions: 00

SIMPLE                                                      J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Informational                         November 10, 2007
Expires: May 13, 2008


              Models for Intra-Domain Presence Federation
            draft-rosenberg-simple-intradomain-federation-00

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 May 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Presence federation involves the sharing of presence information
   across multiple presence systems.  Most often, presence 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 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 federation.



Rosenberg                 Expires May 13, 2008                  [Page 1]


Internet-Draft      Intra-Domain Presence Federation       November 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Partitioned  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.1.  Centralized Database . . . . . . . . . . . . . . . . .  8
       2.2.2.  Routing Proxy  . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Subdomaining . . . . . . . . . . . . . . . . . . . . . 10
       2.2.4.  Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . 12
       2.2.5.  Forking  . . . . . . . . . . . . . . . . . . . . . . . 12
       2.2.6.  Provisioned Routing  . . . . . . . . . . . . . . . . . 12
     2.3.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     2.4.  Presence Data  . . . . . . . . . . . . . . . . . . . . . . 12
   3.  Unioned  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 14
     3.2.  Hierarchical Model . . . . . . . . . . . . . . . . . . . . 17
       3.2.1.  Routing  . . . . . . . . . . . . . . . . . . . . . . . 19
       3.2.2.  Policy and Identity  . . . . . . . . . . . . . . . . . 20
         3.2.2.1.  Root Only  . . . . . . . . . . . . . . . . . . . . 20
         3.2.2.2.  Distributed Provisioning . . . . . . . . . . . . . 22
         3.2.2.3.  Central Provisioning . . . . . . . . . . . . . . . 23
       3.2.3.  Presence Data  . . . . . . . . . . . . . . . . . . . . 25
     3.3.  Peer Model . . . . . . . . . . . . . . . . . . . . . . . . 25
       3.3.1.  Routing  . . . . . . . . . . . . . . . . . . . . . . . 27
       3.3.2.  Policy . . . . . . . . . . . . . . . . . . . . . . . . 28
       3.3.3.  Presence Data  . . . . . . . . . . . . . . . . . . . . 28
   4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   5.  Future Considerations  . . . . . . . . . . . . . . . . . . . . 28
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 29
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 31
















Rosenberg                 Expires May 13, 2008                  [Page 2]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

   Most often, presence federation is considered in the context of
   interconnection between different domains, also known as inter-domain
   presence federation
   [I-D.ietf-speermint-consolidated-presence-im-usecases].  For example,
   consider the network of Figure 1, which shows one model for inter-
   domain 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                 Expires May 13, 2008                  [Page 3]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

   However, federation can happen within a domain as well.  We define
   intra-domain federation as the interconnection of presence servers
   within a single domain, where domain refers explicity to the right
   hand side of the @-sign in the SIP URI.  A single domain can have
   multiple presence systems for several reasons:

   o  The domain may be very large, and for purposes of scale, requires
      several different presence servers.  However, intra-domain
      federation is not the same as clustering, which is also done for
      scale.  Clustering involves a tight synchronization and
      coordination across servers, always of the same vendor.  Intra-
      domain federation involves much looser coupling and can be between
      vendors.




Rosenberg                 Expires May 13, 2008                  [Page 4]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   o  The domain may be divided up organizationally in such a way that
      different users are served by different parts of organization, and
      each part of the organization manages its own presence servers.

   o  A domain has chosen multiple vendors for its presence
      infrastructure, each having their own servers.

   When considering architectures for intra-domain presence federation,
   several issues need to be considered:

   Routing:  How are subscriptions routed to the right presence
      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 server(s) are responsible for executing that policy?
      What identities does the user have in each system and how do they
      relate?

   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?

   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, and composition work.


2.  Partitioned

   In the partitioned model, a single domain has a multiplicity of
   presence servers, each of which manages a non-overlapping set of
   users.  That is, for each user in the domain, their presence data and
   policy reside on a single server.  Each "single server" may in fact
   be physically implemented on more than one box, for the purposes of
   scale or high availability.  However, the key definition of "single
   server" here is that it represents an isolated presence functionality
   that operates independently of any of the others.

   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:



Rosenberg                 Expires May 13, 2008                  [Page 5]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.

   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.

   This model is illustrated in Figure 2.  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 2: Partitioned Model

2.1.  Applicability

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

   One common use case 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



Rosenberg                 Expires May 13, 2008                  [Page 6]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.

   Another common use case is an organization that is just very large,
   and their size exceeds the capacity that a single "server" 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.  The word "server"
   is used in quotes above because, in fact, each such "server" might be
   a clustered set of servers from a particular vendor.  Clustering is
   not the same as intra-domain federation; clustering involves a
   tightly coupled coordination between servers of the same vendor.
   Intra-domain federation involves a looser coupling - only using
   standards-based protocols and possibly involving multiple vendors.

   Yet another common use case 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.

   Another use case is one where certain vendors might specialize in
   specific types of clients, or provide features or presence data that
   are unique, such that a domain might wish to use clients from a
   multiplicity of vendors, depending on the needs of its users.  For
   example, one vendor might provide a mobile client (but no desktop
   client), while another provides a desktop client but no mobile
   client.  A domain might want some users to have a mobile client,
   while others have the desktop client.  This leads to the partitioned
   model.

2.2.  Routing

   The partitioned intra-domain model works almost identically to an
   inter-domain federated model, with the primary difference being
   routing.  In inter-domain federation, the domain part of the URI can
   be used to route presence subscriptions from the watcher's domain to
   the domain of the presentity.  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 2).  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



Rosenberg                 Expires May 13, 2008                  [Page 7]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   server 2?

2.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 3: Centralized DB

   One solution is to rely on a common, centralized database that
   maintains mappings of users to specific servers, shown in Figure 3.
   When Joe subscribes to his buddy list that contains Alice, server 1
   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.  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 SUBSCRIBE request to reflect this.

   Routing database solutions have the problem that they require



Rosenberg                 Expires May 13, 2008                  [Page 8]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

2.2.2.  Routing Proxy


   .....................................................................
   .                         +-----------+                             .
   .        SUB alice        |           |                             .
   .       +---------------> |  Routing  |                             .
   .       |                 |   Proxy   |                             .
   .       |                 |           |                             .
   .       |                 +-----------+                             .
   .       |                       |                                   .
   .       |                       |                                   .
   .       |                       |                                   .
   .       |                       |SUB 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                             .
   .....................................................................


                          Figure 4: Routing Proxy

   A similar solution is to rely on a routing proxy.  Instead of a
   centralized database, there would be a centralized SIP proxy farm.
   Server 1 would send subscriptions 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
   subscriptions 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.




Rosenberg                 Expires May 13, 2008                  [Page 9]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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, which can be a scale
   challenge.

2.2.3.  Subdomaining

   In this solution, each user is associated with a subdomain, and is
   provisioned as part of their respective presence server using that
   subdomain.  Consequently, each presence 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 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 5



































Rosenberg                 Expires May 13, 2008                 [Page 10]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   .....................................................................
   .                         +-----------+                             .
   .    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     |       .
   . | |  |           |        |           |       |           |       .
   . | |  +-----------+        +-----------+       +-----------+       .
   . | |                            ^                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                            |                                  .
   . | |                     +-----------+                             .
   . | +-------------------->|           |                             .
   . |                       |  Watcher  |                             .
   . |                       |           |                             .
   . +-----------------------|           |                             .
   .                         +-----------+                             .
   .                                                                   .
   .                                                                   .
   .                                                                   .
   .                           example.com                             .
   .....................................................................


                          Figure 5: 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
   determining the subdomained URI from the original URI or buddy name,



Rosenberg                 Expires May 13, 2008                 [Page 11]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   and then subscribing 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.

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

2.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 create a back-end subscription for a user it
   doesn't have, it forks the SUBSCRIBE 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 presence servers can differentiate inbound
   SUBSCRIBE requests from end users (which cause back-end subscriptions
   to get forked) and from other servers (which do not cause back-end
   subscriptions).  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.

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

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

2.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 2, the presence data for Alice
   lives on server 2 alone (recall that server two may be physically



Rosenberg                 Expires May 13, 2008                 [Page 12]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.


3.  Unioned

   In the unioned model, each user is actually served by more than one
   presence server.  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

   In essence, in the unioned model, a user's presence data is
   distributed across many presence servers.  In the partitioned model,
   its centralized in a single presence server.

   This definition speaks specifically to ownership of presence data 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 and notifications
      flowing between servers, and the user is potentially provisioned
      on both, there is no authoritative presence 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



Rosenberg                 Expires May 13, 2008                 [Page 13]


Internet-Draft      Intra-Domain Presence Federation       November 2007


      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
      actual server and their UA).  However, the server is acting as a
      proxy in this case.  There is only one source of presence
      information.

3.1.  Applicability

   The unioned models arise naturally for several reasons.

   Firstly, 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
   endpoints work only (or only work well) with the server from the same
   vendor.  In addition, certain vendors might specialize in specific
   types of clients, or provide features that are unique, such that a
   domain might wish to use clients from a multiplicity of vendors.  For
   example, one vendor might provide a mobile client (but no desktop
   client), while another provides a desktop client but no mobile
   client.  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 the unioned case.  This is shown in Figure 6.  Another
   example is where one vendor that provides a business telephone with
   presence, but no desktop client, while another provides a deskop
   client but no business telephone.

























Rosenberg                 Expires May 13, 2008                 [Page 14]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

                                  Alice

                         Figure 6: Unioned Case 1

   Secondly, 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 is
   can be determined manually (where the user enters and updates the
   information), or automatically.  Automatic determination of these
   states is far preferable, since it put 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



Rosenberg                 Expires May 13, 2008                 [Page 15]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   vendors are likely to specialize in particular pieces of presence
   data, based on the other infrastructure they provide.

   Consequently, though a user may have all of their devices connected
   to and associated with a single presence server, that presence server
   may have 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 7.



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


                         Figure 7: Unioned Case 2




Rosenberg                 Expires May 13, 2008                 [Page 16]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   Another use case for unioned federation are subscriber moves.
   Consider a domain which uses multiple presence servers, typically
   running in a partitioned configuration.  The servers are organized
   regionally so that each user is served by a presence 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 presence state existing on both servers at the same time.

3.2.  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 for the presentity
   in question are always routed first to one of the servers - the root
   - and then the root presence server subscribes to the next layer of
   presence servers (which may, in turn, subscribe to the presence state
   in other presence servers).  Each presence server composes the
   presence information it receives from its children, applying local
   authorization and composition policies, and then passes the results
   up to the higher layer.  This is shown in Figure 8.


























Rosenberg                 Expires May 13, 2008                 [Page 17]


Internet-Draft      Intra-Domain Presence Federation       November 2007


                              +-----------+
            *-----------*     |           |
            |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 8: 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 6.  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                 Expires May 13, 2008                 [Page 18]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

3.2.1.  Routing

   In the hierarchical model, each presence server needs to be
   provisioned with the root, its parent and its children presence
   servers for each presentity it handles.  These relationships could in
   fact be different on a presentity-by-presentity basis; however, this
   is complex to manage.  In all likelihood, the parent and child
   relationships are identical for each presentities.  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.

   o  If a SUBSCRIBE is received from a node that is not the parent node
      for this presentity, proxy the SUBSCRIBE to the parent node.  This
      includes cases where the node that sent the SUBSCRIBE 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 2.2.5.  This points to the forking algorithm as
   the "natural" routing algorithm for partitioned models.

   An important property of the routing in the hierarchical model is
   that the sequence of composition and policy operations are identical
   for all watchers to that presentity, regardless of which presence
   server they are associated with.  The result is that the overall
   presence state provided to a watcher is always consistent and
   independent of the server the watcher is connected to.  We call this
   property the *consistency property*, and it is an important metric in
   assessing the correctness of a federated presence system.






Rosenberg                 Expires May 13, 2008                 [Page 19]


Internet-Draft      Intra-Domain Presence Federation       November 2007


3.2.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 the server performing the back-
   end subscription.

   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.

   The principle challenge in a unioned presence 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.

3.2.2.1.  Root Only

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

















Rosenberg                 Expires May 13, 2008                 [Page 20]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

                            Figure 9: Root Only

   As long as the 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.  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
   provision policy in a single place (the root).  However, it has the
   drawback that the composition and policy processing may be performed



Rosenberg                 Expires May 13, 2008                 [Page 21]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   very poorly.  Presumably, the purpose of the multiplicity of presence
   servers is because each has access to and specializes in manipulation
   of certain pieces of presence state.  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.

3.2.2.2.  Distributed Provisioning

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

   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.

   Firstly, 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.

   Things get more complicated when one considers 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.





Rosenberg                 Expires May 13, 2008                 [Page 22]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.

   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 containg 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
   access to email servers, and separately in IM and presence
   applications for access to IM.

3.2.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 10.






Rosenberg                 Expires May 13, 2008                 [Page 23]


Internet-Draft      Intra-Domain Presence Federation       November 2007


                         +---------------------+
                         |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 10: Central Provisioning




Rosenberg                 Expires May 13, 2008                 [Page 24]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.

   For both the centralized and distributed provisioning approaches, 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 6, 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.

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

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



Rosenberg                 Expires May 13, 2008                 [Page 25]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   to which the watcher is connected (effectively acting as the root),
   and then the subscription is passed to other child presence servers.
   In essence, in the peer model, there is a per-watcher hierarchy, with
   the root being a function of the watcher.  Consider the use case in
   Figure 6 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
   subscription to presence server 1.  This is shown in Figure 11.



           alice@example.com           alice@example.com
            +------------+              +------------+
            |            |<-------------|            |<--------+
     SUB    |  Presence  |              |  Presence  |         |
     List w/|   Server   |              |   Server   |  SUB    |
     Alice  |     1      |              |     2      |  List w/|
      +---->|            |------------->|            |  Alice  |
      |     |            |              |            |         |
      |     +------------+              +------------+         |
      |        \                                /              |
      |         \                              /               |
      |          \                            /                |
      |           \                           /                |
      |            \                         /                 |
      |             \                       /                  |
   ...|........      \...................../.......   .........|........
   .          .       \                    /      .   .                .
   .          .       .\                  /       .   .    +--------+  .
   .   |      .       . \  |         +--------+   .   .    |+------+|  .
   .   |      .       .    |         |+------+|   .   .    ||      ||  .
   .  +---+   .       .   +---+      ||      ||   .   .    ||      ||  .
   .  |+-+|   .       .   |+-+|      ||      ||   .   .    |+------+|  .
   .  |+-+|   .       .   |+-+|      |+------+|   .   .    +--------+  .
   .  |   |   .       .   |   |      +--------+   .   .    /------ /   .
   .  |   |   .       .   |   |      /------ /    .   .   /------ /    .
   .  +---+   .       .   +---+     /------ /     .   .  --------/     .
   .          .       .            --------/      .   .                .
   .          .       .                           .   .                .
   ............       .............................   ..................

      Bob                       Alice                       Joe


                           Figure 11: Peer Model




Rosenberg                 Expires May 13, 2008                 [Page 26]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   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.  It ends up being a
   function of the composition policies of the individual servers.  If
   Pi() represents the composition and authorization policies of server
   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.

3.3.1.  Routing

   Routing in the peer model works similarly to the hierarchical model.
   Each presence server would be configured with the children it has
   when it acts as the root.  The overall 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 watchers 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.

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




Rosenberg                 Expires May 13, 2008                 [Page 27]


Internet-Draft      Intra-Domain Presence Federation       November 2007


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

   In addition, the policy processing in the peer model eliminates the
   problem described in Section 3.2.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.

3.3.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 7, 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.


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


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



Rosenberg                 Expires May 13, 2008                 [Page 28]


Internet-Draft      Intra-Domain Presence Federation       November 2007


   requires further discussion.


6.  Acknowledgements

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


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


8.  IANA Considerations

   There are no IANA considerations associated with this specification.


9.  Informative References

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

   [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



Rosenberg                 Expires May 13, 2008                 [Page 29]


Internet-Draft      Intra-Domain Presence Federation       November 2007


              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.

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


Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

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






























Rosenberg                 Expires May 13, 2008                 [Page 30]


Internet-Draft      Intra-Domain Presence Federation       November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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                 Expires May 13, 2008                 [Page 31]


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