idnits 2.17.1
draft-peterson-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 4 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 (September 2, 2003) is 7533 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 509, but no explicit reference
was found in the text
== Unused Reference: '13' is defined on line 552, 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 (-04) exists of
draft-ietf-impp-pres-03
== 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 (~~), 9 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV WG J. Peterson
3 Internet-Draft NeuStar
4 Expires: March 2, 2004 September 2, 2003
6 A Presence-based GEOPRIV Location Object Format
7 draft-peterson-geopriv-pidf-lo-01
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that
16 other groups may also distribute working documents as Internet-
17 Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at http://
25 www.ietf.org/ietf/1id-abstracts.txt.
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 This Internet-Draft will expire on March 2, 2004.
32 Copyright Notice
34 Copyright (C) The Internet Society (2003). All Rights Reserved.
36 Abstract
38 This document describes an object format for carrying geographical
39 information on the Internet. This location object extends the
40 Presence Information Data Format (PIDF), which was designed for
41 communicating privacy-sensitive presence information and which has
42 similar properties.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
47 2. Location Object Format . . . . . . . . . . . . . . . . . . . 4
48 2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . . 4
49 2.2 Extensions to PIDF for Location and Usage Rules . . . . . . 5
50 2.2.1 'location-info' element . . . . . . . . . . . . . . . . . . 5
51 2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . . . . 6
52 2.2.3 Schema definition . . . . . . . . . . . . . . . . . . . . . 7
53 2.3 Example Location Object . . . . . . . . . . . . . . . . . . 9
54 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . 9
55 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . 10
56 5. Security Considerations . . . . . . . . . . . . . . . . . . 11
57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
58 6.1 URN Sub-Namespace Registration for
59 urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . . 11
60 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
61 A. To Do and Unmet requirements . . . . . . . . . . . . . . . . 14
62 Normative References . . . . . . . . . . . . . . . . . . . . 12
63 Informative References . . . . . . . . . . . . . . . . . . . 12
64 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
65 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
67 1. Introduction
69 Geographical location information describes a physical position in
70 the world that may correspond to the past, present or future location
71 of a person or device. Numerous applications used in the Internet
72 today benefit from sharing location information (including mapping/
73 navigation applications, 'friend finders' on cell phones, and so on).
74 However, such applications may disclose the whereabouts of a person
75 in a manner contrary to the user's preferences. Privacy lapses may
76 result from poor protocol security (which permits eavesdroppers to
77 capture location information), inability to articulate or accommodate
78 user preferences, or similar defects common in existing systems. The
79 privacy concerns surrounding the unwanted disclosure of a person's
80 physical location are among the more serious that confront users on
81 the Internet.
83 Consequently, a need has been identified to convey geographical
84 location information within an object that includes a user's privacy
85 and disclosure preferences and which is protected by strong
86 cryptographic security. Previous work [12] has observed that this
87 problem bears some resemblance to the general problem of
88 communicating and securing presence information on the Internet.
89 Presence (which is defined in [11]) provides a real-time
90 communications disposition for a user, and thus has similar
91 requirements for selective distribution and security.
93 Therefore, this document extends the XML-based Presence Information
94 Data Format (PIDF [2]) to allow the encapsulation of location
95 information within a presence document.
97 This document does not invent any format for location information
98 itself. Numerous already existing formats based on civil location,
99 spatial coordinates, and the like have been developed in other
100 standards fora. Instead, this document defines an object that is
101 suitable for both identifying and encapsulating pre-existing location
102 information formats, and for providing adequate security and policy
103 controls to regulate the distribution of location information over
104 the Internet.
106 The location object described in this document can be used
107 independently of any 'using protocol', as the term is defined in the
108 GEOPRIV requirements [9]. It is considered an advantage of this
109 proposal that existing presence protocols (such as [14]) would
110 natively accommodate the location object format defined in this
111 document, and be capable of composing location information with other
112 presence information, since this location object is an extension of
113 PIDF. However, the usage of this location object format is not
114 limited to presence using protocols - any protocol that can carry XML
115 or MIME types can carry PIDF.
117 Some of the requirements in [9] and [10] concern data collection and
118 usage policies associated with location objects. This document
119 provides only the minimum markup necessary for a user to express the
120 necessary privacy preferences as specified by the geopriv
121 requirements (the three basic elements in [10]). However, this
122 document does not demonstrate how a full XML-based ruleset
123 accommodating the needs of Location Servers could be embedded in PIDF
124 - it is assumed that other protocols (such as HTTP) will be used to
125 move rules between Rule Holders and Location Servers, and that full
126 rulesets will be defined in a separate document.
128 2. Location Object Format
130 2.1 Baseline PIDF Usage
132 The GEOPRIV requirements [9] (or REQ for short throughout this
133 section) specify the need for a name for the person, place or thing
134 that location information describes (REQ 2.1). PIDF has such an
135 identifier already, since every PIDF document has an "entity"
136 attribute of the 'presence' element that signifies the URI of the
137 entity whose presence the document describes. Consequently, if
138 location information is contained in a PIDF document, the URI in the
139 "entity" attribute of the 'presence' element indicates the target of
140 that location information. The URI in the "entity" attribute
141 generally uses the "pres" URI scheme defined in [3]. Such URIs can
142 serve as unlinkable pseudonyms (per REQ 12).
144 PIDF optionally contains a 'contact' element that provides a URI
145 where the presentity can be reached by some means of communication
146 (usually, the URI scheme in the value of the 'contact' element gives
147 some sense of how the presentity can be reached: if it uses the SIP
148 URI scheme, for example, SIP can be used, and so on). Location
149 information can be provided without any associated means of
150 communication - thus, the 'contact' element may or may not be
151 present, as desired by the creator of the PIDF document.
153 PIDF optionally contains a 'timestamp' element that designates the
154 time at which the PIDF document was created. This element
155 corresponds to REQ 2.7a.
157 PIDF contains a 'status' element, which is mandatory. 'status'
158 contains an optional child element 'basic' that describes the
159 presentity's communications disposition (in the very broad terms:
160 either OPEN or CLOSED). For the purposes of this document, it is not
161 necessary for 'basic' status to be included. If, however,
162 communications disposition is included in a PIDF document above and
163 beyond geolocation, then 'basic' status may appear in a PIDF document
164 that uses these extensions.
166 PIDF also contains a 'tuple' umbrella element, which holds an "id"
167 element used to uniquely identify a segment of presence information
168 so that changes to this information can be tracked over time (as
169 multiple notifications of presence are received). 'timestamp',
170 'status', and 'contact' are composed under 'tuple'.
172 2.2 Extensions to PIDF for Location and Usage Rules
174 This XML Schema extends the 'status' element of PIDF with a complex
175 element called 'geopriv'. There are two major subelements that are
176 encapsulated within geopriv: one for location information, and one
177 for usage rules. Both of these subelements are mandatory, and are
178 described in subsequent sections. By composing this two subelements
179 under 'geopriv', the usage rules are clearly and explicitly
180 associated with the location information.
182 For extensibility (see REQ 1.4), the schema allows any other
183 subelements to appear under the 'geopriv' element. No such
184 subelements are currently envisioned by this document.
186 2.2.1 'location-info' element
188 Each 'geopriv' element MUST contain one 'location-info' element. A
189 'location-info' element consists of one or more chunks of location
190 information (per REQ 2.5). The format of the location information
191 (REQ 2.6) is identified by the imported XML Schema describing the
192 namespace in question. All PIDF documents that contain a 'geopriv'
193 element MUST contain one or more import directives indicating the XML
194 Schema(s) that will be used as geolocation formats.
196 In order to ensure interoperability of GEOPRIV implementations, it is
197 necessary to select a baseline location format that all compliant
198 implementations support (see REQ 3.1). At this time, there is not
199 sufficient working group consensus within the GEOPRIV WG to award
200 this distinction to any particular location format. Without applying
201 any particular selection criteria (apart from REQs 2.5.1), this
202 document works from the assumption that GML 3.0 [15] will be this
203 mandatory format (a MUST implement for all PIDF implementations
204 supporting the 'geopriv' element).
206 The Geography Markup Language (GML) is an extraordinarily thorough
207 and versatile system for modeling all manner of geographic topologies
208 and objects. The simplest package for GML supporting location
209 information is the 'feature.xsd' schema. Various format descriptions
210 (including latitude/longitude based location information) are
211 supported by Feature (see section 7.4.1.4 of [15] for examples),
212 which resides here:
214 urn:opengis:specification:gml:schema-xsd:feature:v3.0
216 Note that by importing the Feature schema, necessary GML baseline
217 schemas are transitively imported.
219 Complex features (such as modeling topologies and polygons,
220 directions and vectors, temporal indications of the time for which a
221 particular location is valid for a target) are also available in GML,
222 but require importing additional schemas. For the purposes of
223 baseline interoperability has defined by this document, only support
224 for the 'feature.xsd' GML schema is REQUIRED.
226 2.2.2 'usage-rules' element
228 At the time this document was written, the policy requirements for
229 GEOPRIV objects were not definitively completed. However, the
230 'usage-rules' element exists to satisfy REQ 2.8, and the requirements
231 of the GEOPRIV policy requirements [10] document. Each 'geopriv'
232 element SHOULD contain one 'usage-rules' element - Location
233 Generators MAY opt not to include this element if the Rule Maker has
234 requested that all sub-elements given below have their default
235 values.
237 Following the policy requirements document (Section 3.1), there are
238 three fields that need to be expressible in Location Objects
239 throughout their lifecycle (from Generator to Recipient): one field
240 that limits retransmission, one that limits retention, and one that
241 contains a reference to external rulesets. Those three fields are
242 instantiated here by the first three elements. The fourth element
243 provides a generic space for human-readable policy directives. Any
244 of these fields MAY be present in a Location Object 'usage-rules'
245 element; none are required to be.
247 'retransmission-allowed': When the value of this element is 'no',
248 the Recipient of this Location Object is not permitted to share
249 the enclosed Location Information, or the object as a whole, with
250 other parties. When the value of this element is 'yes',
251 distributing this Location Location is permitted (barring an
252 existing out-of-band agreement or obligation to the contrary). By
253 default, the value MUST be assumed to be 'no'. Implementations
254 MUST include this field, with a value of 'no', if the Rule Maker
255 specifies no preference.
257 'retention-expires': This field specifies an absolute date at
258 which time the Recipient is no longer permitted to possess the
259 location information and its encapsulating Location Object - both
260 may be retained only up until the time specified by this field.
261 By default, the value MUST be assumed to be twenty-four hours from
262 the 'timestamp' element in the PIDF document, if present; if the
263 'timestamp' element is also not present, then twenty-four hours
264 from the time at which the Location Object is received by the
265 Location Recipient. If the value in the 'retention-expires'
266 element has already passed when the Location Recipient receives
267 the Location Object, the Recipient MUST discard the Location
268 Object immediately.
270 'ruleset-reference': This field contains a URI that indicates
271 where a fuller ruleset of policies related to this object can be
272 found. This URI SHOULD use the HTTPS URI scheme, and if it does,
273 the server that holds these rules MUST authenticate any attempt to
274 access these rules - usage rules themselves may divulge private
275 information about a Target or Rule Maker. The URI MAY
276 alternatively use the CID URI scheme [7], in which case it MUST
277 denote a MIME body carried with the Location Object by the using
278 protocol. Rulesets carried as MIME bodies SHOULD be encrypted and
279 signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored
280 by Location Servers or Location Recipients.
282 'note-well': This field contains a block of text containing
283 further generic privacy directives. These directives are intended
284 to be human-readable only, not to be processed by any automaton.
286 2.2.3 Schema definition
288 Note that the XML namespace [4] for this extension to PIDF contains a
289 version number 1.0 (as per REQ 2.10).
291
292
See RFCXXXX.
503 504 505 END 507 Normative References 509 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 510 levels", RFC 2119, March 1997. 512 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 513 J. Peterson, "CPIM Presence Information Data Format", draft- 514 ietf-impp-cpim-pidf-07 (work in progress), August 2001. 516 [3] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf- 517 impp-pres-03 (work in progress), May 2003. 519 [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana- 520 xmlns-registry-05 (work in progress), June 2003. 522 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 523 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 525 [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 526 2002. 528 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 529 Locators", RFC 2392, August 1998. 531 [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) 532 Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 533 3565, July 2003. 535 Informative References 537 [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 538 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 539 in progress), February 2003. 541 [10] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 542 Protections for Geopriv Location Object", draft-morris-geopriv- 543 core-02 (work in progress), June 2003. 545 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 546 Instant Messaging", RFC 2778, February 2000. 548 [12] Peterson, J., "A Presence Architecture for the Distribution of 549 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 550 in progress), February 20003. 552 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 553 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 554 1998. 556 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 557 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 558 Session Initiation Protocol", RFC 3261, May 2002. 560 [15] OpenGIS, "", OGC 02-023r4, January 2003,