draft-ietf-geopriv-common-policy-07.txt   draft-ietf-geopriv-common-policy-08.txt 
GEOPRIV H. Schulzrinne GEOPRIV H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: August 15, 2006 J. Morris Expires: September 6, 2006 J. Morris
CDT CDT
H. Tschofenig H. Tschofenig
J. Cuellar J. Cuellar
Siemens Siemens
J. Polk J. Polk
Cisco Cisco
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
February 11, 2006 March 5, 2006
A Document Format for Expressing Privacy Preferences A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-07.txt draft-ietf-geopriv-common-policy-08.txt
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 42 skipping to change at page 1, line 42
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 August 15, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a framework for authorization policies This document defines a framework for authorization policies
controling access to application specific data. This framework controlling access to application specific data. This framework
combines common location- and presence-specific authorization combines common location- and presence-specific authorization
aspects. An XML schema specifies the language in which common policy aspects. An XML schema specifies the language in which common policy
rules are represented. The common policy framework can be extended rules are represented. The common policy framework can be extended
to other application domains. to other application domains.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 7 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 4, line 25 skipping to change at page 4, line 25
reuses the same underlying authorization mechanism. Second, it reuses the same underlying authorization mechanism. Second, it
encourages a more generic authorization framework with mechanisms for encourages a more generic authorization framework with mechanisms for
extensibility. The applicability of the framework specified in this extensibility. The applicability of the framework specified in this
document is not limited to policies controling access to presence and document is not limited to policies controling access to presence and
location information data, but can be extended to other application location information data, but can be extended to other application
domains. domains.
The general framework defined in this document is intended to be The general framework defined in this document is intended to be
accompanied and enhanced by application-specific policies specified accompanied and enhanced by application-specific policies specified
elsewhere. The common policy framework described here is enhanced by elsewhere. The common policy framework described here is enhanced by
domain-speific policy documents, including presence [6] and domain-speific policy documents, including presence [6] and location
location[7]. This relationship is shown inFigure 1. [7]. This relationship is shown in Figure 1.
+-----------------+ +-----------------+
| | | |
| Common | | Common |
| Policy | | Policy |
| | | |
+---+---------+---+ +---+---------+---+
/|\ /|\ /|\ /|\
| | | |
+-------------------+ | | +-------------------+ +-------------------+ | | +-------------------+
skipping to change at page 6, line 26 skipping to change at page 6, line 26
RM - Rule Maker: RM is an entity which creates the authorization RM - Rule Maker: RM is an entity which creates the authorization
rules which restrict access to data items. rules which restrict access to data items.
PS - (Authorization) Policy Server: This entity has access to both PS - (Authorization) Policy Server: This entity has access to both
the authorization policies and to the data items. In location- the authorization policies and to the data items. In location-
specific applications, the entity PS is labeled as location server specific applications, the entity PS is labeled as location server
(LS). (LS).
WR - Watcher / Recipient: This entity requests access to data items WR - Watcher / Recipient: This entity requests access to data items
of the PT. An access operation might be either be a read, write of the PT. An access operation might be either be a read, write
or any other operation. In case of access to location information or be any other operation. In case of access to location
it might be a read operation. information it might be a read operation.
An 'authorization policy' is given by a 'rule set'. A 'rule set' An 'authorization policy' is given by a 'rule set'. A 'rule set'
contains an unordered list of 'rules'. A 'rule' has a 'conditions', contains an unordered list of 'rules'. A 'rule' has a 'conditions',
an 'actions' and a 'transformations' part. an 'actions' and a 'transformations' part.
The term 'permission' indicates the action and transformation The term 'permission' indicates the action and transformation
components of a 'rule'. components of a 'rule'.
The terms 'authorization policy', 'policy' and 'rule set' are used The terms 'authorization policy', 'policy' and 'rule set' are used
interchangeably. interchangeably.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
Below, we summarize our design goals and constraints. Below, we summarize our design goals and constraints.
Table representation: Table representation:
Each rule must be representable as a row in a relational database. Each rule must be representable as a row in a relational database.
This design goal should allow efficient policy rule implementation This design goal should allow efficient policy rule implementation
by utilizing standard database optimization techniques. by utilizing standard database optimization techniques.
Permit only: Permit only:
Rules only provide permissions rather than denying them. Allowing Rules only provide permissions rather than denying them. Removing
both 'permit' and 'deny' actions would require some rule ordering a rule can never increase permissions. Allowing both 'permit' and
which had implications on the update operations executed on these 'deny' actions would require some rule ordering which had
rules. Additionally it would make distributed rule sets more implications on the update operations executed on these rules.
Additionally, it would make distributed rule sets more
complicated. Hence, only 'permit' actions are allowed which complicated. Hence, only 'permit' actions are allowed which
result in more efficient rule processing. This also implies that result in more efficient rule processing. This also implies that
rule ordering is not important. Consequently, to make a policy rule ordering is not important. Consequently, to make a policy
decision requires processing all policy rules. decision requires processing all policy rules.
Additive permissions: Additive permissions:
A query for access to data items is matched against the rules in A query for access to data items is matched against the rules in
the rule database. If several rules match, then the overall the rule database. If several rules match, then the overall
permissions granted to the WR are the union of those permissions. permissions granted to the WR are the union of those permissions.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
versions may include these capabilities, using the extension versions may include these capabilities, using the extension
mechanism described in this document. Non-goals include: mechanism described in this document. Non-goals include:
No external references: No external references:
Attributes within specific rules cannot refer to external rule Attributes within specific rules cannot refer to external rule
sets, databases, directories or other network elements. Any such sets, databases, directories or other network elements. Any such
external reference would make simple database implementation external reference would make simple database implementation
difficult and hence they are not supported in this version. difficult and hence they are not supported in this version.
No regular expression or wildcard matching: No regular expression:
Conditions are matched on equality or 'greater-than'-style Conditions are matched on equality or 'greater-than'-style
comparisons, not regular expressions, partial matches such as the comparisons, not regular expressions, partial matches such as the
SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches
("*@example.com"). Most of these are better expressed as explicit ("*@example.com"). Most of these are better expressed as explicit
elements. elements.
No all-except conditions:
It is not possible to express exclusion conditions based on
identities such as "everybody except Alice". However, this
restriction does not prevent all forms of blacklisting. It is
still possible to express an authorization rule like 'I allow
access to my location information for everyone of domain
example.com except for John'. See the example in Section 7.1
describing how exceptions can be made to work. The reason for
this choice is the ease with which identities can be manufactured,
and the implication that all-except types of rules are easily
subverted.
No repeat times: No repeat times:
Repeat times are difficult to make work correctly, due to the Repeat times (e.g., every day from 9am to 4pm) are difficult to
different time zones that PT, WR, PS and RM may occupy. It make work correctly, due to the different time zones that PT, WR,
appears that suggestions for including time intervals are often PS and RM may occupy. It appears that suggestions for including
based on supporting work/non-work distinctions, which time intervals are often based on supporting work/non-work
unfortunately are difficult to capture by time alone. distinctions, which unfortunately are difficult to capture by time
alone. Note that this feature must not be confused with the
'Validity' element that provides a mechanism to restrict the
lifetime of a rule.
6. Basic Data Model and Processing 6. Basic Data Model and Processing
A rule set (or synonymously, a policy) consists of zero or more A rule set (or synonymously, a policy) consists of zero or more
rules. The ordering of these rules is irrelevant. The rule set can rules. The ordering of these rules is irrelevant. The rule set can
be stored at the PS and conveyed from RM to PS as a single document, be stored at the PS and conveyed from RM to PS as a single document,
in subsets or as individual rules. A rule consists of three parts - in subsets or as individual rules. A rule consists of three parts -
conditions (see Section 7), actions (see Section 8), and conditions (see Section 7), actions (see Section 8), and
transformations (see Section 9). transformations (see Section 9).
skipping to change at page 12, line 48 skipping to change at page 12, line 48
PS processes a request, it takes the transformations specified across PS processes a request, it takes the transformations specified across
all rules that match, and creates the union of them. For computing all rules that match, and creates the union of them. For computing
this union the data type, such as Integer, Boolean, Set, or the Undef this union the data type, such as Integer, Boolean, Set, or the Undef
data type, plays a role. The details of the algorithm for combining data type, plays a role. The details of the algorithm for combining
permissions is described in Section 10. The resulting union permissions is described in Section 10. The resulting union
effectively represents a "mask" - it defines what information is effectively represents a "mask" - it defines what information is
exposed to the WR. This mask is applied to the actual location or exposed to the WR. This mask is applied to the actual location or
presence data for the PT, and the data which is permitted by the mask presence data for the PT, and the data which is permitted by the mask
is shown to the WR. If the WR request a subset of information only is shown to the WR. If the WR request a subset of information only
(such as city-level civil location data only, instead of the full (such as city-level civil location data only, instead of the full
civil location information), the information delivered to the WR civil location information), the information delivered to the WR MUST
SHOULD be the intersection of the permissions granted to the WR and be the intersection of the permissions granted to the WR and the data
the data requested by the WR. requested by the WR.
In accordance to this document, rules are encoded in XML. To this In accordance to this document, rules are encoded in XML. To this
end, Section 13 contains an XML schema defining the Common Policy end, Section 13 contains an XML schema defining the Common Policy
Markup Language. This, however, is purely an exchange format between Markup Language. This, however, is purely an exchange format between
RM and PS. The format does not imply that the RM or the PS use this RM and PS. The format does not imply that the RM or the PS use this
format internally, e.g., in matching a query with the policy rules. format internally, e.g., in matching a query with the policy rules.
The rules are designed so that a PS can translate the rules into a The rules are designed so that a PS can translate the rules into a
relational database table, with each rule represented by one row in relational database table, with each rule represented by one row in
the database. The database representation is by no means mandatory; the database. The database representation is by no means mandatory;
we will use it as a convenient and widely-understood example of an we will use it as a convenient and widely-understood example of an
skipping to change at page 14, line 30 skipping to change at page 14, line 30
The identity condition restricts matching of a rule either to a The identity condition restricts matching of a rule either to a
single entity or a group of entitites. Only authenticated entities single entity or a group of entitites. Only authenticated entities
can be matched; acceptable means of authentication are defined in can be matched; acceptable means of authentication are defined in
protocol-specific documents. As usual, if the <identity> element is protocol-specific documents. As usual, if the <identity> element is
(or all its child elements are) omitted, identities are not (or all its child elements are) omitted, identities are not
considered and, thus, the condition matches any user, authenticated considered and, thus, the condition matches any user, authenticated
or not. or not.
The <identity> condition is considered TRUE if any of its child The <identity> condition is considered TRUE if any of its child
elements (i.e., the <one/> and the <many/> elements as defined in elements (e.g., the <one/> and the <many/> elements defined in this
this document) evaluate to TRUE, i.e., the results of the individual document) evaluate to TRUE, i.e., the results of the individual child
child element are combined using a logical OR. element are combined using a logical OR.
7.1.2. Matching One Entity 7.1.2. Matching One Entity
The <one> element matches the authenticated identity (as contained in The <one> element matches the authenticated identity (as contained in
the 'id' attribute) of exactly one entity or user. For the 'id' attribute) of exactly one entity or user. For
considerations regarding the 'id' attribute refer to Section 7.1.3. considerations regarding the 'id' attribute refer to Section 7.1.3.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 15, line 30 skipping to change at page 15, line 30
</ruleset> </ruleset>
This example matches if the authenticated identity of the WR is This example matches if the authenticated identity of the WR is
either sip:alice@example.com, tel:+1-212-555-1234 or either sip:alice@example.com, tel:+1-212-555-1234 or
mailto:bob@example.net. mailto:bob@example.net.
7.1.3. Single Entity 7.1.3. Single Entity
The 'id' attribute used in the <one> and in the <except> element The 'id' attribute used in the <one> and in the <except> element
refers to a single entity. In the subsequent text we use the term refers to a single entity. In the subsequent text we use the term
'single-user' element as a placeholder for the <one> and the <except> 'single-user' entity as a placeholder for the <one> and the <except>
element. element. The <except> element fulfills the purpose of excluding
elements from the solution set.
The <single-user> element matches the authenticated identity (as A single-user entity matches the authenticated identity (as contained
contained in the 'id' attribute) of exactly one entity or user. The in the 'id' attribute) of exactly one entity or user. The single-
<single-user> element MUST NOT contain a 'domain' attribute. user entity MUST NOT contain a 'domain' attribute.
The 'id' attribute contains an identity that MUST first be expressed The 'id' attribute contains an identity that MUST first be expressed
as a URI. Applications using this framework must describe how the as a URI. Applications using this framework must describe how the
identities they are using can be expressed as a URIs. identities they are using can be expressed as a URIs.
7.1.4. Matching Multiple Entities 7.1.4. Matching Multiple Entities
The <many> element is a mechanism to perform authorization decisions The <many> element is a mechanism to perform authorization decisions
based on the domain part of the authenticated identity. As such, it based on the domain part of the authenticated identity. As such, it
allows to match a large and possibly unknown number of users within a allows to match a large and possibly unknown number of users within a
skipping to change at page 16, line 36 skipping to change at page 16, line 37
3. Convert both domain strings using the toASCII operation described 3. Convert both domain strings using the toASCII operation described
in RFC 3490 [2]. (Naturally, if one of the strings already in RFC 3490 [2]. (Naturally, if one of the strings already
begins with the ACE prefix xn--, the conversion operation has begins with the ACE prefix xn--, the conversion operation has
already been performed.) already been performed.)
4. Compare the two domain strings for ASCII equality, for each 4. Compare the two domain strings for ASCII equality, for each
label. label.
If the conversion fails in step (3), the domains are not equal. If the conversion fails in step (3), the domains are not equal.
7.1.4.1. Matching Any Authenticated Entity 7.1.4.1. Matching Any Authenticated Identity
The <many/> element without any child elements or attributes matches The <many/> element without any child elements or attributes matches
any authenticated user. any authenticated user.
The following example shows such a rule that matches any The following example shows such a rule that matches any
authenticated user: authenticated user:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
skipping to change at page 17, line 36 skipping to change at page 17, line 36
<rule id="f3g44r5"> <rule id="f3g44r5">
<conditions> <conditions>
<identity/> <identity/>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
7.1.4.2. Matching Any Identity Excepting Enumerated Domains and 7.1.4.2. Matching Any Authenticated Identity Excepting Enumerated
Identities Domains/Identities
The <many> element enclosing one or more <except domain="..."/> The <many> element enclosing one or more <except domain="..."/>
elements matches any user from any domain except those enumerated. elements matches any user from any domain except those enumerated.
The <except id="..."/> element excludes particular users. The The <except id="..."/> element excludes particular users. The
semantic of the 'id' attribute of the <except> element is described semantic of the 'id' attribute of the <except> element is described
in Section 7.1.3. The results of the child elements of the <many> in Section 7.1.3. The results of the child elements of the <many>
element are combined using a logical OR. element are combined using a logical OR.
An example is shown below: An example is shown below:
skipping to change at page 18, line 38 skipping to change at page 18, line 38
</rule> </rule>
</ruleset> </ruleset>
This example matches all users except any user in example.com, or any This example matches all users except any user in example.com, or any
user in example.org or the particular users alice@bad.example.net, user in example.org or the particular users alice@bad.example.net,
bob@good.example.net and the user with the telephone number bob@good.example.net and the user with the telephone number
'tel:+1-212-555-1234'. The last 'except' element is redundant since 'tel:+1-212-555-1234'. The last 'except' element is redundant since
alice@example.com is already excluded through the first line. alice@example.com is already excluded through the first line.
7.1.4.3. Matching Any Identity Within a Domain Excepting Enumerated 7.1.4.3. Matching Any Authenticated Identity Within a Domain Excepting
Identities Enumerated Identities
The <many> element with a 'domain' attribute and zero or more <except The <many> element with a 'domain' attribute and zero or more <except
id="..."/> elements matches any authenticated user from the indicated id="..."/> elements matches any authenticated user from the indicated
domain except those explicitly enumerated. The semantic of the 'id' domain except those explicitly enumerated. The semantic of the 'id'
attribute of the <except> element is described in Section 7.1.3. attribute of the <except> element is described in Section 7.1.3.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
skipping to change at page 19, line 36 skipping to change at page 19, line 36
7.2. Sphere 7.2. Sphere
The <sphere> element belongs to the group of condition elements. It The <sphere> element belongs to the group of condition elements. It
can be used to indicate a state (e.g., 'work', 'home', 'meeting', can be used to indicate a state (e.g., 'work', 'home', 'meeting',
'travel') the PT is currently in. A sphere condition matches only if 'travel') the PT is currently in. A sphere condition matches only if
the PT is currently in the state indicated. The state may be the PT is currently in the state indicated. The state may be
conveyed by manual configuration or by some protocol. For example, conveyed by manual configuration or by some protocol. For example,
RPID [9] provides the ability to inform the PS of its current sphere. RPID [9] provides the ability to inform the PS of its current sphere.
The application domain needs to describe in more detail how the The application domain needs to describe in more detail how the
sphere state is determined. Switching from one sphere to another sphere state is determined. Switching from one sphere to another
causes to switch between different modes of visibility. As a result causes a switch between different modes of visibility. As a result
different subsets of rules might be applicable. different subsets of rules might be applicable.
The content of the 'value' attribute of the <sphere> element MAY The content of the 'value' attribute of the <sphere> element MAY
contain more than one token. The individual tokens MUST be separated contain more than one token. The individual tokens MUST be separated
by a blank character. A logical OR is used for the matching the by a blank character. A logical OR is used for the matching the
tokens against the sphere settings of the PT. As an example, if the tokens against the sphere settings of the PT. As an example, if the
the content of the 'value' attribute in the sphere attribute contains the content of the 'value' attribute in the sphere attribute contains
two tokens 'work' and 'home' then this part of the rule matches if two tokens 'work' and 'home' then this part of the rule matches if
the sphere for a particular PT is either 'work' OR 'home'. To the sphere for a particular PT is either 'work' OR 'home'. To
compare the content of the 'value' attribute in the <sphere> element compare the content of the 'value' attribute in the <sphere> element
skipping to change at page 20, line 33 skipping to change at page 20, line 33
<one id="sip:allison@example.com"/> <one id="sip:allison@example.com"/>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
<rule id="z6y55r2"> <rule id="z6y55r2">
<conditions> <conditions>
<identity> <identity>
<one id="sip:john@doe.com"/> <one id="sip:john@doe.example.com"/>
</identity> </identity>
<sphere value="home work"/> <sphere value="home work"/>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
The rule example above illustrates that the rule with the entity The rule example above illustrates that the rule with the entity
andrew@example.com matches if the sphere is been set to 'work'. In andrew@example.com matches if the sphere is been set to 'work'. In
the second rule with the entity allison@example.com matches if the the second rule with the entity allison@example.com matches if the
sphere is set to 'home'. sphere is set to 'home'. The third rule also matches since the the
value in the sphere element also contains the token 'home'.
7.3. Validity 7.3. Validity
The <validity> element is the third condition element specified in The <validity> element is the third condition element specified in
this document. It expresses the rule validity period by two this document. It expresses the rule validity period by two
attributes, a starting and a ending time. The validity condition is attributes, a starting and a ending time. The validity condition is
TRUE if the current time is greater than or equal to at least one TRUE if the current time is greater than or equal to at least one
<from> child, but less than the <until> child after it. This <from> child, but less than the <until> child after it. This
represents a logical OR operation across each <from> and <until> represents a logical OR operation across each <from> and <until>
pair. Times are expressed in XML dateTime format. A rule maker pair. Times are expressed in XML dateTime format. A rule maker
skipping to change at page 24, line 18 skipping to change at page 24, line 18
This section describes the mechanism to evaluate the final result of This section describes the mechanism to evaluate the final result of
a rule evaluation. The result is reflected in the action and a rule evaluation. The result is reflected in the action and
transformation part of a rule. This procedure is sometimes referred transformation part of a rule. This procedure is sometimes referred
as conflict resolution. as conflict resolution.
We use the following terminology (which in parts has already been We use the following terminology (which in parts has already been
introduced in previous sections): The term 'permission' stands for an introduced in previous sections): The term 'permission' stands for an
action or a transformation. The notion 'attribute' terms a action or a transformation. The notion 'attribute' terms a
condition, an action, or a transformation. An attribute has a name, condition, an action, or a transformation. An attribute has a name,
has a certain data type. A value may be assigned to an attribute or and a certain data type. A value may be assigned to an attribute or
it may be undefined, in case it does not have a value associated with it may be undefined, in case it does not have a value associated with
the attribute. For example, the name of the <sphere> attribute the attribute. For example, the name of the <sphere> attribute
discussed in Section 7 is 'sphere', its data type is 'string', and discussed in Section 7 is 'sphere', its data type is 'string', and
its value may be set to 'home'. To evaluate a condition means to its value may be set to 'home'. To evaluate a condition means to
associate either TRUE or FALSE to the condition. Please note that associate either TRUE or FALSE to the condition. Please note that
the <identity> element is a condition whereas the <id> element is a the <identity> element is a condition whereas the <id> element is a
parameter of that condition. A rule matches if all conditions parameter of that condition. A rule matches if all conditions
contained in the conditions part of a rule evaluate to TRUE. contained in the conditions part of a rule evaluate to TRUE.
When the PS receives a request for access to privacy-sensitive data When the PS receives a request for access to privacy-sensitive data
skipping to change at page 25, line 20 skipping to change at page 25, line 20
CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as
follows: If v(r,n)=undefined for all r in M(n), then V(n) is not follows: If v(r,n)=undefined for all r in M(n), then V(n) is not
specified by this specification. Otherwise, V(n)=max{v(r,n) | r specified by this specification. Otherwise, V(n)=max{v(r,n) | r
in M(n)}. in M(n)}.
CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as
follows: V(n)=union of all v(r,n), the union to be computed over all follows: V(n)=union of all v(r,n), the union to be computed over all
r in M(n) with v(r,n)!=undefined. r in M(n) with v(r,n)!=undefined.
The combining operation will result in the largest value for an The combining operation will result in the largest value for an
Integral type, the Or operation for boolean, and union for set. Integral type, the OR operation for boolean, and union for set.
As a result, applications should define values such that, for As a result, applications should define values such that, for
integers, the lowest value corresponds to the most privacy, for integers, the lowest value corresponds to the most privacy, for
booleans, false corresponds to the most privacy, and for sets, the booleans, false corresponds to the most privacy, and for sets, the
empty set corresponds to the most privacy. More empty set corresponds to the most privacy.
10.3. Example 10.3. Example
In the following example we illustrate the process of combining In the following example we illustrate the process of combining
permissions. We will consider three conditions for our purpose, permissions. We will consider three conditions for our purpose,
namely those of name identity, sphere, and validity. For editorial namely those of name identity, sphere, and validity. For editorial
reasons the rule set in this example is represented in a table. reasons the rule set in this example is represented in a table.
Furthermore, the domain part of the identity of the WR is omitted. Furthermore, the domain part of the identity of the WR is omitted.
For actions we use two permissions with names X and Y. The values of For actions we use two permissions with names X and Y. The values of
X and Y are of data types Boolean and Integer, respectively. X and Y are of data types Boolean and Integer, respectively.
skipping to change at page 37, line 33 skipping to change at page 37, line 33
RFC 3023, January 2001. RFC 3023, January 2001.
16.2. Informative References 16.2. Informative References
[6] Rosenberg, J., "Presence Authorization Rules", [6] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-04 (work in progress), draft-ietf-simple-presence-rules-04 (work in progress),
October 2005. October 2005.
[7] Schulzrinne, H., "A Document Format for Expressing Privacy [7] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information", Preferences for Location Information",
draft-ietf-geopriv-policy-07 (work in progress), October 2005. draft-ietf-geopriv-policy-08 (work in progress), February 2006.
[8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9] Schulzrinne, H., "RPID: Rich Presence Extensions to the [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", Presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-10 (work in progress), December 2005. draft-ietf-simple-rpid-10 (work in progress), December 2005.
[10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
 End of changes. 25 change blocks. 
55 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/