diff options
Diffstat (limited to 'doc/rfc/rfc7035.txt')
| -rw-r--r-- | doc/rfc/rfc7035.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc7035.txt b/doc/rfc/rfc7035.txt new file mode 100644 index 0000000..5cba9f1 --- /dev/null +++ b/doc/rfc/rfc7035.txt @@ -0,0 +1,2187 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Thomson +Request for Comments: 7035 Microsoft +Category: Standards Track B. Rosen +ISSN: 2070-1721 Neustar + D. Stanley + Aruba Networks + G. Bajko + Nokia + A. Thomson + Lookingglass + October 2013 + + + Relative Location Representation + +Abstract + + This document defines an extension to the Presence Information Data + Format Location Object (PIDF-LO) (RFC 4119) for the expression of + location information that is defined relative to a reference point. + The reference point may be expressed as a geodetic or civic location, + and the relative offset may be one of several shapes. An alternative + binary representation is described. + + Optionally, a reference to a secondary document (such as a map image) + can be included, along with the relationship of the map coordinate + system to the reference/offset coordinate system, to allow display of + the map with the reference point and the relative offset. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7035. + + + + + + + + + +Thomson, et al. Standards Track [Page 1] + +RFC 7035 Relative Location October 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 7035 Relative Location October 2013 + + +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 ...................................38 + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 7035 Relative Location October 2013 + + +1. Introduction + + This document describes a format for the expression of relative + location information. + + A relative location is formed of a reference location plus a relative + offset from that reference location. The reference location can be + represented in either civic or geodetic form. The reference location + can also have dynamic components such as velocity. The relative + offset is specified in meters using a Cartesian coordinate system. + + In addition to the relative location, an optional URI can be provided + to a document that contains a map, floor plan, or other spatially + oriented information. Applications could use this information to + display the relative location. Additional fields allow the map to be + oriented and scaled correctly. + + Two formats are included: an XML form that is intended for use in + PIDF-LO [RFC4119] and a TLV format for use in other protocols such as + those that already convey binary representation of location + information defined in [RFC4776]. + +2. Conventions Used in This Document + + 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 + + This document describes an extension to PIDF-LO [RFC4119] as updated + by [RFC5139] and [RFC5491], to allow the expression of a location as + an offset relative to a reference. + + Reference + Location + o + \ + \ Offset + \ + _\| + x + Relative + Location + + This extension allows the creator of a location object to include two + location values plus an offset. The two location values, named + "baseline" and "reference", combine to form the origin of the offset. + + + +Thomson, et al. Standards Track [Page 4] + +RFC 7035 Relative Location October 2013 + + + The final, relative location is described relative to this reference + point. + + ..--"""--.. + .-' `-. + ,' `. + / Reference \ + / o \ + | \ | + | \ | + | \ | + \ _\| / + `. x .' \_ Baseline + `._ Relative _.' Location + `--..___..--' + + The baseline location is included outside of the <relative-location> + element. The baseline location is visible to a client that does not + understand relative location (i.e., it ignores the + <relative-location> element). + + A client that does understand relative location will interpret the + location within the relative element as a refinement of the baseline + location. This document defines both a reference location, which + serves as a refinement of the baseline location and the starting + point, and an offset, which describes the location of the Target + based on this starting point. + + Creators of location objects with relative location thus have a + choice of how much information to put into the baseline location and + how much to put into the reference location. For example, the + baseline location value could be precise enough to specify a building + that contains the relative location, and the reference location could + specify a point within the building from which the offset is + measured. + + Location objects SHOULD NOT have all location information in the + baseline location. Doing this would cause clients that do not + understand relative location to incorrectly interpret the baseline + location (i.e., the reference point) as the actual, precise location + of the client. The baseline location is intended to carry a location + that encompasses both the reference location and the relative + location (i.e., the reference location plus offset). + + It is possible to provide a valid relative location with no + information in the baseline. However, this provides recipients who + do not understand relative location with no information. A baseline + location SHOULD include sufficient information to encompass both the + + + +Thomson, et al. Standards Track [Page 5] + +RFC 7035 Relative Location October 2013 + + + reference and relative locations while providing a baseline that is + as accurate as possible. + + Both the baseline and the reference location are defined as either a + geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If + the baseline location was expressed as a geodetic location, the + reference MUST be geodetic. If the baseline location was expressed + as a civic address, the reference MUST be civic. + + Baseline and reference locations MAY also include dynamic location + information [RFC5962]. + + The relative location can be expressed using a point (2- or + 3-dimensional) or a shape that includes uncertainty: circle, sphere, + ellipse, ellipsoid, polygon, prism, or arc-band. Descriptions of + these shapes can be found in [RFC5491]. + + Optionally, a reference to a 'map' document can be provided. The + reference is a URI [RFC3986]. The document could be an image or + dataset that represents a map, floor plan, or other form. The type + of document the URI points to is described as a MIME media type + [RFC2046]. Metadata in the relative location can include the + location of the reference point in the map as well as an orientation + (angle from North) and scale to align the document Coordinate + Reference System (CRS) with the World Geodetic System 1984 (WGS84) + [WGS84] CRS. The document is assumed to be usable by the application + receiving the PIDF with the relative location to locate the reference + point in the map. This document does not describe any mechanisms for + displaying or manipulating the document other than providing the + reference location, orientation, and scale. + + As an example, consider 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> + + + +Thomson, et al. Standards Track [Page 6] + +RFC 7035 Relative Location October 2013 + + + <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 + + Relative location is a shape (e.g., point, circle, ellipse). The + shape is defined with a CRS that has a datum defined as the reference + (which appears as a civic address or geodetic location in the tuple) + and the shape coordinates as meter offsets North/East of the datum + measured in meters (with an optional Z offset relative to datum + altitude). An optional angle allows the reference CRS be to rotated + with respect to North. + + + + + + +Thomson, et al. Standards Track [Page 7] + +RFC 7035 Relative Location October 2013 + + +4.1. Relative Coordinate System + + The relative coordinate reference system uses a coordinate system + with two or three axes. + + The baseline and reference locations are used to define a relative + datum. The reference location defines the origin of the coordinate + system. The centroid of the reference location is used when the + reference location contains any uncertainty. + + The axes in this coordinate system are originally oriented based on + the directions of 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. All axes of the + coordinate system use meters as a basic unit. + + Any coordinates in the relative shapes use the described Cartesian + coordinate system. In the XML form, this uses a URN of + "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 alters the relative coordinate system. The resulting + Cartesian coordinate system axes are rotated so that 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 included in the tuple (or equivalent) element + applies to all location elements, including all three components of a + relative location: baseline, reference, and relative. This is + particularly important when there are dynamic components to these + items. A location generator is responsible for ensuring the + consistency of these fields. + +4.2. Placement of XML Elements + + The baseline of the reference location is represented as + <location-info> like a normal PIDF-LO. Relative location adds a new + <relative-location> element to <location-info>. Within + <relative-location>, <reference> and <offset> elements are described. + Within <offset> are the shape elements described below. This + document extends PIDF-LO as described in [RFC6848]. + + + + + + +Thomson, et al. Standards Track [Page 8] + +RFC 7035 Relative Location October 2013 + + +4.3. Binary Format + + This document describes a way to encode the relative location in a + binary TLV form for use in other protocols that use TLVs to represent + location. + + A type-length-value encoding is used. + + +------+------+------+------+------+------+------+ + | Type |Length| Value ... + +------+------+------+------+------+------+------+ + | T | N | Value ... + +------+------+------+------+------+------+------+ + + Figure 1: TLV Tuple Format + + The Type field (T) is an 8-bit unsigned integer. The type codes used + are registered in an IANA-managed "Relative Location Parameters" + registry defined by this document and restricted to not include the + values defined by the "Civic Address Types (CAtypes)" registry. This + restriction permits a location reference and offset to be coded + within the same object without type collisions. + + The Length field (N) is defined as an 8-bit unsigned integer. This + field can encode values from 0 to 255. The length field describes + the number of bytes in the Value. Length does not count the bytes + used for the Type or Length. + + The Value field is defined separately for each type. + + Each element of the relative location has a unique TLV assignment. A + relative location encoded in TLV form includes both baseline and + reference location TLVs and relative location TLVs. The reference + TLVs are followed by the relative offset and optional map TLVs + described in this document. + +4.4. Distances and Angles + + All distance measures used in shapes are expressed in meters. + + All orientation angles used in shapes are expressed in degrees. + Orientation angles are measured from WGS84 Northing to Easting with + zero at Northing. Orientation angles in the relative coordinate + system start from the second coordinate axis (y or Northing) and + increase toward the first axis (x or Easting). + + + + + + +Thomson, et al. Standards Track [Page 9] + +RFC 7035 Relative Location October 2013 + + +4.5. Value Encoding + + 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. + + 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]. + +4.6. Relative Location Restrictions + + More than one relative shape MUST NOT be included in either a PIDF-LO + or TLV encoding of location for a given reference point. + + 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. + +4.7. Baseline TLVs + + Baseline locations are described using the formats defined in + [RFC4776] or [RFC6225]. + +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). + + +------+------+------+------+------+------+ + | 111 |Length| Reference TLVs | + +------+------+------+------+------+------+ + + Figure 2: Reference TLV + + + + + + + + + +Thomson, et al. Standards Track [Page 10] + +RFC 7035 Relative Location October 2013 + + +4.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 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 Template + + Where "$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. + + + + + + + + + + +Thomson, et al. Standards Track [Page 11] + +RFC 7035 Relative Location October 2013 + + +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 Encoding + +4.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 Template + + + + + + + + + +Thomson, et al. Standards Track [Page 12] + +RFC 7035 Relative Location October 2013 + + + A 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 Template + +4.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 Encoding + +4.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. + + + + + + + + +Thomson, et al. Standards Track [Page 13] + +RFC 7035 Relative Location October 2013 + + +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 Template + + An 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 Template + + + + + + + +Thomson, et al. Standards Track [Page 14] + +RFC 7035 Relative Location October 2013 + + +4.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 Encoding + +4.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. + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 15] + +RFC 7035 Relative Location October 2013 + + +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 Template + + Alternatively, 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. + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 16] + +RFC 7035 Relative Location October 2013 + + + 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 Template + + Alternatively, a series of <pos> elements can be used in place of the + single "posList". Each <pos> element contains three coordinate + values. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 17] + +RFC 7035 Relative Location October 2013 + + +4.9.4.2. TLV Encoding + + A polygon containing 2D points uses a type code of 119. A polygon + with 3D points uses a type code of 120. A prism uses a type code of + 121. 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 Encoding + + Note that unlike the polygon representation in GML, the first and + last points are not the same point in the TLV representation. The + duplicated point is removed from the binary form. + +4.9.5. Arc-Band Shape + + An arc-band describes a region constrained by a range of angles and + distances from a predetermined point. This shape can only be + provided for a two-dimensional CRS. + + Distance and angular measures are defined in meters and degrees, + respectively. Both are encoded as single-precision floating-point + values. + + + + + + + +Thomson, et al. Standards Track [Page 18] + +RFC 7035 Relative Location October 2013 + + +4.9.5.1. XML Encoding + + An arc-band is represented in and converted from GML using the + following 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 Template + +4.9.5.2. TLV Encoding + + An arc-band is introduced by a type code of 122. + + +------+------+ + | 122 |Length| + +------+------+------+------+ + | Coordinate | + +------+------+------+------+ + | Coordinate | + +------+------+------+------+------+------+------+------+ + | Inner Radius | Outer Radius | + +------+------+------+------+------+------+------+------+ + | Start Angle | Opening Angle | + +------+------+------+------+------+------+------+------+ + + Figure 15: Arc-Band Encoding + + + + + + + + + +Thomson, et al. Standards Track [Page 19] + +RFC 7035 Relative Location October 2013 + + +4.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. + Orientation uses a type code of 123. + + +------+------+ + | 123 |Length| + +------+------+------+------+ + | Angle | + +------+------+------+------+ + | (Optional) Angle | + +------+------+------+------+ + + Figure 16: Dynamic Orientation TLVs + +4.10.2. Speed + + The speed of the Target is a scalar value in meters per second. + Speed uses a type code of 124. + + +------+------+ + | 124 |Length| + +------+------+------+------+ + | Speed | + +------+------+------+------+ + + Figure 17: Dynamic Speed TLVs + +4.10.3. Heading + + The heading, or direction of travel, is described using one or two + angles. Heading uses a type code of 125. + + +------+------+ + | 125 |Length| + +------+------+------+------+ + | Angle | + +------+------+------+------+ + | (Optional) Angle | + +------+------+------+------+ + + Figure 18: Dynamic Heading TLVs + + + + + +Thomson, et al. Standards Track [Page 20] + +RFC 7035 Relative Location October 2013 + + +4.11. Secondary Map Metadata + + The optional "map" URL can be used to provide a user of relative + location with a visual reference for the location information. This + document does not describe how the recipient uses the map nor how it + locates the reference or offset within the map. Maps can be simple + images, vector files, 2D or 3D geospatial databases, or any other + form of representation understood by both the sender and recipient. + +4.11.1. Map URL + + In XML, the map is a <map> element defined within <relative-location> + and contains the URL. The URL is encoded as a UTF-8-encoded string. + An "http:" [RFC2616] or "https:" [RFC2818] URL MUST be used unless + the entity creating the PIDF-LO is able to ensure that authorized + recipients of this data are able to use other URI schemes. A "type" + attribute MUST be present and specifies the kind of map the URL + points to. Map types are specified as MIME media types as recorded + in the IANA Media Types registry, for example, <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 a type code of 126; the URL uses a type code of 127. + + +------+------+------+------+------+------+------+ + | 126 |Length| Map Media Type ... + +------+------+------+------+------+------+------+ + | 127 |Length| Map Image URL ... + +------+------+------+------+------+------+------+ + + Figure 19: Map URL TLVs + + Note that the binary form restricts data to 255 octets. This + restriction could be problematic for URLs in particular. + Applications that use the XML form, but cannot guarantee that a + binary form won't be used, are encouraged to limit the size of the + URL to fit within 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 the building may contain a + complete CRS description in it. For some kinds of maps, typically + described as images, the CRS used within the map must define the + following: + + + + + + +Thomson, et al. Standards Track [Page 21] + +RFC 7035 Relative Location October 2013 + + + o The CRS origin + + o The CRS axes used and their orientation + + o The unit of measure used + + This document provides elements that allow for a mapping between the + local coordinate reference system used for the relative location and + the coordinate reference system used for the map where they are not + 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. This 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, and + coordinates are first counted by column with positive values to the + right; then, rows are counted with positive values toward the bottom + of the image. For such an image, the first item is columns, the + second 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 a type code of 129. + + +------+------+ + | 129 |Length| + +------+------+------+------+ + | Coordinate-1 | + +------+------+------+------+ + | Coordinate-2 | + +------+------+------+------+ + | (3D-only) Coordinate-3 | + +------+------+------+------+ + + Figure 20: Map Reference Point Coordinates TLV + + If omitted, a value containing all zeros is assumed. If the + coordinates provided contain fewer values than are needed, the first + value from the set is applied in place of any absent values. Thus, + if a single value is provided, that value is used for Coordinate-2 + + + + +Thomson, et al. Standards Track [Page 22] + +RFC 7035 Relative Location October 2013 + + + 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 includes the orientation of the map direction in + relation to the Earth. Map orientation is expressed relative to the + orientation of the relative coordinate system. This means that 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, for example, <orientation>67.00</orientation>. In TLV form, + map orientation uses the code 130: + + +------+------+------+------+------+------+ + | 130 |Length| Angle | + +------+------+------+------+------+------+ + + Figure 21: Map Orientation TLV + +4.11.2.3. Map Scale + + The optional map scale describes the relationship between the units + of measure used in the map, relative to the meters unit used in the + relative coordinate system. + + This type uses a sequence of IEEE 754 [IEEE.754] single-precision + floating-point values to represent scale as a sequence of numeric + values. The units of these values are dependent on the type of map + and could, for example, be pixels per meter for an image. + + A scaling factor is provided for each axis in the coordinate system. + For a two-dimensional coordinate system, two values are included to + allow for different scaling along the x and y axes independently. + For a three-dimensional coordinate system, three values are specified + for the x, y, and z axes. Decoders can determine the number of + scaling factors by examining the length field. + + Alternatively, a single scaling value MAY be used to apply the same + scaling factor to all coordinate components. + + + + +Thomson, et al. Standards Track [Page 23] + +RFC 7035 Relative Location October 2013 + + + Images that use a rows/columns coordinate system often use a left- + handed coordinate system. A negative value for the y/rows axis + scaling value can be used to account for any change in direction + between the y axis used in the relative coordinate system and the + rows axis of the image coordinate system. + + 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 a + type code of 131. The length of the TLV determines how many scale + values are present: + + +------+------+------+------+------+------+ + | 131 |Length| Scale(s) ... + +------+------+------+------+------+------+ + + Figure 22: Map Scale TLV + +4.11.3. Map Example + + An example of expressing a map is: + + <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 combine elements 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"> + + + +Thomson, et al. Standards Track [Page 24] + +RFC 7035 Relative Location October 2013 + + + <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> + + + + + + +Thomson, et al. Standards Track [Page 25] + +RFC 7035 Relative Location October 2013 + + +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> + + + +Thomson, et al. Standards Track [Page 26] + +RFC 7035 Relative Location October 2013 + + + <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 | + +--------+-------------------------------------------------+ + + + + + + + + +Thomson, et al. Standards Track [Page 27] + +RFC 7035 Relative Location October 2013 + + +6. Schema Definition + + Note: The pattern value for "mimeType" has been folded onto + multiple lines. Whitespace has been added to conform to comply + with document formatting restrictions. Extra whitespace around + the line endings MUST be removed before using this 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> + + + +Thomson, et al. Standards Track [Page 28] + +RFC 7035 Relative Location October 2013 + + + <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"> + + + +Thomson, et al. Standards Track [Page 29] + +RFC 7035 Relative Location October 2013 + + + <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 + + This document describes a data format. To a large extent, security + properties of this depend on how this data is used. + + Privacy for location data is typically important. Adding relative + location may increase the precision of the location but does not + otherwise alter its privacy considerations, which are discussed in + [RFC4119]. + + The map URL provided in a relative location could accidentally reveal + information if a Location Recipient uses the URL to acquire the map. + The coverage area of a map, or parameters of the URL itself, could + provide information about the location of a Target. In combination + with other information that could reveal the set of potential Targets + that the Location Recipient has location information for, acquiring a + map could leak significant information. In particular, it is + important to note that the Target and Location Recipient are often + the same entity. + + 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. + + + + + + + + + + +Thomson, et al. Standards Track [Page 30] + +RFC 7035 Relative Location October 2013 + + +8. IANA Considerations + +8.1. Relative Location Registry + + This document creates a new registry called "Relative Location + Parameters". This 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, unless 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 ensure this, 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. + + + + + + + +Thomson, et al. Standards Track [Page 31] + +RFC 7035 Relative Location October 2013 + + + 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 | + +--------+----------------------------------------+-----------+ + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 32] + +RFC 7035 Relative Location October 2013 + + +8.2. URN Sub-Namespace Registration + + This document registers a new XML namespace, as per 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> + + END + +8.3. XML Schema Registration + + This section registers an XML schema as per 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. + + + + + + + + + +Thomson, et al. Standards Track [Page 33] + +RFC 7035 Relative Location October 2013 + + +8.4. Geopriv Identifiers Registry + + This section registers two URNs for use in identifying relative + coordinate reference systems. These are added to a new "Geopriv + Identifiers" registry according to 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 is + registered independently. + + Each registration in the "Geopriv Identifiers" registry requires the + following information: + + 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 groups making the registration. + + Index value: As described in [RFC3553], URN prefixes that are + registered include a description of how the URN is constructed. + This is not applicable for specific URNs. + + The "Geopriv Identifiers" registry has two initial registrations, + included in the following sections. + + + + + + + + + + +Thomson, et al. Standards Track [Page 34] + +RFC 7035 Relative Location October 2013 + + +8.4.1. Registration of Two-Dimensional Relative Coordinate Reference + System URN + + This section registers the "urn:ietf:params:geopriv:relative:2d" URN + in the "Geopriv Identifiers" registry. + + 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/A + +8.4.2. Registration of Three-Dimensional Relative Coordinate Reference + System URN + + This section registers the "urn:ietf:params:geopriv:relative:3d" URN + in the "Geopriv Identifiers" registry. + + 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/A + +9. Acknowledgements + + This document is the product of a design team on relative location. + Besides the authors, this team included Marc Linsner, James Polk, and + James Winterbottom. + + + + + + + + + + + +Thomson, et al. Standards Track [Page 35] + +RFC 7035 Relative Location October 2013 + + +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. + + + + +Thomson, et al. Standards Track [Page 36] + +RFC 7035 Relative Location October 2013 + + + [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. + + + + + + + +Thomson, et al. Standards Track [Page 37] + +RFC 7035 Relative Location October 2013 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 38] + +RFC 7035 Relative Location October 2013 + + +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.com + + + + + + + +Thomson, et al. Standards Track [Page 39] + |