idnits 2.17.1
draft-peterson-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 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 (June 22, 2003) is 7615 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 491, but no explicit reference
was found in the text
== Unused Reference: '12' is defined on line 531, 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 (-07) exists of
draft-ietf-smime-aes-alg-06
== Outdated reference: A later version (-04) exists of
draft-ietf-geopriv-reqs-03
== Outdated reference: A later version (-02) exists of
draft-morris-geopriv-core-01
-- Obsolete informational reference (is this intentional?): RFC 2396 (ref.
'12') (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.
'17') (Obsoleted by RFC 3369, RFC 3370)
Summary: 3 errors (**), 0 flaws (~~), 11 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: December 21, 2003 June 22, 2003
6 A Presence-based GEOPRIV Location Object Format
7 draft-peterson-geopriv-pidf-lo-00
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 December 21, 2003.
32 Copyright Notice
34 Copyright (C) The Internet Society (2003). All Rights Reserved.
36 Abstract
38 This document describes a 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 has similar
42 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 Privacy Policy . . . . . 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 . . . . . . . . . . . . . . . . . . 8
54 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . 9
55 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 13
61 A. To Do and Unmet requirements . . . . . . . . . . . . . . . . 14
62 Normative References . . . . . . . . . . . . . . . . . . . . 12
63 Informative References . . . . . . . . . . . . . . . . . . . 12
64 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
65 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
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 [11] has observed that this
87 problem bears some resembles to the general problem of communicating
88 and securing presence information on the Internet. Presence (which
89 is defined in [10]) provides a real-time communications disposition
90 to a user that have similar requirements for selective distribution
91 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 [8]. It is considered an advantage of this
109 proposal that existing presence protocols (such as [13]) 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, any protocol that can carry XML or MIME types can
114 carry PIDF.
116 Some of the requirements in [8] concern data collection and usage
117 policies associated with location objects. This document does not
118 provide a markup suitable for a user to express the necessary privacy
119 preferences as specified by the geopriv requirements. However, this
120 document does demonstrate how an XML-based privacy preference
121 document could be embedded within a PIDF document.
123 2. Location Object Format
125 2.1 Baseline PIDF Usage
127 The GEOPRIV requirements [8] (or REQ for short throughout this
128 section) specify the need for a name for the person, place or thing
129 that location information describes (REQ 2.1). PIDF has such an
130 identifier already, since every PIDF document has "entity" attribute
131 of the "presence" element that signifies the URI of the entity whose
132 presence the document describes. Similarly, if location information
133 is contained in a PIDF document, the URI in the "entity" attribute of
134 the "presence" element indicates the target of that location
135 information. The URI in the "entity" attribute should use the "pres"
136 URI scheme defined in [3]. URIs can serve as "unlinkable pseudonyms"
137 (per REQ 12).
139 PIDF optionally contains a "contact" element that contains a URI
140 where the presentity can be reached by some means of communication
141 (usually, the URI scheme in the value of the "contact" element gives
142 some sense of how the presentity can be reached: if it uses the SIP
143 URI scheme, for example, SIP can be used, and so on). Location
144 information can be provided without any associated means of
145 communication - thus, the "contact" element may or may not be
146 present, as desired by the creator of the PIDF document.
148 PIDF optionally contains a "timestamp" element that designates the
149 time at which the PIDF was created. This element corresponds to REQ
150 2.7a.
152 PIDF contains a "status" element, which is mandatory. "status"
153 contains an optional child element "basic" that describes the
154 presentity's communications disposition (in the very broad terms:
155 either OPEN or CLOSED). For the purposes of this document, it is not
156 necessary for "basic" status to be included. If, however,
157 communications disposition is included in a PIDF document above and
158 beyond geolocation, then "basic" status may appear in a PIDF document
159 that uses these extensions.
161 PIDF also contains a "tuple" element, which is used to uniquely
162 identify a segment of presence information so that changes to this
163 information can be tracked over time (as multiple notifications of
164 presence are received).
166 2.2 Extensions to PIDF for Location and Privacy Policy
168 This XML Schema extends the "status" element of PIDF with a complex
169 element called "geopriv". There are two major subelements that are
170 encapsulated within geopriv: one for location information, and one
171 for usage rules. Both of these subelements are mandatory, and are
172 described in subsequent sections.
174 There are also a few other elements which are contained within the
175 geopriv element in support of the GEOPRIV requirements.
177 2.2.1 'location-info' element
179 Each 'geopriv' element MUST contain one 'location-info' element. A
180 'location-info' element consists of one or more chunks of location
181 information (per REQ 2.5). The format of the location information
182 (REQ 2.6) is identified by the imported XML Schema describing the
183 namespace in question. All PIDF documents that contain a 'geopriv'
184 element MUST contain one or more import directive indicating the XML
185 Schema(s) that will be used as geolocation formats.
187 In order to ensure interoperability of GEOPRIV implementations, it is
188 necessary to select a baseline location format that all compliant
189 implementations support (see REQ 3.1). At this time, there is not
190 sufficient working group consensus within the GEOPRIV WG to award
191 this distinction to any particular location format. Without applying
192 any particular selection criteria (apart from REQs 2.5.1), this
193 document works from the assumption that GML 3.0 [14] will be this
194 mandatory format (MUST implement for all PIDF implementations
195 supporting the 'geopriv' element).
197 The Geography Markup Language (GML) is an extraordinarily thorough
198 and versatile system for modeling all manner of geographic topologies
199 and objects. The simplest package for GML supporting location
200 information is the 'feature.xsd' schema. Various format descriptions
201 (including latitude/longitude based location information) is
202 supported by Feature (see section 7.4.1.4 of [14] for examples).
203 This resides here:
205 urn:opengis:specification:gml:schema-xsd:feature:v3.0
206
208 Note that by importing the Feature schema, necessary GML baseline
209 schemas are transitively imported.
211 Complex features (such as modeling topologies and polygons,
212 directions and vectors, temporal indications of the time for which a
213 particular location is valid for a target) are also available in GML,
214 but require importing additional schemas. For the purposes of this
215 document, only support for the feature.xsd GML schema is REQUIRED.
217 2.2.2 'usage-rules' element
219 At the time this document was written, the policy requirements for
220 GEOPRIV objects were not definitively completed. However, the
221 'usage-rules' element exists to satisfy REQ 2.8, and the requirements
222 of the GEOPRIV policy requirements [9] document. Each 'geopriv'
223 element SHOULD contain one 'usage-rules' element - Location
224 Generators MAY not include this element ONLY IF users have
225 specifically requested that all sub-elements given below are
226 unnecessary to protect this Location Object.
228 Following to that document (Section 3.1), there are three fields that
229 need to be expressible in Location Objects throughout their lifecycle
230 (from Generator to Recipient): one field that limit retransmission,
231 one that limit retention, and one that contains a reference to
232 external rulesets. Those three fields are instantiated here by the
233 first three elements. The fourth element provides a generic space
234 for human-readable policy directives. Any of these fields MAY be
235 present in a Location Object 'usage-rules' element; none are required
236 to be.
238 'retransmission-allowed': When the value of this element is 'no',
239 the Recipient of this Location Object is not permitted to share
240 the enclosed Location Information, or the object as a whole, with
241 other parties. When the value of this element is 'yes', sharing
242 this Location Object or information is permitted (barring an
243 existing agreement or obligation to the contrary). By default,
244 the value MUST be assumed to be 'no'. Implementations MUST
245 include this field, with a value of 'no', if the Rule Maker
246 specifies no preference.
248 'retention-expires': This field specifies an absolute date at
249 which time the Recipient is no longer permitted to possess the
250 location information and its encapsulating Location Object - both
251 may be retained only up until the time specified by this field.
252 By default, the value MUST be assumed to be twenty-four hours from
253 the 'timestamp' element in the PIDF document, if present; if the
254 'timestamp' element is not present, then twenty-four hours from
255 the time at which the Location Object is received. If the value
256 in the 'retention-expires' element has already passed when the
257 Location Recipient receives the Location Object, the Recipient
258 MUST discard the Location Object immediately.
260 'ruleset-reference': This field contains a URI to a network server
261 that holds rules appropriate for this Location Object. This
262 SHOULD be an HTTPS URI, and the server that holds these rules MUST
263 authenticate any attempt to access these rules - usage rules
264 themselves may divulge private information about a Target or Rule
265 Maker. Location Recipients SHOULD NOT attempt to dereference this
266 URI - it is intended only for the consumption of Location Servers.
268 'note-well': This field contains a block of text containing
269 further generic privacy directives. These directives are intended
270 to be human-readable only, not to be processed by any automaton.
272 2.2.3 Schema definition
274 Note that the XML namespace [4] for this extension to PIDF contains a
275 version number 1.0 (as per REQ 2.10).
277
278
See RFCXXXX.
485 486 487 END 489 Normative References 491 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 492 levels", RFC 2119, March 1997. 494 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 495 J. Peterson, "CPIM Presence Information Data Format", draft- 496 ietf-impp-cpim-pidf-07 (work in progress), August 2001. 498 [3] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf- 499 impp-pres-03 (work in progress), May 2003. 501 [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana- 502 xmlns-registry-05 (work in progress), June 2003. 504 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 505 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 507 [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 508 2002. 510 [7] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm 511 and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 512 (work in progress), January 2003. 514 Informative References 516 [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 517 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 518 in progress), February 2003. 520 [9] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 521 Protections for Geopriv Location Object", draft-morris-geopriv- 522 core-01 (work in progress), March 2003. 524 [10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 525 Instant Messaging", RFC 2778, February 2000. 527 [11] Peterson, J., "A Presence Architecture for the Distribution of 528 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 529 in progress), February 20003. 531 [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 532 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 533 1998. 535 [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 536 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 537 Session Initiation Protocol", RFC 3261, May 2002. 539 [14] OpenGIS, "", OGC 02-023r4, January 2003,