idnits 2.17.00 (12 Aug 2021)
/tmp/idnits49574/draft-rosen-dns-sos-03.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 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 925.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 902.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 909.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 23, 2005) is 6047 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'REF' is mentioned on line 212, but not defined
== Unused Reference: 'RFC2535' is defined on line 852, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034,
RFC 4035)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2806 (Obsoleted by RFC 3966)
** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402,
RFC 3403, RFC 3404)
** Obsolete normative reference: RFC 2916 (Obsoleted by RFC 3761)
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ecrit B. Rosen
3 Internet-Draft NeuStar
4 Expires: April 26, 2006 October 23, 2005
6 Emergency Call Information in the Domain Name System
7 draft-rosen-dns-sos-03.txt
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on April 26, 2006.
34 Copyright Notice
36 Copyright (C) The Internet Society (2005).
38 Abstract
40 Location of a caller is essential to processing an emergency call.
41 Location is needed to correctly route the call, and to correctly
42 dispatch help to the right place. Location can be specified in
43 geographic (latitude, longitude) or civic (country, province,
44 locality) forms. This document proposes a DNS-based mechanism to
45 lookup emergency calling URIs and related emergency information from
46 a known civic location in a specific form. Other companion documents
47 propose a non DNS-based approach to determine civic location from
48 geographic location, and describe how to discover a civic location in
49 the appropriate local form(s) for this application.
51 Table of Contents
53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
54 2. What's Changed . . . . . . . . . . . . . . . . . . . . . . . . 3
55 3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 4. Overview of the Solution . . . . . . . . . . . . . . . . . . . 5
57 5. The SOS Application Specifications . . . . . . . . . . . . . . 7
58 5.1. Application Unique String . . . . . . . . . . . . . . . . 8
59 5.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 8
60 5.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 8
61 5.4. Valid Databases . . . . . . . . . . . . . . . . . . . . . 8
62 5.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
63 5.4.2. Services Parameters . . . . . . . . . . . . . . . . . 9
64 5.5. What constitutes an 'Sos Resolver'? . . . . . . . . . . . 10
65 6. Registration mechanism for sosservices . . . . . . . . . . . . 10
66 6.1. Registration Requirements . . . . . . . . . . . . . . . . 11
67 6.1.1. Functionality Requirement . . . . . . . . . . . . . . 11
68 6.1.2. Naming requirement . . . . . . . . . . . . . . . . . . 11
69 6.1.3. Security requirement . . . . . . . . . . . . . . . . . 11
70 6.1.4. Publication Requirements . . . . . . . . . . . . . . . 12
71 6.2. Registration procedure . . . . . . . . . . . . . . . . . . 12
72 6.2.1. IANA Registration . . . . . . . . . . . . . . . . . . 12
73 6.2.2. Initial Registrations . . . . . . . . . . . . . . . . 12
74 7. Polygon Document . . . . . . . . . . . . . . . . . . . . . . . 16
75 8. Subdomain Document . . . . . . . . . . . . . . . . . . . . . . 17
76 9. Structure Document . . . . . . . . . . . . . . . . . . . . . . 17
77 10. Resolving geo locations . . . . . . . . . . . . . . . . . . . 17
78 11. Notes and things to do . . . . . . . . . . . . . . . . . . . . 18
79 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
80 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
81 14. Normative References . . . . . . . . . . . . . . . . . . . . . 19
82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
83 Intellectual Property and Copyright Statements . . . . . . . . . . 22
85 1. Requirements notation
87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
89 document are to be interpreted as described in [RFC2119].
91 2. What's Changed
93 Version 2
95 Minor refresh to keep proposal alive
97 Version 1
99 Major simplifications have been made to this version from the
100 initial.
102 The contents of proposed entries in the DNS has been simplified to
103 several NAPTRs; no new DNS objects are proposed, and specifically,
104 the proposed POLY object is replaced with a NAPTR to a boundary
105 description document in XML.
107 3. Problem
109 Placing an emergency call to get help depends on location = where the
110 caller is located at the time of the call. Location is needed for
111 two fundamental reasons:
112 1. To determine which Public Safety Answering Point (PSAP) also
113 known as an Emergency Communications Center (ECC) to direct the
114 call to.
115 2. To direct responders (police, fire, ambulance) to the caller.
117 Location, within the context of emergency calls, can be expressed in
118 two different forms, geographic (geo) - latitude, longitude, altitude
119 and civic - county, province or state, city, ...
121 Determining the correct PSAP is not trivial. PSAPs have service
122 boundaries. If a caller is inside the service boundary, that PSAP
123 should get the call. Nearest PSAP, home PSAP or other, simpler
124 mechanisms will not work. One must either know, from some kind of
125 authenticated database, the PSAP that serves a given civic address,
126 or have a geo location and use a network service or local algorithm
127 to determine the correct PSAP from the geographic coordinates. (For
128 example, a service may know the service boundaries for a region and
129 compare the location of the caller with all of the PSAP service
130 boundaries to determine which boundary the geo location falls
131 within.) There are about 6,000 PSAPs in North America, and perhaps 3
132 times that number in the rest of the world (ed note, anyone have a
133 better number?).
135 With the advent of Voice over IP, the Internet presents daunting
136 problems to emergency calls because users can be anywhere in the
137 world relative to the elements that are processing the call.
138 Consider for example, a user sitting in a cafe' in Chicago with a
139 laptop connected to the Internet via a hotspot, communicating with
140 her employer's SIP proxy through a VPN tunnel. An accident occurs
141 and the patron calls for help. What if the employer is in Sierra
142 Leone, and has Sierra Leone based VoIP service provider? The
143 employer's proxy server must determine, based on the actual location
144 of the user, that the PSAP is in Chicago!
146 In processing a call to an PSAP using a protocol such as SIP
147 [RFC3261], a routing element must determine the location of the
148 caller, and depending on the form of the location either have access
149 to all the PSAP service boundaries, run an intersection algorithm
150 between a geo location of the caller and all possible PSAP
151 boundaries, or have a civic address and a database that contains the
152 PSAP that serves that address. Having determined the correct PSAP,
153 the routing element must forward the call to it (which implies
154 knowing the URI of that PSAP). At present, there is no standard
155 mechanism to discover the correct PSAP from either civil or
156 geographic addresses.
158 Once the correct PSAP is determined, the call will be forwarded to
159 it. The PSAP will then answer the call, and determine what response
160 is required. The responders are then dispatched to the location of
161 the caller. Dispatch is typically based on civic location. If the
162 location is reported by the caller in geo form, it must be translated
163 to civic form in the PSAP, which requires an accurate translation
164 database.
166 Each of the responders (e.g. police, fire, emergency medical) have
167 their own service boundaries, and they do not correspond to the
168 service boundary of the PSAP. A mechanism is needed to publish
169 responder service boundaries.
171 If location is available as a civic, access to a database that
172 enumerates all known street addresses is used to validate the address
173 prior to its being used for an emergency call. This database (called
174 a "Master Street Address Guide" or "MSAG") must be made available to
175 the entities that supply location to the endpoints. Validation
176 against the MSAG is essential because there are many variations in
177 naming locations (First Street vs 1st Street, New York Avenue
178 Northwest, vs New York Ave. NW). Accurate dispatch requires
179 uniformity of reporting civic addresses, and thus all addresses must
180 be verified against some form of the MSAG prior to an emergency.
181 This implies the MSAG, which in some areas is commonly available to
182 PSTN carriers and in use by PSAPs, must be more publicly available.
184 Organizing PSAPs and responders is a government function.
185 Governments determine where boundaries are, how coverage is handled
186 in less populated areas, etc. In smaller countries, the national
187 government organizes the entire system. More commonly, while some
188 aspects are organized and regulated at the national level, much of
189 the organization is delegated to state/province/district level, and
190 often further delegation to country and/or city/township level is
191 done. Any organization of the data here must mirror this delegation.
192 On the other hand, for historical reasons, many service boundaries do
193 not follow government entity boundaries. Therefore, there is not
194 necessarily a correlation between the delegation boundaries and the
195 service boundaries.
197 There are areas of the world that are disputed - more than one
198 country claims the area as part of its territory. This gives rise to
199 multiple PSAPs having a service boundary including disputed
200 territory. While such areas are few and relatively small, the
201 problem exists and must be accounted for in the design of systems and
202 databases.
204 4. Overview of the Solution
206 SIP has been extended to carry a location object [REF]. Emergency
207 calls will be required to include this object in the first message
208 (INVITE) of an emergency call. The location can be determined by a
209 measurement method (such as a Global Positioning Satellite (GPS)
210 receiver in the endpoint, or the endpoint can learn its location from
211 the local infrastructure using, for example, the location option of
212 Dynamic Host Configuration Protocol (DHCP) [REF].
214 We propose to use the Domain Name System (DNS) to hold a hierarchy of
215 civic locations. We think the DNS is particularly appropriate for
216 this purpose because of its delegation mechanism, which we will show
217 matches the need very closely. Starting at the root sos.arpa (sos
218 being the universal symbol for emergency), we propose that the next
219 level be a two-character iso country code, e.g. au.sos.arpa. We
220 propose that an international agency be delegated the sos.arpa
221 domain, and that it delegate au.sos.arpa to an agency selected by the
222 government of Australia. The national agency can, if appropriate,
223 make further delegations. For example, there might be a domain such
224 as pittsburgh.allegheny.pa.us.sos.arpa representing the City of
225 Pittsburgh, Allegheny County, in the Commonwealth (state) of
226 Pennsylvania, in the United States. A city could, for example,
227 create subdomains in its domain representing streets, and within
228 those street domains, subdomains for addresses. For example, we
229 might find an entry at 123.main.pittsburgh.allegheny.pa.us.sos.arpa.
230 There is no requirement for each subdomain in a domain to have the
231 same semantics (for example, rural and urban areas might use
232 different parallel civic location schemes). Nor is there a
233 requirement for a particular level of hierarchy within two different
234 countries or regions to share the same semantics.
236 The contents of the domains are primarily Naming Authority Pointers
237 (NAPTRs) [RFC2915]. For example, some of these domains may have
238 NAPTR records representing the service URIs for the PSAP or
239 responders that cover that boundary. These may exist at any level.
241 Besides NAPTRs that represent service boundaries for PSAPs or
242 responders, there can also be NAPTRs to additional information.
243 These NAPTRs are expected to resolve to HTPPS URLs which point to XML
244 documents with specific semantics. This document describes several
245 such NAPTRs:
246 o a pointer to a document containing a set of polygons: each a
247 sequence of geospatial coordinates describing the boundary of a
248 domain;
249 o a pointer to a list of subdomains of a domain to facilitate
250 searching;
251 o a pointer to a set of information about a structure (building)
252 provided by the actual owner of the domain, and not essential for
253 routing or dispatch, but potentially usefull for the PSAP and
254 responder. For example, an after hours contact;
256 For location information within a building, a city or township may
257 delegate a street address to a building owner. In turn, the building
258 owner may delegate subdomains to suite tenants. The tenant, or
259 building owner, would enter floor subdomains, and within those, room
260 domains. For example, one might find a entry at 235-
261 5.5.123.main.pittsburgh.allegheny.pa.us.sos.arpa representing cubicle
262 235-5 on the 5th floor of 123 Main Street. Interior information is
263 optional, and intended for non-private data.
265 Of course, any administrative entity in the hierarchy could contract
266 with a registrar to manage the delegation of its subdomains if it so
267 chose. It could also create an administrative mechanism to obtain
268 lower level data, and publish lower levels itself, rather than
269 delegate.
271 We note that the actual meaning of any level in this hierarchy is not
272 defined, and the number of levels is not significant. What matters
273 is that the names mean something to the (human) dispatcher and
274 responder and there is a reasonably consistant style within larger
275 (e.g. country) levels that facilitates construction of a query string
276 from a location representation.
278 Creation of the database may look daunting, but in many areas it
279 already exists, albeit in different forms. The hierarchical nature
280 of DNS can simplify the data that needs to be assembled where the
281 data does not yet exist. In many cases, PSAP boundaries actually are
282 aligned to political boundaries. A large city, for example,
283 typically has only one PSAP, whose service boundary matches the city
284 boundary. Thus, street level information is not needed for a civic
285 location to find the serving PSAP, if the city entry has an PSAP
286 NAPTR. It is common for an PSAP to serve more than one township or
287 smaller city, but the mechanism would work equally well for such a
288 circumstance. There are some circumstances where PSAP boundaries do
289 not align well. Some PSAPs only serve a part of a city, and an
290 adjacent PSAP serves the remainder. The basic mechanism works quite
291 well, because an PSAP NAPTR can be put in the upper level domain that
292 covers the majority of the served area, and only subdomains for
293 exception, either within the majority area -- all except these
294 streets -- or within the minority area -- all plus these streets,
295 need be populated with domains containing the correct PSAP NAPTR. It
296 is also possible for a routing proxy to be designated as the PSAP for
297 an entire city, state, or even a country, and for that proxy to have
298 the information needed to determine which PSAP serves the caller
299 location, forwarding the call to it.
301 Clearly, the existence of a street address entry indicates a valid
302 civic Location. The jurisdiction responsible for defining valid
303 addresses within its domain would enter its preferred spelling/
304 representation of that name. Any entity assigning civic locations
305 would verify an address by looking it up in the sos.arpa tree. In
306 this regard, the tree is the MSAG. Alternate spellings, and
307 alternate forms of the address (for example, a postal address) can
308 also be placed in the sos.arpa tree, with a CNAME element pointing to
309 the correctly spelled DNS entry.
311 For locations provided in geo form, we propose that the sos.arpa
312 domain have entries for each PSAP, which contains a NAPTR with the
313 URI to reach that PSAP and a NAPTR with the polygon lists defining
314 its service boundaries. For convenience, we define a mechanism for a
315 DNS name server to accept a query with a lat/lon/altitude as two name
316 components and return the URI of the PSAP boundary the lat/lon/
317 altitude lies within.
319 5. The SOS Application Specifications
320 The following text is based on the equivalent text in [RFC2916].
322 This template defines the SOS DDDS Application according to the rules
323 and requirements found in [RFC3402]. The DDDS database used by this
324 Application is found in [RFC3403] which is the document that defines
325 the NAPTR DNS Resource Record type.
327 5.1. Application Unique String
329 The Application Unique String for a civic location expressed as a
330 series of increasingly specific regions starting at national
331 (country), with the components separated by periods, and in reverse
332 order (i.e., country code appears just to the left of "sos.arpa").
333 There is no significance to the meaning of the components as long as
334 the civic location is interpretable by residents in the specified
335 location, and they are in increasingly specific. Implementations
336 SHOULD use the components listed in [DHCP civic ref] to allow direct
337 mapping between locations reported by DHCP and locations in the DNS.
339 Where local convention omits levels of hierarchy that are required in
340 other regions within a country (for example, use of county in some
341 provinces but not in others), the omitted element would be specified
342 as ".null".
344 The application unique string for a geo location is expressed by
345 placing latitude, longitude and altitude (in decimal degrees/meters)
346 as three components (left to right), dot separatated and appending
347 ".geo". The character "d" is used as the separator between the whole
348 and fractional part of the degree/meter.
350 5.2. First Well Known Rule
352 The First Well Known Rule for this Application is the identity rule.
353 The output of this rule is the same as the input. This is because
354 this Application's databases are organized in such a way that it is
355 possible to go directly from the name to the smallest granularity of
356 the namespace directly from the name itself.
358 5.3. Expected Output
360 The output of the last DDDS loop is a set of Uniform Resource
361 Identifiers in absolute form according to the 'absoluteURI'
362 production in the Collected ABNF found in [RFC2396].
364 5.4. Valid Databases
366 At present only one DDDS Database is specified for this Application.
367 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
368 Database [RFC3403] specifies a DDDS Database that uses the NAPTR DNS
369 resource record to contain the rewrite rules. The Keys for this
370 database are encoded as domain-names.
372 The output of the First Well Known Rule for the SOS Application is
373 the input string with the string "sos.arpa" appended.
375 This domain-name is used to request NAPTR records which may contain
376 the end result or, if the flags field is blank, produces new keys in
377 the form of domain-names from the DNS.
379 The character set used to encode the substitution expression is
380 UTF-8. The allowed input characters are and the characters allowed
381 to be in a Key are those that are currently defined for DNS domain-
382 names. Spellings SHOULD use local conventions, but MUST match the
383 same conventions used for DHCP reported location.
385 5.4.1. Flags
387 This Database contains a field that contains flags that signal when
388 the DDDS algorithm has finished. At this time only one flag, "U", is
389 defined. This means that this Rule is the last one and that the
390 output of the Rule is a URI. See [RFC3403].
392 If a client encounters a record with an unknown flag, it MUST ignore
393 it and move to the next Rule. This test takes precedence over any
394 ordering since flags can control the interpretation placed on fields.
395 A novel flag might change the interpretation of the regexp and/or
396 replacement fields such that it is impossible to determine if a
397 record matched a given target.
399 If this flag is not present then this rule is non-terminal. If a
400 Rule is non-terminal, then clients MUST use the Key produced by this
401 Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
402 client to query for new NAPTR records at the domain-name that is the
403 result of this Rule).
405 5.4.2. Services Parameters
407 Service Parameters for this Application take the following form and
408 are found in the Service field of the NAPTR record.
410 service_field = "SOS" 1*(servicespec)
411 servicespec = "+" sosservice
412 sosservice = type 0*(subtypespec)
413 subtypespec = ":" subtype
414 type = 1*32(ALPHA / DIGIT)
415 subtype = 1*32(ALPHA / DIGIT)
417 In other words, a non-optional "SOS" (used to denote SOS-only Rewrite
418 Rules in order to mitigate record collisions) followed by 1 or more
419 or more sosservices which indicate what class of functionality a
420 given end point offers. Each sosservice is indicated by an initial
421 '+' character.
423 No use for subtypes is presently contemplated, but is left defined as
424 in [RFC2916] for possible future use.
426 5.4.2.1. SOS Services
428 sosservice specifications contain the functional specification (i.e.,
429 what it can be used for), the valid protocols, and the URI schemes
430 that may be returned. Note that there is no implicit mapping between
431 the textual string "type" or "subtype" in the grammar for the
432 sosservice and URI schemes or protocols. The mapping, if any, must
433 be made explicit in the specification for the sosservice itself. A
434 registration of a specific Type also has to specify the Subtypes
435 allowed.
437 The registration mechanism is specified in Section 6.
439 5.5. What constitutes an 'Sos Resolver'?
441 The algorithm defined above always returns a single rule. Specific
442 applications may have application-specific knowledge or facilities
443 that allow them to present multiple results or speed selection, but
444 these should never change the operation of the algorithm.
446 6. Registration mechanism for sosservices
448 As specified in the ABNF found in Section 5.4.2, an 'sosservice' is
449 made up of 'types' and 'subtypes'. For any given 'type', the
450 allowable 'subtypes' must be specified in the registration. There is
451 currently no concept of a registered 'subtype' outside the scope of a
452 given 'type'. Thus, the registration process uses the 'type' as the
453 main key within the IANA Registry. While the combination of each
454 type and all of its subtypes constitutes the allowed values for the
455 'enumservice' field, it is not sufficient to simply document those
456 values. A complete registration will also include the allowed URI
457 schemes, a functional specification, security considerations,
458 intended usage, and any other information needed to allow for
459 interoperability within the application. In order to be a registered
460 sos service, the entire specification, including the template,
461 requires publication of the sosservice registration specification as
462 an RFC.
464 6.1. Registration Requirements
466 Service registration proposals are all expected to conform to various
467 requirements laid out in the following sections.
469 6.1.1. Functionality Requirement
471 A registered sosservice must be able to function as a selection
472 mechanism when choosing one NAPTR resource record from another. That
473 means that the registration MUST specify what is expected when using
474 that very NAPTR record, and the URI that is the outcome of the use of
475 it.
477 6.1.2. Naming requirement
479 An sosservice MUST be unique in order to be useful as a selection
480 criteria. Since an sosservice is made up of a type and a type-
481 dependent subtype, it is sufficient to require that the 'type' itself
482 be unique. The 'type' MUST be unique, and conform to the ABNF
483 specified in Section 5.4.2.
485 The subtype, being dependent on the type, MUST be unique within a
486 given 'type'. It must conform to the ABNF specified in
487 Section 5.4.2. The subtype for one type MAY be the same as a subtype
488 for a different registered type but it is not sufficient to simply
489 reference another type's subtype. The function of each subtype must
490 be specified in the context of the type being registered.
492 6.1.3. Security requirement
494 An analysis of security issues is required for all registered
495 sosservices. (This is in accordance with the basic requirements for
496 all IETF protocols.) In most cases, it is expected that the security
497 considerations will be the same as those services defined in this
498 memo, but new services could have different security considerations.
500 All descriptions of security issues must be as accurate as possibly
501 regardless of registration tree. In particular, a statement that
502 there are "no security issues associated with this sosservice" must
503 not be confused with "the security issues associated with this
504 sosservice have not been assessed".
506 There is no requirement that an sosservice must be secure or
507 completely free from risks. Nevertheless, all known security risks
508 must be identified in the registration of an sosservice.
510 The security considerations section of all registrations is subject
511 to continuing evaluation and modification.
513 6.1.4. Publication Requirements
515 Proposals for sosservice registrations MUST be published as an RFC.
517 6.2. Registration procedure
519 6.2.1. IANA Registration
521 IANA will register the sosservice and make the sosservice
522 registration available to the community in addition to the RFC/BCP
523 publication.
525 6.2.1.1. Location of sosservice Registrations
527 sosservice registrations will be published in the IANA repository and
528 made available via anonymous FTP at the following URI:
529 "ftp://ftp.iana.org/assignments/sos-services/".
531 6.2.1.2. Change Control
533 Change control of sosservice stay with the IETF via the RFC
534 publication process. sosservice registrations may not be deleted;
535 sosservice which are no longer believed appropriate for use can be
536 declared OBSOLETE by publication of a new RFC and a change to their
537 "intended use" field; such sosservices will be clearly marked
538 OBSOLETE in the lists published by IANA.
540 Registration Template
541 sosservice Type:
542 sosservice Subtype(s):
543 URI Scheme(s):
544 Functional Specification:
545 Security considerations:
546 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
547 Author:
548 Any other information that the author deems interesting:
550 Note: In the case where a particular field has no value, that field
551 is left completely blank, especially in the case where a given type
552 has no subtypes.
554 6.2.2. Initial Registrations
556 The following services are defined in this memo
558 Type sos+PSAP
559 Subtypes: none
560 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
561 Functional Specification: Provides a contact uri for the emergency
562 call center (public safety answering point) that serves the civic
563 address corresponding to this DDDS entry. It is not necessary for
564 the uri to be the uri of the PSAP itself; it can be a uri of a
565 proxy server which can route the call to the correct PSAP
566 Security considerations: As this URI reaches the PSAP, directly or
567 indirectly, it can be a target for a denial of service attack.
568 Intended usage: COMMON
569 Author: Brian Rosen
570 Other Information: None
572 Type sos+fire
573 Subtypes: none
574 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
575 Functional Specification: Provides a contact uri for the fire
576 department/brigade that serves the civic address corresponding to
577 this DDDS entry.
578 Security considerations: As this URI reaches the responder,
579 directly or indirectly, it can be a target for a denial of service
580 attack.
581 Intended usage: COMMON
582 Author: Brian Rosen
583 Other Information: In many jurisdictions, emergency calls should
584 be routed to an PSAP rather than a specific service such as a
585 direct call to the fire department/brigade. The agency can refuse
586 such direct calls by, e.g. requiring authentication.
588 Type sos+rescue
589 Subtypes: none
590 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
591 Functional Specification: Provides a contact uri for the rescue/
592 emergency medical service/ambulance service that serves the civic
593 address corresponding to this DDDS entry.
594 Security considerations: As this URI reaches the responder,
595 directly or indirectly, it can be a target for a denial of service
596 attack.
597 Intended usage: COMMON
598 Author: Brian Rosen
599 Other Information: In many jurisdictions, emergency calls should
600 be routed to an PSAP rather than a specific service such as a
601 direct call to the rescue/EMS/ambulance service. The agency can
602 refuse such direct calls by, e.g. requiring authentication.
604 Type sos+marine
605 Subtypes: none
606 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
607 Functional Specification: Provides a contact uri for the maritime
608 rescue service that serves the civic address corresponding to this
609 DDDS entry.
610 Security considerations: As this URI reaches the responder,
611 directly or indirectly, it can be a target for a denial of service
612 attack.
613 Intended usage: COMMON
614 Author: Brian Rosen
615 Other Information: The concept of a "civic address" for a marine
616 emergency is somewhat strange. Entries should be made in the DDDS
617 for territory within a jurisdiction that is served by a maritime
618 emergency response service. For example, one could have an entry
619 such as 5.atlantic.us for the Coast Guard District 5 in the
620 Atlantic region of the United States.
622 Type sos+police
623 Subtypes: none
624 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
625 Functional Specification: Provides a contact uri for the police
626 department that serves the civic address corresponding to this
627 DDDS entry.
628 Security considerations: As this URI reaches the responder,
629 directly or indirectly, it can be a target for a denial of service
630 attack.
631 Intended usage: COMMON
632 Author: Brian Rosen
633 Other Information: In many jurisdictions, emergency calls should
634 be routed to an PSAP rather than a specific service such as a
635 direct call to the police. The agency can refuse such direct
636 calls by, e.g. requiring authentication.
638 Type sos+mountain
639 Subtypes: none
640 URI Schemes: sips: [RFC3261] and tel: [RFC2806]
641 Functional Specification: Provides a contact uri for the mountain
642 rescue service point that serves the civic address corresponding
643 to this DDDS entry.
644 Security considerations: As this URI reaches the responder,
645 directly or indirectly, it can be a target for a denial of service
646 attack.
647 Intended usage: COMMON
648 Author: Brian Rosen
649 Other Information: In many jurisdictions, emergency calls should
650 be routed to an PSAP rather than a specific service such as a
651 direct call to the mountain rescue. The agency can refuse such
652 direct calls by, e.g. requiring authentication.
654 Type sos+subdomain
655 Subtypes: none
656 URI Schemes: http or https [RFC2616]
657 Functional Specification: Pointer to an XML document as defined in
658 Section 8 containing a list of subdomains. Facilitates searching
659 the sos.arpa tree.
660 Security considerations: The DNS system is usually considered more
661 secure against various forms of attack than most web servers.
662 Thus, in situations where there are major disruptions to the
663 Internet (which may be exactly when the data is most needed), the
664 DNS may work, while the web server may not. Routing proxies
665 SHOULD NOT assume that they can use this NAPTR to access the list
666 of subdomains, at the time an emergency call is being routed.
667 Intended usage: COMMON
668 Author: Brian Rosen
669 Other Information: none.
671 Type sos+polygon
672 Subtypes: none
673 URI Schemes: http or https [RFC2616]
674 Functional Specification: Pointer to an XML document as defined in
675 Section 7 containing a list of polygons describing the boundaries
676 of psaps within the domain. May be protected by TLS if needed.
677 Security considerations: If the information must be kept private,
678 the document should be protected with TLS. Polygons representing
679 boundaries within a building are often considered private and thus
680 should be protected.
681 The DNS system is usually considered more secure against various
682 forms of attack than most web servers. Thus, in situations where
683 there are major disruptions to the Internet (which may be exactly
684 when the data is most needed), the DNS may work, while the web
685 server may not. Routing proxies SHOULD NOT assume that they can
686 use this NAPTR to access the list of polygons, at the time an
687 emergency call is being routed.
688 Intended usage: COMMON
689 Author: Brian Rosen
690 Other Information: none.
692 Type sos+structure
693 Subtypes: none
694 URI Schemes: http or https [RFC2616]
695 Functional Specification: Pointer to an XML document as defined in
696 Section 9.
697 Security considerations: In many cases, this information is
698 private and the document should be protected with TLS.
699 Intended usage: COMMON
700 Author: Brian Rosen
701 Other Information: none.
703 7. Polygon Document
705 The Polygon document MUST be a well-formed XML document meeting the
706 following schema, which is derived from Geography Markup Language
707 (GML) as defined by the OpenGIS Consortium [1].
709
710
716
718
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
739 8. Subdomain Document
741 The subdomain document shall be a well-structured XML document
742 accessed by HTTP or HTTPS. The schema of this document is:
744
745
749
750
751
752
753
754
756 9. Structure Document
758 The structure document shall be a well-structured XML document
759 accessed by HTTP or HTTPS. The schema of this document is:
761
762
766
767
768
769
770
771
773 10. Resolving geo locations
775 Within any civic level (country, state/province, county, city>, a
776 polygon NAPTR may occur. The URI points to a list of pairs of
777 "psapUri" and "boundary" elements, where the URI is the target of any
778 call within the boundary. In simple situations, a single boundary
779 representing an entire country may exist at the country code level of
780 the civic namespace, for example to.sos.arpa may have a polygon NAPTR
781 with a single URI and boundary of the country. In the United States,
782 it may be more convenient to put the polygons in the state and/or
783 county levels.
785 Any element can use the subdomain NAPTR to "walk" the entire tree and
786 discover all the polygon NAPTRs in the tree to produce a complete set
787 of polygons. The element could then use standard techniques that can
788 quickly determine which polygon a particular point lies within.
790 As a convenience, any name server can, if it chooses, do such a
791 "walk", and subsequently resolve a query of the form:
792 101d221.93d0345.0.geo.sos.arpa, where the meaning of such a query
793 would be to ask for the RRs (presumably, the PSAP NAPTR) for the geo
794 101.221 degrees latitude, 93.0354 degrees longitude and 0 meters
795 altitude. Such a resolution is NOT standard DNS name server
796 behavior, and clients cannot necessarily depend on their local name
797 server providing resolution of such a query. Specifically, the
798 "geo.sos,arpa" subdomain is NOT delegated to any entity, and an
799 attempt to query with a valid geo using the .geo.sos.arpa tree with
800 no name servers in the path that support the geo query will fail.
802 11. Notes and things to do
804 Need text on i18n names.
806 12. Security Considerations
808 Details of building interiors and structure documents may not be
809 public data. Revealing this data to unauthorized users (PSAPs and
810 responders) could provide attackers with information that could be
811 exploited to burgle, inflict damage on, or otherwise do significant
812 harm to the owners and occupants of the structure. Where the data is
813 not public, accessing the data MUST be restricted to authorized
814 entities using HTTPS.
816 If the data in the DNS is forged, or a man in the middle attack is
817 mounted, emergency calls could be directed to the wrong place. The
818 call could be directed to the wrong PSAP, could be directed to a
819 valid URI which was not an PSAP, to a completely invalid URI. Worse
820 the call could be directed to an entity impersonating an PSAP, which
821 could leave the caller believing help was coming when in fact it was
822 not.
824 Data in the DNS sos.arpa tree includes a URI that can directly or
825 indirectly reach the PSAP, which may be used to mount a Denial of
826 Service attack.
828 For these reasons, clients and servers SHOULD use protected services
829 such as HTTPS and sips: which could authenticate that the destination
830 is the desired one.
832 If the caller provides an incorrect location, the call could be
833 directed to the wrong PSAP. An inadvertent error could be detected
834 before a call by verifying that the call exists in the sos.arpa tree.
835 Indeed validation of address is one of the reasons we propose that
836 the address data be in a publicly accessible database.
838 13. Acknowledgements
840 This document has benefited greatly from numerous comments from both
841 Henning Schulzrinne and Rohan Mahy.
843 14. Normative References
845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
846 Requirement Levels", BCP 14, RFC 2119, March 1997.
848 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
849 Resource Identifiers (URI): Generic Syntax", RFC 2396,
850 August 1998.
852 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
853 RFC 2535, March 1999.
855 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
856 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
857 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
859 [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
860 April 2000.
862 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
863 (NAPTR) DNS Resource Record", RFC 2915, September 2000.
865 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
866 September 2000.
868 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
869 A., Peterson, J., Sparks, R., Handley, M., and E.
870 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
871 June 2002.
873 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
874 Part Two: The Algorithm", RFC 3402, October 2002.
876 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
877 Part Three: The Domain Name System (DNS) Database",
878 RFC 3403, October 2002.
880 [1]
882 Author's Address
884 Brian Rosen
885 NeuStar
886 470 Conrad Dr.
887 Mars, PA 16046
888 US
890 Phone: +1 724 382 1051
891 Email: br@brianrosen.net
893 Intellectual Property Statement
895 The IETF takes no position regarding the validity or scope of any
896 Intellectual Property Rights or other rights that might be claimed to
897 pertain to the implementation or use of the technology described in
898 this document or the extent to which any license under such rights
899 might or might not be available; nor does it represent that it has
900 made any independent effort to identify any such rights. Information
901 on the procedures with respect to rights in RFC documents can be
902 found in BCP 78 and BCP 79.
904 Copies of IPR disclosures made to the IETF Secretariat and any
905 assurances of licenses to be made available, or the result of an
906 attempt made to obtain a general license or permission for the use of
907 such proprietary rights by implementers or users of this
908 specification can be obtained from the IETF on-line IPR repository at
909 http://www.ietf.org/ipr.
911 The IETF invites any interested party to bring to its attention any
912 copyrights, patents or patent applications, or other proprietary
913 rights that may cover technology that may be required to implement
914 this standard. Please address the information to the IETF at
915 ietf-ipr@ietf.org.
917 Disclaimer of Validity
919 This document and the information contained herein are provided on an
920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
927 Copyright Statement
929 Copyright (C) The Internet Society (2005). This document is subject
930 to the rights, licenses and restrictions contained in BCP 78, and
931 except as set forth therein, the authors retain all their rights.
933 Acknowledgment
935 Funding for the RFC Editor function is currently provided by the
936 Internet Society.