idnits 2.17.1 draft-ietf-geopriv-pidf-lo-00.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 (January 12, 2004) is 7403 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 683, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 726, 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: July 12, 2004 January 12, 2004 5 A Presence-based GEOPRIV Location Object Format 6 draft-ietf-geopriv-pidf-lo-00 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 July 12, 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 . . . . . . . . . . . . . . . . . . 11 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 369 371 372 373 375 377 379 380 382 383 384 386 387 389 391 The 'geopriv10' schema imports, for the 'usage-rules' element, the 392 following policy schema. This schema has been broken out from the 393 basic geolocation object in order to allow for its reuse. The 394 semantics associated with these elements described in Section 2.2.2 395 apply only to the use of these elements to define policy for 396 geolocation objects; any other use of 'usage-rules' must characterize 397 its own semantics for all 'usage-rules' subelements. 399 400 406 407 408 410 412 414 416 418 419 421 422 423 424 425 426 427 429 431 The following schema is a trivial representation of civil location 432 that MAY be implemented by entities compliant with this 433 specification. 435 436 441 442 443 445 447 449 451 453 455 457 459 461 463 465 467 469 471 473 475 477 479 480 482 484 2.3 Example Location Objects 486 Note that these examples show PIDF documents without any MIME headers 487 or security applied to them (see Section 4 below). 489 The following XML instance document is an example of the use of a 490 simple GML 3.0 markup with a few of the policy directives specified 491 above within a PIDF document. 493 494 498 499 2003-06-22T20:57:29Z 500 501 502 503 504 505 31:56:00S 115:50:00E 506 507 508 509 510 no 511 2003-06-23T04:57:29Z 512 513 514 515 516 518 The following XML instance document is an example of the use of the 519 civilLoc object with a few of the policy directives specified above 520 within a PIDF document. 522 523 527 528 2003-06-22T20:57:29Z 529 530 531 532 533 US 534 New York 535 New York 536 Broadway 537 123 538 Suite 75 539 10027-0401 540 541 542 543 yes 544 2003-06-23T04:57:29Z 545 546 547 548 549 551 3. Carrying PIDF in a Using Protocol 553 A PIDF document is an XML document, and therefore PIDF might be 554 carried in any protocol that is capable of carrying XML. A MIME type 555 has also been registered for PIDF: 'application/cpim-pidf+xml'. PIDF 556 may therefore be carried as a MIME body in protocols that use MIME 557 (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME 558 headers, including a Content-Type of 'application/cpim-pidf+xml". 560 Further specification of the behavior of using protocols (including 561 subscribing to or requesting presence information) is outside the 562 scope of this document. 564 4. Securing PIDF 566 There are a number of ways in which XML documents can be secured. 567 XML itself supports several ways of partially securing documents, 568 including element-level encryption and digital signature properties. 570 For the purposes of this document, only the securing of a PIDF 571 document as a whole, rather than element-by-element security, is 572 considered. None of the requirements [9] suggest that only part of 573 the information in a location object might need to be protected while 574 other parts are unprotected - virtually any such configuration would 575 introduce potentials for privacy leakage. Consequently, the use of 576 MIME-level security is appropriate. 578 S/MIME [5] allows security properties (including confidentiality, 579 integrity and authentication properties) to be applied to the 580 contents of a MIME body. Therefore, all PIDF implementations that 581 support the XML Schema extensions for location information described 582 in this document MUST support S/MIME, and in particular must support 583 the CMS [6] EnvelopedData and SignedData messages, which are used for 584 encryption and digital signatures respectively. It is believed that 585 this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, 14.4. 587 Additionally, all compliant applications MUST implement the AES 588 encryption algorithm for S/MIME, as specified in [8] (and per REQ 589 15.1). Of course, implementations MUST also support the baseline 590 encryption and digital signature algorithms described in the S/MIME 591 specification. 593 S/MIME generally entails the use of X.509 [17] certificates. In 594 order to encrypt a request for a particular destination end-to-end 595 (i.e. to a Location Recipient), the Location Generator must possess 596 credentials (typically an X.509 certificate) that have been issued to 597 the Location Recipient. Implementations of this specification SHOULD 598 support X.509 certificates for S/MIME, and MUST support password- 599 based CMS encryption (see [18]). Any symmetric keying systems SHOULD 600 derive high-entropy content encoding keys (CEKs). When X.509 601 certificates are used to sign PIDF Location Objects, the 602 subjectAltName of the certificate SHOULD use the "pres" URI scheme. 604 S/MIME was designed for end-to-end security between email peers that 605 communicate through multiple servers (i.e mail transfer agents) that 606 do not modify message bodies. There is, however, at least one 607 instance in which Location Servers modify Location Objects - namely 608 when Location Servers enforce policies on behalf of the Rule Maker. 609 For example, a Rule Maker may specify that Location Information 610 should be coarsened (made less specific) before it is transmitted to 611 particular recipients. If the Location Server were unable to modify 612 a Location Object, because it was encrypted, signed, or both, it 613 would be unable to accomplish this function. Consequently, when a 614 Location Generator wants to allow a Location Server to modify such 615 messages, they MAY encrypt such messages with a key that can be 616 decrypted the Location Server (the digital signature, of course, can 617 still be created with keying material from the Location Generator's 618 certificate). After modifying the Location Object, the Location 619 Server can re-sign the Object with its own credentials (encrypting it 620 with any keys issued to the Location Recipient, if they are known to 621 the Server). 623 Note that policies for data collection and usage of location 624 information, in so far as they are carried within a location object, 625 are discussed in Section 2.2.2. 627 5. Security Considerations 629 The threats to which an Internet service carrying geolocation might 630 be subjected are detailed in [16]. The requirements that were 631 identified in that analysis of the threat model were incorporated 632 into [9], in particular within Section 7.4. This document aims to be 633 compliant with the security requirements derived from those two 634 undertakings in so far as they apply to the location object itself 635 (as opposed to the using protocol). 637 Security of the location object defined in this document, including 638 normative requirements for implementations, is discussed in Section 639 4. This security focuses on end-to-end integrity and confidentiality 640 properties that are applied to a location object for its lifetime via 641 S/MIME. 643 Security requirements associated with using protocols (including 644 authentication of subscribers to geographical information, and so on) 645 are outside the scope of this document. 647 6. IANA Considerations 649 6.1 URN Sub-Namespace Registration for 650 urn:ietf:params:xml:ns:pidf:geopriv10 652 This section registers a new XML namespace, as per the guidelines in 653 [4]. 655 URI: The URI for this namespace is 656 urn:ietf:params:xml:ns:pidf:geopriv10. 658 Registrant Contact: IETF, GEOPRIV working group, 659 (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). 661 XML: 663 BEGIN 664 665 667 668 669 671 GEOPRIV PIDF Extensions 672 673 674

PIDF Extensions of Geographical Information and Privacy

675

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

676

See RFCXXXX.

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