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.