[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-winterbottom-geopriv-pdif-lo-profile) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5491

Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Updates: 4119 (if approved)                           Andrew Corporation
Intended status: Standards Track                           H. Tschofenig
Expires: August 23, 2008                          Nokia Siemens Networks
                                                       February 20, 2008


GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
               draft-ietf-geopriv-pdif-lo-profile-11.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).












Winterbottom, et al.     Expires August 23, 2008                [Page 1]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


Abstract

   The Presence Information Data Format Location Object (PIDF-LO)
   specification provides a flexible and versatile means to represent
   location information.  There are, however, circumstances that arise
   when information needs to be constrained in how it is represented.
   In these circumstances the range of options that need to be
   implemented are reduced.  There is growing interest in being able to
   use location information contained in a PIDF-LO for routing
   applications.  To allow successful interoperability between
   applications, location information needs to be normative and more
   tightly constrained than is currently specified in the RFC 4119
   (PIDF-LO).  This document makes recommendations on how to constrain,
   represent and interpret locations in a PIDF-LO.  It further
   recommends a subset of GML that is mandatory to implement by
   applications involved in location based routing.



































Winterbottom, et al.     Expires August 23, 2008                [Page 2]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Using Location Information . . . . . . . . . . . . . . . . . .  6
     3.1.  Single Civic Location Information  . . . . . . . . . . . .  9
     3.2.  Civic and Geospatial Location Information  . . . . . . . .  9
     3.3.  Manual/Automatic Configuration of Location Information . . 10
     3.4.  Multiple Location Objects in a Single PIDF-LO  . . . . . . 11
   4.  Geodetic Coordinate Representation . . . . . . . . . . . . . . 13
   5.  Geodetic Shape Representation  . . . . . . . . . . . . . . . . 14
     5.1.  Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15
     5.2.  Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  Point  . . . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.2.  Polygon  . . . . . . . . . . . . . . . . . . . . . . . 17
       5.2.3.  Circle . . . . . . . . . . . . . . . . . . . . . . . . 19
       5.2.4.  Ellipse  . . . . . . . . . . . . . . . . . . . . . . . 20
       5.2.5.  Arc Band . . . . . . . . . . . . . . . . . . . . . . . 21
       5.2.6.  Sphere . . . . . . . . . . . . . . . . . . . . . . . . 23
       5.2.7.  Ellipsoid  . . . . . . . . . . . . . . . . . . . . . . 24
       5.2.8.  Prism  . . . . . . . . . . . . . . . . . . . . . . . . 26
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 32
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34






















Winterbottom, et al.     Expires August 23, 2008                [Page 3]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


1.  Introduction

   The Presence Information Data Format Location Object (PIDF-LO)
   [RFC4119] is the recommended way of encoding location information and
   associated privacy policies.  Location information in a PIDF-LO may
   be described in a geospatial manner based on a subset of GMLv3, or as
   civic location information [I-D.ietf-geopriv-revised-civic-lo].  A
   GML profile for expressing geodetic shapes in a PIDF-LO is described
   in [GeoShape].  Uses for PIDF-LO are envisioned in the context of
   numerous location based applications.  This document makes
   recommendations for formats and conventions to make interoperability
   less problematic.

   The PIDF-LO provides a general presence format for representing
   location information, and permits specification of location
   information relating to a whole range of aspects of a Target.  The
   general presence data model is described in [RFC4479] and caters for
   a presence document to describe different aspects of the reachability
   of a presentity.  Continuing this approach, a presence document may
   contain several GEOPRIV objects that specify different locations and
   aspects of reachability relating to a presentity.  This degree of
   flexibility is important, and recommendations in this document make
   no attempt to forbid the usage of a PIDF-LO in this manner.  This
   document provides a specific set of guidelines for building presence
   documents when it is important to unambiguously convey exactly one
   location.

























Winterbottom, et al.     Expires August 23, 2008                [Page 4]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


2.  Terminology

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

   The definition for "Target" is taken from [RFC3693].

   In this document a "discrete location" is defined as a place, point,
   area or volume in which a Target can be found.

   The term "compound location" is used to describe location information
   represented by a composite of both civic and geodetic information.
   An example of compound location might be a geodetic polygon
   describing the perimeter of a building and a civic element
   representing the floor in the building.

   The term "method" in this document refers to the mechanism used to
   determine the location of a Target.  This may be something employed
   by a LIS, or by the Target itself.  It specifically does not refer to
   the LCP used to deliver location information either to the Target or
   the Recipient.

   The term "source" is used to refer to the LIS, node or device from
   which a Recipient (Target or Third-Party) obtains location
   information.

























Winterbottom, et al.     Expires August 23, 2008                [Page 5]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


3.  Using Location Information

   The PIDF format provides for an unbounded number of <tuple>,
   <device>, and <person> elements.  Each of these elements contains a
   single <status> element that may contain more than one <geopriv>
   element as a child.  Each <geopriv> element must contain at least the
   following two child elements: <location-info> element and <usage-
   rules> element.  One or more chunks of location information are
   contained inside a <location-info> element.

   Hence, a single PIDF document may contain an arbitrary number of
   location objects some or all of which may be contradictory or
   complementary.  Graphically, the structure of a PIDF-LO document can
   be depicted as shown in Figure 1.

   <?xml version="1.0" encoding="UTF-8"?>
   <presence>
      <tuple> -- #1
          <status>
               <geopriv> -- #1
                   <location-info>
                       location chunk #1
                       location chunk #2
                       ...
                       location chunk #n
                   <usage-rules>
               </geopriv>
               <geopriv> -- #2
               <geopriv> -- #3
               ...
               <geopriv> -- #m
          </status>
      </tuple>
      <device>
         <status>
               <geopriv> -- #1
                   <location-info>
                       location chunk #1
                       location chunk #2
                       ...
                       location chunk #n
                   <usage-rules>
               </geopriv>
               <geopriv> -- #2
               <geopriv> -- #3
               ...
               <geopriv> -- #m
          </status>



Winterbottom, et al.     Expires August 23, 2008                [Page 6]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


      </device>
      <person>
         <status>
               <geopriv> -- #1
                   <location-info>
                       location chunk #1
                       location chunk #2
                       ...
                       location chunk #n
                   <usage-rules>
               </geopriv>
               <geopriv> -- #2
               <geopriv> -- #3
               ...
               <geopriv> -- #m
          </status>
      </person>
      <tuple> -- #2
      <device> -- #2
      <person> -- #2
      ...
      <tuple> -- #o
   </presence>

                 Figure 1: Structure of a PIDF-LO Document

   All of these potential sources and storage places for location lead
   to confusion for the generators, conveyors and consumers of location
   information.  Practical experience within the United States National
   Emergency Number Association (NENA) in trying to solve these
   ambiguities led to a set of conventions being adopted.  These rules
   do not have any particular order, but should be followed by creators
   and consumers of location information contained in a PIDF-LO to
   ensure that a consistent interpretation of the data can be achieved.

   Rule #1:  A <geopriv> element MUST describe a discrete location.


   Rule #2:  Where a discrete location can be uniquely described in more
      than one way, each location description SHOULD reside in a
      separate <tuple>, <device>, or <person> element.


   Rule #3:  Providing more than one <geopriv> element in a single
      presence document (PIDF) MUST only be done if the locations refer
      to the same place or are put into different element types.  For
      example, one location in a <tuple>, a second location in a
      <device> element, and a third location in a <person> element.



Winterbottom, et al.     Expires August 23, 2008                [Page 7]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


         This may occur if a Target's location is determined using a
         series of different techniques, or the Target wishes to
         represent her location as well as the location of her PC.  In
         general avoid putting more than one location into a document
         unless it makes sense to do so.


   Rule #4:  Providing more than one location chunk in a single
      <location-info> element SHOULD be avoided where possible.  Rule #5
      and Rule #6 provide further refinement.


   Rule #5:  When providing more than one location chunk in a single
      <location-info> element the locations MUST be provided by a common
      source at the same time and by the same location determination
      method.


   Rule #6:  Providing more than one location chunk in a single
      <location-info> element SHOULD only be used for representing
      compound location referring to the same place.

         For example, a geodetic location describing a point, and a
         civic location indicating the floor in a building.


   Rule #7:  Where compound location is provided in a single <location-
      info> element, the coarse location information MUST be provided
      first.

         For example, a geodetic location describing an area, and a
         civic location indicating the floor should be represented with
         the area first followed by the civic location.


   Rule #8:  Where a PIDF document contains more than one <geopriv>
      element, the priority of interpretation is given to the first
      <device> element in the document containing a location.  If no
      <device> element containing a location is present in the document,
      then priority is given to the first <tuple> element containing a
      location.  Locations contained in <person> tuples SHOULD only be
      used as a last resort.


   Rule #9:  Where multiple PIDF documents can be sent or received
      together, say in a multi-part MIME body, and current location
      information is required by the recipient, then document selection
      SHOULD be based on document order, with the first document



Winterbottom, et al.     Expires August 23, 2008                [Page 8]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


      considered first.

   The following examples illustrate the application of these rules.

3.1.  Single Civic Location Information

   Jane is at a coffee shop on the ground floor of a large shopping
   mall.  Jane turns on her laptop and connects to the coffee-shop's
   WiFi hotspot, Jane obtains a complete civic address for her current
   location, for example using the DHCP civic mechanism defined in
   [RFC4776].  A Location Object is constructed consisting of a single
   PIDF document, with a single <tuple> or <device> element, a single
   <status> element, a single <geopriv> element, and a single location
   chunk residing in the <location-info> element.  This document is
   unambiguous, and should be interpreted consistently by receiving
   nodes if sent over the network.

3.2.  Civic and Geospatial Location Information

   Mike is visiting his Seattle office and connects his laptop into the
   Ethernet port in a spare cube.  In this case location information is
   geodetic location, with the altitude represented as a building floor
   number.  Mike's main location is the point specified by the geodetic
   coordinates.  Further, Mike is on the second floor of the building
   located at these coordinates.  Applying rules #6 and #7, the
   resulting compound location information is shown in Figure 2.

























Winterbottom, et al.     Expires August 23, 2008                [Page 9]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?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:gml="http://www.opengis.net/gml"
         xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         entity="pres:mike@seattle.example.com">
       <dm:device id="mikepc">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-43.5723 153.21760</gml:pos>
               </gml:Point>
               <cl:civicAddress>
                 <cl:FLR>2</cl:FLR>
               </cl:civicAddress>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
         <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
       </dm:device>
     </presence>

                                 Figure 2

3.3.  Manual/Automatic Configuration of Location Information

   Loraine has a predefined civic location stored in her laptop, since
   she normally lives in Sydney, the address is for her Sydney-based
   apartment.  Loraine decides to visit sunny San Francisco, and when
   she gets there she plugs in her laptop and makes a call.  Loraine's
   laptop receives a new location from the visited network in San
   Francisco.  As this system cannot be sure that the pre-existing, and
   new location, both describe the same place, Loraine's computer
   generates a new PIDF-LO and will use this to represent Loraine's
   location.  If Loraine's computer were to add the new location to her
   existing PIDF location document (breaking rule #3), then the correct
   information may still be interpreted by the Location Recipient
   providing Loraine's system applies rule #9.  In this case the
   resulting order of location information in the PIDF document should
   be San Francisco first, followed by Sydney.  Since the information is
   provided by different sources, rule #8 should also be applied and the
   information placed in different tuples with the tuple containing the
   San Francisco location first.



Winterbottom, et al.     Expires August 23, 2008               [Page 10]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


3.4.  Multiple Location Objects in a Single PIDF-LO

   Vanessa has her PC with her at the park, but due to a
   misconfiguration, her PC reports her location as being in the office.
   The resulting PIDF-LO will have a <device> element showing the
   location of Vanessa's PC as the park, and a <person> element saying
   that Vanessa is in her office.

     <?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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         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">
         <status>
           <gp:geopriv>
             <gp:location-info>
                 <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-34.410649 150.87651</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   30
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
             <method>GPS</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
         <dm:deviceID>mac:1234567890ab</dm:deviceID>
       </dm:device>
       <dm:person id="ness">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <civicAddress xml:lang="en-AU">
                 <country>AU</country>
                 <A1>NSW</A1>
                 <A3>     Wollongong
                 </A3><A4>North Wollongong
                 </A4>
                 <RD>Flinders</RD><STS>Street</STS>
                 <RDBR>Campbell Street</RDBR>
                 <LMK>
                   Gilligan's Island



Winterbottom, et al.     Expires August 23, 2008               [Page 11]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


                 </LMK> <LOC>Corner</LOC>
                 <NAM> Main Bank </NAM>
                 <PC>2500</PC>
                 <ROOM> 398 </ROOM>
                 <PLC>store</PLC>
                 <POBOX>Private Box 15</POBOX>
               </civicAddress>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Manual</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-24T12:28:04Z</timestamp>
       </dm:person>
     </presence>

                                 Figure 3


































Winterbottom, et al.     Expires August 23, 2008               [Page 12]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


4.  Geodetic Coordinate Representation

   The geodetic examples provided in RFC 4119 [RFC4119] are illustrated
   using the <gml:location> element, which uses the <gml:coordinates>
   element inside the <gml:Point> element and this representation has
   several drawbacks.  Firstly, it has been deprecated in later versions
   of GML (3.1 and beyond) making it inadvisable to use for new
   applications.  Secondly, the format of the coordinates type is opaque
   and so can be difficult to parse and interpret to ensure consistent
   results, as the same geodetic location can be expressed in a variety
   of ways.  The PIDF-LO Geodetic Shapes specification [GeoShape]
   provides a specific GML profile for expressing commonly used shapes
   using simple GML representations.  The shapes defined in [GeoShape]
   are the recommended shapes to ensure interoperability.





































Winterbottom, et al.     Expires August 23, 2008               [Page 13]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


5.  Geodetic Shape Representation

   The cellular mobile world today makes extensive use of geodetic based
   location information for emergency and other location-based
   applications.  Generally these locations are expressed as a point
   (either in two or three dimensions) and an area or volume of
   uncertainty around the point.  In theory, the area or volume
   represents a coverage in which the user has a relatively high
   probability of being found, and the point is a convenient means of
   defining the centroid for the area or volume.  In practice, most
   systems use the point as an absolute value and ignore the
   uncertainty.  It is difficult to determine if systems have been
   implemented in this manner for simplicity, and even more difficult to
   predict if uncertainty will play a more important role in the future.
   An important decision is whether an uncertainty area should be
   specified.

   The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight
   shape types most of which are easily translated into shapes
   definitions used in other applications and protocols, such as Open
   Mobile Alliance (OMA) Mobile Location Protocol (MLP).  For
   completeness the shapes defined in [GeoShape] are listed below:

   o  Point (2d and 3d)

   o  Polygon (2d)

   o  Circle (2d)

   o  Ellipse (2d)

   o  Arc band (2d)

   o  Sphere (3d)

   o  Ellipsoid (3d)

   o  Prism (3d)

   All above-listed shapes are mandatory to implement.

   The GeoShape specification [GeoShape] also describes a standard set
   of coordinate reference systems (CRS), unit of measure (UoM) and
   conventions relating to lines and distances.  The use of the WGS-84
   coordinate reference system and the usage of EPSG-4326 (as identified
   by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape
   representations and EPSG-4979 (as identified by the URN
   urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume



Winterbottom, et al.     Expires August 23, 2008               [Page 14]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


   representations is mandated.  Distance and heights are expressed in
   meters using EPSG-9001 (as identified by the URN
   urn:ogc:def:uom:EPSG::9001).  Angular measures MUST use either
   degrees or radians.  Measures in degrees MUST be identified by the
   URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be
   identified by the URN urn:ogc:def:uom:EPSG::9101

   Implementations MUST specify the CRS using the srsName attribute on
   the outermost geometry element.  The CRS MUST NOT be respecified or
   changed for any sub-elements.  The srsDimension attribute SHOULD be
   omitted, since the number of dimensions in these CRSs is known.  A
   CRS MUST be specified using the above URN notation only;
   implementations do not need to support user-defined CRSs.

   It is RECOMMENDED that where uncertainty is included, a confidence of
   95% is used.  Specifying a convention for confidence enables better
   use of uncertainty values.

5.1.  Polygon Restrictions

   The Polygon shape type defined in [GeoShape] intentionally does not
   place any constraints on the number of vertices that may be included
   to define the bounds of a polygon.  This allows arbitrarily complex
   shapes to be defined and conveyed in a PIDF-LO.  However, where
   location information is to be used in real-time processing
   applications, such as location dependent routing, having arbitrarily
   complex shapes consisting of tens or even hundreds of points could
   result in significant performance impacts.  To mitigate this risk it
   is recommended that Polygon shapes be restricted to a maximum of 15
   points (16 including the repeated point) when the location
   information is intended for use in real-time applications.  This
   limit of 15 points is chosen to allow moderately complex shape
   definitions while at the same time enabling interoperation with other
   location transporting protocols such as those defined in 3GPP (see
   [3GPP-TS-23_032]) and OMA where the 15 point limit is already
   imposed.

   The edges of a polygon are defined by the shortest path between two
   points in space (not a geodesic curce).  To avoid significant errors
   arising from potential geodesic interpolation, the length between
   adjacent vertices SHOULD be restricted to a maximum of 130km.  More
   information relating to this restriction is provided in [GeoShape].

   A connecting line SHALL NOT cross another connecting line of the same
   Polygon.

   Polygons SHOULD be defined with the upward normal pointing up.  This
   is accomplished by defining the vertices in a counter-clockwise



Winterbottom, et al.     Expires August 23, 2008               [Page 15]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


   direction.

   Points specified in a polygon MUST be coplanar and it is RECOMMENDED
   that where points are specified in 3 dimensions that all points
   maintain the same altitude.

5.2.  Shape Examples

   This section provides some examples of where some of the more complex
   shapes are used, how they are determined, and how they are
   represented in a PIDF-LO.  Complete details on all of the GeoShape
   types are provided in [GeoShape].

5.2.1.  Point

   The point shape type is the simplest form of geodetic LI, which is
   natively supported by GML.  The gml:Point element is used when there
   is no known uncertainty.  A point also forms part of a number of
   other geometries.  A point may be specified using either WGS 84
   (latitude, longitude) or WGS 84 (latitude, longitude, altitude).
   Figure 4 shows a 2d point:

     <?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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         xmlns:gml="http://www.opengis.net/gml"
         entity="pres:point2d@example.com">
       <dm:device id="point2d">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-34.407 150.883</gml:pos>
               </gml:Point>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
         <dm:deviceID>mac:1234567890ab</dm:deviceID>
       </dm:device>
     </presence>

                                 Figure 4




Winterbottom, et al.     Expires August 23, 2008               [Page 16]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


   Figure 5 shows a 3d point:

     <?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:gml="http://www.opengis.net/gml"
         entity="pres:point3d@example.com">
       <dm:device id="point3d">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
                          xmlns:gml="http://www.opengis.net/gml">
                 <gml:pos>-34.407 150.883 24.8</gml:pos>
               </gml:Point>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
         <dm:deviceID>mac:1234567890ab</dm:deviceID>
       </dm:device>
     </presence>

                                 Figure 5

5.2.2.  Polygon

   The polygon shape may be used to represent a building outline or
   coverage area.  The first and last points of the polygon have to be
   the same.  For example, looking at the hexagon in Figure 6 with
   vertices, A, B, C, D, E, and F. The resulting polygon will be defined
   with 7 points, with the first and last points both having the
   coordinates of point A.

       F--------------E
      /                \
     /                  \
    /                    \
   A                      D
    \                    /
     \                  /
      \                /
       B--------------C

                                 Figure 6



Winterbottom, et al.     Expires August 23, 2008               [Page 17]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         entity="pres:hexagon@example.com">
       <tuple id="polygon-pos">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:exterior>
                   <gml:LinearRing>
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                     <gml:pos>43.111 -73.322</gml:pos> <!--B-->
                     <gml:pos>43.111 -73.222</gml:pos> <!--C-->
                     <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                     <gml:pos>43.411 -73.222</gml:pos> <!--E-->
                     <gml:pos>43.411 -73.322</gml:pos> <!--F-->
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                   </gml:LinearRing>
                 </gml:exterior>
               </gml:Polygon>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 7

   In addition to the form shown in Figure 7 GML supports a posList
   which provides a more compact representation for the coordinates of
   the Polygon vertices than the discrete pos elements.  The more
   compact form is shown in Figure 8.  Both forms are permitted.














Winterbottom, et al.     Expires August 23, 2008               [Page 18]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         entity="pres:hexagon@example.com">
       <tuple id="polygon-poslist">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:exterior>
                   <gml:LinearRing>
                     <gml:posList>
                       43.311 -73.422 43.111 -73.322
                       43.111 -73.222 43.311 -73.122
                       43.411 -73.222 43.411 -73.322
                       43.311 -73.422
                     </gml:posList>
                   </gml:LinearRing>
                 </gml:exterior>
               </gml:Polygon>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 8

5.2.3.  Circle

   The circular area is used for coordinates in two-dimensional CRSs to
   describe uncertainty about a point.  The definition is based on the
   one-dimensional geometry in GML, gml:CircleByCenterPoint.  The centre
   point of a circular area is specified by using a two dimensional CRS;
   in three dimensions, the orientation of the circle cannot be
   specified correctly using this representation.  A point with
   uncertainty that is specified in three dimensions should use the
   Sphere shape type.









Winterbottom, et al.     Expires August 23, 2008               [Page 19]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:circle@example.com">
       <tuple id="circle">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
             <method>OTDOA</method>
           </gp:geopriv>
         </status>
       </tuple>
     </presence>

                                 Figure 9

5.2.4.  Ellipse

   An elliptical area describes an ellipse in two dimensional space.
   The ellipse is described by a center point, the length of its semi-
   major and semi-minor axes, and the orientation of the semi-major
   axis.  Like the circular area (Circle), the ellipse MUST be specified
   using the two dimensional CRS.


















Winterbottom, et al.     Expires August 23, 2008               [Page 20]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:Ellipse@somecell.example.com">
       <tuple id="ellipse">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512</gml:pos>
                 <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   1275
                 </gs:semiMajorAxis>
                 <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   670
                 </gs:semiMinorAxis>
                 <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                   43.2
                 </gs:orientation>
               </gs:Ellipse>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Device-Assisted_A-GPS</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 10

   The gml:pos element indicates the position of the center, or origin,
   of the ellipse.  The gs:semiMajorAxis and gs:semiMinorAxis elements
   are the length of the semi-major and semi-minor axes respectively.
   The gs:orientation element is the angle by which the semi-major axis
   is rotated from the first axis of the CRS towards the second axis.
   For WGS 84, the orientation indicates rotation from Northing to
   Easting, which, if specified in degrees, is roughly equivalent to a
   compass bearing (if magnetic north were the same as the WGS north
   pole).  Note: An ellipse with equal major and minor axis lengths is a
   circle.

5.2.5.  Arc Band

   The arc band shape type is commonly generated in wireless systems
   where timing advance or code offsets sequences are used to compensate



Winterbottom, et al.     Expires August 23, 2008               [Page 21]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


   for distances between handsets and the access point.  The arc band is
   represented as two radii emanating from a central point, and two
   angles which represent the starting angle and the opening angle of
   the arc.  In a cellular environment the central point is nominally
   the location of the cell tower, the two radii are determined by the
   extent of the timing advance, and the two angles are generally
   provisioned information.

   For example, Paul is using a cellular wireless device and is 7 timing
   advance symbols away from the cell tower.  For a GSM-based network
   this would place Paul roughly between 3,594 meters and 4,148 meters
   from the cell tower, providing the inner and outer radius values.  If
   the start angle is 20 degrees from north, and the opening angle is
   120 degrees, an arc band representing Paul's location would look
   similar to Figure 11.

         N ^        ,.__
           | a(s)  /     `-.
           | 20   /         `-.
           |--.  /             `.
           |   `/                \
           |   /__                \
           |  .   `-.              \
           | .       `.             \
           |. \        \             .
        ---c-- a(o) -- |             | -->
           |.  / 120   '             |   E
           |  .       /              '
           |    .    /              ;
                  .,'              /
               r(i)`.             /
            (3594m)  `.          /
                       `.      ,'
                         `.  ,'
                       r(o)`'
                     (4148m)

                                 Figure 11

   The resulting PIDF-LO is shown in Figure 12.











Winterbottom, et al.     Expires August 23, 2008               [Page 22]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:paul@somecell.example.com">
       <tuple id="arcband">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-43.5723 153.21760</gml:pos>
                 <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   3594
                 </gs:innerRadius>
                 <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   4148
                 </gs:outerRadius>
                 <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:startAngle>
                 <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:openingAngle>
               </gs:ArcBand>
             </gp:location-info>
             <gp:usage-rules/>
             <method>TA-NMR</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 12

   An important note to make on the arc band is that the center point
   used in the definition of the shape is not included in resulting
   enclosed area, and that Target may be anywhere in the defined area of
   the arc band.

5.2.6.  Sphere

   The sphere is a volume that provides the same information as a circle
   in three dimensions.  The sphere has to be specified using a three
   dimensional CRS.  Figure 13 shows the sphere shape, which is
   identical to the circle example, except for the addition of an
   altitude in the provided coordinates.



Winterbottom, et al.     Expires August 23, 2008               [Page 23]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:circle@example.com">
       <tuple id="sphere">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979">
                 <gml:pos>42.5463 -73.2512 26.3</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Sphere>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Device-Based_A-GPS</method>
           </gp:geopriv>
         </status>
       </tuple>
     </presence>

                                 Figure 13

5.2.7.  Ellipsoid

   The ellipsoid is the volume most commonly produced by GPS systems.
   It is used extensively in navigation systems and wireless location
   networks.  The ellipsoid is constructed around a central point
   specified in three dimensions, and three axies perpendicular to one
   another are extended outwards from this point.  These axies are
   defined as the semi-major (M) axis, the semi-minor (m) axis, and the
   vertical (v) axis respectively.  An angle is used to express the
   orientation of the ellipsoid.  The orientation angle is measured in
   degrees from north, and represents the direction of the semi-major
   axis from the center point.













Winterbottom, et al.     Expires August 23, 2008               [Page 24]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


                  \
                _.-\""""^"""""-._
              .'    \   |        `.
             /       v  m          \
            |         \ |           |
            |          -c ----M---->|
            |                       |
             \                     /
              `._               _.'
                 `-...........-'

                                 Figure 14

   A PIDF-LO containing an ellipsoid appears as shown in Figure 15.





































Winterbottom, et al.     Expires August 23, 2008               [Page 25]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:somone@gpsreceiver.example.com">
       <tuple id="ellipsoid">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">
                 <gml:pos>42.5463 -73.2512 26.3</gml:pos>
                 <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   7.7156
                 </gs:semiMajorAxis>
                 <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   3.31
                 </gs:semiMinorAxis>
                 <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
                   28.7
                 </gs:verticalAxis>
                 <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                   90
                 </gs:orientation>
               </gs:Ellipsoid>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Hybrid_A-GPS</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 15

5.2.8.  Prism

   A prism may be used to represent a section of a building or range of
   floors of building.  The prism extrudes a polygon by providing a
   height element.  It consists of a base made up of coplanar points
   defined in 3 dimensions all at the same altitude.  The prism is then
   an extrusion from this base to the value specified in the height
   element.  If the height is negative, then the prism is extruded from
   the top down, while a positive height extrudes from the bottom up.
   The first and last points of the polygon have to be the same.

   For example, looking at the cube in Figure 16.  If the prism is



Winterbottom, et al.     Expires August 23, 2008               [Page 26]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


   extruded from the bottom up, then the polygon forming the base of the
   prism is defined with the points A, B, C, D, A. The height of the
   prism is the distance between point A and point E in meters.

              G-----F
             /|    /|
            / |   / |
           H--+--E  |
           |  C--|--B
           | /   | /
           |/    |/
           D-----A

                                 Figure 16

   The resulting PIDF-LO is shown in Figure 17.



































Winterbottom, et al.     Expires August 23, 2008               [Page 27]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:mike@someprism.example.com">
       <tuple id="prism">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
                 <gs:base>
                   <gml:Polygon>
                     <gml:exterior>
                       <gml:LinearRing>
                         <gml:posList>
                           42.556844 -73.248157 36.6 <!--A-->
                           42.656844 -73.248157 36.6 <!--B-->
                           42.656844 -73.348157 36.6 <!--C-->
                           42.556844 -73.348157 36.6 <!--D-->
                           42.556844 -73.248157 36.6 <!--A-->
                         </gml:posList>
                       </gml:LinearRing>
                     </gml:exterior>
                   </gml:Polygon>
                 </gs:base>
                 <gs:height uom="urn:ogc:def:uom:EPSG::9001">
                   2.4
                 </gs:height>
               </gs:Prism>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                                 Figure 17











Winterbottom, et al.     Expires August 23, 2008               [Page 28]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


6.  Security Considerations

   The primary security considerations relate to how location
   information is conveyed and used, which are outside the scope of this
   document.  This document is intended to serve only as a set of
   guidelines as to which elements MUST or SHOULD be implemented by
   systems wishing to perform location dependent routing.  The
   ramification of such recommendations is that they extend to devices
   and clients that wish to make use of such services.










































Winterbottom, et al.     Expires August 23, 2008               [Page 29]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


7.  IANA Considerations

   This document does not introduce any IANA considerations.
















































Winterbottom, et al.     Expires August 23, 2008               [Page 30]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


8.  Acknowledgments

   The authors would like to thank the GEOPRIV working group for their
   discussions in the context of PIDF-LO, in particular Carl Reed, Ron
   Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall
   and Robert Sparks.  Furthermore, we would like to thank Jon Peterson
   as the author of PIDF-LO and Nadine Abbott for her constructive
   comments in clarifying some aspects of the document.

   Thanks to Karen Navas for pointing out some emissions in the
   examples.








































Winterbottom, et al.     Expires August 23, 2008               [Page 31]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


9.  References

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

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

   [GeoShape]
              Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
              Application Schema for use by the Internet Engineering
              Task Force (IETF)", Candidate OpenGIS Implementation
              Specification 06-142r1, Version: 1.0, April 2007.

   [I-D.ietf-geopriv-revised-civic-lo]
              Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for PIDF-LO",
              draft-ietf-geopriv-revised-civic-lo-07 (work in progress),
              December 2007.

9.2.  Informative References

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [3GPP-TS-23_032]
              "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
              Technical Specification Group Code Network; Universal
              Geographic Area Description (GAD)".













Winterbottom, et al.     Expires August 23, 2008               [Page 32]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


Authors' Addresses

   James Winterbottom
   Andrew Corporation
   Wollongong
   NSW Australia

   Email: james.winterbottom@andrew.com


   Martin Thomson
   Andrew Corporation
   Wollongong
   NSW Australia

   Email: martin.thomson@andrew.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com

























Winterbottom, et al.     Expires August 23, 2008               [Page 33]

Internet-Draft           GEOPRIV PIDF-LO Profile           February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Winterbottom, et al.     Expires August 23, 2008               [Page 34]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/