From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4079.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc4079.txt (limited to 'doc/rfc/rfc4079.txt') diff --git a/doc/rfc/rfc4079.txt b/doc/rfc/rfc4079.txt new file mode 100644 index 0000000..06ef9db --- /dev/null +++ b/doc/rfc/rfc4079.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. Peterson +Request for Comments: 4079 NeuStar +Category: Informational July 2005 + + + A Presence Architecture for the + Distribution of GEOPRIV Location Objects + +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 + + 1. Introduction ....................................................2 + 2. Framework Analysis ..............................................2 + 3. Presence Architecture for GEOPRIV ...............................3 + 4. GEOPRIV Extensions to PIDF ......................................5 + 5. Security Considerations .........................................5 + 6. Acknowledgements ................................................5 + 7. Informative References ..........................................6 + + + + + + + + + + + + +Peterson Informational [Page 1] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + +1. Introduction + + 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 RFC2778 [2] 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. + +2. Framework Analysis + + The GEOPRIV framework [1] 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. + + + + +Peterson Informational [Page 2] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + + 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. + +3. Presence Architecture for GEOPRIV + + The Common Profile for Presence [4] (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; + + + +Peterson Informational [Page 3] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + + 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 [5] (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 Section 4. + + 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 [6] and XMPP [7]. 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 [8] 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. + + + +Peterson Informational [Page 4] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + +4. GEOPRIV Extensions to PIDF + + 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 RFC2779 [3] (see + especially sections 5.1, 5.2, and 5.3), which parallel those of the + GEOPRIV location object given in the GEOPRIV requirements [1]. 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. + +5. Security Considerations + + GEOPRIV information, like presence information, has very sensitive + security requirements. The requirements of RFC2779 [3], 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 [9] document. Specifically, the presence security + requirements call for authentication of watchers, integrity and + confidentiality properties, and similar measures to prevent abuse of + presence information. + +6. Acknowledgements + + Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet + Sarikaya for their comments. + + + + + + + + +Peterson Informational [Page 5] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + +7. Informative References + + [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. + Polk, "GEOPRIV requirements", RFC 3693, February 2004. + + [2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence + and Instant Messaging", RFC 2778, February 2000. + + [3] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / + Presence Protocol Requirements", RFC 2779, February 2000. + + [4] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, + August 2004. + + [5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and + J. Peterson, "Presence Information Data Format (PIDF)", + RFC 3863, August 2004. + + [6] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [7] Saint-Andre, P., "Extensible Messaging and Presence Protocol + (XMPP): Instant Messaging and Presence", RFC 3921, October + 2004. + + [8] Rosenberg, J., "The Extensible Markup Language (XML) + Configuration Access Protocol (XCAP)", Work in Progress, + February 2004. + + [9] Danley, M., Morris, J., Mulligan, D., and J. Peterson, "Threat + Analysis of the GEOPRIV Protocol", RFC 3694, 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: http://www.neustar.biz/ + + + + + + + + +Peterson Informational [Page 6] + +RFC 4079 GEOPRIV Presence Arch July 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, 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 BCP 78 and BCP 79. + + 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 + http://www.ietf.org/ipr. + + 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] + -- cgit v1.2.3