GEOPRIV                                                       M. Thomson
Internet-Draft                                        Andrew Corporation
Intended status: Standards Track                                B. Rosen
Expires: January 6, 2011                                         Neustar
                                                              D. Stanley
                                                          Aruba Networks
                                                                G. Bajko
                                                                   Nokia
                                                              A. Thomson
                                                     Cisco Systems, Inc.
                                                            July 5, 2010


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

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.  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.
   Also included in this document is a Type/Length/Value (TLV)
   representation of the relative location for use in other protocols
   that use TLVs.

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 January 6, 2011.

Copyright Notice



Thomson, et al.          Expires January 6, 2011                [Page 1]


Internet-Draft              Relative Location                  July 2010


   Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Binary Format  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Relative Location  . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Reference TLV  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Orientation of Relative Offset Coordinate Reference
           System . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Shape Encoding . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Units of Measure . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  Coordinates  . . . . . . . . . . . . . . . . . . . . . . .  9
     6.3.  On Uncertainty and Encoding  . . . . . . . . . . . . . . . 10
   7.  Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Point  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       7.1.1.  XML encoding . . . . . . . . . . . . . . . . . . . . . 10
       7.1.2.  TLV encoding . . . . . . . . . . . . . . . . . . . . . 10
     7.2.  Circle or Sphere Shape . . . . . . . . . . . . . . . . . . 11
       7.2.1.  XML encoding . . . . . . . . . . . . . . . . . . . . . 11
       7.2.2.  TLV encoding . . . . . . . . . . . . . . . . . . . . . 12
     7.3.  Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . . . 12
       7.3.1.  XML encoding . . . . . . . . . . . . . . . . . . . . . 13
       7.3.2.  TLV encoding . . . . . . . . . . . . . . . . . . . . . 14
     7.4.  Polygon or Prism Shape . . . . . . . . . . . . . . . . . . 14
       7.4.1.  XML Encoding . . . . . . . . . . . . . . . . . . . . . 15
       7.4.2.  TLV Encoding . . . . . . . . . . . . . . . . . . . . . 16
     7.5.  Arc-Band Shape . . . . . . . . . . . . . . . . . . . . . . 17
       7.5.1.  XML encoding . . . . . . . . . . . . . . . . . . . . . 18
       7.5.2.  TLV Encoding . . . . . . . . . . . . . . . . . . . . . 18
   8.  Secondary Map Metadata . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Map URL  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.2.  Map Coordinate Reference System  . . . . . . . . . . . . . 19
       8.2.1.  Map Reference Point Offset . . . . . . . . . . . . . . 19
       8.2.2.  Map Orientation  . . . . . . . . . . . . . . . . . . . 20



Thomson, et al.          Expires January 6, 2011                [Page 2]


Internet-Draft              Relative Location                  July 2010


       8.2.3.  Map Scale  . . . . . . . . . . . . . . . . . . . . . . 21
     8.3.  Map Example  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 22
     9.2.  Geo PIDF with Circle Offset  . . . . . . . . . . . . . . . 23
     9.3.  Civic TLV with Point Offset  . . . . . . . . . . . . . . . 25
   10. Schema Definition  . . . . . . . . . . . . . . . . . . . . . . 25
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
     12.1. Relative Location Registry . . . . . . . . . . . . . . . . 28
     12.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 29
     12.3. XML Schema Registration  . . . . . . . . . . . . . . . . . 30
     12.4. CRS public identifier registration . . . . . . . . . . . . 30
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     14.2. Informative References . . . . . . . . . . . . . . . . . . 33


































Thomson, et al.          Expires January 6, 2011                [Page 3]


Internet-Draft              Relative Location                  July 2010


1.  Introduction

   This document describes a format for the expression of relative
   location information.

   The location is given relative to a reference, which is expressed
   with a civic or geodetic representation, with the relative offset as
   described in this document.  The offset is expressed in meters, and a
   directional vector is either implied to be earth North/East or
   supplied explicitly.  Also defined is an optional URI to a document
   that can contain a map/floorplan/illustration ('map') upon which the
   relative location can be plotted as well as an optional angle, offset
   and scale defining the Coordinate Reference System (CRS) of the map.

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

   Numeric values in this scheme are all represented using floating
   point values [IEEE.754].  Single precision values are 32-bit values
   with a sign bit, 8 exponent bits and 23 fractional bits.  Double
   precision values are 64-bit values with a sign bit, 11 exponent bits
   and 52 fractional bits.

3.  Overview

   This document describes an update to PIDF-LO [RFC4119] as updated by
   [RFC5139] and [RFC5491], to allow the expression of a location as an
   offset relative to a reference.

   This extension effectively allows the creator of a location object to
   include two location values plus an offset.  The "baseline" location
   that is given outside of the <relative-location> element is what will
   be visible to a client that does not understand that extension (i.e.,
   one that ignores the <relative-location> element).  A client that
   does understand this extension will interpret the location within the
   relative element as a refinement of the baseline location, which
   gives the reference location for the relative offset.

   Creators of location objects with relative location thus have a
   choice of how much information to put into the "baseline" location



Thomson, et al.          Expires January 6, 2011                [Page 4]


Internet-Draft              Relative Location                  July 2010


   and how much to put into the "reference" location.  For example, all
   location information could be put inside the <relative-location>
   element, so that clients that do not understand relative location
   would receive no location information at all.  Alternatively, 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.

   In any case, it is RECOMMENDED that the baseline location be general
   enough to describe both the reference location and the relative
   location (reference plus offset).  In particular, while it is
   possible to put all location information into the "reference"
   location (leaving an universally broad "baseline"), 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.

   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.

   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.  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.  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 CRS with the WGS-84 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,
   relative to a civic location:

   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"



Thomson, et al.          Expires January 6, 2011                [Page 5]


Internet-Draft              Relative Location                  July 2010


             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:INT N="Door" R="A">Front</ca:INT>
               </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>




Thomson, et al.          Expires January 6, 2011                [Page 6]


Internet-Draft              Relative Location                  July 2010


4.  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                         ...
   +------+------+------+------+------+------+------+------+
   |  X   |      N      |  Value label                   ...
   +------+------+------+------+------+------+------+------+

                        Figure 1: TLV-tuple format

   Type field (X) is defined as a single byte.  The type codes used are
   registered an IANA managed 'RLtypes' 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 with unique TLVs.

   The Length field (N) is defined as an unsigned integer that is two
   bytes in length.  This field can encode values from 0 to 65535.  The
   length field describes the number of bytes in the Value.  Length does
   not count the bytes used for the Type or Length.  Note that the
   length field of a TLVs using the CAtypes registry (such as those
   defined in [RFC5139] are one byte.  Since the type codes defined here
   are restricted to be different from the CAtypes, the difference in
   the length field can be accommodated.

   The value field is defined explicitly for each shape in this
   document.

5.  Relative Location

   Relative location is a shape (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.

   The CRS for 2-D is denoted with an SRSname of
   urn:ietf:params:geopriv:relative:2d, while the 3-D CRS is
   urn:ietf:params:geopriv:relative:3d.  A 2D offset MUST NOT be used
   with a 3D reference, and a 3D offset MUST NOT be used with a 2D



Thomson, et al.          Expires January 6, 2011                [Page 7]


Internet-Draft              Relative Location                  July 2010


   reference

   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
   shape elements described below.

   The individual elements of the relative location have unique TLV
   assignments.  A relative location encoded in TLV would have the
   baseline location reference TLDs followed by an outer reference TLD
   which contains within it the reference refinement TLVs.  The
   reference TLD is followed by the relative offset, and optional map
   TLDs described in this document.

   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.

5.1.  Reference TLV

   When a reference is encoded in TLV, the refinement of the baseline
   location is represented in a reference TLV, inside of which are civic
   CAtype TLVs (if the baseline was a civic) or geo TLVs (if the
   baseline was a geo).

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

                               Reference TLV

5.2.  Orientation of Relative Offset Coordinate Reference System

   The relative location element may contain an optional angle relative
   to North that defines the CRS of the offset.  The offset CRS scale is
   always meters, and the datum is the reference.  The angle is encoded
   as a single precision floating point degrees, with 0.0 representing
   North.  In xml, the angle is contained in an <ro-angle> element,
   example <ro-angle>50.0</ro-angle>.  In TLV encoding:

   +------+------+------+------+------+------+------+
   |  112 |   Length    |  Angle                    |
   +------+------+------+------+------+------+------+




Thomson, et al.          Expires January 6, 2011                [Page 8]


Internet-Draft              Relative Location                  July 2010


                      Relative Offset Orientation TLV

6.  Shape Encoding

   Shape data is used to represent regions of uncertainty in the
   relative CRS.

   The description of each shape type includes a description of how that
   type is encoded in Geography Markup Language (GML) [OGC.GML-3.1.1],
   consistent with the rules in [RFC5491], but with a relative CRS.  The
   CRS is identified by a distinguished urn --tbd-- defined by this
   document.

6.1.  Units of Measure

   All distance measures used in shapes are expressed in meters using
   single precision floating point values.

   All orientation angles used in shapes are expressed in degrees using
   single precision floating point values.  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).

6.2.  Coordinates

   Coordinates are a sequence of numeric values.  These are encoded as a
   sequence of double precision floating point numbers.

   Coordinates are represented using a single precision floating point
   value as described in IEEE 754 [IEEE.754].

   Every CRS MUST define how many values are present in each set of
   coordinates, the axes that each value applies to, the order of axes,
   and the units that are used for each axis.

   For the two-dimensional CRS, coordinates are made of two values.  The
   first value corresponds to latitude (Easting).  The second value
   corresponds to longitude (Northing).  Both axis are rotated relative
   to North by the ro-angle, if present.

   For the three-dimensional CRS, coordinates are made of three values,
   the first two of which are the same as for the two-dimensional CRS.
   The third value corresponds to the altitude above the plane of the
   horizontal at the reference location and is measured in meters.





Thomson, et al.          Expires January 6, 2011                [Page 9]


Internet-Draft              Relative Location                  July 2010


6.3.  On Uncertainty and Encoding

   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 is chosen according to
   [Clinger1990].

7.  Shapes

   Nine shape type codes are defined.

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

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

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



Thomson, et al.          Expires January 6, 2011               [Page 10]


Internet-Draft              Relative Location                  July 2010


   +------+------+------+------+

                              Point Encoding

7.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.  The uncertainty radius is specified as a single precision
   floating point value (32 bits: 1 sign bit, 8 exponent bits, 23
   fractional bits in binary).

   The circle size is defined as a radius in meters encoded as single
   precision floating point value

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

     <gs:Sphere xmlns:gml="http://www.opengis.net/gml"
                xmlns:gml="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



Thomson, et al.          Expires January 6, 2011               [Page 11]


Internet-Draft              Relative Location                  July 2010


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

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

   Distance and angular measures are defined in meters and degrees
   respectively.  Both are encoded as single precision floating point
   values.


















Thomson, et al.          Expires January 6, 2011               [Page 12]


Internet-Draft              Relative Location                  July 2010


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

                           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







Thomson, et al.          Expires January 6, 2011               [Page 13]


Internet-Draft              Relative Location                  July 2010


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

                       Ellipse or Ellipsoid Encoding

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

   The height of the prism is encoded as a single precision floating
   point value.

















Thomson, et al.          Expires January 6, 2011               [Page 14]


Internet-Draft              Relative Location                  July 2010


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

   Alternatively, a series of "pos" elements can be used in place of the
   single "posList".  Each "pos" element contains two 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 completely
   in binary.  When converting to the binary representation, a two
   dimensional CRS is used and altitude is removed from each coordinate.


















Thomson, et al.          Expires January 6, 2011               [Page 15]


Internet-Draft              Relative Location                  July 2010


   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.

7.4.2.  TLV Encoding

   A polygon is introduced with a type code of 119.  A prism is
   introduced with a type code of 120.














Thomson, et al.          Expires January 6, 2011               [Page 16]


Internet-Draft              Relative Location                  July 2010


   +------+-------------+
   |119/20|    Length   |
   +------+------+------+------+------+------+
   |  Count      |  (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 required to be the same in the TLV
   representation. an explicit count of the number of points is provided
   in 'Count'.

7.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 January 6, 2011               [Page 17]


Internet-Draft              Relative Location                  July 2010


7.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">
         $Inner-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:Ellipsoid>

                           GML Arc-Band Template

7.5.2.  TLV Encoding

   An arc-band is introduced by a type code of 122.

   +------+-------------+
   | 121  |    Length   |
   +------+------+------+------+
   |  Coordinate               |
   +------+------+------+------+
   |  Coordinate               |
   +------+------+------+------+------+------+------+------+
   |  Inner Radius             |  Outer Radius             |
   +------+------+------+------+------+------+------+------+
   |  Start Angle              |  Opening Angle            |
   +------+------+------+------+------+------+------+------+

                             Arc-Band Encoding

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



Thomson, et al.          Expires January 6, 2011               [Page 18]


Internet-Draft              Relative Location                  July 2010


   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.

8.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:" or "https:" 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 "map-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 map-type="image/png">https://
   www.example.com/floorplans/123South/floor-2</map>.  In binary, the
   maptype is a separate TLV from the map URL:

   +------+------+------+------+------+------+--  --+------+
   |  122 |   Length    |   maptype         ...
   +------+------+------+------+------+------+--  --+------+
   |  123 |   Length    |   Map Image URL   ...
   +------+------+------+------+------+------+--  --+------+

                               Map URL TLVs

8.2.  Map Coordinate Reference System

   The CRS used by the map depends on the type of map.  For example, a
   map described by a 3-D geometric model of the building may contain a
   complete CRS description in it.  For some kinds of maps, typically
   described as images, the CRS used within the map must define the
   following:

   o  The CRS origin

   o  The CRS axes used and their orientation

   o  The unit of measure used

   This document provides elements that allow for a mapping between the
   local coordinate reference system used for the relative location and
   the coordinate reference system used for the map where they are not
   the same.

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



Thomson, et al.          Expires January 6, 2011               [Page 19]


Internet-Draft              Relative Location                  July 2010


   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 <map-offset> element contains 2 (or 3) coordinates similar to a
   GML "pos", For example:

        <map-offset> 2670.0 1124.0 1022.0</map-offset>

                      Map Reference Point Example XML


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

                    Map Reference Point Coordinates TLV

   The encoding for coordinates is described in Section 6.2.

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

8.2.2.  Map Orientation

   The map orientation includes the orientation of the map direction
   ('UP') 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 two orientation fields.  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



Thomson, et al.          Expires January 6, 2011               [Page 20]


Internet-Draft              Relative Location                  July 2010


   value, example <orientation>67.00</orientation>.  In TLV form:

   +------+------+------+------+------+------+------+
   |  125 |   Length    |  Angle                    |
   +------+------+------+------+------+------+------+

                            Map Orientation TLV

8.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 is map-type dependent, and could
   for example be pixels per meter in image map-types.

   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.

   Alternatively, a single scaling value MAY be used to apply the same
   scaling factor to all coordinate components.

   Images that use a rows/columns coordinate system often use a left-
   handed coordinate system.  A negative value for 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 the single scale value, or
   may contain 2 (or 3) values similar to a GML "pos" with separate
   scale values.  In TLV form:

   +------+------+------+------+------+------+
   |  126 |   Length    |  Scales       ...
   +------+------+------+------+------+------+

                               Map Scale TLV








Thomson, et al.          Expires January 6, 2011               [Page 21]


Internet-Draft              Relative Location                  July 2010


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

9.  Examples

9.1.  Civic PIDF with Polygon Offset

    <presence xmlns="urn:ietf:params:xml:ns:pidf"
              xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
              xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
              xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
              xmlns:gml="http://www.opengis.net/gml"
              xmlns:gs="http://www.opengis.net/pidflo/1.0"
              entity="pres:ness@example.com">
      <dm:device id="nesspc-1">
        <gp:geopriv>
          <gp:location-info>
            <ca:civicAddress xml:lang="en-AU">
              <ca:country>AU</ca:country>
              <ca:A1>NSW</ca:A1>
              <ca:A3>Wollongong</ca:A3>
              <ca:A4>North Wollongong</ca:A4>
              <ca:RD>Flinders</ca:RD>
              <ca:STS>Street</ca:STS>
              <ca:HNO>123</ca:HNO>
            </ca:civicAddress>
            <rel:relative-location>
              <rel:reference>
                <ca:civicAddress xml:lang="en-AU">
                  <ca:INT N="Building">A</ca:INT>
                  <ca:INT N="Level">I</ca:INT>
                  <ca:INT N="Suite">113</ca:INT>
                  <ca:INT N="Door" R="A">Front</ca:INT>
                </ca:civicAddress>
              </rel:reference>



Thomson, et al.          Expires January 6, 2011               [Page 22]


Internet-Draft              Relative Location                  July 2010


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

9.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"
              entity="pres:point2d@example.com">
      <dm:device id="point2d">
        <gp:geopriv>
          <gp:location-info>
            <gml: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>
            </gml:Circle>
            <rel:relative-location>
              <rel:reference>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>-34.407 150.883</gml:pos>



Thomson, et al.          Expires January 6, 2011               [Page 23]


Internet-Draft              Relative Location                  July 2010


                </gml:Point>
              </rel:reference>
              <rel:offset>
                <gml:Circle xmlns:gml="http://www.opengis.net/gml"
                      srsName="urn:ietf:params:geopriv:relative:2d">
                    <gml:pos>500.0 750.0</gml:pos>
                    <gml:radius uom="urn:ogc:def:uom:EPSG::9001">
                       5.0
                     </gml:radius>
               </gml:Circle>
            </rel:relative-location>
            <map:map>
              <map:urltype="image/png">
                https://www.example.com/flrpln/123South/flr-2</gp:url>
              <map:offset> 2670.0 1124.0 1022.0</gp:offset>
              <map:orientation>67.00</gp:orientation>
              <map:scale>10</gp:scale>
            </map:map>
          </gp:location-info>
          <gp:usage-rules/>
          <gp:method>Wiremap</gp:method>
        </gp:geopriv>
        <dm:deviceID>mac:1234567890ab</dm:deviceID>
        <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
      </dm:device>
     </gp:geopriv>
    </status>
    <timestamp>2003-06-22T20:57:29Z</timestamp>
   </tuple>
  </presence>





















Thomson, et al.          Expires January 6, 2011               [Page 24]


Internet-Draft              Relative Location                  July 2010


9.3.  Civic TLV with Point Offset

           +--------+-------------------------------------------------+
           | Type   | Value                                           |
           +--------+-------------------------------------------------+
           | 0      | en                                              |
           |        |                                                 |
           | 1      | IL                                              |
           |        |                                                 |
           | 3      | Chicago                                         |
           |        |                                                 |
           | 34     | Wacker                                          |
           |        |                                                 |
           | 18     | Drive                                           |
           |        |                                                 |
           | 19     | 3400                                            |
           |        |                                                 |
           | 112    | Reference                                       |
           |        |                                                 |
           | 40     | BBuilding|A                                     |
           |        |                                                 |
           | 40     | AFloor|6th                                      |
           |        |                                                 |
           | 40     | BSuite|213                                      |
           |        |                                                 |
           | 40     | ADoor|Front                                     |
           |        |                                                 |
           | 115    | 100 70                                          |
           |        |                                                 |
           | 122    | image/png                                       |
           |        |                                                 |
           | 123    | http://maps.example.com/3400Wacker/A6           |
           |        |                                                 |
           | 124    | 0.0 4120.0                                      |
           |        |                                                 |
           | 125    | 113.0                                           |
           |        |                                                 |
           | 126    | 10.6                                            |
           +--------+-------------------------------------------------+

10.  Schema Definition

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



Thomson, et al.          Expires January 6, 2011               [Page 25]


Internet-Draft              Relative Location                  July 2010


       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>

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




Thomson, et al.          Expires January 6, 2011               [Page 26]


Internet-Draft              Relative Location                  July 2010


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

     <!-- From draft-ietf-httpbis-p3-payload-09, excluding
             the obsolete parts -->
     <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>



Thomson, et al.          Expires January 6, 2011               [Page 27]


Internet-Draft              Relative Location                  July 2010


     <xs:simpleType name="doubleList">
       <xs:list itemType="xs:double"/>
     </xs:simpleType>

   </xs:schema>

                       xml schema relative-location

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

   [[Not that interesting, but it could be relevant ?]]  The fractional
   bits in IEEE 754 [IEEE.754] floating point values can be used as a
   covert channel.  For values of either zero or infinity, non-zero
   fraction bits could be used to convey information.  If the presence
   of covert channels is not desired then the fractional bits MUST be
   set to zero.  There is no need to represent NaN (not a number) in
   this encoding.

12.  IANA Considerations

12.1.  Relative Location Registry

   This document creates a new registry called 'RLtypes'.  As defined in
   [RFC5226], this registry operates under "IETF Consensus" rules.

   The content of this registry includes:

   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
   which describes the value in sufficient detail so that
   interoperability between independent implementations is possible.

   IANA is requested to not permit values to be assigned into this
   registry which conflict with values assigned in the CAtypes registry
   or to permit values to be assigned into the CAtypes registry which
   conflict with values assigned to to this registry unless the IANA



Thomson, et al.          Expires January 6, 2011               [Page 28]


Internet-Draft              Relative Location                  July 2010


   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

   The values defined are:

      +--------+----------------------------------------+-----------+
      | RLtype | description                            | Reference |
      +--------+-------+--------------------------------+-----------+
      | 111    | relative location reference            | this RFC  |
      | 112    | relative location angle                | this RFC  |
      | 113    | relative location shape 2D point       | this RFC  |
      | 114    | relative location shape 3D point       | this RFC  |
      | 115    | relative location shape circlular      | 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 arc-band       | this RFC  |
      | 120    | relative location shape polygon        | this RFC  |
      | 121    | relative location shape prism          | this RFC  |
      | 122    | relative location map type             | this RFC  |
      | 123    | relative location map URI              | this RFC  |
      | 124    | relative location map coordinates      | this RFC  |
      | 125    | relative location map angle            | this RFC  |
      | 126    | relative location map scale            | this RFC  |
      +--------+-------+--------------------------------+-----------+

12.2.  URN Sub-Namespace Registration

   This document registers a new XML namespace, as per the guidelines in
   [RFC3688]) that has been registered with IANA.




















Thomson, et al.          Expires January 6, 2011               [Page 29]


Internet-Draft              Relative Location                  July 2010


    URI:  urn:ietf:params:xml:ns:pidf:geopriv10:relative

    Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
       Martin Thomson (martin.thomson@andrew.com).

    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 in GEOPRIV</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>
   <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
        with the number of the published
        document and remove this note.]] -->
        END

12.3.  XML Schema Registration

   This section registers an XML schema as per the procedures in
   [RFC3688].


    URI:  urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation

    Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
       Martin Thomson (martin.thomson@andrew.com).

       The XML for this schema can be found as the entirety of Section 7
       of this document.

12.4.  CRS public identifier registration

   This section registers two public identifiers as per the procedures
   in [RFC3688].


   URI:  urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d



Thomson, et al.          Expires January 6, 2011               [Page 30]


Internet-Draft              Relative Location                  July 2010


   Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   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 2d CRS</title>
         </head>
         <body>
           <h1>Identifier for a 2D CRS in GEOPRIV relative location</h1>
           <h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d</h2>
           <p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
                 RFCXXXX</a>.</p>
         </body>
      </html>
  <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
       with the number of the published document
       and remove this note.]] -->
    END

    URI:  urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d

    Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   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 3d CRS</title>
         </head>
         <body>
           <h1>Identifier for a 3D CRS in GEOPRIV relative location</h1>
           <h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2>
           <p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
                 RFCXXXX</a>.</p>
         </body>
      </html>
  <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX



Thomson, et al.          Expires January 6, 2011               [Page 31]


Internet-Draft              Relative Location                  July 2010


       with the number of the published
       document and remove this note.]] -->
       END


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

14.  References

14.1.  Normative References

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [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



Thomson, et al.          Expires January 6, 2011               [Page 32]


Internet-Draft              Relative Location                  July 2010


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

14.2.  Informative References

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

Authors' Addresses

   Martin Thomson
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   EMail: martin.thomson@andrew.com


   Brian Rosen
   Neustar
   470 Conrad Dr
   Mars, PA  16046
   US

   EMail: br@brianrosen.net









Thomson, et al.          Expires January 6, 2011               [Page 33]


Internet-Draft              Relative Location                  July 2010


   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
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   EMail: althomso@cisco.com


























Thomson, et al.          Expires January 6, 2011               [Page 34]