idnits 2.17.1 draft-ietf-ecrit-specifying-holes-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 474. 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 162 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 13, 2008) is 5667 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 409, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-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 ECRIT J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: BCP Andrew Corporation 5 Expires: April 16, 2009 October 13, 2008 7 Specifying Holes in LoST Service Boundaries 8 draft-ietf-ecrit-specifying-holes-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 16, 2009. 35 Abstract 37 This document describes how holes can be specified in geodetic 38 service boundaries. One means of implementing a search solution in a 39 service database, such as one might provide with a LoST server, is 40 described. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5 47 4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8 48 5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9 49 6. Service Boundary Specification and Selection Algorithm . . . . 10 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 51 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 52 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 54 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 55 10.2. Informative References . . . . . . . . . . . . . . . . . 16 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 57 Intellectual Property and Copyright Statements . . . . . . . . . . 18 59 1. Introduction 61 The LoST protocol [RFC5222] describes a protocol that's primary 62 purpose is to map service and locations to destination addresses. 63 LoST does this by provisioning boundary maps or areas against service 64 URNs. The boundary is a polygon made up of sets of geodetic 65 coordinates specifying an enclosed area. In some circumstances an 66 area enclosed by a polygon, also known as an exterior polygon, may 67 contain exception areas, or holes, that for the same service must 68 yield a different destination to that described by the larger area. 69 This document describes how holes SHOULD be specified in service 70 boundaries defined using a GML encoding for the polygons and their 71 internal elements (holes). GML polygons are based on elements 72 defined in [ISO-19107]. 74 o--------------o 75 / \ 76 / /\ \ 77 / + +-----+ \ 78 o | Hole \ o 79 | | 1 / | 80 | +-------+ |<--- Primary Polygon 81 | +-------+ | 82 | / Hole | | 83 o \ 2 | o 84 \ +-----+ + / 85 \ \/ / 86 \ / 87 o--------------o 89 Figure 1: Holes in a Polygon 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Specifying Holes 99 Holes related to an exterior boundary polygon MUST adhere to the 100 following rules: 102 Rule 1: Two holes MUST NOT have more than one point of 103 intersection. If two or more holes share a common set of 104 boundaries then to the primary polygon these represent a 105 single hole in the service. The internal elements (holes) 106 should have common boundaries removed and a single hole 107 created irrespective of whether the excluded area is itself 108 made up of multiple service boundaries. 110 o--------------o o--------------o 111 / \ / \ 112 / /\ \ / /\ \ 113 / + +-----+ \ / + +-----+ \ 114 o | Hole \ o o | \ o 115 | | 1 \ | | | One \ | 116 | +-+-------+ | =========> | +-+ Hole + | 117 | / Hole | | | / | | 118 o \ 2 | o o \ | o 119 \ +-----+ + / \ +-----+ + / 120 \ \/ / \ \/ / 121 \ / \ / 122 o--------------o o--------------o 124 Incorrect Correct 126 Figure 2: Incorrect Hole Specification with Boundary Sharing 128 Rule 2: A hole MUST NOT have more than one point of intersection 129 with the outer-boundary of the primary (exterior) polygon. 130 If more than one point of intersection occurs the primary 131 polygon is either doesn't have a hole, it has an inlet as 132 in Figure 3, or the primary polygon SHOULD be expressed as 133 two polygons as in Figure 4. 135 +------- Inlet 136 | 137 v 138 o---+-----+----o o---o o----o 139 / |%%%%%| \ / | | \ 140 / /%%%%%%| \ / / | \ 141 / +%%%%%%%| \ / o o \ 142 o |%%%%%%%%\ o o | \ o 143 | |%%%%%%%%%\ | | | \ | 144 | +-+%%%%%%%%+ | ========> | o-o o | 145 | /%%%%%%%%| | | / | | 146 o \%%%%%%%%| o o \ | o 147 \ +-----+ + / \ o-----o o / 148 \ \/ / \ \/ / 149 \ / \ / 150 o--------------o o--------------o 152 Incorrect Correct 154 Figure 3: Correct Specification of an Inlet 156 A--q-----------B A-q q----------B 157 / | | \ / | | \ 158 / | | \ / | | \ 159 / z r-----s \ / P z r-----s P \ 160 H | \ C H o | \ o C 161 | | One \ | | l | \ l | 162 | y-x Hole t | ========> | y y-x t y | 163 | / | | | g / | g | 164 G \ | D G o \ | o D 165 \ / v---u / \ n / v---u n / 166 \ \ / / \ 1 \ / 2 / 167 \ \ / / \ \ / / 168 F-----w--------E F-----w w--------E 170 1 Polgon with a 2 Polygons that map 171 Dividing Hole to the same service 173 Figure 4: Correct Specification of Hole with Multiple Outer-Boundary 174 Intersections 176 Similarly, a polygon containing a hole with an island must be 177 represented as two polygons mapping to the same service. 179 Rule 3: A hole MUST be a legal polygon in accordance with the 180 geoshape specification [geoshape]. There is no restriction 181 on the number of points that may be used to express the 182 perimeter of the hole. 184 4. GML Polygons 186 The GML encoding of a polygon defines a enclosed exterior boundary, 187 with the first and last points of boundary being the same. Consider 188 the example in Figure 5. 190 B--------------C 191 / \ 192 / \ 193 / \ 194 A D 195 \ / 196 \ / 197 \ / 198 F--------------E 200 201 202 203 43.311 -73.422 204 43.111 -73.322 205 43.111 -73.222 206 43.311 -73.122 207 43.411 -73.222 208 43.411 -73.322 209 43.311 -73.422 210 211 212 214 Figure 5: Hexagon and Associated GML 216 NOTE that polygon vertices in Figure 5 are expressed using 217 elements for clarity. The vertices can also be expressed using a 218 element. 220 5. Holes in GML Polygons 222 A hole is specified in the polygon by defining an interior boundary. 223 The points defining the internal boundary define the area represented 224 by the hole in the primary (exterior) polygon. The shaded area in 225 Figure 6 is represented by the 4 points of the interior boundary 226 specified by (w,z,y,x). 228 B-------------C 229 / \ 230 / w-------------x \ 231 / |/////////////| \ 232 A |/////////////| D 233 \ |/////////////| / 234 \ z-------------y / 235 \ / 236 F-------------E 238 239 240 241 43.311 -73.422 242 43.111 -73.322 243 43.111 -73.222 244 43.311 -73.122 245 43.511 -73.222 246 43.511 -73.322 247 43.311 -73.422 248 249 250 251 252 43.411 -73.322 253 43.211 -73.322 254 43.211 -73.222 255 43.411 -73.222 256 43.411 -73.322 257 258 259 261 Figure 6: Hexagon with Hole 263 6. Service Boundary Specification and Selection Algorithm 265 A service boundary is represented by a polygon that may have many 266 vertices. The enclosed area of the polygon represents the area in 267 which a service, expressed as a service URN, maps to a single URI. 269 Figure 6 shall be used to illustrate two service boundaries. The 270 first service boundary A->F shall be referred to as area-A, and the 271 second service boundary w->z shall be referred to as area-w. Further 272 more area-A is directly represented by the GML encoding provided in 273 Figure 6. Area-w is represented as a hole in area-A by the interior 274 boundary. Since area-w is also a service boundary, a separate 275 polygon describing this area is also required and is shown in 276 Figure 7. 278 279 280 281 43.411 -73.322 282 43.211 -73.322 283 43.211 -73.222 284 43.411 -73.222 285 43.411 -73.322 286 287 288 290 Figure 7: GML for Area-w 292 If this data were in a LoST server the data mappings may look similar 293 to the example in Figure 8. This is an example only and does not 294 represent actual LoST server provisioning or data transfer records. 295 The example XML will not complie. 297 298 299 Outer Area Police Department 300 urn:service:sos.police 301 302 303 304 305 43.311 -73.422 306 43.111 -73.322 307 43.111 -73.222 308 43.311 -73.122 309 43.511 -73.222 310 43.511 -73.322 311 43.311 -73.422 312 313 314 315 316 317 43.411 -73.322 318 43.211 -73.322 319 43.211 -73.222 320 43.411 -73.222 321 43.411 -73.322 322 323 324 325 326 sip:area-A-pd@example.com 327 xmpp:area-A-pd@example.com 328 000 329 330 331 Inner Area Police Department 332 urn:service:sos.police 333 334 335 336 337 43.411 -73.322 338 43.211 -73.322 339 43.211 -73.222 340 43.411 -73.222 341 43.411 -73.322 342 343 344 345 346 sip:area-w-pd@example.com 347 xmpp:area-w-pd@example.com 348 000 349 351 Figure 8: Service Boundary Specifications 353 It is considered likely that LoST servers will need to provide 354 responses sufficiently quickly to allow real-time queries to be 355 performed as part of an emergency call routing flow. It is for this 356 reason that databases supporting native geospatial query techniques 357 are desirable and that service boundary specifications that are 358 easily mapped to internal data structures are preferred. The format 359 described in this memo makes support for this operation easy, while 360 allowing an arbitrary number of holes in a service boundary to be 361 specified. 363 Each primary polygon is stored in the geospatial database and mapped 364 to a service URN and destination URI. Holes may be stored as 365 polygons in a separate table and mapped to the primary polygon. When 366 a location is found to map to a polygon, the exceptions table can be 367 checked to see if the primary polygon contains any coverage holes. 368 In general no holes will exist for a service boundary, so this check 369 results in almost no overhead and the service mapping can be 370 returned. Where one or more holes are found to exist, the provided 371 location is checked against each hole. If the location is found to 372 exist in one of the specified holes then the primary polygon can be 373 discarded, and searching of the service boundary database can 374 continue. 376 7. Security Considerations 378 This document does not introduce any security issues. 380 8. IANA Considerations 382 There are no specific IANA considerations for this document. 384 9. Acknowledgements 386 Thanks to Carl Reed for input provided to the list some months back 387 and for reviewing this document. Thanks also to Michael Haberler for 388 suggesting that such a specification is required. 390 10. References 392 10.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, March 1997. 397 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 398 Tschofenig, "LoST: A Location-to-Service Translation 399 Protocol", RFC 5222, August 2008. 401 [geoshape] 402 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 403 Application Schema for use by the Internet Engineering 404 Task Force (IETF)", Candidate OpenGIS Implementation 405 Specification 06-142r1, Version: 1.0, April 2007. 407 10.2. Informative References 409 [I-D.ietf-ecrit-lost-sync] 410 Schulzrinne, H., "Synchronizing Location-to-Service 411 Translation (LoST) Servers", draft-ietf-ecrit-lost-sync-00 412 (work in progress), July 2008. 414 [ISO-19107] 415 ISO, "Geographic information - Spatial Schema", ISO 416 Standard 19107, First Edition, 5 2003. 418 Authors' Addresses 420 James Winterbottom 421 Andrew Corporation 422 PO Box U40 423 University of Wollongong, NSW 2500 424 AU 426 Email: james.winterbottom@andrew.com 428 Martin Thomson 429 Andrew Corporation 430 PO Box U40 431 University of Wollongong, NSW 2500 432 AU 434 Email: martin.thomson@andrew.com 436 Full Copyright Statement 438 Copyright (C) The IETF Trust (2008). 440 This document is subject to the rights, licenses and restrictions 441 contained in BCP 78, and except as set forth therein, the authors 442 retain all their rights. 444 This document and the information contained herein are provided on an 445 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 446 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 447 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 448 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 449 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 450 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 452 Intellectual Property 454 The IETF takes no position regarding the validity or scope of any 455 Intellectual Property Rights or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; nor does it represent that it has 459 made any independent effort to identify any such rights. Information 460 on the procedures with respect to rights in RFC documents can be 461 found in BCP 78 and BCP 79. 463 Copies of IPR disclosures made to the IETF Secretariat and any 464 assurances of licenses to be made available, or the result of an 465 attempt made to obtain a general license or permission for the use of 466 such proprietary rights by implementers or users of this 467 specification can be obtained from the IETF on-line IPR repository at 468 http://www.ietf.org/ipr. 470 The IETF invites any interested party to bring to its attention any 471 copyrights, patents or patent applications, or other proprietary 472 rights that may cover technology that may be required to implement 473 this standard. Please address the information to the IETF at 474 ietf-ipr@ietf.org.