1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Network Working Group J. Peterson
Request for Comments: 4079 NeuStar
Category: Informational July 2005
<span class="h1">A Presence Architecture for the</span>
<span class="h1">Distribution of GEOPRIV Location Objects</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
GEOPRIV defines the concept of a 'using protocol' -- a protocol that
carries GEOPRIV location objects. GEOPRIV also defines various
scenarios for the distribution of location objects that require the
concepts of subscriptions and asynchronous notifications. This
document examines some existing IETF work on the concept of presence,
shows how presence architectures map onto GEOPRIV architectures, and
moreover demonstrates that tools already developed for presence could
be reused to simplify the standardization and implementation of
GEOPRIV.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Framework Analysis ..............................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Presence Architecture for GEOPRIV ...............................<a href="#page-3">3</a>
<a href="#section-4">4</a>. GEOPRIV Extensions to PIDF ......................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. Acknowledgements ................................................<a href="#page-5">5</a>
<a href="#section-7">7</a>. Informative References ..........................................<a href="#page-6">6</a>
<span class="grey">Peterson Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
GEOPRIV is a standard for the transmission of location information
and privacy policies over the Internet. Location information is a
description of a particular spatial location, which may be
represented as coordinates (via longitude, latitude, and so on), as
civil addresses (such as postal addresses), or in other ways.
GEOPRIV focuses on the privacy and security issues, from both a
technology perspective and a policy perspective, of sharing location
information over the Internet; it essentially defines a secure
container class capable of carrying both location information and
policy data governing the distribution of this information. GEOPRIV
also defines the concept of a 'using protocol' -- a protocol that
carries the GEOPRIV location object.
Presence is a service defined in <a href="./rfc2778">RFC2778</a> [<a href="#ref-2" title=""A Model for Presence and Instant Messaging"">2</a>] that allows users of a
communications service to monitor one another's availability and
disposition in order to make decisions about communicating. Presence
information is highly dynamic, and it generally characterizes whether
a user is online or offline, busy or idle, away from communications
devices or nearby, and the like.
This document shows the applicability of presence to GEOPRIV and
shows that a presence protocol could be a suitable using protocol for
GEOPRIV. This document is not intended to demonstrate that presence
is the only method by which GEOPRIV location objects might be
distributed. However, there are numerous applications of GEOPRIV
that depend on the fundamental subscription/notification architecture
that also underlies presence.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Framework Analysis</span>
The GEOPRIV framework [<a href="#ref-1" title=""GEOPRIV requirements"">1</a>] defines four primary network entities: a
Location Generator, a Location Server, a Location Recipient, and a
Rule Holder. Three interfaces between these entities are defined,
including a publication interface and a notification interface.
GEOPRIV specifies that a 'using protocol' is employed to transport
location objects from one place to another. If the publication
interface and notification interface are network connections, then a
using protocol would be responsible for the transmission of the
location object. Location Recipients may request that a Location
Server provide them with GEOPRIV location information concerning a
particular Target. The Location Generator publishes Location
Information to a Location Server, which, in coordination with
policies set by the Rule Maker, distributes the location information
to Location Recipients as necessary.
<span class="grey">Peterson Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
The GEOPRIV requirements document shows three scenarios for the use
of the GEOPRIV protocol. In some of these scenarios (such as the
third), a Location Recipient sends some kind of message to the
Location Server to request the periodic transmission of location
information. The location of a GEOPRIV Target is likely to vary over
time (if the Target is a person, or something similarly mobile), and
consequently the concept of a persistent subscription to the location
of a Target resulting in periodic notification is valuable to
GEOPRIV. In other scenarios, a Location Recipient may request a one-
time notification of the geographical location of the Target.
GEOPRIV places few requirements on using protocols. However, it is
clear from the description above that there must be some mechanism
allowing Location Recipients to establish a persistent subscription
in order to receive regular notification of the geographical location
of a Target as their location changes over time. There must also be
a way for Location Generators to publish location information to a
Location Server that applies further policies for distribution.
This document adopts a model in which the using protocol is
responsible for requesting subscriptions, handling publications, and
sending notifications. There are other models for GEOPRIV in which
these operations might be built into location objects themselves.
However, there is a significant amount of pre-existing work in the
IETF related to managing publications, subscriptions, and
notifications for data sets that vary over time. In fact, these
concepts all correspond exactly to architectures for presence that
have been developed in support of real-time communications
applications such as instant messaging, voice and video sessions.
Note that in some GEOPRIV scenarios, the Location Recipient does not
actively request the location of a Target; rather, it receives an
unsolicited notification of Target's location. This document focuses
on the use of presence only for scenarios in which the Location
Recipient actively solicits location information. However, it is
possible that many of these base operations of the
subscription/notification framework of presence could be reused for
cases in which the Location Recipient is passive.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Presence Architecture for GEOPRIV</span>
The Common Profile for Presence [<a href="#ref-4" title=""Common Profile for Presence (CPP)"">4</a>] (CPP) defines a set of operations
for delivery of presence information. These primarily consist of
subscription operations and notification operations. A subscription
creates a persistent connection between a 'watcher' (which
corresponds to the Location Recipient of GEOPRIV) and a 'presentity'
(which corresponds roughly to the GEOPRIV target). When a watcher
subscribes to a presentity, a persistent connection is created;
<span class="grey">Peterson Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
notifications of presence information will henceforth be sent to the
watcher as the presence information changes. CPP also supports
unsubscriptions (terminating the persistent subscription) and fetches
(one-time requests for presence information that do not result in a
persistent subscription).
CPP provides a number of attributes of these operations that flesh
out the presence system. There is a system for automatically
expiring subscriptions if they are not refreshed at user-defined
intervals (in order to eliminate stale subscriptions). There are
transaction and subscription identifiers used to correlate messages,
and a URI scheme ("pres:") is defined to identify watchers and
presentities.
The IETF IMPP WG has also defined an XML data format for presence
information, called the Presence Information Data Format [<a href="#ref-5" title=""Presence Information Data Format (PIDF)"">5</a>] (PIDF).
PIDF is a body that is carried by presence protocols and that
contains presence information, including the current state of a
presentity. PIDF is discussed in more detail in <a href="#section-4">Section 4</a>.
At a high level, then, the presence architecture seems to have
considerable applicability to the problem of delivering GEOPRIV
information. However, the CPP framework is an abstract framework:
it doesn't actually specify a protocol, instead it specifies a
framework and a set of requirements to which presence protocols must
conform. Also, CPP does not define any concept similar to a Location
Server.
However, the IETF has standardized protocols that instantiate this
framework, such as SIMPLE [<a href="#ref-6" title=""A Presence Event Package for the Session Initiation Protocol (SIP)"">6</a>] and XMPP [<a href="#ref-7" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">7</a>]. XMPP and SIMPLE both
have architectural elements comparable to a Location Server: points
where presentities register their availability, and where policies
for distributing presence can be managed. The presence community has
also defined a policy protocol and schema set called XCAP [<a href="#ref-8" title=""The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)"">8</a>] through
which authorization policies can be provisioned in a presence server.
In summary, like GEOPRIV, presence requires an architecture for
publication, subscription, and notification for a mutable set of data
associated with a principal. Presence has already tackled many of
the harder issues associated with subscription management, including
subscription expiration, development of identifiers for principals,
and defining document formats for presence information. Rather than
reinvent work that has been done elsewhere in the IETF, GEOPRIV has
reused this existing work by specifying presence protocols as GEOPRIV
using protocols. Moreover, the existing foundational presence tools
developed in IMPP, such as PIDF, have immediate applicability to the
efforts underway in GEOPRIV to develop objects for sharing location
information.
<span class="grey">Peterson Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. GEOPRIV Extensions to PIDF</span>
As was mentioned above, the presence architecture developed in the
IETF IMPP WG has defined a format for presence information called
PIDF. PIDF is an XML format that provides presence information about
a presentity. Primarily, this consists of status information, but it
also optionally includes contact addresses (a way of reaching the
presentity), timestamps, and textual notes with arbitrary content.
PIDF is an extensible format. It defines an XML element for
representing the status of a presentity (the status element), and it
gives some guidance as to how this element might be extended.
Although the authors of PIDF viewed geographical location as a
potential category of presence information, baseline PIDF defines no
format for location information.
PIDF meets the security requirements given in <a href="./rfc2779">RFC2779</a> [<a href="#ref-3" title=""Instant Messaging / Presence Protocol Requirements"">3</a>] (see
especially sections <a href="#section-5.1">5.1</a>, <a href="#section-5.2">5.2</a>, and <a href="#section-5.3">5.3</a>), which parallel those of the
GEOPRIV location object given in the GEOPRIV requirements [<a href="#ref-1" title=""GEOPRIV requirements"">1</a>]. CPP
and PIDF specify mechanisms for mutual authentication of participants
in a presence exchange as well as for confidentiality and integrity
properties for presence information.
In short, many of the requirements of GEOPRIV objects map well onto
the capabilities of PIDF.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
GEOPRIV information, like presence information, has very sensitive
security requirements. The requirements of <a href="./rfc2779">RFC2779</a> [<a href="#ref-3" title=""Instant Messaging / Presence Protocol Requirements"">3</a>], which are
instantiated by CPP, PIDF, and XCAP, in addition to the various
derivative concrete presence protocols, such as XMPP and SIMPLE, map
well onto the security requirements of the GEOPRIV protocol, as
defined in the GEOPRIV requirements document and the GEOPRIV threat
analysis [<a href="#ref-9" title=""Threat Analysis of the GEOPRIV Protocol"">9</a>] document. Specifically, the presence security
requirements call for authentication of watchers, integrity and
confidentiality properties, and similar measures to prevent abuse of
presence information.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet
Sarikaya for their comments.
<span class="grey">Peterson Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Informative References</span>
[<a id="ref-1">1</a>] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "GEOPRIV requirements", <a href="./rfc3693">RFC 3693</a>, February 2004.
[<a id="ref-2">2</a>] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", <a href="./rfc2778">RFC 2778</a>, February 2000.
[<a id="ref-3">3</a>] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", <a href="./rfc2779">RFC 2779</a>, February 2000.
[<a id="ref-4">4</a>] Peterson, J., "Common Profile for Presence (CPP)", <a href="./rfc3859">RFC 3859</a>,
August 2004.
[<a id="ref-5">5</a>] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
<a href="./rfc3863">RFC 3863</a>, August 2004.
[<a id="ref-6">6</a>] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", <a href="./rfc3856">RFC 3856</a>, August 2004.
[<a id="ref-7">7</a>] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", <a href="./rfc3921">RFC 3921</a>, October
2004.
[<a id="ref-8">8</a>] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Work in Progress,
February 2004.
[<a id="ref-9">9</a>] Danley, M., Morris, J., Mulligan, D., and J. Peterson, "Threat
Analysis of the GEOPRIV Protocol", <a href="./rfc3694">RFC 3694</a>, February 2004.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St., Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: <a href="http://www.neustar.biz/">http://www.neustar.biz/</a>
<span class="grey">Peterson Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4079">RFC 4079</a> GEOPRIV Presence Arch July 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Informational [Page 7]
</pre>
|
