idnits 2.17.00 (12 Aug 2021) /tmp/idnits19192/draft-ietf-geopriv-relative-location-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 3855 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE754' is mentioned on line 348, but not defined == Missing Reference: 'WGS84' is mentioned on line 391, but not defined == Unused Reference: 'RFC3986' is defined on line 1507, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-geopriv-local-civic has been published as RFC 6848 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clinger1990' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Andrew Corporation 4 Intended status: Standards Track B. Rosen 5 Expires: May 3, 2012 Neustar 6 D. Stanley 7 Aruba Networks 8 G. Bajko 9 Nokia 10 A. Thomson 11 Cisco Systems, Inc. 12 October 31, 2011 14 Relative Location Representation 15 draft-ietf-geopriv-relative-location-02 17 Abstract 19 This document defines an extension to PIDF-LO (RFC4119) for the 20 expression of location information that is defined relative to a 21 reference point. The reference point may be expressed as a geodetic 22 or civic location, and the relative offset may be one of several 23 shapes. Optionally, a reference to a secondary document (such as a 24 map image) can be included, along with the relationship of the map 25 coordinate system to the reference/offset coordinate system to allow 26 display of the map with the reference point and the relative offset. 27 Also included in this document is a Type/Length/Value (TLV) 28 representation of the relative location for use in other protocols 29 that use TLVs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 3, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions used in this document . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Relative Coordinate System . . . . . . . . . . . . . . . . 7 69 4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7 70 4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8 71 4.4. Distances and Angles . . . . . . . . . . . . . . . . . . . 8 72 4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . . 9 73 4.6. Relative Location Restrictions . . . . . . . . . . . . . . 9 74 4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9 75 4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9 76 4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . . 11 79 4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . 12 80 4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . . 14 81 4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . . 17 82 4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18 83 4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . . 19 84 4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . . 19 85 4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . . 19 87 4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . . 20 88 4.11.2. Map Coordinate Reference System . . . . . . . . . . . 20 89 4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . . 22 90 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 23 92 5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 24 93 5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 26 94 6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 26 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 97 8.1. Relative Location Registry . . . . . . . . . . . . . . . . 29 98 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 30 99 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 31 100 8.4. CRS public identifier registration . . . . . . . . . . . . 31 101 8.5. CAtype Registration . . . . . . . . . . . . . . . . . . . 33 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 105 10.2. Informative References . . . . . . . . . . . . . . . . . . 35 107 1. Introduction 109 This document describes a format for the expression of relative 110 location information. 112 A relative location is formed of a reference location, plus a 113 relative offset from that reference location. The reference location 114 can be represented in either civic or geodetic form. The reference 115 location can also have dynamic components such as velocity. The 116 relative offset is specified in meters using a Cartesian coordinate 117 system. 119 In addition to the relative location, an optional URI can be provided 120 to a document that contains a map, floorplan or illustration. 121 Applications could use this information to display the relative 122 location. Additional fields allow the map to be oriented and scaled 123 correctly. 125 Two formats are included: an XML form that is intended for use in 126 PIDF-LO [RFC4119] and a TLV format for use in other protocols such as 127 those that already convey binary representation of location 128 information defined in [RFC4776]. 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Overview 138 This document describes an extension to PIDF-LO [RFC4119] as updated 139 by [RFC5139] and [RFC5491], to allow the expression of a location as 140 an offset relative to a reference. 142 This extension effectively allows the creator of a location object to 143 include two location values plus an offset. The "baseline" location 144 that is given outside of the element is what will 145 be visible to a client that does not understand that extension (i.e., 146 one that ignores the element). A client that 147 does understand this extension will interpret the location within the 148 relative element as a refinement of the baseline location, which 149 gives the reference location for the relative offset. 151 Creators of location objects with relative location thus have a 152 choice of how much information to put into the "baseline" location 153 and how much to put into the "reference" location. For example, all 154 location information could be put inside the 155 element, so that clients that do not understand relative location 156 would receive no location information at all. Alternatively, the 157 baseline location value could be precise enough to specify a building 158 that contains the relative location, and the reference location could 159 specify a point within the building from which the offset is 160 measured. 162 The baseline location SHOULD be general enough to describe both the 163 reference location and the relative location (reference plus offset). 164 In particular, while it is possible to put all location information 165 into the "reference" location (leaving an universally broad 166 "baseline"), location objects SHOULD NOT have all location 167 information in the baseline location. Doing this would cause clients 168 that do not understand relative location to incorrectly interpret the 169 baseline location (i.e., the reference point) as the actual, precise 170 location of the client. 172 Both the baseline and the reference location are defined either as a 173 geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If 174 the baseline location was expressed as a geodetic location, the 175 reference MUST be geodetic. If the baseline location was expressed 176 as a civic address, the reference MUST be a civic. 178 Baseline and reference locations MAY also include dynamic location 179 information [RFC5962]. 181 The relative location can be expressed using a point (2- or 182 3-dimensional), or a shape that includes uncertainty: circle, sphere, 183 ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of 184 these shapes can be found in [RFC5491]. 186 Optionally, a reference to a 'map' document can be provided. The 187 reference is a URI. The document could be an image or dataset that 188 represents a map, floorplan or other form. The type of document the 189 URI points to is described as a MIME media type. Metadata in the 190 relative location can include the location of the reference point in 191 the map as well as an orientation (angle from North) and scale to 192 align the document CRS with the WGS-84 CRS. The document is assumed 193 to be useable by the application receiving the PIDF with the relative 194 location to locate the reference point in the map. This document 195 does not describe any mechanisms for displaying or manipulating the 196 document other than providing the reference location, orientation and 197 scale. 199 As an example, consider a relative location expressed as a point, 200 relative to a civic location: 202 210 211 212 213 214 AU 215 NSW 216 Wollongong 217 North Wollongong 218 Flinders 219 Street 220 123 221 222 223 224 225 Front 226 227 228 229 231 100 50 232 233 234 235 236 237 GPS 238 239 240 http://example.com/location/map.png 241 242 20. 120. 243 29. 244 20. -20. 245 246 247 mac:1234567890ab 248 2007-06-22T20:57:29Z 249 250 252 4. Relative Location 254 Relative location is a shape (point, circle, ellipse...). The shape 255 is defined with a CRS that has a datum defined as the reference 256 (which appears as a civic address or geodetic location in the tuple), 257 and the shape coordinates as meter offsets North/East of the datum 258 measured in meters (with an optional Z offset relative to datum 259 altitude). An optional angle allows the reference CRS be to rotated 260 with respect to North. 262 4.1. Relative Coordinate System 264 The relative coordinate reference system uses a coordinate system 265 with two or three axes. 267 The baseline and reference locations are used to define a relative 268 datum. The reference location defines the origin of the coordinate 269 system. The centroid of the reference location is used when the 270 reference location contains any uncertainty. 272 The axes in this coordinate system are originally oriented based on 273 the directions of East, North and Up from the reference location: the 274 first (x) axis increases to the East, the second (y) axis points 275 North, and the optional third (z) axis points Up. All axes of the 276 coordinate system use meters as a basic unit. 278 Any coordinates in the relative shapes use the described Cartesian 279 coordinate system. In the XML form, this uses a URN of 280 "urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and 281 "urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes. 282 The binary form uses different shape type identifiers for 2D and 3D 283 shapes. 285 Dynamic location information [RFC5962] in the baseline or reference 286 location alters relative coordinate system. The resulting Cartesian 287 coordinate system axes are rotated so that the 'y' axis is oriented 288 along the direction described by the element. The 289 coordinate system also moves as described by the and 290 elements. 292 4.2. Placement of XML Elements 294 The baseline of the reference location is represented as like a normal PIDF-LO. Relative location adds a new element to Within 297 and elements are described. Within are 298 shape elements described below. This document extends PIDF-LO as 299 described in [I-D.ietf-geopriv-local-civic]. 301 4.3. Binary Format 303 This document describes a way to encode the relative location in a 304 binary TLV form for use in other protocols that use TLVs to represent 305 location. 307 A type-length-value encoding is used. 309 +------+------+------+------+------+------+------+ 310 | Type |Length| Value ... 311 +------+------+------+------+------+------+ 312 | X | N | Value label ... 313 +------+------+------+------+------+------+------+ 315 Figure 1: TLV-tuple format 317 Type field (X) is defined as a single byte. The type codes used are 318 registered an IANA managed 'RLtypes' registry defined by this 319 document, and restricted to not include the values defined by the 320 CAtypes registry. This restriction permits a location reference and 321 offset to be coded with unique TLVs. 323 The Length field (N) is defined as an unsigned integer that is one 324 byte in length. This field can encode values from 0 to 255. The 325 length field describes the number of bytes in the Value. Length does 326 not count the bytes used for the Type or Length. 328 The Value field is defined separately for each type. 330 Each element of the relative location has a unique TLV assignment. A 331 relative location encoded in TLV would have the baseline location 332 TLVs, a reference location TLV which contains within it the reference 333 refinement TLVs. The reference TLVs are followed by the relative 334 offset, and optional map TLDs described in this document. 336 4.4. Distances and Angles 338 All distance measures used in shapes are expressed in meters. 340 All orientation angles used in shapes are expressed in degrees. 341 Orientation angles are measured from WGS84 Northing to Easting with 342 zero at Northing. Orientation angles in the relative coordinate 343 system start from the second coordinate axis (y or Northing) and 344 increase toward the first axis (x or Easting). 346 4.5. Value Encoding 348 The binary form uses single-precision floating point values [IEEE754] 349 to represent coordinates, distance and angle measures. Single 350 precision values are 32-bit values with a sign bit, 8 exponent bits 351 and 23 fractional bits. 353 Binary-encoded coordinate values are considered to be a single value 354 without uncertainty. When encoding a value that cannot be exactly 355 represented, the best approximation is chosen according to 356 [Clinger1990]. 358 4.6. Relative Location Restrictions 360 More than one relative shape MUST NOT be included in either a PIDF-LO 361 or TLV encoding of location for a given reference point. 363 Any error in the reference point transfers to the location described 364 by the relative location. Any errors arising from an implementation 365 not supporting or understanding elements of the reference point 366 directly increases the error (or uncertainty) in the resulting 367 location. 369 4.7. Baseline TLVs 371 Baseline locations is described using the formats defined in 372 [RFC4776] or [RFC6225]. 374 4.8. Reference TLV 376 When a reference is encoded in binary form, the baseline and 377 reference locations are combined in a reference TLV. This TLV 378 contains civic address TLVs (if the baseline was a civic) or geo TLVs 379 (if the baseline was a geo). 381 +------+------+------+------+------+------+ 382 | 111 |Length| Reference TLVs | 383 +------+------+------+------+------+------+ 385 Reference TLV 387 4.9. Shapes 389 Shape data is used to represent regions of uncertainty for the 390 reference and relative locations. Shape data in the reference 391 location uses a [WGS84] CRS. Shape data in the relative location 392 uses a relative CRS. 394 The XML form for shapes uses Geography Markup Language (GML) 395 [OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference 396 locations use the CRS URNs specified in [RFC5491]; relative locations 397 use either a 2D CRS (urn:ietf:params:geopriv:relative:2d), or a 3D 398 (urn:ietf:params:geopriv:relative:3d), depending on the shape type. 400 The binary form of each shape uses a different shape types for 2d and 401 3d shapes. 403 Nine shape type codes are defined. 405 4.9.1. Point 407 A point "shape" describes a single point with unknown uncertainty. 408 It consists of a single set of coordinates. 410 In a two-dimensional CRS, the coordinate includes two values; in a 411 three-dimensional CRS, the coordinate includes three values. 413 4.9.1.1. XML encoding 415 A point is represented in GML using the following template: 417 419 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 420 422 GML Point Template 424 Where "$CRS-URN$" is replaced by a 425 urn:ietf:params:geopriv:relative:2d or 426 urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted 427 if the CRS is two-dimensional. 429 4.9.1.2. TLV encoding 431 The point shape is introduced by a TLV of 113 for a 2D point and 114 432 for a 3D point. 434 +------+------+ 435 | 113/4|Length| 436 +------+------+------+------+ 437 | Coordinate-1 | 438 +------+------+------+------+ 439 | Coordinate-2 | 440 +------+------+------+------+ 441 | (3D-only) Coordinate-3 | 442 +------+------+------+------+ 444 Point Encoding 446 4.9.2. Circle or Sphere Shape 448 A circle or sphere describes a single point with a single uncertainty 449 value in meters. 451 In a two-dimensional CRS, the coordinate includes two values and the 452 resulting shape forms a circle. In a three-dimensional CRS, the 453 coordinate includes three values and the resulting shape forms a 454 sphere. 456 4.9.2.1. XML encoding 458 A circle is represented in and converted from GML using the following 459 template: 461 464 $Coordinate-1 $Coordinate-2$ 465 466 $Radius$ 467 468 470 GML Circle Template 472 A sphere is represented in and converted from GML using the following 473 template: 475 478 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 479 480 $Radius$ 481 482 484 GML Sphere Template 486 4.9.2.2. TLV encoding 488 A circular shape is introduced by a type code of 115. A spherical 489 shape is introduced by a type code of 116. 491 +------+------+ 492 | 115/6|Length| 493 +------+------+------+------+ 494 | Coordinate-1 | 495 +------+------+------+------+ 496 | Coordinate-2 | 497 +------+------+------+------+ 498 | (3D-only) Coordinate-3 | 499 +------+------+------+------+ 500 | Radius | 501 +------+------+------+------+ 503 Circle or Sphere Encoding 505 4.9.3. Ellipse or Ellipsoid Shape 507 A ellipse or ellipsoid describes a point with an elliptical or 508 ellipsoidal uncertainty region. 510 In a two-dimensional CRS, the coordinate includes two values, plus a 511 semi-major axis, a semi-minor axis, a semi-major axis orientation 512 (clockwise from North). In a three-dimensional CRS, the coordinate 513 includes three values and in addition to the two-dimensional values, 514 an altitude uncertainty (semi-vertical) is added. 516 4.9.3.1. XML encoding 518 An ellipse is represented in and converted from GML using the 519 following template: 521 524 $Coordinate-1 $Coordinate-2$ 525 526 $Semi-Major$ 527 528 529 $Semi-Minor$ 530 531 532 $Orientation$ 533 534 536 GML Ellipse Template 538 An ellipsoid is represented in and converted from GML using the 539 following template: 541 544 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 545 546 $Semi-Major$ 547 548 549 $Semi-Minor$ 550 551 552 $Semi-Vertical$ 553 554 555 $Orientation$ 556 557 559 GML Ellipsoid Template 561 4.9.3.2. TLV encoding 563 An ellipse is introduced by a type code of 117 and an ellipsoid is 564 introduced by a type code of 118. 566 +------+------+ 567 | 117/8|Length| 568 +------+------+------+------+ 569 | Coordinate-1 | 570 +------+------+------+------+ 571 | Coordinate-2 | 572 +------+------+------+------+ 573 | (3D-only) Coordinate-3 | 574 +------+------+------+------+------+------+------+------+ 575 | Semi-Major Axis | Semi-Minor Axis | 576 +------+------+------+------+------+------+------+------+ 577 | Orientation | (3D) Semi-Vertical Axis | 578 +------+------+------+------+------+------+------+------+ 580 Ellipse or Ellipsoid Encoding 582 4.9.4. Polygon or Prism Shape 584 A polygon or prism include a number of points that describe the outer 585 boundary of an uncertainty region. A prism also includes an altitude 586 for each point and prism height. 588 At least 3 points MUST be included in a polygon. In order to 589 interoperate with existing systems, an encoding SHOULD include 15 or 590 fewer points, unless the recipient is known to support larger 591 numbers. 593 4.9.4.1. XML Encoding 595 A polygon is represented in and converted from GML using the 596 following template: 598 600 601 602 603 $Coordinate1-1$ $Coordinate1-2$ 604 $Coordinate2-1$ $Coordinate2-2$ 605 $Coordinate3-1$ ... 606 ... 607 $CoordinateN-1$ $CoordinateN-2$ 608 $Coordinate1-1$ $Coordinate1-2$ 609 610 611 612 614 GML Polygon Template 616 Alternatively, a series of "pos" elements can be used in place of the 617 single "posList". Each "pos" element contains two or three 618 coordinate values. 620 Note that the first point is repeated at the end of the sequence of 621 coordinates and no explicit count of the number of points is 622 provided. 624 A GML polygon that includes altitude cannot be represented completely 625 in binary. When converting to the binary representation, a two 626 dimensional CRS is used and altitude is removed from each coordinate. 628 A prism is represented in and converted from GML using the following 629 template: 631 634 635 636 637 638 639 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 640 $Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$ 641 $Coordinate2-1$ ... ... 642 ... 643 $CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$ 644 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 645 646 647 648 649 650 651 $Height$ 652 653 655 GML Prism Template 657 Alternatively, a series of "pos" elements can be used in place of the 658 single "posList". Each "pos" element contains three coordinate 659 values. 661 4.9.4.2. TLV Encoding 663 A polygon containing 2D points is uses a type code of 119. A polygon 664 with 3D points uses a type code of 120. A prism uses a type code of 665 121. 667 +------+------+ 668 |119-21|Length| 669 +------+------+------+------+------+------+ 670 | Count | (3D-only) Height | 671 +------+------+------+------+------+------+ 672 | Coordinate1-1 | 673 +------+------+------+------+ 674 | Coordinate1-2 | 675 +------+------+------+------+ 676 | (3D-only) Coordinate1-3 | 677 +------+------+------+------+ 678 | Coordinate2-1 | 679 +------+------+------+------+ 680 ... 681 +------+------+------+------+ 682 | CoordinateN-1 | 683 +------+------+------+------+ 684 | CoordinateN-2 | 685 +------+------+------+------+ 686 | (3D-only) CoordinateN-3 | 687 +------+------+------+------+ 689 Polygon or Prism Encoding 691 Note that unlike the polygon representation in GML, the first and 692 last points are not the same point to be the same in the TLV 693 representation. The duplicated point is removed from the binary 694 form. 696 4.9.5. Arc-Band Shape 698 A arc-band describes a region constrained by a range of angles and 699 distances from a predetermined point. This shape can only be 700 provided for a two-dimensional CRS. 702 Distance and angular measures are defined in meters and degrees 703 respectively. Both are encoded as single precision floating point 704 values. 706 4.9.5.1. XML encoding 708 An arc-band is represented in and converted from GML using the 709 following template: 711 714 $Coordinate-1 $Coordinate-2$ 715 716 $Inner-Radius$ 717 718 719 $Inner-Radius$ 720 721 722 $Start-Angle$ 723 724 725 $Opening-Angle$ 726 727 729 GML Arc-Band Template 731 4.9.5.2. TLV Encoding 733 An arc-band is introduced by a type code of 122. 735 +------+------+ 736 | 122 |Length| 737 +------+------+------+------+ 738 | Coordinate | 739 +------+------+------+------+ 740 | Coordinate | 741 +------+------+------+------+------+------+------+------+ 742 | Inner Radius | Outer Radius | 743 +------+------+------+------+------+------+------+------+ 744 | Start Angle | Opening Angle | 745 +------+------+------+------+------+------+------+------+ 747 Arc-Band Encoding 749 4.10. Dynamic Location TLVs 751 Dynamic location elements use the definitions in [RFC5962]. 753 4.10.1. Orientation 755 The orientation of the target is described using one or two angles. 757 +------+------+ 758 | 123 |Length| 759 +------+------+------+------+ 760 | Angle | 761 +------+------+------+------+ 762 | (Optional) Angle | 763 +------+------+------+------+ 765 Dynamic Orientation TLVs 767 4.10.2. Speed 769 The speed of the target is a scalar value in meters per second. 771 +------+------+ 772 | 124 |Length| 773 +------+------+------+------+ 774 | Length | 775 +------+------+------+------+ 776 | Speed | 777 +------+------+------+------+ 779 Dynamic Speed TLVs 781 4.10.3. Heading 783 The heading, or direction of travel, is described using one or two 784 angles. 786 +------+------+ 787 | 125 |Length| 788 +------+------+------+------+ 789 | Angle | 790 +------+------+------+------+ 791 | (Optional) Angle | 792 +------+------+------+------+ 794 Dynamic Heading TLVs 796 4.11. Secondary Map Metadata 798 The optional "map" URL can be used to provide a user of relative 799 location with a visual reference for the location information. This 800 document does not describe how the recipient uses the map nor how it 801 locates the reference or offset within the map. Maps can be simple 802 images, vector files, 2-D or 3-D geospatial databases, or any other 803 form of representation understood by both the sender and recipient. 805 4.11.1. Map URL 807 In XML, the map is a element defined within 808 and contains the URL. The URL is encoded as a UTF-8 encoded string. 809 An "http:" or "https:" URL MUST be used unless the entity creating 810 the PIDF-LO is able to ensure that authorized recipients of this data 811 are able to use other URI schemes. A "type" attribute MUST be 812 present and specifies the kind of map the URL points to. Map types 813 are specified as mime media types as recorded in the IANA Media Types 814 registry. For example https://www.example.com/ 815 floorplans/123South/floor-2. In binary, the map type is a 816 separate TLV from the map URL: 818 +------+------+------+------+------+-- --+------+ 819 | 126 |Length| Map Media Type ... 820 +------+------+------+------+------+-- --+------+ 821 | 127 |Length| Map Image URL ... 822 +------+------+------+------+------+-- --+------+ 824 Map URL TLVs 826 4.11.2. Map Coordinate Reference System 828 The CRS used by the map depends on the type of map. For example, a 829 map described by a 3-D geometric model of the building may contain a 830 complete CRS description in it. For some kinds of maps, typically 831 described as images, the CRS used within the map must define the 832 following: 834 o The CRS origin 836 o The CRS axes used and their orientation 838 o The unit of measure used 840 This document provides elements that allow for a mapping between the 841 local coordinate reference system used for the relative location and 842 the coordinate reference system used for the map where they are not 843 the same. 845 4.11.2.1. Map Reference Point Offset 847 This optional element identifies the coordinates of the reference 848 point as it appears in the map. This value is measured in a map-type 849 dependent manner, using the coordinate system of the map. 851 For image maps, coordinates start from the upper left corner and 852 coordinates are first counted by column with positive values to the 853 right; then rows are counted with positive values toward the bottom 854 of the image. For such an image, the first item is columns, the 855 second rows and any third value applies to any third dimension used 856 in the image coordinate space. 858 The element contains 2 (or 3) coordinates similar to a GML 859 "pos", For example: 861 2670.0 1124.0 1022.0 863 Map Reference Point Example XML 865 +------+------+ 866 | 128 |Length| 867 +------+------+------+------+ 868 | Coordinate-1 | 869 +------+------+------+------+ 870 | Coordinate-2 | 871 +------+------+------+------+ 872 | (3D-only) Coordinate-3 | 873 +------+------+------+------+ 875 Map Reference Point Coordinates TLV 877 If omitted, a value containing all zeros is assumed. If the 878 coordinates provided contain fewer values than are needed, the first 879 value from the set is applied in place of any missing values. 881 4.11.2.2. Map Orientation 883 The map orientation includes the orientation of the map direction in 884 relation to the Earth. Map orientation is expressed relative to the 885 orientation of the relative coordinate system. This means that map 886 orientation with respect to WGS84 North is the sum of th orientation 887 field, plus any orientation included in a dynamic portion of the 888 reference location. Both values default to zero if no value is 889 specified. 891 This type uses a single precision floating point value of degrees 892 relative to North. 894 In XML, the element contains a single floating point 895 value, example 67.00. In TLV form: 897 +------+------+------+------+------+------+ 898 | 129 |Length| Angle | 899 +------+------+------+------+------+------+ 901 Map Orientation TLV 903 4.11.2.3. Map Scale 905 The optional map scale describes the relationship between the units 906 of measure used in the map, relative to the meters unit used in the 907 relative coordinate system. 909 This type uses a sequence of IEEE 754 [IEEE.754] single precision 910 floating point values to represent scale as a sequence of numeric 911 values. The units of these values is dependent on the type of map, 912 and could for example be pixels per meter for an image. 914 A scaling factor is provided for each axis in the coordinate system. 915 For a two-dimensional coordinate system, two values are included to 916 allow for different scaling along the x and y axes independently. 917 For a three-dimensional coordinate system, three values are specified 918 for the x, y and z axes. 920 Alternatively, a single scaling value MAY be used to apply the same 921 scaling factor to all coordinate components. 923 Images that use a rows/columns coordinate system often use a left- 924 handed coordinate system. A negative value for the y/rows-axis 925 scaling value can be used to account for any change in direction 926 between the y-axis used in the relative coordinate system and the 927 rows axis of the image coordinate system. 929 In XML, the element may contain the single scale value, or 930 may contain 2 (or 3) values similar to a GML "pos" with separate 931 scale values. In TLV form: 933 +------+------+------+------+------+ 934 | 130 |Length| Scales ... 935 +------+------+------+------+------+ 937 Map Scale TLV 939 4.11.3. Map Example 941 An example of expressing a map is: 943 944 945 http://example.com/map.jpg 946 947 200 210 948 68 949 2.90 -2.90 950 952 Map Example 954 5. Examples 956 5.1. Civic PIDF with Polygon Offset 958 966 967 968 969 970 AU 971 NSW 972 Wollongong 973 North Wollongong 974 Flinders 975 Street 976 123 977 978 979 980 981 A 982 I 983 113 984 Front 985 986 987 988 990 991 992 433.0 -734.0 993 431.0 -733.0 994 431.0 -732.0 995 433.0 -731.0 996 434.0 -732.0 997 434.0 -733.0 998 433.0 -734.0 999 1000 1001 1002 1003 1004 1005 1006 GPS 1007 1008 mac:1234567890ab 1009 2007-06-22T20:57:29Z 1010 1011 1013 5.2. Geo PIDF with Circle Offset 1015 1016 1022 1023 1024 1025 1026 -34.407 150.883 1027 1028 50.0 1029 1030 1031 1032 1033 1034 -34.407 150.883 1035 1036 1037 1038 1040 500.0 750.0 1041 1042 5.0 1043 1044 1045 1046 1047 1048 https://www.example.com/flrpln/123South/flr-2 1049 2670.0 1124.0 1022.0 1050 67.00 1051 10 1052 1053 1054 1055 Wiremap 1056 1057 mac:1234567890ab 1058 2007-06-22T20:57:29Z 1059 1060 1061 1062 2003-06-22T20:57:29Z 1063 1064 1066 5.3. Civic TLV with Point Offset 1068 +--------+-------------------------------------------------+ 1069 | Type | Value | 1070 +--------+-------------------------------------------------+ 1071 | 0 | en | 1072 | | | 1073 | 1 | IL | 1074 | | | 1075 | 3 | Chicago | 1076 | | | 1077 | 34 | Wacker | 1078 | | | 1079 | 18 | Drive | 1080 | | | 1081 | 19 | 3400 | 1082 | | | 1083 | 112 | Reference | 1084 | | | 1085 | 40 | BBuilding|A | 1086 | | | 1087 | 40 | AFloor|6th | 1088 | | | 1089 | 40 | BSuite|213 | 1090 | | | 1091 | 40 | ADoor|Front | 1092 | | | 1093 | 115 | 100 70 | 1094 | | | 1095 | 126 | image/png | 1096 | | | 1097 | 127 | http://maps.example.com/3400Wacker/A6 | 1098 | | | 1099 | 128 | 0.0 4120.0 | 1100 | | | 1101 | 129 | 113.0 | 1102 | | | 1103 | 130 | 10.6 | 1104 +--------+-------------------------------------------------+ 1106 6. Schema Definition 1108 1109 1117 1121 1122 1124 Relative Location for PIDF-LO 1125 1126 1127 This schema defines a location representation that allows for 1128 the description of locations that are relative to another. 1129 An optional map reference is also defined. 1130 1131 1133 1135 1137 1138 1139 1140 1141 1142 1143 1145 1146 1147 1148 1149 1151 1152 1153 1154 1155 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1168 1169 1170 1171 1173 1174 1175 1176 1177 1178 1179 1181 1183 1185 1186 1187 1188 1190 1191 1192 1193 1195 1196 1197 1199 1201 1202 1203 1207 1208 1209 1210 1211 1213 1215 xml schema relative-location 1217 7. Security Considerations 1219 This document describes a data format. To a large extent, security 1220 properties of this depend on how this data is used. 1222 Privacy for location data is typically important. Adding relative 1223 location may increase the precision of the location, but does not 1224 otherwise alter its privacy considerations, which are discussed in 1225 [RFC4119] 1227 [[Not that interesting, but it could be relevant ?]] The fractional 1228 bits in IEEE 754 [IEEE.754] floating point values can be used as a 1229 covert channel. For values of either zero or infinity, non-zero 1230 fraction bits could be used to convey information. If the presence 1231 of covert channels is not desired then the fractional bits MUST be 1232 set to zero. There is no need to represent NaN (not a number) in 1233 this encoding. 1235 8. IANA Considerations 1237 8.1. Relative Location Registry 1239 This document creates a new registry called 'Relative Location 1240 Parameters'. As defined in [RFC5226], this registry operates under 1241 "IETF Consensus" rules. 1243 The content of this registry includes: 1245 Relative Location Code: Numeric identifier, assigned by IANA. 1247 Brief description: Short description identifying the meaning of the 1248 element. 1250 Reference to published specification: A stable reference to an RFC 1251 which describes the value in sufficient detail so that 1252 interoperability between independent implementations is possible. 1254 IANA is requested to not permit values to be assigned into this 1255 registry which conflict with values assigned in the CAtypes registry 1256 or to permit values to be assigned into the CAtypes registry which 1257 conflict with values assigned to to this registry unless the IANA 1258 considerations section for the new value explicitly overrides this 1259 prohibition, and the document defining the value describes how 1260 conflicting TLV codes will be interpreted by implementations 1262 The values defined are: 1264 +--------+----------------------------------------+-----------+ 1265 | RLtype | description | Reference | 1266 +--------+-------+--------------------------------+-----------+ 1267 | 111 | relative location reference | this RFC | 1268 | 112 | relative location angle | this RFC | 1269 | 113 | relative location shape 2D point | this RFC | 1270 | 114 | relative location shape 3D point | this RFC | 1271 | 115 | relative location shape circular | this RFC | 1272 | 116 | relative location shape spherical | this RFC | 1273 | 117 | relative location shape elliptical | this RFC | 1274 | 118 | relative location shape ellipsoid | this RFC | 1275 | 119 | relative location shape 2D polygon | this RFC | 1276 | 120 | relative location shape 3D polygon | this RFC | 1277 | 121 | relative location shape prism | this RFC | 1278 | 122 | relative location shape arc-band | this RFC | 1279 | 123 | relative location dynamic orientation | this RFC | 1280 | 124 | relative location dynamic speed | this RFC | 1281 | 125 | relative location dynamic heading | this RFC | 1282 | 126 | relative location map type | this RFC | 1283 | 127 | relative location map URI | this RFC | 1284 | 128 | relative location map coordinates | this RFC | 1285 | 129 | relative location map angle | this RFC | 1286 | 130 | relative location map scale | this RFC | 1287 +--------+-------+--------------------------------+-----------+ 1289 8.2. URN Sub-Namespace Registration 1291 This document registers a new XML namespace, as per the guidelines in 1292 [RFC3688]) that has been registered with IANA. 1294 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative 1296 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1297 Martin Thomson (martin.thomson@andrew.com). 1299 XML: 1301 BEGIN 1302 1303 1305 1306 1307 GEOPRIV Relative Location 1308 1309 1310

Format for representing relative location in GEOPRIV

1311

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

1312

See 1313 RFCXXXX.

1314 1315 1316 1319 END 1321 8.3. XML Schema Registration 1323 This section registers an XML schema as per the procedures in 1324 [RFC3688]. 1326 URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation 1328 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1329 Martin Thomson (martin.thomson@andrew.com). 1331 The XML for this schema can be found as the entirety of Section 7 1332 of this document. 1334 8.4. CRS public identifier registration 1336 This section registers two public identifiers as per the procedures 1337 in [RFC3688]. 1339 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d 1340 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1341 Martin Thomson (martin.thomson@andrew.com). 1343 XML: 1345 BEGIN 1346 1347 1349 1350 1351 GEOPRIV Relative Location 2d CRS 1352 1353 1354

Identifier for a 2D CRS in GEOPRIV relative location

1355

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

1356

See 1357 RFCXXXX.

1358 1359 1360 1363 END 1365 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d 1367 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1368 Martin Thomson (martin.thomson@andrew.com). 1370 XML: 1372 BEGIN 1373 1374 1376 1377 1378 GEOPRIV Relative Location 3d CRS 1379 1380 1381

Identifier for a 3D CRS in GEOPRIV relative location

1382

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

1383

See 1384 RFCXXXX.

1385 1386 1387 1390 END 1392 8.5. CAtype Registration 1394 This section adds a new entry to the CAtype registry defined by 1395 [I-D.ietf-geopriv-local-civic]. 1397 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative 1399 Local Name: REL 1401 Description: Relative location from a reference point 1403 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 1404 (geopriv@ietf.org). 1406 Specification: RFCXXXX 1408 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation 1410 Type: A 1412 9. Acknowledgements 1414 This is the product of a design team on relative location. Besides 1415 the authors, this team included: Marc Linsner, James Polk, and James 1416 Winterbottom. 1418 10. References 1420 10.1. Normative References 1422 [RFC2119] Bradner, S., "Key words for use in 1423 RFCs to Indicate Requirement Levels", 1424 BCP 14, RFC 2119, March 1997. 1426 [RFC4119] Peterson, J., "A Presence-based 1427 GEOPRIV Location Object Format", 1428 RFC 4119, December 2005. 1430 [RFC4776] Schulzrinne, H., "Dynamic Host 1431 Configuration Protocol (DHCPv4 and 1432 DHCPv6) Option for Civic Addresses 1433 Configuration Information", RFC 4776, 1434 November 2006. 1436 [RFC5139] Thomson, M. and J. Winterbottom, 1437 "Revised Civic Location Format for 1438 Presence Information Data Format 1439 Location Object (PIDF-LO)", RFC 5139, 1440 February 2008. 1442 [RFC5226] Narten, T. and H. Alvestrand, 1443 "Guidelines for Writing an IANA 1444 Considerations Section in RFCs", 1445 BCP 26, RFC 5226, May 2008. 1447 [RFC5491] Winterbottom, J., Thomson, M., and H. 1448 Tschofenig, "GEOPRIV Presence 1449 Information Data Format Location 1450 Object (PIDF-LO) Usage Clarification, 1451 Considerations, and Recommendations", 1452 RFC 5491, March 2009. 1454 [RFC5962] Schulzrinne, H., Singh, V., 1455 Tschofenig, H., and M. Thomson, 1456 "Dynamic Extensions to the Presence 1457 Information Data Format Location 1458 Object (PIDF-LO)", RFC 5962, 1459 September 2010. 1461 [RFC6225] Polk, J., Linsner, M., Thomson, M., 1462 and B. Aboba, "Dynamic Host 1463 Configuration Protocol Options for 1464 Coordinate-Based Location 1465 Configuration Information", RFC 6225, 1466 July 2011. 1468 [I-D.ietf-geopriv-local-civic] Winterbottom, J., Thomson, M., 1469 Barnes, R., Rosen, B., and R. George, 1470 "Specifying Civic Address Extensions 1471 in PIDF-LO", 1472 draft-ietf-geopriv-local-civic-02 1473 (work in progress), October 2011. 1475 [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., 1476 Portele, C., and A. Whiteside, 1477 "Geographic information - Geography 1478 Markup Language (GML)", OpenGIS 03- 1479 105r1, April 2004, . 1483 [OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 1484 PIDF-LO Shape Application Schema for 1485 use by the Internet Engineering Task 1486 Force (IETF)", OGC Best Practice 06- 1487 142r1, Version: 1.0, April 2007. 1489 [IEEE.754] IEEE, "IEEE Standard for Binary 1490 Floating-Point Arithmetic", IEEE 1491 Standard 754-1985, January 2003. 1493 [Clinger1990] Clinger, W., "How to Read Floating 1494 Point Numbers Accurately", 1495 Proceedings of Conference on 1496 Programming Language Design and 1497 Implementation pp. 92-101, 1990, . 1501 10.2. Informative References 1503 [RFC3688] Mealling, M., "The IETF XML 1504 Registry", BCP 81, RFC 3688, 1505 January 2004. 1507 [RFC3986] Berners-Lee, T., Fielding, R., and L. 1508 Masinter, "Uniform Resource 1509 Identifier (URI): Generic Syntax", 1510 STD 66, RFC 3986, January 2005. 1512 Authors' Addresses 1514 Martin Thomson 1515 Andrew Corporation 1516 Andrew Building (39) 1517 Wollongong University Campus 1518 Northfields Avenue 1519 Wollongong, NSW 2522 1520 AU 1522 EMail: martin.thomson@andrew.com 1523 Brian Rosen 1524 Neustar 1525 470 Conrad Dr 1526 Mars, PA 16046 1527 US 1529 EMail: br@brianrosen.net 1531 Dorothy Stanley 1532 Aruba Networks 1533 1322 Crossman Ave 1534 Sunnyvale, CA 94089 1535 US 1537 EMail: dstanley@arubanetworks.com 1539 Gabor Bajko 1540 Nokia 1541 323 Fairchild Drive 1542 Mountain View, CA 94043 1543 US 1545 EMail: gabor.bajko@nokia.com 1547 Allan Thomson 1548 Cisco Systems, Inc. 1549 170 West Tasman Drive 1550 San Jose, CA 95134 1551 US 1553 EMail: althomso@cisco.com