Geopriv WG James Polk Internet-Draft Allan Thomson Expires: September 4, 2009 Marc Linsner Intended Status: Standards Track (PS) Cisco Systems March 4, 2009 Dynamic Host Configuration Protocol (DHCP) Location Shapes Option for Geopriv for IPv4 and IPv6 draft-polk-geopriv-dhc-geoelement-shape-option-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 4, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your Polk, et al. Expires September 4, 2009 [Page 1] Internet-Draft DHCP Geoelement Shapes Option March 2009 rights and restrictions with respect to this document. Legal This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document defines the Dynamic Host Configuration Protocol (DHCP) Option for downloading a location shape to a client, from a server. This is commonly called Location Configuration Information (LCI). Servers that provide this information to a client are doing so by communicating via a Location Configuration Protocol, or LCP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Format of the DHCP Geoelement Shapes Option . . . . . . . . . 2.1 DHC Option for Shapes Option in IPv4 . . . . . . . . . . 2.2 DHC Option for Shapes Option in IPv6 . . . . . . . . . . 3. Geo-element Format for both IPv4 and IPv6 . . . . . . . . . . 3.1 The Geoelement Shape for a 2D/3D Point . . . . . . . . . 3.2 The Geoelement Shape for a 2D/3D Circle . . . . . . . . . 3.3 The Geoelement Shape for a 2D/3D Polygon . . . . . . . . 3.4 Additional Optional Geotypes . . . . . . . . . . . . . . 4. Versioning this Option . . . . . . . . . . . . . . . . . . . 5. Recommendations for Converting this Option into a PIDF-LO . . 6. Security considerations . . . . . . . . . . . . . . . . . . . 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9.1. Normative References . . . . . . . . . . . . . . . . . 9.2. Informative References . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 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 RFC 2119 [1]. Polk, et al. Expires September 4, 2009 [Page 2] Internet-Draft DHCP Geoelement Shapes Option March 2009 1. Introduction This document defines the Dynamic Host Configuration Protocol (DHCP) Option [RFC2131] for downloading a location shape to a client, from a server. This is commonly called Location Configuration Information (LCI). Servers that provide this information to a client are doing so by communicating via a Location Configuration Protocol, or LCP. The DHCP server is assumed to have determined the location from the Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt 1) in [RFC3046]. In order to translate the circuit (switch port identifier) into a location, the DHCP server is assumed to have access to a service that maps the from circuit-ID to the location at which the circuit connected to that port terminates in the building, for example, the location of the wall jack. Further, the local administrator can have the knowledge that a certain attachment point, for example, is connected to an IEEE 802.11 Access Point (AP). Understanding this about the attachment point allows certain location characteristics to be gleaned from this knowledge, such as, by itself, a wireless client can be within 100 meters of the location of the AP, therefore a precise location may not be possible, but informing the client it is within a 100 meter circle of a given point would be more appropriate. Another example would be if the local administrator has the ability to triangulate the location of the client, and lay this information onto a building map or grid, the local administrator can inform the client that it is in a particular room, instead of giving the client the exact coordinates for where it is at this time. This room would most likely best be presented in the form of a polygon (i.e., many sided and enclosed 2D or 3D container). This document creates 3 different location shapes, as follows, o a single point - articulated by X and Y coordinates; o a circle - which takes the point X and Y coordinates and extends a radius out from that spot; o a polygon - which is a number of x/y coordinate points - greater than 2 - that make up what OpenGIS defines as a Linear Ring Ring [OpenGIS]. The use of the term "point" has been changed in GML from the version 3.0 specification to the 3.1 specification [OpenGIS]. A point (GML3.0) became a "position" (GML3.1). For the remainder of this document, we do not distinguish between the two terms. A reader of this document needs to consider these two terms interchangeable here. Polk, et al. Expires September 4, 2009 [Page 3] Internet-Draft DHCP Geoelement Shapes Option March 2009 In both GML3.0 and GML3.1 (and more recently GML3.2) - a point or position is contained within the feature.xsd schema, which relates directly to what the Presence Information Data Format - Location Object (PIDF-LO), defined in RFC 4119 [RFC4119], mandates support of, but that is all RFC 4119 requires support of as far as GML schemas are concerned. A circle is not defined within the feature.xsd schema, but rather the geometryPrimitives.xsd schema in GML 3.1.1. If this Option were used by implementers to place location information in a PIDF-LO, additional support for the geometryPrimitives.xsd schema in GML 3.1.1 is necessary. Section 6 of this document is dedicated to give guidance to implementers for just such a conversion from this DHCP Option to a PIDF-LO. A polygon is also not defined within the feature.xsd schema, and is also defined in the geometryPrimitives.xsd schema in GML 3.1.1. Therefore, just as converting a circle from this Option into a PIDF-LO requires the geometryPrimitives.xsd schema, so too does a polygon representation in a PIDF-LO. Additional location shapes can be defined by extending this Specification, and can require the geometryPrimitives.xsd schema be implemented, or another GML schema. This Option has limited applicability to certain environments, such as cellular networks. One shape defined in this document overlaps with [RFC3825], which includes a mechanism for transporting a geo point. In support of backward compatibility, this document leaves [RFC3825] alone. Implementers will have the choice to use this new option or continue to support [RFC3825]. By leaving [RFC3825] alone, implementations based on [RFC3825] will not be affected by this new option. 2. Format of the DHCP Geoelement Shapes Option 2.1 Overall Format of Shapes Option in IPv4 This section defines this DHCP Option for use in IPv4. The first 4 bytes of this Option has the same format, regardless of the shape contained in the Option. The fields that follow are where the Option deviates based on the type of location shape being expressed (i.e., a point, a circle or a polygon). Figure 1, below, shows the first 4 bytes of each shape for IPv4. Each field is defined below Figure 1 for any shape of this Option. The 4-bit shape field in this Option will be detailed in section 3, describing each of the 3 shapes introduced by this document. Polk, et al. Expires September 4, 2009 [Page 4] Internet-Draft DHCP Geoelement Shapes Option March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code XXX | Length=XX | Ver | Shape | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Geoelements... ... . (see section 3 for details) ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. IPv4 Fields for this Geo-element Option Code XXX: The code for this DHCPv4 option (IANA assigned). Length=XX: The length of this option, counted in bytes - not counting the Code and Length bytes. This is a variable length Option, therefore the length value will change based on the shape within the Option. Ver: (4 bits) The version of this Option. This will specify version 1. Shape: (4 bits) The Format of this location. This value determines how the rest of the Option is processed (i.e. what are the expected fields based on the rules for each shape) Initially defined in this document are shapes for a point, a circle and a polygon. This is an extensible field for additional shapes. Reserved: (8 bits) reserved for future use. Geoelements: see section 3 for details The above defined v4 fields are all enumerated. [Editor's Note: we're open to including a 4-bit "what" field (in the manner in which it is used in RFC 4776); but want to get feedback from the WG on this prior to including it.] 2.2 Overall Format of Shapes Option in IPv6 The LCI format for IPv6 is as follows: Polk, et al. Expires September 4, 2009 [Page 5] Internet-Draft DHCP Geoelement Shapes Option March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Shape | Reserved | . +-------------------------------+ . . Geo-elements... . . (see section 3 for details) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. IPv6 fields of this Geo-element Option option-code: The code for this DHCPv6 option (IANA assigned). option-len: The length of this option, counted in bytes - not counting the Code and Length bytes. This is a variable length Option, therefore the length value will change based on the shape within the Option. Ver: See above (Section 2.1). This will specify version 1. Shape: See above (Section 2.1). Reserved: See above (Section 2.1). Geoelements: see below (Section 3 for details). The above defined v6 fields are all enumerated. [Editor's Note: we're open to including a 4-bit "what" field (in the manner in which it is used in RFC 4776); but want to get feedback from the WG on this prior to including it.] 3. Geo-element Format for both IPv4 and IPv6 The Geo-elements, in both DHCPv4 and DHCPv6, have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geotype | Geolength | Geovalue ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Geo-element Format for both IPv4 and IPv6 Geotype: A one-byte identifier of the data location value. Polk, et al. Expires September 4, 2009 [Page 6] Internet-Draft DHCP Geoelement Shapes Option March 2009 Geolength: The length, in bytes, of the Geovalue, not including the Geolength field itself, up to a maximum of 255 bytes. Geovalue: The location shape value, as described in detail below. The Geovalue is always in UTP-8. The Geotypes this document defines (and IANA registers) for a point are: Geotype=1 X-coordinate - this necessitates there be a Latitude Geovalue present. Geotype=2 Y-coordinate - this necessitates there be a Longitude Geovalue present. Geotype=3 Z-coordinate - this necessitates there be an Altitude Geovalue present. Geotype=4 Unit of Measurement Altitude (UofMA) - this necessitates there be an Altitude unit of measurement Geovalue present. The first byte of the Geovalue for Geotypes =1 and =2 MUST be a plus '+' or minus '-' sign byte, indicating: For Geotype=1 - whether the latitude is positive (above the equator) or negative (below the equator). For Geotype=2 - whether the longitude is positive (East of the prime meridian of the datum used) or negative (West of the prime meridian of the datum used). This document defines (and IANA registers) 2 Altitude units of measurement (Geotype=4). Geotype=4, Geovalue=1 - meters above or below the datum 0 plane. Geotype=4, Geovalue=2 - building floor. When Geotype=4 (UofMA) has a Geovalue=2 (building floor), the Geovalue for Geotype=3 (Z-coordinate) is alpha characters, meaning there is no need to include a plus '+' or minus '-' sign byte (more on this below table 2). When Geotype=4 (UofMA) has a Geovalue=1 (meters), first byte of the Geovalue=3 MUST be a plus '+' or minus '-' sign byte, indicating: For Geotype=3 - whether the altitude Geovalue is positive (above datum 0) or negative (below datum 0). Polk, et al. Expires September 4, 2009 [Page 7] Internet-Draft DHCP Geoelement Shapes Option March 2009 +---------+----------------------------------+---------+ | Geotype | Geoelement | PIDF-LO | +---------+----------------------------------+---------+ | 1 | X-Coordinate (Latitude) | Sec 5.1 | | | | | | 2 | Y-Coordinate (Longitude) | Sec 5.1 | | | | | | 3 | Z-Coordinate (Altitude) | Sec 5.1 | | | | | | 4 | Unit of Measurement Altitude * | Sec 5.2 | +---------+----------------------------------+---------+ Table 1. Geotypes for a Basic 3D Point * For Geotype=4 (Unit of Measurement Altitude), the following table applies: +---------+--------------------------------------------------------+ | Geotype | Geovalue | Description | +---------+--------------------------------------------------------+ | 4 | 1 | meters above or below the datum 0 plane | | | | | | 4 | 2 | building floor | +---------+--------------------------------------------------------+ Table 2. Unit of Measurement for the Altitude value The Unit of Measurement Altitude (UofMA) field in this Option will define what is considered the 3-Dimensional 0 (zero) altitude. For example, it could be the ground, Mean-lowest-Low-tide or Mean-Tide level at a given X/Y coordinate. The 'floor', Geovalue=2, SHOULD match the locally significant description for identifying floors in a multi-floor building. Values for this option would include '1' or '2' and could include 'basement' or 'mezzanine' or any other floor identifier determined by local administration. For example, for a Geotype=4 (UofMA), the Geovalue in Geotype=3 (Z-Coordinate) would be 'basement' or 'mezzanine', either spelled out. For any point, there MUST be a Geotype=1 (X-coordinate) and Geotype=2 (Y-coordinate) present. Geotype=3 (Z-coordinate) and Geotype=4 (UofMA) MUST be implemented to comply with this specification, but are OPTIONAL to use for any given communication. That said, if there is an altitude provide (Geotype=3), there MUST be a (Geotype=4) present as well. If the DHCP Option size becomes an issue (i.e., longer than 255 Polk, et al. Expires September 4, 2009 [Page 8] Internet-Draft DHCP Geoelement Shapes Option March 2009 bytes), it is allowed to use the long Options capability created in RFC 3396 [RFC3396] to solve for this. New Geotypes and Geovalues MUST be defined in an RFC, following expert review. 3.1 The Geoelement Shape for a 2D/3D Point The elements defined in Section 3 define how to communicate a point (shape=1). These additional rules need to be followed for a point: o There MUST NOT be more than one Geotype=3 (Z-coordinate) or more than one Geotype=4 (UofMA) within this Option when shape=1. o These are the Geotypes that MUST be present for a 2D point within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o These are the Geotypes that MUST NOT be present for a 2D point within this Option: o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o Geotype=5 (Radius) o Geotype=6 (# of Points) o Geotype=7 (Centerpoint X-Coordinate (Lat)) o Geotype=8 (Centerpoint Y-Coordinate (Long)) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) All other Geotypes are OPTIONAL, but MAY change in future extension(s) to this document. o These are the Geotypes that MUST be present for a 3D point within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o These are the Geotypes that MUST NOT be present for a 3D point within this Option: o Geotype=5 (Radius) o Geotype=6 (# of Points) o Geotype=7 (Centerpoint X-Coordinate (Lat)) Polk, et al. Expires September 4, 2009 [Page 9] Internet-Draft DHCP Geoelement Shapes Option March 2009 o Geotype=8 (Centerpoint Y-Coordinate (Long)) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL, but MAY change in future extension(s) to this document. 3.2 The Geoelement Shape for a 2D/3D Circle The elements defined in section 3.1 define how to communicate a point (shape=1). The additional element needed to communicate a circle (shape=2) is a radius Geotype. The a unit of measurement of for the radius (UofMR) is always meters, therefore, there does not need to be a separate value for this - having only one to choose from. Geotype=5 Radius - the straight line from the point at the center of the circle, extending out a given distance (this is the Geovalue of the Radius Geotype). +---------+----------------------------------+---------+ | Geotype | Geoelement | PIDF-LO | +---------+----------------------------------+---------+ | 5 | Radius | Sec 5.3 | +---------+----------------------------------+---------+ Table 3. Required Radius Geoelement Information When the Option communicates a circle (shape=2), the following Geotype MUST be present in the Option: Geotype=1 (the X-coordinate representing the center of the circle) Geotype=2 (the Y-coordinate representing the center of the circle) Geotype=5 (the Radius value from the center X/Y point of the circle) An altitude (Geotypes 3 & 4) coordinate is OPTIONAL, but both Geotypes MUST appear in the Option if either appears for shape=2 (a circle). Geotypes=7 through =10, which detail a Centerpoint (see Section 3.3 below) MUST NOT appear in a shape=2 (circle) Option. There is already an implicit centerpoint of the circle, and that is the one X/Y point in the Option. The following additional rules need to be followed for a circle: o There MUST NOT be more than one Geotype=3 (Z-coordinate) or Polk, et al. Expires September 4, 2009 [Page 10] Internet-Draft DHCP Geoelement Shapes Option March 2009 more than one Geotype=4 (UofMA) within this Option when shape=2. o These are the Geotypes that MUST be present for a 2D circle within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o Geotype=5 (Radius) o These are the Geotypes that MUST NOT be present for a 2D circle within this Option: o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o Geotype=6 (# of Points) o Geotype=7 (Centerpoint X-Coordinate (Lat)) o Geotype=8 (Centerpoint Y-Coordinate (Long)) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) All other Geotypes are OPTIONAL, but MAY change in future extension(s) to this document. o These are the Geotypes that MUST be present for a 3D circle within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o Geotype=5 (Radius) o These are the Geotypes that MUST NOT be present for a 3D circle within this Option: o Geotype=6 (# of Points) o Geotype=7 (Centerpoint X-Coordinate (Lat)) o Geotype=8 (Centerpoint Y-Coordinate (Long)) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL, but MAY change in future extension(s) to this document. 3.3 The Geoelement Shape for a 2D/3D Polygon The elements defined in this section define how to communicate a polygon (shape=3). A polygon is a series of X/Y coordinate points, or X/Y/Z coordinate groupings. There MUST be at least 4 points to shape a polygon (which would result in a triangle), to be consistent Polk, et al. Expires September 4, 2009 [Page 11] Internet-Draft DHCP Geoelement Shapes Option March 2009 with the GML 3.1 specification [OpenGIS]. A minimum of 4 Points make up a polygon in GML because the first and last point in a polygon are the same, i.e., the first point is repeated to indicate the representation has completed (or circled). There can be more points included in the polygon. There is one additional Geo-element that MUST be present in shape=3 (polygon) of this Option, and that is an indication of the number of points in the polygon. Geotypes=1 and =2 create an X/Y point. Geotype=6 # of Points - each point, in 2D, is a point of X and Y coordinates. If a 3rd dimension exists for a point, Geotype=3 (the Z-coordinate) is added to Geotype=1 and =2. +---------+----------------------------------+---------+ | Geotype | Geoelement | PIDF-LO | +---------+----------------------------------+---------+ | 6 | # of Points | N/A | +---------+----------------------------------+---------+ Table 4. Required Number of Points within "this" Polygon For shape=3 (polygon), the Geotype=6 MUST be the first element in the Option -- as this will indicate how many points (respectively) there are in the Option; thus giving the remaining length of the Option from a number of Geo-elements point of view. When this Option indicates it contains a polygon (shape=3), coordinate points or 3D combinations (X, Y and Z coordinates describing a 3D point) MUST have a specific order or grouping of Geotype elements. The order is this: For 2D points, this Option MUST have this point order: Geotype=6, Geotype=1, Geotype=2, Geotype=1, Geotype=2, Geotype=1, Geotype=2, etc... for however many coordinate points are in the polygon. In other words, the "# of Points" indicator is indicated first, followed by at least 3 sets of points: (# of Points), (x/y), (x/y), (x/y) (more if there are more 2D points in the polygon) For 3D Points, this Option MUST have this point order: Geotype=6, Geotype=1, Geotype=2, Geotype=3, Geotype=4, Geotype=1, Geotype=2, etc ... Polk, et al. Expires September 4, 2009 [Page 12] Internet-Draft DHCP Geoelement Shapes Option March 2009 for however many coordinate points are in the polygon. In other words, the "# of Points" is indicated first, followed by at least 3 sets of points: (# of Points), (x/y/z), (x/y/z), (x/y/z) (more if there are more 3D points in the polygon) This Option does not repeat the first and last points as GML mandates for a Linear Ring representation of a polygon in XML. That function is part of the conversion from this Option to a PIDF-LO, which is described in section 5 of this document. Thus, is not part of DHCP operation/communication. Any polygon can contain an OPTIONAL Centerpoint Geo-element, which is identified by the following Geotypes: Geotype=7 Polygon Centerpoint X-Coordinate - server calculated center point X-Coordinate within a supplied polygon. Geotype=8 Polygon Centerpoint Y-Coordinate - server calculated center point X-Coordinate within a supplied polygon. Geotype=9 Polygon Centerpoint Z-Coordinate - server calculated center point X-Coordinate within a supplied polygon. Geotype=10 Polygon Centerpoint Unit of Measurement Altitude - this is the same as the (UofMA) for Geotype=4 (from section 3.1). The DHCP server, or an application on another server, calculates this point (in 2D or 3D), and provides this via this Option to the client. The client does not perform this calculation or formatting of this centerpoint information other than to pass it on whenever it wants. The Location Recipient MUST NOT assume the Location Target is at the centerpoint. This information can be used by applications - making it valuable in some situations. Geotypes=7 through =10 MUST NOT appear in a shape=2 (circle) Option. There is already an implicit centerpoint of the circle, and that is the one X/Y(/Z) point provided to the client in the Option. +---------+----------------------------------+---------+ | Geotype | Geoelement | PIDF-LO | +---------+----------------------------------+---------+ | | | | | 7 | Centerpoint X-Coordinate (Lat) | Sec 5.5 | | | | | | 8 | Centerpoint Y-Coordinate (Long) | Sec 5.5 | | | | | | 9 | Centerpoint Z-Coordinate (Alt) | Sec 5.5 | | | | | Polk, et al. Expires September 4, 2009 [Page 13] Internet-Draft DHCP Geoelement Shapes Option March 2009 | 10 | Centerpoint Unit of Measurement | Sec 5.6 | | | Altitude | | +---------+----------------------------------+---------+ Table 5. Centerpoint Geotypes If there is a centerpoint contained in the Option (of a polygon), it has its own order of Geotypes, which is as follows: Geotype=7, Geotype=8, Geotype=9, Geotype=10 There are no additional Geotypes involved with centerpoint. So this looks like the following: center-x, center-y (and optionally) center-z, center-UofMA This order above MUST NOT be altered, and MUST be the last 2D or 3D point of (shape=3) polygon Geo-elements. It is its own separate point. There MUST NOT be more than 1 altitude Geotype within this Option, unless each coordinate point in the polygon is a 3D point. In other words, if there is an altitude (Geotype=3) -- the rule is every point is in 3D, or only one of them is in 3D. If none of points are in 3D, then the centerpoint can have the only altitude (Geotype=3). If one of the polygon points is in 3D, the centerpoint MUST NOT have an altitude (Geotype=3). It is RECOMMENDED that if there is a centerpoint within this Option, the centerpoint is the one point that includes the altitude for the Option. [EDITOR'S NOTE: do we want to allow both 2D & 3D points in the same polygon? Right now, the answer is "not allowed" - because this would make everything much more complicated.] The following additional rules need to be followed for a polygon: o There MUST NOT be more than one Geotype=3 (Z-coordinate) or more than one Geotype=4 (UofMA) within this Option when shape=3. o If the Centerpoint does not include altitude (Geotype=3), or if there is no Centerpoint, and one point of a polygon is defined as 3D - it is REQUIRED (with one exception) the remaining points are defined as 2D, it is assumed the remaining points are at the same altitude as the point that has the altitude (Geotype=3) for that Option. The exception to the above rule is when all points include altitude Polk, et al. Expires September 4, 2009 [Page 14] Internet-Draft DHCP Geoelement Shapes Option March 2009 (Geotype=3). In other words, it is an 'only one has it (altitude), or they all have it' rule. o These are the Geotypes that MUST be present for a 2D polygon within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o Geotype=6 (# of Points) The shape=3 (polygon) Option MUST contain at least 3 points to be a Polygon in this Option (conversion from this Option to a PIDF-LO is done by the client, and is described in section 5 of this document). See earlier in this section for the order rules around more than one Geotype=1 and =2 (and the centerpoint, if present). o These are the Geotypes that are OPTIONAL for a 2D polygon within this Option: o Geotype=7 (Centerpoint X-Coordinate (Lat)) o Geotype=8 (Centerpoint Y-Coordinate (Long)) o These are the Geotypes that MUST NOT be present for a 2D polygon within this Option: o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o Geotype=5 (Radius) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) All other Geotypes are OPTIONAL, but MAY change in future extension(s) to this document. o These are the Geotypes that MUST be present for a 3D polygon within this Option: o Geotype=1 (X-Coordinate (Latitude)) o Geotype=2 (Y-Coordinate (Longitude)) o Geotype=6 (# of Points) plus either of these two sets: o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) or o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) Each UofMA Geotype (=4 and =10) MUST be the same Geovalue, Polk, et al. Expires September 4, 2009 [Page 15] Internet-Draft DHCP Geoelement Shapes Option March 2009 regardless of how many altitudes are in the Option for shape=3 (polygon). Geotype=9 and =10 MUST NOT be present without the corresponding Geotypes=7 and =8. To reduce complexity, it is RECOMMENDED that all altitudes - when all points are in 3D - be the same value (i.e., parallel to the ground). The shape=3 (polygon) Option MUST contain at least 3 points to be a polygon. See earlier in this section for the order rules around more than one Geotype=1, =2 and =3 point set. o These are the Geotypes that are OPTIONAL for a 2D polygon within this Option: o Geotype=3 (Z-Coordinate (Altitude)) o Geotype=4 (Unit of Measurement Altitude) o Geotype=7 (Centerpoint X-Coordinate (Lat)) o Geotype=8 (Centerpoint Y-Coordinate (Long)) o Geotype=9 (Centerpoint Z-Coordinate (Alt)) o Geotype=10 (Centerpoint Unit of Measurement Altitude) o This Geotype MUST NOT be present for a 3D polygon within this Option: o Geotype=5 (Radius) Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL in either a 2D or 3D polygon, but MAY change in future extension(s) to this document. 3.4 Additional Optional Geotypes The following Geotypes are OPTIONAL: Geotype=11 Datum - the base line of reference from which measurements are taken out from (here both horizontally and vertically). When not present, WGS84 2D or 3D (EPSG 4326 and 4979 respectively) MUST be assumed. This Geotype indicates another Datum is assigned to all coordinate Geotypes in Option (meaning each X-coordinate, Y-coordinate, Z-coordinate, including Centerpoint coordinates). The WGS84 datum can be made explicit, but including this Geotype=11, Geovalue=1; two other datum combinations are included here. This document establishes the following alternate (to WGS84) datums: Polk, et al. Expires September 4, 2009 [Page 16] Internet-Draft DHCP Geoelement Shapes Option March 2009 Datum = 1 denotes WGS84 (EPSG4326) for 2D, and (EPSG4979) for 3D (depending on whether an altitude Geotype is present). Datum = 2 denotes the horizontal datum NAD83 as defined by the EPSG as their CRS Code 4269; North American Vertical Datum of 1988 (NAVD88) is the associated vertical datum for NAD83 Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as their CRS Code 4269; Mean Lower Low Water (MLLW) is the associated vertical datum for NAD83 Each of the above is IANA registered. Geotype=12 Valid-for - measured in seconds the location within this Option is to be considered good, before needing a refresh, which maps to PIDF. If Valid-for is not present, the Geoelement shape Option is valid until the whole Option lease has expired. This timer MUST start when the Option is received by the Client. +---------+----------------------------------+---------+ | Geotype | Geoelement | PIDF-LO | +---------+----------------------------------+---------+ | | | | | 11 | Datum | Sec 5.7 | | | | | | 12 | Valid-for | Sec 5.8 | +---------+----------------------------------+---------+ Table 6. List of Additional non-grouped Geotypes Geotypes 14 - 255 are reserved. NOTE: the authors are open to including both the Confidence and/or Uncertainty Geotypes if the WG can reasonably provide valid use-cases, as well as industry accepted definitions. Currently, the US Federal Communications Commission (FCC), as one source, is ambiguous about either of these fields, including lacking a good definition for either. 4. Versioning this Option It is RECOMMENDED that new shapes (until this Option exceeds 16) not necessitate a new version of this Option. A new version SHOULD only be necessary if one of the shapes requires a change in the format of the fields within the Option. If one or more shapes need altering, the remaining shapes SHOULD carry forward into the new version of this Option. This ensures backwards compatibility with as large an Polk, et al. Expires September 4, 2009 [Page 17] Internet-Draft DHCP Geoelement Shapes Option March 2009 installed base as possible. 5. Recommendations for Converting this Option into a PIDF-LO The following table is how this DHCP Geoelement shapes Option maps into a PIDF-LO. Currently, not every Geoelement maps properly into the PIDF-LO. Those mappings are for another effort. 5.1 X-, Y- and Z-Coordinate placement in the PIDF-LO The following 2D XML element is where the X-, Y-coordinates go into the PIDF-LO: 32 -86 The following 3D XML element is where the X-, Y-, Z-coordinates go into the PIDF-LO: 32 -86 10 5.2 Unit of Measurement Altitude (UofMA) in the PIDF-LO GML expects altitude (Geotype=3) to be in meters only. This is not possible today because the need express altitude in floors. This results in the following ways of expressing the Z-coordinate (altitude): - if Z-coordinate (Geotype=3) is given in floors (Geotype=4, Geovalue=3), the client determines that the PIDF-LO needs place the altitude value into the element. - if Z-coordinate (Geotype=3) is given in meters (Geotype=4, Geovalue=1), the client has two options: Choice#1 - placing the altitude value into the same element that Lat and Long go; Choice#2 - shown this way Polk, et al. Expires September 4, 2009 [Page 18] Internet-Draft DHCP Geoelement Shapes Option March 2009 15 [Editor's Note: if this solution is chosen, then one of the two Choices above for altitude placement needs to be mandatory to implement, with the other being optional.] 5.3 A Circle expressed within the PIDF-LO The Shape=2 part of this DHCP Option is shown at the beginning of the XML as . The schema for a circle is defined in [GeoShape]. The following is where Geotype=5 fits into the PIDF-LO, as described in the GML3.1 specification here [OpenGIS]: 32.51 -86.51 33 5.4 A Polygon placement within a PIDF-LO The Shape=3 part of this DHCP Option is shown at the beginning of the XML as . As stated earlier, a polygon has to have at least 4 linear ring points within it. Also stated earlier, if there is a 3rd dimension, there can only be one altitude value, or every point has to have the same altitude value. This is to reduce complexity. The XML for a circle is defined in [GeoShape]. Polk, et al. Expires September 4, 2009 [Page 19] Internet-Draft DHCP Geoelement Shapes Option March 2009 32.51 -86.51 32.56 -86.56 32.56 -86.61 32.51 -86.66 32.46 -86.61 32.46 -86.56 32.51 -86.51 5.5 Centerpoint X-, Y- and Z-Coordinate placement in the PIDF-LO TBD GML does not specify XML for a centerpoint of a polygon. 5.6 Centerpoint Unit of Measurement Altitude (CUofMA) placement in the PIDF-LO TBD GML does not specify XML for a centerpoint of a polygon. 5.7 Datum placement in the PIDF-LO At issue here is that GML specifically assumes WGS84 2D or 3D to be the datum, therefore a datum element is not present for the PIDF-LO. For points, circles and polygons using the WGS84 datum, each accomplishes this identification with the use of srsName="urn:ogc:def:crs:EPSG::4326" for 2D representations, and srsName="urn:ogc:def:crs:EPSG::4979" for 3D representations. Unfortunately, WGS84 is a goal for many (all?) systems; one in which some have not achieved yet. Some systems believe it might be decades before they are converted over to the WGS84 datum. Polk, et al. Expires September 4, 2009 [Page 20] Internet-Draft DHCP Geoelement Shapes Option March 2009 For a 2D or 3D non-WGS84 datum, this is the XML schema from [OpenGIS]: For 1D Vertical only coordinate reference system utilized for heights and depths, where WGS84 2D is used horizontally, the following schema from [OpenGIS] is this: 5.8 Valid-for placement in the PIDF-LO TBD (this is likely part of the PIDF specification) 6. Security considerations There are no additional security considerations in addition to those contained within RFC 4776. 7. IANA considerations This IANA registers the following fields introduced by this Option. Polk, et al. Expires September 4, 2009 [Page 21] Internet-Draft DHCP Geoelement Shapes Option March 2009 7.1 The IPv4 Option number for this Option This document IANA registers this IPv4 Option number XXX (to be assigned by IANA once this document becomes an RFC). 7.2 The IPv6 Option-Code for this Option This document IANA registers this IPv6 Option-Code XXX (to be assigned by IANA once this document becomes an RFC). 7.3 The Version number for this Option This document IANA registers the version number 1 of this Option. 7.4 The Shape Designation for this Option This document IANA registers the following shapes for this Option +---------+--------------------------------------------------+ | Shape | Description | +---------+--------------------------------------------------+ | 1 | a 2D or 3D point | | | | | 2 | a 2D or 3D circle | | | | | 3 | a 2D or 3D polygon, optionally with a centerpoint| | | | +---------+--------------------------------------------------+ Additions, modifications or deletions to the above table require expert review, followed by a published RFC. 7.5 The Geotypes for this Option This document IANA registers the following Geotypes for use with this Option: +---------+--------------------------------------------+-----------+ | Geotype | Geoelement | Reference | +---------+--------------------------------------------+-----------+ | 1 | X-Coordinate (Latitude) | RFC XXXX* | | | | | | 2 | Y-Coordinate (Longitude) | RFC XXXX* | | | | | | 3 | Z-Coordinate (Altitude) | RFC XXXX* | | | | | | 4 | Unit of Measurement Altitude ** | RFC XXXX* | Polk, et al. Expires September 4, 2009 [Page 22] Internet-Draft DHCP Geoelement Shapes Option March 2009 | | | | | 5 | Radius | RFC XXXX* | | | | | | 6 | # of Points | RFC XXXX* | | | | | | 7 | Centerpoint X-Coordinate (Lat) | RFC XXXX* | | | | | | 8 | Centerpoint Y-Coordinate (Long) | RFC XXXX* | | | | | | 9 | Centerpoint Z-Coordinate (Alt) | RFC XXXX* | | | | | | 10 | Centerpoint Unit of Measurement | RFC XXXX* | | | Altitude ** | | | | | | | 11 | Datum | RFC XXXX* | | | | | | 12 | Valid-for | RFC XXXX* | +---------+--------------------------------------------+-----------+ * RFC-Editor -- where "RFC XXXX" appears, please replace this string with the RFC number assigned to this document, if and when it is published as an RFC. ** Both Units of Measurement for Altitude are IANA registered in section 6.2. Geotypes 14 - 255 are reserved for future assignment. Additions, modifications or deletions to the above table require expert review, followed by a published RFC. 7.6 The Unit of Measurement for Altitude This document IANA registers the following Unit of Measurement for Altitude. For Geotype=4 (UofMA) and Geotype=10 (Centerpoint UofMA), the following IANA registrations are necessary, and identical for either Geotype: +---------+----------+---------------------------------------------+ | Geotype | Geovalue | Description | +---------+----------+---------------------------------------------+ | 4 | 1 | meters above or below the datum 0 plane | | | | | | 4 | 2 | floors - defined by local administration | | | | | +---------+----------+---------------------------------------------+ Additions, modifications or deletions to the above table require expert review, followed by a published RFC. Polk, et al. Expires September 4, 2009 [Page 23] Internet-Draft DHCP Geoelement Shapes Option March 2009 7.7 Datums Registered by this Document This document IANA registers the following Datums to be used by the Geotype=11 (Datum). If no Geotype=11 is present in this Option, it the default datum will be either EPSG-4326 for 2D, and EPSG-4979 for 3D. Datum = 1 denotes WGS84 (EPSG4326) for 2D, and (EPSG4979) for 3D (depending on whether an altitude Geotype is present). Datum = 2 denotes the horizontal datum NAD83 as defined by the EPSG as their CRS Code 4269; North American Vertical Datum of 1988 (NAVD88) is the associated vertical datum for NAD83 Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as their CRS Code 4269; Mean Lower Low Water (MLLW) is the associated vertical datum for NAD83 8. Acknowledgments Your name here... 9. References 9.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [OpenGIS] - http://www.opengeospatial.org/standards/gml [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [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 Polk, et al. Expires September 4, 2009 [Page 24] Internet-Draft DHCP Geoelement Shapes Option March 2009 Specification 06-142, Version: 0.0.9, December 2006. 9.2 Informative References There are no Informational references at this time Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Allan Thomson Cisco Systems, Inc. San Jose, California, USA Email: althomso@cisco.com Marc Linsner Cisco Systems, Inc. Marco Island, Florida, USA Email: mlinsner@cisco.com Polk, et al. Expires September 4, 2009 [Page 25]