RFC 4079

RFC 4079: A Presence Architecture for the Distribution of GEOPRIV Location Objects 💖

Okay bestie, this is RFC 4079, published in July 2005 by J. Peterson from NeuStar 🧚. It's an Informational doc, so it's sharing ideas rather than setting a standard. It doesn't list any RFCs that it obsoletes or updates, so it's giving main character energy all on its own ✨.

---

Status of This Memo 📜

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, so nobody has to follow it like a rulebook. Distribution of this memo is unlimited, so share it with whoever 💜

Copyright Notice ©️

Copyright (C) The Internet Society (2005). Legally boring, but it's there 🙈

Abstract 🌸

GEOPRIV defines the idea of a 'using protocol', which is basically a protocol that carries GEOPRIV location objects 📦. GEOPRIV also has different scenarios for distributing location objects, and those need subscriptions and asynchronous notifications. This doc looks at some existing IETF work on presence, shows how presence architectures line up with GEOPRIV architectures, and proves that tools already built for presence could be reused to make GEOPRIV easier to standardize and implement 🔥.

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

1. Introduction ✨

Okay so GEOPRIV is a standard for sending location info and privacy policies over the Internet 🌍. Location info describes a specific spatial location. It can be coordinates (like longitude, latitude, and so on), civil addresses (like postal addresses), or other stuff too. GEOPRIV is all about privacy and security, from both the tech side and the policy side, when you share location info online. Basically it's a secure container class that can carry both the location info AND the policy data that controls who gets it 🔐. It also defines the 'using protocol' idea again, which is the protocol that carries the GEOPRIV location object 🚚.

Presence is a service defined in RFC2778 [2] that lets people on a communications service keep an eye on each other's availability and disposition, so they can decide whether to reach out 👀. Presence info changes super fast. It usually tells you stuff like whether someone is online or offline, busy or idle, away from their devices or nearby, and so on 💅.

This doc shows that presence applies to GEOPRIV, and that a presence protocol could be a good using protocol for GEOPRIV 🦋. It is not trying to prove that presence is the only way GEOPRIV location objects could get distributed. But lots of GEOPRIV apps depend on the same subscription/notification setup that presence is built on, so the connection is real 🫶.

2. Framework Analysis 🔍

The GEOPRIV framework [1] has four main network entities: a Location Generator, a Location Server, a Location Recipient, and a Rule Holder 🧩. There are three interfaces between these entities defined, including a publication interface and a notification interface.

GEOPRIV says a 'using protocol' is used to move location objects from one place to another 🚀. If the publication and notification interfaces are network connections, then a using protocol would be the thing in charge of sending the location object. Location Recipients can ask a Location Server to give them GEOPRIV location info about a particular Target 🎯. The Location Generator publishes Location Information to a Location Server. The Location Server, working together with policies set by the Rule Maker, passes that location info along to Location Recipients when it's appropriate 💌.

The GEOPRIV requirements doc lays out three scenarios for using the GEOPRIV protocol 📋. In some of them (like the third one), a Location Recipient sends a message to the Location Server asking it to keep sending location info on a regular schedule ⏰. A GEOPRIV Target's location will probably keep changing over time, especially if the Target is a person or something similarly mobile 🏃‍♀️. So a persistent subscription to a Target's location, with periodic notifications, is really valuable for GEOPRIV 💖. In other scenarios, a Location Recipient might just want a one-time notification of where the Target is 📍.

GEOPRIV doesn't put many requirements on using protocols 🤷‍♀️. Still, from everything above, there must be some mechanism that lets Location Recipients set up a persistent subscription so they can get regular notifications about a Target's location as it changes over time. There also must be a way for Location Generators to publish location info to a Location Server, and that server applies extra policies for distribution 🔥.

This doc goes with a model where the using protocol handles requesting subscriptions, handling publications, and sending notifications 🎀. Other GEOPRIV models could build these operations into the location objects themselves. But the IETF already has a ton of existing work on managing publications, subscriptions, and notifications for data sets that change over time 📚. These ideas match up exactly with presence architectures, which were built for real-time communication apps like instant messaging, voice, and video sessions 📱.

Heads up though: in some GEOPRIV scenarios, the Location Recipient doesn't actually ask for the Target's location. Instead, it gets an unsolicited notification of the Target's location 😳. This doc only looks at using presence for scenarios where the Location Recipient actively asks for location info. Even so, many of the base operations from presence's subscription/notification framework could be reused when the Location Recipient is passive 🌈.

3. Presence Architecture for GEOPRIV 🦋

The Common Profile for Presence [4] (CPP) defines a set of operations for delivering presence info 📬. These mostly break down into subscription operations and notification operations. A subscription creates a persistent connection between a 'watcher' (which matches the Location Recipient in GEOPRIV) and a 'presentity' (which roughly matches the GEOPRIV target) 💞. Once a watcher subscribes to a presentity, that persistent connection exists, and notifications of presence info get sent to the watcher whenever the presence info changes 🔔. CPP also supports unsubscriptions, which end the persistent subscription, and fetches, which are one-time requests for presence info that don't create a persistent subscription 🙌.

CPP has a bunch of extra attributes that round out the presence system ✨. Subscriptions automatically expire if they aren't refreshed at user-defined intervals, which gets rid of stale subscriptions 🧹. Transaction and subscription identifiers are used to match up messages 🔗. And a URI scheme ("pres:") is defined for identifying watchers and presentities 🪪.

The IETF IMPP WG also defined an XML data format for presence info, called the Presence Information Data Format [5] (PIDF) 🧾. PIDF is a body that presence protocols carry, and it holds the presence info, including the presentity's current state. PIDF gets a closer look in Section 4 💅.

So at a high level, the presence architecture seems to fit really well with the problem of delivering GEOPRIV info 💜. But CPP is an abstract framework, which means it doesn't actually specify a protocol. Instead, it specifies a framework and a set of requirements that presence protocols must conform to 🧠. Also, CPP doesn't define anything like a Location Server 🙃.

That said, the IETF has standardized protocols that put this framework into practice, like SIMPLE [6] and XMPP [7] 🛠️. Both XMPP and SIMPLE have architectural pieces that are comparable to a Location Server: places where presentities register their availability, and where policies for distributing presence can be managed 🏛️. The presence community also defined a policy protocol and schema set called XCAP [8], which lets you provision authorization policies in a presence server 🔐.

Summing up: like GEOPRIV, presence needs an architecture for publication, subscription, and notification of a changing set of data tied to a principal 🔄. Presence has already dealt with a lot of the harder issues around subscription management, including subscription expiration, creating identifiers for principals, and defining document formats for presence info 🏆. Instead of reinventing the wheel, GEOPRIV reused this existing work by specifying presence protocols as GEOPRIV using protocols 🎉. And the foundational presence tools from IMPP, like PIDF, are immediately useful for the GEOPRIV effort to develop objects for sharing location info 🌸.

4. GEOPRIV Extensions to PIDF 🧚

As mentioned above, the presence architecture from the IETF IMPP WG defined a format for presence info called PIDF 💅. PIDF is an XML format that provides presence info about a presentity. Mostly it's status info, but it can also optionally include contact addresses (a way to reach the presentity), timestamps, and textual notes with arbitrary content 📝.

PIDF is extensible. It defines an XML element for representing the status of a presentity (the status element), and it gives some guidance on how that element might be extended 🧩. The PIDF authors saw geographical location as a possible category of presence info, but baseline PIDF doesn't define any format for location info 🌍.

PIDF meets the security requirements in RFC2779 [3] (see especially sections 5.1, 5.2, and 5.3), and those parallel the requirements for the GEOPRIV location object in the GEOPRIV requirements [1] 🔐. CPP and PIDF both specify mechanisms for mutual authentication of participants in a presence exchange, plus confidentiality and integrity properties for presence info 🫶.

So, in short, a lot of the requirements for GEOPRIV objects map really well onto what PIDF can do 🦋✨ More coming in part 2 👀

5. Security Considerations ✨

okay bestie, this section is SERIOUS 🫶 GEOPRIV info is like presence info but even more sensitive, so the security bar is hiiigh 🔥 The requirements of RFC2779 [3] are the baseline here 💅 They get instantiated by CPP, PIDF, and XCAP, plus the different concrete presence protocols built on top, like XMPP and SIMPLE, and they map really well onto what GEOPRIV needs. The GEOPRIV requirements document and the GEOPRIV threat analysis [9] document define those GEOPRIV security needs. Basically, presence security calls for authentication of watchers, integrity and confidentiality properties, and similar measures to stop people from abusing presence information 😭🔒

6. Acknowledgements 🌸

Huge thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet Sarikaya for their comments 🫶💖

7. Informative References 📚

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/

---

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.