< draft-ietf-simple-view-sharing-01.txt   draft-ietf-simple-view-sharing-02.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft S. Donovan Internet-Draft S. Donovan
Intended status: Standards Track K. McMurry Intended status: Standards Track K. McMurry
Expires: January 15, 2009 Cisco Expires: May 7, 2009 Cisco
July 14, 2008 November 3, 2008
Optimizing Federated Presence with View Sharing Optimizing Federated Presence with View Sharing
draft-ietf-simple-view-sharing-01 draft-ietf-simple-view-sharing-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on May 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Presence federation refers to the exchange of presence information Presence federation refers to the exchange of presence information
between systems. One of the primary challenges in presence between systems. One of the primary challenges in presence
federation is scale. With a large number of watchers in one domain federation is scale. With a large number of watchers in one domain
skipping to change at page 2, line 15 skipping to change at page 2, line 15
sharing allows the amount of presence traffic between domains to sharing allows the amount of presence traffic between domains to
achieve the theoretical lower bound on information exchange in any achieve the theoretical lower bound on information exchange in any
presence system. presence system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. RLS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. RLS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. On Receipt of a Resource List Subscription Request . . . . 8 3.1. On Receipt of a Resource List Subscription Request . . . . 8
3.1.1. Authentication and Authorization . . . . . . . . . . . 8 3.1.1. Find a Matching Back-End Subscription . . . . . . . . 8
3.1.2. No Active Back-End Subscription . . . . . . . . . . . 8 3.1.2. Generating a Back-End Subscription . . . . . . . . . 9
3.1.3. Active Back-End Subscription . . . . . . . . . . . . . 9
3.2. Processing NOTIFY Requests . . . . . . . . . . . . . . . . 10 3.2. Processing NOTIFY Requests . . . . . . . . . . . . . . . . 10
3.2.1. Processing ACL-Infos . . . . . . . . . . . . . . . . . 10 3.2.1. Processing ACL-Infos . . . . . . . . . . . . . . . . . 10
3.2.2. Processing Presence Documents . . . . . . . . . . . . 11 3.2.2. Processing State Documents . . . . . . . . . . . . . . 11
3.2.3. Processing Back-End Terminations . . . . . . . . . . . 12 3.2.3. Processing Back-End Terminations . . . . . . . . . . . 11
4. Presence Agent Behavior . . . . . . . . . . . . . . . . . . . 12 4. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Authentication and Authorization . . . . . . . . . . . . . 12 4.1. Authentication and Authorization . . . . . . . . . . . . . 12
4.2. Processing Initial SUBSCRIBE Requests . . . . . . . . . . 12 4.2. Processing Initial SUBSCRIBE Requests . . . . . . . . . . 12
4.3. SUBSCRIBE Refreshes . . . . . . . . . . . . . . . . . . . 13 4.3. SUBSCRIBE Refreshes . . . . . . . . . . . . . . . . . . . 13
4.4. Policy Changes . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Policy Changes . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Presence State Changes . . . . . . . . . . . . . . . . . . 15 4.5. Event State Changes . . . . . . . . . . . . . . . . . . . 15
5. ACL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. ACL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Document Structure and Semantics . . . . . . . . . . . . . 15 5.1. Document Structure and Semantics . . . . . . . . . . . . . 15
5.2. Trust Considerations when Construcing ACLs . . . . . . . . 17 5.2. Trust Considerations when Construcing ACLs . . . . . . . . 17
5.3. Example Documents . . . . . . . . . . . . . . . . . . . . 18 5.3. Example Documents . . . . . . . . . . . . . . . . . . . . 18
5.4. Rule Determination Algorithm . . . . . . . . . . . . . . . 19 5.4. Rule Determination Algorithm . . . . . . . . . . . . . . . 19
5.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 21 6. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 21
7. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 22 7. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.1. Privacy Considerations of the Serving Domain . . . . . . . 24
9.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 25 8.2. Privacy Considerations of the Watched Resource . . . . . . 25
9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26 8.3. Interactions with S/MIME . . . . . . . . . . . . . . . . . 26
9.3. Schema Registration . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.3. Schema Registration . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
Presence refers to the ability, willingness and desire to communicate Presence refers to the ability, willingness and desire to communicate
across differing devices, mediums and services [RFC2778]. Presence across differing devices, mediums and services [RFC2778]. Presence
is described using presence documents [RFC3863] [RFC4479], exchanged is described using presence documents [RFC3863] [RFC4479], exchanged
using a SIP-based event package [RFC3856]. using a SIP-based event package [RFC3856].
Presence federation refers to the interconnection of disparate Presence federation refers to the interconnection of disparate
systems for the purposes of sharing presence information. This systems for the purposes of sharing presence information. This
interconnection involves passing of subscriptions from one system to interconnection involves passing of subscriptions from one system to
another, and then the passing of notifications in the opposite another, and then the passing of notifications in the opposite
direction. 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 [I-D.ietf-simple-interdomain-scaling-analysis] has analyzed the
amount of traffic, in terms of messages and in terms of bytes, which amount of traffic, in terms of messages and in terms of bytes, which
flow between systems in various federated use cases. These numbers flow between systems in various federated use cases. These numbers
demonstrate that presence traffic can be a substantial source of demonstrate that presence traffic can be a substantial source of
overhead. The root cause of this scale challenge is the so-called overhead. The root cause of this scale challenge is the so-called
multiplicative effect of presence data. If there are N users, each multiplicative effect of presence data. If there are N users, each
of which have B buddies on their buddy list, and each buddy changes of which have B buddies on their buddy list, and each buddy changes
state L times per hour, the amount of notification traffic is state L times per hour, the amount of notification traffic is
proportional to N*B*L. For example, in the case of two extremely proportional to N*B*L. For example, in the case of two extremely
skipping to change at page 3, line 50 skipping to change at page 4, line 4
For this reason, there is a clear need to improve the scale of SIMPLE For this reason, there is a clear need to improve the scale of SIMPLE
in federated envrionments. in federated envrionments.
[I-D.ietf-sipping-presence-scaling-requirements] has laid out a set [I-D.ietf-sipping-presence-scaling-requirements] has laid out a set
of requirements for optimizations. The essence of these requirements of requirements for optimizations. The essence of these requirements
are that the extension should improve performance, while being are that the extension should improve performance, while being
backwards compatible and supporting the privacy and policy backwards compatible and supporting the privacy and policy
requirements of users. requirements of users.
This document defines a mechanism called view sharing in support of This document defines a mechanism called view sharing in support of
those requirements. The key idea with view sharing is that when those requirements. The key idea with view sharing is that when
there are many watchers in a domain to a single presentity in another there are many watchers in one system to a single presentity in
domain, each of which is actually going to get the exact same another system, each of which is actually going to get the exact same
presence document, the domain of the watchers extends a single presence document, the watcher's system extends a single subscription
subscription to the domain of the presentity, and the domain of the to the system of the presentity, and the system of the presentity
presentity sends a single copy of the presence document back to the sends a single copy of the presence document back to the system of
domain of the watcher. 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 In the case of a pair of large providers that are peering with each
other, this mechanism can result in a significant savings. Assuming other, this mechanism can result in a significant savings. Assuming
a symmetrical system whereby the average buddies per watcher is B and 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 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 are in one domain or the other, this optimization can reduce the
overall subscription overhead and notification traffic by a factor of overall subscription overhead and notification traffic by a factor of
B/2. In cases where there are a large number of small domains, this 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 mechanism is less useful. Of course, in such cases, the amount of
traffic between any pair of domains is small anyway. traffic between any pair of domains is small anyway.
2. Overview of Operation 2. Overview of Operation
The extensions works in the environment shown in Figure 1. The The extension works in the environment shown in Figure 1. For
environment assumes two domains. There are some number of watchers explanatory purposes, the environment assumes two domains. There are
(W1 - W3) in the domain on the left, which we call the watching some number of subscribers (W1 - W3) in the domain on the left, which
domain. All of those watchers are interested in the presence of a we call the subscribing domain. All of those subscribers are
single presentity P1 in the domain on the right, which we call the interested in the state of a single resource P1 in the domain on the
serving domain. The watchers all make use of a resource list server right, which we call the serving domain. The subscribers all make
(RLS) [RFC4662] which stores their buddy lists and performs the buddy use of a resource list server (RLS) [RFC4662] which stores their
list expansion. Consequently, when each watcher subscribes to their resource lists and performs the list expansion. Consequently, when
buddy list on the RLS, in absence of any optimizations, the RLS will each subscriber subscribes to their resource list on the RLS, in
generate three separate subscriptions to P1, each of which reaches absence of any optimizations, the RLS will generate three separate
the presence server in the serving domain. subscriptions to P1, each of which reaches the notifier in the
serving domain.
. .
+--------------+ . +--------------+ +--------------+ . +--------------+
| | . | | | | . | |
| | SUB . | | | | SUB . | |
| | -------.---> | Presence | | | -------.---> | |
| RLS | NOT . | Server | | RLS | NOT . | Notifier |
| | <------.---- | | | | <------.---- | |
| | . | | | | . | |
| | . | | | | . | |
+--------------+ . +--------------+ +--------------+ . +--------------+
^ ^ ^ . ^ ^ ^ ^ . ^
List | | | . | PUB List | | | . | PUB
SUB | | | . | SUB | | | . |
| | | . | | | | . |
+----+ +----+ +----+ . +----+ +----+ +----+ +----+ . +----+
| | | | | | . | | | | | | | | . | |
| W1 | | W2 | | W3 | . | P1 | | W1 | | W2 | | W3 | . | P1 |
| | | | | | . | | | | | | | | . | |
+----+ +----+ +----+ . +----+ +----+ +----+ +----+ . +----+
. .
. .
. .
Watching . Serving Subscribing . Serving
Domain . Domain Domain . Domain
. .
Figure 1: Deployment Model Figure 1: Deployment Model
Of course, in practice each domain will act as both a watching domain Of course, in practice each domain will act as both a subscribing
and a serving domain, thus implementing both sides of the system. domain and a serving domain, thus implementing both sides of the
system.
The initial SUBSCRIBE generated by the RLS includes a SIP option tag The initial SUBSCRIBE generated by the RLS includes a SIP option tag
"view-share" in the Supported header field, indicating that the RLS "view-share" in the Supported header field, indicating that the RLS
supports the view sharing extension. If the presence server also supports the view sharing extension. If the notifier also supports
supports the extension, it makes use of it and includes an indication the extension, it makes use of it and includes an indication of this
of this fact in the Require header field in the SUBSCRIBE response fact in the Require header field in the SUBSCRIBE response and in
and in NOTIFY requests it generates. NOTIFY requests it generates.
View sharing requires a level of trust between the two domains. View sharing requires a level of trust between the two domains.
Consequently, the connection between them utilizes TLS with mutual Typically, TLS will be deployed between them, and the notifier uses
authentication. The presence server verifies that the certificate it to determine if the subscribing domain is authorized.
presented in the mutual authentication matches the domain of the
watcher.
If this is the first subscription from domain 1 for that particular If this is the first subscription from domain 1 for that particular
presentity, the presence server accepts the subscription (assuming resource, the notifier accepts the subscription (assuming the
the watcher is authorized of course). The notifications sent to the subscriber is authorized of course). The notifications sent to the
RLS include two separate pieces of state. One is the actual presence RLS include two separate pieces of state. One is the actual state
state for the presentity. The other is an Access Control List (ACL) for the resource. The other is an Access Control List (ACL)
document. This document describes the set of other watchers from the document. This document describes the set of other subscribers from
originating domain, if any, who are authorized to see exactly the the originating domain, if any, who are authorized to see exactly the
same presence document - in other words, the set of users that share same document - in other words, the set of users that share the same
the same view. Should one of those watchers seek the presence of view. Should one of those subscribers seek the state of that
that presentity, the RLS from the originating domain does not need to resource for the same event package, the RLS from the originating
generate a back-end subscription; rather, it just uses the presence domain does not need to generate a back-end subscription; rather, it
document it is receiving from the original subscription, and passes just uses the document it is receiving from the original
it to both watchers. The ACL can also list users in the originating subscription, and passes it to both subscribers. The ACL can also
domain that are authorized to subscribe to that presentity, but who list users in the originating domain that are authorized to subscribe
will end up receiving a different view. Should one of those watchers to that resource, but who will end up receiving a different view.
subscribe, the RLS knows that it must perform a back-end subscription Should one of those subscribers subscribe, the RLS knows that it must
to obtain that view. The ACL can also list watchers in the perform a back-end subscription to obtain that view. The ACL can
originating domain that are not authorized at all, in which case the also list subscribers in the originating domain that are not
RLS could immediately reject their subscriptions. Finally, if the authorized at all, in which case the RLS could immediately reject
ACL says nothing about a particular watcher, it means that the their subscriptions. Finally, if the ACL says nothing about a
presence server has elected to say nothing about what view this particular subscriber, it means that the notifier has elected to say
watcher will receive. Consequently, the RLS must perform a back-end nothing about what view this subscriber will receive. Consequently,
subscription should that watcher subscribe to the presentity. the RLS must perform a back-end subscription should that subscriber
subscribe to the resource.
Other subsequent subscriptions to the same presentity from the same Other subsequent subscriptions to the same resource from the same
originating domain are processed in a similar way. However, the originating domain are processed in a similar way. However, the
presence server in the serving domain will keep track of the set of notifier in the serving domain will keep track of the set of
subscriptions to the same presentity from the same RLS which are to subscriptions to the same resource for the same event package from
receive the same view. When a presence notification is to be sent, the same RLS which are to receive the same view. When a presence
instead of sending it on all subscriptions, the notification is sent notification is to be sent, instead of sending it on all such
on just a single subscription. subscriptions, the notification is sent on just a single
subscription.
Should the authorization policies in the serving domain change, an Should the authorization policies in the serving domain change, an
updated ACL is sent, informing the watching domain of the new updated ACL is sent, informing the subscribing domain of the new
policies. This may require the watching domain to extend a back-end policies. This may require the subscribing domain to extend a back-
subscription to obtain a view, or may change the view an existing end subscription to obtain a view, or may change the view an existing
watcher is receiving, and so on. subscriber is receiving, and so on.
The ACL allows the serving domain a great deal of flexibility in the 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 level of trust it imparts to the watching domain. The following are
all possible approaches that the serving domain can utilize: all possible approaches that the serving domain can utilize:
No Trust: When a presence server receives the subscription, it No Trust: When a notifier receives the subscription, it elects not
elects not to use this mechanism at all using the negotiation to use this mechanism at all using the negotiation techniques
techniques defined here. defined here.
Minimal Trust: When a watcher subscribes to a presentity, the ACL Minimal Trust: When a subscriber subscribes to a resource, the ACL
generated for that subscription includes only that watcher, along generated for that subscription includes only that subscriber,
with an identifier for their view. Consequently, for each watcher along with an identifier for their view. Consequently, for each
in domain 1 there will be a backend subscription to domain 2. subscriber in domain 1 there will be a backend subscription to
However, should multiple watchers share the same view, the domain 2. However, should multiple subscribers share the same
presence server in domain 2 sends a single presence document on view, the notifier in domain 2 sends a single document on one of
one of the subscriptions, and the RLS uses this for all of the the subscriptions, and the RLS uses this for all of the other
other watchers with the same view. With this approach, domain 2 subscribers with the same view. With this approach, domain 2
never discloses the list of authorized watchers ahead of time, and never discloses the list of authorized subscribers ahead of time,
it has full knowledge of each watcher that is subscribed. and it has full knowledge of each subscriber that is subscribed.
However, it gets the performance benefits of reducing the amount However, it gets the performance benefits of reducing the amount
of notification traffic. of notification traffic.
Partial Trust: When a watcher subscribes to a presentity, the ACL Partial Trust: When a subscriber subscribes to a resource, the ACL
generated for that subscription includes that watcher and all generated for that subscription includes that subscriber and all
other watchers authorized for that same view. Consequently, there other subscribers authorized for that same view. Consequently,
will only be one backend subscription from the RLS to the presence there will only be one backend subscription from the RLS to the
server for each view. However, the full set of authorized notifier for each view. However, the full set of authorized
watchers is not disclosed ahead of time, only those that will get subscribers is not disclosed ahead of time, only those that will
the same view. With partial trust, the presence server will not get the same view. With partial trust, the notifier will not know
know the full set of watchers currently subscribed. the full set of subscribers currently subscribed.
Full Trust: When a watcher subscribes to a presentity, the ACL Full Trust: When a subscriber subscribes to a resource, the ACL
generated for that subscription includes that watcher and all generated for that subscription includes that subscriber and all
other watchers that are authorized for that view, and all other other subscribers that are authorized for that view, and all other
views, along with a rule that says that all other watchers get views, along with a rule that says that all other subscribers get
rejected. In this case, as with partial trust, there is only one rejected. In this case, as with partial trust, there is only one
backend subscription from the RLS to the presence server for each backend subscription from the RLS to the notifier for each view.
view. The full set of watchers is disclosed ahead of time as The full set of subscribers is disclosed ahead of time as well.
well. The presence server will not know the full set of watchers The notifier will not know the full set of subscribers currently
currently subscribed. subscribed.
Depending on the level of trust, the mechanism trades off inter- Depending on the level of trust, the mechanism trades off inter-
domain messaging traffic for increased processing load in the RLS to domain messaging traffic for increased processing load in the RLS to
handle the ACL documents. handle the ACL documents.
3. RLS Behavior 3. RLS Behavior
This section defines the procedures that are to be followed by the This section defines the procedures that are to be followed by the
RLS. It is important to note that, even though this specification RLS. It is important to note that, even though this specification
defines an extension to the SIP events framework, that extension is defines an extension to the SIP events framework, the extension is
only useful for the back-end subscriptions generated by an RLS. The only useful for the back-end subscriptions generated by an RLS. The
extension defined here is not applicable or useful for individual extension defined here is not applicable or useful for individual
users generating subscriptions. Indeed, if it were utilized by users generating subscriptions. Indeed, if it were utilized by
individual users, it has the potential for violations of user individual users, it has the potential for violations of user
privacy. See Section 8 for a discussion. privacy. See Section 8 for a discussion.
3.1. On Receipt of a Resource List Subscription Request 3.1. On Receipt of a Resource List Subscription Request
When the RLS receives a subscription to a resource list which When the RLS receives a subscription to a resource list which
includes some presentity P in another domain, it follows the rules includes some resource P in another domain or system, it follows the
defined here. rules defined here. The processing depends on whether the RLS
already has a backend subscription to the resource that is in the
3.1.1. Authentication and Authorization active state, and for which an ACL has been received.
First, the RLS MUST check a configured list of peer domains for which
this extension is to be applied. Because of the potential privacy
disclosures involved in unauthorized use of this facility, it can
only be used between pairs of domains which have a pre-arranged
agreement to utilize it. If the domain of the presentity P matches
one of the configured list of peer domains, the RLS is permitted to
utilize this extension. If not, the extension MUST NOT be used.
Next, the RLS MUST send the SUBSCRIBE request over a mutually
authenticated TLS connection. The RLS MUST check that the
subjectAltName in the certificate of its peer contains a domain name
that is a match for the domain of the URI of the presentity. If they
are not a match, view sharing cannot be utilized for this
subscription.
The procedures followed by the RLS after this point depend on whether
the RLS already has a backend subscription to the presentity that is
in the active state, and for which an ACL has been received.
3.1.2. No Active Back-End Subscription
The RLS MUST generate a back-end subscription to obtain the state of
the presentity. 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/
aclinfo+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 watchers, in a short period of
time, both subscribe to their resource lists, both of which include
presentity 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 watchers are
receiving the same view and both ACLs contain both watchers, the RLS
SHOULD terminate one of the back-end subscriptions.
3.1.3. Active Back-End Subscription 3.1.1. Find a Matching Back-End Subscription
In this case, the RLS already has at least one back-end subscription First, the RLS determines if it has a back-end subscription in place
to the target presentity P, and it has received at least one ACL for whose view corresponds to that of the new subscriber. Let P be the
that presentity. It has received a resource list subscription from target resource, E the desired event package, and W the identity of
watcher W which includes presentity P. Based on the procedures of the subscriber.
Section 3.2.1, the RLS will keep, for each presentity, the list of
the most recent ACLs received on each back-end subscription currently
in place. This is called the current ACL list.
For each ACL Ai in the current ACL list, the RLS performs the rule 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 determination algorithm of Section 5.4 to compute the rule ID R for
the watcher W. This represents the view that the watcher is supposed the subscriber W. This represents the view that the subscriber is
to receive. supposed to receive.
Next, the RLS goes through all subscriptions it currently has for Next, the RLS goes through all subscriptions it currently has for
presentity P. For each one, it takes the identity of the watcher for resource P and event package E. For each one, it takes the identity
that actual subscription. The identity for the watcher for that of the subscriber for that actual subscription. The identity for the
actual subscription is equal to the asserted identity included in the subscriber for that actual subscription is equal to the asserted
back-end subscription. For example, if SIP Identity [RFC4474] is identity included in the back-end subscription. For example, if SIP
utilized, this would be the URI present in the From header field of Identity [RFC4474] is utilized, this would be the URI present in the
the back-end SUBSCRIBE. Call the watcher identity for each From header field of the back-end SUBSCRIBE. Call the subscriber
subscription Wj. identity for each subscription Wj.
Next, the RLS computes the rule determination algorithm of Next, the RLS computes the rule determination algorithm of
Section 5.4 to compute the rule ID Rj for the watcher Wj on each 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 subscription j. This represents the rule ID for the view being
delivered on that subscription. delivered on that subscription.
Then, processing depends on the values of R and Rj: Then, processing depends on the values of R and Rj:
o If R is null, it means that the ACL doesn't specify the view for o If R is null, it means that no ACL in the list specifies the view
this watcher. The RLS MUST generate a back-end subscription to for this subscriber. The RLS MUST generate a back-end
presentity P, and MUST use watcher W as the identity in the back- subscription to resource P and event package E, and MUST use
end subscription. subscriber W as the identity in the back-end subscription.
o If R is not null, but the associated rule is blocked, it means o If R is not null, but the associated rule is blocked, it means
that the watcher will be rejected. The RLS SHOULD NOT perform that the subscriber will be rejected. The RLS SHOULD NOT perform
another back-end subscription, and must act as if it had created a another back-end subscription, and must act as if it had created a
back-end subscription which was rejected. back-end subscription which was rejected.
o If R is not null, and there is at least one subscription j for 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 which Rj = R, it means that subscription j is already generating
notifications for the view that watcher W is supposed to receive. notifications for the view that subscriber W is supposed to
In that case, the RLS SHOULD NOT generate a back-end subscription receive. In that case, the RLS SHOULD NOT generate a back-end
for P on behalf of W. Rather, it should treat the existing back subscription for P on behalf of W. Rather, it should treat the
end subscription j as if it were the back-end subscription for W, existing back end subscription j as if it were the back-end
and follow the guidelines of RFC 4662 [RFC4662] based on that. subscription for W, and follow the guidelines of RFC 4662
Subscription j is called the generating subscription for watcher [RFC4662] based on that. Subscription j is called the generating
W, and the actual watcher associated with subscription j, Wj, is subscription for subscriber W, and the actual subscriber
called the generating watcher Wgen for watcher W. 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, 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 watcher W it means that the RLS is not yet receiving the view that
requires. The RLS MUST generate a back-end subscription to subscriber W requires. The RLS MUST generate a back-end
presentity P, and MUST use watcher W as the identity in the back- subscription to resource P, and MUST use subscriber W as the
end subscription. 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.
3.2. Processing NOTIFY Requests 3.2. Processing NOTIFY Requests
If a NOTIFY request arrives with a Require header field that includes If a NOTIFY request arrives with a Require header field that includes
the "view-share" option tag, it MUST be processed according to the the "view-share" option tag, it MUST be processed according to the
rules of this specification. rules of this specification.
3.2.1. Processing ACL-Infos 3.2.1. Processing ACL-Infos
If the contents of the NOTIFY are of type "application/aclinfo+xml", If the contents of the NOTIFY are of type "application/
the subscriber processes the body as described here. viewshare-acl+xml", the subscriber processes the body as described
here.
For each presentity that the RLS has at least one back-end For each resource that the RLS has at least one back-end subscription
subscription for, the RLS MUST remember the most recent aclinfo for, the RLS MUST remember the most recent viewshare-acl received on
received on each back-end subscription. This is called the current each back-end subscription. This is called the current ACL list for
ACL list for the presentity. This set of aclinfo is used in the the resource. This set of viewshare-acl is used in the processing of
processing of subscription requests, as described in Section 3.1.3. subscription requests, as described in Section 3.1.1.
The serving domain can change policies at any time. When it does, it 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 sends an updated ACL on one or more subscriptions. The RLS MUST
store this ACL. Furthermore, the ACL might impact the views being store this ACL, replacing any previous ACL's received on this
received by watchers, and may impact the state of the back-end subscription. Furthermore, the ACL might impact the views being
received by subscribers, and may impact the state of the back-end
subscriptions. subscriptions.
The RLS computes the set of watchers Wi which have a resource list The RLS computes the set of subscribers Wi which have a resource list
subscription that includes the presentity P for whom an updated ACL subscription that includes the resource P for whom an updated ACL has
has just been received. For each Wi, it performs the view just been received. For each Wi, it performs the view determination
determination algorithm (see Section 5.4 on the current ACL set. Let algorithm (see Section 5.4 on the current ACL set. Let Ri be the
Ri be the view associated with watcher Wi. If Ri has not changed view associated with subscriber Wi. If Ri has not changed from prior
from prior to the receipt of the new ACL, no action is taken. to the receipt of the new ACL, no action is taken. However, if it
However, if it has changed, the RLS takes the set of current back-end has changed, the RLS takes the set of current back-end subscriptions,
subscriptions, and for each subscription j, computes the view and for each subscription j, computes the view determination
determination algorithm for its associated watcher Wj, to produce Rj. algorithm for its associated subscriber Wj, to produce Rj. The
The action to take depends on what has changed: action to take depends on what has changed:
o If Ri is now null, it means that the serving domain has changed o If Ri is now null, it means that the serving domain has changed
the views associated with watcher Wi, and this new view is not the views associated with subscriber Wi, and this new view is not
known to the RLS. The RLS MUST generate a new back-end known to the RLS. The RLS MUST generate a new back-end
subscription on behalf of watcher Wi for presentity P to obtain subscription on behalf of subscriber Wi for resource P to obtain
this view. this view.
o If Ri is now a blocked rule, it means that the serving domain has o If Ri is now a blocked rule, it means that the serving domain has
now blocked Wi from obtaining the presence of the presentity. The 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 RLS must act as if it had a back-end subscription on behalf of
watcher Wi which was terminated. subscriber Wi which was terminated.
o If Ri is not null and not blocked, and if there is an Rj which 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 matches the new Ri, it means that the serving domain has changed
the views associated with watcher Wi, and changed them to another the views associated with subscriber Wi, and changed them to
view already being received by the RLS. The RLS MUST treat this another view already being received by the RLS. The RLS MUST
back-end subscription j as if it were the back-end subscription to treat this back-end subscription j as if it were the back-end
presentity P for watcher Wi. If the most recent presence document subscription to resource P for subscriber Wi. If the most recent
received on this back-end subscription is not a semantic match for presence document received on this back-end subscription is not a
the presence document most recently delivered to Wi for presentity semantic match for the presence document most recently delivered
P, the RLS MUST send this most recent presence document to watcher to Wi for resource P, the RLS MUST send this most recent presence
Wi. document to subscriber Wi.
o If Ri is not null and not blocked, but there is no Rj which 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 matches the new Ri, it means that the serving domain has changed
the views associated with watcher Wi, and this new view is not one the views associated with subscriber Wi, and this new view is not
currently being delivered to the RLS. The RLS MUST generate a new one currently being delivered to the RLS. The RLS MUST generate a
back-end subscription on behalf of watcher Wi for presentity P to new back-end subscription on behalf of subscriber Wi for resource
obtain this view. P to obtain this view.
Furthermore, if there are now two back-end subscriptions j1 and j2 Furthermore, if there are now two back-end subscriptions j1 and j2
for which Aj1 = Aj2, the RLS SHOULD terminate one of those two which have identical ACLs, RLS SHOULD terminate one of those two
subscriptions. Two ACL documents are considered equal if they subscriptions. Two ACL documents are considered equal if they
enumerate the same set of rules with the same members for each rule. enumerate the same set of rules with the same members for each rule.
3.2.2. Processing Presence Documents 3.2.2. Processing State Documents
If the contents of the NOTIFY is a presence document, the RLS follows If the contents of the NOTIFY is a state document for the given event
the procedures defined here. package, the RLS follows the procedures defined here.
Let Wj be the watcher on the subscription j on which the presence Let Wj be the subscriber on the subscription j on which the document
document was just received. Let Rj be the results of running the was just received. Let Rj be the results of running the rule
rule determination algorithm on Wj using the current ACL set. Next, determination algorithm on Wj using the current ACL set. Next, the
the RLS takes the set of watchers Wi which have presentity P on their RLS takes the set of subscribers Wi which have resource P on their
buddy lists. The RLS then runs the rule determination algorithm on resource lists. The RLS then runs the rule determination algorithm
each Wi using the current ACL set, producting Ri for each watcher Wi. on each Wi using the current ACL set, producting Ri for each
For each Ri that is equal to Rj, the RLS MUST utilize the presence subscriber Wi. For each Ri that is equal to Rj, the RLS MUST utilize
document just received as if the back-end subscription j was in fact the document just received as if the back-end subscription j was in
for watcher Wi. This will typically cause that presence document to fact for subscriber Wi. This will typically cause that document to
be sent in a NOTIFY request to each such watcher, though each watcher be sent in a NOTIFY request to each such subscriber, though each
may have some kind of filtering policy which causes the RLS to modify subscriber may have some kind of filtering policy which causes the
the document prior to delivery. RLS to modify the document prior to delivery.
3.2.3. Processing Back-End Terminations 3.2.3. Processing Back-End Terminations
If the NOTIFY request from the serving domain terminates the back-end If the NOTIFY request from the serving domain terminates the back-end
subscription, it may be because the watcher Wj associated with that subscription, it may be because the subscriber Wj associated with
subscription is no longer permitted to view the presence of the that subscription is no longer permitted to view the state of the
presentity. resource.
The ACL associated with the subscription MUST be removed from the The ACL associated with the subscription MUST be removed from the
current ACL set. The procedures of Section 3.2.1 MUST be performed current ACL set. The procedures of Section 3.2.1 MUST be performed
to adjust back-end subscriptions, if needed. to adjust back-end subscriptions, if needed.
4. Presence Agent Behavior 4. Notifier Behavior
When a presence agent receives a SUBSCRIBE request containing a When a notifier receives a SUBSCRIBE request containing a Supported
Supported header with the value "view-share", and it wishes to header with the value "view-share", and it wishes to utilize view
utilize view sharing for this subscription, it follows the procedures sharing for this subscription, it follows the procedures defined
defined here. here.
4.1. Authentication and Authorization 4.1. Authentication and Authorization
First, the presence agent MUST have received the SUBSCRIBE request The principle concern of the notifier is to determine the domain of
over a mutually authenticated TLS connection. If it had not, view the RLS, and assess whether the subscribing entity is an RLS
sharing cannot be utilized for this subscription. The presence agent authorized to operate on behalf of that domain. In order to utilize
MUST check that the subjectAltName in the certificate of its peer view sharing, a notifier MUST determine both. This information is
contains a domain name that is a match for the domain of the URI of necessary in order to compute the ACL to be sent to that domain, and
the watcher. If they are not a match, view sharing cannot be if done incorrectly, may reveal sensitive information to the watching
utilized for this subscription. domain.
Assuming they are a match, the presence agent MUST check a configured To determine the domain of the subscribing RLS, TLS with mutual
list of peer domains for which this extension is to be applied. authentication SHOULD be used. In such a case, the notifier can
Because of the potential privacy disclosures involved in unauthorized determine the domain of the RLS from the subjectAltName in the
use of this facility, it can only be used between pairs of domains certificate presented from its peer.
which have a pre-arranged agreement to utilize it. If the domain of
the watcher W matches one of the configured list of peer domains, the This specification does not define any automated mechanism for a
presence agent is permitted to utilize this extension. If not, the notifier to determine whether the subscribing entity is, in fact, an
extension MUST NOT be used. 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 4.2. Processing Initial SUBSCRIBE Requests
First, the subscription is processed as it normally would be, First, the subscription is processed as it normally would be,
including authorization and policy around the presence document to be including authorization and policy around the document to be
delivered to the watcher. Furthermore, if the presence agent wishes delivered to the subscriber. Furthermore, if the notifier wishes to
to utilize view sharing for this subscription, it MUST include a utilize view sharing for this subscription, it MUST include a Require
Require header field in the first NOTIFY request (and indeed any header field in the first NOTIFY request (and indeed any subsequent
subsequent ones) it sends confirming this subscription, and that ones) it sends confirming this subscription, and that NOTIFY MUST
NOTIFY MUST contain the "view-share" option tag. contain the "view-share" option tag. That option tag MUST NOT be
present in the Require header field of notifications unless the
corresponding dialog-forming SUBSCRIBE contained it in a Supported
header field.
Furthermore, the initial state sent by the presence agent MUST Furthermore, the initial state sent by the notifier MUST include an
include an ACL document. It is formatted according to the rules and ACL document. It is formatted according to the rules and
considerations in Section 5. considerations in Section 5.
The initial state sent by the presence agent might include an actual The initial state sent by the notifier might include an actual state
presence document. In particular, a presence document MUST be sent document. In particular, a state document MUST be sent if one of the
if one of the following is true: following is true:
o There is only one subscription from the watching domain to this o There is only one subscription from the watching domain to this
presentity that has the view associated with the watcher. resource that has the view associated with the subscriber.
o There is more than one subscription from the watching domain to o There is more than one subscription from the watching domain to
this presentity with the same view, but the +sip.instance this resource with the same view, but the +sip.instance parameter
parameter for the remote target (as conveyed in the Contact header for the remote target (as conveyed in the Contact header field of
field of the SUBSCRIBE) differs. In other words, these the SUBSCRIBE) differs. In other words, these subscriptions are
subscriptions are from the same domain, but from different RLS in from the same domain, but from different RLS in the watching
the watching domain. Each RLS in the watching domain needs to get domain. Each RLS in the watching domain needs to get their own
their own copy of the view for a particular presentity. copy of the view for a particular resource.
If one of these conditions is not true, the presence agent SHOULD NOT If one of these conditions is not true, the notifier SHOULD NOT send
send an initial presence document on this subscription. an initial state document on this subscription.
If an ACL and a presence document are to be delivered, they MUST be If an ACL and a state document are to be delivered, they MUST be
delivered in a separate NOTIFY request (unless the subscriber delivered separate NOTIFY requests unless the subscriber indicated
indicated support for multipart, in which case the content MAY be support for multipart, in which case the content MAY be included in a
included in a single NOTIFY with mulitpart content). single NOTIFY with mulitpart content.
4.3. SUBSCRIBE Refreshes 4.3. SUBSCRIBE Refreshes
When the presence agent receives a SUBSCRIBE refresh, it MUST send When the notifier receives a SUBSCRIBE refresh, it MUST send the most
the most recent ACL document, and if presence documents are being recent ACL document, and if state documents are being sent for this
sent for this subscription, the most recent presence document. subscription, the most recent state document.
4.4. Policy Changes 4.4. Policy Changes
There are several different types of policy changes that can occur: There are several different types of policy changes that can occur:
o If the definitions for a particular rule change, the presence o If the definitions for a particular rule change, the notifier MUST
agent MUST assign a new rule ID for that rule. For each assign a new rule ID for that rule. For each subscription to a
subscription to a presentity which contained that rule, the resource which contained that rule, the notifier MUST send an
presence agent MUST send an updated ACL which includes a rule with updated ACL which includes a rule with this new rule ID.
this new rule ID.
o If some watcher W was previously associated with rule X and is now o If some subscriber W was previously associated with rule X and is
associated with rule Y, the presence agent checks if it has any now associated with rule Y, the notifier checks if it has any
subscriptions from watcher W. If it does, it MUST send an updated subscriptions from subscriber W. If it does, it MUST send an
ACL on that subscription. Based on the rules in Section 5, this updated ACL on that subscription. Based on the rules in
ACL will contain rule Y and will at least include W amongst the Section 5, this ACL will contain rule Y and will at least include
list of members. Furthermore, if there were subscriptions from W amongst the list of members. Furthermore, if there were
other watchers, but the presence agent had previously sent an ACL subscriptions from other subscribers, but the notifier had
on the subscription which was a match for W, it MUST send an previously sent an ACL on the subscription which was a match for
updated ACL on that subscription. This updated ACL MAY omit a W, it MUST send an updated ACL on that subscription. This updated
statement about rule Y or MAY include it. However, the updated ACL MAY omit a statement about rule Y or MAY include it. However,
ACL MUST NOT claim that watcher W will receive rule X. the updated ACL MUST NOT claim that subscriber W will receive rule
X.
o If some watcher W was previously associated with rule X and is now o If some subscriber W was previously associated with rule X and is
blocked, the presence agent checks if it has any subscriptions now blocked, the notifier checks if it has any subscriptions from
from watcher W. If it does, it MUST terminate the back-end subscriber W. If it does, it MUST terminate the back-end
subscription. If it doesn't, but it has a subscription from some subscription. If it doesn't, but it has a subscription from some
other watcher which had included a rule that was a match for W, other subscriber which had included a rule that was a match for W,
the presence agent MUST send an updated ACL on that subscription. the notifier MUST send an updated ACL on that subscription. This
This updated ACL MAY omit any statement about watcher W, or MAY updated ACL MAY omit any statement about subscriber W, or MAY
include them as part of a blocked rule in that ACL. include them as part of a blocked rule in that ACL.
o If some watcher W was previously blocked and is now permitted and o If some subscriber W was previously blocked and is now permitted
associated with some rule X, the presence agent checks if it had and associated with some rule X, the notifier checks if it had any
any subscriptions from some other watcher which included a blocked subscriptions from some other subscriber which included a blocked
rule that matched watcher W. If it had, it MUST send an updated rule that matched subscriber W. If it had, it MUST send an updated
ACL on that subscription. That updated ACL MAY omit any statement ACL on that subscription. That updated ACL MAY omit any statement
about watcher W, or MAY indicate that watcher W is now associated about subscriber W, or MAY indicate that subscriber W is now
with rule X. associated with rule X.
Of course, a policy change will also potentially alter the presence Of course, a policy change will also potentially alter the state
documents that are associated with a view. If so, the presence agent documents that are associated with a view. If so, the notifier MUST
MUST send an updated document on a subscription if one of the send an updated document on a subscription if one of the following is
following is true: true:
o There is only one subscription from the watching domain to this o There is only one subscription from the watching domain to this
presentity that has the view associated with the watcher. resource that has the view associated with the subscriber.
o There is more than one subscription from the watching domain to o There is more than one subscription from the watching domain to
this presentity with the same view, but the User-Agent header this resource with the same view, but the +sip.instance Contact
field in the request differs between them. header field in the request differs between them.
If neither is true, the presence agent MUST select one subscription If neither is true, the notifier MUST select one subscription amongst
amongst the several which share the same presentity, view, and User- the several which share the same resource, view, and Contact
Agent header field, and sent an updated notification on that +sip.instance header field parameter, and sent an updated
subscription. The choice of subscriptions is arbitrary and MAY notification on that subscription. The choice of subscriptions is
change for each notification. arbitrary and MAY change for each notification.
4.5. Presence State Changes 4.5. Event State Changes
If the state of some presentity changes, the presence agent may need If the state of some resource changes, the notifier may need to send
to send an updated notification on a subscription. The presence an updated notification on a subscription. The notifier MUST send an
agent MUST send an update on a subscription if one of the following update on a subscription if one of the following is true:
is true:
o There is only one subscription from the watching domain to this o There is only one subscription from the watching domain to this
presentity that has the view associated with the watcher. resource that has the view associated with the subscriber.
o There is more than one subscription from the watching domain to o There is more than one subscription from the watching domain to
this presentity with the same view, but the User-Agent header this resource with the same view, but the +sip.instance Contact
field in the request differs between them. header field in the request differs between them.
If neither is true, the presence agent MUST select one subscription If neither is true, the notifier MUST select one subscription amongst
amongst the several which share the same presentity, view, and User- the several which share the same resource, view, and Contact
Agent header field, and sent an updated notification on that +sip.instance header field parameter, and sent an updated
subscription. The choice of subscriptions is arbitrary and MAY notification on that subscription. The choice of subscriptions is
change for each notification. arbitrary and MAY change for each notification.
5. ACL Format 5. ACL Format
An ACL document is an XML [W3C.REC-xml-20001006] document that MUST An ACL document is an XML [W3C.REC-xml-20001006] document that MUST
be well-formed and MUST be valid according to schemas, including be well-formed and MUST be valid according to schemas, including
extension schemas, available to the validater and applicable to the extension schemas, available to the validater and applicable to the
XML document. ACL documents MUST be based on XML 1.0 and MUST be 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 encoded using UTF-8. This specification makes use of XML namespaces
for identifying ACL documents and document fragments. The namespace for identifying ACL documents and document fragments. The namespace
URI for elements defined by this specification is a URN [RFC2141], URI for elements defined by this specification is a URN [RFC2141],
using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648] using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648]
and extended by RFC 3688 [RFC3688]. This URN is: and extended by RFC 3688 [RFC3688]. This URN is:
urn:ietf:params:xml:ns:aclinfo urn:ietf:params:xml:ns:viewshare-acl
5.1. Document Structure and Semantics 5.1. Document Structure and Semantics
An ACL document informs a watching domain of the set of views that An ACL document informs a watching domain of the set of views that
can be received by that domain, and associates specific watchers with can be received by that domain, and associates specific subscribers
specific views. It is very important to understand that the ACL with specific views. It is very important to understand that the ACL
document does not convey the actual processing that will be applied document does not convey the actual processing that will be applied
by the serving domain. It does not indicate, for example, whether by the serving domain. It does not indicate, for example, whether
geolocation is present in a presence document, or which rich presence geolocation is present in a presence document, or which rich presence
[RFC4480] data elements will be conveyed. It merely provides [RFC4480] data elements will be conveyed. It merely provides
grouping - indicating which watchers from the watching domain will grouping - indicating which subscribers from the subscribing domain
receive the same view. will receive the same view.
Each ACL document starts with the enclosing root element <acl-list>. Each ACL document starts with the enclosing root element <acl-list>.
This contains the list of rules defined by the ACL. Each rule is This contains the list of rules defined by the ACL. Each rule is
represented by the <rule> element. Each rule represents a specific represented by the <rule> element. Each rule represents a specific
view, which is generated by the presence server based on its view, which is generated by the notifier based on its authorization,
authorization, composition and filtering policies. Each rule is composition and filtering policies. Each rule is associated with a
associated with a rule ID, which is a mandatory attribute of the rule ID, which is a mandatory attribute of the <rule> element. This
<rule> element. This ID is scoped within a single presentity. That ID is scoped within a single resource. That is, the IDs for two
is, the IDs for two rules for different presentities are unrelated. rules for different presentities are unrelated.
The <rule> element also contains an optional "blocked" boolean The <rule> element also contains an optional "blocked" boolean
attribute. If "true", it means that the rule specifies that the attribute. If "true", it means that the rule specifies that the
associated set of watchers will be rejected, should they subscribe. associated set of subscribers will be rejected, should they
This can be used by the watching domain to avoid performing back-end subscribe. This can be used by the watching domain to avoid
subscriptions to users which will only be blocked anyway. performing back-end subscriptions to users which will only be blocked
anyway.
Each <rule> contains the set of users that will receive the Each <rule> contains the set of users that will receive the
corresponding view. This can be described by an enumerated set or by 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 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 sequence of <member> elements, each of which contains a SIP URI for
the watcher that will receive that view. the subscriber that will receive that view.
The default view is specified by including a single child element for The default view is specified by including a single child element for
<rule> - <other>. The default view applies to all watchers except <rule> - <other>. The default view applies to all subscribers except
those enumerated by other rules. For this reason, an ACL document those enumerated by other rules. For this reason, an ACL document
which contains a default view MUST include the rule IDs and which contains a default view MUST include the rule IDs and
associated members for all other views that are delivered to associated members for all other views that are delivered to
watchers. For example, consider a presentity that has three views. subscribers. For example, consider a resource that has three views.
View 1 is delivered to watchers A and B. View 2 is delivered to View 1 is delivered to subscribers A and B. View 2 is delivered to
watcher C. View 3 is delivered to everyone else. An ACL document 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 that includes the default view must also include views 1 and 2 with
watchers A, B, and C. subscribers A, B, and C.
In contrast, an ACL document that does not include a default does not 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 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 members for a particular view. Using the example above, it is valid
to include an ACL document which includes only view 1 with watcher 1. to include an ACL document which includes only view 1 with subscriber
1.
If two URI are present within <member> elements within the same If two URI are present within <member> elements within the same
<rule>, it represents a contract by the presence server that both <rule>, it represents an indication by the notifier that both users
users MUST get the same view. Formally, if the presence server were MUST get the same view. Formally, if the notifier were to receive a
to receive a subscription from each watcher, both subscriptions would subscription from each subscriber, both subscriptions would be
be accepted or both would be rejected, and if accepted, each accepted or both would be rejected, and if accepted, each
subscription would receive semantically identical presence documents subscription would receive semantically identical presence documents
at approximately the same time. at approximately the same time.
Even if two users will receive the same view, a presence server MAY Even if two users will receive the same view, a notifier MAY assign
assign each to a different view ID. There is no requirement that two each to a different view ID. There is no requirement that two unique
unique views actually contain different presence data. The only views actually contain different presence data. The only requirement
requirement is that, if two users are listed within the same rule, is that, if two users are listed within the same rule, that they do
that they do in fact receive the same view. in fact receive the same view.
An ACL document delivered in a subscription from watcher W MUST An ACL document delivered in a subscription from subscriber W MUST
include the view associated with watcher W and MUST include watcher W include the view associated with subscriber W and MUST include
explicitly in a <member> element or implicitly by presence of an subscriber W explicitly in a <member> element or implicitly by
<other> element. presence of an <other> element.
5.2. Trust Considerations when Construcing ACLs 5.2. Trust Considerations when Construcing ACLs
The semantics above give very little guidance about what a presence The semantics above give very little guidance about what a notifier
server should include in an ACL. The amount of information to convey should include in an ACL. The amount of information to convey
depends on the level of trust between the watching and serving depends on the level of trust between the subscribing and serving
domains. domains.
Optimal performance is achieved when the ACL document for a Firstly, in all cases, any subscriber listed in a rule MUST be one
presentity includes all views that the server might ever deliver, and that the subscribing RLS is authorized to perform subscriptions for.
includes all members for each view, including any defaults and Typically, this is all of the subscribers in the domain of the RLS.
blocked rules. However, this informs the watching domain of the set For example, if a view-sharing subscription is received from
of allowed and blocked watchers, and associated groupings amongst example.com, only subscribers whose domain is example.com should be
watchers. 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 Slightly worse performance is achieved when the ACL document for a
presentity sent in a subscription from watcher W includes only a resource sent in a subscription from subscriber W includes only a
single view - the one for watcher W - along with the full set of single view - the one for subscriber W - along with the full set of
watchers which will also receive that view, assuming it is not the subscribers from that domain which will also receive that view,
default view. If the view is the default view, the document can assuming it is not the default view. If the view is the default
include just watcher W. This approach will cause back-end view, the document can include just subscriber W. This approach will
subscriptions from every watcher that will receive the default, but cause back-end subscriptions from every subscriber that will receive
it discloses less information to the watching domain. In particular, the default, but it discloses less information to the watching
the full set and number of views is never known by the watching domain. In particular, the full set and number of views is never
domain. The fact that a view is default is never known by the known by the watching domain. The fact that a view is default is
watching domain. The full set of users that are permitted to view never known by the watching domain. The full set of users that are
the presence of the presentity is never disclosed to the watching permitted to view the state of the resource is never disclosed to the
domain. The performance of this approach is still reasonably good watching domain. The performance of this approach is still
when the default rule is blocked. However it is much less effective reasonably good when the default rule is blocked. However it is much
when the default is not blocked, and many watchers receive the less effective when the default is not blocked, and many subscribers
default. receive the default.
Another choice for construction of ACL documents is to include, in a Another choice for construction of ACL documents is to include, in a
subscription from watcher W, a single rule containing the rule ID for subscription from subscriber W, a single rule containing the rule ID
the view that watcher W will receive, along with a single member - W. for the view that subscriber W will receive, along with a single
This approach will still result in a back-end subscription from each member - W. This approach will still result in a back-end
watcher. However, a single notification is sent for each view, subscription from each subscriber. However, a single notification is
rather than one per watcher. The benefit of this construction is sent for each view, rather than one per subscriber. The benefit of
that it provides the watching domain no additional information about this construction is that it provides the watching domain no
the authorization policies of the presentity than if this extension additional information about the authorization policies of the
were not in use at all. resource than if this extension were not in use at all.
5.3. Example Documents 5.3. Example Documents
The example document in Figure 2 shows the case when there is maximum The example document in Figure 2 shows the case when there is maximum
trust between domains. The full set of watchers, include a blocked trust between domains. The full set of subscribers, include a
default, is included. blocked default, is included.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) --> <!-- 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"> <acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="6228"> <rule id="6228">
<member>sip:user1@example.com</member> <member>sip:user1@example.com</member>
<member>sip:user2@example.com</member> <member>sip:user2@example.com</member>
<member>sip:user3@example.com</member> <member>sip:user3@example.com</member>
<member>sip:user4@example.com</member> <member>sip:user4@example.com</member>
<member>sip:user5@example.com</member> <member>sip:user5@example.com</member>
skipping to change at page 18, line 39 skipping to change at page 18, line 50
<member>sip:user11@example.com</member> <member>sip:user11@example.com</member>
</rule> </rule>
<rule blocked="true" id="9433"> <rule blocked="true" id="9433">
<other /> <other />
</rule> </rule>
</acl-list> </acl-list>
Figure 2: Example with Maximum Trust Figure 2: Example with Maximum Trust
The example in Figure 3 shows a moderate level of trust. This ACL The example in Figure 3 shows a moderate level of trust. This ACL
only shows the view associated with the watcher user1. only shows the view associated with the subscriber user1.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) --> <!-- 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"> <acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="6228"> <rule id="6228">
<member>sip:user1@example.com</member> <member>sip:user1@example.com</member>
<member>sip:user2@example.com</member> <member>sip:user2@example.com</member>
<member>sip:user3@example.com</member> <member>sip:user3@example.com</member>
<member>sip:user4@example.com</member> <member>sip:user4@example.com</member>
<member>sip:user5@example.com</member> <member>sip:user5@example.com</member>
skipping to change at page 19, line 36 skipping to change at page 19, line 36
<member>sip:user1@example.com</member> <member>sip:user1@example.com</member>
</rule> </rule>
</acl-list> </acl-list>
Figure 4: Example with Minimal Trust Figure 4: Example with Minimal Trust
5.4. Rule Determination Algorithm 5.4. Rule Determination Algorithm
Several steps in the processing of the ACL require that the RLS in Several steps in the processing of the ACL require that the RLS in
the watching domain execute the rule determination algorithm for the watching domain execute the rule determination algorithm for
watcher W on an ACL set. This algorithm is a simple algorithm which subscriber W on an ACL set. This algorithm is a simple algorithm
takes, as input, a watcher W with a given SIP URI, and a set of ACL which takes, as input, a subscriber W with a given SIP URI, and a set
documents Ai, and returns as output, a rule ID R, which is the rule of ACL documents Ai, and returns as output, a rule ID R, which is the
ID for the view that, according to the set of ACLs, watcher W should rule ID for the view that, according to the set of ACLs, subscriber W
receive. should receive.
The algorithm proceeds as follows. First, each Ai is matched to W. The algorithm proceeds as follows. First, each Ai is matched to W.
ACL Ai is a match for watcher W if: ACL Ai is a match for subscriber W if:
o ACL Ai contains a <member> tag whose URI is a match, based on URI o ACL Ai contains a <member> tag whose URI is a match, based on URI
equality, for W, or equality, for W, or
o none of the <member> tags in Ai contain a URI that is a match, 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 based on URI equality, for W, but there is an <other> element in
Ai Ai
If no ACL Ai matched, the algorithm returns a null result. 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 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> the enclosing <rule> element that contained the <member> or <other>
element that caused the match. For ACL Ai, this is rule Ri. For element that caused the match. For ACL Ai, this is rule Ri. For
example, consider the following ACL: example, consider the following ACL:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<acl-list "xmlns=urn:ietf:params:xml:ns:aclinfo"> <acl-list "xmlns=urn:ietf:params:xml:ns:viewshare-acl">
<rule id="1"> <rule id="1">
<member>sip:user1@example.com</member> <member>sip:user1@example.com</member>
<member>sip:user2@example.com</member> <member>sip:user2@example.com</member>
</rule> </rule>
<rule id="2"> <rule id="2">
<member>sip:user3@example.com</member> <member>sip:user3@example.com</member>
</rule> </rule>
<rule id="3"> <rule id="3">
<other/> <other/>
</rule> </rule>
</acl-list> </acl-list>
If this document is A1, and the watcher is sip:user3@example.com, the If this document is A1, and the subscriber is sip:user3@example.com,
associated rule R1 is 2. If the watcher is sip:user1@example.com or the associated rule R1 is 2. If the subscriber is
sip:user2@example.com, the rule R1 is 1. If the watcher is anyone sip:user1@example.com or sip:user2@example.com, the rule R1 is 1. If
else from example.com, such as sip:user4@example.com, the rule R1 is the subscriber is anyone else from example.com, such as
3. sip:user4@example.com, the rule R1 is 3.
If all Ri are equal, denote R = Ri. Thus, R is the rule ID If all Ri are equal, denote R = Ri. Thus, R is the rule ID
associated with this watcher. Normally, all Ri will be equal. associated with this subscriber. Normally, all Ri will be equal.
However, during transient periods of changes in authorization state, However, during transient periods of changes in authorization state,
it is possible that inconsistent ACL documents exist. In that case, 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 R is assigned the value Ri from the ACL Ai which is the most recently
received amonst all ACL. received amonst all ACLs.
5.5. XML Schema 5.5. XML Schema
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) --> <!-- 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:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="acl-list"> <xs:element name="acl-list">
<xs:complexType> <xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded"> <xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="rule"> <xs:element name="rule">
skipping to change at page 21, line 33 skipping to change at page 21, line 33
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
6. Performance Analysis 6. Performance Analysis
This section considers the performance improvement of the mechanism This section considers the performance improvement of the mechanism
when it is maximally exercised. In that case, the full ACL, when it is maximally exercised. The performance is examined in the
including blocked senders, is returned in the first subscription to a context of an inter-domain presence federation. In this example, the
presentity. This analysis assumes there is a single, monolithic full ACL, including blocked senders, is returned in the first
presence server serving each domain. 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 The optimizations improve ramp-up, steady state, and termination
message loads. In particular, each of those loads, without the message loads. In particular, each of those loads, without the
optimization described here, is proportional to C04, the total number optimization described here, is proportional to C04, the total number
of federated presentities per watcher. If we assume symmetry, such of federated presentities per watcher. If we assume symmetry, such
that the number of federated presentities per watcher is equal to the that the number of federated presentities per watcher is equal to the
number of watchers per federated presentity, then each of the load number of watchers per federated presentity, then each of the load
figures is reduced by C04. That is, the system behaves identically figures is reduced by C04. That is, the system behaves identically
to the case where there is a single watcher per federated presentity, to the case where there is a single subscriber per federated
and assuming symmetric, the same as if there is a single federated presentity, and assuming symmetric, the same as if there is a single
presentity per watcher - e.g., C04 = 1. federated presentity per subscriber - e.g., C04 = 1.
Consider then the very large network peering model in Consider then the very large network peering model in
[I-D.ietf-simple-interdomain-scaling-analysis]. In this model, the [I-D.ietf-simple-interdomain-scaling-analysis]. In this model, the
assumption is two large peering domains with 20 million users each, assumption is two large peering domains with 20 million users each,
with a value of 10 for C04. With this optimization, the number of with a value of 10 for C04. With this optimization, the number of
steady state notifications due to presence state changes drops from 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 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 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 second. Still a big number, of course, but it can't actually get
much smaller. much smaller.
Indeed, it can be readily shown that, assuming the federated domains Indeed, it can be readily shown that, assuming the federated domains
do not actually share raw presence inputs and the actual policies do not actually share raw presence inputs and the actual policies
that govern operation of their servers, no protocol can do better that govern operation of their servers, no protocol can do better
(constants, such as mesage size and the need for protocol responses (constants, such as mesage size and the need for protocol responses
and acknowledgements aside). Consider a domain with N presentities. and acknowledgements aside). Consider a domain with N presentities.
Each presentity changes state P times per hour. Every time the state Each resource changes state P times per hour. Every time the state
changes, the domain applies its authorization and composition changes, the domain applies its authorization and composition
policies. The resulting presence document cannot be known to the policies. The resulting presence document cannot be known to the
watching domain. Thus, there must be at least one message from 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 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 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 better than N*P, and this is exactly the factor governing the rate of
messages when this optimization is applied. messages when this optimization is applied.
7. Requirements Analysis 7. Requirements Analysis
skipping to change at page 23, line 8 skipping to change at page 23, line 8
new privacy considerations, described below in Section 8. new privacy considerations, described below in Section 8.
REQ-003: Systems that are not using the new additions to the REQ-003: Systems that are not using the new additions to the
protocol should operate at the same level as they do today. This protocol should operate at the same level as they do today. This
requirement is met by usage of the Supported and Require requirement is met by usage of the Supported and Require
mechanisms in SIP. mechanisms in SIP.
REQ-004: The solution does not limit the ability for presentities to REQ-004: The solution does not limit the ability for presentities to
present different views of presence to different watchers. This present different views of presence to different watchers. This
requirement is met by usage of the ACL document, which allows the requirement is met by usage of the ACL document, which allows the
serving domain to associate a watcher with any view it likes, and serving domain to associate a subscriber with any view it likes,
to change it over time. and to change it over time.
REQ-005: The solution does not restrict the ability of a presentity REQ-005: The solution does not restrict the ability of a presentity
to obtain its list of watchers. The mechanism does allow a to obtain its list of watchers. The mechanism does allow a
presence server to know the list of watchers, at the expense of presence server to know the list of subscribers, at the expense of
non-optimal performance. In particular, it will receive a non-optimal performance. In particular, it will receive a
subscription from each watcher. However, it only generates one subscription from each subscriber. However, it only generates one
notification per view on presence changes. The fully optimized notification per view on presence changes. The fully optimized
solution will result in a loss of knowledge of the set of solution will result in a loss of knowledge of the set of
watchers. However, it is a policy decision at the presence agent watchers. However, it is a policy decision at the presence agent
about whether it would like to make this tradeoff. about whether it would like to make this tradeoff.
REQ-006: The solution MUST NOT create any new or make worse any REQ-006: The solution MUST NOT create any new or make worse any
existing privacy holes. This requirement is met, but only when existing privacy holes. This requirement is met, but only when
carefully provisioned. See Section 8. carefully provisioned. See Section 8.
REQ-007: It is highly desirable for any presence system (intra or REQ-007: It is highly desirable for any presence system (intra or
skipping to change at page 24, line 25 skipping to change at page 24, line 25
REQ-013: The solution SHOULD allow for arbitrary federation REQ-013: The solution SHOULD allow for arbitrary federation
topologies including direct peering and intermediary routing. The topologies including direct peering and intermediary routing. The
mechanism is optimized for direct peering. It can work in mechanism is optimized for direct peering. It can work in
intermediary routing cases as well. intermediary routing cases as well.
8. Security Considerations 8. Security Considerations
The principal question with the specification is whether it alters The principal question with the specification is whether it alters
the privacy characteristics of a non-optimized federated system. 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 Consider first the case where the serving domain is using the minimal
trust model. In that case, the ACL provided to the watching trust model. In that case, the ACL provided to the subscribing
information does not carry any information that the watching domain domain does not carry any information that the subscribing domain
doesn't already know. It merely points out when two watchers share doesn't already know. It merely points out when two subscribers
the same view. This is something that the watching domain could have share the same view. This is something that the subscribing domain
already ascertained by comparing presence documents delivered to each could have already ascertained by comparing presence documents
watcher. The ACL makes this task easier, but nonetheless the delivered to each subscriber. The ACL makes this task easier, but
watching domain could have already ascertained it. Consequently, nonetheless the subscribing domain could have already ascertained it.
there is no change whatsoever in the level of privacy afforded by the Consequently, there is no change whatsoever in the level of privacy
optimization when this mode is used. afforded by the optimization when this mode is used.
However, when an ACL is provided that includes other users besides However, when an ACL is provided that includes other users besides
the actual watcher, this provides additional information to the the actual subscriber, this provides additional information to the
watching domain. This is, however, information that the watching subscribing domain. This is, however, information that the
domain could find out anyway. If it generated a subscription from subscribing domain could find out anyway. If it generated a
each of its users to the presentity it would be able to determine who subscription from each of its users to the resource it would be able
from its domain is allowed to subscribe and what view they would to determine who from its domain is allowed to subscribe and what
receive. This would be an expensive operation to be sure, but it is view they would receive. This would be an expensive operation to be
possible. Consequently, the optimization doesn't really provide sure, but it is possible. Consequently, the optimization doesn't
anything new to the originating domain, even in this case. really provide anything new to the originating domain, even in this
case.
However, there is an attack possible when the information is divulged However, there is an attack possible when the information is divulged
to an end user. Consider a watching domain that doesn't actually to an end user. Consider a subscribing domain that doesn't actually
implement this extension at all. A user within the domain uses a implement this extension at all. A user within the domain uses a
client that generates a subscription to a presentity in a remote client that generates a subscription to a resource in a remote
domain. This subscription uses an outbound proxy in the watching domain. This subscription uses an outbound proxy in the watching
domain. The outbound proxy is just a proxy, and therefore doesn't domain. The outbound proxy is just a proxy, and therefore doesn't
remove or modify the Supported header field in the request. The remove or modify the Supported header field in the request. The
serving domain accepts the subscription and sends an ACL that serving domain accepts the subscription and sends an ACL that
contains the full set of watchers that are permitted in the contains the full set of subscribers that are permitted in the
originating domain. The original watcher now knows the set of other originating domain. The original subscriber now knows the set of
authorized buddies within their own domain, and what views they will other authorized buddies within their own domain, and what views they
see. While this is information that the domain overall would have will see. While this is information that the domain overall would
access to, it is not information an end user would normally have have access to, it is not information an end user would normally have
access to. Consequently, this is a more serious privacy violation. access to. Consequently, this is a more serious privacy violation.
It is for this reason that this specification requires that both It is for this reason that this specification requires that both
sides of the federated link be explicitly provisioned to utilize this sides of the federated link be explicitly provisioned to utilize this
optimization. In the attack above, the watching domain would not optimization. In the attack above, the subscribing domain would not
have set up a peering relationship with the serving domain. If it 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 had, it would have an RLS and would not have permitted the user to
directly subscribe in this way. Thus, when the subscription is directly subscribe in this way. Thus, when the subscription is
received by the serving domain, it will find that it has no agreement received by the serving domain, it will find that it has no agreement
with the originating domain, and would not utilize view sharing. with the originating domain, and would not utilize view sharing.
This thwarts the attack. This thwarts the attack.
This remedy is not optimal because it requires on provisioning to This remedy is not optimal because it requires on provisioning to
prevent. There does not appear to be any easy cryptographic means to prevent. There does not appear to be any easy cryptographic means to
prevent it, however. prevent it, however.
In all cases, view sharing requires secure authentication and 8.2. Privacy Considerations of the Watched Resource
encryption between the domains that use it. This is provided by TLS.
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
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 9. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
9.1. MIME Type Registration 9.1. MIME Type Registration
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 2048 [RFC2048] and guidelines in according to the procedures of RFC 2048 [RFC2048] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: aclinfo+xml MIME subtype name: viewshare-acl+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023]. specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023]. application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification]]. XXXX with the RFC number of this specification]].
skipping to change at page 26, line 43 skipping to change at page 27, line 38
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
9.2. URN Sub-Namespace Registration 9.2. URN Sub-Namespace Registration
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: The URI for this namespace is urn:ietf:params:xml:ns:aclinfo. URI: The URI for this namespace is
urn:ietf:params:xml:ns:viewshare-acl.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>ACL Info Namespace</title> <title>ACL Info Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for ACL Info</h1> <h1>Namespace for ACL Info</h1>
<h2>urn:ietf:params:xml:ns:aclinfo</h2> <h2>urn:ietf:params:xml:ns:viewshare-acl</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [NOTE <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
9.3. Schema Registration 9.3. Schema Registration
This section registers an XML schema per the procedures in [RFC3688]. This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:aclinfo URI: urn:ietf:params:xml:schema:viewshare-acl
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5.5. Section 5.5.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Avshalom Houri and Michael Froman for The authors would like to thank Avshalom Houri, Richard Barnes, and
their comments on this document. Michael Froman for their comments on this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
skipping to change at page 28, line 32 skipping to change at page 29, line 32
[W3C.REC-xml-20001006] [W3C.REC-xml-20001006]
Maler, E., Paoli, J., Bray, T., and C. Sperberg-McQueen, Maler, E., Paoli, J., Bray, T., and C. Sperberg-McQueen,
"Extensible Markup Language (XML) 1.0 (Second Edition)", "Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006, World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>. <http://www.w3.org/TR/2000/REC-xml-20001006>.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008. draft-ietf-sip-outbound-16 (work in progress),
October 2008.
11.2. Informative References 11.2. Informative References
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000. Presence and Instant Messaging", RFC 2778, February 2000.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004. (PIDF)", RFC 3863, August 2004.
skipping to change at page 29, line 9 skipping to change at page 30, line 10
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006. Information Data Format (PIDF)", RFC 4480, July 2006.
[I-D.ietf-simple-interdomain-scaling-analysis] [I-D.ietf-simple-interdomain-scaling-analysis]
Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
and H. Schulzrinne, "Presence Interdomain Scaling Analysis and H. Schulzrinne, "Presence Interdomain Scaling Analysis
for SIP/SIMPLE", for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-04 (work in draft-ietf-simple-interdomain-scaling-analysis-05 (work in
progress), February 2008. 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] [I-D.ietf-sip-subnot-etags]
Niemi, A., "An Extension to Session Initiation Protocol Niemi, A., "An Extension to Session Initiation Protocol
(SIP) Events for Conditional Event Notification", (SIP) Events for Conditional Event Notification",
draft-ietf-sip-subnot-etags-02 (work in progress), draft-ietf-sip-subnot-etags-03 (work in progress),
February 2008. July 2008.
[I-D.ietf-sipping-presence-scaling-requirements] [I-D.ietf-sipping-presence-scaling-requirements]
Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. Houri, A., Parameswar, S., Aoki, E., Singh, V., and H.
Schulzrinne, "Scaling Requirements for Presence in SIP/ Schulzrinne, "Scaling Requirements for Presence in SIP/
SIMPLE", SIMPLE",
draft-ietf-sipping-presence-scaling-requirements-00 (work draft-ietf-sipping-presence-scaling-requirements-01 (work
in progress), February 2008. in progress), July 2008.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Iselin, NJ
US US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Steve Donovan Steve Donovan
Cisco Cisco
Richardson, TX Richardson, TX
US US
Email: stdonova@cisco.com Email: stdonova@cisco.com
Kathleen McMurry Kathleen McMurry
Cisco Cisco
Richardson, TX Richardson, TX
US US
Email: kmcmurry@cisco.com Email: kmcmurry@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
 End of changes. 132 change blocks. 
486 lines changed or deleted 559 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/