idnits 2.17.1 draft-ietf-geopriv-relative-location-08.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 (September 06, 2013) is 3882 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) ** Downref: Normative reference to an Unknown state RFC: RFC 1014 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clinger1990' -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84' Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Microsoft 4 Intended status: Standards Track B. Rosen 5 Expires: March 10, 2014 Neustar 6 D. Stanley 7 Aruba Networks 8 G. Bajko 9 Nokia 10 A. Thomson 11 Cisco Systems, Inc. 12 September 06, 2013 14 Relative Location Representation 15 draft-ietf-geopriv-relative-location-08 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. An alternative binary representation is described. 25 Optionally, a reference to a secondary document (such as a map image) 26 can be included, along with the relationship of the map coordinate 27 system to the reference/offset coordinate system to allow display of 28 the map with the reference point and the relative offset. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 10, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Relative Coordinate System . . . . . . . . . . . . . . . 7 68 4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 8 69 4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 9 71 4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 9 72 4.6. Relative Location Restrictions . . . . . . . . . . . . . 9 73 4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9 74 4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9 75 4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 11 78 4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 12 79 4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 14 80 4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 16 81 4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18 82 4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 18 83 4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 18 84 4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 18 85 4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 19 86 4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 19 87 4.11.2. Map Coordinate Reference System . . . . . . . . . . 19 88 4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 22 89 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 22 91 5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 24 92 5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25 93 6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 8.1. Relative Location Registry . . . . . . . . . . . . . . . 29 97 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 30 98 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 31 99 8.4. Geopriv Identifiers Registry . . . . . . . . . . . . . . 31 100 8.4.1. Registration of Two-Dimentional Relative Coordinate 101 Reference System URN . . . . . . . . . . . . . . . . 32 102 8.4.2. Registration of Three-Dimentional Relative Coordinate 103 Reference System URN . . . . . . . . . . . . . . . . 32 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 107 10.2. Informative References . . . . . . . . . . . . . . . . . 35 109 1. Introduction 111 This document describes a format for the expression of relative 112 location information. 114 A relative location is formed of a reference location, plus a 115 relative offset from that reference location. The reference location 116 can be represented in either civic or geodetic form. The reference 117 location can also have dynamic components such as velocity. The 118 relative offset is specified in meters using a Cartesian coordinate 119 system. 121 In addition to the relative location, an optional URI can be provided 122 to a document that contains a map, floorplan or other spatially 123 oriented information. Applications could use this information to 124 display the relative location. Additional fields allow the map to be 125 oriented and scaled correctly. 127 Two formats are included: an XML form that is intended for use in 128 PIDF-LO [RFC4119] and a TLV format for use in other protocols such as 129 those that already convey binary representation of location 130 information defined in [RFC4776]. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Overview 140 This document describes an extension to PIDF-LO [RFC4119] as updated 141 by [RFC5139] and [RFC5491], to allow the expression of a location as 142 an offset relative to a reference. 144 Reference 145 Location 146 o 147 \ 148 \ Offset 149 \ 150 _\| 151 x 152 Relative 153 Location 155 This extension allows the creator of a location object to include two 156 location values plus an offset. The two location values, named 157 "baseline" and "reference", combine to form the origin of the offset. 158 The final, relative location is described relative to this reference 159 point. 161 ..--"""--.. 162 .-' `-. 163 ,' `. 164 / Reference \ 165 / o \ 166 | \ | 167 | \ | 168 | \ | 169 \ _\| / 170 `. x .' \_ Baseline 171 `._ Relative _.' Location 172 `--..___..--' 174 The "baseline" location is included outside of the element. The baseline location is visible to a client that 176 does not understand relative location (i.e., it ignores the 177 element). 179 A client that does understand relative location will interpret the 180 location within the relative element as a refinement of the baseline 181 location. This document defines both a "reference" location, which 182 serves as a refinement of the baseline location and the starting 183 point; and an offset, which describes the location of the Target 184 based on this starting point. 186 Creators of location objects with relative location thus have a 187 choice of how much information to put into the "baseline" location 188 and how much to put into the "reference" location. For example, the 189 baseline location value could be precise enough to specify a building 190 that contains the relative location, and the reference location could 191 specify a point within the building from which the offset is 192 measured. 194 Location objects SHOULD NOT have all location information in the 195 baseline location. Doing this would cause clients that do not 196 understand relative location to incorrectly interpret the baseline 197 location (i.e., the reference point) as the actual, precise location 198 of the client. The baseline location is intended to carry a location 199 that encompasses both the reference location and the relative 200 location (i.e., the reference location plus offset). 202 It is possible to provide a valid relative location with no 203 information in the baseline. However, this provides recipients who 204 do not understand relative location with no information. A baseline 205 location SHOULD include sufficient information to encompass both the 206 reference and relative locations while providing a baseline that is 207 as accurate as possible. 209 Both the baseline and the reference location are defined either as a 210 geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If 211 the baseline location was expressed as a geodetic location, the 212 reference MUST be geodetic. If the baseline location was expressed 213 as a civic address, the reference MUST be a civic. 215 Baseline and reference locations MAY also include dynamic location 216 information [RFC5962]. 218 The relative location can be expressed using a point (2- or 219 3-dimensional), or a shape that includes uncertainty: circle, sphere, 220 ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of 221 these shapes can be found in [RFC5491]. 223 Optionally, a reference to a 'map' document can be provided. The 224 reference is a URI [RFC3986]. The document could be an image or 225 dataset that represents a map, floorplan or other form. The type of 226 document the URI points to is described as a MIME media type 227 [RFC2046]. Metadata in the relative location can include the 228 location of the reference point in the map as well as an orientation 229 (angle from North) and scale to align the document Co-ordinate 230 Reference System (CRS) with the WGS84 [WGS84] CRS. The document is 231 assumed to be useable by the application receiving the PIDF with the 232 relative location to locate the reference point in the map. This 233 document does not describe any mechanisms for displaying or 234 manipulating the document other than providing the reference 235 location, orientation and scale. 237 As an example, consider a relative location expressed as a point, 238 relative to a civic location: 240 248 249 250 251 252 AU 253 NSW 254 Wollongong 255 North Wollongong 256 Flinders 257 Street 258 123 259 260 261 262 263 Front Door 264 265 266 267 269 100 50 270 271 272 273 274 275 GPS 276 277 278 http://example.com/location/map.png 279 280 20. 120. 281 29. 282 20. -20. 283 284 285 mac:1234567890ab 286 2007-06-22T20:57:29Z 287 288 290 4. Relative Location 292 Relative location is a shape (e.g., point, circle, ellipse). The 293 shape is defined with a CRS that has a datum defined as the reference 294 (which appears as a civic address or geodetic location in the tuple), 295 and the shape coordinates as meter offsets North/East of the datum 296 measured in meters (with an optional Z offset relative to datum 297 altitude). An optional angle allows the reference CRS be to rotated 298 with respect to North. 300 4.1. Relative Coordinate System 302 The relative coordinate reference system uses a coordinate system 303 with two or three axes. 305 The baseline and reference locations are used to define a relative 306 datum. The reference location defines the origin of the coordinate 307 system. The centroid of the reference location is used when the 308 reference location contains any uncertainty. 310 The axes in this coordinate system are originally oriented based on 311 the directions of East, North and Up from the reference location: the 312 first (x) axis increases to the East, the second (y) axis points 313 North, and the optional third (z) axis points Up. All axes of the 314 coordinate system use meters as a basic unit. 316 Any coordinates in the relative shapes use the described Cartesian 317 coordinate system. In the XML form, this uses a URN of 318 "urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and 319 "urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes. 320 The binary form uses different shape type identifiers for 2D and 3D 321 shapes. 323 Dynamic location information [RFC5962] in the baseline or reference 324 location alters relative coordinate system. The resulting Cartesian 325 coordinate system axes are rotated so that the "y" axis is oriented 326 along the direction described by the element. The 327 coordinate system also moves as described by the and 328 elements. 330 The single timestamp included in the tuple (or equivalent) element 331 applies to all location elements, including all three components of a 332 relative location: baseline, reference and relative. This is 333 particularly important when there are dynamic components to these 334 items. A location generator is responsible for ensuring the 335 consistency of these fields. 337 4.2. Placement of XML Elements 339 The baseline of the reference location is represented as like a normal PIDF-LO. Relative location adds a new element to . Within , 342 and elements are described. Within are 343 the shape elements described below. This document extends PIDF-LO as 344 described in [RFC6848]. 346 4.3. Binary Format 348 This document describes a way to encode the relative location in a 349 binary TLV form for use in other protocols that use TLVs to represent 350 location. 352 A type-length-value encoding is used. 354 +------+------+------+------+------+------+------+ 355 | Type |Length| Value ... 356 +------+------+------+------+------+------+------+ 357 | T | N | Value ... 358 +------+------+------+------+------+------+------+ 360 Figure 1: TLV-tuple format 362 Type field (T) is an 8-bit unsigned integer. The type codes used are 363 registered an IANA-managed "Relative Location Parameters" registry 364 defined by this document, and restricted to not include the values 365 defined by the "CAtypes" registry. This restriction permits a 366 location reference and offset to be coded within the same object 367 without type collisions. 369 The Length field (N) is defined as an 8-bit unsigned integer. This 370 field can encode values from 0 to 255. The length field describes 371 the number of bytes in the Value. Length does not count the bytes 372 used for the Type or Length. 374 The Value field is defined separately for each type. 376 Each element of the relative location has a unique TLV assignment. A 377 relative location encoded in TLV form includes both baseline and 378 reference location TLVs and a reference location TLVs. The reference 379 TLVs are followed by the relative offset, and optional map TLDs 380 described in this document. 382 4.4. Distances and Angles 384 All distance measures used in shapes are expressed in meters. 386 All orientation angles used in shapes are expressed in degrees. 387 Orientation angles are measured from WGS84 Northing to Easting with 388 zero at Northing. Orientation angles in the relative coordinate 389 system start from the second coordinate axis (y or Northing) and 390 increase toward the first axis (x or Easting). 392 4.5. Value Encoding 394 The binary form uses single-precision floating point values IEEE 754 395 [IEEE.754] to represent coordinates, distance and angle measures. 396 Single precision values are 32-bit values with a sign bit, 8 exponent 397 bits and 23 fractional bits. This uses the interchange format 398 defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign, 399 biased exponent and significand, with the most significant bit first. 401 Binary-encoded coordinate values are considered to be a single value 402 without uncertainty. When encoding a value that cannot be exactly 403 represented, the best approximation MUST be selected according to 404 [Clinger1990]. 406 4.6. Relative Location Restrictions 408 More than one relative shape MUST NOT be included in either a PIDF-LO 409 or TLV encoding of location for a given reference point. 411 Any error in the reference point transfers to the location described 412 by the relative location. Any errors arising from an implementation 413 not supporting or understanding elements of the reference point 414 directly increases the error (or uncertainty) in the resulting 415 location. 417 4.7. Baseline TLVs 419 Baseline locations are described using the formats defined in 420 [RFC4776] or [RFC6225]. 422 4.8. Reference TLV 424 When a reference is encoded in binary form, the baseline and 425 reference locations are combined in a reference TLV. This TLV is 426 identified with the code 111 and contains civic address TLVs (if the 427 baseline was a civic) or geo TLVs (if the baseline was a geo). 429 +------+------+------+------+------+------+ 430 | 111 |Length| Reference TLVs | 431 +------+------+------+------+------+------+ 433 Reference TLV 435 4.9. Shapes 437 Shape data is used to represent regions of uncertainty for the 438 reference and relative locations. Shape data in the reference 439 location uses a WGS84 [WGS84] CRS. Shape data in the relative 440 location uses a relative CRS. 442 The XML form for shapes uses Geography Markup Language (GML) 443 [OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference 444 locations use the CRS URNs specified in [RFC5491]; relative locations 445 use either a 2D CRS (urn:ietf:params:geopriv:relative:2d), or a 3D 446 (urn:ietf:params:geopriv:relative:3d), depending on the shape type. 448 The binary form of each shape uses a different shape type for 2d and 449 3d shapes. 451 Nine shape type codes are defined. 453 4.9.1. Point 455 A point "shape" describes a single point with unknown uncertainty. 456 It consists of a single set of coordinates. 458 In a two-dimensional CRS, the coordinate includes two values; in a 459 three-dimensional CRS, the coordinate includes three values. 461 4.9.1.1. XML encoding 463 A point is represented in GML using the following template: 465 467 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 468 470 GML Point Template 472 Where "$CRS-URN$" is replaced by a 473 urn:ietf:params:geopriv:relative:2d or 474 urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted 475 if the CRS is two-dimensional. 477 4.9.1.2. TLV encoding 479 The point shape is introduced by a TLV of 113 for a 2D point and 114 480 for a 3D point. 482 +------+------+ 483 | 113/4|Length| 484 +------+------+------+------+ 485 | Coordinate-1 | 486 +------+------+------+------+ 487 | Coordinate-2 | 488 +------+------+------+------+ 489 | (3D-only) Coordinate-3 | 490 +------+------+------+------+ 492 Point Encoding 494 4.9.2. Circle or Sphere Shape 496 A circle or sphere describes a single point with a single uncertainty 497 value in meters. 499 In a two-dimensional CRS, the coordinate includes two values and the 500 resulting shape forms a circle. In a three-dimensional CRS, the 501 coordinate includes three values and the resulting shape forms a 502 sphere. 504 4.9.2.1. XML encoding 506 A circle is represented in and converted from GML using the following 507 template: 509 512 $Coordinate-1 $Coordinate-2$ 513 514 $Radius$ 515 516 518 GML Circle Template 520 A sphere is represented in and converted from GML using the following 521 template: 523 526 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 527 528 $Radius$ 529 530 532 GML Sphere Template 534 4.9.2.2. TLV encoding 536 A circular shape is introduced by a type code of 115. A spherical 537 shape is introduced by a type code of 116. 539 +------+------+ 540 | 115/6|Length| 541 +------+------+------+------+ 542 | Coordinate-1 | 543 +------+------+------+------+ 544 | Coordinate-2 | 545 +------+------+------+------+ 546 | (3D-only) Coordinate-3 | 547 +------+------+------+------+ 548 | Radius | 549 +------+------+------+------+ 551 Circle or Sphere Encoding 553 4.9.3. Ellipse or Ellipsoid Shape 555 A ellipse or ellipsoid describes a point with an elliptical or 556 ellipsoidal uncertainty region. 558 In a two-dimensional CRS, the coordinate includes two values, plus a 559 semi-major axis, a semi-minor axis, a semi-major axis orientation 560 (clockwise from North). In a three-dimensional CRS, the coordinate 561 includes three values and in addition to the two-dimensional values, 562 an altitude uncertainty (semi-vertical) is added. 564 4.9.3.1. XML encoding 566 An ellipse is represented in and converted from GML using the 567 following template: 569 572 $Coordinate-1 $Coordinate-2$ 573 574 $Semi-Major$ 575 576 577 $Semi-Minor$ 578 579 580 $Orientation$ 581 582 584 GML Ellipse Template 586 An ellipsoid is represented in and converted from GML using the 587 following template: 589 592 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 593 594 $Semi-Major$ 595 596 597 $Semi-Minor$ 598 599 600 $Semi-Vertical$ 601 602 603 $Orientation$ 604 605 607 GML Ellipsoid Template 609 4.9.3.2. TLV encoding 611 An ellipse is introduced by a type code of 117 and an ellipsoid is 612 introduced by a type code of 118. 614 +------+------+ 615 | 117/8|Length| 616 +------+------+------+------+ 617 | Coordinate-1 | 618 +------+------+------+------+ 619 | Coordinate-2 | 620 +------+------+------+------+ 621 | (3D-only) Coordinate-3 | 622 +------+------+------+------+------+------+------+------+ 623 | Semi-Major Axis | Semi-Minor Axis | 624 +------+------+------+------+------+------+------+------+ 625 | Orientation | (3D) Semi-Vertical Axis | 626 +------+------+------+------+------+------+------+------+ 628 Ellipse or Ellipsoid Encoding 630 4.9.4. Polygon or Prism Shape 632 A polygon or prism include a number of points that describe the outer 633 boundary of an uncertainty region. A prism also includes an altitude 634 for each point and prism height. 636 At least 3 points MUST be included in a polygon. In order to 637 interoperate with existing systems, an encoding SHOULD include 15 or 638 fewer points, unless the recipient is known to support larger 639 numbers. 641 4.9.4.1. XML Encoding 643 A polygon is represented in and converted from GML using the 644 following template: 646 648 649 650 651 $Coordinate1-1$ $Coordinate1-2$ 652 $Coordinate2-1$ $Coordinate2-2$ 653 $Coordinate3-1$ ... 654 ... 655 $CoordinateN-1$ $CoordinateN-2$ 656 $Coordinate1-1$ $Coordinate1-2$ 657 658 659 660 662 GML Polygon Template 664 Alternatively, a series of "pos" elements can be used in place of the 665 single "posList". Each "pos" element contains two or three 666 coordinate values. 668 Note that the first point is repeated at the end of the sequence of 669 coordinates and no explicit count of the number of points is 670 provided. 672 A GML polygon that includes altitude cannot be represented perfectly 673 in TLV form. When converting to the binary representation, a two 674 dimensional CRS is used and altitude is removed from each coordinate. 676 A prism is represented in and converted from GML using the following 677 template: 679 682 683 684 685 686 687 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 688 $Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$ 689 $Coordinate2-1$ ... ... 690 ... 691 $CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$ 692 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 693 694 695 696 697 698 699 $Height$ 700 701 703 GML Prism Template 705 Alternatively, a series of "pos" elements can be used in place of the 706 single "posList". Each "pos" element contains three coordinate 707 values. 709 4.9.4.2. TLV Encoding 710 A polygon containing 2D points uses a type code of 119. A polygon 711 with 3D points uses a type code of 120. A prism uses a type code of 712 121. The number of points can be inferred from the length of the 713 TLV. 715 +------+------+ 716 |119-21|Length| 717 +------+------+------+------+ 718 | (3D-only) Height | 719 +------+------+------+------+ 720 | Coordinate1-1 | 721 +------+------+------+------+ 722 | Coordinate1-2 | 723 +------+------+------+------+ 724 | (3D-only) Coordinate1-3 | 725 +------+------+------+------+ 726 | Coordinate2-1 | 727 +------+------+------+------+ 728 ... 729 +------+------+------+------+ 730 | CoordinateN-1 | 731 +------+------+------+------+ 732 | CoordinateN-2 | 733 +------+------+------+------+ 734 | (3D-only) CoordinateN-3 | 735 +------+------+------+------+ 737 Polygon or Prism Encoding 739 Note that unlike the polygon representation in GML, the first and 740 last points are not the same point in the TLV representation. The 741 duplicated point is removed from the binary form. 743 4.9.5. Arc-Band Shape 745 A arc-band describes a region constrained by a range of angles and 746 distances from a predetermined point. This shape can only be 747 provided for a two-dimensional CRS. 749 Distance and angular measures are defined in meters and degrees 750 respectively. Both are encoded as single precision floating point 751 values. 753 4.9.5.1. XML encoding 755 An arc-band is represented in and converted from GML using the 756 following template: 758 761 $Coordinate-1$ $Coordinate-2$ 762 763 $Inner-Radius$ 764 765 766 $Outer-Radius$ 767 768 769 $Start-Angle$ 770 771 772 $Opening-Angle$ 773 774 776 GML Arc-Band Template 778 4.9.5.2. TLV Encoding 780 An arc-band is introduced by a type code of 122. 782 +------+------+ 783 | 122 |Length| 784 +------+------+------+------+ 785 | Coordinate | 786 +------+------+------+------+ 787 | Coordinate | 788 +------+------+------+------+------+------+------+------+ 789 | Inner Radius | Outer Radius | 790 +------+------+------+------+------+------+------+------+ 791 | Start Angle | Opening Angle | 792 +------+------+------+------+------+------+------+------+ 794 Arc-Band Encoding 796 4.10. Dynamic Location TLVs 798 Dynamic location elements use the definitions in [RFC5962]. 800 4.10.1. Orientation 802 The orientation of the target is described using one or two angles. 803 Orientation uses a type code of 123. 805 +------+------+ 806 | 123 |Length| 807 +------+------+------+------+ 808 | Angle | 809 +------+------+------+------+ 810 | (Optional) Angle | 811 +------+------+------+------+ 813 Dynamic Orientation TLVs 815 4.10.2. Speed 817 The speed of the target is a scalar value in meters per second. 818 Speed uses a type code of 124. 820 +------+------+ 821 | 124 |Length| 822 +------+------+------+------+ 823 | Speed | 824 +------+------+------+------+ 826 Dynamic Speed TLVs 828 4.10.3. Heading 830 The heading, or direction of travel, is described using one or two 831 angles. Heading uses a type code of 125. 833 +------+------+ 834 | 125 |Length| 835 +------+------+------+------+ 836 | Angle | 837 +------+------+------+------+ 838 | (Optional) Angle | 839 +------+------+------+------+ 841 Dynamic Heading TLVs 843 4.11. Secondary Map Metadata 845 The optional "map" URL can be used to provide a user of relative 846 location with a visual reference for the location information. This 847 document does not describe how the recipient uses the map nor how it 848 locates the reference or offset within the map. Maps can be simple 849 images, vector files, 2-D or 3-D geospatial databases, or any other 850 form of representation understood by both the sender and recipient. 852 4.11.1. Map URL 854 In XML, the map is a element defined within 855 and contains the URL. The URL is encoded as a UTF-8 encoded string. 856 An "http:" ([RFC2616]) or "https:" ([RFC2818]) URL MUST be used 857 unless the entity creating the PIDF-LO is able to ensure that 858 authorized recipients of this data are able to use other URI schemes. 859 A "type" attribute MUST be present and specifies the kind of map the 860 URL points to. Map types are specified as MIME media types as 861 recorded in the IANA Media Types registry. For example https://www.example.com/floorplans/123South/floor-2< 863 /map>. 865 In binary, the map type is a separate TLV from the map URL. The 866 media type uses a type code of 126; the URL uses a type code of 127. 868 +------+------+------+------+------+-- --+------+ 869 | 126 |Length| Map Media Type ... 870 +------+------+------+------+------+-- --+------+ 871 | 127 |Length| Map Image URL ... 872 +------+------+------+------+------+-- --+------+ 874 Map URL TLVs 876 Note that the binary form restricts data to 255 octets. This 877 restriction could be problematic for URLs in particular. 878 Applications that use the XML form, but cannot guarantee that a 879 binary form won't be used, are encouraged to limit the size of the 880 URL to fit within this restriction. 882 4.11.2. Map Coordinate Reference System 884 The CRS used by the map depends on the type of map. For example, a 885 map described by a 3-D geometric model of the building may contain a 886 complete CRS description in it. For some kinds of maps, typically 887 described as images, the CRS used within the map must define the 888 following: 890 o The CRS origin 891 o The CRS axes used and their orientation 893 o The unit of measure used 895 This document provides elements that allow for a mapping between the 896 local coordinate reference system used for the relative location and 897 the coordinate reference system used for the map where they are not 898 the same. 900 4.11.2.1. Map Reference Point Offset 902 This optional element identifies the coordinates of the reference 903 point as it appears in the map. This value is measured in a map-type 904 dependent manner, using the coordinate system of the map. 906 For image maps, coordinates start from the upper left corner and 907 coordinates are first counted by column with positive values to the 908 right; then rows are counted with positive values toward the bottom 909 of the image. For such an image, the first item is columns, the 910 second rows and any third value applies to any third dimension used 911 in the image coordinate space. 913 The element contains 2 (or 3) coordinates similar to a GML 914 "pos". For example: 916 2670.0 1124.0 1022.0 918 Map Reference Point Example XML 920 The map reference point uses a type code of 129. 922 +------+------+ 923 | 129 |Length| 924 +------+------+------+------+ 925 | Coordinate-1 | 926 +------+------+------+------+ 927 | Coordinate-2 | 928 +------+------+------+------+ 929 | (3D-only) Coordinate-3 | 930 +------+------+------+------+ 932 Map Reference Point Coordinates TLV 934 If omitted, a value containing all zeros is assumed. If the 935 coordinates provided contain fewer values than are needed, the first 936 value from the set is applied in place of any absent values. Thus, 937 if a single value is provided, that value is used for Coordinate-2 938 and Coordinate-3 (if required). If two values are provided and three 939 are required, the value of Coordinate-1 is used in place of 940 Coordinate-3. 942 4.11.2.2. Map Orientation 944 The map orientation includes the orientation of the map direction in 945 relation to the Earth. Map orientation is expressed relative to the 946 orientation of the relative coordinate system. This means that map 947 orientation with respect to WGS84 North is the sum of the orientation 948 field, plus any orientation included in a dynamic portion of the 949 reference location. Both values default to zero if no value is 950 specified. 952 This type uses a single precision floating point value of degrees 953 relative to North. 955 In XML, the element contains a single floating point 956 value, example 67.00. In TLV form map 957 orientation uses the code 130: 959 +------+------+------+------+------+------+ 960 | 130 |Length| Angle | 961 +------+------+------+------+------+------+ 963 Map Orientation TLV 965 4.11.2.3. Map Scale 967 The optional map scale describes the relationship between the units 968 of measure used in the map, relative to the meters unit used in the 969 relative coordinate system. 971 This type uses a sequence of IEEE 754 [IEEE.754] single precision 972 floating point values to represent scale as a sequence of numeric 973 values. The units of these values are dependent on the type of map, 974 and could for example be pixels per meter for an image. 976 A scaling factor is provided for each axis in the coordinate system. 977 For a two-dimensional coordinate system, two values are included to 978 allow for different scaling along the x and y axes independently. 979 For a three-dimensional coordinate system, three values are specified 980 for the x, y and z axes. Decoders can determine the number of 981 scaling factors by examining the length field. 983 Alternatively, a single scaling value MAY be used to apply the same 984 scaling factor to all coordinate components. 986 Images that use a rows/columns coordinate system often use a left- 987 handed coordinate system. A negative value for the y/rows-axis 988 scaling value can be used to account for any change in direction 989 between the y-axis used in the relative coordinate system and the 990 rows axis of the image coordinate system. 992 In XML, the element MAY contain a single scale value, or MAY 993 contain 2 (or 3) values in XML list form. In TLV form, scale uses a 994 type code of 131. The length of the TLV determines how many scale 995 values are present: 997 +------+------+------+------+------+------+ 998 | 131 |Length| Scale(s) ... 999 +------+------+------+------+------+------+ 1001 Map Scale TLV 1003 4.11.3. Map Example 1005 An example of expressing a map is: 1007 1008 1009 http://example.com/map.jpg 1010 1011 200 210 1012 68 1013 2.90 -2.90 1014 1016 Map Example 1018 5. Examples 1020 The examples in this section combine elements from [RFC3863], 1021 [RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape]. 1023 5.1. Civic PIDF with Polygon Offset 1025 1033 1034 1035 1036 1037 AU 1038 NSW 1039 Wollongong 1040 North Wollongong 1041 Flinders 1042 Street 1043 123 1044 1045 1046 1047 1048 Front Door 1049 A 1050 I 1051 113 1052 1053 1054 1055 1057 1058 1059 433.0 -734.0 1060 431.0 -733.0 1061 431.0 -732.0 1062 433.0 -731.0 1063 434.0 -732.0 1064 434.0 -733.0 1065 433.0 -734.0 1066 1067 1068 1069 1070 1071 1072 1073 GPS 1074 1075 mac:1234567890ab 1076 2007-06-22T20:57:29Z 1077 1078 1080 5.2. Geo PIDF with Circle Offset 1082 1083 1090 1091 1092 1093 1094 -34.407 150.883 1095 1096 50.0 1097 1098 1099 1100 1101 1102 -34.407 150.883 1103 1104 1105 1106 1108 500.0 750.0 1109 1110 5.0 1111 1112 1113 1114 1115 1116 https://www.example.com/flrpln/123South/flr-2 1117 1118 2670.0 1124.0 1022.0 1119 67.00 1120 10 -10 1121 1122 1123 1124 1125 Wiremap 1126 1127 mac:1234567890ab 1128 2007-06-22T20:57:29Z 1129 1130 1132 5.3. Civic TLV with Point Offset 1134 +--------+-------------------------------------------------+ 1135 | Type | Value | 1136 +--------+-------------------------------------------------+ 1137 | 0 | en | 1138 | | | 1139 | 1 | IL | 1140 | | | 1141 | 3 | Chicago | 1142 | | | 1143 | 34 | Wacker | 1144 | | | 1145 | 18 | Drive | 1146 | | | 1147 | 19 | 3400 | 1148 | | | 1149 | 112 | Reference | 1150 | | | 1151 | 25 | Building A | 1152 | | | 1153 | 27 | Floor 6 | 1154 | | | 1155 | 26 | Suite 213 | 1156 | | | 1157 | 28 | Reception Area | 1158 | | | 1159 | 115 | 100 70 | 1160 | | | 1161 | 126 | image/png | 1162 | | | 1163 | 127 | http://maps.example.com/3400Wacker/A6 | 1164 | | | 1165 | 129 | 0.0 4120.0 | 1166 | | | 1167 | 130 | 113.0 | 1168 | | | 1169 | 131 | 10.6 | 1170 +--------+-------------------------------------------------+ 1172 6. Schema Definition 1173 Note: The pattern value for "mimeType" has been folded onto multiple 1174 lines. Whitespace has been added to conform to comply with 1175 document formatting restrictions. Extra whitespace around the 1176 line endings MUST be removed before using this schema. 1178 1179 1187 1191 1192 1194 Relative Location for PIDF-LO 1195 1196 1197 This schema defines a location representation that allows for 1198 the description of locations that are relative to another. 1199 An optional map reference is also defined. 1200 1201 1203 1205 1207 1208 1209 1210 1211 1212 1213 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1226 1227 1228 1229 1231 1232 1233 1234 1235 1236 1238 1239 1240 1241 1243 1244 1245 1246 1247 1248 1249 1251 1253 1255 1256 1257 1258 1260 1261 1262 1263 1265 1266 1267 1268 1269 1270 1274 1275 1277 1278 1279 1281 1283 xml schema relative-location 1285 7. Security Considerations 1287 This document describes a data format. To a large extent, security 1288 properties of this depend on how this data is used. 1290 Privacy for location data is typically important. Adding relative 1291 location may increase the precision of the location, but does not 1292 otherwise alter its privacy considerations, which are discussed in 1293 [RFC4119]. 1295 The map URL provided in a relative location could accidentally reveal 1296 information if a Location Recipient uses the URL to acquire the map. 1297 The coverage area of a map, or parameters of the URL itself, could 1298 provide information about the location of a Target. In combination 1299 with other information that could reveal the set of potential Targets 1300 that the Location Recipient has location information for, acquiring a 1301 map could leak significant information. In particular, it is 1302 important to note that the Target and Location Recipient are often 1303 the same entity. 1305 Access to map URLs MUST be secured with TLS [RFC5246] (that is, 1306 restricting the map URL to be an https URI), unless the map URL 1307 cannot leak information about the Target's location. This restricts 1308 information about the map URL to the entity serving the map request. 1309 If the map URL conveys more information about a target than a map 1310 server is authorized to receive, that URL MUST NOT be included in the 1311 PIDF-LO. 1313 8. IANA Considerations 1314 8.1. Relative Location Registry 1316 This document creates a new registry called "Relative Location 1317 Parameters". This shares a page, entitled "Civic and Relative 1318 Location Parameters" with the existing "Civic Address Types Registry 1319 (CAtypes)" registry. As defined in [RFC5226], this new registry 1320 operates under "IETF Review" rules. 1322 The content of this registry includes: 1324 Relative Location Code: Numeric identifier, assigned by IANA. 1326 Brief description: Short description identifying the meaning of the 1327 element. 1329 Reference to published specification: A stable reference to an RFC 1330 which describes the value in sufficient detail so that 1331 interoperability between independent implementations is possible. 1333 Values requested to be assigned into this registry MUST NOT conflict 1334 with values assigned in the "Civic Address Types Registry (CAtypes)" 1335 registry or vice versa, unless the IANA considerations section for 1336 the new value explicitly overrides this prohibition and the document 1337 defining the value describes how conflicting TLV codes will be 1338 interpreted by implementations. To ensure this, the CAtypes entries 1339 are explicitly reserved in the initial values table below. Those 1340 reserved entries can be changed, but only with caution as explained 1341 here. 1343 To make this clear for future users of the registry, the following 1344 note is added to the "Civic Address Types Registry (CAtypes)": The 1345 registration of new values should be accompanied by a corresponding 1346 reservation in the "Relative Location Parameters" registry. 1347 Similarly, the "Relative Location Parameters" registry bears the 1348 note: The registration of new values should be accompanied by a 1349 corresponding reservation in the "Civic Address Types Registry 1350 (CAtypes)" registry. 1352 The values defined are: 1354 +--------+----------------------------------------+-----------+ 1355 | RLtype | description | Reference | 1356 +--------+----------------------------------------+-----------+ 1357 | 0-40 | RESERVED by CAtypes registry | this RFC | 1358 | 128 | | & RFC4776 | 1359 +--------+----------------------------------------+-----------+ 1360 | 111 | relative location reference | this RFC | 1361 | 113 | relative location shape 2D point | this RFC | 1362 | 114 | relative location shape 3D point | this RFC | 1363 | 115 | relative location shape circular | this RFC | 1364 | 116 | relative location shape spherical | this RFC | 1365 | 117 | relative location shape elliptical | this RFC | 1366 | 118 | relative location shape ellipsoid | this RFC | 1367 | 119 | relative location shape 2D polygon | this RFC | 1368 | 120 | relative location shape 3D polygon | this RFC | 1369 | 121 | relative location shape prism | this RFC | 1370 | 122 | relative location shape arc-band | this RFC | 1371 | 123 | relative location dynamic orientation | this RFC | 1372 | 124 | relative location dynamic speed | this RFC | 1373 | 125 | relative location dynamic heading | this RFC | 1374 | 126 | relative location map type | this RFC | 1375 | 127 | relative location map URI | this RFC | 1376 | 129 | relative location map coordinates | this RFC | 1377 | 130 | relative location map angle | this RFC | 1378 | 131 | relative location map scale | this RFC | 1379 +--------+----------------------------------------+-----------+ 1381 8.2. URN Sub-Namespace Registration 1383 This document registers a new XML namespace, as per the guidelines in 1384 [RFC3688]). 1386 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative 1388 Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org), 1389 Martin Thomson (martin.thomson@skype.net). 1391 XML: 1393 BEGIN 1394 1395 1397 1398 1399 GEOPRIV Relative Location 1400 1401 1402

Format for representing relative location

1403

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

1404

See 1405 RFCXXXX.

1406 1407 1408 1413 END 1415 8.3. XML Schema Registration 1417 This section registers an XML schema as per the procedures in 1418 [RFC3688]. 1420 URI: urn:ietf:params:xml:schema:pidf:geopriv10:relative 1422 Registratant Contact: IETF, GEOPRIV working group 1423 (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net). 1425 Schema The XML for this schema is found in Section 6 of this 1426 document. 1428 8.4. Geopriv Identifiers Registry 1430 This section registers two URNs for use in identifying relative 1431 coordinate reference systems. These are added to a new "Geopriv 1432 Identifiers" registry according to the procedures in Section 4 of 1433 [RFC3553]. The "Geopriv Identifiers" registry is entered under the 1434 "Uniform Resource Name (URN) Namespace for IETF Use" category. 1436 Registrations in this registry follow the IETF Review [RFC5226] 1437 policy. 1439 Registry name: Geopriv Identifiers 1441 URN Prefix: urn:ietf:params:geopriv: 1443 Specification: RFCXXXX (this document) 1445 Respository: [Editor/IANA note: please include a link to the 1446 registry location.] 1448 Index value: Values in this registry are URNs or URN prefixes that 1449 start with the prefix "urn:ietf:params:geopriv:". Each is 1450 registered independently. 1452 Each registration in the "Geopriv Identifiers" registry requires the 1453 following information: 1455 URN The complete URN that is used, or the prefix for that URN. 1457 Description: A summary description for the URN or URN prefix. 1459 Specification: A reference to a specification describing the URN or 1460 URN prefix. 1462 Contact: Email for the person or groups making the registration. 1464 Index value: As described in [RFC3553], URN prefixes that are 1465 registered include a description of how the URN is constructed. 1466 This is not applicable for specific URNs. 1468 The "Geopriv Identifiers" registry has two initial registrations, 1469 included in the following sections. 1471 8.4.1. Registration of Two-Dimentional Relative Coordinate Reference 1472 System URN 1474 This section registers the "urn:ietf:params:geopriv:relative:2d" URN 1475 in the "Geopriv Identifiers" registry. 1477 URN urn:ietf:params:geopriv:relative:2d 1479 Description: A two-dimensional relative coordinate reference system 1481 Specification: RFCXXXX (this document) 1483 Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin 1484 Thomson (martin.thomson@skype.net). 1486 Index value: N/A. 1488 8.4.2. Registration of Three-Dimentional Relative Coordinate Reference 1489 System URN 1491 This section registers the "urn:ietf:params:geopriv:relative:3d" URN 1492 in the "Geopriv Identifiers" registry. 1494 URN urn:ietf:params:geopriv:relative:3d 1496 Description: A three-dimensional relative coordinate reference 1497 system 1499 Specification: RFCXXXX (this document) 1501 Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin 1502 Thomson (martin.thomson@skype.net). 1504 Index value: N/A. 1506 9. Acknowledgements 1508 This is the product of a design team on relative location. Besides 1509 the authors, this team included: Marc Linsner, James Polk, and James 1510 Winterbottom. 1512 10. References 1514 10.1. Normative References 1516 [RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation 1517 standard", RFC 1014, June 1987. 1519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1520 Requirement Levels", BCP 14, RFC 2119, March 1997. 1522 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1523 Extensions (MIME) Part Two: Media Types", RFC 2046, 1524 November 1996. 1526 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1527 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1528 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1530 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1532 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1533 IETF URN Sub-namespace for Registered Protocol 1534 Parameters", BCP 73, RFC 3553, June 2003. 1536 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1537 January 2004. 1539 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1540 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1541 3986, January 2005. 1543 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1544 Format", RFC 4119, December 2005. 1546 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1547 (DHCPv4 and DHCPv6) Option for Civic Addresses 1548 Configuration Information", RFC 4776, November 2006. 1550 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1551 Format for Presence Information Data Format Location 1552 Object (PIDF-LO)", RFC 5139, February 2008. 1554 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1555 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1556 May 2008. 1558 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1559 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1561 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1562 Presence Information Data Format Location Object (PIDF-LO) 1563 Usage Clarification, Considerations, and Recommendations", 1564 RFC 5491, March 2009. 1566 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 1567 Thomson, "Dynamic Extensions to the Presence Information 1568 Data Format Location Object (PIDF-LO)", RFC 5962, 1569 September 2010. 1571 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 1572 Host Configuration Protocol Options for Coordinate-Based 1573 Location Configuration Information", RFC 6225, July 2011. 1575 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 1576 R. George, "Specifying Civic Address Extensions in the 1577 Presence Information Data Format Location Object (PIDF- 1578 LO)", RFC 6848, January 2013. 1580 [OGC.GML-3.1.1] 1581 Cox, S., Daisey, P., Lake, R., Portele, C., and A. 1582 Whiteside, "Geographic information - Geography Markup 1583 Language (GML)", OpenGIS 03-105r1, April 2004, . 1586 [OGC.GeoShape] 1587 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 1588 Application Schema for use by the Internet Engineering 1589 Task Force (IETF)", OGC Best Practice 06-142r1, Version: 1590 1.0, April 2007. 1592 [IEEE.754] 1593 IEEE, "IEEE Standard for Binary Floating-Point 1594 Arithmetic", IEEE Standard 754-1985, January 2003. 1596 [Clinger1990] 1597 Clinger, W., "How to Read Floating Point Numbers 1598 Accurately", Proceedings of Conference on Programming 1599 Language Design and Implementation pp. 92-101, 1990, . 1602 [WGS84] US National Imagery and Mapping Agency, "Department of 1603 Defense (DoD) World Geodetic System 1984 (WGS 84), Third 1604 Edition ", NIMA TR8350.2, January 2000. 1606 10.2. Informative References 1608 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1609 W., and J. Peterson, "Presence Information Data Format 1610 (PIDF)", RFC 3863, August 2004. 1612 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 1613 2006. 1615 Authors' Addresses 1617 Martin Thomson 1618 Microsoft 1619 3210 Porter Drive 1620 Palo Alto, CA 94304 1621 US 1623 Phone: +1 650-353-1925 1624 EMail: martin.thomson@skype.net 1626 Brian Rosen 1627 Neustar 1628 470 Conrad Dr 1629 Mars, PA 16046 1630 US 1632 EMail: br@brianrosen.net 1634 Dorothy Stanley 1635 Aruba Networks 1636 1322 Crossman Ave 1637 Sunnyvale, CA 94089 1638 US 1640 EMail: dstanley@arubanetworks.com 1641 Gabor Bajko 1642 Nokia 1643 323 Fairchild Drive 1644 Mountain View, CA 94043 1645 US 1647 EMail: gabor.bajko@nokia.com 1649 Allan Thomson 1650 Cisco Systems, Inc. 1651 170 West Tasman Drive 1652 San Jose, CA 95134 1653 US 1655 EMail: althomso@cisco.com