One document matched: draft-ietf-simple-view-sharing-02.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc ipr="full3978" category="std">
<front>
<title abbrev="Presence View Sharing">
Optimizing Federated Presence with View Sharing</title>
<author initials="J.R." surname="Rosenberg"
fullname="Jonathan Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<city>Iselin</city> <region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author initials="S.D." surname="Donovan"
fullname="Steve Donovan">
<organization>Cisco</organization>
<address>
<postal>
<city>Richardson</city> <region>TX</region>
<country>US</country>
</postal>
<email>stdonova@cisco.com</email>
</address>
</author>
<author initials="K.M." surname="McMurry"
fullname="Kathleen McMurry">
<organization>Cisco</organization>
<address>
<postal>
<city>Richardson</city> <region>TX</region>
<country>US</country>
</postal>
<email>kmcmurry@cisco.com</email>
</address>
</author>
<date year="2008" />
<area>RAI</area>
<workgroup>SIMPLE</workgroup>
<keyword>SIP</keyword>
<keyword>Presence</keyword>
<keyword>Federation</keyword>
<abstract>
<t>Presence federation refers to the exchange of presence
information between systems. One of the primary
challenges in presence federation is scale. With a large
number of watchers in one domain obtaining presence for
many presentities in another, the amount of notification
traffic is large. This document describes an extension to
the Session Initiation Protocol (SIP) event framework,
called view sharing. View sharing can substantially
reduce the amount of traffic, but requires a certain
level of trust between domains. View sharing allows the
amount of presence traffic between domains to achieve the
theoretical lower bound on information exchange in any
presence system. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Presence refers to the ability, willingness and desire to communicate
across differing devices, mediums and services
<xref target="RFC2778"/>. Presence is described using presence
documents <xref target="RFC3863"/> <xref target="RFC4479"/>, exchanged
using a SIP-based event package <xref target="RFC3856"/>.
</t>
<t>
Presence federation refers to the interconnection of disparate systems
for the purposes of sharing presence information. This interconnection
involves passing of subscriptions from one system to another, and then
the passing of notifications in the opposite direction. Federation can
be occur between different domains, where it is referred to as
inter-domain federation. However, federation can also occur within a
domain, where it is referred to as intra-domain federation
<xref target="I-D.ietf-simple-intradomain-federation"/>.
</t>
<t>
<xref target="I-D.ietf-simple-interdomain-scaling-analysis"/> has
analyzed the amount of traffic, in terms of messages and in terms of
bytes, which flow between systems in various federated use
cases. These numbers demonstrate that presence traffic can be a
substantial source of overhead. The root cause of this scale challenge
is the so-called multiplicative effect of presence data. If there are
N users, each of which have B buddies on their buddy list, and each
buddy changes state L times per hour, the amount of notification
traffic is proportional to N*B*L. For example, in the case of two
extremely large public IM providers that federate with each other
(each with 20 million users),
<xref target="I-D.ietf-simple-interdomain-scaling-analysis"/> shows
that the amount of traffic due to these steady state notifications is
18.4 billion messages per day, an astoundingly large number. Overhead
for subscription maintenance and refreshes brings the total to 25.6
billion per day.
</t>
<t>
The overhead for SIP-based presence can be reduced using SIP
optimizations. In particular,
<xref target="I-D.ietf-sip-subnot-etags"/> can reduce the amount of
traffic due to refreshes and polls. However, this optimization targets
the overhead, and doesn't address the core scaling problem - the
multiplicative effect of presence data.
</t>
<t>
For this reason, there is a clear need to improve the scale of SIMPLE
in federated
envrionments. <xref target="I-D.ietf-sipping-presence-scaling-requirements"/>
has laid out a set of requirements for optimizations. The essence of
these requirements are that the extension should improve performance,
while being backwards compatible and supporting the privacy and policy
requirements of users.
</t>
<t>
This document defines a mechanism called view sharing in support of
those requirements. The key idea with view sharing is that when there
are many watchers in one system to a single presentity in
another system, each of which is actually going to get the
exact same presence document, the watcher's system extends a
single subscription to the system of the presentity, and the
system of the presentity sends a single copy of the presence document
back to the system of the watcher. Consequently, a "view" is a
particular sequence of presence documents that come about as a
consequence of a particular composition, authorization and privacy
policy. Two watchers which share the same view will always receive the
same presence document when the state of the presentity changes.
</t>
<t>
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.
</t>
<t>
In the case of a pair of large providers that are peering with each
other, this mechanism can result in a significant savings.
Assuming a symmetrical system whereby the average buddies per
watcher is B and the average number of watchers for a user is also B,
if most buddies are in one domain or the other, this optimization can
reduce the overall subscription overhead and notification traffic by a
factor of B/2. In cases where there are a large number of small
domains, this mechanism is less useful. Of course, in such cases, the
amount of traffic between any pair of domains is small anyway.
</t>
</section>
<section title="Overview of Operation">
<t>
The extension works in the environment shown in
<xref target="fig-pres-model"/>. For explanatory purposes, the
environment assumes two domains. There are some number of subscribers (W1
- W3) in the domain on the left, which we call the subscribing
domain. All of those subscribers are interested in the state of a
single resource P1 in the domain on the right, which we call the
serving domain. The subscribers all make use of a resource list server
(RLS) <xref target="RFC4662"/> which stores their resource lists and
performs the list expansion. Consequently, when each subscriber
subscribes to their resource list on the RLS, in absence of any
optimizations, the RLS will generate three separate subscriptions to
P1, each of which reaches the notifier in the serving domain.
</t>
<figure title="Deployment Model" anchor="fig-pres-model"><artwork>
<![CDATA[
.
+--------------+ . +--------------+
| | . | |
| | SUB . | |
| | -------.---> | |
| RLS | NOT . | Notifier |
| | <------.---- | |
| | . | |
| | . | |
+--------------+ . +--------------+
^ ^ ^ . ^
List | | | . | PUB
SUB | | | . |
| | | . |
+----+ +----+ +----+ . +----+
| | | | | | . | |
| W1 | | W2 | | W3 | . | P1 |
| | | | | | . | |
+----+ +----+ +----+ . +----+
.
.
.
Subscribing . Serving
Domain . Domain
.
]]></artwork></figure>
<t>
Of course, in practice each domain will act as both a subscribing domain
and a serving domain, thus implementing both sides of the
system.
</t>
<t>
The initial SUBSCRIBE generated by the RLS includes a SIP option tag
"view-share" in the Supported header field, indicating that the RLS
supports the view sharing extension. If the notifier also
supports the extension, it makes use of it and includes an indication
of this fact in the Require header field in the SUBSCRIBE response and
in NOTIFY requests it generates.
</t>
<t>
View sharing requires a level of trust between the two
domains. Typically, TLS will be deployed between them, and the
notifier uses it to determine if the subscribing domain is
authorized.
</t>
<t>
If this is the first subscription from domain 1 for that particular
resource, the notifier accepts the subscription (assuming the
subscriber is authorized of course). The notifications sent to the RLS
include two separate pieces of state. One is the actual state for the
resource. The other is an Access Control List (ACL) document. This
document describes the set of other subscribers from the originating
domain, if any, who are authorized to see exactly the same document -
in other words, the set of users that share the same view. Should one
of those subscribers seek the state of that resource for the same
event package, the RLS from the originating domain does not need to
generate a back-end subscription; rather, it just uses the
document it is receiving from the original subscription, and passes it
to both subscribers. The ACL can also list users in the originating
domain that are authorized to subscribe to that resource, but who will
end up receiving a different view. Should one of those subscribers
subscribe, the RLS knows that it must perform a back-end subscription
to obtain that view. The ACL can also list subscribers in the
originating domain that are not authorized at all, in which case the
RLS could immediately reject their subscriptions. Finally, if the ACL
says nothing about a particular subscriber, it means that the notifier
has elected to say nothing about what view this subscriber will
receive. Consequently, the RLS must perform a back-end subscription
should that subscriber subscribe to the resource.
</t>
<t>
Other subsequent subscriptions to the same resource from the same
originating domain are processed in a similar way. However, the
notifier in the serving domain will keep track of the set of
subscriptions to the same resource for the same event package from the
same RLS which are to receive the same view. When a presence
notification is to be sent, instead of sending it on all
such subscriptions, the notification is sent on just a single subscription.
</t>
<t>
Should the authorization policies in the serving domain change, an
updated ACL is sent, informing the subscribing domain of the new
policies. This may require the subscribing domain to extend a back-end
subscription to obtain a view, or may change the view an existing
subscriber is receiving, and so on.
</t>
<t>
The ACL allows the serving domain a great deal of flexibility in the
level of trust it imparts to the watching domain. The following are
all possible approaches that the serving domain can utilize:
</t>
<list style="hanging">
<t hangText="No Trust:"> When a notifier receives the
subscription, it elects not to use this mechanism at all using the
negotiation techniques defined here.
</t>
<t hangText="Minimal Trust:"> When a subscriber subscribes to a
resource, the ACL generated for that subscription includes only
that subscriber, along with an identifier for their view. Consequently,
for each subscriber in domain 1 there will be a backend subscription to
domain 2. However, should multiple subscribers share the same view, the
notifier in domain 2 sends a single document on one
of the subscriptions, and the RLS uses this for all of the other
subscribers with the same view. With this approach, domain 2 never
discloses the list of authorized subscribers ahead of time, and it has
full knowledge of each subscriber that is subscribed. However, it gets
the performance benefits of reducing the amount of notification
traffic.
</t>
<t hangText="Partial Trust:"> When a subscriber subscribes to a
resource, the ACL generated for that subscription includes that
subscriber and all other subscribers authorized for that same
view. Consequently, there will only be one backend subscription from
the RLS to the notifier for each view. However, the full set
of authorized subscribers is not disclosed ahead of time, only those
that will get the same view. With partial trust, the notifier
will not know the full set of subscribers currently subscribed.
</t>
<t hangText="Full Trust:"> When a subscriber subscribes to a resource,
the ACL generated for that subscription includes that subscriber and
all other subscribers that are authorized for that view, and all other
views, along with a rule that says that all other subscribers get
rejected. In this case, as with partial trust, there is only one
backend subscription from the RLS to the notifier for each
view. The full set of subscribers is disclosed ahead of time as
well. The notifier will not know the full set of subscribers
currently subscribed.
</t>
</list>
<t>
Depending on the level of trust, the mechanism trades off inter-domain
messaging traffic for increased processing load in the RLS to handle
the ACL documents.
</t>
</section>
<section title="RLS Behavior">
<t>
This section defines the procedures that are to be followed by the
RLS. It is important to note that, even though this specification
defines an extension to the SIP events framework, the extension is
only useful for the back-end subscriptions generated by an RLS. The
extension defined here is not applicable or useful for individual
users generating subscriptions. Indeed, if it were utilized by
individual users, it has the potential for violations of user
privacy. See <xref target="sec-security"/> for a discussion.
</t>
<section title="On Receipt of a Resource List Subscription Request">
<t>
When the RLS receives a subscription to a resource list which includes
some resource P in another domain or system, it follows the rules
defined here. The processing depends on whether
the RLS already has a backend subscription to the resource that is
in the active state, and for which an ACL has been received.
</t>
<section anchor="sec-sub" title="Find a Matching Back-End Subscription">
<t>
First, the RLS determines if it has a back-end subscription in place
whose view corresponds to that of the new subscriber. Let P be the
target resource, E the desired event package, and W the identity of
the subscriber.
</t>
<t>
Based on the procedures of <xref target="sec-aclinfo"/>, 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
<xref target="sec-rule-determine"/> to compute the rule ID R for the
subscriber W. This represents the view that the subscriber is supposed
to receive.
</t>
<t>
Next, the RLS goes through all subscriptions it currently has for
resource P and event package E. For each one, it takes the identity of
the subscriber for that actual subscription. The identity for the
subscriber for that actual subscription is equal to the asserted
identity included in the back-end subscription. For example, if SIP
Identity <xref target="RFC4474"/> is utilized, this would be the URI
present in the From header field of the back-end SUBSCRIBE. Call the
subscriber identity for each subscription Wj.
</t>
<t>
Next, the RLS computes the rule determination algorithm of
<xref target="sec-rule-determine"/> to compute the rule ID Rj for the
subscriber Wj on each subscription j. This represents the rule ID for the
view being delivered on that subscription.
</t>
<t>
Then, processing depends on the values of R and Rj:
</t>
<list style="symbols">
<t>
If R is null, it means that no ACL in the list specifies the view for
this subscriber. The RLS MUST generate a back-end subscription to
resource P and event package E, and MUST use subscriber W as the
identity in the back-end subscription.
</t>
<t>
If R is not null, but the associated rule is blocked, it means that
the subscriber will be rejected. The RLS SHOULD NOT perform another
back-end subscription, and must act as if it had created a back-end
subscription which was rejected.
</t>
<t>If R is not null, and there is at least one subscription j for
which Rj = R, it means
that subscription j is already generating notifications for the view
that subscriber W is supposed to receive. In that case, the RLS SHOULD
NOT generate a back-end subscription for P on behalf of W. Rather,
it should treat the existing back end subscription j as if it were
the back-end subscription for W, and follow the guidelines of RFC
4662 <xref target="RFC4662"/> based on that. Subscription j is
called the generating subscription for subscriber W, and the actual
subscriber associated with subscription j, Wj, is called the generating
subscriber Wgen for subscriber W.
</t>
<t>If R is not null, but there is no subscription j for which Rj=R,
it means that the RLS
is not yet receiving the view that subscriber W requires. The RLS MUST
generate a back-end subscription to resource P, and MUST use
subscriber W as the identity in the back-end subscription.
</t>
</list>
</section>
<section title="Generating a Back-End Subscription">
<t>
If, based on the processing of the previous section, a new back-end
subscription is needed, the rules in this section are followed.
</t>
<t>
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 <xref target="I-D.ietf-sip-outbound"/> to
uniquely identify the RLS instance.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Processing NOTIFY Requests">
<t>
If a NOTIFY request arrives with a Require header field that includes
the "view-share" option tag, it MUST be processed according to the
rules of this specification.
</t>
<section anchor="sec-aclinfo" title="Processing ACL-Infos">
<t>
If the contents of the NOTIFY are of type "application/viewshare-acl+xml",
the subscriber processes the body as described here.
</t>
<t>
For each resource that the RLS has at least one back-end subscription
for, the RLS MUST remember the most recent viewshare-acl received on
each back-end subscription. This is called the current ACL list for
the resource. This set of viewshare-acl is used in
the processing of subscription requests, as described in
<xref target="sec-sub"/>.
</t>
<t>
The serving domain can change policies at any time. When it does, it
sends an updated ACL on one or more subscriptions. The RLS MUST store
this ACL, replacing any previous ACL's received on this
subscription. Furthermore, the ACL might impact the views being
received by subscribers, and may impact the state of the back-end
subscriptions.
</t>
<t>
The RLS computes the set of subscribers Wi which have a resource list
subscription that includes the resource P for whom an updated ACL
has just been received. For each Wi, it performs the view
determination algorithm (see <xref target="sec-rule-determine"/> on
the current ACL set. Let Ri be the view associated with subscriber Wi. If
Ri has not changed from prior to the receipt of the new ACL, no action
is taken. However, if it has changed, the RLS takes the set of current
back-end subscriptions, and for each subscription j, computes the view
determination algorithm for its associated subscriber Wj, to produce
Rj. The action to take depends on what has changed:
<list style="symbols">
<t>
If Ri is now null, it means that the
serving domain has changed the views associated with subscriber Wi, and
this new view is not known to the RLS. The
RLS MUST generate a new back-end subscription on behalf of subscriber
Wi for resource P to obtain this view.
</t>
<t>
If Ri is now a blocked rule, it means that the serving domain has
now blocked Wi from obtaining the presence of the resource. The
RLS must act as if it had a back-end subscription on behalf of
subscriber Wi which was terminated.
</t>
<t>If Ri is not null and not blocked, and if there is an Rj which
matches the new Ri, it means that the
serving domain has changed the views associated with subscriber Wi, and
changed them to another view already being received by the RLS. The
RLS MUST treat this back-end subscription j as if it were the
back-end subscription to resource P for subscriber Wi. If the most
recent presence document received on this back-end subscription is
not a semantic match for the presence document most recently
delivered to Wi for resource P, the RLS MUST send this most recent
presence document to subscriber Wi.
</t>
<t>
If Ri is not null and not blocked, but there is no Rj which matches
the new Ri, it means that the
serving domain has changed the views associated with subscriber Wi, and
this new view is not one currently being delivered to the RLS. The
RLS MUST generate a new back-end subscription on behalf of subscriber
Wi for resource P to obtain this view.
</t>
</list>
</t>
<t>
Furthermore, if there are now two back-end subscriptions j1 and j2
which have identical ACLs, RLS SHOULD terminate one of those two
subscriptions. Two ACL documents are considered equal if they
enumerate the same set of rules with the same members for each rule.
</t>
</section>
<section title="Processing State Documents">
<t>
If the contents of the NOTIFY is a state document for the given event
package, the RLS follows the procedures defined here.
</t>
<t>
Let Wj be the subscriber on the subscription j on which the
document was just received. Let Rj be the results of running the rule
determination algorithm on Wj using the current ACL set. Next, the RLS
takes the set of subscribers Wi which have resource P on their resource
lists. The RLS then runs the rule determination algorithm on each Wi
using the current ACL set, producting Ri for each subscriber Wi. For each
Ri that is equal to Rj, the RLS MUST utilize the document
just received as if the back-end subscription j was in fact for
subscriber Wi. This will typically cause that document to be
sent in a NOTIFY request to each such subscriber, though each subscriber may
have some kind of filtering policy which causes the RLS to modify the
document prior to delivery.
</t>
</section>
<section title="Processing Back-End Terminations">
<t>
If the NOTIFY request from the serving domain terminates the back-end
subscription, it may be because the subscriber Wj associated with that
subscription is no longer permitted to view the state of the
resource.
</t>
<t>
The ACL associated with the subscription MUST be removed from the
current ACL set. The procedures of <xref target="sec-aclinfo"/> MUST
be performed to adjust back-end subscriptions, if needed.
</t>
</section>
</section>
<!-- RLS behavior -->
</section>
<section title="Notifier Behavior">
<t>
When a notifier receives a
SUBSCRIBE request containing a Supported header with the value
"view-share", and it wishes to utilize view sharing for this
subscription, it follows the procedures defined here.
</t>
<section title="Authentication and Authorization">
<t>
The principle concern of the notifier is to determine the domain
of the RLS, and assess whether the subscribing entity is an RLS
authorized to operate on behalf of that domain. In order to utilize
view sharing, a notifier MUST determine both. This information is
necessary in order to compute the ACL to be sent to that domain, and
if done incorrectly, may reveal sensitive information to the watching
domain.
</t>
<t>
To determine the domain of the subscribing RLS, TLS with mutual
authentication SHOULD be used. In such a case, the notifier can
determine the domain of the RLS from the subjectAltName in the
certificate presented from its peer.
</t>
<t>
This specification does not define any automated mechanism for a
notifier to determine whether the subscribing entity is, in
fact, an RLS authorized to operate on behalf of the watching
domain. <xref target="sec-security"/> 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.
</t>
</section>
<section title="Processing Initial SUBSCRIBE Requests">
<t>
First, the subscription is processed as it normally would be,
including authorization and policy around the document to be
delivered to the subscriber. Furthermore, if the notifier wishes to
utilize view sharing for this subscription, it MUST include a Require
header field in the first NOTIFY request (and indeed any subsequent
ones) it sends confirming this
subscription, and that NOTIFY MUST contain the "view-share" option
tag. That option tag MUST NOT be present in the Require header field
of notifications unless the corresponding dialog-forming SUBSCRIBE
contained it in a Supported header field.
</t>
<t>
Furthermore, the initial state sent by the notifier MUST include an
ACL document. It is formatted according to the rules and
considerations in <xref target="sec-aclformat"/>.
</t>
<t>
The initial state sent by the notifier might include an actual
state document. In particular, a state document MUST be sent if
one of the following is true:
<list style="symbols">
<t>There is only one subscription from the watching domain to this
resource that has the view associated with the subscriber.
</t>
<t>
There is more than one subscription from the watching domain to this
resource with the same view, but the +sip.instance parameter for the
remote target (as conveyed in the Contact header field of the
SUBSCRIBE) differs. In other words, these subscriptions are from the
same domain, but from different RLS in the watching domain. Each RLS
in the watching domain needs to get their own copy of the view for a
particular resource.
</t>
</list>
If one of these conditions is not true, the notifier SHOULD NOT
send an initial state document on this subscription.
</t>
<t>If an ACL and a state document are to be delivered, they MUST be
delivered separate NOTIFY requests unless the
subscriber indicated support for multipart, in which case the content
MAY be included in a single NOTIFY with mulitpart content.
</t>
</section>
<section title="SUBSCRIBE Refreshes">
<t>
When the notifier receives a SUBSCRIBE refresh, it MUST send the most
recent ACL document, and if state documents are being sent for
this subscription, the most recent state document.
</t>
</section>
<section title="Policy Changes">
<t>
There are several different types of policy changes that can occur:
<list style="symbols">
<t>If the definitions for a particular rule change, the notifier
MUST assign a new rule ID for that rule. For each subscription to a
resource which contained that rule, the notifier MUST send
an updated ACL which includes a rule with this new rule ID.
</t>
<t>If some subscriber W was previously associated with rule X and is now
associated with rule Y, the notifier checks if it has any
subscriptions from subscriber W. If it does, it MUST send an updated
ACL on that subscription. Based on the rules in
<xref target="sec-aclformat"/>, this ACL will contain rule Y and
will at least include W amongst the list of members. Furthermore, if
there were subscriptions from other subscribers, but the notifier
had previously sent an ACL on the subscription which was a match for
W, it MUST send an updated ACL on that subscription. This updated
ACL MAY omit a statement about rule Y or MAY include it. However,
the updated ACL MUST NOT claim that subscriber W will receive rule X.
</t>
<t>
If some subscriber W was previously associated with rule X and is now
blocked, the notifier checks if it has any subscriptions from
subscriber W. If it does, it MUST terminate the back-end
subscription. If it doesn't, but it has a subscription from some
other subscriber which had included a rule that was a match for W, the
notifier MUST send an updated ACL on that subscription. This updated
ACL MAY omit any statement about subscriber W, or MAY include them as
part of a blocked rule in that ACL.
</t>
<t>
If some subscriber W was previously blocked and is now permitted and
associated with some rule X, the notifier checks if it had any
subscriptions from some other subscriber which included a blocked rule
that matched subscriber W. If it had, it MUST send an updated ACL on
that subscription. That updated ACL MAY omit any statement about
subscriber W, or MAY indicate that subscriber W is now associated with
rule X.
</t>
</list>
</t>
<t>
Of course, a policy change will also potentially alter the state
documents that are associated with a view. If so, the notifier
MUST send an updated document on a subscription if one of the
following is true:
<list style="symbols">
<t>There is only one subscription from the watching domain to this
resource that has the view associated with the subscriber.
</t>
<t>
There is more than one subscription from the watching domain to this
resource with the same view, but the +sip.instance Contact header field in
the request differs between them.
</t>
</list>
</t>
<t>
If neither is true, the notifier MUST select one subscription amongst
the several which share the same resource, view, and Contact
+sip.instance header field parameter, and sent an updated notification
on that subscription. The choice of subscriptions is arbitrary and MAY
change for each notification.
</t>
</section>
<section title="Event State Changes">
<t>
If the state of some resource changes, the notifier may need
to send an updated notification on a subscription. The notifier
MUST send an update on a subscription if one of the
following is true:
<list style="symbols">
<t>There is only one subscription from the watching domain to this
resource that has the view associated with the subscriber.
</t>
<t>
There is more than one subscription from the watching domain to this
resource with the same view, but the +sip.instance Contact header
field in the request differs between them.
</t>
</list>
</t>
<t>
If neither is true, the notifier MUST select one subscription amongst
the several which share the same resource, view, and Contact
+sip.instance header field parameter, and sent an updated notification
on that subscription. The choice of subscriptions is arbitrary and MAY
change for each notification.
</t>
</section>
<!-- end notifier behavior -->
</section>
<section anchor="sec-aclformat" title="ACL Format">
<t>
An ACL document is an <xref
target="W3C.REC-xml-20001006">XML</xref> document that MUST be
well-formed and MUST be valid according to schemas, including
extension schemas, available to the validater and applicable to the
XML document. ACL documents MUST be based on XML 1.0 and
MUST be encoded using UTF-8. This specification makes use of XML
namespaces for identifying ACL documents and document
fragments. The namespace URI for elements defined by this
specification is a <xref target="RFC2141">URN</xref>, using the
namespace identifier 'ietf' defined by <xref target="RFC2648">RFC
2648</xref> and extended by <xref target="RFC3688">RFC
3688</xref>. This URN is:
</t>
<list style="hanging"><t>
urn:ietf:params:xml:ns:viewshare-acl
</t></list>
<section title="Document Structure and Semantics">
<t>
An ACL document informs a watching domain of the set of views that can
be received by that domain, and associates specific subscribers with
specific views. It is very important to understand that the ACL
document does not convey the actual processing that will be applied by
the serving domain. It does not indicate, for example, whether
geolocation is present in a presence document, or which rich presence
<xref target="RFC4480"/> data elements will be conveyed. It merely
provides grouping - indicating which subscribers from the subscribing domain
will receive the same view.
</t>
<t>
Each ACL document starts with the enclosing root element
<acl-list>. This contains the list of rules defined by the
ACL. Each rule is represented by the <rule> element. Each rule
represents a specific view, which is generated by the notifier
based on its authorization, composition and filtering policies. Each
rule is associated with a rule ID, which is a mandatory attribute of
the <rule> element. This ID is scoped within a single
resource. That is, the IDs for two rules for different presentities
are unrelated.
</t>
<t>
The <rule> element also contains an optional "blocked"
boolean attribute. If "true", it means that the rule specifies that
the associated set of subscribers will be rejected, should they
subscribe. This can be used by the watching domain to avoid performing
back-end subscriptions to users which will only be blocked anyway.
</t>
<t>
Each <rule> contains the set of users that will receive the
corresponding view. This can be described by an enumerated set or by a
default. If it is an enumerated set, the <rule> is followed by a
sequence of <member> elements, each of which contains a SIP URI
for the subscriber that will receive that view.
</t>
<t>
The default view is specified by including a single child element for
<rule> - <other>. The default view applies to all subscribers
except those enumerated by other rules. For this reason, an ACL
document which contains a default view MUST include the rule IDs and
associated members for all other views that are delivered to
subscribers. For example, consider a resource that has three
views. View 1 is delivered to subscribers A and B. View 2 is delivered to
subscriber C. View 3 is delivered to everyone else. An ACL document that
includes the default view must also include views 1 and 2 with
subscribers A, B, and C.
</t>
<t>In contrast, an ACL document that does not
include a default does not need to include all views, and it does not
need to include all members for a particular view. Using the example
above, it is valid to include an ACL document which includes only
view 1 with subscriber 1.
</t>
<t>
If two URI are present within <member> elements within the same
<rule>, it represents an indication by the notifier that
both users MUST get the same view. Formally, if the notifier
were to receive a subscription from each subscriber, both subscriptions
would be accepted or both would be rejected, and if accepted, each
subscription would receive semantically identical presence documents
at approximately the same time.
</t>
<t>
Even if two users will receive the same view, a notifier MAY
assign each to a different view ID. There is no requirement that two
unique views actually contain different presence data. The only
requirement is that, if two users are listed within the same rule,
that they do in fact receive the same view.
</t>
<t>
An ACL document delivered in a subscription from subscriber W MUST
include the view associated with subscriber W and MUST include subscriber W
explicitly in a <member> element or implicitly by presence of an
<other> element.
</t>
</section>
<section title="Trust Considerations when Construcing ACLs">
<t>
The semantics above give very little guidance about what a notifier
should include in an ACL. The amount of information to convey
depends on the level of trust between the subscribing and serving
domains.
</t>
<t>
Firstly, in all cases, any subscriber listed in a rule MUST be one that
the subscribing RLS is authorized to perform subscriptions
for. Typically, this is all of the subscribers in the domain of the
RLS. For example, if a view-sharing subscription is received from
example.com, only subscribers whose domain is example.com should be
included in the ACL. However, in cases where view sharing is used
between a clearinghouse provider and clearinghouse members, the ACL
could include subscribers in other domains, based on the policy of the
serving domain.
</t>
<t>
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.
</t>
<t>
Slightly worse performance is achieved when the ACL document for a
resource sent in a subscription from subscriber W includes only a
single view - the one for subscriber W - along with the full set of
subscribers from that domain which will also receive that view, assuming
it is not the default view. If the view is the default view, the
document can include just subscriber W. This approach will cause back-end
subscriptions from every subscriber that will receive the default, but it
discloses less information to the watching domain. In particular, the
full set and number of views is never known by the watching
domain. The fact that a view is default is never known by the watching
domain. The full set of users that are permitted to view the state
of the resource is never disclosed to the watching domain. The
performance of this approach is still reasonably good when the default
rule is blocked. However it is much less effective when the default is
not blocked, and many subscribers receive the default.
</t>
<t>
Another choice for construction of ACL documents is to include, in a
subscription from subscriber W, a single rule containing the rule ID for
the view that subscriber W will receive, along with a single member -
W. This approach will still result in a back-end subscription from
each subscriber. However, a single notification is sent for each view,
rather than one per subscriber. The benefit of this construction is that
it provides the watching domain no additional information about the
authorization policies of the resource than if this extension were
not in use at all.
</t>
</section>
<section title="Example Documents">
<t>
The example document in <xref target="fig-example1"/> shows the case
when there is maximum trust between domains. The full set of subscribers,
include a blocked default, is included.
</t>
<figure anchor="fig-example1" title="Example with Maximum Trust"><artwork>
<![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="6228">
<member>sip:user1@example.com</member>
<member>sip:user2@example.com</member>
<member>sip:user3@example.com</member>
<member>sip:user4@example.com</member>
<member>sip:user5@example.com</member>
</rule>
<rule id="3584">
<member>sip:user6@example.com</member>
</rule>
<rule id="1735">
<member>sip:user7@example.com</member>
<member>sip:user8@example.com</member>
<member>sip:user9@example.comm</member>
<member>sip:user10@example.com</member>
<member>sip:user11@example.com</member>
</rule>
<rule blocked="true" id="9433">
<other />
</rule>
</acl-list>
]]></artwork></figure>
<t>
The example in <xref target="fig-example2"/> shows a moderate level of
trust. This ACL only shows the view associated with the subscriber user1.
</t>
<figure title="Example with Partial Trust" anchor="fig-example2"><artwork>
<![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="6228">
<member>sip:user1@example.com</member>
<member>sip:user2@example.com</member>
<member>sip:user3@example.com</member>
<member>sip:user4@example.com</member>
<member>sip:user5@example.com</member>
</rule>
</acl-list>
]]></artwork></figure>
<t>
The example in <xref target="fig-example3"/> shows the minimal level
of trust. This ACL would be sent in a subscription to user1.
</t>
<figure title="Example with Minimal Trust" anchor="fig-example3"><artwork>
<![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<acl-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="6228">
<member>sip:user1@example.com</member>
</rule>
</acl-list>
]]></artwork></figure>
</section>
<section anchor="sec-rule-determine" title="Rule Determination Algorithm">
<t>
Several steps in the processing of the ACL require that the RLS in the
watching domain execute the rule determination algorithm for subscriber W
on an ACL set. This algorithm is a simple algorithm which takes, as
input, a subscriber W with a given SIP URI, and a set of ACL documents
Ai, and returns as output, a rule ID R, which is the rule ID for the
view that, according to the set of ACLs, subscriber W should receive.
</t>
<t>
The algorithm proceeds as follows. First, each Ai is matched to W.
ACL Ai is a match
for subscriber W if:
<list style="symbols">
<t>ACL Ai contains a <member> tag whose URI is a match, based on URI
equality, for W, or</t>
<t>none of the <member> tags in Ai contain a URI that is a match,
based on URI equality, for W, but there is an
<other> element in Ai </t>
</list>
</t>
<t>
If no ACL Ai matched, the algorithm returns a null result.
</t>
<t>
For each ACL Ai that matches based on the rules above, take the id of
the enclosing <rule> element that contained the
<member> or
<other> element that caused the match. For ACL Ai, this is rule
Ri. For example, consider the following ACL:
</t>
<figure><artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<acl-list "xmlns=urn:ietf:params:xml:ns:viewshare-acl">
<rule id="1">
<member>sip:user1@example.com</member>
<member>sip:user2@example.com</member>
</rule>
<rule id="2">
<member>sip:user3@example.com</member>
</rule>
<rule id="3">
<other/>
</rule>
</acl-list>
]]></artwork></figure>
<t>
If this document is A1, and the subscriber is sip:user3@example.com, the
associated rule R1 is 2. If the subscriber is sip:user1@example.com or
sip:user2@example.com, the rule R1 is 1. If the subscriber is anyone else
from example.com, such as sip:user4@example.com, the rule R1 is 3.
</t>
<t>
If all Ri are equal, denote R = Ri. Thus, R is the rule ID associated
with this subscriber. Normally, all Ri will be equal. However, during
transient periods of changes in authorization state, it is possible
that inconsistent ACL documents exist. In that case, R is assigned the
value Ri from the ACL Ai which is the most recently received amonst
all ACLs.
</t>
</section>
<section anchor="sec-schema" title="XML Schema">
<figure><artwork>
<![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio 1.0.6.0 (http://www.liquid-technologies.com) -->
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="acl-list">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="rule">
<xs:complexType>
<xs:choice>
<xs:element name="other" />
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="member" type="xs:anyURI" />
</xs:sequence>
</xs:choice>
<xs:attribute name="id" type="xs:integer" use="required" />
<xs:attribute default="false" name="blocked" type="xs:boolean" use="optional" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork></figure>
</section>
</section>
<section anchor="sec-anal" title="Performance Analysis">
<t>
This section considers the performance improvement of the mechanism
when it is maximally exercised. The performance is examined in the
context of an inter-domain presence federation. In this example, the
full ACL, including blocked senders, is returned in the first
subscription to a presentity. This analysis assumes there is a single,
monolithic notifier serving each domain.
</t>
<t>
The optimizations improve ramp-up, steady state, and termination
message loads. In particular, each of those loads, without the
optimization described here, is proportional to C04, the total number
of federated presentities per watcher. If we assume symmetry, such
that the number of federated presentities per watcher is equal to the
number of watchers per federated presentity, then each of the load
figures is reduced by C04. That is, the system behaves identically to
the case where there is a single subscriber per federated presentity, and
assuming symmetric, the same as if there is a single federated
presentity per subscriber - e.g., C04 = 1.
</t>
<t>
Consider then the very large network peering model in
<xref target="I-D.ietf-simple-interdomain-scaling-analysis"/>. In this
model, the assumption is two large peering domains with 20 million
users each, with a value of 10 for C04. With this optimization, the
number of steady state notifications due to presence state changes
drops from 18.4 billion per day to 1.84 billion per day. The number of
messages per second overall is reduced from 654,167 per second to
65,417 per second. Still a big number, of course, but it can't
actually get much smaller.
</t>
<t>
Indeed, it can be readily shown that, assuming the federated domains
do not actually share raw presence inputs and the actual policies that
govern operation of their servers, no protocol can do better
(constants, such as mesage size and the need for protocol responses
and acknowledgements aside). Consider a domain with N
presentities. Each resource changes state P times per hour. Every
time the state changes, the domain applies its authorization and
composition policies. The resulting presence document cannot be known
to the watching domain. Thus, there must be at least one message from
the serving to watching domain, per view, in order to inform it of
that view. This means that the steady state rate of messages can never
be better than N*P, and this is exactly the factor governing the rate
of messages when this optimization is applied.
</t>
</section>
<section title="Requirements Analysis">
<t>
This section analyzes the requirements in
<xref target="I-D.ietf-sipping-presence-scaling-requirements"/> to
show how they are met by the mechanism proposed here.
</t>
<list style="hanging">
<t hangText="REQ-001:"> The solution should not hinder the
ability of existing SIMPLE clients and/or servers from peering
with a domain or client implementing the solution. No changes may
be required of existing servers to interoperate. This requirement
is met by usage of the Supported and Require mechanisms and SIP
which negotiate its usage.
</t>
<t hangText="REQ-002:"> It
does NOT constrain any existing RFC functional or security
requirements for presence. The mechanism does not change anything
that is possible without it. It does, however, introduce new
privacy considerations, described below in
<xref target="sec-security"/>.
</t>
<t hangText="REQ-003:"> Systems that are not using
the new additions to the protocol should operate at the same level
as they do today. This requirement is met by usage of the
Supported and Require mechanisms in SIP.
</t>
<t hangText="REQ-004:"> The solution does not limit the ability for presentities
to present different views of presence to different
watchers. This requirement is met by usage of the ACL document,
which allows the serving domain to associate a subscriber with any
view it likes, and to change it over time.
</t>
<t hangText="REQ-005:"> The solution does not restrict the ability of a
presentity to obtain its list of watchers. The mechanism does
allow a presence server to
know the list of subscribers, at the expense of non-optimal
performance. In particular, it will receive a subscription from
each subscriber. However, it only generates one notification per
view on presence changes. The fully optimized solution will
result in a loss of knowledge of the set of watchers. However,
it is a policy decision at the presence agent about whether it
would like to make this tradeoff.
</t>
<t hangText="REQ-006:"> The solution MUST NOT create any new or make worse any
existing privacy holes. This requirement is met, but only when
carefully provisioned. See <xref target="sec-security"/>.
</t>
<t hangText="REQ-007:"> It is highly desirable for any presence system (intra or
inter-domain) to scale linearly as number of watchers and
presentities increase linearly. When the most optimal technique
is used, there is always one subscription per view per
presentity, independent of the number of watchers in the remote
domain or the number of averages buddies per buddy list. Since
the number of views is not proportional to the number of users,
the total traffic volume in a domain is linear with its number
of presentities, and is independent of the number of users in
the peering domain.
</t>
<t hangText="REQ-008:"> The solution SHOULD NOT require significantly more state
in order to implement the solution. The mechanism requires
storage of the ACL, which has a size exactly equal to the number
of subscriptions that would be required if the extension were
not in place. Thus the memory usage is not worsened compared to
the baseline.
</t>
<t hangText="REQ-009:"> It MUST be able to scale to tens of millions of
concurrent users in each domain and in each peer domain. The
analysis in <xref target="sec-anal"/> shows that, when fully
utilized, this mechanism is the best that can possibly be
achieved in any system that does not actually share policies and
raw presence data.
</t>
<t hangText="REQ-010:"> It MUST support a very high level of watcher/presentity
intersections in various intersection models. The mechanism is
optimized for this case.
</t>
<t hangText="REQ-011:"> Protocol changes MUST NOT prohibit optimizations in
different deployment models esp. where there is a high level of
cross subscriptions between the domains. Since standard SIP
techniques are utilized to negotiate the extension, other
mechansims can be defined in the future.
</t>
<t hangText="REQ-012:"> New functionalities and extensions to the presence
protocol SHOULD take into account scalability with respect to the
number of messages, state size and management and processing
load. That is exactly what this extension targets.
</t>
<t hangText="REQ-013:"> The solution SHOULD allow for arbitrary federation
topologies including direct peering and intermediary
routing. The mechanism is optimized for direct peering. It can
work in intermediary routing cases as well.
</t>
</list>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>
The principal question with the specification is whether it alters the
privacy characteristics of a non-optimized federated system. This can
be considered for both the serving domain and the subscribed-to resource.
In all cases, view sharing requires secure authentication and
encryption between the domains that use it. This is provided by TLS.
</t>
<section title="Privacy Considerations of the Serving Domain">
<t>
Consider first the case where the serving domain is using the minimal
trust model. In that case, the ACL provided to the subscribing
domain does not carry any information that the subscribing domain
doesn't already know. It merely points out when two subscribers share the
same view. This is something that the subscribing domain could have
already ascertained by comparing presence documents delivered to each
subscriber. The ACL makes this task easier, but nonetheless the subscribing
domain could have already ascertained it. Consequently, there is no
change whatsoever in the level of privacy afforded by the optimization
when this mode is used.
</t>
<t>
However, when an ACL is provided that includes other users besides the
actual subscriber, this provides additional information to the subscribing
domain. This is, however, information that the subscribing domain could
find out anyway. If it generated a subscription from each of its users
to the resource it would be able to determine who from its domain is
allowed to subscribe and what view they would receive. This would be
an expensive operation to be sure, but it is possible. Consequently,
the optimization doesn't really provide anything new to the
originating domain, even in this case.
</t>
<t>
However, there is an attack possible when the information is divulged
to an end user. Consider a subscribing domain that doesn't actually
implement this extension at all. A user within the domain uses a
client that generates a subscription to a resource in a remote
domain. This subscription uses an outbound proxy in the watching
domain. The outbound proxy is just a proxy, and therefore doesn't
remove or modify the Supported header field in the request. The
serving domain accepts the subscription and sends an ACL that contains
the full set of subscribers that are permitted in the originating
domain. The original subscriber now knows the set of other authorized
buddies within their own domain, and what views they will see. While
this is information that the domain overall would have access to, it
is not information an end user would normally have access
to. Consequently, this is a more serious privacy violation.
</t>
<t>
It is for this reason that this specification requires that both sides
of the federated link be explicitly provisioned to utilize this
optimization. In the attack above, the subscribing domain would not have
set up a peering relationship with the serving domain. If it had, it
would have an RLS and would not have permitted the user to directly
subscribe in this way. Thus, when the subscription is received by the
serving domain, it will find that it has no agreement with the
originating domain, and would not utilize view sharing. This thwarts
the attack.
</t>
<t>
This remedy is not optimal because it requires on provisioning to
prevent. There does not appear to be any easy cryptographic means to
prevent it, however.
</t>
</section>
<section title="Privacy Considerations of the Watched Resource">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Interactions with S/MIME">
<t>
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.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
There are several IANA considerations associated with this
specification.
</t>
<section title="MIME Type Registration">
<t>
This specification requests the registration of a new MIME type
according to the procedures of <xref target="RFC2048">RFC 2048</xref>
and guidelines in <xref target="RFC3023">RFC 3023</xref>.
</t>
<list style="hanging">
<t>MIME media type name: application</t>
<t>MIME subtype name: viewshare-acl+xml</t>
<t>Mandatory parameters: none</t>
<t>Optional parameters: Same as charset parameter application/xml
as specified in <xref target="RFC3023">RFC 3023</xref>.</t>
<t>Encoding considerations: Same as encoding considerations of
application/xml as specified in <xref target="RFC3023">RFC
3023</xref>.</t>
<t>Security considerations: See Section 10 of <xref
target="RFC3023">RFC 3023</xref> and
<xref target="sec-security"/> of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification]].</t>
<t>Interoperability considerations: none.</t>
<t>Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification]]</t>
<t>Applications which use this media type: This document type has
been used to support subscriptions to <xref
target="RFC4662">lists of users</xref> for
<xref target="RFC3856">SIP-based presence</xref>.</t>
<t>Additional Information:
<list style="hanging">
<t>Magic Number: None</t>
<t>File Extension: .acl</t>
<t>Macintosh file type code: "TEXT"</t>
<t>Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net</t>
<t>Intended usage: COMMON</t>
<t>Author/Change controller: The IETF.</t>
</list>
</t>
</list>
</section>
<section title="URN Sub-Namespace Registration">
<t>This section registers a new XML namespace, as per the guidelines
in <xref target="RFC3688">RFC 3688</xref>.</t>
<list style="hanging">
<t>URI: The URI for this namespace is
urn:ietf:params:xml:ns:viewshare-acl.</t>
<t>Registrant Contact: IETF, SIMPLE working group,
(simple@ietf.org), Jonathan Rosenberg
(jdrosen@jdrosen.net).</t>
<t>XML:
<figure><artwork>
<![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>ACL Info Namespace</title>
</head>
<body>
<h1>Namespace for ACL Info</h1>
<h2>urn:ietf:params:xml:ns:viewshare-acl</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
]]></artwork></figure></t>
</list>
</section>
<section title="Schema Registration">
<t>This section registers an XML schema per the procedures in
<xref target="RFC3688"/>.
</t>
<list style="hanging">
<t>URI: urn:ietf:params:xml:schema:viewshare-acl</t>
<t>Registrant Contact: IETF, SIMPLE working group,
(simple@ietf.org), Jonathan Rosenberg
(jdrosen@jdrosen.net).</t>
<t>The XML for this schema can be found as the sole content of <xref
target="sec-schema"/>.</t>
</list>
</section>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Avshalom Houri, Richard Barnes, and
Michael Froman for their comments on this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.4662"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.RFC.2141"?>
<?rfc include="reference.RFC.2648"?>
<?rfc include="reference.RFC.3688"?>
<?rfc include="reference.RFC.2048"?>
<?rfc include="reference.RFC.3023"?>
<?rfc include="reference.W3C.REC-xml-20001006"?>
<?rfc include="reference.I-D.ietf-sip-outbound"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2778"?>
<?rfc include="reference.RFC.3863"?>
<?rfc include="reference.RFC.4479"?>
<?rfc include="reference.RFC.3856"?>
<?rfc include="reference.RFC.4480"?>
<?rfc include="reference.I-D.ietf-simple-interdomain-scaling-analysis"?>
<?rfc include="reference.I-D.ietf-simple-intradomain-federation"?>
<?rfc include="reference.I-D.ietf-sip-subnot-etags"?>
<?rfc include="reference.I-D.ietf-sipping-presence-scaling-requirements"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:46:29 |