idnits 2.17.1 draft-ietf-geopriv-pres-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 330. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 346), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 8, 2004) is 7142 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: '5' is defined on line 265, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 286, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '11') (Obsoleted by RFC 3986) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 9, 2005 September 8, 2004 5 A Presence Architecture for the Distribution of GEOPRIV Location 6 Objects 7 draft-ietf-geopriv-pres-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 9, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 GEOPRIV defines the concept of a 'using protocol', a protocol that 41 carries GEOPRIV location objects. GEOPRIV also defines various 42 scenarios for the distribution of location objects that require the 43 concept of subscriptions and asynchronous notifications. This 44 document examines some existing IETF work on the concept of presence, 45 shows how presence architectures map onto GEOPRIV architectures, and 46 moreover demonstrates that tools already developed for presence could 47 be reused to simplify the standardization and implementation of 48 GEOPRIV. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Framework Analysis . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Presence Architecture for GEOPRIV . . . . . . . . . . . . . . 4 55 4. GEOPRIV Extensions to PIDF . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 60 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . 9 63 1. Introduction 65 GEOPRIV is a standard for the transmission of location information 66 and privacy policies over the Internet. Location information is a 67 description of a particular spatial location, which may be 68 represented as coordinates (via longitude, latitude, and so on), or 69 as civil addresses (such as postal addresses), or in other ways. 70 GEOPRIV focuses on the privacy and security issues, both from a 71 technology perspective and a policy perspective, of sharing location 72 information over the Internet; it essentially defines a secure 73 container class capable of carrying both location information and 74 policy data governing the distribution of this information. GEOPRIV 75 also defines the concept of a 'using protocol', a protocol that 76 carries the GEOPRIV location object. 78 Presence is a service defined in RFC2778 [2] that allows users of a 79 communications service to monitor one another's availability and 80 disposition in order to make decisions about communicating. Presence 81 information is highly dynamic, and generally characterizes whether a 82 user is online or offline, busy or idle, away from communications 83 devices or nearby, and the like. 85 This document shows the applicability of presence to GEOPRIV, and 86 shows that a presence protocol could be a suitable using protocol for 87 GEOPRIV. This document is not intended to demonstrate that presence 88 is the only method by which GEOPRIV location objects might be 89 distributed. However, there are numerous applications of GEOPRIV 90 that depend on the fundamental subscription/notification architecture 91 that also underlies presence. 93 2. Framework Analysis 95 The GEOPRIV framework [1] defines four primary network entities: a 96 Location Generator, a Location Server, a Location Recipient, and a 97 Rule Holder. Three interfaces between these entities are defined, 98 including a publication interface and a notification interface. 100 GEOPRIV specifies that a 'using protocol' is employed to transport 101 location objects from one place to another. If the publication 102 interface and notification interface are network connections, then a 103 using protocol would be responsible for the transmission of the 104 location object. Location Recipients may request that a Location 105 Server provide them with GEOPRIV location information concerning a 106 particular Target. The Location Generator publishes Location 107 Information to a Location Server, which, in coordination with 108 policies set by the Rule Maker, distributes the location information 109 to Location Recipients as necessary. 111 The GEOPRIV requirements document shows three scenarios for the use 112 of the GEOPRIV protocol. In some of these scenarios (such as the 113 third), a Location Recipient sends some kind of message to the 114 Location Server to request the periodic transmission of location 115 information. The location of a GEOPRIV Target is likely to vary over 116 time (if the Target is a person, or something similarly mobile) and 117 consequently the concept of a persistent subscription to the location 118 of a Target resulting in periodic notification is valuable to 119 GEOPRIV. In other scenarios, a Location Recipient may request a 120 one-time notification of the geographical location of the Target. 122 GEOPRIV places few requirements on using protocols. However, it is 123 clear from the description above that there must be some mechanism to 124 allow Location Recipients to establish a persistent subscription in 125 order to receive regular notification of the geographical location of 126 a Target as their location changes over time. There must also be a 127 way for Location Generators to publish location information to a 128 Location Server that applies further policies for distribution. 130 This document adopts a model in which the using protocol is 131 responsible for requesting subscriptions, handling publications, and 132 sending notifications. There are other models for GEOPRIV in which 133 such operations might be built into location objects themselves. 134 However, there is a significant amount of pre-existing work in the 135 IETF related to managing publications, subscriptions and 136 notifications for data sets that vary over time. In fact, these 137 concepts all correspond exactly to architectures for presence that 138 have been developed in support of real-time communications 139 applications such as instant messaging, voice and video sessions. 141 Note that there are some GEOPRIV scenarios in which the Location 142 Recipient does not actively request the location of a Target, but 143 rather it receives an unsolicited notification of Target's location. 144 This document focuses on the use of presence only for those scenarios 145 in which the Location Recipient actively solicits location 146 information. It is however possible that many of these base 147 operations of the subscription/notification framework of presence 148 could be reused in for cases in which the Location Recipient is 149 passive. 151 3. Presence Architecture for GEOPRIV 153 The Common Profile for Presence [4] (CPP) defines a set of operations 154 for delivery of presence information. These primarily consist of 155 subscription operations and notification operations. A subscription 156 creates a persistent connection between a 'watcher' (which 157 corresponds to the Location Recipient of GEOPRIV) and a 'presentity' 158 (which corresponds roughly to the GEOPRIV target). When a watcher 159 subscribes to a presentity, a persistent connection is created; 160 notifications of presence information will henceforth be sent to the 161 watcher as the presence information changes. CPP also supports 162 unsubscriptions (terminating the persistent subscription) and fetches 163 (one-time requests for presence information that result in no 164 persistent subscription). 166 CPP provides a number of attributes of these operations that flesh 167 out the presence system. There is a system for automatically 168 expiring subscriptions if they are not refreshed at user-defined 169 intervals (in order to eliminate stale subscriptions). There are 170 transaction and subscription identifiers used to correlate messages, 171 and a URI scheme ("pres:") is defined to identify watchers and 172 presentities. 174 The IETF IMPP WG has also defined an XML data format for presence 175 information called the Presence Information Data Format [6] (PIDF). 176 PIDF is a body carried by presence protocols that contains presence 177 information, including the current state of a presentity. PIDF is 178 discussed in more detail in Section 4. 180 At a high-level, then, the presence architecture seems to have 181 considerable applicability to the problem of delivering GEOPRIV 182 information. However, the CPP framework is an abstract framework - 183 it doesn't actually specify a protocol, it specifies a framework and 184 a set of requirements to which presence protocols must conform. 185 Also, CPP does not define any concept similar to a Location Server. 187 However, the IETF has standardized protocols that instantiate this 188 framework, such as SIMPLE [7] and XMPP [8]. XMPP and SIMPLE both 189 have architectural elements comparable to a Location Server: points 190 where presentities register their availability, and where policies 191 for distributing presence can be managed. The presence community has 192 also defined a policy protocol and schema set called XCAP [9] through 193 which authorization policies can be provisioned in a presence server. 195 In summary, like GEOPRIV, presence requires an architecture for 196 publication, subscription, and notification for a mutable set of data 197 associated with a principal. Presence has already tackled many of 198 the harder issues associated with subscription management, including 199 subscription expiration, development of identifiers for principals, 200 and defining document formats for presence information. Rather than 201 reinventing work that has been done elsewhere in the IETF, GEOPRIV 202 has reused this existing work by specifying presence protocols as 203 GEOPRIV using protocols. Moreover, the existing foundational 204 presence tools developed in IMPP, such as PIDF, have immediate 205 applicability to the efforts underway in GEOPRIV to develop objects 206 for sharing location information. 208 4. GEOPRIV Extensions to PIDF 210 As was mentioned above, the presence architecture developed in the 211 IETF IMPP WG has defined a format for presence information called 212 PIDF. PIDF is an XML format that provides presence information about 213 a presentity - primarily, this consists of status information, but 214 also optionally includes contact addresses (a way of reaching the 215 presentity), timestamps, and textual notes with arbitrary content. 217 PIDF is an extensible format. It defines an XML element for 218 representing the status of a presentity (the status element), and 219 gives some guidance on how this element might be extended. While the 220 authors of PIDF viewed geographical location as a potential category 221 of presence information, baseline PIDF defines no format for location 222 information. 224 PIDF meets the security requirements given in RFC2779 [3] (see 225 especially 5.1, 5.2 and 5.3), which parallel the security 226 requirements of the GEOPRIV location object given in the GEOPRIV 227 requirements [1]. CPP and PIDF specify mechanisms for mutual 228 authentication of participants in a presence exchange as well as 229 confidentiality and integrity properties for presence information. 231 So in short, many of the requirements of GEOPRIV objects map well 232 onto the capabilities of PIDF. 234 5. Security Considerations 236 GEOPRIV information, like presence information, has very sensitive 237 security requirements. The requirements of RFC2779 [3], which are 238 instantiated by CPP, PIDF and XCAP, in addition to the various 239 derivative concrete presence protocols like XMPP and SIMPLE, map well 240 onto the security requirements of the GEOPRIV protocol, as defined in 241 the GEOPRIV requirements document and the GEOPRIV threat analysis 242 [10] document. Specifically, the presence security requirements call 243 for authentication of watchers, integrity and confidentiality 244 properties, and similar measures to prevent abuse of presence 245 information. 247 6. IANA Considerations 249 This document introduces no considerations for the IANA. 251 7 Informative References 253 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 254 Polk, "GEOPRIV requirements", RFC 3693, February 2004. 256 [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 257 Instant Messaging", RFC 2778, February 2000. 259 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 260 Presence Protocol Requirements", RFC 2779, February 2000. 262 [4] Peterson, J., "A Model for Presence and Instant Messaging", RFC 263 3859, August 2004. 265 [5] Peterson, J., "Address Resolution for Instant Messaging and 266 Presence", RFC 3861, August 2004. 268 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 269 J. Peterson, "CPIM Presence Information Data Format", RFC 3863, 270 August 2004. 272 [7] Rosenberg, J., "A Presence Event Package for the Session 273 Initiation Protocol (SIP)", RFC 3856, August 2004. 275 [8] Saint-Andre, P., "Extensible Messaging and Presence Protocol 276 (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 277 (work in progress), April 2004. 279 [9] Rosenberg, J., "The Extensible Markup Language (XML) 280 Configuration Access Protocol (XCAP)", 281 draft-ietf-simple-xcap-02 (work in progress), February 2004. 283 [10] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat 284 Analysis of the GEOPRIV Protocol", RFC 3694, February 2004. 286 [11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 287 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 288 1998. 290 Author's Address 292 Jon Peterson 293 NeuStar, Inc. 294 1800 Sutter St 295 Suite 570 296 Concord, CA 94520 297 USA 299 Phone: +1 925/363-8720 300 EMail: jon.peterson@neustar.biz 301 URI: http://www.neustar.biz/ 303 Appendix A. Acknowledgements 305 Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet 306 Sarikaya for their comments. 308 Intellectual Property Statement 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the procedures with respect to rights in RFC documents can be 317 found in BCP 78 and BCP 79. 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at 330 ietf-ipr@ietf.org. 332 Disclaimer of Validity 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 337 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 338 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 339 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Copyright Statement 344 Copyright (C) The Internet Society (2004). This document is subject 345 to the rights, licenses and restrictions contained in BCP 78, and 346 except as set forth therein, the authors retain all their rights. 348 Acknowledgment 350 Funding for the RFC Editor function is currently provided by the 351 Internet Society.