idnits 2.17.1 draft-ietf-ecrit-specifying-holes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 174 has weird spacing: '...x Hole t ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ecrit-lost-sync' is defined on line 430, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ecrit-lost-sync-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: BCP Andrew Corporation 5 Expires: September 9, 2010 March 8, 2010 7 Specifying Holes in LoST Service Boundaries 8 draft-ietf-ecrit-specifying-holes-02 10 Abstract 12 This document describes how holes can be specified in geodetic 13 service boundaries. One means of implementing a search solution in a 14 service database, such as one might provide with a LoST server, is 15 described. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 9, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9 62 6. Service Boundary Specification and Selection Algorithm . . . . 10 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 68 10.2. Informative References . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 71 1. Introduction 73 The LoST protocol [RFC5222] describes a protocol that's primary 74 purpose is to map service and locations to destination addresses. 75 LoST does this by provisioning boundary maps or areas against service 76 URNs. The boundary is a polygon made up of sets of geodetic 77 coordinates specifying an enclosed area. In some circumstances an 78 area enclosed by a polygon, also known as an exterior polygon, may 79 contain exception areas, or holes, that for the same service must 80 yield a different destination to that described by the larger area. 81 This document describes how holes SHOULD be specified in service 82 boundaries defined using a GML encoding for the polygons and their 83 internal elements (holes). GML polygons are based on elements 84 defined in [ISO-19107]. 86 o--------------o 87 / \ 88 / /\ \ 89 / + +-----+ \ 90 o | Hole \ o 91 | | 1 / | 92 | +-------+ |<--- Primary Polygon 93 | +-------+ | 94 | / Hole | | 95 o \ 2 | o 96 \ +-----+ + / 97 \ \/ / 98 \ / 99 o--------------o 101 Figure 1: Holes in a Polygon 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Specifying Holes 111 Holes related to an exterior boundary polygon MUST adhere to the 112 following rules: 114 Rule 1: Two holes MUST NOT have more than one point of 115 intersection. If two or more holes share a common set of 116 boundaries then to the primary polygon these represent a 117 single hole in the service. The internal elements (holes) 118 should have common boundaries removed and a single hole 119 created irrespective of whether the excluded area is itself 120 made up of multiple service boundaries. 122 o--------------o o--------------o 123 / \ / \ 124 / /\ \ / /\ \ 125 / + +-----+ \ / + +-----+ \ 126 o | Hole \ o o | \ o 127 | | 1 \ | | | One \ | 128 | +-+-------+ | =========> | +-+ Hole + | 129 | / Hole | | | / | | 130 o \ 2 | o o \ | o 131 \ +-----+ + / \ +-----+ + / 132 \ \/ / \ \/ / 133 \ / \ / 134 o--------------o o--------------o 136 Incorrect Correct 138 Figure 2: Incorrect Hole Specification with Boundary Sharing 140 Rule 2: A hole MUST NOT have more than one point of intersection 141 with the outer-boundary of the primary (exterior) polygon. 142 If more than one point of intersection occurs the primary 143 polygon is either doesn't have a hole, it has an inlet as 144 in Figure 3, or the primary polygon SHOULD be expressed as 145 two polygons as in Figure 4. 147 +------- Inlet 148 | 149 v 150 o---+-----+----o o---o o----o 151 / |%%%%%| \ / | | \ 152 / /%%%%%%| \ / / | \ 153 / +%%%%%%%| \ / o o \ 154 o |%%%%%%%%\ o o | \ o 155 | |%%%%%%%%%\ | | | \ | 156 | +-+%%%%%%%%+ | ========> | o-o o | 157 | /%%%%%%%%| | | / | | 158 o \%%%%%%%%| o o \ | o 159 \ +-----+ + / \ o-----o o / 160 \ \/ / \ \/ / 161 \ / \ / 162 o--------------o o--------------o 164 Incorrect Correct 166 Figure 3: Correct Specification of an Inlet 168 A--q-----------B A-q q----------B 169 / | | \ / | | \ 170 / | | \ / | | \ 171 / z r-----s \ / P z r-----s P \ 172 H | \ C H o | \ o C 173 | | One \ | | l | \ l | 174 | y-x Hole t | ========> | y y-x t y | 175 | / | | | g / | g | 176 G \ | D G o \ | o D 177 \ / v---u / \ n / v---u n / 178 \ \ / / \ 1 \ / 2 / 179 \ \ / / \ \ / / 180 F-----w--------E F-----w w--------E 182 1 Polgon with a 2 Polygons that map 183 Dividing Hole to the same service 185 Figure 4: Correct Specification of Hole with Multiple Outer-Boundary 186 Intersections 188 Similarly, a polygon containing a hole with an island must be 189 represented as two polygons mapping to the same service. 191 Rule 3: A hole MUST be a legal polygon in accordance with the 192 geoshape specification [geoshape]. There is no restriction 193 on the number of points that may be used to express the 194 perimeter of the hole. 196 4. GML Polygons 198 The GML encoding of a polygon defines a enclosed exterior boundary, 199 with the first and last points of boundary being the same. Consider 200 the example in Figure 5. 202 B--------------C 203 / \ 204 / \ 205 / \ 206 A D 207 \ / 208 \ / 209 \ / 210 F--------------E 212 213 214 215 43.311 -73.422 216 43.111 -73.322 217 43.111 -73.222 218 43.311 -73.122 219 43.411 -73.222 220 43.411 -73.322 221 43.311 -73.422 222 223 224 226 Figure 5: Hexagon and Associated GML 228 Note that polygon vertices in Figure 5 are expressed using 229 elements for clarity. The vertices can also be expressed using a 230 element. 232 5. Holes in GML Polygons 234 A hole is specified in the polygon by defining an interior boundary. 235 The points defining the internal boundary define the area represented 236 by the hole in the primary (exterior) polygon. The shaded area in 237 Figure 6 is represented by the 4 points of the interior boundary 238 specified by (w,z,y,x). 240 F-------------E 241 / \ 242 / w-------------x \ 243 / |/////////////| \ 244 A |/////////////| D 245 \ |/////////////| / 246 \ z-------------y / 247 \ / 248 B-------------C 250 251 252 253 43.311 -73.422 254 43.111 -73.322 255 43.111 -73.222 256 43.311 -73.122 257 43.511 -73.222 258 43.511 -73.322 259 43.311 -73.422 260 261 262 263 264 43.411 -73.322 265 43.411 -73.222 266 43.211 -73.222 267 43.211 -73.322 268 43.411 -73.322 269 270 271 273 Figure 6: Hexagon with Hole 275 Interior parts are specified in clockwise direction, such that the 276 upward normal is opposite to the upward normal of the exterior part. 278 6. Service Boundary Specification and Selection Algorithm 280 A service boundary is represented by a polygon that may have many 281 vertices. The enclosed area of the polygon represents the area in 282 which a service, expressed as a service URN, maps to a single URI. 284 Figure 6 is used to illustrate two service boundaries. The first 285 service boundary A->F shall be referred to as area-A, and the second 286 service boundary w->z shall be referred to as area-w. Furthermore, 287 area-A is directly represented by the GML encoding provided in 288 Figure 6. Area-w is represented as a hole in area-A by the interior 289 boundary. Since area-w is also a service boundary, a separate 290 polygon describing this area is also required and is shown in 291 Figure 7 (note the reversal of the vertices). 293 294 295 296 43.411 -73.322 297 43.211 -73.322 298 43.211 -73.222 299 43.411 -73.222 300 43.411 -73.322 301 302 303 305 Figure 7: GML for Area-w 307 If this data were in a LoST server the data mappings may look similar 308 to the example in Figure 8. This is an example only and does not 309 represent actual LoST server provisioning or data transfer records. 310 The example XML will not complie. 312 317 Outer Area Police 318 urn:service:sos.police 319 320 322 323 324 43.311 -73.422 325 43.111 -73.322 326 43.111 -73.222 327 43.311 -73.122 328 43.511 -73.222 329 43.511 -73.322 330 43.311 -73.422 331 332 333 334 335 336 43.411 -73.322 337 43.211 -73.322 338 43.211 -73.222 339 43.411 -73.222 340 43.411 -73.322 341 342 343 344 345 sip:area-A-pd@example.com 346 xmpp:area-A-pd@example.com 347 000 348 349 354 Inner Area Police 355 urn:service:sos.police 356 357 359 360 361 43.411 -73.322 362 43.211 -73.322 363 43.211 -73.222 364 43.411 -73.222 365 43.411 -73.322 366 367 368 369 370 sip:area-w-pd@example.com 371 xmpp:area-w-pd@example.com 372 000 374 376 Figure 8: Service Boundary Specifications 378 It is considered likely that LoST servers will need to provide 379 responses sufficiently quickly to allow real-time queries to be 380 performed as part of an emergency call routing flow. It is for this 381 reason that databases supporting native geospatial query techniques 382 are desirable and that service boundary specifications that are 383 easily mapped to internal data structures are preferred. Using 384 interior boundaries makes support for this operation easy, while 385 allowing an arbitrary number of holes in a service boundary to be 386 specified. 388 Each polygon is stored in the geospatial database and mapped to a 389 service URN and destination URI. Many geospatial databases natively 390 support polygons with interior exclusions. Without native support, 391 interior boundaries can be stored against the polygon and can checked 392 separately. A location falls within the area described by a polygon 393 if it is within the exterior boundary and not within any interior 394 boundary. 396 7. Security Considerations 398 This document does not introduce any security issues. 400 8. IANA Considerations 402 There are no specific IANA considerations for this document. 404 9. Acknowledgements 406 Thanks to Carl Reed for input provided to the list some months back 407 and for reviewing this document. Thanks to Michael Haberler for 408 suggesting that such a specification is required. Thanks to Avery 409 Penniston for review and feedback. 411 10. References 413 10.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 419 Tschofenig, "LoST: A Location-to-Service Translation 420 Protocol", RFC 5222, August 2008. 422 [geoshape] 423 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 424 Application Schema for use by the Internet Engineering 425 Task Force (IETF)", Candidate OpenGIS Implementation 426 Specification 06-142r1, Version: 1.0, April 2007. 428 10.2. Informative References 430 [I-D.ietf-ecrit-lost-sync] 431 Schulzrinne, H. and H. Tschofenig, "Synchronizing 432 Location-to-Service Translation (LoST) Protocol based 433 Service Boundaries and Mapping Elements", 434 draft-ietf-ecrit-lost-sync-09 (work in progress), 435 March 2010. 437 [ISO-19107] 438 ISO, "Geographic information - Spatial Schema", ISO 439 Standard 19107, First Edition, 5 2003. 441 Authors' Addresses 443 James Winterbottom 444 Andrew Corporation 445 Andrew Building (39) 446 Wollongong University Campus 447 Northfields Avenue 448 Wollongong, NSW 2522 449 AU 451 Email: james.winterbottom@andrew.com 453 Martin Thomson 454 Andrew Corporation 455 Andrew Building (39) 456 Wollongong University Campus 457 Northfields Avenue 458 Wollongong, NSW 2522 459 AU 461 Email: martin.thomson@andrew.com