Internet DRAFT - draft-ietf-geopriv-relative-location

draft-ietf-geopriv-relative-location







GEOPRIV                                                       M. Thomson
Internet-Draft                                                 Microsoft
Intended status: Standards Track                                B. Rosen
Expires: March 10, 2014                                          Neustar
                                                              D. Stanley
                                                          Aruba Networks
                                                                G. Bajko
                                                                   Nokia
                                                              A. Thomson
                                                     Cisco Systems, Inc.
                                                      September 06, 2013


                    Relative Location Representation
                draft-ietf-geopriv-relative-location-08

Abstract

   This document defines an extension to PIDF-LO (RFC4119) 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   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.

Copyright Notice




Thomson, et al.          Expires March 10, 2014                 [Page 1]

Internet-Draft              Relative Location             September 2013


   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
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Relative Location . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Relative Coordinate System  . . . . . . . . . . . . . . .   7
     4.2.  Placement of XML Elements . . . . . . . . . . . . . . . .   8
     4.3.  Binary Format . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Distances and Angles  . . . . . . . . . . . . . . . . . .   9
     4.5.  Value Encoding  . . . . . . . . . . . . . . . . . . . . .   9
     4.6.  Relative Location Restrictions  . . . . . . . . . . . . .   9
     4.7.  Baseline TLVs . . . . . . . . . . . . . . . . . . . . . .   9
     4.8.  Reference TLV . . . . . . . . . . . . . . . . . . . . . .   9
     4.9.  Shapes  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.9.1.  Point . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.9.2.  Circle or Sphere Shape  . . . . . . . . . . . . . . .  11
       4.9.3.  Ellipse or Ellipsoid Shape  . . . . . . . . . . . . .  12
       4.9.4.  Polygon or Prism Shape  . . . . . . . . . . . . . . .  14
       4.9.5.  Arc-Band Shape  . . . . . . . . . . . . . . . . . . .  16
     4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . .  18
       4.10.1.  Orientation  . . . . . . . . . . . . . . . . . . . .  18
       4.10.2.  Speed  . . . . . . . . . . . . . . . . . . . . . . .  18
       4.10.3.  Heading  . . . . . . . . . . . . . . . . . . . . . .  18
     4.11. Secondary Map Metadata  . . . . . . . . . . . . . . . . .  19
       4.11.1.  Map URL  . . . . . . . . . . . . . . . . . . . . . .  19
       4.11.2.  Map Coordinate Reference System  . . . . . . . . . .  19
       4.11.3.  Map Example  . . . . . . . . . . . . . . . . . . . .  22
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     5.1.  Civic PIDF with Polygon Offset  . . . . . . . . . . . . .  22
     5.2.  Geo PIDF with Circle Offset . . . . . . . . . . . . . . .  24
     5.3.  Civic TLV with Point Offset . . . . . . . . . . . . . . .  25
   6.  Schema Definition . . . . . . . . . . . . . . . . . . . . . .  25
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28



Thomson, et al.          Expires March 10, 2014                 [Page 2]

Internet-Draft              Relative Location             September 2013


     8.1.  Relative Location Registry  . . . . . . . . . . . . . . .  29
     8.2.  URN Sub-Namespace Registration  . . . . . . . . . . . . .  30
     8.3.  XML Schema Registration . . . . . . . . . . . . . . . . .  31
     8.4.  Geopriv Identifiers Registry  . . . . . . . . . . . . . .  31
       8.4.1.  Registration of Two-Dimentional Relative Coordinate
               Reference System URN  . . . . . . . . . . . . . . . .  32
       8.4.2.  Registration of Three-Dimentional Relative Coordinate
               Reference System URN  . . . . . . . . . . . . . . . .  32
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  33
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     10.2.  Informative References . . . . . . . . . . . . . . . . .  35

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, floorplan 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.




Thomson, et al.          Expires March 10, 2014                 [Page 3]

Internet-Draft              Relative Location             September 2013


          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" 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



Thomson, et al.          Expires March 10, 2014                 [Page 4]

Internet-Draft              Relative Location             September 2013


   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 defined either as 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 a 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, floorplan 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 Co-ordinate
   Reference System (CRS) with the WGS84 [WGS84] CRS.  The document is
   assumed to be useable 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,



Thomson, et al.          Expires March 10, 2014                 [Page 5]

Internet-Draft              Relative Location             September 2013


   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>



Thomson, et al.          Expires March 10, 2014                 [Page 6]

Internet-Draft              Relative Location             September 2013


       <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.

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 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



Thomson, et al.          Expires March 10, 2014                 [Page 7]

Internet-Draft              Relative Location             September 2013


   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].

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

   Type field (T) is an 8-bit unsigned integer.  The type codes used are
   registered an IANA-managed "Relative Location Parameters" registry
   defined by this document, and restricted to not include the values
   defined by the "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 a reference location TLVs.  The reference
   TLVs are followed by the relative offset, and optional map TLDs
   described in this document.



Thomson, et al.          Expires March 10, 2014                 [Page 8]

Internet-Draft              Relative Location             September 2013


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-precision floating point values IEEE 754
   [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 TLV

   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).





Thomson, et al.          Expires March 10, 2014                 [Page 9]

Internet-Draft              Relative Location             September 2013


   +------+------+------+------+------+------+
   |  111 |Length|  Reference TLVs           |
   +------+------+------+------+------+------+

                               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), 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>

                            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.          Expires March 10, 2014                [Page 10]

Internet-Draft              Relative Location             September 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   |
   +------+------+------+------+

                              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>

                            GML Circle Template

   A sphere is represented in and converted from GML using the following
   template:






Thomson, et al.          Expires March 10, 2014                [Page 11]

Internet-Draft              Relative Location             September 2013


   <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>

                            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                   |
   +------+------+------+------+

                         Circle or Sphere Encoding

4.9.3.  Ellipse or Ellipsoid Shape

   A ellipse or ellipsoid describes a point with an elliptical or
   ellipsoidal uncertainty region.

   In a two-dimensional CRS, the coordinate includes two values, plus a
   semi-major axis, a semi-minor axis, a semi-major axis orientation
   (clockwise from North).  In a three-dimensional CRS, the coordinate
   includes three values and in addition to the two-dimensional values,
   an altitude uncertainty (semi-vertical) is added.

4.9.3.1.  XML encoding

   An ellipse is represented in and converted from GML using the
   following template:






Thomson, et al.          Expires March 10, 2014                [Page 12]

Internet-Draft              Relative Location             September 2013


   <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>

                           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>

                          GML Ellipsoid Template

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|
   +------+------+------+------+



Thomson, et al.          Expires March 10, 2014                [Page 13]

Internet-Draft              Relative Location             September 2013


   |  Coordinate-1             |
   +------+------+------+------+
   |  Coordinate-2             |
   +------+------+------+------+
   |  (3D-only) Coordinate-3   |
   +------+------+------+------+------+------+------+------+
   |  Semi-Major Axis          |  Semi-Minor Axis          |
   +------+------+------+------+------+------+------+------+
   |  Orientation              |  (3D) Semi-Vertical Axis  |
   +------+------+------+------+------+------+------+------+

                       Ellipse or Ellipsoid Encoding

4.9.4.  Polygon or Prism Shape

   A polygon or prism include 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>

                           GML Polygon Template





Thomson, et al.          Expires March 10, 2014                [Page 14]

Internet-Draft              Relative Location             September 2013


   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.

   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>

                            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.

4.9.4.2.  TLV Encoding





Thomson, et al.          Expires March 10, 2014                [Page 15]

Internet-Draft              Relative Location             September 2013


   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  |
   +------+------+------+------+

                         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

   A 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.          Expires March 10, 2014                [Page 16]

Internet-Draft              Relative Location             September 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>

                           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            |
   +------+------+------+------+------+------+------+------+

                             Arc-Band Encoding









Thomson, et al.          Expires March 10, 2014                [Page 17]

Internet-Draft              Relative Location             September 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        |
   +------+------+------+------+

                         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             |
   +------+------+------+------+

                            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        |
   +------+------+------+------+

                           Dynamic Heading TLVs





Thomson, et al.          Expires March 10, 2014                [Page 18]

Internet-Draft              Relative Location             September 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, 2-D or 3-D 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                ...
   +------+------+------+------+------+--  --+------+

                               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



Thomson, et al.          Expires March 10, 2014                [Page 19]

Internet-Draft              Relative Location             September 2013


   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>

                      Map Reference Point Example XML

   The map reference point uses a type code of 129.

   +------+------+
   | 129  |Length|
   +------+------+------+------+
   |  Coordinate-1             |
   +------+------+------+------+
   |  Coordinate-2             |
   +------+------+------+------+
   |  (3D-only) Coordinate-3   |
   +------+------+------+------+

                    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



Thomson, et al.          Expires March 10, 2014                [Page 20]

Internet-Draft              Relative Location             September 2013


   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, plus 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, example <orientation>67.00</orientation>.  In TLV form map
   orientation uses the code 130:

   +------+------+------+------+------+------+
   |  130 |Length|  Angle                    |
   +------+------+------+------+------+------+

                            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.          Expires March 10, 2014                [Page 21]

Internet-Draft              Relative Location             September 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)               ...
   +------+------+------+------+------+------+

                               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>

                                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.          Expires March 10, 2014                [Page 22]

Internet-Draft              Relative Location             September 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.          Expires March 10, 2014                [Page 23]

Internet-Draft              Relative Location             September 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.          Expires March 10, 2014                [Page 24]

Internet-Draft              Relative Location             September 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                                            |
        +--------+-------------------------------------------------+


6.  Schema Definition




Thomson, et al.          Expires March 10, 2014                [Page 25]

Internet-Draft              Relative Location             September 2013


   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:documentation source="http://ietf.org/rfc/rfcXXXX.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>




Thomson, et al.          Expires March 10, 2014                [Page 26]

Internet-Draft              Relative Location             September 2013


     <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>



Thomson, et al.          Expires March 10, 2014                [Page 27]

Internet-Draft              Relative Location             September 2013


     <xs:simpleType name="mimeType">
       <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>

                       xml schema relative-location

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.

8.  IANA Considerations





Thomson, et al.          Expires March 10, 2014                [Page 28]

Internet-Draft              Relative Location             September 2013


8.1.  Relative Location Registry

   This document creates a new registry called "Relative Location
   Parameters".  This shares a page, entitled "Civic and Relative
   Location Parameters" with the existing "Civic Address Types Registry
   (CAtypes)" registry.  As defined in [RFC5226], this new registry
   operates under "IETF Review" rules.

   The content of this registry includes:

   Relative Location Code:  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
      which 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 Registry (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 Registry (CAtypes)": 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 Registry
   (CAtypes)" registry.

   The values defined are:

   +--------+----------------------------------------+-----------+
   | RLtype | description                            | Reference |
   +--------+----------------------------------------+-----------+
   | 0-40   | RESERVED by CAtypes registry           | this RFC  |
   | 128    |                                        | & RFC4776 |
   +--------+----------------------------------------+-----------+
   | 111    | relative location reference            | this RFC  |
   | 113    | relative location shape 2D point       | this RFC  |



Thomson, et al.          Expires March 10, 2014                [Page 29]

Internet-Draft              Relative Location             September 2013


   | 114    | relative location shape 3D point       | this RFC  |
   | 115    | relative location shape circular       | this RFC  |
   | 116    | relative location shape spherical      | this RFC  |
   | 117    | relative location shape elliptical     | this RFC  |
   | 118    | relative location shape ellipsoid      | this RFC  |
   | 119    | relative location shape 2D polygon     | this RFC  |
   | 120    | relative location shape 3D polygon     | this RFC  |
   | 121    | relative location shape prism          | this RFC  |
   | 122    | relative location shape arc-band       | this RFC  |
   | 123    | relative location dynamic orientation  | this RFC  |
   | 124    | relative location dynamic speed        | this RFC  |
   | 125    | relative location dynamic heading      | this RFC  |
   | 126    | relative location map type             | this RFC  |
   | 127    | relative location map URI              | this RFC  |
   | 129    | relative location map coordinates      | this RFC  |
   | 130    | relative location map angle            | this RFC  |
   | 131    | relative location map scale            | this RFC  |
   +--------+----------------------------------------+-----------+


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/rfcXXXX.txt">
                    RFCXXXX</a>.</p>
           </body>
         </html>
   <!--



Thomson, et al.          Expires March 10, 2014                [Page 30]

Internet-Draft              Relative Location             September 2013


     [[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:relative

   Registratant Contact:  IETF, GEOPRIV working group
      (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net).

   Schema  The XML for this schema is found in Section 6 of this
      document.

8.4.  Geopriv Identifiers Registry

   This section registers two URNs for 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:  RFCXXXX (this document)

   Respository:  [Editor/IANA note: please include a link to the
      registry location.]

   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.




Thomson, et al.          Expires March 10, 2014                [Page 31]

Internet-Draft              Relative Location             September 2013


   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 of Two-Dimentional 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:  RFCXXXX (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-Dimentional 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:  RFCXXXX (this document)

   Contact:  IETF, GEOPRIV working group (geopriv@ietf.org), Martin
      Thomson (martin.thomson@skype.net).

   Index value:  N/A.



Thomson, et al.          Expires March 10, 2014                [Page 32]

Internet-Draft              Relative Location             September 2013


9.  Acknowledgements

   This is the product of a design team on relative location.  Besides
   the authors, this team included: Marc Linsner, James Polk, and James
   Winterbottom.

10.  References

10.1.  Normative References

   [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.

   [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.




Thomson, et al.          Expires March 10, 2014                [Page 33]

Internet-Draft              Relative Location             September 2013


   [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>.




Thomson, et al.          Expires March 10, 2014                [Page 34]

Internet-Draft              Relative Location             September 2013


   [WGS84]    US National Imagery and Mapping Agency, "Department of
              Defense (DoD) World Geodetic System 1984 (WGS 84), Third
              Edition ", NIMA TR8350.2, January 2000.

10.2.  Informative References

   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
              W., and J. Peterson, "Presence Information Data Format
              (PIDF)", RFC 3863, August 2004.

   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479, July
              2006.

Authors' Addresses

   Martin Thomson
   Microsoft
   3210 Porter Drive
   Palo Alto, CA  94304
   US

   Phone: +1 650-353-1925
   EMail: martin.thomson@skype.net


   Brian Rosen
   Neustar
   470 Conrad Dr
   Mars, PA  16046
   US

   EMail: br@brianrosen.net


   Dorothy Stanley
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089
   US

   EMail: dstanley@arubanetworks.com










Thomson, et al.          Expires March 10, 2014                [Page 35]

Internet-Draft              Relative Location             September 2013


   Gabor Bajko
   Nokia
   323 Fairchild Drive
   Mountain View, CA  94043
   US

   EMail: gabor.bajko@nokia.com


   Allan Thomson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   EMail: althomso@cisco.com



































Thomson, et al.          Expires March 10, 2014                [Page 36]