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

Versions: (draft-rosenberg-simple-view-sharing) 00 01 02

SIMPLE                                                      J. Rosenberg
Internet-Draft                                                S. Donovan
Intended status: Standards Track                              K. McMurry
Expires: May 7, 2009                                               Cisco
                                                        November 3, 2008


            Optimizing Federated Presence with View Sharing
                   draft-ietf-simple-view-sharing-02

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

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   Presence federation refers to the exchange of presence information
   between systems.  One of the primary challenges in presence
   federation is scale.  With a large number of watchers in one domain
   obtaining presence for many presentities in another, the amount of
   notification traffic is large.  This document describes an extension
   to the Session Initiation Protocol (SIP) event framework, called view
   sharing.  View sharing can substantially reduce the amount of



Rosenberg, et al.          Expires May 7, 2009                  [Page 1]


Internet-Draft            Presence View Sharing            November 2008


   traffic, but requires a certain level of trust between domains.  View
   sharing allows the amount of presence traffic between domains to
   achieve the theoretical lower bound on information exchange in any
   presence system.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   3.  RLS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  On Receipt of a Resource List Subscription Request . . . .  8
       3.1.1.  Find a Matching Back-End Subscription  . . . . . . . .  8
       3.1.2.  Generating a  Back-End Subscription  . . . . . . . . .  9
     3.2.  Processing NOTIFY Requests . . . . . . . . . . . . . . . . 10
       3.2.1.  Processing ACL-Infos . . . . . . . . . . . . . . . . . 10
       3.2.2.  Processing State Documents . . . . . . . . . . . . . . 11
       3.2.3.  Processing Back-End Terminations . . . . . . . . . . . 11
   4.  Notifier Behavior  . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Authentication and Authorization . . . . . . . . . . . . . 12
     4.2.  Processing Initial SUBSCRIBE Requests  . . . . . . . . . . 12
     4.3.  SUBSCRIBE Refreshes  . . . . . . . . . . . . . . . . . . . 13
     4.4.  Policy Changes . . . . . . . . . . . . . . . . . . . . . . 13
     4.5.  Event State Changes  . . . . . . . . . . . . . . . . . . . 15
   5.  ACL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Document Structure and Semantics . . . . . . . . . . . . . 15
     5.2.  Trust Considerations when Construcing ACLs . . . . . . . . 17
     5.3.  Example Documents  . . . . . . . . . . . . . . . . . . . . 18
     5.4.  Rule Determination Algorithm . . . . . . . . . . . . . . . 19
     5.5.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21
   6.  Performance Analysis . . . . . . . . . . . . . . . . . . . . . 21
   7.  Requirements Analysis  . . . . . . . . . . . . . . . . . . . . 22
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     8.1.  Privacy Considerations of the Serving Domain . . . . . . . 24
     8.2.  Privacy Considerations of the Watched Resource . . . . . . 25
     8.3.  Interactions with S/MIME . . . . . . . . . . . . . . . . . 26
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  MIME Type Registration . . . . . . . . . . . . . . . . . . 26
     9.2.  URN Sub-Namespace Registration . . . . . . . . . . . . . . 27
     9.3.  Schema Registration  . . . . . . . . . . . . . . . . . . . 28
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     11.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 32





Rosenberg, et al.          Expires May 7, 2009                  [Page 2]


Internet-Draft            Presence View Sharing            November 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 SIP-based event package [RFC3856].

   Presence federation refers to the interconnection of disparate
   systems for the purposes of sharing presence information.  This
   interconnection involves passing of subscriptions from one system to
   another, and then the passing of notifications in the opposite
   direction.  Federation can be occur between different domains, where
   it is referred to as inter-domain federation.  However, federation
   can also occur within a domain, where it is referred to as intra-
   domain federation [I-D.ietf-simple-intradomain-federation].

   [I-D.ietf-simple-interdomain-scaling-analysis] has analyzed the
   amount of traffic, in terms of messages and in terms of bytes, which
   flow between systems in various federated use cases.  These numbers
   demonstrate that presence traffic can be a substantial source of
   overhead.  The root cause of this scale challenge is the so-called
   multiplicative effect of presence data.  If there are N users, each
   of which have B buddies on their buddy list, and each buddy changes
   state L times per hour, the amount of notification traffic is
   proportional to N*B*L. For example, in the case of two extremely
   large public IM providers that federate with each other (each with 20
   million users), [I-D.ietf-simple-interdomain-scaling-analysis] shows
   that the amount of traffic due to these steady state notifications is
   18.4 billion messages per day, an astoundingly large number.
   Overhead for subscription maintenance and refreshes brings the total
   to 25.6 billion per day.

   The overhead for SIP-based presence can be reduced using SIP
   optimizations.  In particular, [I-D.ietf-sip-subnot-etags] can reduce
   the amount of traffic due to refreshes and polls.  However, this
   optimization targets the overhead, and doesn't address the core
   scaling problem - the multiplicative effect of presence data.

   For this reason, there is a clear need to improve the scale of SIMPLE
   in federated envrionments.
   [I-D.ietf-sipping-presence-scaling-requirements] has laid out a set
   of requirements for optimizations.  The essence of these requirements
   are that the extension should improve performance, while being
   backwards compatible and supporting the privacy and policy
   requirements of users.

   This document defines a mechanism called view sharing in support of
   those requirements.  The key idea with view sharing is that when



Rosenberg, et al.          Expires May 7, 2009                  [Page 3]


Internet-Draft            Presence View Sharing            November 2008


   there are many watchers in one system to a single presentity in
   another system, each of which is actually going to get the exact same
   presence document, the watcher's system extends a single subscription
   to the system of the presentity, and the system of the presentity
   sends a single copy of the presence document back to the system of
   the watcher.  Consequently, a "view" is a particular sequence of
   presence documents that come about as a consequence of a particular
   composition, authorization and privacy policy.  Two watchers which
   share the same view will always receive the same presence document
   when the state of the presentity changes.

   Though this mechanism can be applied intra-domain as well as inter-
   domain, the specification considers only the inter-domain case.  In
   addition, though the principal application of view sharing is for
   presence, it is a general extension to the SIP events framework and
   specified in that way.

   In the case of a pair of large providers that are peering with each
   other, this mechanism can result in a significant savings.  Assuming
   a symmetrical system whereby the average buddies per watcher is B and
   the average number of watchers for a user is also B, if most buddies
   are in one domain or the other, this optimization can reduce the
   overall subscription overhead and notification traffic by a factor of
   B/2.  In cases where there are a large number of small domains, this
   mechanism is less useful.  Of course, in such cases, the amount of
   traffic between any pair of domains is small anyway.


2.  Overview of Operation

   The extension works in the environment shown in Figure 1.  For
   explanatory purposes, the environment assumes two domains.  There are
   some number of subscribers (W1 - W3) in the domain on the left, which
   we call the subscribing domain.  All of those subscribers are
   interested in the state of a single resource P1 in the domain on the
   right, which we call the serving domain.  The subscribers all make
   use of a resource list server (RLS) [RFC4662] which stores their
   resource lists and performs the list expansion.  Consequently, when
   each subscriber subscribes to their resource list on the RLS, in
   absence of any optimizations, the RLS will generate three separate
   subscriptions to P1, each of which reaches the notifier in the
   serving domain.









Rosenberg, et al.          Expires May 7, 2009                  [Page 4]


Internet-Draft            Presence View Sharing            November 2008


                                        .
                +--------------+        .     +--------------+
                |              |        .     |              |
                |              |  SUB   .     |              |
                |              | -------.---> |              |
                |     RLS      |  NOT   .     |  Notifier    |
                |              | <------.---- |              |
                |              |        .     |              |
                |              |        .     |              |
                +--------------+        .     +--------------+
                 ^      ^     ^         .            ^
          List   |      |     |         .            | PUB
          SUB    |      |     |         .            |
                 |      |     |         .            |
             +----+  +----+  +----+     .          +----+
             |    |  |    |  |    |     .          |    |
             | W1 |  | W2 |  | W3 |     .          | P1 |
             |    |  |    |  |    |     .          |    |
             +----+  +----+  +----+     .          +----+
                                        .
                                        .
                                        .
                Subscribing             .        Serving
                Domain                  .        Domain
                                        .











                        Figure 1: Deployment Model

   Of course, in practice each domain will act as both a subscribing
   domain and a serving domain, thus implementing both sides of the
   system.

   The initial SUBSCRIBE generated by the RLS includes a SIP option tag
   "view-share" in the Supported header field, indicating that the RLS
   supports the view sharing extension.  If the notifier also supports
   the extension, it makes use of it and includes an indication of this
   fact in the Require header field in the SUBSCRIBE response and in
   NOTIFY requests it generates.



Rosenberg, et al.          Expires May 7, 2009                  [Page 5]


Internet-Draft            Presence View Sharing            November 2008


   View sharing requires a level of trust between the two domains.
   Typically, TLS will be deployed between them, and the notifier uses
   it to determine if the subscribing domain is authorized.

   If this is the first subscription from domain 1 for that particular
   resource, the notifier accepts the subscription (assuming the
   subscriber is authorized of course).  The notifications sent to the
   RLS include two separate pieces of state.  One is the actual state
   for the resource.  The other is an Access Control List (ACL)
   document.  This document describes the set of other subscribers from
   the originating domain, if any, who are authorized to see exactly the
   same document - in other words, the set of users that share the same
   view.  Should one of those subscribers seek the state of that
   resource for the same event package, the RLS from the originating
   domain does not need to generate a back-end subscription; rather, it
   just uses the document it is receiving from the original
   subscription, and passes it to both subscribers.  The ACL can also
   list users in the originating domain that are authorized to subscribe
   to that resource, but who will end up receiving a different view.
   Should one of those subscribers subscribe, the RLS knows that it must
   perform a back-end subscription to obtain that view.  The ACL can
   also list subscribers in the originating domain that are not
   authorized at all, in which case the RLS could immediately reject
   their subscriptions.  Finally, if the ACL says nothing about a
   particular subscriber, it means that the notifier has elected to say
   nothing about what view this subscriber will receive.  Consequently,
   the RLS must perform a back-end subscription should that subscriber
   subscribe to the resource.

   Other subsequent subscriptions to the same resource from the same
   originating domain are processed in a similar way.  However, the
   notifier in the serving domain will keep track of the set of
   subscriptions to the same resource for the same event package from
   the same RLS which are to receive the same view.  When a presence
   notification is to be sent, instead of sending it on all such
   subscriptions, the notification is sent on just a single
   subscription.

   Should the authorization policies in the serving domain change, an
   updated ACL is sent, informing the subscribing domain of the new
   policies.  This may require the subscribing domain to extend a back-
   end subscription to obtain a view, or may change the view an existing
   subscriber is receiving, and so on.

   The ACL allows the serving domain a great deal of flexibility in the
   level of trust it imparts to the watching domain.  The following are
   all possible approaches that the serving domain can utilize:




Rosenberg, et al.          Expires May 7, 2009                  [Page 6]


Internet-Draft            Presence View Sharing            November 2008


   No Trust:  When a notifier receives the subscription, it elects not
      to use this mechanism at all using the negotiation techniques
      defined here.

   Minimal Trust:  When a subscriber subscribes to a resource, the ACL
      generated for that subscription includes only that subscriber,
      along with an identifier for their view.  Consequently, for each
      subscriber in domain 1 there will be a backend subscription to
      domain 2.  However, should multiple subscribers share the same
      view, the notifier in domain 2 sends a single document on one of
      the subscriptions, and the RLS uses this for all of the other
      subscribers with the same view.  With this approach, domain 2
      never discloses the list of authorized subscribers ahead of time,
      and it has full knowledge of each subscriber that is subscribed.
      However, it gets the performance benefits of reducing the amount
      of notification traffic.

   Partial Trust:  When a subscriber subscribes to a resource, the ACL
      generated for that subscription includes that subscriber and all
      other subscribers authorized for that same view.  Consequently,
      there will only be one backend subscription from the RLS to the
      notifier for each view.  However, the full set of authorized
      subscribers is not disclosed ahead of time, only those that will
      get the same view.  With partial trust, the notifier will not know
      the full set of subscribers currently subscribed.

   Full Trust:  When a subscriber subscribes to a resource, the ACL
      generated for that subscription includes that subscriber and all
      other subscribers that are authorized for that view, and all other
      views, along with a rule that says that all other subscribers get
      rejected.  In this case, as with partial trust, there is only one
      backend subscription from the RLS to the notifier for each view.
      The full set of subscribers is disclosed ahead of time as well.
      The notifier will not know the full set of subscribers currently
      subscribed.

   Depending on the level of trust, the mechanism trades off inter-
   domain messaging traffic for increased processing load in the RLS to
   handle the ACL documents.


3.  RLS Behavior

   This section defines the procedures that are to be followed by the
   RLS.  It is important to note that, even though this specification
   defines an extension to the SIP events framework, the extension is
   only useful for the back-end subscriptions generated by an RLS.  The
   extension defined here is not applicable or useful for individual



Rosenberg, et al.          Expires May 7, 2009                  [Page 7]


Internet-Draft            Presence View Sharing            November 2008


   users generating subscriptions.  Indeed, if it were utilized by
   individual users, it has the potential for violations of user
   privacy.  See Section 8 for a discussion.

3.1.  On Receipt of a Resource List Subscription Request

   When the RLS receives a subscription to a resource list which
   includes some resource P in another domain or system, it follows the
   rules defined here.  The processing depends on whether the RLS
   already has a backend subscription to the resource that is in the
   active state, and for which an ACL has been received.

3.1.1.  Find a Matching Back-End Subscription

   First, the RLS determines if it has a back-end subscription in place
   whose view corresponds to that of the new subscriber.  Let P be the
   target resource, E the desired event package, and W the identity of
   the subscriber.

   Based on the procedures of Section 3.2.1, the RLS will keep, for each
   resource and event package, the list of the most recent ACLs received
   on each back-end subscription currently in place.  This is called the
   current ACL list.  Using this ACL list, the RLS performs the rule
   determination algorithm of Section 5.4 to compute the rule ID R for
   the subscriber W. This represents the view that the subscriber is
   supposed to receive.

   Next, the RLS goes through all subscriptions it currently has for
   resource P and event package E. For each one, it takes the identity
   of the subscriber for that actual subscription.  The identity for the
   subscriber for that actual subscription is equal to the asserted
   identity included in the back-end subscription.  For example, if SIP
   Identity [RFC4474] is utilized, this would be the URI present in the
   From header field of the back-end SUBSCRIBE.  Call the subscriber
   identity for each subscription Wj.

   Next, the RLS computes the rule determination algorithm of
   Section 5.4 to compute the rule ID Rj for the subscriber Wj on each
   subscription j.  This represents the rule ID for the view being
   delivered on that subscription.

   Then, processing depends on the values of R and Rj:

   o  If R is null, it means that no ACL in the list specifies the view
      for this subscriber.  The RLS MUST generate a back-end
      subscription to resource P and event package E, and MUST use
      subscriber W as the identity in the back-end subscription.




Rosenberg, et al.          Expires May 7, 2009                  [Page 8]


Internet-Draft            Presence View Sharing            November 2008


   o  If R is not null, but the associated rule is blocked, it means
      that the subscriber will be rejected.  The RLS SHOULD NOT perform
      another back-end subscription, and must act as if it had created a
      back-end subscription which was rejected.

   o  If R is not null, and there is at least one subscription j for
      which Rj = R, it means that subscription j is already generating
      notifications for the view that subscriber W is supposed to
      receive.  In that case, the RLS SHOULD NOT generate a back-end
      subscription for P on behalf of W. Rather, it should treat the
      existing back end subscription j as if it were the back-end
      subscription for W, and follow the guidelines of RFC 4662
      [RFC4662] based on that.  Subscription j is called the generating
      subscription for subscriber W, and the actual subscriber
      associated with subscription j, Wj, is called the generating
      subscriber Wgen for subscriber W.

   o  If R is not null, but there is no subscription j for which Rj=R,
      it means that the RLS is not yet receiving the view that
      subscriber W requires.  The RLS MUST generate a back-end
      subscription to resource P, and MUST use subscriber W as the
      identity in the back-end subscription.

3.1.2.  Generating a  Back-End Subscription

   If, based on the processing of the previous section, a new back-end
   subscription is needed, the rules in this section are followed.

   The RLS MUST include a Supported header field in the request with the
   option tag "view-share".  The Accept header field MUST be present in
   the request and MUST include the "application/viewshare-acl+xml" MIME
   type amongst the list of supported types.  The RLS MUST include an
   +sip.instance Contact header field parameter [I-D.ietf-sip-outbound]
   to uniquely identify the RLS instance.

   Note that it is possible that two subscribers, in a short period of
   time, both subscribe to their resource lists, both of which include
   resource P. This will cause the RLS to generate two back-end
   subscriptions at around the same time.  The RLS is forced to generate
   the second back-end subscription because it doesn't have an active
   back-end subscription that has yet generated an ACL.  Once both
   subscriptions become active and generate ACLs, if the subscribers are
   receiving the same view and both ACLs contain both subscribers, the
   RLS SHOULD terminate one of the back-end subscriptions.







Rosenberg, et al.          Expires May 7, 2009                  [Page 9]


Internet-Draft            Presence View Sharing            November 2008


3.2.  Processing NOTIFY Requests

   If a NOTIFY request arrives with a Require header field that includes
   the "view-share" option tag, it MUST be processed according to the
   rules of this specification.

3.2.1.  Processing ACL-Infos

   If the contents of the NOTIFY are of type "application/
   viewshare-acl+xml", the subscriber processes the body as described
   here.

   For each resource that the RLS has at least one back-end subscription
   for, the RLS MUST remember the most recent viewshare-acl received on
   each back-end subscription.  This is called the current ACL list for
   the resource.  This set of viewshare-acl is used in the processing of
   subscription requests, as described in Section 3.1.1.

   The serving domain can change policies at any time.  When it does, it
   sends an updated ACL on one or more subscriptions.  The RLS MUST
   store this ACL, replacing any previous ACL's received on this
   subscription.  Furthermore, the ACL might impact the views being
   received by subscribers, and may impact the state of the back-end
   subscriptions.

   The RLS computes the set of subscribers Wi which have a resource list
   subscription that includes the resource P for whom an updated ACL has
   just been received.  For each Wi, it performs the view determination
   algorithm (see Section 5.4 on the current ACL set.  Let Ri be the
   view associated with subscriber Wi.  If Ri has not changed from prior
   to the receipt of the new ACL, no action is taken.  However, if it
   has changed, the RLS takes the set of current back-end subscriptions,
   and for each subscription j, computes the view determination
   algorithm for its associated subscriber Wj, to produce Rj.  The
   action to take depends on what has changed:

   o  If Ri is now null, it means that the serving domain has changed
      the views associated with subscriber Wi, and this new view is not
      known to the RLS.  The RLS MUST generate a new back-end
      subscription on behalf of subscriber Wi for resource P to obtain
      this view.

   o  If Ri is now a blocked rule, it means that the serving domain has
      now blocked Wi from obtaining the presence of the resource.  The
      RLS must act as if it had a back-end subscription on behalf of
      subscriber Wi which was terminated.





Rosenberg, et al.          Expires May 7, 2009                 [Page 10]


Internet-Draft            Presence View Sharing            November 2008


   o  If Ri is not null and not blocked, and if there is an Rj which
      matches the new Ri, it means that the serving domain has changed
      the views associated with subscriber Wi, and changed them to
      another view already being received by the RLS.  The RLS MUST
      treat this back-end subscription j as if it were the back-end
      subscription to resource P for subscriber Wi.  If the most recent
      presence document received on this back-end subscription is not a
      semantic match for the presence document most recently delivered
      to Wi for resource P, the RLS MUST send this most recent presence
      document to subscriber Wi.

   o  If Ri is not null and not blocked, but there is no Rj which
      matches the new Ri, it means that the serving domain has changed
      the views associated with subscriber Wi, and this new view is not
      one currently being delivered to the RLS.  The RLS MUST generate a
      new back-end subscription on behalf of subscriber Wi for resource
      P to obtain this view.

   Furthermore, if there are now two back-end subscriptions j1 and j2
   which have identical ACLs, RLS SHOULD terminate one of those two
   subscriptions.  Two ACL documents are considered equal if they
   enumerate the same set of rules with the same members for each rule.

3.2.2.  Processing State Documents

   If the contents of the NOTIFY is a state document for the given event
   package, the RLS follows the procedures defined here.

   Let Wj be the subscriber on the subscription j on which the document
   was just received.  Let Rj be the results of running the rule
   determination algorithm on Wj using the current ACL set.  Next, the
   RLS takes the set of subscribers Wi which have resource P on their
   resource lists.  The RLS then runs the rule determination algorithm
   on each Wi using the current ACL set, producting Ri for each
   subscriber Wi.  For each Ri that is equal to Rj, the RLS MUST utilize
   the document just received as if the back-end subscription j was in
   fact for subscriber Wi.  This will typically cause that document to
   be sent in a NOTIFY request to each such subscriber, though each
   subscriber may have some kind of filtering policy which causes the
   RLS to modify the document prior to delivery.

3.2.3.  Processing Back-End Terminations

   If the NOTIFY request from the serving domain terminates the back-end
   subscription, it may be because the subscriber Wj associated with
   that subscription is no longer permitted to view the state of the
   resource.




Rosenberg, et al.          Expires May 7, 2009                 [Page 11]


Internet-Draft            Presence View Sharing            November 2008


   The ACL associated with the subscription MUST be removed from the
   current ACL set.  The procedures of Section 3.2.1 MUST be performed
   to adjust back-end subscriptions, if needed.


4.  Notifier Behavior

   When a notifier receives a SUBSCRIBE request containing a Supported
   header with the value "view-share", and it wishes to utilize view
   sharing for this subscription, it follows the procedures defined
   here.

4.1.  Authentication and Authorization

   The principle concern of the notifier is to determine the domain of
   the RLS, and assess whether the subscribing entity is an RLS
   authorized to operate on behalf of that domain.  In order to utilize
   view sharing, a notifier MUST determine both.  This information is
   necessary in order to compute the ACL to be sent to that domain, and
   if done incorrectly, may reveal sensitive information to the watching
   domain.

   To determine the domain of the subscribing RLS, TLS with mutual
   authentication SHOULD be used.  In such a case, the notifier can
   determine the domain of the RLS from the subjectAltName in the
   certificate presented from its peer.

   This specification does not define any automated mechanism for a
   notifier to determine whether the subscribing entity is, in fact, an
   RLS authorized to operate on behalf of the watching domain.
   Section 8 discusses why this determination is important.  Absent an
   automated mechanism, notifiers SHOULD support a configuration option
   which allows the administrator to enumerate a set of domains for
   which it is known that an entity holding a certificate for that
   domain is an authorized RLS.  In such a case, the subject from the
   certificate can be compared against that list, and if a match is
   found, view sharing can be utilized for this subscription.

4.2.  Processing Initial SUBSCRIBE Requests

   First, the subscription is processed as it normally would be,
   including authorization and policy around the document to be
   delivered to the subscriber.  Furthermore, if the notifier wishes to
   utilize view sharing for this subscription, it MUST include a Require
   header field in the first NOTIFY request (and indeed any subsequent
   ones) it sends confirming this subscription, and that NOTIFY MUST
   contain the "view-share" option tag.  That option tag MUST NOT be
   present in the Require header field of notifications unless the



Rosenberg, et al.          Expires May 7, 2009                 [Page 12]


Internet-Draft            Presence View Sharing            November 2008


   corresponding dialog-forming SUBSCRIBE contained it in a Supported
   header field.

   Furthermore, the initial state sent by the notifier MUST include an
   ACL document.  It is formatted according to the rules and
   considerations in Section 5.

   The initial state sent by the notifier might include an actual state
   document.  In particular, a state document MUST be sent if one of the
   following is true:

   o  There is only one subscription from the watching domain to this
      resource that has the view associated with the subscriber.

   o  There is more than one subscription from the watching domain to
      this resource with the same view, but the +sip.instance parameter
      for the remote target (as conveyed in the Contact header field of
      the SUBSCRIBE) differs.  In other words, these subscriptions are
      from the same domain, but from different RLS in the watching
      domain.  Each RLS in the watching domain needs to get their own
      copy of the view for a particular resource.

   If one of these conditions is not true, the notifier SHOULD NOT send
   an initial state document on this subscription.

   If an ACL and a state document are to be delivered, they MUST be
   delivered separate NOTIFY requests unless the subscriber indicated
   support for multipart, in which case the content MAY be included in a
   single NOTIFY with mulitpart content.

4.3.  SUBSCRIBE Refreshes

   When the notifier receives a SUBSCRIBE refresh, it MUST send the most
   recent ACL document, and if state documents are being sent for this
   subscription, the most recent state document.

4.4.  Policy Changes

   There are several different types of policy changes that can occur:

   o  If the definitions for a particular rule change, the notifier MUST
      assign a new rule ID for that rule.  For each subscription to a
      resource which contained that rule, the notifier MUST send an
      updated ACL which includes a rule with this new rule ID.

   o  If some subscriber W was previously associated with rule X and is
      now associated with rule Y, the notifier checks if it has any
      subscriptions from subscriber W. If it does, it MUST send an



Rosenberg, et al.          Expires May 7, 2009                 [Page 13]


Internet-Draft            Presence View Sharing            November 2008


      updated ACL on that subscription.  Based on the rules in
      Section 5, this ACL will contain rule Y and will at least include
      W amongst the list of members.  Furthermore, if there were
      subscriptions from other subscribers, but the notifier had
      previously sent an ACL on the subscription which was a match for
      W, it MUST send an updated ACL on that subscription.  This updated
      ACL MAY omit a statement about rule Y or MAY include it.  However,
      the updated ACL MUST NOT claim that subscriber W will receive rule
      X.

   o  If some subscriber W was previously associated with rule X and is
      now blocked, the notifier checks if it has any subscriptions from
      subscriber W. If it does, it MUST terminate the back-end
      subscription.  If it doesn't, but it has a subscription from some
      other subscriber which had included a rule that was a match for W,
      the notifier MUST send an updated ACL on that subscription.  This
      updated ACL MAY omit any statement about subscriber W, or MAY
      include them as part of a blocked rule in that ACL.

   o  If some subscriber W was previously blocked and is now permitted
      and associated with some rule X, the notifier checks if it had any
      subscriptions from some other subscriber which included a blocked
      rule that matched subscriber W. If it had, it MUST send an updated
      ACL on that subscription.  That updated ACL MAY omit any statement
      about subscriber W, or MAY indicate that subscriber W is now
      associated with rule X.

   Of course, a policy change will also potentially alter the state
   documents that are associated with a view.  If so, the notifier MUST
   send an updated document on a subscription if one of the following is
   true:

   o  There is only one subscription from the watching domain to this
      resource that has the view associated with the subscriber.

   o  There is more than one subscription from the watching domain to
      this resource with the same view, but the +sip.instance Contact
      header field in the request differs between them.

   If neither is true, the notifier MUST select one subscription amongst
   the several which share the same resource, view, and Contact
   +sip.instance header field parameter, and sent an updated
   notification on that subscription.  The choice of subscriptions is
   arbitrary and MAY change for each notification.







Rosenberg, et al.          Expires May 7, 2009                 [Page 14]


Internet-Draft            Presence View Sharing            November 2008


4.5.  Event State Changes

   If the state of some resource changes, the notifier may need to send
   an updated notification on a subscription.  The notifier MUST send an
   update on a subscription if one of the following is true:

   o  There is only one subscription from the watching domain to this
      resource that has the view associated with the subscriber.

   o  There is more than one subscription from the watching domain to
      this resource with the same view, but the +sip.instance Contact
      header field in the request differs between them.

   If neither is true, the notifier MUST select one subscription amongst
   the several which share the same resource, view, and Contact
   +sip.instance header field parameter, and sent an updated
   notification on that subscription.  The choice of subscriptions is
   arbitrary and MAY change for each notification.


5.  ACL Format

   An ACL document is an XML [W3C.REC-xml-20001006] document that MUST
   be well-formed and MUST be valid according to schemas, including
   extension schemas, available to the validater and applicable to the
   XML document.  ACL documents MUST be based on XML 1.0 and MUST be
   encoded using UTF-8.  This specification makes use of XML namespaces
   for identifying ACL documents and document fragments.  The namespace
   URI for elements defined by this specification is a URN [RFC2141],
   using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648]
   and extended by RFC 3688 [RFC3688].  This URN is:

      urn:ietf:params:xml:ns:viewshare-acl

5.1.  Document Structure and Semantics

   An ACL document informs a watching domain of the set of views that
   can be received by that domain, and associates specific subscribers
   with specific views.  It is very important to understand that the ACL
   document does not convey the actual processing that will be applied
   by the serving domain.  It does not indicate, for example, whether
   geolocation is present in a presence document, or which rich presence
   [RFC4480] data elements will be conveyed.  It merely provides
   grouping - indicating which subscribers from the subscribing domain
   will receive the same view.

   Each ACL document starts with the enclosing root element <acl-list>.
   This contains the list of rules defined by the ACL.  Each rule is



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


Internet-Draft            Presence View Sharing            November 2008


   represented by the <rule> element.  Each rule represents a specific
   view, which is generated by the notifier based on its authorization,
   composition and filtering policies.  Each rule is associated with a
   rule ID, which is a mandatory attribute of the <rule> element.  This
   ID is scoped within a single resource.  That is, the IDs for two
   rules for different presentities are unrelated.

   The <rule> element also contains an optional "blocked" boolean
   attribute.  If "true", it means that the rule specifies that the
   associated set of subscribers will be rejected, should they
   subscribe.  This can be used by the watching domain to avoid
   performing back-end subscriptions to users which will only be blocked
   anyway.

   Each <rule> contains the set of users that will receive the
   corresponding view.  This can be described by an enumerated set or by
   a default.  If it is an enumerated set, the <rule> is followed by a
   sequence of <member> elements, each of which contains a SIP URI for
   the subscriber that will receive that view.

   The default view is specified by including a single child element for
   <rule> - <other>.  The default view applies to all subscribers except
   those enumerated by other rules.  For this reason, an ACL document
   which contains a default view MUST include the rule IDs and
   associated members for all other views that are delivered to
   subscribers.  For example, consider a resource that has three views.
   View 1 is delivered to subscribers A and B. View 2 is delivered to
   subscriber C. View 3 is delivered to everyone else.  An ACL document
   that includes the default view must also include views 1 and 2 with
   subscribers A, B, and C.

   In contrast, an ACL document that does not include a default does not
   need to include all views, and it does not need to include all
   members for a particular view.  Using the example above, it is valid
   to include an ACL document which includes only view 1 with subscriber
   1.

   If two URI are present within <member> elements within the same
   <rule>, it represents an indication by the notifier that both users
   MUST get the same view.  Formally, if the notifier were to receive a
   subscription from each subscriber, both subscriptions would be
   accepted or both would be rejected, and if accepted, each
   subscription would receive semantically identical presence documents
   at approximately the same time.

   Even if two users will receive the same view, a notifier MAY assign
   each to a different view ID.  There is no requirement that two unique
   views actually contain different presence data.  The only requirement



Rosenberg, et al.          Expires May 7, 2009                 [Page 16]


Internet-Draft            Presence View Sharing            November 2008


   is that, if two users are listed within the same rule, that they do
   in fact receive the same view.

   An ACL document delivered in a subscription from subscriber W MUST
   include the view associated with subscriber W and MUST include
   subscriber W explicitly in a <member> element or implicitly by
   presence of an <other> element.

5.2.  Trust Considerations when Construcing ACLs

   The semantics above give very little guidance about what a notifier
   should include in an ACL.  The amount of information to convey
   depends on the level of trust between the subscribing and serving
   domains.

   Firstly, in all cases, any subscriber listed in a rule MUST be one
   that the subscribing RLS is authorized to perform subscriptions for.
   Typically, this is all of the subscribers in the domain of the RLS.
   For example, if a view-sharing subscription is received from
   example.com, only subscribers whose domain is example.com should be
   included in the ACL.  However, in cases where view sharing is used
   between a clearinghouse provider and clearinghouse members, the ACL
   could include subscribers in other domains, based on the policy of
   the serving domain.

   Optimal performance is achieved when the ACL document for a resource
   includes all views that the server might ever deliver to subscribers
   from the watching domain, and includes all members from that domain
   for each view, including any defaults and blocked rules.  However,
   this informs the watching domain of the set of allowed and blocked
   subscribers from its own domain, and associated groupings amongst
   subscribers.

   Slightly worse performance is achieved when the ACL document for a
   resource sent in a subscription from subscriber W includes only a
   single view - the one for subscriber W - along with the full set of
   subscribers from that domain which will also receive that view,
   assuming it is not the default view.  If the view is the default
   view, the document can include just subscriber W. This approach will
   cause back-end subscriptions from every subscriber that will receive
   the default, but it discloses less information to the watching
   domain.  In particular, the full set and number of views is never
   known by the watching domain.  The fact that a view is default is
   never known by the watching domain.  The full set of users that are
   permitted to view the state of the resource is never disclosed to the
   watching domain.  The performance of this approach is still
   reasonably good when the default rule is blocked.  However it is much
   less effective when the default is not blocked, and many subscribers



Rosenberg, et al.          Expires May 7, 2009                 [Page 17]


Internet-Draft            Presence View Sharing            November 2008


   receive the default.

   Another choice for construction of ACL documents is to include, in a
   subscription from subscriber W, a single rule containing the rule ID
   for the view that subscriber W will receive, along with a single
   member - W. This approach will still result in a back-end
   subscription from each subscriber.  However, a single notification is
   sent for each view, rather than one per subscriber.  The benefit of
   this construction is that it provides the watching domain no
   additional information about the authorization policies of the
   resource than if this extension were not in use at all.

5.3.  Example Documents

   The example document in Figure 2 shows the case when there is maximum
   trust between domains.  The full set of subscribers, include a
   blocked default, is included.


<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <rule id="6228">
    <member>sip:user1@example.com</member>
    <member>sip:user2@example.com</member>
    <member>sip:user3@example.com</member>
    <member>sip:user4@example.com</member>
    <member>sip:user5@example.com</member>
  </rule>
  <rule id="3584">
    <member>sip:user6@example.com</member>
  </rule>
  <rule id="1735">
    <member>sip:user7@example.com</member>
    <member>sip:user8@example.com</member>
    <member>sip:user9@example.comm</member>
    <member>sip:user10@example.com</member>
    <member>sip:user11@example.com</member>
  </rule>
  <rule blocked="true" id="9433">
    <other />
  </rule>
</acl-list>

                   Figure 2: Example with Maximum Trust

   The example in Figure 3 shows a moderate level of trust.  This ACL
   only shows the view associated with the subscriber user1.



Rosenberg, et al.          Expires May 7, 2009                 [Page 18]


Internet-Draft            Presence View Sharing            November 2008


<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <rule id="6228">
    <member>sip:user1@example.com</member>
    <member>sip:user2@example.com</member>
    <member>sip:user3@example.com</member>
    <member>sip:user4@example.com</member>
    <member>sip:user5@example.com</member>
  </rule>
</acl-list>

                   Figure 3: Example with Partial Trust

   The example in Figure 4 shows the minimal level of trust.  This ACL
   would be sent in a subscription to user1.


<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <rule id="6228">
    <member>sip:user1@example.com</member>
  </rule>
</acl-list>

                   Figure 4: Example with Minimal Trust

5.4.  Rule Determination Algorithm

   Several steps in the processing of the ACL require that the RLS in
   the watching domain execute the rule determination algorithm for
   subscriber W on an ACL set.  This algorithm is a simple algorithm
   which takes, as input, a subscriber W with a given SIP URI, and a set
   of ACL documents Ai, and returns as output, a rule ID R, which is the
   rule ID for the view that, according to the set of ACLs, subscriber W
   should receive.

   The algorithm proceeds as follows.  First, each Ai is matched to W.
   ACL Ai is a match for subscriber W if:

   o  ACL Ai contains a <member> tag whose URI is a match, based on URI
      equality, for W, or

   o  none of the <member> tags in Ai contain a URI that is a match,
      based on URI equality, for W, but there is an <other> element in
      Ai




Rosenberg, et al.          Expires May 7, 2009                 [Page 19]


Internet-Draft            Presence View Sharing            November 2008


   If no ACL Ai matched, the algorithm returns a null result.

   For each ACL Ai that matches based on the rules above, take the id of
   the enclosing <rule> element that contained the <member> or <other>
   element that caused the match.  For ACL Ai, this is rule Ri.  For
   example, consider the following ACL:


   <?xml version="1.0" encoding="UTF-8"?>
   <acl-list "xmlns=urn:ietf:params:xml:ns:viewshare-acl">
       <rule id="1">
         <member>sip:user1@example.com</member>
         <member>sip:user2@example.com</member>
       </rule>
       <rule id="2">
          <member>sip:user3@example.com</member>
       </rule>
       <rule id="3">
         <other/>
       </rule>
    </acl-list>

   If this document is A1, and the subscriber is sip:user3@example.com,
   the associated rule R1 is 2.  If the subscriber is
   sip:user1@example.com or sip:user2@example.com, the rule R1 is 1.  If
   the subscriber is anyone else from example.com, such as
   sip:user4@example.com, the rule R1 is 3.

   If all Ri are equal, denote R = Ri.  Thus, R is the rule ID
   associated with this subscriber.  Normally, all Ri will be equal.
   However, during transient periods of changes in authorization state,
   it is possible that inconsistent ACL documents exist.  In that case,
   R is assigned the value Ri from the ACL Ai which is the most recently
   received amonst all ACLs.

















Rosenberg, et al.          Expires May 7, 2009                 [Page 20]


Internet-Draft            Presence View Sharing            November 2008


5.5.  XML Schema



<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="acl-list">
    <xs:complexType>
      <xs:sequence minOccurs="1" maxOccurs="unbounded">
        <xs:element name="rule">
          <xs:complexType>
            <xs:choice>
              <xs:element name="other" />
              <xs:sequence minOccurs="1" maxOccurs="unbounded">
                <xs:element name="member" type="xs:anyURI" />
              </xs:sequence>
            </xs:choice>
            <xs:attribute name="id" type="xs:integer" use="required" />
            <xs:attribute default="false" name="blocked" type="xs:boolean" use="optional" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>


6.  Performance Analysis

   This section considers the performance improvement of the mechanism
   when it is maximally exercised.  The performance is examined in the
   context of an inter-domain presence federation.  In this example, the
   full ACL, including blocked senders, is returned in the first
   subscription to a presentity.  This analysis assumes there is a
   single, monolithic notifier serving each domain.

   The optimizations improve ramp-up, steady state, and termination
   message loads.  In particular, each of those loads, without the
   optimization described here, is proportional to C04, the total number
   of federated presentities per watcher.  If we assume symmetry, such
   that the number of federated presentities per watcher is equal to the
   number of watchers per federated presentity, then each of the load
   figures is reduced by C04.  That is, the system behaves identically
   to the case where there is a single subscriber per federated
   presentity, and assuming symmetric, the same as if there is a single
   federated presentity per subscriber - e.g., C04 = 1.




Rosenberg, et al.          Expires May 7, 2009                 [Page 21]


Internet-Draft            Presence View Sharing            November 2008


   Consider then the very large network peering model in
   [I-D.ietf-simple-interdomain-scaling-analysis].  In this model, the
   assumption is two large peering domains with 20 million users each,
   with a value of 10 for C04.  With this optimization, the number of
   steady state notifications due to presence state changes drops from
   18.4 billion per day to 1.84 billion per day.  The number of messages
   per second overall is reduced from 654,167 per second to 65,417 per
   second.  Still a big number, of course, but it can't actually get
   much smaller.

   Indeed, it can be readily shown that, assuming the federated domains
   do not actually share raw presence inputs and the actual policies
   that govern operation of their servers, no protocol can do better
   (constants, such as mesage size and the need for protocol responses
   and acknowledgements aside).  Consider a domain with N presentities.
   Each resource changes state P times per hour.  Every time the state
   changes, the domain applies its authorization and composition
   policies.  The resulting presence document cannot be known to the
   watching domain.  Thus, there must be at least one message from the
   serving to watching domain, per view, in order to inform it of that
   view.  This means that the steady state rate of messages can never be
   better than N*P, and this is exactly the factor governing the rate of
   messages when this optimization is applied.


7.  Requirements Analysis

   This section analyzes the requirements in
   [I-D.ietf-sipping-presence-scaling-requirements] to show how they are
   met by the mechanism proposed here.

   REQ-001:  The solution should not hinder the ability of existing
      SIMPLE clients and/or servers from peering with a domain or client
      implementing the solution.  No changes may be required of existing
      servers to interoperate.  This requirement is met by usage of the
      Supported and Require mechanisms and SIP which negotiate its
      usage.

   REQ-002:  It does NOT constrain any existing RFC functional or
      security requirements for presence.  The mechanism does not change
      anything that is possible without it.  It does, however, introduce
      new privacy considerations, described below in Section 8.

   REQ-003:  Systems that are not using the new additions to the
      protocol should operate at the same level as they do today.  This
      requirement is met by usage of the Supported and Require
      mechanisms in SIP.




Rosenberg, et al.          Expires May 7, 2009                 [Page 22]


Internet-Draft            Presence View Sharing            November 2008


   REQ-004:  The solution does not limit the ability for presentities to
      present different views of presence to different watchers.  This
      requirement is met by usage of the ACL document, which allows the
      serving domain to associate a subscriber with any view it likes,
      and to change it over time.

   REQ-005:  The solution does not restrict the ability of a presentity
      to obtain its list of watchers.  The mechanism does allow a
      presence server to know the list of subscribers, at the expense of
      non-optimal performance.  In particular, it will receive a
      subscription from each subscriber.  However, it only generates one
      notification per view on presence changes.  The fully optimized
      solution will result in a loss of knowledge of the set of
      watchers.  However, it is a policy decision at the presence agent
      about whether it would like to make this tradeoff.

   REQ-006:  The solution MUST NOT create any new or make worse any
      existing privacy holes.  This requirement is met, but only when
      carefully provisioned.  See Section 8.

   REQ-007:  It is highly desirable for any presence system (intra or
      inter-domain) to scale linearly as number of watchers and
      presentities increase linearly.  When the most optimal technique
      is used, there is always one subscription per view per presentity,
      independent of the number of watchers in the remote domain or the
      number of averages buddies per buddy list.  Since the number of
      views is not proportional to the number of users, the total
      traffic volume in a domain is linear with its number of
      presentities, and is independent of the number of users in the
      peering domain.

   REQ-008:  The solution SHOULD NOT require significantly more state in
      order to implement the solution.  The mechanism requires storage
      of the ACL, which has a size exactly equal to the number of
      subscriptions that would be required if the extension were not in
      place.  Thus the memory usage is not worsened compared to the
      baseline.

   REQ-009:  It MUST be able to scale to tens of millions of concurrent
      users in each domain and in each peer domain.  The analysis in
      Section 6 shows that, when fully utilized, this mechanism is the
      best that can possibly be achieved in any system that does not
      actually share policies and raw presence data.

   REQ-010:  It MUST support a very high level of watcher/presentity
      intersections in various intersection models.  The mechanism is
      optimized for this case.




Rosenberg, et al.          Expires May 7, 2009                 [Page 23]


Internet-Draft            Presence View Sharing            November 2008


   REQ-011:  Protocol changes MUST NOT prohibit optimizations in
      different deployment models esp. where there is a high level of
      cross subscriptions between the domains.  Since standard SIP
      techniques are utilized to negotiate the extension, other
      mechansims can be defined in the future.

   REQ-012:  New functionalities and extensions to the presence protocol
      SHOULD take into account scalability with respect to the number of
      messages, state size and management and processing load.  That is
      exactly what this extension targets.

   REQ-013:  The solution SHOULD allow for arbitrary federation
      topologies including direct peering and intermediary routing.  The
      mechanism is optimized for direct peering.  It can work in
      intermediary routing cases as well.


8.  Security Considerations

   The principal question with the specification is whether it alters
   the privacy characteristics of a non-optimized federated system.
   This can be considered for both the serving domain and the
   subscribed-to resource.  In all cases, view sharing requires secure
   authentication and encryption between the domains that use it.  This
   is provided by TLS.

8.1.  Privacy Considerations of the Serving Domain

   Consider first the case where the serving domain is using the minimal
   trust model.  In that case, the ACL provided to the subscribing
   domain does not carry any information that the subscribing domain
   doesn't already know.  It merely points out when two subscribers
   share the same view.  This is something that the subscribing domain
   could have already ascertained by comparing presence documents
   delivered to each subscriber.  The ACL makes this task easier, but
   nonetheless the subscribing domain could have already ascertained it.
   Consequently, there is no change whatsoever in the level of privacy
   afforded by the optimization when this mode is used.

   However, when an ACL is provided that includes other users besides
   the actual subscriber, this provides additional information to the
   subscribing domain.  This is, however, information that the
   subscribing domain could find out anyway.  If it generated a
   subscription from each of its users to the resource it would be able
   to determine who from its domain is allowed to subscribe and what
   view they would receive.  This would be an expensive operation to be
   sure, but it is possible.  Consequently, the optimization doesn't
   really provide anything new to the originating domain, even in this



Rosenberg, et al.          Expires May 7, 2009                 [Page 24]


Internet-Draft            Presence View Sharing            November 2008


   case.

   However, there is an attack possible when the information is divulged
   to an end user.  Consider a subscribing domain that doesn't actually
   implement this extension at all.  A user within the domain uses a
   client that generates a subscription to a resource in a remote
   domain.  This subscription uses an outbound proxy in the watching
   domain.  The outbound proxy is just a proxy, and therefore doesn't
   remove or modify the Supported header field in the request.  The
   serving domain accepts the subscription and sends an ACL that
   contains the full set of subscribers that are permitted in the
   originating domain.  The original subscriber now knows the set of
   other authorized buddies within their own domain, and what views they
   will see.  While this is information that the domain overall would
   have access to, it is not information an end user would normally have
   access to.  Consequently, this is a more serious privacy violation.

   It is for this reason that this specification requires that both
   sides of the federated link be explicitly provisioned to utilize this
   optimization.  In the attack above, the subscribing domain would not
   have set up a peering relationship with the serving domain.  If it
   had, it would have an RLS and would not have permitted the user to
   directly subscribe in this way.  Thus, when the subscription is
   received by the serving domain, it will find that it has no agreement
   with the originating domain, and would not utilize view sharing.
   This thwarts the attack.

   This remedy is not optimal because it requires on provisioning to
   prevent.  There does not appear to be any easy cryptographic means to
   prevent it, however.

8.2.  Privacy Considerations of the Watched Resource

   The principle security concern for the watched resource is whether
   the documents shown to subscriber meet its privacy policies.  This is
   particularly a concern for presence.  These privacy policies can be
   violated if presence documents are shown to subscribers to whom the
   resource has not granted permission, or if they contain content that
   the resource has not allowed the subscriber to see.

   Based on the mechanisms defined in this specification, view sharing
   gives clear guidance to the watching RLS about which additional
   subscribers can see a particular presence document.  Consequently,
   under normal operating conditions, the system ensures that the
   privacy policies of the resource are met.  It is possible that a
   buggy implementation might accidentally redistribute presence
   documents to unauthorized subscribers.  Implementors SHOULD be
   careful to implement the ACL mechanism carefully to avoid this.  A



Rosenberg, et al.          Expires May 7, 2009                 [Page 25]


Internet-Draft            Presence View Sharing            November 2008


   malicious RLS or domain could ignore the ACL documents defined by
   this document, and distribute the presence documents to unauthorized
   subscribers.  However, such an attack is already possible in the
   normal operation of an RLS, and is not worsened by the view sharing
   mechanism defined here.

8.3.  Interactions with S/MIME

   The SIP and SIMPLE specifications do allow state documents to be
   signed and/or encrypted with S/MIME.  When S/MIME is used strictly
   for message integrity, view sharing is fully compatible with S/MIME.
   However, when presence documents are encrypted using S/MIME, this
   causes an interaction with view sharing.  The serving domain will
   send out only a single document to the watching domain for each view.
   This document needs to be decryptable by each authorized subscriber.
   Consequently, that group must either share a single key, or the
   serving domain needs to encrypt the content using the keys from each
   of the authorized subscribers.  In the latter case, view sharing and
   S/MIME cannot be used together if the set of authorized subscribers
   is wildcarded.


9.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

9.1.  MIME Type Registration

   This specification requests the registration of a new MIME type
   according to the procedures of RFC 2048 [RFC2048] and guidelines in
   RFC 3023 [RFC3023].

      MIME media type name: application

      MIME subtype name: viewshare-acl+xml

      Mandatory parameters: none

      Optional parameters: Same as charset parameter application/xml as
      specified in RFC 3023 [RFC3023].

      Encoding considerations: Same as encoding considerations of
      application/xml as specified in RFC 3023 [RFC3023].







Rosenberg, et al.          Expires May 7, 2009                 [Page 26]


Internet-Draft            Presence View Sharing            November 2008


      Security considerations: See Section 10 of RFC 3023 [RFC3023] and
      Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
      XXXX with the RFC number of this specification]].

      Interoperability considerations: none.

      Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
      Please replace XXXX with the RFC number of this specification]]

      Applications which use this media type: This document type has
      been used to support subscriptions to lists of users [RFC4662] for
      SIP-based presence [RFC3856].

      Additional Information:

         Magic Number: None

         File Extension: .acl

         Macintosh file type code: "TEXT"

         Personal and email address for further information: Jonathan
         Rosenberg, jdrosen@jdrosen.net

         Intended usage: COMMON

         Author/Change controller: The IETF.

9.2.  URN Sub-Namespace Registration

   This section registers a new XML namespace, as per the guidelines in
   RFC 3688 [RFC3688].

      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:viewshare-acl.

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      XML:











Rosenberg, et al.          Expires May 7, 2009                 [Page 27]


Internet-Draft            Presence View Sharing            November 2008


             BEGIN
             <?xml version="1.0"?>
             <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                       "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
             <html xmlns="http://www.w3.org/1999/xhtml">
             <head>
               <meta http-equiv="content-type"
                  content="text/html;charset=iso-8859-1"/>
               <title>ACL Info Namespace</title>
             </head>
             <body>
               <h1>Namespace for ACL Info</h1>
               <h2>urn:ietf:params:xml:ns:viewshare-acl</h2>
               <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.]</a>.</p>
             </body>
             </html>
             END

9.3.  Schema Registration

   This section registers an XML schema per the procedures in [RFC3688].

      URI: urn:ietf:params:xml:schema:viewshare-acl

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      The XML for this schema can be found as the sole content of
      Section 5.5.


10.  Acknowledgements

   The authors would like to thank Avshalom Houri, Richard Barnes, and
   Michael Froman for their comments on this document.


11.  References

11.1.  Normative References

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

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for



Rosenberg, et al.          Expires May 7, 2009                 [Page 28]


Internet-Draft            Presence View Sharing            November 2008


              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2648]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
              August 1999.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC2048]  Freed, N., Klensin, J., and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) Part Four: Registration
              Procedures", BCP 13, RFC 2048, November 1996.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [W3C.REC-xml-20001006]
              Maler, E., Paoli, J., Bray, T., and C. Sperberg-McQueen,
              "Extensible Markup Language (XML) 1.0 (Second Edition)",
              World Wide Web Consortium FirstEdition REC-xml-20001006,
              October 2000,
              <http://www.w3.org/TR/2000/REC-xml-20001006>.

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-16 (work in progress),
              October 2008.

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

   [RFC4480]  Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
              Rosenberg, "RPID: Rich Presence Extensions to the Presence



Rosenberg, et al.          Expires May 7, 2009                 [Page 29]


Internet-Draft            Presence View Sharing            November 2008


              Information Data Format (PIDF)", RFC 4480, July 2006.

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

   [I-D.ietf-simple-intradomain-federation]
              Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra-
              Domain Presence and Instant Messaging (IM) Federation",
              draft-ietf-simple-intradomain-federation-01 (work in
              progress), July 2008.

   [I-D.ietf-sip-subnot-etags]
              Niemi, A., "An Extension to Session Initiation Protocol
              (SIP) Events for Conditional  Event Notification",
              draft-ietf-sip-subnot-etags-03 (work in progress),
              July 2008.

   [I-D.ietf-sipping-presence-scaling-requirements]
              Houri, A., Parameswar, S., Aoki, E., Singh, V., and H.
              Schulzrinne, "Scaling Requirements for Presence in SIP/
              SIMPLE",
              draft-ietf-sipping-presence-scaling-requirements-01 (work
              in progress), July 2008.


Authors' Addresses

   Jonathan Rosenberg
   Cisco
   Iselin, NJ
   US

   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Steve Donovan
   Cisco
   Richardson, TX
   US

   Email: stdonova@cisco.com





Rosenberg, et al.          Expires May 7, 2009                 [Page 30]


Internet-Draft            Presence View Sharing            November 2008


   Kathleen McMurry
   Cisco
   Richardson, TX
   US

   Email: kmcmurry@cisco.com













































Rosenberg, et al.          Expires May 7, 2009                 [Page 31]


Internet-Draft            Presence View Sharing            November 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 May 7, 2009                 [Page 32]


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