summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4745.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4745.txt')
-rw-r--r--doc/rfc/rfc4745.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc4745.txt b/doc/rfc/rfc4745.txt
new file mode 100644
index 0000000..8e4f15d
--- /dev/null
+++ b/doc/rfc/rfc4745.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group H. Schulzrinne
+Request for Comments: 4745 Columbia U.
+Category: Standards Track H. Tschofenig
+ Siemens Networks GmbH & Co KG
+ J. Morris
+ CDT
+ J. Cuellar
+ Siemens
+ J. Polk
+ J. Rosenberg
+ Cisco
+ February 2007
+
+
+ Common Policy: A Document Format for Expressing Privacy Preferences
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document defines a framework for authorization policies
+ controlling access to application-specific data. This framework
+ combines common location- and presence-specific authorization
+ aspects. An XML schema specifies the language in which common policy
+ rules are represented. The common policy framework can be extended
+ to other application domains.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 1]
+
+RFC 4745 Common Policy February 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Modes of Operation ..............................................4
+ 3.1. Passive Request-Response - PS as Server (Responder) ........5
+ 3.2. Active Request-Response - PS as Client (Initiator) .........5
+ 3.3. Event Notification .........................................5
+ 4. Goals and Assumptions ...........................................6
+ 5. Non-Goals .......................................................7
+ 6. Basic Data Model and Processing .................................8
+ 6.1. Identification of Rules ....................................9
+ 6.2. Extensions .................................................9
+ 7. Conditions .....................................................10
+ 7.1. Identity Condition ........................................10
+ 7.1.1. Overview ...........................................10
+ 7.1.2. Matching One Entity ................................11
+ 7.1.3. Matching Multiple Entities .........................11
+ 7.2. Single Entity .............................................14
+ 7.3. Sphere ....................................................15
+ 7.4. Validity ..................................................16
+ 8. Actions ........................................................17
+ 9. Transformations ................................................18
+ 10. Procedure for Combining Permissions ...........................18
+ 10.1. Introduction .............................................18
+ 10.2. Combining Rules (CRs) ....................................18
+ 10.3. Example ..................................................19
+ 11. Meta Policies .................................................21
+ 12. Example .......................................................21
+ 13. XML Schema Definition .........................................22
+ 14. Security Considerations .......................................25
+ 15. IANA Considerations ...........................................25
+ 15.1. Common Policy Namespace Registration .....................25
+ 15.2. Content-type Registration for
+ 'application/auth-policy+xml' ............................26
+ 15.3. Common Policy Schema Registration ........................27
+ 16. References ....................................................27
+ 16.1. Normative References .....................................27
+ 16.2. Informative References ...................................28
+ Appendix A. Contributors ..........................................29
+ Appendix B. Acknowledgments .......................................29
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 2]
+
+RFC 4745 Common Policy February 2007
+
+
+1. Introduction
+
+ This document defines a framework for creating authorization policies
+ for access to application-specific data. This framework is the
+ result of combining the common aspects of single authorization
+ systems that more specifically control access to presence and
+ location information and that previously had been developed
+ separately. The benefit of combining these two authorization systems
+ is two-fold. First, it allows building a system that enhances the
+ value of presence with location information in a natural way and
+ reuses the same underlying authorization mechanism. Second, it
+ encourages a more generic authorization framework with mechanisms for
+ extensibility. The applicability of the framework specified in this
+ document is not limited to policies controlling access to presence
+ and location information data, but can be extended to other
+ application domains.
+
+ The general framework defined in this document is intended to be
+ accompanied and enhanced by application-specific policies specified
+ elsewhere. The common policy framework described here is enhanced by
+ domain-specific policy documents, including presence [7] and location
+ [8]. This relationship is shown in Figure 1.
+
+ +-----------------+
+ | |
+ | Common |
+ | Policy |
+ | |
+ +---+---------+---+
+ /|\ /|\
+ | |
+ +-------------------+ | | +-------------------+
+ | | | enhance | | |
+ | Location-specific | | | | Presence-specific |
+ | Policy |----+ +----| Policy |
+ | | | |
+ +-------------------+ +-------------------+
+
+ Figure 1: Common Policy Enhancements
+
+ This document starts with an introduction to the terminology in
+ Section 2, an illustration of basic modes of operation in Section 3,
+ a description of goals (see Section 4) and non-goals (see Section 5)
+ of the policy framework, followed by the data model in Section 6.
+ The structure of a rule, namely, conditions, actions, and
+ transformations, is described in Sections 7, 8, and 9. The procedure
+ for combining permissions is explained in Section 10 and used when
+ conditions for more than one rule are satisfied. A short description
+
+
+
+Schulzrinne, et al. Standards Track [Page 3]
+
+RFC 4745 Common Policy February 2007
+
+
+ of meta policies is given in Section 11. An example is provided in
+ Section 12. The XML schema will be discussed in Section 13. IANA
+ considerations in Section 15 follow security considerations in
+ Section 14.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [1].
+
+ This document introduces the following terms:
+
+ PT - Presentity / Target: The PT is the entity about whom
+ information has been requested.
+
+ RM - Rule Maker: The RM is an entity that creates the authorization
+ rules that restrict access to data items.
+
+ PS - (Authorization) Policy Server: This entity has access to both
+ the authorization policies and the data items. In location-
+ specific applications, the entity PS is labeled as location
+ server (LS).
+
+ WR - Watcher / Recipient: This entity requests access to data items
+ of the PT. An access operation might be a read, a write, or any
+ other operation.
+
+ A policy is given by a 'rule set' that contains an unordered list of
+ 'rules'. A 'rule' has a 'conditions', an 'actions', and a
+ 'transformations' part.
+
+ The term 'permission' indicates the action and transformation
+ components of a 'rule'.
+
+ The term 'using protocol' is defined in [9]. It refers to the
+ protocol used to request access to and to return privacy-sensitive
+ data items.
+
+3. Modes of Operation
+
+ The abstract sequence of operations can roughly be described as
+ follows. The PS receives a query for data items for a particular PT,
+ via the using protocol. The using protocol (or more precisely, the
+ authentication protocol) provides the identity of the requestor,
+ either at the time of the query or at the subscription time. The
+ authenticated identity of the WR, together with other information
+ provided by the using protocol or generally available to the server,
+
+
+
+Schulzrinne, et al. Standards Track [Page 4]
+
+RFC 4745 Common Policy February 2007
+
+
+ is then used for searching through the rule set. All matching rules
+ are combined according to a permission combining algorithm described
+ in Section 10. The combined rules are applied to the application
+ data, resulting in the application of privacy based on the
+ transformation policies. The resulting application data is returned
+ to the WR.
+
+ Three different modes of operation can be distinguished:
+
+3.1. Passive Request-Response - PS as Server (Responder)
+
+ In a passive request-response mode, the WR queries the PS for data
+ items about the PT. Examples of protocols following this mode of
+ operation include HTTP, FTP, LDAP, finger, and various remote
+ procedure call (RPC) protocols, including Sun RPC, Distributed
+ Computing Environment (DCE), Distributed Component Object Model
+ (DCOM), common object request broker architecture (Corba), and Simple
+ Object Access Protocol (SOAP). The PS uses the rule set to determine
+ whether the WR is authorized to access the PT's information, refusing
+ the request if necessary. Furthermore, the PS might filter
+ information by removing elements or by reducing the resolution of
+ elements.
+
+3.2. Active Request-Response - PS as Client (Initiator)
+
+ Alternatively, the PS may contact the WR and convey data items.
+ Examples include HTTP, SIP session setup (INVITE request), H.323
+ session setup or SMTP.
+
+3.3. Event Notification
+
+ Event notification adds a subscription phase to the "Active Request-
+ Response - PS as Client (Initiator)" mode of operation. A watcher or
+ subscriber asks to be added to the notification list for a particular
+ presentity or event. When the presentity changes state or the event
+ occurs, the PS sends a message to the WR containing the updated
+ state. (Presence is a special case of event notification; thus, we
+ often use the term interchangeably.)
+
+ In addition, the subscriber may itself add a filter to the
+ subscription, limiting the rate or content of the notifications. If
+ an event, after filtering by the rule-maker-provided rules and by the
+ subscriber-provided rules, only produces the same notification
+ content that was sent previously, no event notification is sent.
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 5]
+
+RFC 4745 Common Policy February 2007
+
+
+ A single PS may authorize access to data items in more than one mode.
+ Rather than having different rule sets for different modes all three
+ modes are supported with a one rule set schema. Specific instances
+ of the rule set can omit elements that are only applicable to the
+ subscription model.
+
+4. Goals and Assumptions
+
+ Below, we summarize our design goals and constraints.
+
+ Table representation:
+
+ Each rule must be representable as a row in a relational database.
+ This design goal should allow efficient policy implementation by
+ utilizing standard database optimization techniques.
+
+ Permit only:
+
+ Rules only provide permissions rather than denying them. Removing
+ a rule can never increase permissions. Depending on the
+ interpretation of 'deny' and 'permit' rules, the ordering of rules
+ might matter, making updating rule sets more complicated since
+ such update mechanisms would have to support insertion at specific
+ locations in the rule set. Additionally, it would make
+ distributed rule sets more complicated. Hence, only 'permit'
+ actions are allowed that result in more efficient rule processing.
+ This also implies that rule ordering is not important.
+ Consequently, to make a policy decision requires processing all
+ rules.
+
+ Additive permissions:
+
+ A query for access to data items is matched against the rules in
+ the rule database. If several rules match, then the overall
+ permissions granted to the WR are the union of those permissions.
+ A more detailed discussion is provided in Section 10.
+
+ Upgradeable:
+
+ It should be possible to add additional rules later, without
+ breaking PSs that have not been upgraded. Any such upgrades must
+ not degrade privacy constraints, but PSs not yet upgraded may
+ reveal less information than the rule maker would have chosen.
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 6]
+
+RFC 4745 Common Policy February 2007
+
+
+ Capability support:
+
+ In addition to the previous goal, a RM should be able to determine
+ which extensions are supported by the PS. The mechanism used to
+ determine the capability of a PS is outside the scope of this
+ specification.
+
+ Protocol-independent:
+
+ The rule set supports constraints on both notifications or queries
+ as well as subscriptions for event-based systems such as presence
+ systems.
+
+ No false assurance:
+
+ It appears more dangerous to give the user the impression that the
+ system will prevent disclosure automatically, but fail to do so
+ with a significant probability of operator error or
+ misunderstanding, than to force the user to explicitly invoke
+ simpler rules. For example, rules based on weekday and time-of-
+ day ranges seem particularly subject to misinterpretation and
+ false assumptions on part of the RM. (For example, a non-
+ technical RM would probably assume that the rules are based on the
+ time zone of his current location, which may not be known to other
+ components of the system.)
+
+5. Non-Goals
+
+ We explicitly decided that a number of possibly worthwhile
+ capabilities are beyond the scope of this first version. Future
+ versions may include these capabilities, using the extension
+ mechanism described in this document. Non-goals include:
+
+ No external references:
+
+ Attributes within specific rules cannot refer to external rule
+ sets, databases, directories, or other network elements. Any such
+ external reference would make simple database implementation
+ difficult and hence they are not supported in this version.
+
+ No regular expressions:
+
+ Conditions are matched on equality or 'greater-than'-style
+ comparisons, not regular expressions, partial matches such as the
+ SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches
+ ("*@example.com"). Most of these are better expressed as explicit
+ elements.
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 7]
+
+RFC 4745 Common Policy February 2007
+
+
+ No repeat times:
+
+ Repeat times (e.g., every day from 9 am to 4 pm) are difficult to
+ make work correctly, due to the different time zones that PT, WR,
+ PS, and RM may occupy. It appears that suggestions for including
+ time intervals are often based on supporting work/non-work
+ 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
+
+ A rule set (or synonymously, a policy) consists of zero or more
+ 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,
+ in subsets or as individual rules. A rule consists of three parts:
+ conditions (see Section 7), actions (see Section 8), and
+ transformations (see Section 9).
+
+ The conditions part is a set of expressions, each of which evaluates
+ to either TRUE or FALSE. When a WR asks for information about a PT,
+ the PS goes through each rule in the rule set. For each rule, it
+ evaluates the expressions in the conditions part. If all of the
+ expressions evaluate to TRUE, then the rule is applicable to this
+ request. Generally, each expression specifies a condition based on
+ some variable that is associated with the context of the request.
+ These variables can include the identity of the WR, the domain of the
+ WR, the time of day, or even external variables, such as the
+ temperature or the mood of the PT.
+
+ Assuming that the rule is applicable to the request, the actions and
+ transformations (commonly referred to as permissions) in the rule
+ specify how the PS is supposed to handle this request. If the
+ request is to view the location of the PT, or to view its presence,
+ the typical action is "permit", which allows the request to proceed.
+
+ Assuming the action allows the request to proceed, the
+ transformations part of the rule specifies how the information about
+ the PT -- their location information, their presence, etc. -- is
+ modified before being presented to the WR. These transformations are
+ in the form of positive permissions. That is, they always specify a
+ piece of information that is allowed to be seen by the WR. When a PS
+ processes a request, it takes the transformations specified across
+ 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 data type, plays a role. The details of the algorithm for
+ combining permissions is described in Section 10. The resulting
+
+
+
+Schulzrinne, et al. Standards Track [Page 8]
+
+RFC 4745 Common Policy February 2007
+
+
+ union effectively represents a "mask" -- it defines what information
+ is exposed to the WR. This mask is applied to the actual location or
+ presence data for the PT, and the data that is permitted by the mask
+ is shown to the WR. If the WR requests a subset of information only
+ (such as city-level civic location data only, instead of the full
+ civic location information), the information delivered to the WR MUST
+ be the intersection of the permissions granted to the WR and the data
+ requested by the WR.
+
+ Rules are encoded in XML. To this end, Section 13 contains an XML
+ schema defining the Common Policy 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 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 relational database table,
+ with each rule represented by one row in the database. The database
+ representation is by no means mandatory; we will use it as a
+ convenient and widely-understood example of an internal
+ representation. The database model has the advantage that operations
+ on rows have tightly defined meanings. In addition, it appears
+ plausible that larger-scale implementations will employ a backend
+ database to store and query rules, as they can then benefit from
+ existing optimized indexing, access control, scaling, and integrity
+ constraint mechanisms. Smaller-scale implementations may well choose
+ different implementations, e.g., a simple traversal of the set of
+ rules.
+
+6.1. Identification of Rules
+
+ Each rule is equipped with a parameter that identifies the rule.
+ This rule identifier is an opaque token chosen by the RM. A RM MUST
+ NOT use the same identifier for two rules that are available to the
+ PS at the same time for a given PT. If more than one RM modifies the
+ same rule set, then it needs to be ensured that a unique identifier
+ is chosen for each rule. A RM can accomplish this goal by retrieving
+ the already specified rule set and choosing a new identifier for a
+ rule that is different from the existing rule set.
+
+6.2. Extensions
+
+ The policy framework defined in this document is meant to be
+ extensible towards specific application domains. Such an extension
+ is accomplished by defining conditions, actions, and transformations
+ that are specific to the desired application domain. Each extension
+ MUST define its own namespace.
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 9]
+
+RFC 4745 Common Policy February 2007
+
+
+ Extensions cannot change the schema defined in this document, and
+ this schema is not expected to change except via revision to this
+ specification. Therefore, no versioning procedures for this schema
+ or namespace are provided.
+
+7. Conditions
+
+ The access to data items needs to be matched with the rule set stored
+ at the PS. Each instance of a request has different attributes
+ (e.g., the identity of the requestor) that are used for
+ authorization. A rule in a rule set might have a number of
+ conditions that need to be met before executing the remaining parts
+ of a rule (i.e., actions and transformations). Details about rule
+ matching are described in Section 10. This document specifies only a
+ few conditions (i.e., identity, sphere, and validity). Further
+ condition elements can be added via extensions to this document. If
+ a child element of the <conditions> element is in a namespace that is
+ not known or not supported, then this child element evaluates to
+ FALSE.
+
+ As noted in Section 5, conditions are matched on equality or "greater
+ than" style comparisons, rather than regular expressions. Equality
+ is determined according to the rules for the data type associated
+ with the element in the schema given in Section 13, unless explicit
+ comparison steps are included in this document. For xs:anyURI types,
+ readers may wish to consult [2] for its discussion xs:anyURI, as well
+ as the text in Section 13.
+
+7.1. Identity Condition
+
+7.1.1. Overview
+
+ The identity condition restricts matching of a rule either to a
+ single entity or a group of entities. Only authenticated entities
+ can be matched; acceptable means of authentication are defined in
+ protocol-specific documents. If the <identity> element is absent,
+ identities are not considered, and thus, other conditions in the rule
+ apply to any user, authenticated or not.
+
+ The <identity> condition is considered TRUE if any of its child
+ elements (e.g., the <one/> and the <many/> elements defined in this
+ document) evaluate to TRUE, i.e., the results of the individual child
+ element are combined using a logical OR.
+
+ If a child element of the <identity> element is in a namespace that
+ is not known or not supported, then this child element evaluates to
+ FALSE.
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 10]
+
+RFC 4745 Common Policy February 2007
+
+
+7.1.2. Matching One Entity
+
+ The <one> element matches the authenticated identity (as contained in
+ the 'id' attribute) of exactly one entity or user. For
+ considerations regarding the 'id' attribute, refer to Section 7.2.
+
+ An example is shown below:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r1">
+ <conditions>
+ <identity>
+ <one id="sip:alice@example.com"/>
+ <one id="tel:+1-212-555-1234" />
+ <one id="mailto:bob@example.net" />
+ </identity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+ </ruleset>
+
+ This example matches if the authenticated identity of the WR is
+ either sip:alice@example.com, tel:+1-212-555-1234, or
+ mailto:bob@example.net.
+
+7.1.3. Matching Multiple Entities
+
+ The <many> element is a mechanism to perform authorization decisions
+ based on the domain part of the authenticated identity. As such, it
+ allows matching a large and possibly unknown number of users within a
+ domain.
+
+ Furthermore, it is possible to include one or multiple <except>
+ elements to exclude either individual users or users belonging to a
+ specific domain. Excluding individual entities is implemented using
+ a <except id="..."/> statement. The semantic of the 'id' attribute
+ of the <except> element has the same meaning as the 'id' attribute of
+ the <one> element (see Section 7.2). Excluding users belonging to a
+ specific domain is implemented using the <except domain="..."/>
+ element that excludes any user from the indicated domain.
+
+ If multiple <except> elements are listed as child elements of the
+ <many> element, then the result of each <except> element is combined
+ using a logical OR.
+
+
+
+Schulzrinne, et al. Standards Track [Page 11]
+
+RFC 4745 Common Policy February 2007
+
+
+ Common policy MUST either use UTF-8 or UTF-16 to store domain names
+ in the 'domain' attribute. For non-IDNs (Internationalized Domain
+ Names), lowercase ASCII SHOULD be used. For the comparison operation
+ between the value stored in the 'domain' attribute and the domain
+ value provided via the using protocol (referred to as "protocol
+ domain identifier"), the following rules are applicable:
+
+ 1. Translate percent-encoding for either string.
+
+ 2. Convert both domain strings using the ToASCII operation described
+ in RFC 3490 [3].
+
+ 3. Compare the two domain strings for ASCII equality, for each
+ label. If the string comparison for each label indicates
+ equality, the comparison succeeds. Otherwise, the domains are
+ not equal.
+
+ If the conversion fails in step (2), the domains are not equal.
+
+7.1.3.1. Matching Any Authenticated Identity
+
+ The <many/> element without any child elements or attributes matches
+ any authenticated user.
+
+ The following example shows such a rule that matches any
+ authenticated user:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r5">
+ <conditions>
+ <identity>
+ <many/>
+ </identity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+ </ruleset>
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 12]
+
+RFC 4745 Common Policy February 2007
+
+
+7.1.3.2. Matching Any Authenticated Identity Except Enumerated
+ Domains/Identities
+
+ The <many> element enclosing one or more <except domain="..."/>
+ elements matches any user from any domain except those enumerated.
+ The <except id="..."/> element excludes particular users. The
+ semantics of the 'id' attribute of the <except> element is described
+ in Section 7.2. The results of the child elements of the <many>
+ element are combined using a logical OR.
+
+ An example is shown below:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r1">
+ <conditions>
+ <sphere value="work"/>
+ <identity>
+ <many>
+ <except domain="example.com"/>
+ <except domain="example.org"/>
+ <except id="sip:alice@bad.example.net"/>
+ <except id="sip:bob@good.example.net"/>
+ <except id="tel:+1-212-555-1234" />
+ <except id="sip:alice@example.com"/>
+ </many>
+ </identity>
+ <validity>
+ <from>2003-12-24T17:00:00+01:00</from>
+ <until>2003-12-24T19:00:00+01:00</until>
+ </validity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+ </ruleset>
+
+ 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,
+ bob@good.example.net, and the user with the telephone number
+ 'tel:+1-212-555-1234'. The last 'except' element is redundant since
+ alice@example.com is already excluded through the first line.
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 13]
+
+RFC 4745 Common Policy February 2007
+
+
+7.1.3.3. Matching Any Authenticated Identity within a Domain Except
+ Enumerated Identities
+
+ The <many> element with a 'domain' attribute and zero or more <except
+ id="..."/> elements matches any authenticated user from the indicated
+ domain except those explicitly enumerated. The semantics of the 'id'
+ attribute of the <except> element is described in Section 7.2.
+
+ It is nonsensical to have domains in the 'id' attribute that do not
+ match the value of the 'domain' attribute in the enclosing <many>
+ element.
+
+ An example is shown below:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r1">
+ <conditions>
+ <identity>
+ <many domain="example.com">
+ <except id="sip:alice@example.com"/>
+ <except id="sip:bob@example.com"/>
+ </many>
+ </identity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+ </ruleset>
+
+ This example matches any user within example.com (such as
+ carol@example.com) except alice@example.com and bob@example.com.
+
+7.2. Single Entity
+
+ 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
+ 'single-user entity' as a placeholder for the <one> and the <except>
+ element. The <except> element fulfills the purpose of excluding
+ elements from the solution set.
+
+ A single-user entity matches the authenticated identity (as contained
+ in the 'id' attribute) of exactly one entity or user. If there is a
+ match, the single-user entity is considered TRUE. The single-user
+ entity MUST NOT contain a 'domain' attribute.
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 14]
+
+RFC 4745 Common Policy February 2007
+
+
+ The 'id' attribute contains an identity that MUST first be expressed
+ as a URI. Applications using this framework must describe how the
+ identities they are using can be expressed as URIs.
+
+7.3. Sphere
+
+ The <sphere> element belongs to the group of condition elements. It
+ can be used to indicate a state (e.g., 'work', 'home', 'meeting',
+ 'travel') the PT is currently in. A sphere condition matches only if
+ the PT is currently in the state indicated. The state may be
+ conveyed by manual configuration or by some protocol. For example,
+ RPID [10] provides the ability to inform the PS of its current
+ sphere. The application domain needs to describe in more detail how
+ the sphere state is determined. Switching from one sphere to another
+ causes a switch between different modes of visibility. As a result,
+ different subsets of rules might be applicable.
+
+ The content of the 'value' attribute of the <sphere> element MAY
+ contain more than one token. The individual tokens MUST be separated
+ 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
+ content of the 'value' attribute in the sphere attribute contains 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 compare
+ the content of the 'value' attribute in the <sphere> element with the
+ stored state information about the PT's sphere setting a
+ case-insensitive string comparison MUST be used for each individual
+ token. There is neither a registry for these values nor a language-
+ specific indication of the sphere content. As such, the tokens are
+ treated as opaque strings.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r2">
+ <conditions>
+ <sphere value="work"/>
+ <identity>
+ <one id="sip:andrew@example.com"/>
+ </identity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 15]
+
+RFC 4745 Common Policy February 2007
+
+
+ <rule id="y6y55r2">
+ <conditions>
+ <sphere value="home"/>
+ <identity>
+ <one id="sip:allison@example.com"/>
+ </identity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+
+ <rule id="z6y55r2">
+ <conditions>
+ <identity>
+ <one id="sip:john@doe.example.com"/>
+ </identity>
+ <sphere value="home work"/>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+ </ruleset>
+
+ The rule example above illustrates that the rule with the entity
+ andrew@example.com matches if the sphere is been set to 'work'. In
+ the second rule, the entity allison@example.com matches if the sphere
+ is set to 'home'. The third rule also matches since the value in the
+ sphere element also contains the token 'home'.
+
+7.4. Validity
+
+ The <validity> element is the third condition element specified in
+ this document. It expresses the rule validity period by two
+ attributes, a starting and an ending time. The validity condition is
+ 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
+ represents a logical OR operation across each <from> and <until>
+ pair. Times are expressed in XML dateTime format. A rule maker
+ might not always have access to the PS to invalidate some rules that
+ grant permissions. Hence, this mechanism allows invalidating granted
+ permissions automatically without further interaction between the
+ rule maker and the PS. The PS does not remove the rules; instead the
+ rule maker has to clean them up.
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 16]
+
+RFC 4745 Common Policy February 2007
+
+
+ An example of a rule fragment is shown below:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r3">
+ <conditions>
+ <validity>
+ <from>2003-08-15T10:20:00.000-05:00</from>
+ <until>2003-09-15T10:20:00.000-05:00</until>
+ </validity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+ </ruleset>
+
+ The <validity> element MUST have the <from> and <until> subelements
+ in pairs. Multiple <from> and <until> elements might appear in pairs
+ (i.e., without nesting of <from> and <until> elements). Using
+ multiple <validity> elements as subelements of the <conditions>
+ element is not useful since all subelements of the <conditions>
+ element are combined as a logical AND.
+
+8. Actions
+
+ While conditions are the 'if'-part of rules, actions and
+ transformations form their 'then'-part. The actions and
+ transformations parts of a rule determine which operations the PS
+ MUST execute after having received from a WR a data access request
+ that matches all conditions of this rule. Actions and
+ transformations only permit certain operations; there is no 'deny'
+ functionality. Transformations exclusively specify PS-side
+ operations that lead to a modification of the data items requested by
+ the WR. Regarding location data items, for instance, a
+ transformation could force the PS to lower the precision of the
+ location information that is returned to the WR.
+
+ Actions, on the other hand, specify all remaining types of operations
+ the PS is obliged to execute, i.e., all operations that are not of
+ transformation type. Actions are defined by application-specific
+ usages of this framework. The reader is referred to the
+ corresponding extensions to see examples of such elements.
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 17]
+
+RFC 4745 Common Policy February 2007
+
+
+9. Transformations
+
+ Two sub-parts follow the conditions part of a rule: transformations
+ and actions. As defined in Section 8, transformations specify
+ operations that the PS MUST execute and that modify the result that
+ is returned to the WR. This functionality is particularly helpful in
+ reducing the granularity of information provided to the WR, as, for
+ example, required for location privacy. Transformations are defined
+ by application-specific usages of this framework.
+
+ A simple transformation example is provided in Section 10.
+
+10. Procedure for Combining Permissions
+
+10.1. Introduction
+
+ This section describes how rules are selected and how actions and
+ permissions are determined. When a PS receives a request for access
+ to privacy-sensitive data, the request is matched against the rule
+ set. A rule matches if all conditions contained as child elements in
+ the <conditions> element of a rule evaluate to TRUE. Each type of
+ condition defines when it is TRUE. All rules where the conditions
+ match the request form the matching rule set. The permissions in the
+ matching rule set are combined using a set of combining rules (CRs)
+ described in Section 10.2.
+
+10.2. Combining Rules (CRs)
+
+ Each type of permission is combined across all matching rules. Each
+ type of action or transformation is combined separately and
+ independently. The combining rules generate a combined permission.
+ The combining rules depend only on the data type of permission. If a
+ particular permission type has no value in a rule, it assumes the
+ lowest possible value for that permission for the purpose of
+ computing the combined permission. That value is given by the data
+ type for booleans (FALSE) and sets (empty set), and MUST be defined
+ by any extension to the Common Policy for other data types.
+
+ For boolean permissions, the resulting permission is TRUE if and only
+ if at least one permission in the matching rule set has a value of
+ TRUE and FALSE otherwise. For integer, real-valued and date-time
+ permissions, the resulting permission is the maximum value across the
+ permission values in the matching set of rules. For sets, it is the
+ union of values across the permissions in the matching rule set.
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 18]
+
+RFC 4745 Common Policy February 2007
+
+
+10.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 (WR-ID), sphere, and validity
+ (from,until). The ID column is used as a rule identifier. For
+ editorial reasons we omit the domain part of the WR's identity.
+
+ We use two actions in our example, namely X and Y. The values of X
+ and Y are of data types Boolean and Integer, respectively.
+
+ The transformation, referred to as Z, uses values that can be set
+ either to '+' (or 3), 'o' (or 2) or '-' (or 1). 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.
+
+ The label 'NULL' in the table indicates that no value is available
+ for a particular cell.
+
+ Conditions Actions/Transformations
+ +---------------------------------+---------------------+
+ | Id WR-ID sphere from until | 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 | NULL 12 o |
+ | 6 bob work B1 B2 | FALSE 10 - |
+ +---------------------------------+---------------------+
+
+ Again for editorial reasons, we use the following abbreviations for
+ the two <validity> attributes 'from' and 'until':
+
+ 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
+
+ Note that B1 < B2 < A1 < A2 < A3.
+
+ The entity 'bob' acts as a WR and requests data items. The rule set
+ 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
+
+
+
+Schulzrinne, et al. Standards Track [Page 19]
+
+RFC 4745 Common Policy February 2007
+
+
+ 2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our
+ example, we assume that the sphere value of the PT is currently set
+ to 'work'.
+
+ As a first step, it is necessary to determine which rules fire by
+ evaluating the conditions part of each of them.
+
+ 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.
+
+ Only rules 3 and 5 fire. We use the actions and transformations part
+ of these two rules to determine the combined permission, as shown
+ below.
+
+ Actions/Transformations
+ +-----+-----------------------+
+ | Id | X Y Z |
+ +-----+-----------------------+
+ | 3 | TRUE 3 - |
+ | 5 | NULL 12 o |
+ +-----+-----------------------+
+
+ Each column is treated independently. The combined value of X is set
+ to TRUE since the NULL value equals FALSE according to the
+ description in Section 10.2. For the column with the name Y, we
+ apply the maximum of 3 and 12, so that the combined value of Y is 12.
+ For column Z, we again compute the maximum of 'o' and '-' (i.e., 2
+ and 1) which is 'o' (2).
+
+ The combined permission for all three columns is therefore:
+
+ Actions/Transformations
+ +-----------------------+
+ | X Y Z |
+ +-----------------------+
+ | TRUE 12 o |
+ +-----------------------+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 20]
+
+RFC 4745 Common Policy February 2007
+
+
+11. Meta Policies
+
+ Meta policies authorize a rule maker to insert, update, or delete a
+ particular rule or an entire rule set. Some authorization policies
+ are required to prevent unauthorized modification of rule sets. Meta
+ policies are outside the scope of this document.
+
+ A simple implementation could restrict access to the rule set only to
+ the PT but more sophisticated mechanisms could be useful. As an
+ example of such policies, one could think of parents configuring the
+ policies for their children.
+
+12. Example
+
+ This section gives an example of an XML document valid with respect
+ to the XML schema defined in Section 13. Semantically richer
+ examples can be found in documents that extend this schema with
+ application-domain-specific data (e.g., location or presence
+ information).
+
+ Below a rule is shown with a condition that matches for a given
+ authenticated identity (bob@example.com) and within a given time
+ period. Additionally, the rule matches only if the target has set
+ its sphere to 'work'.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
+
+ <rule id="f3g44r1">
+ <conditions>
+ <identity>
+ <one id="sip:bob@example.com"/>
+ </identity>
+ <sphere value="work"/>
+ <validity>
+ <from>2003-12-24T17:00:00+01:00</from>
+ <until>2003-12-24T19:00:00+01:00</until>
+ </validity>
+ </conditions>
+ <actions/>
+ <transformations/>
+ </rule>
+ </ruleset>
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 21]
+
+RFC 4745 Common Policy February 2007
+
+
+13. XML Schema Definition
+
+ This section provides the XML schema definition for the common policy
+ markup language described in this document.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy"
+ xmlns:cp="urn:ietf:params:xml:ns:common-policy"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified" attributeFormDefault="unqualified">
+ <!-- /ruleset -->
+ <xs:element name="ruleset">
+ <xs:complexType>
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:sequence>
+ <xs:element name="rule" type="cp:ruleType"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ </xs:element>
+ <!-- /ruleset/rule -->
+ <xs:complexType name="ruleType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:sequence>
+ <xs:element name="conditions"
+ type="cp:conditionsType" minOccurs="0"/>
+ <xs:element name="actions"
+ type="cp:extensibleType" minOccurs="0"/>
+ <xs:element name="transformations"
+ type="cp:extensibleType" minOccurs="0"/>
+ </xs:sequence>
+ <xs:attribute name="id" type="xs:ID" use="required"/>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //rule/conditions -->
+ <xs:complexType name="conditionsType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:choice maxOccurs="unbounded">
+ <xs:element name="identity"
+ type="cp:identityType" minOccurs="0"/>
+ <xs:element name="sphere"
+ type="cp:sphereType" minOccurs="0"/>
+
+
+
+Schulzrinne, et al. Standards Track [Page 22]
+
+RFC 4745 Common Policy February 2007
+
+
+ <xs:element name="validity"
+ type="cp:validityType" minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:choice>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //conditions/identity -->
+ <xs:complexType name="identityType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:choice minOccurs="1" maxOccurs="unbounded">
+ <xs:element name="one" type="cp:oneType"/>
+ <xs:element name="many" type="cp:manyType"/>
+ <xs:any namespace="##other" processContents="lax"/>
+ </xs:choice>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //identity/one -->
+ <xs:complexType name="oneType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:sequence>
+ <xs:any namespace="##other"
+ minOccurs="0" processContents="lax"/>
+ </xs:sequence>
+ <xs:attribute name="id"
+ type="xs:anyURI" use="required"/>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //identity/many -->
+ <xs:complexType name="manyType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element name="except" type="cp:exceptType"/>
+ <xs:any namespace="##other"
+ minOccurs="0" processContents="lax"/>
+ </xs:choice>
+ <xs:attribute name="domain"
+ use="optional" type="xs:string"/>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //many/except -->
+
+
+
+Schulzrinne, et al. Standards Track [Page 23]
+
+RFC 4745 Common Policy February 2007
+
+
+ <xs:complexType name="exceptType">
+ <xs:attribute name="domain" type="xs:string" use="optional"/>
+ <xs:attribute name="id" type="xs:anyURI" use="optional"/>
+ </xs:complexType>
+ <!-- //conditions/sphere -->
+ <xs:complexType name="sphereType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:attribute name="value"
+ type="xs:string" use="required"/>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //conditions/validity -->
+ <xs:complexType name="validityType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:sequence minOccurs="1" maxOccurs="unbounded">
+ <xs:element name="from" type="xs:dateTime"/>
+ <xs:element name="until" type="xs:dateTime"/>
+ </xs:sequence>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+ <!-- //rule/actions or //rule/transformations -->
+ <xs:complexType name="extensibleType">
+ <xs:complexContent>
+ <xs:restriction base="xs:anyType">
+ <xs:sequence>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:restriction>
+ </xs:complexContent>
+ </xs:complexType>
+</xs:schema>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 24]
+
+RFC 4745 Common Policy February 2007
+
+
+14. Security Considerations
+
+ This document describes a framework for policies. This framework is
+ intended to be enhanced elsewhere by application-domain-specific
+ data. Security considerations are to a great extent application-data
+ dependent, and therefore need to be covered by documents that extend
+ the framework defined in this specification. However, new action and
+ transformation permissions along with their allowed values must be
+ defined in a way so that the usage of the permissions combining rules
+ of Section 10 does not lower the level of privacy protection. See
+ Section 10 for more details on this privacy issue.
+
+15. IANA Considerations
+
+ This section registers a new XML namespace, a new XML schema, and a
+ new MIME type. This section registers a new XML namespace per the
+ procedures in [4].
+
+15.1. Common Policy Namespace Registration
+
+ URI: urn:ietf:params:xml:ns:common-policy
+
+ Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
+ (hgs+geopriv@cs.columbia.edu).
+
+ XML:
+
+ 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>Common Policy Namespace</title>
+ </head>
+ <body>
+ <h1>Namespace for Common Authorization Policies</h1>
+ <h2>urn:ietf:params:xml:ns:common-policy</h2>
+ <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
+ RFC 4745</a>.</p>
+ </body>
+ </html>
+ END
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 25]
+
+RFC 4745 Common Policy February 2007
+
+
+15.2. Content-type Registration for 'application/auth-policy+xml'
+
+ This specification requests the registration of a new MIME type
+ according to the procedures of RFC 4288 [5] and guidelines in RFC
+ 3023 [6].
+
+ MIME media type name: application
+
+ MIME subtype name: auth-policy+xml
+
+ Mandatory parameters: none
+
+ Optional parameters: charset
+
+ Indicates the character encoding of enclosed XML.
+
+ Encoding considerations:
+
+ Uses XML, which can employ 8-bit characters, depending on the
+ character encoding used. See RFC 3023 [6], Section 3.2.
+
+ Security considerations:
+
+ This content type is designed to carry authorization policies.
+ Appropriate precautions should be adopted to limit disclosure of
+ this information. Please refer to Section 14 of RFC 4745 and to
+ the security considerations described in Section 10 of RFC 3023
+ [6] for more information.
+
+ Interoperability considerations: None
+
+ Published specification: RFC 4745
+
+ Applications which use this media type:
+
+ Presence- and location-based systems
+
+ Additional information:
+
+ Magic Number: None
+
+ File Extension: .apxml
+
+ Macintosh file type code: 'TEXT'
+
+ Personal and email address for further information:
+ Hannes Tschofenig, Hannes.Tschofenig@siemens.com
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 26]
+
+RFC 4745 Common Policy February 2007
+
+
+ Intended usage: LIMITED USE
+
+ Author:
+
+ This specification is a work item of the IETF GEOPRIV working
+ group, with mailing list address <geopriv@ietf.org>.
+
+ Change controller:
+
+ The IESG <iesg@ietf.org>
+
+15.3. Common Policy Schema Registration
+
+ URI: urn:ietf:params:xml:schema:common-policy
+
+ Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
+ (hgs+geopriv@cs.columbia.edu).
+
+ XML: The XML schema to be registered is contained in Section 13.
+ Its first line is
+
+ <?xml version="1.0" encoding="UTF-8"?>
+
+ and its last line is
+
+ </xs:schema>
+
+16. References
+
+16.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", RFC 3987, January 2005.
+
+ [3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
+ Domain Names in Applications (IDNA)", RFC 3490, March 2003.
+
+ [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [5] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+ [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
+ RFC 3023, January 2001.
+
+
+
+Schulzrinne, et al. Standards Track [Page 27]
+
+RFC 4745 Common Policy February 2007
+
+
+16.2. Informative References
+
+ [7] Rosenberg, J., "Presence Authorization Rules", Work in Progress,
+ June 2006.
+
+ [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J.
+ Polk, "A Document Format for Expressing Privacy Preferences for
+ Location Information", Work in Progress, February 2006.
+
+ [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
+ Polk, "Geopriv Requirements", RFC 3693, February 2004.
+
+ [10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
+ "RPID: Rich Presence Extensions to the Presence Information Data
+ Format (PIDF)", RFC 4480, July 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 28]
+
+RFC 4745 Common Policy February 2007
+
+
+Appendix A. Contributors
+
+ We would like to thank Christian Guenther for his help with initial
+ versions of this document.
+
+Appendix B. Acknowledgments
+
+ This document is partially based on the discussions within the IETF
+ GEOPRIV working group. Discussions at the Geopriv Interim Meeting
+ 2003 in Washington, D.C., helped the working group to make progress
+ on the authorization policies based on the discussions among the
+ participants.
+
+ We particularly want to thank Allison Mankin <mankin@psg.com>,
+ Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
+ <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon
+ Peterson <jon.peterson@neustar.biz> for discussing a number of
+ details with us. They helped us to improve the quality of this
+ document. Allison, Ted, and Andrew also helped us to make good
+ progress with the internationalization support of the identifier/
+ domain attributes.
+
+ Furthermore, we would like to thank the IETF SIMPLE working group for
+ their discussions of J. Rosenberg's draft on presence authorization
+ policies. We would also like to thank Stefan Berg, Murugaraj
+ Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki
+ Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their
+ comments. Martin Thomson helped us with the XML schema. Mark Baker
+ provided a review of the media type. Scott Brim provided a review on
+ behalf of the General Area Review Team.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 29]
+
+RFC 4745 Common Policy February 2007
+
+
+Authors' Addresses
+
+ Henning Schulzrinne
+ Columbia University
+ Department of Computer Science
+ 450 Computer Science Building
+ New York, NY 10027
+ USA
+
+ Phone: +1 212 939 7042
+ EMail: schulzrinne@cs.columbia.edu
+ URI: http://www.cs.columbia.edu/~hgs
+
+
+ Hannes Tschofenig
+ Siemens Networks GmbH & Co KG
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ EMail: Hannes.Tschofenig@siemens.com
+ URI: http://www.tschofenig.com
+
+
+ John B. Morris, Jr.
+ Center for Democracy and Technology
+ 1634 I Street NW, Suite 1100
+ Washington, DC 20006
+ USA
+
+ EMail: jmorris@cdt.org
+ URI: http://www.cdt.org
+
+
+ Jorge R. Cuellar
+ Siemens
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ EMail: Jorge.Cuellar@siemens.com
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 30]
+
+RFC 4745 Common Policy February 2007
+
+
+ James Polk
+ Cisco
+ 2200 East President George Bush Turnpike
+ Richardson, Texas 75082
+ USA
+
+ EMail: jmpolk@cisco.com
+
+
+ Jonathan Rosenberg
+ Cisco Systems
+ 600 Lanidex Plaza
+ Parsippany, New York 07054
+ USA
+
+ EMail: jdrosen@cisco.com
+ URI: http://www.jdrosen.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 31]
+
+RFC 4745 Common Policy February 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Schulzrinne, et al. Standards Track [Page 32]
+