draft-ietf-geopriv-common-policy-01.txt   draft-ietf-geopriv-common-policy-02.txt 
GEOPRIV H. Schulzrinne GEOPRIV H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: January 17, 2005 J. Morris Expires: April 5, 2005 J. Morris
CDT CDT
H. Tschofenig H. Tschofenig
J. Cuellar J. Cuellar
Siemens Siemens
J. Polk J. Polk
Cisco Cisco
J. Rosenberg J. Rosenberg
DynamicSoft DynamicSoft
July 19, 2004 October 5, 2004
A Document Format for Expressing Privacy Preferences A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-01.txt draft-ietf-geopriv-common-policy-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 January 17, 2005. This Internet-Draft will expire on April 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 controling access to application specific data. This framework
combines common location- and SIP-presence-specific authorization combines common location- and SIP-presence-specific authorization
skipping to change at page 2, line 33 skipping to change at page 2, line 33
7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Transformations . . . . . . . . . . . . . . . . . . . . . . 17 9. Transformations . . . . . . . . . . . . . . . . . . . . . . 17
10. Procedure for Combining Permissions . . . . . . . . . . . . 18 10. Procedure for Combining Permissions . . . . . . . . . . . . 18
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 18 10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 18
10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 18 10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 18
10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 19 10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 22 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 23
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 24 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . 27 14. Security Considerations . . . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
15.1 Common Policy Namespace Registration . . . . . . . . . . 28 15.1 Common Policy Namespace Registration . . . . . . . . . . 29
15.2 Common Policy Schema Registration . . . . . . . . . . . 28 15.2 Common Policy Schema Registration . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1 Normative References . . . . . . . . . . . . . . . . . . . 29 16.1 Normative References . . . . . . . . . . . . . . . . . . . 30
16.2 Informative References . . . . . . . . . . . . . . . . . . 29 16.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33
C. Enhancements to the Combining Permissions Algorithm . . . . 33 Intellectual Property and Copyright Statements . . . . . . . 34
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 33
C.2 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 36
C.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . 40
1. Introduction 1. Introduction
This document defines a framework for creating authorization policies This document defines a framework for creating authorization policies
for access to application specific data. This framework is the for access to application specific data. This framework is the
result of combining the common aspects of single authorization result of combining the common aspects of single authorization
systems that more specifically control access to presence and systems that more specifically control access to presence and
location information and that previously had been developed location information and that previously had been developed
separately. The benefit of combining these two authorization systems separately. The benefit of combining these two authorization systems
is two-fold. First, it allows to build a system which enhances the is two-fold. First, it allows to build a system which enhances the
skipping to change at page 14, line 40 skipping to change at page 14, line 40
<except>mike</except> <except>mike</except>
</identity> </identity>
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 [I-D.ietf-impp-cpim-pidf] provides the ability to inform the PS RPID [RFC3863] provides the ability to inform the PS of its current
of its current sphere. Switching from one sphere to another causes sphere. Switching from one sphere to another causes to switch
to switch between different modes of visibility. As a result between different modes of visibility. As a result different subsets
different subsets of rules might be applicable. An example of a rule of rules might be applicable. An example of a rule fragment is shown
fragment is shown below: below:
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<sphere>work</sphere> <sphere>work</sphere>
<identity> <identity>
<id>andrew@example.com</id> <id>andrew@example.com</id>
</identity> </identity>
</conditions> </conditions>
</rule> </rule>
skipping to change at page 19, line 29 skipping to change at page 19, line 29
CR 2: If d(r,n)=Integer or d(r,n)=Undefined for all r in M(n), then CR 2: If d(r,n)=Integer or d(r,n)=Undefined 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 given as follows: If v(r,n)=undefined for all r in M(n), then
V(n) is not specified by this specification. Otherwise, V(n) is not specified by this specification. Otherwise,
V(n)=max{v(r,n) | r in M(n)}. V(n)=max{v(r,n) | r in M(n)}.
CR 3: If d(r,n)=Set or d(r,n)=Undefined for all r in M(n), then V(n) CR 3: If d(r,n)=Set or d(r,n)=Undefined 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 is given as 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. computed over all r in M(n) with v(r,n)!=undefined.
It is important to note that documents enhancing this concept (and
therefore using this algorithm) should make sure that output of the
combining permissions algorithm is privacy safe. It is desirable to
reveal less than more information. Furthermore, the algorithm
considers each individual attribute independently. If there is a
dependency between different attributes then the algorithm might not
be capable of producing the 'intuitively expected' result. The
combining permissions algorithm is based set theory and protocol
designers and users should be aware of the limitations.
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.
Permission X might, for example, represent the <confirmation> action. Permission X might, for example, represent the <confirmation> action.
skipping to change at page 29, line 14 skipping to change at page 30, line 14
16. References 16. References
16.1 Normative References 16.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
16.2 Informative References 16.2 Informative References
[I-D.ietf-impp-cpim-pidf]
Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress),
May 2003, <reference.I-D.ietf-impp-cpim-pidf.xml>.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004, Polk, "Geopriv Requirements", RFC 3693, February 2004.
<reference.RFC.3693.xml>.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
USA USA
skipping to change at page 33, line 4 skipping to change at page 34, line 4
Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
Peterson <jon.peterson@neustar.biz> for discussing a number of Peterson <jon.peterson@neustar.biz> for discussing a number of
details with us. They helped us to improve the quality of this details with us. They helped us to improve the quality of this
document. document.
Furthermore, we would like to thank the IETF SIMPLE working group for Furthermore, we would like to thank the IETF SIMPLE working group for
their discussions of J. Rosenberg's draft on XCAP authorization their discussions of J. Rosenberg's draft on XCAP authorization
policies. We thank Stefan Berg, Christian Schmidt, Markus Isomaki policies. We thank Stefan Berg, Christian Schmidt, Markus Isomaki
and Eva Maria Leppanen for their comments. and Eva Maria Leppanen for their comments.
Appendix C. Enhancements to the Combining Permissions Algorithm
This section contains text, which should replace the text in Section
10, if approved by the Geopriv working group. It aims to enhance the
combining permissions algorithm to offer a better privacy protection
and to fix technical problems with the current algorithm.
C.1 Introduction
This section describes the mechanism that MUST be employed in order
to determine the actions and transformations the PS has to employ
when processing a request for privacy-sensitive data. When a PS
receives such a request, the PS MUST evaluate the set of rules
applicable to the request. According to this specification, a rule
set consists of a set of rules each of which is composed of
conditions, actions and transformations.
First of all, the PS MUST determine the set of matching rules within
the rule set. To this end, the PS MUST evaluate the conditions part
of each rule contained in the rule set. To evaluate the conditions
part of a rule means to associate either TRUE or FALSE to each
condition contained in the conditions part of the rule. A rule
matches if all conditions contained in the conditions part of a rule
evaluate to TRUE.
Secondly, the PS MUST determine the actions and transformations it
has to perform. If the set of matching rules consists of a single
rule only, then the PS MUST execute the actions and transformations
as specified in that rule. However, it can also be the case that two
or more matching rules contain a permission of the same name (e.g.,
two rules contain a permission named
'location-information-precision'), but do not specify the same value
for that permission (e.g., the two rules might specify values of '10
km' and '200 km', respectively, for the permission named
'location-information-precision'). This section describes the
procedure for combining actions and transformations in such cases.
The notion 'permission' is used herein as a generic term for 'action'
and 'transformation'.
In order to come to an executable procedure for combining
permissions, each permission definition MUST specify the name and the
data type of it. Each permission MUST be either of data type
'Boolean', 'Integer', or 'Set'. In case of 'Boolean', the permission
can have the values 'TRUE' or 'FALSE'. In case of 'Integer', the
permitted values of a permission of this type are the integer number
values. In case of 'Set', the definition of a permission of this
type MUST also include the definition of the names and the elements
of the sets that are permitted as values of such permissions.
For example, a permission named 'civil location information' that is
to specify different precision levels of civil location information
could be realized by specifying that it is of data type 'Set' and
that the set named 'level 1' consists of the elements 'country',
'city', and 'street', while the set named 'level 2' has the elements
'country' and 'city' only.
The data type 'Integer' also allows for enumerations when defining
permissions: For example, instead of using the 'Set' data type, you
could also define the permission indicating different precision
levels of civil location information by enumerating these levels
(e.g., level A, level B, ...), associating integer values to the
single enumeration values (e.g., 1, 2, ...), and specifying the
meaning of these values (e.g., level A stands for "country, city,
street", level B stands for "country, city", and so on). This does
not contradict the fact that permissions must be either of data type
'Boolean', 'Integer', or 'Set', as you MUST associate integer values
to the single enumeration values when defining permission by
enumeration.
Now, it is necessary to have a means of preserving the level of
privacy-protection when combining two permissions. The problem here
is as follows: Assume, a first matching rule contains the permission
named 'location-information-precision' of data type 'Integer' which
has been equipped with the value 1 permitting the level of location
information precision that consists of 'country', 'city' and 'street'
data. A second matching rule (which might have a different set of
conditions when compared to the first rule, but is also matching just
like the first) also comprises the permission named
'location-information-precision', but this time specifying a value of
2 admitting 'country' and 'city' level precision only.
In favor of privacy protection, it is necessary to combine these two
permissions to a rule that permits 'country' and 'city' level
location information only. Mathematically spoken and respecting the
fact that the locatin-information-precision permission had been
defined in this example in such a way that its values 1 and 2
represent lower and higher levels of pricacy protection,
respectively, it is necessary to combine these two permissions by
calculating the maximum of its single values: combined value =
maximum of single values = max{1,2} = 2 = 'country' and 'city' level
of precision.
However, the 'location-information-precision' permission could have
been specified in another way as well: the value of 1 could have been
made representing 'country' and 'city' only, while the value of 2
could represent 'country', 'city' and 'street'. Now, it were
necessary to combine these two rules by calculating the minimum and
not the maximum of the single value. Similar problems occur also for
the permission data types 'Boolean' and 'Set'.
Computer programs responsible for combining permissions must
therefore get indicated which algorithm is to be employed when
combining a permission of a given name. This is accomplished by the
requirement that each permission definition has not only to specify
its name and data type but also exactly one of the following six
combining rules (CRs):
CR-Boolean-Or
CR-Boolean-And
CR-Integer-Minimum
CR-Integer-Maximum
CR-Set-Intersection
CR-Set-Union
What these combining rules actually mean from the algorithmic
perspective will be detailed in the next paragraph. From the XML
point of view, authors of XML policy languages that are to be
integrated under the roof of the common policy framework MUST use the
XML built-in element <appinfo> when defining new permissions in XML
schemas and equip this element with one of the six character strings
above representing one of the six possible combining rules. This
approach guarantees that each computer program that has access to the
XML schema specifying a certain policy language within the common
policy framework can apply the combining rule that is specified by
the permission definition's child element <appinfo>.
To give an example: A location information-specific XML policy
language might define a permission named 'latitude-resolution' of
data type 'Integer' which is to indicate the number of digits
permitted to be sent to a certain set of receivers. In order to
fulfill the requirement discussed above, the XML schema defining that
policy language should specify the 'latitude-resolution'
transformation as follows:
<xs:element name="latitude-resolution"
type="xs:integer"
substitutionGroup="cp:transformation">
<xs:annotation>
<xs:appinfo>
CR-Integer-Minimum
</xs:appinfo>
</xs:annotation>
</xs:element>
C.2 Algorithms
This section describes the algorithms for the six possible combining
rules in a formal fashion.
The combining rules are simple and depend on the data types of the
values of permissions: Let P be a policy, i.e., a rule set. Let M be
the subset of P consisting of rules r in P that match with respect to
a given request. Let n be a name of a permission contained in a rule
r in M, D(n) be the data type of the permissions of name n, and let
M(n) be the subset of M consisting of rules r in M that have a
permission of name n. For each rule r in M(n), let v(r,n) be the
value of the permission of name n contained in the rule r. Finally,
let CV(n) be the combined value of all the permissions values v(r,n),
r in M(n). The combining rules CR-Boolean-Or, CR-Boolean-And,
CR-Integer-Minimum, CR-Integer-Maximum, CR-Set-Intersection and
CR-Set-Union MUST be implemented as follows:
CR-Boolean-Or: This CR is applicable only if D(n)=Boolean:
CV(n)=Or{v(r,n) | r in M(n)}. This means: CV(n)=TRUE if and only
if there is a value v(r,n), r in M(n), with v(r,n)=TRUE.
CR-Boolean-And: This CR is applicable only if D(n)=Boolean:
CV(n)=And{v(r,n) | r in M(n)}. This means: CV(n)=TRUE if and only
if for all r in M(n): v(r,n)=TRUE.
CR-Integer-Minimum: This CR is applicable only if D(n)=Integer:
CV(n)=Minimum{v(r,n) | r in M(n)}.
CR-Integer-Maximum: This CR is applicable only if D(n)=Integer:
CV(n)=Maximum{v(r,n) | r in M(n)}.
CR-Set-Intersection: This CR is applicable only if D(n)=Set:
CV(n)=Intersection{v(r,n) | r in M(n)}.
CR-Set-Union: This CR is applicable only if D(n)=Set:
CV(n)=Union{v(r,n) | r in M(n)}.
C.3 Example
In the following example we illustrate the process of combining
permissions. We will consider three conditions for our purpose,
namely those of name identity, sphere, and validity. For editorial
reasons the rule set in this example is represented in a table.
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
X and Y are of data types Boolean and Integer, respectively. The
combining rules that must be employed when combining values of X and
Y are CR-Boolean-Or and CR-Integer-Maximum, respectively.
For transformations we use the permission with the name Z whose value
can be set either to '-'(or 1), 'o' (or 2) or '+' (or 3). Its
combining rule is CR-Integer-Minimum. Permission Z allows us to show
the granularity reduction whereby a value of '+' shows the
corresponding information unrestricted and '-' shows nothing. This
permission might be related to location information or other presence
attributes like mood. Internally we use the data type Integer for
computing the permission of this attribute.
Conditions Actions/Transformations
+--------------------------------+---------------------+
| Id WR-ID sphere from to | X Y Z |
+--------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | undef 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+--------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for
values of the two <validity> attributes 'from' and 'to':
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
The entity 'bob' acts as a WR and requests data items. The policy P
consists of the six rules shown in the table and identified by the
values 1 to 6 in the 'Id' column. The PS receives the query at
2003-12-24T17:15:00+01:00. The value of the attribute with name
'sphere' indicating the state the PT is currently in is set to
'work'.
Rule 1 does not match since the sphere condition does not match.
Rule 2 does not match as the identity of the WR (here 'alice') does
not equal 'bob'. Rule 3 matches since all conditions evaluate to
TRUE. Rule 4 does not match as the identity of the WR (here 'tom')
does not equal 'bob'. Rule 5 matches. Rule 6 does not match since
the rule is not valid anymore. Therefore, the set M of matching
rules consists of the rules 3 and 5. These two rules are used to
compute the combined permission values CV(X), CV(Y), and CV(Z) for
each of the permissions X, Y, and Z:
Actions/Transformations/Combining Rules
+-----------------------------------------------------------+
| X Y Z |
+-----------------------------------------------------------+
| TRUE 3 - (1) |
| undef 12 o (2) |
| CR-Boolean-Or CR-Integer-Maximum CR-Integer-Minimum |
+-----------------------------------------------------------+
The results of the permission combining algorithms are shown below.
The combined value CV(X) regarding the permission with name X equals
TRUE according to its combining rule CR-Boolean-Or. The maximum of 3
and 12 is 12, so that CV(Y)=12. For the attribute Z in this example,
the minimum between '-' and 'o' (i.e., between 1 and 2) is '-'.
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 - (1) |
+-----------------------+
Documents that extend the authorization policy framework defined here
by introducing application specific actions and transformations MUST
NOT define permissions whose values are of data type other than
Boolean, Integer, and Set. At least, the actual data type used in
the permission definition MUST be representable by means of these
three data types. In such cases, the mapping between the data type
used and one of the three standard data types Boolean, Integer, and
Set MUST be given explicitly when using another permission data type
(such as an enumeration data type or the data type that consists of
the values '-', 'o' and '+' as illustrated above).
Furthermore, permissions and the meaning of their values MUST be
defined in such a way that the application of one of the six
combining rules specified in this section actually preserves the
level of privacy protection when determining combined values of
single permission values contained in several matching rules. For
example, this requirement implies that permission values of data type
'Integer' are ordered in such a way that either lower values
correspond to lower privacy protection levels and higher values to
higher levels, or vice versa. However, the value 1 MUST NOT
correspond to a medium level of privacy protection, 3 to a lower and
2 to a higher, for instance, so that neither the application of
CR-Integer-Minimum nor of CR-Integer-Maximum would result in
reasonable, privacy-protecting combined value.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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