RFC 7035
Relative Location Representation
Part 1 of 7 💖
Title Block ✨
okay bestie, let's start with the basics 🎀 this is RFC 7035, called Relative Location Representation, and it's a Standards Track document from the IETF 🦋 it was published in October 2013 and the ISSN is 2070-1721. The authors are M. Thomson (Microsoft), B. Rosen (Neustar), D. Stanley (Aruba Networks), G. Bajko (Nokia), and A. Thomson (Lookingglass) 👑 the title block doesn't list anything it obsoletes or updates, so there's nothing to cross-check there 🌸
Abstract 🦋
so this doc adds an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) 📍 it lets you express location info that's measured relative to a reference point. The reference point can be geodetic or civic, and the relative offset can come in one of several shapes 💅 there's also an alternative binary representation.
Optionally, you can attach a reference to a secondary document, like a map image 🗺️ you can also say how the map's coordinate system lines up with the reference/offset coordinate system. That way an app can show the map with the reference point and the offset on it. iconic 🔥
Status of This Memo 📜
this is an Internet Standards Track document ✨
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 💜
info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7035 🌈
Copyright Notice 🎀
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read these, bestie, because they spell out your rights and restrictions for this doc 🙈 if you extract Code Components from this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️
Table of Contents 🧚
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Overview ........................................................4
4. Relative Location ...............................................7
4.1. Relative Coordinate System .................................8
4.2. Placement of XML Elements ..................................8
4.3. Binary Format ..............................................9
4.4. Distances and Angles .......................................9
4.5. Value Encoding ............................................10
4.6. Relative Location Restrictions ............................10
4.7. Baseline TLVs .............................................10
4.8. Reference TLVs ............................................10
4.9. Shapes ....................................................11
4.9.1. Point ..............................................11
4.9.2. Circle or Sphere Shape .............................12
4.9.3. Ellipse or Ellipsoid Shape .........................13
4.9.4. Polygon or Prism Shape .............................15
4.9.5. Arc-Band Shape .....................................18
4.10. Dynamic Location TLVs ....................................20
4.10.1. Orientation .......................................20
4.10.2. Speed .............................................20
4.10.3. Heading ...........................................20
4.11. Secondary Map Metadata ...................................21
4.11.1. Map URL ...........................................21
4.11.2. Map Coordinate Reference System ...................21
4.11.3. Map Example .......................................24
5. Examples .......................................................24
5.1. Civic PIDF with Polygon Offset ............................24
5.2. Geo PIDF with Circle Offset ...............................26
5.3. Civic TLV with Point Offset ...............................27
6. Schema Definition ..............................................28
7. Security Considerations ........................................30
8. IANA Considerations ............................................31
8.1. Relative Location Registry ................................31
8.2. URN Sub-Namespace Registration ............................33
8.3. XML Schema Registration ...................................33
8.4. Geopriv Identifiers Registry ..............................34
8.4.1. Registration of Two-Dimensional Relative
Coordinate Reference System URN ....................35
8.4.2. Registration of Three-Dimensional Relative
Coordinate Reference System URN ....................35
9. Acknowledgements ...............................................35
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................381. Introduction ✨
this doc describes a format for expressing relative location information 🦋
so a relative location is a reference location plus a relative offset from that reference location 📍 the reference location can be civic or geodetic. It can also have dynamic components, like velocity 🏃♀️ and the relative offset is specified in meters using a Cartesian coordinate system 📐
on top of the relative location, you can optionally include a URI pointing to a doc with a map, floor plan, or other spatially oriented info 🗺️ apps can use that to display the relative location. There are also extra fields so the map can be oriented and scaled correctly. main character energy 👑
there are two formats 💅 the first is an XML form meant for PIDF-LO [RFC4119], and the second is a TLV format for other protocols, like ones that already carry the binary location info defined in [RFC4776] 🎀
2. Conventions Used in This Document 💅
okay, this part is important, so read closely 🙈 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶
3. Overview ✨
Okay bestie, this section is where the magic starts 🦋 This document is an extension to PIDF-LO [RFC4119] (as updated by [RFC5139] and [RFC5491]) that lets you express a location as an offset from a reference point 💖 Think "I'm a little bit east and a little bit north of the front door," not just a dot on a map 🌸
Reference
Location
o
\
\ Offset
\
_\|
x
Relative
LocationSo the creator of a location object can include two location values plus an offset 👑 The two location values are called "baseline" and "reference," and together they make the origin of the offset 🧚
The final, relative location gets described relative to that reference point ✨
..--"""--..
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'The baseline location sits outside of the <relative-location> element 💅 Clients that don't understand relative location just ignore that element and still see the baseline, so the baseline is what they can read 🙈
A client that does understand relative location treats the location inside the relative element as a refinement of the baseline 🔥 This doc defines both a reference location (which refines the baseline and is the starting point) and an offset (which describes where the Target is, starting from that point) 💜
Creators get to choose how much detail goes in the baseline and how much goes in the reference location 🍓 For example, the baseline could be precise enough to name the building that holds the relative location, and the reference location could pin a spot inside the building that the offset gets measured from 🏢✨
Location objects SHOULD NOT have all of their location information in the baseline 😭 If they did, clients that don't get relative location would read the baseline (aka the reference point) as the actual, precise location of the client, and that's a whole mess 💀 The baseline is meant to carry a location that covers both the reference location and the relative location (the reference location plus the offset) 🫶
You can give a valid relative location with nothing in the baseline 🙃 But then recipients who don't understand relative location get zero information, which is sad 😢 A baseline SHOULD include enough info to cover both the reference and relative locations, while still being as accurate as it possibly can be 🎀
Both the baseline and the reference location are either a geodetic location [OGC.GeoShape] or a civic address [RFC4776] 🌈 If the baseline is geodetic, the reference MUST be geodetic too 💖 If the baseline is a civic address, the reference MUST be civic 💖
Baseline and reference locations MAY also include dynamic location information [RFC5962] 🦋
The relative location can be a point (2D or 3D) or a shape with uncertainty: circle, sphere, ellipse, ellipsoid, polygon, prism, or arc-band 🔮 You can find descriptions of all these shapes in [RFC5491] 📐
You can also optionally include a reference to a "map" document 🗺️ The reference is a URI [RFC3986] 🔗 The document could be an image or dataset that shows a map, floor plan, or something similar 🖼️ The type of document is described as a MIME media type [RFC2046] 🎀 Metadata in the relative location can include where the reference point sits on the map, plus an orientation (angle from North) and a scale, so the document's Coordinate Reference System (CRS) lines up with the World Geodetic System 1984 (WGS84) [WGS84] CRS 🌍 The document is assumed to be usable by the app that receives the PIDF with the relative location, so it can find the reference point on the map 🧭 This doc doesn't describe any way to display or manipulate the document beyond giving the reference location, orientation, and scale 🙅♀️
Here's an example of a relative location expressed as a point, relative to a civic location 🎀
<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:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:relative@example.com">
<dm:device id="relative1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos>
</gml:Point>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
<rel:map>
<rel:url type="image/png">
http://example.com/location/map.png
</rel:url>
<rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale>
</rel:map>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
4. Relative Location 💫
Okay, here's the core vibe: a relative location is a shape (like a point, circle, or ellipse) 🔵 The shape lives in a CRS whose datum is the reference (which shows up as a civic address or geodetic location in the tuple) 📍 The shape's coordinates are meter offsets North/East from that datum, with an optional Z offset relative to datum altitude 📏 And an optional angle lets you rotate the reference CRS with respect to North 🧭
4.1. Relative Coordinate System 🗺️
The relative coordinate reference system is a coordinate system with two or three axes 📐
The baseline and reference locations define a relative datum 💜 The reference location is the origin of the coordinate system 🎯 If the reference location has any uncertainty, the centroid of the reference location is used 🫧
The axes start out oriented by East, North, and Up from the reference location 🌸 The first (x) axis increases to the East, the second (y) axis points North, and the optional third (z) axis points Up ⬆️ Every axis uses meters as the basic unit 📏
Any coordinates in the relative shapes use this Cartesian coordinate system 🧩 In XML form, the URN is "urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and "urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes 💅 The binary form uses different shape type identifiers for 2D and 3D shapes 🔢
Dynamic location information [RFC5962] in the baseline or reference location changes the relative coordinate system 🌀 The resulting Cartesian axes get rotated so the y axis is oriented along the direction described by the <orientation> element 🧭 The coordinate system also moves as described by the <speed> and <heading> elements 🏃♀️
The single timestamp in the tuple (or equivalent) element applies to all location elements, including all three parts of a relative location: baseline, reference, and relative 🕰️ This matters a LOT when there are dynamic parts to these items 😭 A location generator is responsible for making sure these fields stay consistent 🫶
4.2. Placement of XML Elements 🎀
The baseline of the reference location is represented as <location-info>, just like a normal PIDF-LO 💖 Relative location adds a new <relative-location> element to <location-info> 🌈 Inside <relative-location>, you describe <reference> and <offset> elements 🧚 Inside <offset> go the shape elements described below ✨ This document extends PIDF-LO as described in [RFC6848] 🦋
4.3. Binary Format 🔢
This doc also describes a way to encode the relative location in a binary TLV form, for other protocols that use TLVs to represent location 🍓 The encoding is a type-length-value encoding 💜
+------+------+------+------+------+------+------+
| Type |Length| Value ...
+------+------+------+------+------+------+------+
| T | N | Value ...
+------+------+------+------+------+------+------+
Figure 1: TLV Tuple FormatThe Type field (T) is an 8-bit unsigned integer 🔢 The type codes are registered in an IANA-managed "Relative Location Parameters" registry that this document defines 📋 They're restricted so they don't include the values defined by the "Civic Address Types (CAtypes)" registry 🚫 That restriction is what lets a location reference and offset be coded in the same object without type collisions 🙌
The Length field (N) is an 8-bit unsigned integer too 📏 It can encode values from 0 to 255 🌸 Length counts the number of bytes in the Value, and it does not count the bytes used for the Type or Length 🙅♀️
The Value field is defined separately for each type 🎁
Every element of the relative location gets its own unique TLV assignment 🧩 A relative location encoded in TLV form includes baseline and reference location TLVs, plus relative location TLVs 💅 The reference TLVs come first, then the relative offset and the optional map TLVs described in this document 🗺️
4.4. Distances and Angles 📐
All distance measures used in shapes are in meters 📏
All orientation angles used in shapes are in degrees 🌡️ Orientation angles are measured from WGS84 Northing to Easting, with zero at Northing 🧭 In the relative coordinate system, orientation angles start from the second coordinate axis (y or Northing) and increase toward the first axis (x or Easting) 🌈
4.5. Value Encoding 🎀
okay so the binary form uses single-precision floating-point values [IEEE.754] to represent coordinates, distance, and angle measures 🧚 Single-precision values are 32-bit values with a sign bit, 8 exponent bits, and 23 fractional bits 💅 This uses the interchange format defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign, biased exponent and significand, with the most significant bit first. it's giving very specific layout energy, bestie 🫶
Binary-encoded coordinate values are considered to be a single value without uncertainty 🦋 When encoding a value that cannot be exactly represented, the best approximation MUST be selected according to [Clinger1990]. ✨ and yes, that MUST is doing a lot of work here, no cap 💀
4.6. Relative Location Restrictions 🚫
ok rule time 📜 More than one relative shape MUST NOT be included in either a PIDF-LO or TLV encoding of location for a given reference point. one shape per reference point, periodt 💅
Any error in the reference point transfers to the location described by the relative location 🌸 Any errors arising from an implementation not supporting or understanding elements of the reference point directly increases the error (or uncertainty) in the resulting location. so if your implementation doesn't get part of the reference point, the uncertainty goes up, and that's not a vibe 😭
4.7. Baseline TLVs 🍓
Baseline locations are described using the formats defined in [RFC4776] or [RFC6225]. simple and clean, iconic 👑
4.8. Reference TLVs 🌈
When a reference is encoded in binary form, the baseline and reference locations are combined in a reference TLV. This TLV is identified with the code 111 and contains civic address TLVs (if the baseline was a civic) or geo TLVs (if the baseline was a geo). it's the combo move, literally 🙈
+------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
Figure 2: Reference TLV4.9. Shapes 🦋
Shape data is used to represent regions of uncertainty for the reference and relative locations. Shape data in the reference location uses a WGS84 [WGS84] CRS. Shape data in the relative location uses a relative CRS. the shapes are the uncertainty bubbles, and they are giving main character energy ✨
The XML form for shapes uses Geography Markup Language (GML) [OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference locations use the CRS URNs specified in [RFC5491]; relative locations use either a 2D CRS ("urn:ietf:params:geopriv:relative:2d") or a 3D ("urn:ietf:params:geopriv:relative:3d"), depending on the shape type. 🌸
The binary form of each shape uses a different shape type for 2D and 3D shapes. 🧚
Nine shape type codes are defined. 💖
4.9.1. Point 📍
A point "shape" describes a single point with unknown uncertainty. It consists of a single set of coordinates. 💜
In a two-dimensional CRS, the coordinate includes two values; in a three-dimensional CRS, the coordinate includes three values. 🫶
4.9.1.1. XML Encoding
A point is represented in GML using the following template:
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point> Figure 3: GML Point TemplateWhere "$CRS-URN$" is replaced by a "urn:ietf:params:geopriv:relative:2d" or "urn:ietf:params:geopriv:relative:3d" and "$Coordinate-3$" is omitted if the CRS is two-dimensional. ✨
4.9.1.2. TLV Encoding
The point shape is introduced by a TLV of 113 for a 2D point and 114 for a 3D point. 🎀
+------+------+
| 113/4|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Figure 4: Point Encoding4.9.2. Circle or Sphere Shape ⭕
A circle or sphere describes a single point with a single uncertainty value in meters. 🌈
In a two-dimensional CRS, the coordinate includes two values, and the resulting shape forms a circle. In a three-dimensional CRS, the coordinate includes three values, and the resulting shape forms a sphere. 🔥
4.9.2.1. XML Encoding
A circle is represented in and converted from GML using the following template:
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Circle> Figure 5: GML Circle TemplateA sphere is represented in and converted from GML using the following template:
<gs:Sphere xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Sphere> Figure 6: GML Sphere Template4.9.2.2. TLV Encoding
A circular shape is introduced by a type code of 115. A spherical shape is introduced by a type code of 116. 💖
+------+------+
| 115/6|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
| Radius |
+------+------+------+------+
Figure 7: Circle or Sphere Encoding4.9.3. Ellipse or Ellipsoid Shape 🥚
An ellipse or ellipsoid describes a point with an elliptical or ellipsoidal uncertainty region. 🌷
In a two-dimensional CRS, the coordinate includes two values plus a semi-major axis, a semi-minor axis, a semi-major axis orientation (clockwise from North). In a three-dimensional CRS, the coordinate includes three values, and in addition to the two-dimensional values, an altitude uncertainty (semi-vertical) is added. 🧁
4.9.3.1. XML Encoding
An ellipse is represented in and converted from GML using the following template:
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipse> Figure 8: GML Ellipse TemplateAn ellipsoid is represented in and converted from GML using the following template:
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipsoid> Figure 9: GML Ellipsoid Template4.9.3.2. TLV Encoding
An ellipse is introduced by a type code of 117, and an ellipsoid is introduced by a type code of 118. 🌟
+------+------+
| 117/8|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+
Figure 10: Ellipse or Ellipsoid Encoding4.9.4. Polygon or Prism Shape 🔷
A polygon or prism includes a number of points that describe the outer boundary of an uncertainty region. A prism also includes an altitude for each point and prism height. 🌺
At least 3 points MUST be included in a polygon. In order to interoperate with existing systems, an encoding SHOULD include 15 or fewer points, unless the recipient is known to support larger numbers. 🫶
4.9.4.1. XML Encoding
A polygon is represented in and converted from GML using the following template:
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon> Figure 11: GML Polygon TemplateAlternatively, a series of <pos> elements can be used in place of the single "posList". Each <pos> element contains two or three coordinate values. 💕
Note that the first point is repeated at the end of the sequence of coordinates and no explicit count of the number of points is provided. 👀
A GML polygon that includes altitude cannot be represented perfectly in TLV form. When converting to the binary representation, a two-dimensional CRS is used, and altitude is removed from each coordinate. so yeah, altitude gets dropped in TLV, no cap 🙃
A prism is represented in and converted from GML using the following template:
<gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$
$Coordinate2-1$ ... ...
...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$
</gs:height>
</gs:Prism> Figure 12: GML Prism TemplateAlternatively, a series of <pos> elements can be used in place of the single "posList". Each <pos> element contains three coordinate values. 🌈
4.9.4.2. TLV Encoding ✨
okay bestie, polygons get their own type codes 💅 A polygon with 2D points uses type code 119, a polygon with 3D points uses 120, and a prism uses 121 🔥 You don't need a count field, because the number of points can be inferred from the length of the TLV 🧮
+------+------+
|119-21|Length|
+------+------+------+------+
| (3D-only) Height |
+------+------+------+------+
| Coordinate1-1 |
+------+------+------+------+
| Coordinate1-2 |
+------+------+------+------+
| (3D-only) Coordinate1-3 |
+------+------+------+------+
| Coordinate2-1 |
+------+------+------+------+
...
+------+------+------+------+
| CoordinateN-1 |
+------+------+------+------+
| CoordinateN-2 |
+------+------+------+------+
| (3D-only) CoordinateN-3 |
+------+------+------+------+
Figure 13: Polygon or Prism EncodingNow here's the spicy bit 🌶️ Unlike GML polygons, where the first and last points are the same point, the TLV version does NOT repeat the first point at the end. The duplicate gets dropped from the binary form, so don't be shocked when your polygon looks one point short 🙈
4.9.5. Arc-Band Shape 🌙
okay this one is giving pie slice 🥧 An arc-band describes a region constrained by a range of angles and distances from a predetermined point. It can only be provided for a two-dimensional CRS, so no 3D arc-bands, sorry 🫶
Distance and angular measures are defined in meters and degrees, respectively. Both are encoded as single-precision floating-point values 🦋
4.9.5.1. XML Encoding 💜
an arc-band is represented in and converted from GML using this template:
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1$ $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Outer-Radius$
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$
</gs:openingAngle>
</gs:ArcBand>
Figure 14: GML Arc-Band Template4.9.5.2. TLV Encoding 🧚
an arc-band kicks off with type code 122 🎀
+------+------+
| 122 |Length|
+------+------+------+------+
| Coordinate |
+------+------+------+------+
| Coordinate |
+------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+
Figure 15: Arc-Band Encoding4.10. Dynamic Location TLVs 🌸
dynamic location elements use the definitions in [RFC5962] 📚
4.10.1. Orientation 🧭
the orientation of the Target is described using one or two angles, and it uses type code 123 💖
+------+------+
| 123 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Figure 16: Dynamic Orientation TLVs4.10.2. Speed 🏎️
the speed of the Target is a scalar value in meters per second, and it uses type code 124 💨
+------+------+
| 124 |Length|
+------+------+------+------+
| Speed |
+------+------+------+------+
Figure 17: Dynamic Speed TLVs4.10.3. Heading 🧭
heading (aka direction of travel) is described using one or two angles, and it uses type code 125 ✨
+------+------+
| 125 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Figure 18: Dynamic Heading TLVs4.11. Secondary Map Metadata 🗺️
the optional "map" URL gives a user of relative location a visual reference for the location info 👀 This document doesn't say how the recipient uses the map, or how it finds the reference or offset inside it. Maps can be simple images, vector files, 2D or 3D geospatial databases, or any other representation that both sender and recipient understand 🌈
4.11.1. Map URL 🔗
in XML, the map is a <map> element inside <relative-location>, and it holds the URL. The URL is a UTF-8-encoded string. An "http:" [RFC2616] or "https:" [RFC2818] URL MUST be used, unless the entity creating the PIDF-LO can make sure that authorized recipients can use other URI schemes 🔒 A "type" attribute MUST be present, and it says what kind of map the URL points to. Map types are MIME media types registered in the IANA Media Types registry, like this:
<map type="image/png">
https://www.example.com/floorplans/123South/floor-2</map>in binary, the map type is a separate TLV from the map URL 🧩 The media type uses type code 126, and the URL uses type code 127.
+------+------+------+------+------+------+------+
| 126 |Length| Map Media Type ...
+------+------+------+------+------+------+------+
| 127 |Length| Map Image URL ...
+------+------+------+------+------+------+------+
Figure 19: Map URL TLVs⚠️ the binary form only restricts data to 255 octets, and that could be a real problem for URLs in particular. Apps that use the XML form, but can't guarantee a binary form won't be used, are encouraged to limit the URL size so it fits inside this restriction.
4.11.2. Map Coordinate Reference System 🧮
the CRS used by the map depends on the type of map 🗂️ For example, a map described by a 3-D geometric model of a building might contain a complete CRS description inside it. For some kinds of maps, usually described as images, the CRS used within the map must define the following:
- The CRS origin
- The CRS axes used and their orientation
- The unit of measure used
This document provides elements that let you map between the local CRS used for the relative location and the CRS used for the map, when they aren't the same 🦋
4.11.2.1. Map Reference Point Offset 📍
this optional element identifies the coordinates of the reference point as it appears in the map 🎯 The value is measured in a map-type-dependent manner, using the coordinate system of the map.
for image maps, coordinates start from the upper left corner. Coordinates are first counted by column, with positive values to the right, and then rows are counted with positive values toward the bottom of the image. For such an image, the first item is columns, the second is rows, and any third value applies to any third dimension used in the image coordinate space 🖼️
The <offset> element contains 2 (or 3) coordinates, similar to a GML <pos>. For example:
<offset> 2670.0 1124.0 1022.0</offset>The map reference point uses type code 129 💜
+------+------+
| 129 |Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Figure 20: Map Reference Point Coordinates TLVif it's omitted, a value containing all zeros is assumed 0️⃣ If the coordinates provided contain fewer values than are needed, the first value from the set is applied in place of any absent values. So if a single value is provided, that value is used for Coordinate-2 and Coordinate-3 (if required). If two values are provided and three are required, the value of Coordinate-1 is used in place of Coordinate-3 🫶
4.11.2.2. Map Orientation 🧭
the map orientation covers how the map's direction lines up with the Earth 🌍 It's expressed relative to the orientation of the relative coordinate system. That means map orientation with respect to WGS84 North is the sum of the orientation field and any orientation included in a dynamic portion of the reference location. Both values default to zero if no value is specified 🌸
This type uses a single-precision floating-point value of degrees relative to North.
In XML, the <orientation> element contains a single floating-point value, like <orientation>67.00</orientation>. In TLV form, map orientation uses code 130 👑
+------+------+------+------+------+------+
| 130 |Length| Angle |
+------+------+------+------+------+------+
Figure 21: Map Orientation TLV4.11.2.3. Map Scale ⭐
okay so the optional map scale tells you how the units on the map relate to the meters used in the relative coordinate system 🗺️✨
this type uses a sequence of IEEE 754 [IEEE.754] single-precision floating-point values to represent the scale as a list of numbers. the units depend on the kind of map, so for an image it could be something like pixels per meter 📏
each axis in the coordinate system gets its own scaling factor. for a two-dimensional system you get two values, so x and y can be scaled independently 💜 for a three-dimensional system you get three values, one each for x, y, and z. decoders can work out how many scaling factors there are by looking at the length field, which is kind of genius 🧠
alternatively, a single scaling value MAY be used to apply the same scaling factor to all coordinate components 🌸
images that use a rows/columns coordinate system are often left-handed, which is a whole vibe. a negative value on the y/rows axis scaling can account for the direction change between the y axis in the relative system and the rows axis of the image 🙃
in XML, the <scale> element MAY contain a single scale value or MAY contain 2 (or 3) values in XML list form. in TLV form, scale uses type code 131. the length of the TLV tells you how many scale values are in there:
+------+------+------+------+------+------+
| 131 |Length| Scale(s) ...
+------+------+------+------+------+------+Figure 22: Map Scale TLV 🎀
4.11.3. Map Example 🦋
here's what a map looks like when you write it out:
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
Figure 23: Map Example 💅
5. Examples 🌈
the examples in this section mix and match pieces from [RFC3863], [RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape] 🫶
5.1. Civic PIDF with Polygon Offset 🍓
<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:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<dm:device id="nesspc-1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
<ca:BLD>A</ca:BLD>
<ca:FLR>I</ca:FLR>
<ca:ROOM>113</ca:ROOM>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
<gml:pos>431.0 -733.0</gml:pos> <!--F-->
<gml:pos>431.0 -732.0</gml:pos> <!--E-->
<gml:pos>433.0 -731.0</gml:pos> <!--D-->
<gml:pos>434.0 -732.0</gml:pos> <!--C-->
<gml:pos>434.0 -733.0</gml:pos> <!--B-->
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>5.2. Geo PIDF with Circle Offset 🫧
<?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:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0
</gs:radius>
</gs:Circle>
<rel:relative-location>
<rel:reference>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</rel:reference>
<rel:offset>
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gs:radius>
</gs:Circle>
</rel:offset>
<rel:map>
<rel:url type="image/png">
https://www.example.com/flrpln/123South/flr-2
</rel:url>
<rel:offset>2670.0 1124.0 1022.0</rel:offset>
<rel:orientation>67.00</rel:orientation>
<rel:scale>10 -10</rel:scale>
</rel:map>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>5.3. Civic TLV with Point Offset 🧚
+--------+-------------------------------------------------+
| Type | Value |
+--------+-------------------------------------------------+
| 0 | en |
| | |
| 1 | IL |
| | |
| 3 | Chicago |
| | |
| 34 | Wacker |
| | |
| 18 | Drive |
| | |
| 19 | 3400 |
| | |
| 112 | Reference |
| | |
| 25 | Building A |
| | |
| 27 | Floor 6 |
| | |
| 26 | Suite 213 |
| | |
| 28 | Reception Area |
| | |
| 115 | 100 70 |
| | |
| 126 | image/png |
| | |
| 127 | http://maps.example.com/3400Wacker/A6 |
| | |
| 129 | 0.0 4120.0 |
| | |
| 130 | 113.0 |
| | |
| 131 | 10.6 |
+--------+-------------------------------------------------+6. Schema Definition ✨
okay bestie, this is the part where the spec hands you the actual XML schema, and it's giving pure structure 🎀 Quick heads up first: the mimeType pattern got folded onto multiple lines so it fits the page, and extra whitespace around those line endings MUST be removed before you use the schema 💅
<?xml version="1.0"?>
<xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:relative">
Relative Location for PIDF-LO
</xs:appinfo>
<xs:documentation source="http://ietf.org/rfc/rfc7035.txt">
This schema defines a location representation that allows for
the description of locations that are relative to another.
An optional map reference is also defined.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="relative-location" type="rel:relativeType"/>
<xs:complexType name="relativeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="reference" type="rel:referenceType"/>
<xs:element name="offset" type="rel:offsetType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="referenceType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="offsetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="gml:_Geometry"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="map" type="rel:mapType"/>
<xs:complexType name="mapType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="url" type="rel:mapUrlType"/>
<xs:element name="offset" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="orientation" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="scale" type="rel:doubleList"
minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="mapUrlType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="type" type="rel:mimeType"
default="application/octet-stream"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="mimeType">
<xs:restriction base="xs:token">
<xs:pattern value="[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+
/[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+([\t ]*;([\t ])*[!#$%&
'\*\+\-\.\dA-Z^_`a-z\|~]+=([!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+|
"([!#-\[\]-~]|[\t ]*|\\[\t !-~])*"))*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/>
</xs:simpleType>
</xs:schema>7. Security Considerations 🔐
okay this section is SERIOUS, so let's get into it 😭 This document describes a data format, and how safe it is depends a lot on how that data gets used 💜
Privacy for location data is typically important 🙈 Adding relative location can make the location more precise, but it doesn't otherwise change its privacy considerations, which are covered in [RFC4119] ✨
The map URL in a relative location could accidentally reveal info if a Location Recipient uses it to grab the map 💀 The coverage area of a map, or the parameters of the URL itself, could tell someone where a Target is. Put that together with other info that could reveal which potential Targets the Location Recipient has location info for, and grabbing a map could leak a LOT. Also, the Target and the Location Recipient are often the same entity, so keep that in mind 🫶
Access to map URLs MUST be secured with TLS [RFC5246] (that is, restricting the map URL to be an https URI), unless the map URL cannot leak information about the Target's location. This restricts information about the map URL to the entity serving the map request. If the map URL conveys more information about a Target than a map server is authorized to receive, that URL MUST NOT be included in the PIDF-LO. 🚨
8. IANA Considerations 🌸
8.1. Relative Location Registry 🦋
This document creates a new registry called "Relative Location Parameters". It shares a page, titled "Civic Address Types Registry", with the existing "Civic Address Types (CAtypes)" registry. As defined in [RFC5226], this new registry operates under "IETF Review" rules ✨
The content of this registry includes:
Relative Location Code (RLtype): Numeric identifier, assigned by IANA.Brief description: Short description identifying the meaning of the element.Reference to published specification: A stable reference to an RFC that describes the value in sufficient detail so that interoperability between independent implementations is possible.
Values requested to be assigned into this registry MUST NOT conflict with values assigned in the "Civic Address Types (CAtypes)" registry, or vice versa. The exception is when the IANA Considerations section for the new value explicitly overrides this prohibition and the document defining the value describes how conflicting TLV codes will be interpreted by implementations. To make sure this happens, the CAtypes entries are explicitly reserved in the initial values table below. Those reserved entries can be changed, but only with caution, as explained here 👑
To make this clear for future users of the registry, the following note is added to the "Civic Address Types (CAtypes)" registry:
The registration of new values should be accompanied by a
corresponding reservation in the Relative Location Parameters
registry.Similarly, the "Relative Location Parameters" registry bears the note:
The registration of new values should be accompanied by a
corresponding reservation in the Civic Address Types (CAtypes)
registry.The values defined are:
+--------+----------------------------------------+-----------+
| RLtype | description | Reference |
+--------+----------------------------------------+-----------+
| 0-40 | RESERVED by CAtypes registry | RFC 7035 &|
| 128 | | RFC 4776 |
+--------+----------------------------------------+-----------+
| 111 | relative location reference | RFC 7035 |
| 113 | relative location shape 2D point | RFC 7035 |
| 114 | relative location shape 3D point | RFC 7035 |
| 115 | relative location shape circular | RFC 7035 |
| 116 | relative location shape spherical | RFC 7035 |
| 117 | relative location shape elliptical | RFC 7035 |
| 118 | relative location shape ellipsoid | RFC 7035 |
| 119 | relative location shape 2D polygon | RFC 7035 |
| 120 | relative location shape 3D polygon | RFC 7035 |
| 121 | relative location shape prism | RFC 7035 |
| 122 | relative location shape arc-band | RFC 7035 |
| 123 | relative location dynamic orientation | RFC 7035 |
| 124 | relative location dynamic speed | RFC 7035 |
| 125 | relative location dynamic heading | RFC 7035 |
| 126 | relative location map type | RFC 7035 |
| 127 | relative location map URI | RFC 7035 |
| 129 | relative location map coordinates | RFC 7035 |
| 130 | relative location map angle | RFC 7035 |
| 131 | relative location map scale | RFC 7035 |
+--------+----------------------------------------+-----------+8.2. URN Sub-Namespace Registration 🎀
This document registers a new XML namespace, following the guidelines in [RFC3688] 💖
- URI:
urn:ietf:params:xml:ns:pidf:geopriv10:relative - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net).
- XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location</title>
</head>
<body>
<h1>Format for representing relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7035.txt">
RFC 7035</a>.</p>
</body>
</html>
END8.3. XML Schema Registration 🧚
This section registers an XML schema following the procedures in [RFC3688] ✨
- URI:
urn:ietf:params:xml:schema:pidf:geopriv10:relative - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
- Schema: The XML for this schema is found in Section 6 of this document.
8.4. Geopriv Identifiers Registry 🌈
This section registers two URNs for identifying relative coordinate reference systems. They get added to a new "Geopriv Identifiers" registry following the procedures in Section 4 of [RFC3553]. The "Geopriv Identifiers" registry is entered under the "Uniform Resource Name (URN) Namespace for IETF Use" category 🔥
Registrations in this registry follow the "IETF Review" [RFC5226] policy.
- Registry name: Geopriv Identifiers
- URN Prefix:
urn:ietf:params:geopriv: - Specification: RFC 7035 (this document)
- Repository: http://www.iana.org/assignments/geopriv-identifiers
- Index value: Values in this registry are URNs or URN prefixes that start with the prefix "urn:ietf:params:geopriv:". Each one is registered independently.
Each registration in the "Geopriv Identifiers" registry needs the following info:
- URN: The complete URN that is used, or the prefix for that URN.
- Description: A summary description for the URN or URN prefix.
- Specification: A reference to a specification describing the URN or URN prefix.
- Contact: Email for the person or group making the registration.
- Index value: As described in [RFC3553], URN prefixes that get registered include a description of how the URN is constructed. This isn't applicable for specific URNs.
The "Geopriv Identifiers" registry has two initial registrations, which are in the following sections 💜
8.4.1. Registration of Two-Dimensional Relative Coordinate Reference System URN 🦋
okay so bestie, this bit registers a new URN in the "Geopriv Identifiers" registry 🗂️✨ the one that names a two-dimensional relative coordinate reference system. it's giving organised, and honestly it's so satisfying 🫶
Here's the entry, exactly as the registry wants it:
URN: urn:ietf:params:geopriv:relative:2d
Description: A two-dimensional relative coordinate reference system
Specification: RFC 7035 (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net)
Index value: N/A8.4.2. Registration of Three-Dimensional Relative Coordinate Reference System URN 💜
same energy, just one more dimension 🧚 this registers the "urn:ietf:params:geopriv:relative:3d" URN in the "Geopriv Identifiers" registry. it's the 3D sibling, and it's giving main character energy 💅
URN: urn:ietf:params:geopriv:relative:3d
Description: A three-dimensional relative coordinate reference
system
Specification: RFC 7035 (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net)
Index value: N/A9. Acknowledgements 🫶🌸
okay so this document is the product of a design team on relative location, and it took a village 🌈 besides the authors, the team included Marc Linsner, James Polk, and James Winterbottom. big thank yous to them, periodt 💖
10. References 📚
10.1. Normative References 🔥
- [Clinger1990] Clinger, W., "How to Read Floating Point Numbers Accurately", Proceedings of Conference on Programming Language Design and Implementation, pp. 92-101, 1990.
- [IEEE.754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754-2008, August 2008.
- [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OpenGIS 03-105r1, April 2004, <http://portal.opengeospatial.org/files/?artifact_id=4700>.
- [OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", OGC Best Practice 06-142r1, Version: 1.0, April 2007.
- [RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation standard", RFC 1014, June 1987.
- [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
- [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
- [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
- [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [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.
- [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010.
- [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
- [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and R. George, "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)", RFC 6848, January 2013.
- [WGS84] US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000.
10.2. Informative References 🌷
- [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
- [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
Authors' Addresses 💌
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
US
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net
Brian Rosen
Neustar
470 Conrad Dr
Mars, PA 16046
US
EMail: br@brianrosen.net
Dorothy Stanley
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
US
EMail: dstanley@arubanetworks.com
Gabor Bajko
Nokia
323 Fairchild Drive
Mountain View, CA 94043
US
EMail: gabor.bajko@nokia.com
Allan Thomson
Lookingglass Cyber Solutions
1001 S Kenwood Avenue
Baltimore, MD 21224
US
EMail: athomson@lgscout.comthat's the whole thing, bestie!! ✨🎀💖 the end 🧚
📦 where this page comes from
- ietf: rfc7035 2013-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms