RFC 5962
Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)
Internet Engineering Task Force (IETF) Request for Comments 5962 ✨
Okay bestie, let's get into this one 🎀 It's RFC 5962, published in September 2010 by the IETF. It's on the Standards Track (so it's real, official, implement-it-or-else energy 💅), and its ISSN is 2070-1721.
The authors are H. Schulzrinne (Columbia University), V. Singh (Columbia University), H. Tschofenig (Nokia Siemens Networks), and M. Thomson (Andrew Corporation). The title is Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) 🦋
It doesn't obsolete anything, and it doesn't update anything either. It's a brand-new extension that sits on top of PIDF-LO 🌸
Abstract 💖
Okay so PIDF-LO (from RFC 4119) is the Geopriv Location Object, and it's basically a little XML format for carrying a presentity's geographic location 🗺️ This document adds extensions to PIDF-LO so you can also send spatial orientation, speed, and heading. Like, where you're located AND which way you're facing, how fast you're moving, and which direction you're heading 🧚
Status of This Memo 🎀
This is an Internet Standards Track document, meaning it went through the IETF process, got public review, and was approved by the IESG. You can find info on the current status, errata, and feedback at http://www.rfc-editor.org/info/rfc5962. For more on Internet Standards, check Section 2 of RFC 5741.
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the document authors, all rights reserved 💜 This is subject to BCP 78 and the IETF Trust's Legal Provisions (http://trustee.ietf.org/license-info) in effect at publication. Please read those carefully, because they spell out your rights 🫶 Any Code Components pulled from this doc must include Simplified BSD License text (per Section 4.e of the Trust Legal Provisions) and come without warranty.
Table of Contents 📋
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Dynamic Elements ................................................3
3.1. Angular Measures and Coordinate Reference Systems ..........5
4. Dynamic Feature XML Schema ......................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
6.1. Dynamic Feature Extensions Namespace Registration ..........7
6.2. Dynamic Feature Extensions Schema Registration .............8
7. Acknowledgements ................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Earth Centered, Earth Fixed Direction Vectors ........101. Introduction 🌸
So PIDF-LO (see RFC 4119 [RFC4119]) gives you the geographical location of a presentity 📍 It's a snapshot: where you were at one specific moment. RFC 5491 [RFC5491] builds on PIDF-LO and gives implementers extra guidance 💅
This document extends PIDF-LO so it can carry spatial orientation, speed, and heading ✨ Adding rate-of-change info unlocks a bunch of use cases 🔥 Some apps use the dynamic info directly, and others use it to make position tracking smoother over time. For example, an app tracking a presentity could use velocity to estimate where they are between location measurements 🧠 And a shipping company could watch delivery truck speed to make sure speed limits are being followed 🚚💨
2. Terminology 💜
Here's the vibe check: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] 🎀
"Presentity" is the term from RFC 2778 [RFC2778] for the device whose location is being determined 🧚 It's giving presence vibes, because this work reuses the Presence Information Data Format (PIDF, see RFC 3863 [RFC3863]) and its location enhancement (RFC 4119 [RFC4119]), which were inspired by the abstract location privacy architecture in RFC 4079 [RFC4079] 🔐 Also, this doc doesn't care whether the object is a human or a non-human, so both are in scope 🌈
3. Dynamic Elements ✨
This document defines a brand-new element, <Dynamic>, for carrying dynamic info 🦋
Dynamic info MAY be included without any other location info being present 💖 But if dynamic info is attached to the presentity's instantaneous position, the <Dynamic> element MUST be included in the same <location-info> element as the matching geodetic (or civic) location info 🫶
Here's the good news: a recipient that doesn't support this spec can safely ignore dynamic info 🙌 The <Dynamic> element has these parts:
orientation: The<orientation>element describes the spatial orientation of the presentity, aka the direction the object is pointing 🧭 For a device, this might depend on the device type. See Section 3.1 for details 💅speed: Speed is the time rate of change in position of a presentity without caring about direction, so it's the scalar part of velocity 🏎️ The<speed>value is measured in meters per second 💨heading: Heading is the directional part of velocity, so it's the direction of travel. See Section 3.1 for details 🧚
Any of these can be left out if the info isn't available 🌸 In the example below, the presentity is pointing roughly North at a slightly raised angle, and it's traveling 24 meters per second to the West 🔥
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@example.com">
<dm:device id="abc123">
<gp:geopriv>
<gp:location-info>
<dyn:Dynamic>
<dyn:orientation>-3 12</dyn:orientation>
<dyn:speed>24</dyn:speed>
<dyn:heading>278</dyn:heading>
</dyn:Dynamic>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
</gp:geopriv>
<timestamp>2009-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
</presence>Next example: alice@example.com is on a bike going 12 meters per second 🚲💨 Her position is shown as a circle 🎯 A receiver can use the speed value to adjust how uncertain the position estimate is over time 🧠
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:alice@example.com">
<dm:device id="abc123">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
100
</gs:radius>
</gs:Circle>
<dyn:Dynamic>
<dyn:speed>12</dyn:speed>
</dyn:Dynamic>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
</gp:geopriv>
<timestamp>2009-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
</presence>3.1. Angular Measures and Coordinate Reference Systems 🧭
Quick recap of the coordinate system stuff 🗺️ RFC 5491 [RFC5491] limits the coordinate reference system (CRS) used in PIDF-LO to WGS 84 🌍 You can use either the 2D (latitude, longitude) CRS urn:ogc:def:crs:EPSG::4326, or the 3D (latitude, longitude, altitude) CRS urn:ogc:def:crs:EPSG::4979 💖 Dynamic locations assume one of these same CRSs too 🫶
Both <orientation> and <heading> describe a direction, but they mean different things 🎀 <orientation> is the "direction of facing" and <heading> is the "direction of travel" 🧚 Each one has one or two angles, measured relative to the presentity's current position (see Appendix A) 🌸 Angles are in degrees and can be negative 🔥 If there are two angles, they MUST be separated by whitespace 💅
The first angle is the horizontal direction from where the presentity is now to the point it's pointing at (for <orientation>) or traveling toward (for <heading>) 🧭 Horizontal angles go from Northing to Easting, so they start at zero when facing or heading North and increase toward the East 🌈
The second angle, if it's there, is the vertical part of that direction 🦋 It's the elevation above the local horizontal plane 🏔️ If the second value is left out, the vertical part is unknown 🤷♀️ If only one angle shows up, <orientation> only describes the horizontal part 💜 For <heading>, the matching <speed> only carries the horizontal part of speed 🏎️
Stay tuned, bestie! This is Part 1 of 2. Part 2 picks up with Section 4 (Dynamic Feature XML Schema) and keeps going 💖🎀
4. Dynamic Feature XML Schema ✨
okay so this is the actual schema, the bit implementers will be staring at 👀 bestie, copy it exactly 💅
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="Dynamic" type="dyn:dynamicType"/>
<xs:complexType name="dynamicType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="orientation" minOccurs="0"
type="dyn:directionType"/>
<xs:element name="speed" minOccurs="0"
type="xs:double"/>
<xs:element name="heading" minOccurs="0"
type="dyn:directionType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="directionType">
<xs:restriction base="dyn:doubleListType">
<xs:minLength value="1"/>
<xs:maxLength value="2"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="doubleListType">
<xs:list itemType="xs:double"/>
</xs:simpleType>
</xs:schema>5. Security Considerations 🔒
okay this section is SERIOUS, so read it properly, no skimming 🫶
This document defines extra location elements that ride along inside PIDF-LO 🗺️ Those extra elements give us even MORE reason to follow the privacy and security stuff in RFC 4119 [RFC4119]. No further privacy or security measures are necessary, so that's the whole list 💅
RFC 4119 [RFC4119] then points back to RFC 3694 [RFC3694] and RFC 3693 [RFC3693] 📚 Those two cover the threat model, plus the security requirements the GEOPRIV architecture has to meet for sharing location info because of that threat model. Here's the tea ☕: those two docs mostly talk about threats to where a presentity is right now. This document adds dynamic info that an attacker could use to guess where a presentity is going to be 😳 That's a whole new vibe, and it's kind of scary, ngl.
Also, a series of location snapshots is already likely to give someone clues about where a presentity will end up. Even so, putting more info in a PIDF-LO does make a leak more severe 📈 So, obviously, anyone running location-based services is strongly advised to give their users ways to control who gets location info, limited to the people who've been authorized to see it. Privacy is a main character thing, and everyone deserves it 🦋
6. IANA Considerations 📝
this section registers a new XML namespace (as described in [RFC3688]) and a new XML schema 🎀
6.1. Dynamic Feature Extensions Namespace Registration
URI: urn:ietf:params:xml:ns:pidf:geopriv10:dynamic 🌸
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@gmx.net) 💜
The XML registered for this namespace is below. Yes, it's an XHTML page, bestie. Don't ask 🙈
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Dynamic Feature Extensions Namespace</title>
</head>
<body>
<h1>Namespace for Dynamic Feature Extensions to PIDF-LO</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dynamic</h2>
<p>See <a href=
"http://www.rfc-editor.org/rfc/rfc5962.txt"> RFC5962</a>.</p>
</body>
</html>
END6.2. Dynamic Feature Extensions Schema Registration
URI: urn:ietf:params:xml:schema:pidf:dynamic ✨
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@gmx.net) 🦋
XML: the XML schema being registered is the one in Section 4 🧚 Its first line is <?xml version="1.0"?> and its last line is </xs:schema> 💖
7. Acknowledgements 🫶
big thank-yous to the people who gave comments: Klaus Darilion, Cullen Jennings, Rohan Mahy, Carl Reed, and Brian Rosen 🌈 We also want to thank Alexey Melnikov, Adrian Farrel, Tim Polk, and Dan Romascanu (for his IESG review comments), Avshalom Houri (for his GenArt review), Hilarie Orman (for her SECDIR review), and Joel Jaeggli (for his Operations Directorate review) 👑
8. References 📚
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
8.2. Informative References
- [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
- [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
- [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
- [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
- [RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
- [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
Appendix A. Earth Centered, Earth Fixed Direction Vectors 🧭
okay the math is about to get a little spicy 🌶️ but it's giving clarity, I promise ✨
The absolute orientation or heading of a presentity depends on its latitude and longitude 🌍 The vectors below can be used to work out the absolute direction in WGS 84 Earth Centered, Earth Fixed (X, Y, Z) coordinate space.
The direction of North as a unit vector in Earth Centered, Earth Fixed (ECEF) coordinates is:
North = [ -1 * sin(latitude) * cos(longitude),
-1 * sin(latitude) * sin(longitude),
cos(latitude) ]The direction of "up" (the upward normal of the horizontal plane) as a unit vector in ECEF coordinates is:
Up = [ cos(latitude) * cos(longitude),
cos(latitude) * sin(longitude),
sin(latitude) ]Authors' Addresses 💌
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu/Vishal Singh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
EMail: vs2140@cs.columbia.edu
URI: http://www.cs.columbia.edu/~vs2140Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at/Martin Thomson
Andrew Corporation
Wollongong
NSW Australia
EMail: martin.thomson@andrew.com📦 where this page comes from
- ietf: rfc5962 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms