idnits 2.17.1
draft-ietf-geopriv-pidf-lo-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 13.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1047.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1024.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1031.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1037.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1053), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 35.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 69 instances of too long lines in the document, the longest
one being 10 characters in excess of 72.
** There are 32 instances of lines with control characters in the document.
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
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 9, 2004) is 7140 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 831, but no explicit reference
was found in the text
== Unused Reference: '14' is defined on line 877, but no explicit reference
was found in the text
** Obsolete normative reference: RFC 3851 (ref. '5') (Obsoleted by RFC 5751)
** Obsolete normative reference: RFC 3852 (ref. '6') (Obsoleted by RFC 5652)
** Obsolete normative reference: RFC 3211 (ref. '9') (Obsoleted by RFC
3369, RFC 3370)
== Outdated reference: A later version (-04) exists of
draft-ietf-geopriv-reqs-03
-- Obsolete informational reference (is this intentional?): RFC 2396 (ref.
'14') (Obsoleted by RFC 3986)
-- No information found for draft-ietf-geopriv-threats - is the name
correct?
-- Obsolete informational reference (is this intentional?): RFC 3850 (ref.
'18') (Obsoleted by RFC 5750)
Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: March 10, 2005 September 9, 2004
5 A Presence-based GEOPRIV Location Object Format
6 draft-ietf-geopriv-pidf-lo-03
8 Status of this Memo
10 By submitting this Internet-Draft, I certify that any applicable
11 patent or other IPR claims of which I am aware have been disclosed,
12 and any of which I become aware will be disclosed, in accordance with
13 RFC 3668.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as
18 Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on March 10, 2005.
33 Copyright Notice
35 Copyright (C) The Internet Society (2004). All Rights Reserved.
37 Abstract
39 This document describes an object format for carrying geographical
40 information on the Internet. This location object extends the
41 Presence Information Data Format (PIDF), which was designed for
42 communicating privacy-sensitive presence information and which has
43 similar properties.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Location Object Format . . . . . . . . . . . . . . . . . . . . 4
49 2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . 4
50 2.2 Extensions to PIDF for Location and Usage Rules . . . . . 5
51 2.2.1 'location-info' element . . . . . . . . . . . . . . . 5
52 2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . 7
53 2.2.3 'method' element . . . . . . . . . . . . . . . . . . . 9
54 2.2.4 'provided-by' element . . . . . . . . . . . . . . . . 9
55 2.2.5 Schema definitions . . . . . . . . . . . . . . . . . . 10
56 2.3 Example Location Objects . . . . . . . . . . . . . . . . . 13
57 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . . 15
58 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . . 15
59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
61 6.1 'method' tokens . . . . . . . . . . . . . . . . . . . . . 17
62 6.2 'provided-by' elements . . . . . . . . . . . . . . . . . . 18
63 6.3 URN Sub-Namespace Registration for
64 urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . 18
65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
66 A. NENA Provided-By Schema . . . . . . . . . . . . . . . . . . . 21
67 A.1 dataProvider XML Schema . . . . . . . . . . . . . . . . . 22
68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
69 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
70 7.2 Informative References . . . . . . . . . . . . . . . . . . . 20
71 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
72 Intellectual Property and Copyright Statements . . . . . . . . 24
74 1. Introduction
76 Geographical location information describes a physical position in
77 the world that may correspond to the past, present or future location
78 of a person, event or device. Numerous applications used in the
79 Internet today benefit from sharing location information (including
80 mapping/navigation applications, 'friend finders' on cell phones, and
81 so on). However, such applications may disclose the whereabouts of a
82 person in a manner contrary to the user's preferences. Privacy
83 lapses may result from poor protocol security (which permits
84 eavesdroppers to capture location information), inability to
85 articulate or accommodate user preferences, or similar defects common
86 in existing systems. The privacy concerns surrounding the unwanted
87 disclosure of a person's physical location are among the more serious
88 that confront users on the Internet.
90 Consequently, a need has been identified to convey geographical
91 location information within an object that includes a user's privacy
92 and disclosure preferences and which is protected by strong
93 cryptographic security. Previous work [13] has observed that this
94 problem bears some resemblance to the general problem of
95 communicating and securing presence information on the Internet.
96 Presence (which is defined in [12]) provides a real-time
97 communications disposition for a user, and thus has similar
98 requirements for selective distribution and security.
100 Therefore, this document extends the XML-based Presence Information
101 Data Format (PIDF [2]) to allow the encapsulation of location
102 information within a presence document.
104 This document does not invent any format for location information
105 itself. Numerous existing formats based on civil location,
106 geographic coordinates, and the like have been developed in other
107 standards fora. Instead, this document defines an object that is
108 suitable for both identifying and encapsulating pre-existing location
109 information formats, and for providing adequate security and policy
110 controls to regulate the distribution of location information over
111 the Internet.
113 The location object described in this document can be used
114 independently of any 'using protocol', as the term is defined in the
115 GEOPRIV requirements [10]. It is considered an advantage of this
116 proposal that existing presence protocols (such as [15]) would
117 natively accommodate the location object format defined in this
118 document, and be capable of composing location information with other
119 presence information, since this location object is an extension of
120 PIDF. However, the usage of this location object format is not
121 limited to presence using protocols - any protocol that can carry XML
122 or MIME types can carry PIDF.
124 Some of the requirements in [10] and [11] concern data collection and
125 usage policies associated with location objects. This document
126 provides only the minimum markup necessary for a user to express the
127 necessary privacy preferences as specified by the GEOPRIV
128 requirements (the three basic elements in [11]). However, this
129 document does not demonstrate how a full XML-based ruleset
130 accommodating the needs of Location Servers could be embedded in PIDF
131 - it is assumed that other protocols (such as HTTP) will be used to
132 move rules between Rule Holders and Location Servers, and that full
133 rulesets will be defined in a separate document.
135 2. Location Object Format
137 2.1 Baseline PIDF Usage
139 The GEOPRIV requirements [10] (or REQ for short) specify the need for
140 a name for the person, place or thing that location information
141 describes (REQ 2.1). PIDF has such an identifier already, since
142 every PIDF document has an "entity" attribute of the 'presence'
143 element that signifies the URI of the entity whose presence the
144 document describes. Consequently, if location information is
145 contained in a PIDF document, the URI in the "entity" attribute of
146 the 'presence' element indicates the target of that location
147 information (the 'presentity'). The URI in the "entity" attribute
148 generally uses the "pres" URI scheme defined in [3]. Such URIs can
149 serve as unlinkable pseudonyms (per REQ 12).
151 PIDF optionally contains a 'contact' element that provides a URI
152 where the presentity can be reached by some means of communication
153 (usually, the URI scheme in the value of the 'contact' element gives
154 some sense of how the presentity can be reached: if it uses the SIP
155 URI scheme, for example, SIP can be used, and so on). Location
156 information can be provided without any associated means of
157 communication - thus, the 'contact' element may or may not be
158 present, as desired by the creator of the PIDF document.
160 PIDF optionally contains a 'timestamp' element that designates the
161 time at which the PIDF document was created. This element
162 corresponds to REQ 2.7a.
164 PIDF contains a 'status' element, which is mandatory. 'status'
165 contains an optional child element 'basic' that describes the
166 presentity's communications disposition (in very broad terms: either
167 OPEN or CLOSED). For the purposes of this document, it is not
168 necessary for 'basic' status to be included. If, however,
169 communications disposition is included in a PIDF document above and
170 beyond geolocation, then 'basic' status may appear in a PIDF document
171 that uses these extensions.
173 PIDF also contains a 'tuple' umbrella element, which holds an "id"
174 element used to uniquely identify a segment of presence information
175 so that changes to this information can be tracked over time (as
176 multiple notifications of presence are received). 'timestamp',
177 'status', and 'contact' are composed under 'tuple'.
179 2.2 Extensions to PIDF for Location and Usage Rules
181 This XML Schema extends the 'status' element of PIDF with a complex
182 element called 'geopriv'. There are two major subelements that are
183 encapsulated within geopriv: one for location information, and one
184 for usage rules. Both of these subelements are mandatory, and are
185 described in subsequent sections. By composing these two subelements
186 under 'geopriv', the usage rules are clearly and explicitly
187 associated with the location information.
189 For extensibility (see REQ 1.4), the schema allows any other
190 subelements to appear under the 'geopriv' element. Two other
191 optional subelements are included in this document: one that
192 indicates the method by which geographical location was determined,
193 and one that allows an explicit designation of the entity that
194 provided the information.
196 2.2.1 'location-info' element
198 Each 'geopriv' element MUST contain one 'location-info' element. A
199 'location-info' element consists of one or more chunks of location
200 information (per REQ 2.5). The format of the location information
201 (REQ 2.6) is identified by the imported XML Schema describing the
202 namespace in question. All PIDF documents that contain a 'geopriv'
203 element MUST contain one or more import directives indicating the XML
204 Schema(s) that are used for geographic location formats.
206 In order to ensure interoperability of GEOPRIV implementations, it is
207 necessary to select a baseline location format that all compliant
208 implementations support (see REQ 3.1). Since it satisfies REQ 2.5.1,
209 this document works from the assumption that GML 3.0 [16] shall be
210 this mandatory format (a MUST implement for all PIDF implementations
211 supporting the 'geopriv' element).
213 The Geography Markup Language (GML) is an extraordinarily thorough
214 and versatile system for modeling all manner of geographic object
215 types, topologies, metadata, coordinate reference systems and units
216 of measurement. The simplest package for GML supporting location
217 information is the 'feature.xsd' schema. Although 'feature.xsd' can
218 express complicated geographical concepts, it requires very little
219 markup to provide basic coordinates points for the most common use
220 cases. Various format descriptions (including latitude/longitude
221 based location information) are supported by Feature (see section
222 7.4.1.4 of [16] for examples), which resides here:
224 urn:opengis:specification:gml:schema-xsd:feature:v3.0
226 Note that by importing the Feature schema, necessary GML baseline
227 schemas are transitively imported.
229 Complex features (such as modeling topologies and polygons,
230 directions and vectors, temporal indications of the time for which a
231 particular location is valid for a target) are also available in GML,
232 but require importing additional schemas. For the purposes of
233 baseline interoperability as defined by this document, only support
234 for the 'feature.xsd' GML schema is REQUIRED.
236 Implementations MAY support the civil location format (civilLoc)
237 defined in Section 2.2.5. civilLoc provides the following elements:
239 +----------------------+----------------------+---------------------+
240 | Label | Description | Example |
241 +----------------------+----------------------+---------------------+
242 | country | The country is | US |
243 | | identified by the | |
244 | | two-letter ISO 3166 | |
245 | | code. | |
246 | | | |
247 | A1 | national | New York |
248 | | subdivisions (state, | |
249 | | region, province, | |
250 | | prefecture) | |
251 | | | |
252 | A2 | county, parish, gun | King's County |
253 | | (JP), district (IN) | |
254 | | | |
255 | A3 | city, township, shi | New York |
256 | | (JP) | |
257 | | | |
258 | A4 | city division, | Manhattan |
259 | | borough, city | |
260 | | district, ward, chou | |
261 | | (JP) | |
262 | | | |
263 | A5 | neighborhood, block | Morningside Heights |
264 | | | |
265 | A6 | street | Broadway |
266 | | | |
267 | PRD | Leading street | N, W |
268 | | direction | |
269 | | | |
270 | POD | Trailing street | SW |
271 | | suffix | |
272 | | | |
273 | STS | Street suffix | Avenue, Platz, |
274 | | | Street |
275 | | | |
276 | HNO | House number, | 123 |
277 | | numeric part only. | |
278 | | | |
279 | HNS | House number suffix | A, 1/2 |
280 | | | |
281 | LMK | Landmark or vanity | Low Library |
282 | | address | |
283 | | | |
284 | LOC | Additional location | Room 543 |
285 | | information | |
286 | | | |
287 | FLR | Floor | 5 |
288 | | | |
289 | NAM | Name (residence, | Joe's Barbershop |
290 | | business or office | |
291 | | occupant) | |
292 | | | |
293 | PC | Postal code | 10027-0401 |
294 +----------------------+----------------------+---------------------+
296 Either the GML 3.0 geographical information format element, or the
297 location format element ('civilLoc') defined in this document, MAY
298 appear in in a 'location-info' element. Both MAY also be used in the
299 same 'location-info' element. In summary, the feature.xsd schema of
300 GML 3.0 MUST be supported by implementations compliant with this
301 specification, and the civilLoc format MAY be supported by
302 implementations compliant with this specification.
304 2.2.2 'usage-rules' element
306 At the time this document was written, the policy requirements for
307 GEOPRIV objects were not definitively completed. However, the
308 'usage-rules' element exists to satisfy REQ 2.8, and the requirements
309 of the GEOPRIV policy requirements [11] document. Each 'geopriv'
310 element MUST contain one 'usage-rules' element, even if the Rule
311 Maker has requested that all subelements be given their default
312 values.
314 Following the policy requirements document (Section 3.1), there are
315 three fields that need to be expressible in Location Objects
316 throughout their lifecycle (from Generator to Recipient): one field
317 that limits retransmission, one that limits retention, and one that
318 contains a reference to external rulesets. Those three fields are
319 instantiated here by the first three elements. The fourth element
320 provides a generic space for human-readable policy directives. Any
321 of these fields MAY be present in a Location Object 'usage-rules'
322 element; none are required to be.
323 'retransmission-allowed': When the value of this element is 'no',
324 the Recipient of this Location Object is not permitted to share
325 the enclosed Location Information, or the object as a whole, with
326 other parties. When the value of this element is 'yes',
327 distributing this Location is permitted (barring an existing
328 out-of-band agreement or obligation to the contrary). By default,
329 the value MUST be assumed to be 'no'. Implementations MUST
330 include this field, with a value of 'no', if the Rule Maker
331 specifies no preference.
332 'retention-expires': This field specifies an absolute date at
333 which time the Recipient is no longer permitted to possess the
334 location information and its encapsulating Location Object - both
335 may be retained only up until the time specified by this field.
336 By default, the value MUST be assumed to be twenty-four hours from
337 the 'timestamp' element in the PIDF document, if present; if the
338 'timestamp' element is also not present, then twenty-four hours
339 from the time at which the Location Object is received by the
340 Location Recipient. If the value in the 'retention-expires'
341 element has already passed when the Location Recipient receives
342 the Location Object, the Recipient MUST discard the Location
343 Object immediately.
344 'ruleset-reference': This field contains a URI that indicates
345 where a fuller ruleset of policies related to this object can be
346 found. This URI SHOULD use the HTTPS URI scheme, and if it does,
347 the server that holds these rules MUST authenticate any attempt to
348 access these rules - usage rules themselves may divulge private
349 information about a Target or Rule Maker. The URI MAY
350 alternatively use the CID URI scheme [7], in which case it MUST
351 denote a MIME body carried with the Location Object by the using
352 protocol. Rulesets carried as MIME bodies SHOULD be encrypted and
353 signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored
354 by Location Servers or Location Recipients. Note that in order to
355 avoid network lookups that result in an authorization failure,
356 creators of Location Objects MAY put HTTPS-based
357 ruleset-references into an encrypted external MIME body referenced
358 by a CID; in this way, recipients of the Location Object that are
359 unable to decrypt the external MIME body will not learn the HTTPS
360 URI unless they are able to decrypt the MIME body.
361 'note-well': This field contains a block of text containing
362 further generic privacy directives. These directives are intended
363 to be human-readable only, not to be processed by any automaton.
365 2.2.3 'method' element
367 The optional 'method' element describes the way that the location
368 information was derived or discovered. An example of this element
369 (for a geographical position system) is:
371
See RFCXXXX.
823 824 825 END 827 7. References 829 7.1 Normative References 831 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 832 levels", RFC 2119, March 1997. 834 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 835 J. Peterson, "Presence Information Data Format (PIDF)", RFC 836 3863, August 2004. 838 [3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 839 October 2003. 841 [4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 842 2004. 844 [5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/ 845 MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 847 [6] Housley, R., "Cryptographic Message Syntax", RFC RFC3852, July 848 2004. 850 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 851 Locators", RFC 2392, August 1998. 853 [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) 854 Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 855 3565, July 2003. 857 [9] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 858 December 2001. 860 7.2 Informative References 862 [10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 863 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 864 in progress), February 2003. 866 [11] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 867 Protections for Geopriv Location Object", 868 draft-morris-geopriv-core-02 (work in progress), June 2003. 870 [12] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 871 Instant Messaging", RFC 2778, February 2000. 873 [13] Peterson, J., "A Presence Architecture for the Distribution of 874 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 875 in progress), February 20003. 877 [14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 878 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 879 1998. 881 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 882 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 883 Session Initiation Protocol", RFC 3261, May 2002. 885 [16] OpenGIS, "Open Geography Markup Language (GML) Implementation 886 Specification", OGC 02-023r4, January 2003, 887See RFCXXXX.
945 946 947 END 949 A.1 dataProvider XML Schema 951 952 954