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.