idnits 2.17.1 draft-winterbottom-ecrit-specifying-holes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 496. 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 Copyright Line does not match the current year == Line 163 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 (October 11, 2007) is 6036 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) == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-06 == Outdated reference: A later version (-01) exists of draft-schulzrinne-ecrit-lost-sync-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Best Current Andrew Corporation 5 Practice October 11, 2007 6 Expires: April 13, 2008 8 Specifying Holes in LoST Service Boundaries 9 draft-winterbottom-ecrit-specifying-holes-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 13, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how holes can be specified in service 43 boundaries. One means of implementing a solution is described. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9 52 6. Service Boundary Specification and Selection Algorithm . . . . 10 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 55 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 57 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 58 10.2. Informative References . . . . . . . . . . . . . . . . . 16 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 60 Intellectual Property and Copyright Statements . . . . . . . . . . 18 62 1. Introduction 64 The LoST protocol [I-D.ietf-ecrit-lost] describes a protocol that's 65 primary purpose is to map service and locations to destination 66 addresses. LoST does this by provisioning boundary maps or areas 67 against service URNs. The boundary is a polygon made up of sets of 68 geodetic coordinates specifying an enclosed area. In some 69 circumstances an area enclosed by a polygon, also known as an 70 exterior polygon, may contain exception areas, or holes, that for the 71 same service must yield a different destination to that described by 72 the larger area. This document describes how holes SHOULD be 73 specified in service boundaries defined using a GML encoding for the 74 polygons and their internal elements (holes). GML polygons are based 75 on elements defined in [ISO-19107]. 77 o-------------o 78 / \ 79 / /\ \ 80 / + +-----+ \ 81 o | Hole \ o 82 | | 1 / | 83 | +-------+ |<--- Primary Polygon 84 | +-------+ | 85 | / Hole | | 86 o \ 2 | o 87 \ +-----+ + / 88 \ \/ / 89 \ / 90 o--------------o 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Specifying Holes 100 Holes related to an exterior boundary polygon MUST adhere to the 101 following rules: 103 Rule 1: Two holes MUST NOT have more than one point of 104 intersection. If two or more holes share a common set of 105 boundaries then to the primary polygon these represent a 106 single hole in the service. The internal elements (holes) 107 should have common boundaries removed and a single hole 108 created irrespective of whether the excluded area is itself 109 made up of multiple service boundaries. 111 o-------------o o-------------o 112 / \ / \ 113 / /\ \ / /\ \ 114 / + +-----+ \ / + +-----+ \ 115 o | Hole \ o o | \ o 116 | | 1 \ | | | One \ | 117 | +-+-------+ | =========> | +-+ Hole + | 118 | / Hole | | | / | | 119 o \ 2 | o o \ | o 120 \ +-----+ + / \ +-----+ + / 121 \ \/ / \ \/ / 122 \ / \ / 123 o--------------o o--------------o 125 Incorrect Correct 127 Incorrect Hole Specification with Boundary Sharing 129 Rule 2: A hole MUST NOT have more than one point of intersection 130 with the outer-boundary of the primary (exterior) polygon. 131 If more than one point of intersection occurs the primary 132 polygon is either doesn't have a hole, it has an inlet as 133 in Figure 3, or the primary polygon SHOULD be expressed as 134 two polygons as in Figure 4. 136 +------- Inlet 137 | 138 v 139 o--+-----+----o o--o o----o 140 / |%%%%%| \ / | | \ 141 / /%%%%%%| \ / / | \ 142 / +%%%%%%%| \ / o o \ 143 o |%%%%%%%%\ o o | \ o 144 | |%%%%%%%%%\ | | | \ | 145 | +-+%%%%%%%%+ | ========> | o-o o | 146 | /%%%%%%%%| | | / | | 147 o \%%%%%%%%| o o \ | o 148 \ +-----+ + / \ o-----o o / 149 \ \/ / \ \/ / 150 \ / \ / 151 o--------------o o--------------o 153 Incorrect Correct 155 Figure 3: Correct Specification of an Inlet 157 A--q-----------B A-q q----------B 158 / | | \ / | | \ 159 / | | \ / | | \ 160 / z r-----s \ / P z r-----s P \ 161 H | \ C H o | \ o C 162 | | One \ | | l | \ l | 163 | y-x Hole t | ========> | y y-x t y | 164 | / | | | g / | g | 165 G \ | D G o \ | o D 166 \ / v---u / \ n / v---u n / 167 \ \ / / \ 1 \ / 2 / 168 \ \ / / \ \ / / 169 F-----w--------E F-----w w--------E 171 1 Polgon with a 2 Polygons that map 172 Dividing Hole to the same service 174 Figure 4: Correct Specification of Hole with Multiple Outer-Boundary 175 Intersections 177 Similarly, a polygon containing a hole with an island must be 178 represented as two polygons mapping to the same service. 180 Rule 3: A hole MUST be a legal polygon in accordance with the 181 geoshape specification [geoshape]. There is no restriction 182 on the number of points that may be used to express the 183 perimeter of the hole. 185 4. GML Polygons 187 The GML encoding of a polygon defines a enclosed exterior boundary, 188 with the first and last points of boundary being the same. Consider 189 the example in Figure 5. 191 B-------------C 192 / \ 193 / \ 194 / \ 195 A D 196 \ / 197 \ / 198 \ / 199 F--------------E 201 202 203 204 43.311 -73.422 205 43.111 -73.322 206 43.111 -73.222 207 43.311 -73.122 208 43.411 -73.222 209 43.411 -73.322 210 43.311 -73.422 211 212 213 215 Figure 5: Hexagon and Associated GML 217 NOTE that polygon vertices in Figure 5 are expressed using 218 elements for clarity. The vertices can also be expressed using a 219 element. 221 5. Holes in GML Polygons 223 A hole is specified in the polygon by defining an interior boundary. 224 The points defining the internal boundary define the area represented 225 by the hole in the primary (exterior) polygon. The shaded area in 226 Figure 6 is represented by the 4 points of the interior boundary 227 specified in Figure 7. 229 B-------------C 230 / \ 231 / w-------------x \ 232 / |/////////////| \ 233 A |/////////////| D 234 \ |/////////////| / 235 \ z-------------y / 236 \ / 237 F-------------E 239 Figure 6: Hexagon with Hole 241 242 243 244 43.311 -73.422 245 43.111 -73.322 246 43.111 -73.222 247 43.311 -73.122 248 43.511 -73.222 249 43.511 -73.322 250 43.311 -73.422 251 252 253 254 255 43.411 -73.322 256 43.211 -73.322 257 43.211 -73.222 258 43.411 -73.222 259 43.411 -73.322 260 261 262 264 Figure 7: GML for Hexagon with Hole 266 6. Service Boundary Specification and Selection Algorithm 268 A service boundary is represented by a polygon that may have many 269 vertices. The enclosed area of the polygon represents the area in 270 which a service, expressed as a service URN, maps to a single URI. 271 [I-D.schulzrinne-ecrit-lost-sync] describes how LoST servers may 272 synchronize with one another and provides examples of possible 273 boundary exchanges and data formats. At the time of writing there is 274 no standard format for service provisioning data into a LoST server, 275 the format described in [I-D.schulzrinne-ecrit-lost-sync] is used for 276 the example in this section. 278 Figure 6 shall be used to illustrate two service boundaries. The 279 first service boundary A->F shall be referred to as area-A, and the 280 second service boundary w->z shall be referred to as area-w. Further 281 more area-A is directly represented by the GML encoding provided in 282 Figure 7. Area-w is represented as a hole in area-A by the interior 283 boundary. Since area-w is also a service boundary, a separate 284 polygon describing this area is also required and is shown in 285 Figure 8. 287 288 289 290 43.411 -73.322 291 43.211 -73.322 292 43.211 -73.222 293 43.411 -73.222 294 43.411 -73.322 295 296 297 299 Figure 8: GML for Area-w 301 If this data were in a LoST server and was required in a neighbouring 302 LoST server, the data transfer using the format in 303 [I-D.schulzrinne-ecrit-lost-sync] would look similar to Figure 9. 305 306 307 308 311 312 Outer Area Police Department 313 314 urn:service:sos.police 315 316 317 318 319 43.311 -73.422 320 43.111 -73.322 321 43.111 -73.222 322 43.311 -73.122 323 43.511 -73.222 324 43.511 -73.322 325 43.311 -73.422 326 327 328 329 330 43.411 -73.322 331 43.211 -73.322 332 43.211 -73.222 333 43.411 -73.222 334 43.411 -73.322 335 336 337 338 339 sip:area-A-pd@example.com 340 xmpp:area-A-pd@example.com 341 000 342 343 346 347 Inner Area Police Department 348 349 urn:service:sos.police 350 351 352 353 354 43.411 -73.322 355 43.211 -73.322 356 43.211 -73.222 357 43.411 -73.222 358 43.411 -73.322 360 361 362 363 364 sip:area-w-pd@example.com 365 xmpp:area-w-pd@example.com 366 000 367 368 369 371 Figure 9: Service Boundary Specifications 373 It is considered likely that LoST servers will need to provide 374 responses sufficiently quickly to allow real-time queries to be 375 performed as part of an emergency call routing flow. It is for this 376 reason that databases supporting native geospatial query techniques 377 are desirable and that service boundary specifications that are 378 easily mapped to internal data structures are preferred. The format 379 described in this memo makes support for this operation easy, while 380 allowing an arbitrary number of holes in a service boundary to be 381 specified. 383 Each primary polygon is stored in the geospatial database and mapped 384 to a service URN and destination URI. Holes may be stored as 385 polygons in a separate table and mapped to the primary polygon. When 386 a location is found to map to a polygon, the exceptions table can be 387 checked to see if the primary polygon contains any coverage holes. 388 In general no holes will exist for a service boundary, so this check 389 results in almost no overhead and the service mapping can be 390 returned. Where one or more holes are found to exist, the provided 391 location is checked against each hole. If the location is found to 392 exist in one of the specified holes then the primary polygon can be 393 discarded, and searching of the service boundary database can 394 continue. 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 also to Michael Haberler for 408 suggesting that such a specification is required. 410 10. References 412 10.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [I-D.ietf-ecrit-lost] 418 Hardie, T., "LoST: A Location-to-Service Translation 419 Protocol", draft-ietf-ecrit-lost-06 (work in progress), 420 August 2007. 422 [I-D.schulzrinne-ecrit-lost-sync] 423 Schulzrinne, H., "Synchronizing Location-to-Service 424 Translation (LoST) Servers", 425 draft-schulzrinne-ecrit-lost-sync-00 (work in progress), 426 November 2006. 428 [geoshape] 429 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 430 Application Schema for use by the Internet Engineering 431 Task Force (IETF)", Candidate OpenGIS Implementation 432 Specification 06-142r1, Version: 1.0, April 2007. 434 10.2. Informative References 436 [ISO-19107] 437 ISO, "Geographic information - Spatial Schema", ISO 438 Standard 19107, First Edition, 5 2003. 440 Authors' Addresses 442 James Winterbottom 443 Andrew Corporation 444 PO Box U40 445 University of Wollongong, NSW 2500 446 AU 448 Email: james.winterbottom@andrew.com 450 Martin Thomson 451 Andrew Corporation 452 PO Box U40 453 University of Wollongong, NSW 2500 454 AU 456 Email: martin.thomson@andrew.com 458 Full Copyright Statement 460 Copyright (C) The IETF Trust (2007). 462 This document is subject to the rights, licenses and restrictions 463 contained in BCP 78, and except as set forth therein, the authors 464 retain all their rights. 466 This document and the information contained herein are provided on an 467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 469 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 470 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 471 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Intellectual Property 476 The IETF takes no position regarding the validity or scope of any 477 Intellectual Property Rights or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; nor does it represent that it has 481 made any independent effort to identify any such rights. Information 482 on the procedures with respect to rights in RFC documents can be 483 found in BCP 78 and BCP 79. 485 Copies of IPR disclosures made to the IETF Secretariat and any 486 assurances of licenses to be made available, or the result of an 487 attempt made to obtain a general license or permission for the use of 488 such proprietary rights by implementers or users of this 489 specification can be obtained from the IETF on-line IPR repository at 490 http://www.ietf.org/ipr. 492 The IETF invites any interested party to bring to its attention any 493 copyrights, patents or patent applications, or other proprietary 494 rights that may cover technology that may be required to implement 495 this standard. Please address the information to the IETF at 496 ietf-ipr@ietf.org. 498 Acknowledgment 500 Funding for the RFC Editor function is provided by the IETF 501 Administrative Support Activity (IASA).