GEOPRIV H. Schulzrinne Internet-Draft Columbia U. Expires: January 17, 2005 J. Morris CDT H. Tschofenig J. Cuellar Siemens J. Polk Cisco July 19, 2004 A Document Format for Expressing Privacy Preferences for Location Information draft-ietf-geopriv-policy-02 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Schulzrinne, et al. Expires January 17, 2005 [Page 1] Internet-Draft Geopriv Policy July 2004 This document defines an authorization policy language for controling access to location information. It extends the authorization framework of the common policy markup language towards location-specific access control needs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Data Model and Processing . . . . . . . . . . . . . . . 6 4. Rule Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 SIP Message Body . . . . . . . . . . . . . . . . . . . . . 7 4.3 Location Object . . . . . . . . . . . . . . . . . . . . . 7 5. Securing the Location Object . . . . . . . . . . . . . . . . . 9 6. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Geospatial Location . . . . . . . . . . . . . . . . . . . 10 7. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Transformations . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Set D (Distribute) Flag . . . . . . . . . . . . . . . . . 13 8.2 Set R (Retention) Time . . . . . . . . . . . . . . . . . . 13 8.3 Keep Rule (RR) . . . . . . . . . . . . . . . . . . . . . . 13 8.4 Provide Civil Location . . . . . . . . . . . . . . . . . . 13 8.5 Provide Geospatial Location . . . . . . . . . . . . . . . 14 8.6 Provide Timezone Flag . . . . . . . . . . . . . . . . . . 16 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 12.2 Informative References . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 27 Schulzrinne, et al. Expires January 17, 2005 [Page 2] Internet-Draft Geopriv Policy July 2004 1. Introduction Location information needs to be protected against unauthorized access to preserve the privacy of the owner of the location information. Therefore a protocol-independent model for access to geographic information was defined. The model includes a Location Generator (LG) that produces Location Information (LI), a Location Server (LS) that authorizes access to LI, a location recipient (LR) that requests and receives information, and a Rulemaker (RM) that provides policy rules to the LS which enforce access control policies on access to a target. Two policy namespaces have been defined. The first basic rule set [I-D.peterson-geopriv-pres] can restrict how long the receiver can retain the information and it can prohibit any further distribution of the information. It does not allow to customize information to specific receivers, for example. This document describes an enhanced rule set that provides richer constraints on the distribution of the Location Objects (LOs). We assume that a basic location object[I-D.peterson-geopriv-pres] can contain a reference to additional rule sets. We refer to any entity that uses the rules in this document to restrict the retention or distribution of information as a Rule Enforcer (RE). The rule set allows the RE to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals or during particular times. The RM can also stipulate that only certain parts of the location object are to be distributed to recipients or that the resolution of parts of the location object is limited. The sequence of operations can be described as follows. The LS receives either a query for location information of a particular Target, via the using protocol. The using protocol provides the identity of the requestor, either at the time of the query or subscription to the location information. The authenticated identity of the LR, together with other information provided by the using protocol or generally available to the server, is then used for searching through the rule set. All matching rules are combined according to a merging algorithm described in [I-D.ietf-geopriv-common-policy]. The resulting rule is applied to the location data, yielding a possibly modified location object that is delivered to the location recipient. Note that the protocols used to query location information (between LS and LR), update policies at the LS and the protocol between the LG to LS and from LS to LR do not have to be the same. This document does not mandate a specific protocol for any of them. Schulzrinne, et al. Expires January 17, 2005 [Page 3] Internet-Draft Geopriv Policy July 2004 This document is part of extends the framework defined in[I-D.ietf-geopriv-common-policy]. That document provides an abstract authorization framework for expressing policy rules. As specified there, each such rule consists of 'conditions', 'actions' and 'transformations'. Conditions determine under which circumstances the LS is permitted to perform 'actions'. 'Transformations' implement a mechanism to optionally modify information elements returned to the requestor (e.g., to reduce the granularity of location information). The term 'transformation' is also known as 'provisional action'. The XML schema in Section 10 extends the XML based authorization framework (see [I-D.ietf-geopriv-common-policy]) by introducing new members of the 'condition' and 'transformation' substitution groups defined there. To express civil location information, it makes use of the schema in Section 2.2.3 of [I-D.ietf-geopriv-pidf-lo] that defines the 'civilAddress' complex type. Schulzrinne, et al. Expires January 17, 2005 [Page 4] Internet-Draft Geopriv Policy July 2004 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 [RFC2119]. This document reuses the terminology of[RFC3693]. We subsequently refer to the terminology used in [RFC3693] as Geopriv. This section assists in the alignment between the terminology defined in [I-D.ietf-geopriv-common-policy] and in this document. This document uses the terms LS, LR and RM. PT - Presentity / Target: Geopriv uses the term Target to identify the object or person of which location information is required. RM - Rule Maker: The entity RM corresponds to the Geopriv Rulemaker. PS - (Authorization) Policy Server: The PS corresponds to the Location Server (LS) in the Geopriv terminology. WR - Watcher / Recipient: The WR represents the Location Recipient (LR) in the Geopriv terminology. An 'authorization policy' is given by a 'rule set'. A 'rule set' 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 terms 'authorization policy', 'policy' and 'rule set' are used interchangeable. The terms 'authorization policy rule', 'policy rule' and 'rule' are used interchangeable. The term 'using protocol' is defined in[RFC3693]. It refers to the protocol which is used to request access to and to return privacy sensitive data items. The Geopriv policy markup language refers to the authorization language defined in this document. The Common policy markup language refers to the authorization language described in [I-D.ietf-geopriv-common-policy]. Schulzrinne, et al. Expires January 17, 2005 [Page 5] Internet-Draft Geopriv Policy July 2004 3. Basic Data Model and Processing As the Geopriv policy markup language defined in Section 10 extends the Common policy markup language in [I-D.ietf-geopriv-common-policy], this document adopts the basic data model as introduced in Section 6 of [I-D.ietf-geopriv-common-policy]. Schulzrinne, et al. Expires January 17, 2005 [Page 6] Internet-Draft Geopriv Policy July 2004 4. Rule Transport We make no assumption as to how rules are conveyed to entities within the network. Purely as examples, we below describe a few plausible options. None of the rule elements depend on the properties of how rule sets are conveyed to an LS or LR. Mechanisms may allow partial updates of rule sets. A partial update is an update which modifies only parts of the rule set in contrast to a full update. To simplify such partial updates, each rule is labelled with an identifier (see [I-D.ietf-geopriv-common-policy]). Transaction semantics for policy rule updates are not required since 'permit only' and 'additive permissions' properties have to be used. These properties also prevent inconsistency during concurrent query and update operations. 4.1 HTTP A rule set could be uploaded to the LS via an HTTP POST operation or more fully-featured WEBDAV [RFC2518]. Each rule could be modeled as a single 'file', with the rule identifier as a file name. (Since multiple rules may have the LR identity in the condition part of the rule, the LR identity cannot be used.) One example of this approach includes XCAP[I-D.ietf-simple-xcap]. The rule set can also be referenced from within a location object. The attribute 'ruleset-reference' specified in Section 2.2.2 of [I-D.peterson-geopriv-pres] contains an URI that indicates where a rule set related to this object can be found. The URI MAY alternatively use the CID URI scheme in which case it MUST denote a MIME body carried with the Location Object by the using protocol. 4.2 SIP Message Body The rule set can be carried, as a separate MIME message body, in the SIP message that conveys location information from a LG (a SIP UAC) via an LS (a SIP proxy) to an LR (a SIP UAS). The rule set would then govern the behavior expected of the LR. 4.3 Location Object The rule set can be carried in LOs in two ways: by reference and by value. In either case the 'ruleset-reference' attribute inside the LO [I-D.peterson-geopriv-pres] points to the location of the rules. The LG or the LS can attach the rule set (or a pointer to it) to the location object. One of the transformations of the rule set is the removal of the rule Schulzrinne, et al. Expires January 17, 2005 [Page 7] Internet-Draft Geopriv Policy July 2004 set described here before further transmission. Only the whole rule set can be removed and not individual elements (for example, some conditions). Before transmitting the rules to the LR, the rule set SHOULD be removed since the rule set might disclose prefences of the rule maker which entities to trust and to which other entities no trust is available. Revealing this information might have negative implication for the RM itself. Schulzrinne, et al. Expires January 17, 2005 [Page 8] Internet-Draft Geopriv Policy July 2004 5. Securing the Location Object The Geopriv requirements draft [RFC3693] addresses the minimal security protection required for the LO: Mutual end-point authentication, data object integrity, data object confidentiality and replay protection. As proposed in[I-D.ietf-geopriv-pidf-lo] S/ MIME SHOULD be used. Protection for the LO also includes an attached rule set. Protection is likely to be necessary against adversaries who eavesdrop on the communication between the LS and the LR or the LG and the LS, who tamper with the LO or who replay previously recorded LOs. Securing the communication between RM and LS depends on the protocol which is used to perform the desired actions (e.g., https). The communication between the LG and the LS can also be secured using channel security. If the LO is integrity and confidentiality-protected then the receiving entity (LS or LR) has to be able to decrypt and to verify the LO. Since the policy rules described in this document allow the modification of the LO (via granularity reduction or by setting flags), it is not possible to forward the LO without reapplying the cryptographic protection. This is particularly true for the LS as it is not the final consumer of the LO. When the LS protects the LO for transmission to the LR (after successful authorization), then the authenticated identity can be used to select a security association to apply proper protection of the location object. Securing the LO for multiple LRs is not provided. Instead of encrypting the LO, the LG could digitally sign the LO, offering integrity, but no confidentiality. However, if the LS needs to perform modifications on the LO, then it would have to break the digital signature and may apply its own digital signature. Since the LO is generally distributed to more than one LR, the LG lacks the necessary information about the recipient and thus cannot usually apply confidentially protection. By default, the LS re-signs LOs if the signed LO has been modified according to the rule set. If the LS receives an LO that it cannot decrypt, it discards it if and only if the rule requires modification of the content. It remains for further study whether there should be an action that discards an LO that is signed or encrypted and needs to be modified according to the matching rule set. Schulzrinne, et al. Expires January 17, 2005 [Page 9] Internet-Draft Geopriv Policy July 2004 6. Conditions This section describes the location-specific conditions of a rule, namely the civil and geo-spatial location conditions. 6.1 Civil Location The element matches if the current location of the target matches all the values specified in the child elements of this element. The is of the 'civilAddress' complex type defined in Section 2.2.3 of [I-D.ietf-geopriv-pidf-lo]. It includes a number of fields, including the country (expressed as a two-letter ISO 3166 code), and the administrative units A1 through A6 of[I-D.ietf-geopriv-dhcp-civil]. This designation offers street-level precision. If the civil location of the target is not known, rules that contain a civil location never match. (This case may occur, for example, if location information has been removed by earlier transmitters of location information or if only the geospatial location is known.) If any of the elements through are specified, MUST also be specified. The schema does not enforce that the specification uniquely identifies a particular location. For example, it would be possible to omit the region and match only on city name, so that any city sharing that name within a country would match. This feature is primarily designed to deal with users that may not know the administrative divisions between country and city level. For example, many users may not know the county for cities in the United States. 6.2 Geospatial Location Geospatial location conditions can be expressed by means of the element. Such a condition makes the rule match if the Target is currently located within the trapezoid on the surface of the earth that is bounded by the values of longitude and latitude elements , , , and , regardless of the altitude value, if present; Figure 1 shows this. The northern boundary of this trapezoid is on the latitude given by the value of the element correspondingly, the southern boundary is given by the value of the element. The western boundary of this trapezoid is on the longitude given by the value of the element, and its eastern boundary is on the longitude given by the value of the element. Schulzrinne, et al. Expires January 17, 2005 [Page 10] Internet-Draft Geopriv Policy July 2004 _________________________ / \ / \ / _________ \ / / \ \ / / Target \ \ / / \ \ / /---------------\ \ / \ / \ / \ /---------------------------------------------\ Figure 1: Example Trapezoids North of the Equator The Target knows where it is (shown as the inner trapezoid). This trapezoid might be greater in size than the dimensions of the Target due to precision of the measuring device issues. The rule is a match if the outer trapezoid completely encloses the inner trapezoid. Schulzrinne, et al. Expires January 17, 2005 [Page 11] Internet-Draft Geopriv Policy July 2004 7. Actions According to the common policy framework[I-D.ietf-geopriv-common-policy], actions and transformations included in a rule determine which operations the LS MUST execute after having received from a LR a location data access request that matches all conditions of this rule. Transformations exclusively specify LS-side operations that lead to a modification of the location data items requested by the LR. Actions, on the other hand, specify all remaining types of operations the LS is obliged to execute, i.e., all operations that are not of transformation type. This document does not define new, location-specific actions. Schulzrinne, et al. Expires January 17, 2005 [Page 12] Internet-Draft Geopriv Policy July 2004 8. Transformations In addition to the transformations below, the LS MAY translate, add or remove location information. For example, they may add timezone information based on civil information. All transformations are privacy-safe, i.e., if a transformation is NULL (i.e., if the attribute is not present or empty in a policy rule), the LS removes the corresponding location information from the LO and leaves the LO flags undisturbed. Extensions to this document may define other transformations. 8.1 Set D (Distribute) Flag This transformation sets the D flag in the location object to either 'true' or 'false'. A value of 'true' means the recipient of the LO is allowed to further distribute it. A value of 'false' prevents further distribution. The value NULL keeps the D flag in the LO as is. The default value is 'false'. 8.2 Set R (Retention) Time The retention transformation sets the retention value in the location object to the current time plus the time provided in the element, measured in seconds. The value NULL keeps the retention time in the LO as is. If the LO did not contain a value then the LS sets it to a configured default value. 8.3 Keep Rule (RR) If the Keep Rule (RR) flag is set, any extended rules included in the location object are kept. 8.4 Provide Civil Location The Provide Civil Location transformation restricts the civil location to one of six levels, from lowest to highest: null, country, region, city, building, full. Each level includes all elements included by the lower levels. The 'country' level includes only the element; the 'region' level adds the element; the 'city' level adds the and elements; the 'building' level and the 'full' level add further civil location data as shown below. Schulzrinne, et al. Expires January 17, 2005 [Page 13] Internet-Draft Geopriv Policy July 2004 If this action is NULL, all civil information is removed from the LO. The values for this attribute are used in the following hiearchy: Full {, , , , , , , , , , , , , , , , , } | Building {, , , , , , , , , , , , , , } | City {, , } | Region {, } | Country {} | 'NULL' {} 8.5 Provide Geospatial Location The Provide Geospatial Location transformation restricts the resolution of the geospatial location information to the number of bits provided, separately for longitude and latitude, and altitude (if present) . The default value is zero. For purposes of this transformation, longitude and latitude are treated as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. Altitude is treated as a fixed-point 22-bit integer part with a 8-bit fraction, measured in meters. This corresponds to the representation in [RFC3825], but does not constrain the representation in the location object. Longitude, latitude and altitude are not to be conveyed in is 2s- complement form in the this text based protocol, but rather in decimal form for easier reading. Conversation between the two forms is for resolution altering. For example (as given in the appendix of [RFC3825], the civic address of the White House in Washington, DC (US) is: Schulzrinne, et al. Expires January 17, 2005 [Page 14] Internet-Draft Geopriv Policy July 2004 White House 1600 Pennsylvania Ave. NW Washington, DC 20006 which is equivalent to the coordinates (using the WGS84 datum): Latitude 38.89868 degrees North (or +38.89868 degrees) Using 2s complement, 34 bit fixed point, 25 bit fraction Latitude = 0x04dcc1fc8, Latitude = 0001001101110011000001111111001000 Longitude 77.03723 degrees West (or -77.03723 degrees) Using 2s complement, 34 bit fixed point, 25 bit fraction Longitude = 0xf65ecf031, Longitude = 1101100101111011001111000000110001 All three values above (each for latitude and for longitude) are equivalent (barring rounding). Using 2 forms that are of the same representation (decimal, hex and 2s-complement binary), the size of the point a numbering pair represent is approximately 3.11mm by 2.62mm. When reducing the resolution of the 'point' one is conveying, reducing the length of the raw binary number increases the size of the point (to the point of not being a point, but a square with an upper and lower bound to all that is within this area). For example, if o the resolution were reduced (here using the LaRes and LoRes values within the DHCP Option) to 22 (0x16 or 010110), for each - it would describe a geo-location area that is latitude 38.896816 north to latitude 38.8985596 and extends from -77.0372314 degrees to -77.0371094 degrees longitude. This is an area of approximately 143 square meters (10.5m x 13.6m). o the resolution were reduced (here using the LaRes and LoRes values within the DHCP Option) to 18 (0x12 or 010010), for each - it would describe a geo-location area that is latitude 38.8984375 north to latitude 38.9003906 and extends from -77.0390625 degrees Schulzrinne, et al. Expires January 17, 2005 [Page 15] Internet-Draft Geopriv Policy July 2004 to -77.0371094 degrees longitude. This is an area of approximately 36,600 square meters (169m x 217m). o the resolution were reduced (here using the LaRes and LoRes values within the DHCP Option) to 5 (0x05 or 000101), for each - it would describe a geo-location area that is latitude 32 north of the equator to latitude 48 and extends from -64 degrees to -80 degrees longitude. This is approximately an east-west boundary of a time zone, an area of approximately 700,000 square nm. All 3 examples above were from the same 3.11mm x 2.62mm point, merely with a reduced resolution. The altitude value was not adjusted in any example. It is: Altitude 15 (meters is the unit) being precise for the White House. If the transformation value is NULL, all geospatial location information is removed from the LO. 8.6 Provide Timezone Flag The 'Provide Timezone' transformation indicates the inclusion or removal of timezone information of the target, i.e., the offset from UTC. The value of 'false' causes timezone information to be excluded from the LO. If the transformation value is NULL, all timezone information is removed from the LO. Schulzrinne, et al. Expires January 17, 2005 [Page 16] Internet-Draft Geopriv Policy July 2004 9. Example The example of this section illustrates a rule set with a single rule. The conditions given in this rule match to a location requestor named ted@example.com (provided as a SIP URI in our example). The rule is valid for one year (2003-10-01 to 2004-10-01). Requests only match if the target is at his main office in a Siemens site in Munich. This is specified by means of the content of the element. The syntax of this content complies with the 'civilAddress' complex type defined in Section 2.2.3 of [I-D.ietf-geopriv-pidf-lo]. The section indicates that all civil location information is provided to the location requestor. The distribution flag is set to 'false' and the rules included in the LO are left unmodified. 2003-10-01T17:00:00+01:00 2004-10-01T00:00:00+01:00 DE Bavaria Munich Perlach Otto-Hahn-Ring 6 Schulzrinne, et al. Expires January 17, 2005 [Page 17] Internet-Draft Geopriv Policy July 2004 full false true In case of a policy consisting of more than one rule and a request for location information that let multiple rules match, there must be a procedure for combining the permissions contained in the matching rules. This procedure is defined in [I-D.ietf-geopriv-common-policy], Section 10. Schulzrinne, et al. Expires January 17, 2005 [Page 18] Internet-Draft Geopriv Policy July 2004 10. XML Schema This section specifies an XML schema for the authorization policies described in the previous sections. The Geopriv policy markup language introduced by this schema extends the common policy markup language (see [I-D.ietf-geopriv-common-policy]) by introducing new members of the 'condition' and 'transformation' substitution groups whose heads (namely the elements and ) are specified by the common policy schema (once again, see[I-D.ietf-geopriv-common-policy]). This way, the Geopriv policy markup language specializes the common rules markup language towards location-based presence information. To this end, the following schema imports the vocabulary of the common policy markup language. Furthermore, to express civil location information, it imports the 'civilAddress' complex type as defined in section 2.2.3 of[I-D.ietf-geopriv-pidf-lo]. Schulzrinne, et al. Expires January 17, 2005 [Page 19] Internet-Draft Geopriv Policy July 2004 Schulzrinne, et al. Expires January 17, 2005 [Page 20] Internet-Draft Geopriv Policy July 2004 11. Security Considerations This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. Security threats are described in [RFC3694] and are applicable to this draft as well. Requirements are addressed in [RFC3693]. Section 5 addresses issues of protecting the policy rules within the LO and location information itself. Aspects of combining permissions in a privacy-safe fashion are illustrated in Section 8. Schulzrinne, et al. Expires January 17, 2005 [Page 21] Internet-Draft Geopriv Policy July 2004 12. References 12.1 Normative References [I-D.ietf-geopriv-common-policy] Schulzrinne, H., Morris, J., Tschofenig, H., Cuellar, J., Polk, J. and J. Rosenberg, "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-01 (work in progress), July 2004. [I-D.ietf-geopriv-pidf-lo] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-01 (work in progress), February 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. 12.2 Informative References [I-D.ietf-geopriv-dhcp-civil] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses", draft-ietf-geopriv-dhcp-civil-02 (work in progress), March 2004. [I-D.ietf-simple-xcap] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02 (work in progress), February 2004, . [I-D.peterson-geopriv-pres] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work in progress), February 2003. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- Schulzrinne, et al. Expires January 17, 2005 [Page 22] Internet-Draft Geopriv Policy July 2004 WEBDAV", RFC 2518, February 1999. [RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. 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 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 Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Jorge.Cuellar@siemens.com Schulzrinne, et al. Expires January 17, 2005 [Page 23] Internet-Draft Geopriv Policy July 2004 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA EMail: jmpolk@cisco.com Schulzrinne, et al. Expires January 17, 2005 [Page 24] Internet-Draft Geopriv Policy July 2004 Appendix A. Contributors We would like to thank Christian Guenther for his help with the XML schema in this document. Christian Guenther Siemens AG Corporate Technology 81730 Munich Email: christian.guenther@siemens.com Germany Schulzrinne, et al. Expires January 17, 2005 [Page 25] Internet-Draft Geopriv Policy July 2004 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 , Randall Gellens , Andrew Newton , Ted Hardie , Jon Peterson for their time discussing a number of details with us. They helped us to improve the quality of this document. Schulzrinne, et al. Expires January 17, 2005 [Page 26] Internet-Draft Geopriv Policy July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Expires January 17, 2005 [Page 27]