idnits 2.17.1 draft-ietf-geopriv-policy-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 982. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2006) is 6648 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-geopriv-dhcp-civil' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-simple-xcap' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC2518' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3825' is defined on line 890, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Downref: Normative reference to an Informational RFC: RFC 3694 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-06 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-08 -- Obsolete informational reference (is this intentional?): RFC 2518 (Obsoleted by RFC 4918) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: August 15, 2006 H. Tschofenig 5 Siemens 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 Cisco 12 February 11, 2006 14 A Document Format for Expressing Privacy Preferences for Location 15 Information 16 draft-ietf-geopriv-policy-08.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 15, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 This document defines an authorization policy language for controling 49 access to location information. It extends the authorization 50 framework of the common policy markup language to provide location- 51 specific access control. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Basic Data Model and Processing . . . . . . . . . . . . . . . 6 58 4. Rule Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Securing the Location Object . . . . . . . . . . . . . . . . . 8 60 6. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6.1. Civic Location Condition . . . . . . . . . . . . . . . . . 10 62 6.2. Geospatial Location Condition . . . . . . . . . . . . . . 10 63 6.2.1. Polygon . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.2.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . 11 65 7. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Transformations . . . . . . . . . . . . . . . . . . . . . . . 13 67 8.1. Distribution Transformation . . . . . . . . . . . . . . . 13 68 8.2. Retention Transformation . . . . . . . . . . . . . . . . . 13 69 8.3. Keep Rules Transformation . . . . . . . . . . . . . . . . 14 70 8.4. Civic Location Transformation . . . . . . . . . . . . . . 14 71 8.5. Geospatial Location Transformation . . . . . . . . . . . . 15 72 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1. Rule Example with Civic Location Condition . . . . . . . . 17 74 9.2. Rule Example with Geospatial Location Information . . . . 19 75 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 80 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 28 81 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 83 Intellectual Property and Copyright Statements . . . . . . . . . . 32 85 1. Introduction 87 Location information needs to be protected against unauthorized 88 access to preserve the privacy of the subject of the location 89 information. In [RFC3693], a protocol-independent model for access 90 to geographic information was defined. The model includes a Location 91 Generator (LG) that produces Location Information (LI), a Location 92 Server (LS) that authorizes access to LI, a location recipient (LR) 93 that requests and receives information, and a Rulemaker (RM) that 94 provides authorization policy rules. An authorization policy is a 95 set of rules that regulate an entity's activities with respect to 96 privacy-sensitive information such as location information. The data 97 object containing LI is referred to as Location Object (LO). 99 The basic rule set defined in PIDF-LO [RFC4119] can restrict how long 100 the receiver can retain the information and it can prohibitfurther 101 distribution of the information. It does not allow to customize 102 information to specific receivers, for example. This document 103 describes an enhanced rule set that provides richer constraints on 104 the distribution of LOs. 106 We refer to any entity that uses the rules in this document to 107 restrict the retention or distribution of information as a Rule 108 Enforcer (RE). The rule set allows the RE to enforce access 109 restrictions on location data, including prohibiting any 110 dissemination to particular individuals, during particular times or 111 when the Target is located in a specific region. The RM can also 112 stipulate that only certain parts of the location object are to be 113 distributed to recipients or that the resolution of parts of the 114 location object is limited. 116 The sequence of operations is as follows. The location server 117 receives a query for location information for a particular Target, 118 via the using protocol. The using protocol provides the identity of 119 the requestor, either at the time of the query or when subscribing to 120 the location information. The authenticated identity of the location 121 recipient, together with other information provided by the using 122 protocol or generally available to the server, is then used for 123 searching through the rule set. All matching rules are combined 124 according to a merging algorithm described in [I-D.ietf-geopriv- 125 common-policy]. The resulting rule is applied to the location data, 126 yielding a possibly modified location object that is delivered to the 127 location recipient. 129 This document does not describe or mandate the protocol used to 130 deliver location information from the location server to the location 131 recipient, nor the protocol to update the policies or the protocol 132 that is used by the location generator to convey location information 133 to the location server. 135 This document extends the framework defined in [I-D.ietf-geopriv- 136 common-policy]. That document provides an abstract framework for 137 expressing authorization policy rules. As specified there, each such 138 rule consists of conditions, actions and transformations.'Conditions 139 determine under which circumstances the location server is permitted 140 to perform actions and transformations. Transformations regulate how 141 a location server handles location objects; it might limit when and 142 how data and policy can be distributed and may modify the information 143 elements that are returned to the requestor, e.g., reducing the 144 granularity of location information). 146 The XML schema in Section 10 extends the XML-based authorization 147 framework (see [I-D.ietf-geopriv-common-policy]) by introducing new 148 members of the condition and transformation substitution groups 149 defined there. The schema does not define new actions. To express 150 civic location information, it makes use of that schema in [RFC4119] 151 that defines the 'civicAddress' complex type. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 This document reuses the terminology of [RFC3693], e.g., the terms 160 Location Server (LS) and Location Recipient (LR). This document and 161 the common policy document [I-D.ietf-geopriv-common-policy] share the 162 following terminology: 164 Presentity or target: RFC 3693 uses the term Target to identify the 165 object or person of which location information is required. The 166 presence model described in RFC 2778 [RFC2778] uses the term 167 presentity to describe the entity that provides presence 168 information to a presence service. In a presence system, the 169 target is the presentity. 171 Watcher or Location Recipient: The receiver of location information 172 is the Location Recipient (LR) in the terminology of RFC 3693. A 173 watcher, i.e., an entity that requests presence information about 174 a presentity, is a location recipient in presence systems. 176 Authorization policy: An authorization policy is given by a rule set. 177 A rule set contains an unordered list of rules. A rule has a 178 conditions, an actions and a transformations part. 180 Permission: The term permission indicates the action and 181 transformation components of a rule. 183 The terms 'authorization policy', 'policy' and 'rule set' are used 184 interchangeable. The terms 'authorization policy rule', 'policy 185 rule' and 'rule' are used interchangeable. 187 The term 'using protocol' is defined in [RFC3693]. It refers to the 188 protocol which is used to request access to and to return privacy 189 sensitive data items. 191 The geo privacy policy markup language refers to the authorization 192 language defined in this document. The common policy markup language 193 refers to the authorization language described in [I-D.ietf-geopriv- 194 common-policy]. 196 3. Basic Data Model and Processing 198 Since the geo privacy policy markup language defined in Section 10 199 extends the common policy markup language in [I-D.ietf-geopriv- 200 common-policy], this document adopts the basic data model as 201 introduced in Section 6 of [I-D.ietf-geopriv-common-policy]. 203 4. Rule Transport 205 The XML data format of the GEOPRIV location object is specified 206 in[RFC4119]. The definition of the location object there allows 207 enhanced authorization policies associated to the location object to 208 be referenced via a URL in the 'ruleset-reference' element containing 209 an URI that indicates where a rule set related to the location object 210 can be found. 212 One of the transformations of the rule set is the removal of the rule 213 set described here before transmission. Only the whole rule set can 214 be removed and not individual elements such as only some conditions. 215 Before transmitting the rules to the location recipient, unless 216 explicitly permitted by the authorization policy, the rule set MUST 217 be removed from the location object, since the rule set might 218 disclose which entities the rule maker trusts (see Section 8). 220 5. Securing the Location Object 222 The GEOPRIV requirements document [RFC3693] addresses the minimal 223 security protection required for the LO, namely mutual end-point 224 authentication, data object integrity, data object confidentiality 225 and replay protection. As proposed in[RFC4119], S/MIME SHOULD be 226 used. Protection for the location object also includes an attached 227 rule set. 229 Protection is likely to be necessary against adversaries who 230 eavesdrop on the communication between the location server and the 231 location recipient or the location generator and the location server, 232 who tamper with the location object or who replay previously recorded 233 location objects. Securing the communication between rule maker and 234 location server depends on the protocol which is used to perform the 235 desired actions (e.g., https). The communication between the 236 location generator and the location server can also be secured using 237 channel security. 239 If the location object is integrity and confidentiality-protected, 240 then the receiving entity (location server or location recipient) has 241 to be able to decrypt and to verify the location object. Since the 242 authorization policy rules described in this document allow the 243 modification of the location object, by granularity reduction or by 244 setting flags, it is not possible to forward the location object 245 without reapplying the cryptographic protection. This applies 246 especially to the location server as it is not the final consumer of 247 the location object. 249 When the location server protects the location object for 250 transmission to the location recipient after successful 251 authorization, then the authenticated identity can be used to select 252 a security association to apply proper protection of the location 253 object. Securing the location object for multiple recipients is 254 currently not provided. 256 Instead of encrypting the location object, the location generator 257 could digitally sign the location object, offering integrity 258 protection, but no confidentiality. However, if the location server 259 needs to modify the location object, it would have to break the 260 digital signature and then apply its own digital signature. 262 Since the location object is generally distributed to more than one 263 location recipient, the location generator lacks the necessary 264 information about the recipient and thus cannot usually apply 265 confidentially protection. 267 By default, the location server re-signs location objects if the 268 signed location object has been modified according to the rule set. 269 If the location server receives a location object that it cannot 270 decrypt, it discards it if and only if the rule requires modification 271 of the content. 273 6. Conditions 275 This section describes the location-specific conditions in a rule, 276 namely the civic and geo-spatial location conditions. The XML 277 elements and attributes shown below are defined by the XML schema in 278 Section 10. 280 6.1. Civic Location Condition 282 The element matches if the current location of 283 the target matches all the values specified in the child elements of 284 this element. The is of the 'civicAddress' 285 complex type defined in [RFC4119]. It includes a number of fields, 286 including the country, expressed as a two-letter ISO 3166 code, and 287 the administrative units A1 through A6 of [I-D.ietf-geopriv-dhcp- 288 civil]. This designation offers street-level precision. 290 If the civic location of the target is not known, rules that contain 291 a civic location condition never match. This case may occur, for 292 example, if location information has been removed by earlier 293 transmitters of location information or if only the geospatial 294 location is known. 296 If any of the elements through are specified, 297 MUST also be specified. The schema does not enforce that the 298 specification uniquely identifies a particular location. For 299 example, it would be possible to omit the region and match only on 300 city name, so that any city sharing that name within a country would 301 match. This feature is primarily designed to deal with users that 302 may not know the administrative divisions between county and city 303 level. For example, many users may not know the county for cities in 304 the United States. 306 6.2. Geospatial Location Condition 308 The geospatial location condition allows to make authorization 309 decisions based on the current geospatial location of the target. A 310 rule matches if the current location of the Target is contained in 311 either the identified polygon (see Section 6.2.1) or between a range 312 of altitude values (see Section 6.2.2). 314 6.2.1. Polygon 316 The condition matches if the longitude and latitude values of the 317 polygon, interpreted as x and y coordinates on a plane, enclose the 318 current location of the target. 320 There are a number of algorithms for determining whether a point is 321 inside a polygon. A common algorithm draws a ray from the test point 322 to the right. The test point is inside if and only if the ray 323 intersects the line segments making up the polygon an odd number of 324 times. 326 The listed points, which constitute the polygon, MUST be listed as 327 they appear in a clockwise direction all the way around the perimeter 328 of the single plane shape. This is the defined concept of a "Ring" 329 within GML [GML]. The final point MUST be a repeat of the first 330 point listed to enclose the polygon. 332 6.2.2. Altitude 334 The altitude condition matches if the target altitude is defined and 335 falls between the low and high altitude stated in the rule, measured 336 in meters above the WGS84 sphere. If either element is omitted, the 337 altitude range is an open range. 339 7. Actions 341 According to the common policy framework [I-D.ietf-geopriv-common- 342 policy], actions and transformations included in a rule determine 343 which operations the location server MUST execute after having 344 received a location data access request from a location recipient 345 that matches all conditions of this rule. Transformations regulate 346 the location server operations that directly influence the handling 347 of location information. Actions, on the other hand, specify all 348 remaining types of operations the location server is obliged to 349 execute, i.e., all operations that are not of transformation type. 350 This document does not define new, location-specific actions. 352 8. Transformations 354 This policy markup language defines several elements by means of 355 which rulemakers can specify transformations. These transformations 356 determine whether the location server may distribute the location 357 object at all and, if so, limits the accuracy of the location object 358 passed by the location server to the recipient. 360 All transformations defined in this section are privacy-safe in the 361 sense that if the evaluation of the authorization policy related to a 362 given location object does not produce an explicit transformation 363 instruction, the location server MUST execute the transformation in 364 question to ensure minimal discloure of privacy-sensitive 365 information. 367 Extensions to this document may define other transformations. 369 8.1. Distribution Transformation 371 This transformation can be specified by means of the element whose value is of boolean type. A location 373 server is allowed to distribute this location object if and only if 374 all of the following conditions are satisfied: 376 1. the authorization policy related to the location object contains 377 a rule with a element, 379 2. at least one of the rules safisfying (1) matches, and 381 3. the combined value of this permission is 'true' (see [I-D.ietf- 382 geopriv-common-policy] for the term 'combined value'). 384 In all other cases, the location server MUST NOT distribute the 385 location object in question. In particular, this also comprises the 386 case of an authorization policy that does not contain a rule with a 387 element. 389 8.2. Retention Transformation 391 This transformation can be specified by means of the element whose value is of integer type. A location 393 server is allowed to retain a location object for the maximum 394 retention time after receiving the location object, if and only if 395 all of the following conditions are satisfied: 397 1. the authorization policy related to the location object contains 398 a rule with a element, 400 2. at least one of the rules satisfying (1) matches, and 402 3. the combined value of this permission is the retention time. 404 In all other cases, the location server MUST delete the location 405 object immediately after completing the service that makes use of the 406 location object, such as delivering it to current subscribers in a 407 presence system. 409 8.3. Keep Rules Transformation 411 This transformation can be specified by means of the element whose value is of boolean type. For a 413 location object subject to this rule, a location server is allowed to 414 keep all authorization policy rules in the location object when 415 delivering it to the location recipient if and only if all of the 416 following econditions are satisfied: 418 1. the authorization policy related to the location object contains 419 a rule with a element, 421 2. at least one of the rules satisfying (1) matches, and 423 3. the combined value of this permission is 'true'. 425 In all other cases, the location server MUST remove all authorization 426 policy rules from the location object. The rules are referenced from 427 PDIF-LO via the 'ruleset-reference' element either using a URI or a 428 CID URI scheme as described in Section 2.2.2 of [RFC4119]. 430 The reference to the ruleset is removed and no rules are carried as 431 MIME bodies (in case of CID URIs). 433 8.4. Civic Location Transformation 435 The civic location transformation can be specified by means of the 436 element to restrict the level of civic 437 location information the LS is permitted to provide. From lowest to 438 highest level, the names of these levels are: 'null', 'country', 439 'region', 'city', 'building', 'full'. Each level is given by a set 440 of civic location data items such as and , ..., , 441 as defined in [RFC4119]. Each level includes all elements included 442 by the lower levels. 444 The 'country' level includes only the element; the 'region' 445 level adds the element; the 'city' level adds the and 446 elements; the 'building' level and the 'full' level add further civic 447 location data as shown below: 449 full 450 {, , , , , , , , , 451 , , , , , , , , } 452 | 453 building 454 {, , , , , , , 455 , , , , , , , } 456 | 457 city 458 {, , } 459 | 460 region 461 {, } 462 | 463 country 464 {} 465 | 466 null 467 {} 469 With respect to a given LO, a LS is permitted to pass civic location 470 information corresponding to the given LO on at the level L (L = 471 'country', 'region', 'city', 'building', or 'full'), if and only if 472 all of the following conditions are satisfied: 474 1. the authorization policy related to the LO contains a rule with a 475 element, 477 2. at least one of the rules satisfying 1) matches, and 479 3. the combined value of this permission is the level L. 481 In all other cases, including the case in which no rule of the 482 authorization policy related to the given location object contains a 483 element, the location server MUST remove 484 all civic location information from the LO before passing it on, 485 thereby providing the 'null' level of civic location information. 487 8.5. Geospatial Location Transformation 489 The geospatial location transformation can be specified by means of 490 the element to restrict the 491 resolution of the geospatial location information to the value 492 provided in the , and 493 child elements of the element. The resolution is specified as a positive, 495 non-zero number r. If n is the nominal coordinate value (longitude 496 or latitude), the rounded value is computed as 497 floor(n/r + 0.5) * r. 499 For example, if the latitude is n=38.89868 and r=0.01, the latitude 500 value rendered to the recipient of the location object is 38.90. If 501 the longitude is n=77.03723 and r=0.01, the longitude is rendered as 502 77.04. This computation also works for r that are not integer powers 503 of 10 or r > 1. For example, to round longitude to timezone 504 accuracy, one would use r=15 and obtain a value of 75 in this 505 example. 507 For a given LO, a LS is allowed to pass the longitude or latitude 508 value corresponding to the given LO on at the resolution value r, if 509 and only if all of the following conditions are satisfied: 511 1. the authorization policy related to the location object contains 512 a rule with a element that has a 513 element, 515 2. at least one of the rules satisfying (1) matches, and 517 3. the combined value of this permission is r. 519 In all other cases, the LS MUST remove the coordinate value from the 520 geospatial location information. 522 9. Example 524 This section gives two simple examples for authorization policy rules 525 that make use of the civic and the geospatial location condition. 527 9.1. Rule Example with Civic Location Condition 529 This example illustrates a single rule that employs the civic 530 location condition which matches if the current location of the 531 target is inside the area specified by the child elements of the 532 element. The syntax of this content complies 533 with the 'civicAddress' complex type defined in [RFC4119]. In this 534 example, requests match only if the Target is at his main office in a 535 Siemens site in Munich. 537 The rule is valid for one year as specified by the 538 element. No actions are imposed on LSs. The 539 section indicates that LSs are allowed to distribute the LOs with 540 authorization policy included and the full set of civic location 541 information, and to pass latitude and longitude values of geospatial 542 location information on at quite a high level of resolution. Since 543 the policy does not contain a rule with a , 544 LSs have to delete LOs immediately upon service completion. 546 547 552 553 555 556 2004-11-01T00:00:00+01:00 557 2005-11-01T00:00:00+01:00 558 560 561 DE 562 Bavaria 563 Munich 564 Perlach 565 Otto-Hahn-Ring 566 6 567 569 571 573 574 true 575 576 true 577 578 full 579 580 581 0.00001 582 0.00001 583 584 585 586 588 9.2. Rule Example with Geospatial Location Information 590 This example illustrates a rule that employs the geospatial location 591 condition. The rule matches if the current location of the target is 592 inside the area specified by the child elements of the 593 element. The individual points of the polygon have to be 594 interpreted as points of the WGS-84 coordinate reference system, as 595 specified by the value of the 'crsName' attribute of the 596 element. This coordinate reference systems is also used by GPS. The 597 given four points specify a quadrangle on the surface of the 598 rotational ellipoid being part of the WGS-84 system, corresponding to 599 a certain area in Washington, DC, USA. 601 The transformation part of the example rule allows the location 602 server to distribute location objects from which all authorization 603 policy rules or pointers to them have been removed. The location 604 server is permitted to retain the location objects related to the 605 target for at most one hour. They are allowed to provide civic 606 location information about the target at city level of precision, and 607 geospatial location information at roughly the first decimal of 608 precision. 610 611 616 618 620 621 2004-11-01T00:00:00+01:00 622 2005-11-01T00:00:00+01:00 623 625 626 628 629 38.8986 630 -77.03724 631 632 633 38.8986 634 -77.03722 636 637 638 38.8987 639 -77.03722 640 641 642 38.8987 643 -77.03724 644 645 646 648 650 652 653 true 654 656 657 false 658 660 661 3600 662 664 city 666 667 0.2 668 0.1 669 671 673 675 677 The next ruleset indicates that the target has to be at an altitude 678 between 1500 and 4000 meters in order for this rule to match. 680 681 686 688 690 691 2004-11-01T00:00:00+01:00 692 2005-11-01T00:00:00+01:00 693 695 696 697 1500.0 698 4000.0 699 700 702 704 706 707 true 708 710 711 false 712 714 715 3600 716 718 city 720 721 0.3 722 0.2 723 725 727 729 731 10. XML Schema 733 This section presents the XML schema that defines the geo policy 734 language described in the previous sections. The policy markup 735 language introduced by this schema extends the common policy markup 736 language (see[I-D.ietf-geopriv-common-policy]) by introducing new 737 members of the 'condition' and 'transformation' substitution groups 738 whose heads (namely the elements and ) 739 are specified by the common policy schema ([I-D.ietf-geopriv-common- 740 policy]). 742 To express civic location conditions, it imports the 'civicAddress' 743 complex type as defined in [RFC4119]. 745 746 755 756 758 759 760 762 763 764 765 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 787 789 790 791 793 795 798 801 803 804 805 806 807 808 809 810 811 812 813 815 816 817 818 820 822 824 825 827 829 831 11. Security Considerations 833 This document aims to make it simple for users to prevent the 834 unintended disclosure of private information to third parties. 835 Security threats are described in [RFC3694] and are applicable to 836 this draft as well. Security requirements are addressed in 837 [RFC3693]. Section 5 addresses issues of protecting the policy rules 838 within the location object and location information itself. Aspects 839 of combining permissions in cases of multiple occurrence are treated 840 in [I-D.ietf-geopriv-common-policy]). How the behavior of location 841 servers can be regulated in terms of location object handling in a 842 privacy-safe fashion is specified in Section 8. 844 12. References 846 12.1. Normative References 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", March 1997. 851 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 852 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 854 [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, 855 "Threat Analysis of the Geopriv Protocol", RFC 3694, 856 February 2004. 858 12.2. Informative References 860 [GML] OpenGIS, "OpenGIS Geography Markup Language (GML) 861 Implementation Specification, Version 3.00, OGC 02 023r4", 862 http://www.opengeospatial.org/docs/02-023r4.pdf, 863 January 2003. 865 [I-D.ietf-geopriv-common-policy] 866 Schulzrinne, H., "A Document Format for Expressing Privacy 867 Preferences", draft-ietf-geopriv-common-policy-06 (work in 868 progress), October 2005. 870 [I-D.ietf-geopriv-dhcp-civil] 871 Schulzrinne, H., "Dynamic Host Configuration Protocol 872 (DHCPv4 and DHCPv6) Option for Civic Addresses 873 Configuration Information", 874 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 875 January 2006. 877 [I-D.ietf-simple-xcap] 878 Rosenberg, J., "The Extensible Markup Language (XML) 879 Configuration Access Protocol (XCAP)", 880 draft-ietf-simple-xcap-08 (work in progress), 881 October 2005. 883 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 884 Jensen, "HTTP Extensions for Distributed Authoring -- 885 WEBDAV", RFC 2518, February 1999. 887 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 888 Presence and Instant Messaging", RFC 2778, February 2000. 890 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 891 Configuration Protocol Option for Coordinate-based 892 Location Configuration Information", RFC 3825, July 2004. 894 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 895 Format", RFC 4119, December 2005. 897 Appendix A. Contributors 899 We would like to thank Christian Guenther for his help with an 900 earlier version of this document. 902 Appendix B. Acknowledgments 904 This document is informed by the discussions within the IETF GEOPRIV 905 working group, including discussions at the GEOPRIV interim meeting 906 in Washington, D.C., in 2003. 908 We particularly want to thank Allison Mankin , 909 Randall Gellens , Andrew Newton 910 , Ted Hardie , Jon 911 Peterson for their help in improving the 912 quality of this document. 914 Authors' Addresses 916 Henning Schulzrinne 917 Columbia University 918 Department of Computer Science 919 450 Computer Science Building 920 New York, NY 10027 921 USA 923 Phone: +1 212 939 7042 924 Email: schulzrinne@cs.columbia.edu 925 URI: http://www.cs.columbia.edu/~hgs 927 Hannes Tschofenig 928 Siemens 929 Otto-Hahn-Ring 6 930 Munich, Bavaria 81739 931 Germany 933 Email: Hannes.Tschofenig@siemens.com 934 URI: http://www.tschofenig.com 936 John B. Morris, Jr. 937 Center for Democracy and Technology 938 1634 I Street NW, Suite 1100 939 Washington, DC 20006 940 USA 942 Email: jmorris@cdt.org 943 URI: http://www.cdt.org 945 Jorge R. Cuellar 946 Siemens 947 Otto-Hahn-Ring 6 948 Munich, Bavaria 81739 949 Germany 951 Email: Jorge.Cuellar@siemens.com 952 James Polk 953 Cisco 954 2200 East President George Bush Turnpike 955 Richardson, Texas 75082 956 USA 958 Email: jmpolk@cisco.com 960 Intellectual Property Statement 962 The IETF takes no position regarding the validity or scope of any 963 Intellectual Property Rights or other rights that might be claimed to 964 pertain to the implementation or use of the technology described in 965 this document or the extent to which any license under such rights 966 might or might not be available; nor does it represent that it has 967 made any independent effort to identify any such rights. Information 968 on the procedures with respect to rights in RFC documents can be 969 found in BCP 78 and BCP 79. 971 Copies of IPR disclosures made to the IETF Secretariat and any 972 assurances of licenses to be made available, or the result of an 973 attempt made to obtain a general license or permission for the use of 974 such proprietary rights by implementers or users of this 975 specification can be obtained from the IETF on-line IPR repository at 976 http://www.ietf.org/ipr. 978 The IETF invites any interested party to bring to its attention any 979 copyrights, patents or patent applications, or other proprietary 980 rights that may cover technology that may be required to implement 981 this standard. Please address the information to the IETF at 982 ietf-ipr@ietf.org. 984 Disclaimer of Validity 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Copyright Statement 996 Copyright (C) The Internet Society (2006). This document is subject 997 to the rights, licenses and restrictions contained in BCP 78, and 998 except as set forth therein, the authors retain all their rights. 1000 Acknowledgment 1002 Funding for the RFC Editor function is currently provided by the 1003 Internet Society.