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).