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
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,