idnits 2.17.1
draft-ietf-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 473.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 484.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 491.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 497.
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 (June 18, 2008) is 5792 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)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 2 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: Best Current Andrew Corporation
5 Practice June 18, 2008
6 Expires: December 20, 2008
8 Specifying Holes in LoST Service Boundaries
9 draft-ietf-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 December 20, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2008).
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., Newton, A., Schulzrinne, H., and H.
419 Tschofenig, "LoST: A Location-to-Service Translation
420 Protocol", draft-ietf-ecrit-lost-10 (work in progress),
421 May 2008.
423 [I-D.schulzrinne-ecrit-lost-sync]
424 Schulzrinne, H., "Synchronizing Location-to-Service
425 Translation (LoST) Servers",
426 draft-schulzrinne-ecrit-lost-sync-01 (work in progress),
427 February 2008.
429 [geoshape]
430 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
431 Application Schema for use by the Internet Engineering
432 Task Force (IETF)", Candidate OpenGIS Implementation
433 Specification 06-142r1, Version: 1.0, April 2007.
435 10.2. Informative References
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 PO Box U40
446 University of Wollongong, NSW 2500
447 AU
449 Email: james.winterbottom@andrew.com
451 Martin Thomson
452 Andrew Corporation
453 PO Box U40
454 University of Wollongong, NSW 2500
455 AU
457 Email: martin.thomson@andrew.com
459 Full Copyright Statement
461 Copyright (C) The IETF Trust (2008).
463 This document is subject to the rights, licenses and restrictions
464 contained in BCP 78, and except as set forth therein, the authors
465 retain all their rights.
467 This document and the information contained herein are provided on an
468 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
469 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
470 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
471 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
472 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
475 Intellectual Property
477 The IETF takes no position regarding the validity or scope of any
478 Intellectual Property Rights or other rights that might be claimed to
479 pertain to the implementation or use of the technology described in
480 this document or the extent to which any license under such rights
481 might or might not be available; nor does it represent that it has
482 made any independent effort to identify any such rights. Information
483 on the procedures with respect to rights in RFC documents can be
484 found in BCP 78 and BCP 79.
486 Copies of IPR disclosures made to the IETF Secretariat and any
487 assurances of licenses to be made available, or the result of an
488 attempt made to obtain a general license or permission for the use of
489 such proprietary rights by implementers or users of this
490 specification can be obtained from the IETF on-line IPR repository at
491 http://www.ietf.org/ipr.
493 The IETF invites any interested party to bring to its attention any
494 copyrights, patents or patent applications, or other proprietary
495 rights that may cover technology that may be required to implement
496 this standard. Please address the information to the IETF at
497 ietf-ipr@ietf.org.
499 Acknowledgment
501 Funding for the RFC Editor function is provided by the IETF
502 Administrative Support Activity (IASA).