GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7035

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="[!#$%&amp;'\*\+\-\.\dA-Z^_`a-z\|~]+
      /[!#$%&amp;'\*\+\-\.\dA-Z^_`a-z\|~]+([\t ]*;([\t ])*[!#$%&amp;
      '\*\+\-\.\dA-Z^_`a-z\|~]+=([!#$%&amp;'\*\+\-\.\dA-Z^_`a-z\|~]+|
       &quot;([!#-\[\]-~]|[\t ]*|\\[\t !-~])*&quot;))*"/>
     </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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7035.txt · Last modified: 2013/10/17 21:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki