GEOPRIVInternet Engineering Task Force (IETF) M. ThomsonInternet-DraftRequest for Comments: 7035 MicrosoftIntended status:Category: Standards Track B. RosenExpires: March 10, 2014ISSN: 2070-1721 Neustar D. Stanley Aruba Networks G. Bajko Nokia A. ThomsonCisco Systems, Inc. September 06,Lookingglass October 2013 Relative Location Representationdraft-ietf-geopriv-relative-location-08Abstract This document defines an extension toPIDF-LO (RFC4119)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 coordinatesystemsystem, to allow display of the map with the reference point and the relative offset. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication 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 ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 10, 2014.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 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3....................................................3 2. ConventionsusedUsed inthis document . . . . . . . . . . . . . . 3This Document ...............................3 3. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 3........................................................3 4. Relative Location. . . . . . . . . . . . . . . . . . . . . . 7...............................................7 4.1. Relative Coordinate System. . . . . . . . . . . . . . . 7.................................7 4.2. Placement of XML Elements. . . . . . . . . . . . . . . . 8..................................8 4.3. Binary Format. . . . . . . . . . . . . . . . . . . . . . 8..............................................8 4.4. Distances and Angles. . . . . . . . . . . . . . . . . . 9.......................................9 4.5. Value Encoding. . . . . . . . . . . . . . . . . . . . . 9.............................................9 4.6. Relative Location Restrictions. . . . . . . . . . . . . 9.............................9 4.7. Baseline TLVs. . . . . . . . . . . . . . . . . . . . . . 9..............................................9 4.8. ReferenceTLV . . . . . . . . . . . . . . . . . . . . . . 9TLVs .............................................9 4.9. Shapes. . . . . . . . . . . . . . . . . . . . . . . . . 10....................................................10 4.9.1. Point. . . . . . . . . . . . . . . . . . . . . . . . 10..............................................10 4.9.2. Circle or Sphere Shape. . . . . . . . . . . . . . . 11.............................11 4.9.3. Ellipse or Ellipsoid Shape. . . . . . . . . . . . . 12.........................12 4.9.4. Polygon or Prism Shape. . . . . . . . . . . . . . . 14.............................14 4.9.5. Arc-Band Shape. . . . . . . . . . . . . . . . . . . 16.....................................17 4.10. Dynamic Location TLVs. . . . . . . . . . . . . . . . . . 18....................................19 4.10.1. Orientation. . . . . . . . . . . . . . . . . . . . 18.......................................19 4.10.2. Speed. . . . . . . . . . . . . . . . . . . . . . . 18.............................................19 4.10.3. Heading. . . . . . . . . . . . . . . . . . . . . . 18...........................................19 4.11. Secondary Map Metadata. . . . . . . . . . . . . . . . . 19...................................20 4.11.1. Map URL. . . . . . . . . . . . . . . . . . . . . . 19...........................................20 4.11.2. Map Coordinate Reference System. . . . . . . . . . 19...................20 4.11.3. Map Example. . . . . . . . . . . . . . . . . . . . 22.......................................23 5. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . 22.......................................................23 5.1. Civic PIDF with Polygon Offset. . . . . . . . . . . . . 22............................23 5.2. Geo PIDF with Circle Offset. . . . . . . . . . . . . . . 24...............................25 5.3. Civic TLV with Point Offset. . . . . . . . . . . . . . . 25...............................26 6. Schema Definition. . . . . . . . . . . . . . . . . . . . . . 25..............................................27 7. Security Considerations. . . . . . . . . . . . . . . . . . . 28........................................29 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 28............................................30 8.1. Relative Location Registry. . . . . . . . . . . . . . . 29................................30 8.2. URN Sub-Namespace Registration. . . . . . . . . . . . . 30............................31 8.3. XML Schema Registration. . . . . . . . . . . . . . . . . 31...................................32 8.4. Geopriv Identifiers Registry. . . . . . . . . . . . . . 31..............................32 8.4.1. Registration ofTwo-DimentionalTwo-Dimensional Relative Coordinate Reference System URN. . . . . . . . . . . . . . . . 32....................33 8.4.2. Registration ofThree-DimentionalThree-Dimensional Relative Coordinate Reference System URN. . . . . . . . . . . . . . . . 32....................33 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 33...............................................34 10. References. . . . . . . . . . . . . . . . . . . . . . . . . 33....................................................34 10.1. Normative References. . . . . . . . . . . . . . . . . . 33.....................................34 10.2. Informative References. . . . . . . . . . . . . . . . . 35...................................36 1. Introduction This document describes a format for the expression of relative location information. A relative location is formed of a referencelocation,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,floorplanfloor 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. ConventionsusedUsed inthis documentThis 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. The final, relative location is described relative to this reference point. ..--"""--.. .-' `-. ,' `. / Reference \ / o \ | \ | | \ | | \ | \ _\| / `. x .' \_ Baseline `._ Relative _.' Location `--..___..--' The"baseline"baseline location is included outside of the<relative- location><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"reference location, which serves as a refinement of the baseline location and the startingpoint;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"baseline location and how much to put into the"reference"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 reference and relative locations while providing a baseline that is as accurate as possible. Both the baseline and the reference location are definedeitheras 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 beacivic. Baseline and reference locations MAY also include dynamic location information [RFC5962]. The relative location can be expressed using a point (2- or3-dimensional),3-dimensional) or a shape that includes uncertainty: circle, sphere, ellipse, ellipsoid, polygon,prismprism, 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,floorplanfloor 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 documentCo-ordinateCoordinate Reference System (CRS) with theWGS84World Geodetic System 1984 (WGS84) [WGS84] CRS. The document is assumed to beuseableusable 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,orientationorientation, 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> <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 thetuple),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. 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,NorthNorth, 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"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,referencereference, 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><location-info> like a normal PIDF-LO. Relative location adds a new<relative- location><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]. 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 formatTLV 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 thisdocument,document and restricted to not include the values defined by the"CAtypes""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 anda referencerelative location TLVs. The reference TLVs are followed by the relativeoffset,offset and optional mapTLDsTLVs 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). 4.5. Value Encoding The binary form uses single-precisionfloating pointfloating-point valuesIEEE 754[IEEE.754] to represent coordinates,distancedistance, and angle measures.Single precisionSingle-precision values are 32-bit values with a sign bit, 8 exponentbitsbits, 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. ReferenceTLVTLVs 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 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),("urn:ietf:params:geopriv:relative:2d") or a 3D(urn:ietf:params:geopriv:relative:3d),("urn:ietf:params:geopriv:relative:3d"), depending on the shape type. The binary form of each shape uses a different shape type for2d2D and3d3D 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. XMLencodingEncoding 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 aurn:ietf:params:geopriv:relative:2d"urn:ietf:params:geopriv:relative:2d" orurn:ietf:params:geopriv:relative:3d"urn:ietf:params:geopriv:relative:3d" and "$Coordinate-3$" is omitted if the CRS is two-dimensional. 4.9.1.2. TLVencodingEncoding 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 twovaluesvalues, and the resulting shape forms a circle. In a three-dimensional CRS, the coordinate includes threevaluesvalues, and the resulting shape forms a sphere. 4.9.2.1. XMLencodingEncoding 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 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. TLVencodingEncoding 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 ShapeAAn ellipse or ellipsoid describes a point with an elliptical or ellipsoidal uncertainty region. In a two-dimensional CRS, the coordinate includes twovalues,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 threevaluesvalues, and in addition to the two-dimensional values, an altitude uncertainty (semi-vertical) is added. 4.9.3.1. XMLencodingEncoding 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 4.9.3.2. TLVencodingEncoding An ellipse is introduced by a type code of117117, 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 prismincludeincludes 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 Template Alternatively, a series of"pos"<pos> elements can be used in place of the single "posList". Each"pos"<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, atwotwo- dimensional CRS isusedused, and altitude is removed from each coordinate. 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"<pos> elements can be used in place of the single "posList". Each"pos"<pos> element contains three coordinate values. 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 ShapeAAn 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 anddegreesdegrees, respectively. Both are encoded assingle precision floating pointsingle-precision floating-point values. 4.9.5.1. XMLencodingEncoding 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 4.10. Dynamic Location TLVs Dynamic location elements use the definitions in [RFC5962]. 4.10.1. Orientation The orientation of thetargetTarget 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 thetargetTarget 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 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,2-D2D or3-D3D 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 aUTF-8 encodedUTF-8-encoded string. An "http:"([RFC2616])[RFC2616] or "https:"([RFC2818])[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 Typesregistry. For exampleregistry, for example, <maptype="image/png">https://www.example.com/floorplans/123South/floor-2< /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: 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 amap-type dependentmap- type-dependent manner, using the coordinate system of the map. For image maps, coordinates start from the upper leftcornercorner, and coordinates are first counted by column with positive values to the right;thenthen, rows are counted with positive values toward the bottom of the image. For such an image, the first item is columns, the secondrowsrows, 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".<pos>. For example: <offset> 2670.0 1124.0 1022.0</offset>Map Reference Point Example XMLThe 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 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 orientationfield, plusfield 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 asingle precision floating pointsingle-precision floating-point value of degrees relative to North. In XML, the <orientation> element contains a singlefloating pointfloating-point value,examplefor example, <orientation>67.00</orientation>. In TLVformform, 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 pointsingle-precision floating-point values to represent scale as a sequence of numeric values. The units of these values are dependent on the type ofmap,map andcouldcould, forexampleexample, 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,yy, 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. Images that use a rows/columns coordinate system often use a left- handed coordinate system. A negative value for they/rows-axisy/rows axis scaling value can be used to account for any change in direction between they-axisy 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 scalevalue,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"> <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 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"><!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL 'http://ietf.org/rfc/rfcXXXX.txt' with the URL of published document and remove this note.]] --><xs:annotation> <xs:appinfo source="urn:ietf:params:xml:schema:pidf:geopriv10:relative"> Relative Location for PIDF-LO </xs:appinfo> <xs:documentationsource="http://ietf.org/rfc/rfcXXXX.txt">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>xml schema relative-location7. 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 thelocation,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 atargetTarget 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". This shares a page,entitledtitled "Civicand Relative Location Parameters"Address Types Registry" with the existing "Civic Address TypesRegistry(CAtypes)" registry. As defined in [RFC5226], this new registry operates under "IETF Review" rules. The content of this registry includes: Relative LocationCode: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 RFCwhichthat 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 TypesRegistry(CAtypes)" registry or vice versa, unless the IANAconsiderationsConsiderations 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 withcautioncaution, as explained here. To make this clear for future users of the registry, the following note is added to the "Civic Address TypesRegistry (CAtypes)":(CAtypes)" registry: The registration of new values should be accompanied by a corresponding reservation in the"RelativeRelative LocationParameters"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"CivicCivic Address TypesRegistry (CAtypes)"(CAtypes) registry. The values defined are: +--------+----------------------------------------+-----------+ | RLtype | description | Reference | +--------+----------------------------------------+-----------+ | 0-40 | RESERVED by CAtypes registry |thisRFC|7035 &| | 128 | |& RFC4776RFC 4776 | +--------+----------------------------------------+-----------+ | 111 | relative location reference |thisRFC 7035 | | 113 | relative location shape 2D point |thisRFC 7035 | | 114 | relative location shape 3D point |thisRFC 7035 | | 115 | relative location shape circular |thisRFC 7035 | | 116 | relative location shape spherical |thisRFC 7035 | | 117 | relative location shape elliptical |thisRFC 7035 | | 118 | relative location shape ellipsoid |thisRFC 7035 | | 119 | relative location shape 2D polygon |thisRFC 7035 | | 120 | relative location shape 3D polygon |thisRFC 7035 | | 121 | relative location shape prism |thisRFC 7035 | | 122 | relative location shape arc-band |thisRFC 7035 | | 123 | relative location dynamic orientation |thisRFC 7035 | | 124 | relative location dynamic speed |thisRFC 7035 | | 125 | relative location dynamic heading |thisRFC 7035 | | 126 | relative location map type |thisRFC 7035 | | 127 | relative location map URI |thisRFC 7035 | | 129 | relative location map coordinates |thisRFC 7035 | | 130 | relative location map angle |thisRFC 7035 | | 131 | relative location map scale |thisRFC 7035 | +--------+----------------------------------------+-----------+ 8.2. URN Sub-Namespace Registration This document registers a new XML namespace, as per the guidelines in[RFC3688]).[RFC3688]. URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative RegistrantContact:IETF,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 <ahref="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> RFCXXXX</a>.</p>href="http://www.rfc-editor.org/rfc/rfc7035.txt"> RFC 7035</a>.</p> </body> </html><!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX with the number of the published document and remove this note.]] -->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:relativeRegistratantRegistrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson(martin.thomson@skype.net). Schema(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 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 theIETF Review"IETF Review" [RFC5226] policy. Registry name: Geopriv Identifiers URN Prefix: urn:ietf:params:geopriv: Specification:RFCXXXXRFC 7035 (this document)Respository: [Editor/IANA note: please include a link to the registry location.]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:URNURN: The complete URN that isused,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. 8.4.1. Registration ofTwo-DimentionalTwo-Dimensional Relative Coordinate Reference System URN This section registers the "urn:ietf:params:geopriv:relative:2d" URN in the "Geopriv Identifiers" registry.URNURN: urn:ietf:params:geopriv:relative:2d Description: A two-dimensional relative coordinate reference system Specification:RFCXXXXRFC 7035 (this document) Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson(martin.thomson@skype.net).(martin.thomson@skype.net) Index value:N/A.N/A 8.4.2. Registration ofThree-DimentionalThree-Dimensional Relative Coordinate Reference System URN This section registers the "urn:ietf:params:geopriv:relative:3d" URN in the "Geopriv Identifiers" registry.URNURN: urn:ietf:params:geopriv:relative:3d Description: A three-dimensional relative coordinate reference system Specification:RFCXXXXRFC 7035 (this document) Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson(martin.thomson@skype.net).(martin.thomson@skype.net) Index value:N/A.N/A 9. Acknowledgements This document is the product of a design team on relative location. Besides the authors, this teamincluded:included Marc Linsner, James Polk, and James Winterbottom. 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.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[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.[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. [IEEE.754] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", IEEE Standard 754-1985, January 2003. [Clinger1990] Clinger, W., "How to Read Floating Point Numbers Accurately", Proceedings of Conference on Programming Language Design and Implementation pp. 92-101, 1990, <ftp: //ftp.ccs.neu.edu/pub/people/will/howtoread.ps>.[WGS84] US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), ThirdEdition ",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 ThomsonCisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134Lookingglass Cyber Solutions 1001 S Kenwood Avenue Baltimore, MD 21224 US EMail:althomso@cisco.comathomson@lgscout.com