idnits 2.17.1 draft-ietf-geopriv-pidf-lo-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 62 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 3, 2004) is 7388 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: '1' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 732, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 == Outdated reference: A later version (-09) exists of draft-ietf-smime-rfc2633bis-03 ** Obsolete normative reference: RFC 3369 (ref. '6') (Obsoleted by RFC 3852) == Outdated reference: A later version (-04) exists of draft-ietf-geopriv-reqs-03 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '13') (Obsoleted by RFC 3986) -- No information found for draft-ietf-geopriv-threats - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. '18') (Obsoleted by RFC 3369, RFC 3370) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GEOPRIV WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: August 3, 2004 February 3, 2004 5 A Presence-based GEOPRIV Location Object Format 6 draft-ietf-geopriv-pidf-lo-01 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 3, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes an object format for carrying geographical 38 information on the Internet. This location object extends the 39 Presence Information Data Format (PIDF), which was designed for 40 communicating privacy-sensitive presence information and which has 41 similar properties. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Location Object Format . . . . . . . . . . . . . . . . . . . 4 47 2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . . 4 48 2.2 Extensions to PIDF for Location and Usage Rules . . . . . . 5 49 2.2.1 'location-info' element . . . . . . . . . . . . . . . . . . 5 50 2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . . . . 7 51 2.2.3 Schema definitions . . . . . . . . . . . . . . . . . . . . . 9 52 2.3 Example Location Objects . . . . . . . . . . . . . . . . . . 12 53 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . 13 54 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . 13 55 5. Security Considerations . . . . . . . . . . . . . . . . . . 15 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 57 6.1 URN Sub-Namespace Registration for 58 urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . . 15 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 60 A. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 61 Normative References . . . . . . . . . . . . . . . . . . . . 16 62 Informative References . . . . . . . . . . . . . . . . . . . 16 63 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 66 1. Introduction 68 Geographical location information describes a physical position in 69 the world that may correspond to the past, present or future location 70 of a person, event or device. Numerous applications used in the 71 Internet today benefit from sharing location information (including 72 mapping/navigation applications, 'friend finders' on cell phones, and 73 so on). However, such applications may disclose the whereabouts of a 74 person in a manner contrary to the user's preferences. Privacy 75 lapses may result from poor protocol security (which permits 76 eavesdroppers to capture location information), inability to 77 articulate or accommodate user preferences, or similar defects common 78 in existing systems. The privacy concerns surrounding the unwanted 79 disclosure of a person's physical location are among the more serious 80 that confront users on the Internet. 82 Consequently, a need has been identified to convey geographical 83 location information within an object that includes a user's privacy 84 and disclosure preferences and which is protected by strong 85 cryptographic security. Previous work [12] has observed that this 86 problem bears some resemblance to the general problem of 87 communicating and securing presence information on the Internet. 88 Presence (which is defined in [11]) provides a real-time 89 communications disposition for a user, and thus has similar 90 requirements for selective distribution and security. 92 Therefore, this document extends the XML-based Presence Information 93 Data Format (PIDF [2]) to allow the encapsulation of location 94 information within a presence document. 96 This document does not invent any format for location information 97 itself. Numerous existing formats based on civil location, 98 geographic coordinates, and the like have been developed in other 99 standards fora. Instead, this document defines an object that is 100 suitable for both identifying and encapsulating pre-existing location 101 information formats, and for providing adequate security and policy 102 controls to regulate the distribution of location information over 103 the Internet. 105 The location object described in this document can be used 106 independently of any 'using protocol', as the term is defined in the 107 GEOPRIV requirements [9]. It is considered an advantage of this 108 proposal that existing presence protocols (such as [14]) would 109 natively accommodate the location object format defined in this 110 document, and be capable of composing location information with other 111 presence information, since this location object is an extension of 112 PIDF. However, the usage of this location object format is not 113 limited to presence using protocols - any protocol that can carry XML 114 or MIME types can carry PIDF. 116 Some of the requirements in [9] and [10] concern data collection and 117 usage policies associated with location objects. This document 118 provides only the minimum markup necessary for a user to express the 119 necessary privacy preferences as specified by the geopriv 120 requirements (the three basic elements in [10]). However, this 121 document does not demonstrate how a full XML-based ruleset 122 accommodating the needs of Location Servers could be embedded in PIDF 123 - it is assumed that other protocols (such as HTTP) will be used to 124 move rules between Rule Holders and Location Servers, and that full 125 rulesets will be defined in a separate document. 127 2. Location Object Format 129 2.1 Baseline PIDF Usage 131 The GEOPRIV requirements [9] (or REQ for short) specify the need for 132 a name for the person, place or thing that location information 133 describes (REQ 2.1). PIDF has such an identifier already, since 134 every PIDF document has an "entity" attribute of the 'presence' 135 element that signifies the URI of the entity whose presence the 136 document describes. Consequently, if location information is 137 contained in a PIDF document, the URI in the "entity" attribute of 138 the 'presence' element indicates the target of that location 139 information (the 'presentity'). The URI in the "entity" attribute 140 generally uses the "pres" URI scheme defined in [3]. Such URIs can 141 serve as unlinkable pseudonyms (per REQ 12). 143 PIDF optionally contains a 'contact' element that provides a URI 144 where the presentity can be reached by some means of communication 145 (usually, the URI scheme in the value of the 'contact' element gives 146 some sense of how the presentity can be reached: if it uses the SIP 147 URI scheme, for example, SIP can be used, and so on). Location 148 information can be provided without any associated means of 149 communication - thus, the 'contact' element may or may not be 150 present, as desired by the creator of the PIDF document. 152 PIDF optionally contains a 'timestamp' element that designates the 153 time at which the PIDF document was created. This element 154 corresponds to REQ 2.7a. 156 PIDF contains a 'status' element, which is mandatory. 'status' 157 contains an optional child element 'basic' that describes the 158 presentity's communications disposition (in the very broad terms: 159 either OPEN or CLOSED). For the purposes of this document, it is not 160 necessary for 'basic' status to be included. If, however, 161 communications disposition is included in a PIDF document above and 162 beyond geolocation, then 'basic' status may appear in a PIDF document 163 that uses these extensions. 165 PIDF also contains a 'tuple' umbrella element, which holds an "id" 166 element used to uniquely identify a segment of presence information 167 so that changes to this information can be tracked over time (as 168 multiple notifications of presence are received). 'timestamp', 169 'status', and 'contact' are composed under 'tuple'. 171 2.2 Extensions to PIDF for Location and Usage Rules 173 This XML Schema extends the 'status' element of PIDF with a complex 174 element called 'geopriv'. There are two major subelements that are 175 encapsulated within geopriv: one for location information, and one 176 for usage rules. Both of these subelements are mandatory, and are 177 described in subsequent sections. By composing this two subelements 178 under 'geopriv', the usage rules are clearly and explicitly 179 associated with the location information. 181 For extensibility (see REQ 1.4), the schema allows any other 182 subelements to appear under the 'geopriv' element. No such 183 subelements are currently envisioned by this document. 185 2.2.1 'location-info' element 187 Each 'geopriv' element MUST contain one 'location-info' element. A 188 'location-info' element consists of one or more chunks of location 189 information (per REQ 2.5). The format of the location information 190 (REQ 2.6) is identified by the imported XML Schema describing the 191 namespace in question. All PIDF documents that contain a 'geopriv' 192 element MUST contain one or more import directives indicating the XML 193 Schema(s) that will be used for geographic location formats. 195 In order to ensure interoperability of GEOPRIV implementations, it is 196 necessary to select a baseline location format that all compliant 197 implementations support (see REQ 3.1). Since it satisfies REQ 2.5.1, 198 this document works from the assumption that GML 3.0 [15] shall be 199 this mandatory format (a MUST implement for all PIDF implementations 200 supporting the 'geopriv' element). 202 The Geography Markup Language (GML) is an extraordinarily thorough 203 and versatile system for modeling all manner of geographic object 204 types, topologies, metadata, coordinate reference systems and units 205 of measurement. The simplest package for GML supporting location 206 information is the 'feature.xsd' schema. Various format descriptions 207 (including latitude/longitude based location information) are 208 supported by Feature (see section 7.4.1.4 of [15] for examples), 209 which resides here: 211 urn:opengis:specification:gml:schema-xsd:feature:v3.0 213 Note that by importing the Feature schema, necessary GML baseline 214 schemas are transitively imported. 216 Complex features (such as modeling topologies and polygons, 217 directions and vectors, temporal indications of the time for which a 218 particular location is valid for a target) are also available in GML, 219 but require importing additional schemas. For the purposes of 220 baseline interoperability has defined by this document, only support 221 for the 'feature.xsd' GML schema is REQUIRED. 223 Implementations MAY support the civil location format (civilLoc) 224 defined in Section 2.2.3. civilLoc provides the following elements: 226 +----------------------+----------------------+---------------------+ 227 | Label | Description | Example | 228 +----------------------+----------------------+---------------------+ 229 | country | The country is | US | 230 | | identified by the | | 231 | | two-letter ISO 3166 | | 232 | | code. | | 233 | | | | 234 | A1 | national | New York | 235 | | subdivisions (state, | | 236 | | region, province, | | 237 | | prefecture) | | 238 | | | | 239 | A2 | county, parish, gun | King's County | 240 | | (JP), district (IN) | | 241 | | | | 242 | A3 | city, township, shi | New York | 243 | | (JP) | | 244 | | | | 245 | A4 | city division, | Manhattan | 246 | | borough, city | | 247 | | district, ward, chou | | 248 | | (JP) | | 249 | | | | 250 | A5 | neighborhood, block | Morningside Heights | 251 | | | | 252 | A6 | street | Broadway | 253 | | | | 254 | PRD | Leading street | N, W | 255 | | direction | | 256 | | | | 257 | POD | Trailing street | SW | 258 | | suffix | | 259 | | | | 260 | STS | Street suffix | Avenue, Platz, | 261 | | | Street | 262 | | | | 263 | HNO | House number, | 123 | 264 | | numeric part only. | | 265 | | | | 266 | HNS | House number suffix | A, 1/2 | 267 | | | | 268 | LMK | Landmark or vanity | Low Library | 269 | | address | | 270 | | | | 271 | LOC | Additional location | Room 543 | 272 | | information | | 273 | | | | 274 | FLR | Floor | 5 | 275 | | | | 276 | NAM | Name (residence, | Joe's Barbershop | 277 | | business or office | | 278 | | occupant) | | 279 | | | | 280 | PC | Postal code | 10027-0401 | 281 +----------------------+----------------------+---------------------+ 283 Either the GML 3.0 geographical information format element, or the 284 location format element ('civilLoc') defined in this document, MAY 285 appear in in a 'location-info' element. Both MAY also be used in the 286 same 'location-info' element. In summary, the feature.xsd schema of 287 GML 3.0 MUST be support by implementations compliant with this 288 specification, and the civilLoc format MAY be supported by 289 implementations compliant with this specification. 291 2.2.2 'usage-rules' element 293 At the time this document was written, the policy requirements for 294 GEOPRIV objects were not definitively completed. However, the 295 'usage-rules' element exists to satisfy REQ 2.8, and the requirements 296 of the GEOPRIV policy requirements [10] document. Each 'geopriv' 297 element SHOULD contain one 'usage-rules' element - Location 298 Generators MAY opt not to include this element if the Rule Maker has 299 requested that all sub-elements given below have their default 300 values. 302 Following the policy requirements document (Section 3.1), there are 303 three fields that need to be expressible in Location Objects 304 throughout their lifecycle (from Generator to Recipient): one field 305 that limits retransmission, one that limits retention, and one that 306 contains a reference to external rulesets. Those three fields are 307 instantiated here by the first three elements. The fourth element 308 provides a generic space for human-readable policy directives. Any 309 of these fields MAY be present in a Location Object 'usage-rules' 310 element; none are required to be. 312 'retransmission-allowed': When the value of this element is 'no', 313 the Recipient of this Location Object is not permitted to share 314 the enclosed Location Information, or the object as a whole, with 315 other parties. When the value of this element is 'yes', 316 distributing this Location is permitted (barring an existing out- 317 of-band agreement or obligation to the contrary). By default, the 318 value MUST be assumed to be 'no'. Implementations MUST include 319 this field, with a value of 'no', if the Rule Maker specifies no 320 preference. 322 'retention-expires': This field specifies an absolute date at 323 which time the Recipient is no longer permitted to possess the 324 location information and its encapsulating Location Object - both 325 may be retained only up until the time specified by this field. 326 By default, the value MUST be assumed to be twenty-four hours from 327 the 'timestamp' element in the PIDF document, if present; if the 328 'timestamp' element is also not present, then twenty-four hours 329 from the time at which the Location Object is received by the 330 Location Recipient. If the value in the 'retention-expires' 331 element has already passed when the Location Recipient receives 332 the Location Object, the Recipient MUST discard the Location 333 Object immediately. 335 'ruleset-reference': This field contains a URI that indicates 336 where a fuller ruleset of policies related to this object can be 337 found. This URI SHOULD use the HTTPS URI scheme, and if it does, 338 the server that holds these rules MUST authenticate any attempt to 339 access these rules - usage rules themselves may divulge private 340 information about a Target or Rule Maker. The URI MAY 341 alternatively use the CID URI scheme [7], in which case it MUST 342 denote a MIME body carried with the Location Object by the using 343 protocol. Rulesets carried as MIME bodies SHOULD be encrypted and 344 signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored 345 by Location Servers or Location Recipients. Note that in order to 346 avoid network lookups that result in an authorization failure, 347 creators of Location Objects MAY put HTTPS-based ruleset- 348 references into an encrypted external MIME body referenced by a 349 CID; in this way, recipients of the Location Object that are 350 unable to decrypt the external MIME body will not learn the HTTPS 351 URI unless they are able to decrypt the MIME body. 353 'note-well': This field contains a block of text containing 354 further generic privacy directives. These directives are intended 355 to be human-readable only, not to be processed by any automaton. 357 2.2.3 Schema definitions 359 Note that the XML namespace [4] for this extension to PIDF contains a 360 version number 1.0 (as per REQ 2.10). 362 363 370 372 373 374 376 378 380 381 383 384 385 387 388 390 392 The 'geopriv10' schema imports, for the 'usage-rules' element, the 393 following policy schema. This schema has been broken out from the 394 basic geolocation object in order to allow for its reuse. The 395 semantics associated with these elements described in Section 2.2.2 396 apply only to the use of these elements to define policy for 397 geolocation objects; any other use of 'usage-rules' must characterize 398 its own semantics for all 'usage-rules' subelements. 400 401 407 408 411 412 413 415 417 419 421 423 424 426 427 428 429 430 431 432 434 436 The following schema is a trivial representation of civil location 437 that MAY be implemented by entities compliant with this 438 specification. 440 441 447 448 449 451 453 455 457 459 461 463 465 467 469 471 473 475 477 479 481 483 485 486 488 490 2.3 Example Location Objects 492 Note that these examples show PIDF documents without any MIME headers 493 or security applied to them (see Section 4 below). 495 The following XML instance document is an example of the use of a 496 simple GML 3.0 markup with a few of the policy directives specified 497 above within a PIDF document. 499 500 504 505 506 507 508 509 510 31:56:00S 115:50:00E 511 512 513 514 515 no 516 2003-06-23T04:57:29Z 517 518 519 520 2003-06-22T20:57:29Z 521 522 524 The following XML instance document is an example of the use of the 525 civilLoc object with a few of the policy directives specified above 526 within a PIDF document. 528 529 533 534 535 536 537 538 US 539 New York 540 New York 541 Broadway 542 123 543 Suite 75 544 10027-0401 545 546 547 548 yes 549 2003-06-23T04:57:29Z 550 551 552 553 2003-06-22T20:57:29Z 554 555 557 3. Carrying PIDF in a Using Protocol 559 A PIDF document is an XML document, and therefore PIDF might be 560 carried in any protocol that is capable of carrying XML. A MIME type 561 has also been registered for PIDF: 'application/cpim-pidf+xml'. PIDF 562 may therefore be carried as a MIME body in protocols that use MIME 563 (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME 564 headers, including a Content-Type of 'application/cpim-pidf+xml". 566 Further specification of the behavior of using protocols (including 567 subscribing to or requesting presence information) is outside the 568 scope of this document. 570 4. Securing PIDF 572 There are a number of ways in which XML documents can be secured. 573 XML itself supports several ways of partially securing documents, 574 including element-level encryption and digital signature properties. 576 For the purposes of this document, only the securing of a PIDF 577 document as a whole, rather than element-by-element security, is 578 considered. None of the requirements [9] suggest that only part of 579 the information in a location object might need to be protected while 580 other parts are unprotected - virtually any such configuration would 581 introduce potentials for privacy leakage. Consequently, the use of 582 MIME-level security is appropriate. 584 S/MIME [5] allows security properties (including confidentiality, 585 integrity and authentication properties) to be applied to the 586 contents of a MIME body. Therefore, all PIDF implementations that 587 support the XML Schema extensions for location information described 588 in this document MUST support S/MIME, and in particular must support 589 the CMS [6] EnvelopedData and SignedData messages, which are used for 590 encryption and digital signatures respectively. It is believed that 591 this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, 14.4. 593 Additionally, all compliant applications MUST implement the AES 594 encryption algorithm for S/MIME, as specified in [8] (and per REQ 595 15.1). Of course, implementations MUST also support the baseline 596 encryption and digital signature algorithms described in the S/MIME 597 specification. 599 S/MIME generally entails the use of X.509 [17] certificates. In 600 order to encrypt a request for a particular destination end-to-end 601 (i.e. to a Location Recipient), the Location Generator must possess 602 credentials (typically an X.509 certificate) that have been issued to 603 the Location Recipient. Implementations of this specification SHOULD 604 support X.509 certificates for S/MIME, and MUST support password- 605 based CMS encryption (see [18]). Any symmetric keying systems SHOULD 606 derive high-entropy content encoding keys (CEKs). When X.509 607 certificates are used to sign PIDF Location Objects, the 608 subjectAltName of the certificate SHOULD use the "pres" URI scheme. 610 S/MIME was designed for end-to-end security between email peers that 611 communicate through multiple servers (i.e mail transfer agents) that 612 do not modify message bodies. There is, however, at least one 613 instance in which Location Servers modify Location Objects - namely 614 when Location Servers enforce policies on behalf of the Rule Maker. 615 For example, a Rule Maker may specify that Location Information 616 should be coarsened (made less specific) before it is transmitted to 617 particular recipients. If the Location Server were unable to modify 618 a Location Object, because it was encrypted, signed, or both, it 619 would be unable to accomplish this function. Consequently, when a 620 Location Generator wants to allow a Location Server to modify such 621 messages, they MAY encrypt such messages with a key that can be 622 decrypted the Location Server (the digital signature, of course, can 623 still be created with keying material from the Location Generator's 624 certificate). After modifying the Location Object, the Location 625 Server can re-sign the Object with its own credentials (encrypting it 626 with any keys issued to the Location Recipient, if they are known to 627 the Server). 629 Note that policies for data collection and usage of location 630 information, in so far as they are carried within a location object, 631 are discussed in Section 2.2.2. 633 5. Security Considerations 635 The threats to which an Internet service carrying geolocation might 636 be subjected are detailed in [16]. The requirements that were 637 identified in that analysis of the threat model were incorporated 638 into [9], in particular within Section 7.4. This document aims to be 639 compliant with the security requirements derived from those two 640 undertakings in so far as they apply to the location object itself 641 (as opposed to the using protocol). 643 Security of the location object defined in this document, including 644 normative requirements for implementations, is discussed in Section 645 4. This security focuses on end-to-end integrity and confidentiality 646 properties that are applied to a location object for its lifetime via 647 S/MIME. 649 Security requirements associated with using protocols (including 650 authentication of subscribers to geographical information, and so on) 651 are outside the scope of this document. 653 6. IANA Considerations 655 6.1 URN Sub-Namespace Registration for 656 urn:ietf:params:xml:ns:pidf:geopriv10 658 This section registers a new XML namespace, as per the guidelines in 659 [4]. 661 URI: The URI for this namespace is 662 urn:ietf:params:xml:ns:pidf:geopriv10. 664 Registrant Contact: IETF, GEOPRIV working group, 665 (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). 667 XML: 669 BEGIN 670 671 673 674 675 677 GEOPRIV PIDF Extensions 678 679 680

PIDF Extensions of Geographical Information and Privacy

681

urn:ietf:params:xml:ns:pidf:geopriv10

682

See RFCXXXX.

683 684 685 END 687 Normative References 689 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 690 levels", RFC 2119, March 1997. 692 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 693 J. Peterson, "CPIM Presence Information Data Format", draft- 694 ietf-impp-cpim-pidf-07 (work in progress), August 2001. 696 [3] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf- 697 impp-pres-04 (work in progress), October 2003. 699 [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana- 700 xmlns-registry-05 (work in progress), June 2003. 702 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 703 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 705 [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 706 2002. 708 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 709 Locators", RFC 2392, August 1998. 711 [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) 712 Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 713 3565, July 2003. 715 Informative References 717 [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 718 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 719 in progress), February 2003. 721 [10] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 722 Protections for Geopriv Location Object", draft-morris-geopriv- 723 core-02 (work in progress), June 2003. 725 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 726 Instant Messaging", RFC 2778, February 2000. 728 [12] Peterson, J., "A Presence Architecture for the Distribution of 729 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 730 in progress), February 20003. 732 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 733 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 734 1998. 736 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 737 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 738 Session Initiation Protocol", RFC 3261, May 2002. 740 [15] OpenGIS, "Open Geography Markup Language (GML) Implementation 741 Specification", OGC 02-023r4, January 2003, . 744 [16] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat 745 Analysis of the geopriv Protocol", draft-ietf-geopriv-threats- 746 00 (work in progress), February 2003. 748 [17] ITU-T, "Recommendation X.509 - Open Systems Interconnection - 749 The Directory: Authentication", ITU-T X.509, June 1997, . 752 [18] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 753 December 2001. 755 Author's Address 757 Jon Peterson 758 NeuStar, Inc. 759 1800 Sutter St 760 Suite 570 761 Concord, CA 94520 762 US 764 Phone: +1 925/363-8720 765 EMail: jon.peterson@neustar.biz 766 URI: http://www.neustar.biz/ 768 Appendix A. To Do 770 XML Schemas and examples have not been validated. 772 Appendix B. Acknowledgments 774 This document was produced with the assistance of many members of the 775 GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS 776 for a close read of the document. 778 The civil location format described in this document was proposed by 779 Henning Schulzrinne for communicating location information in DHCP, 780 and has been appropriated in its entirety for this document. 782 Full Copyright Statement 784 Copyright (C) The Internet Society (2004). All Rights Reserved. 786 This document and translations of it may be copied and furnished to 787 others, and derivative works that comment on or otherwise explain it 788 or assist in its implementation may be prepared, copied, published 789 and distributed, in whole or in part, without restriction of any 790 kind, provided that the above copyright notice and this paragraph are 791 included on all such copies and derivative works. However, this 792 document itself may not be modified in any way, such as by removing 793 the copyright notice or references to the Internet Society or other 794 Internet organizations, except as needed for the purpose of 795 developing Internet standards in which case the procedures for 796 copyrights defined in the Internet Standards process must be 797 followed, or as required to translate it into languages other than 798 English. 800 The limited permissions granted above are perpetual and will not be 801 revoked by the Internet Society or its successors or assigns. 803 This document and the information contained herein is provided on an 804 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 805 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 806 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 807 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 808 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 810 Acknowledgement 812 Funding for the RFC Editor function is currently provided by the 813 Internet Society.