idnits 2.17.1 draft-schulzrinne-ecrit-mapping-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 688. ** 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 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 == Line 376 has weird spacing: '... Leonia sip...' == Line 377 has weird spacing: '...ort Lee sip:e...' == Line 378 has weird spacing: '...Teaneck sip:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 16, 2005) is 6768 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) == Unused Reference: '2' is defined on line 611, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 614, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 618, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 627, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 633, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 637, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 640, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-rosen-iptel-dialstring-02 == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-03 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: April 19, 2006 October 16, 2005 6 Location-to-URL Mapping Architecture and Framework 7 draft-schulzrinne-ecrit-mapping-arch-00 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 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes an architecture for a global, scalable, 41 resilient and administratively distributed system for mapping 42 geographic location information to URLs. The architecture 43 generalizes well-known approaches found in hierarchical lookup 44 systems such as DNS. The architecture does not depend on using a 45 specific protocol, but does require that protocols can summarize the 46 coverage region of a node. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1 The Mapping Problem . . . . . . . . . . . . . . . . . . . 4 54 3.2 Overview of Operation . . . . . . . . . . . . . . . . . . 5 55 3.3 Seekers: The Users of the Mapping System . . . . . . . . . 5 56 3.4 Trees: Authoritative Knowledge . . . . . . . . . . . . . . 6 57 3.5 Forest Guides: Finding the Right Tree . . . . . . . . . . 7 58 3.6 Resolvers: Finding Forest Guides and Caching Data . . . . 7 59 3.7 Minimal System Architecture . . . . . . . . . . . . . . . 7 60 4. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1 Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 64 6.2 Answering Queries . . . . . . . . . . . . . . . . . . . . 10 65 6.3 Overlapping Coverage Regions . . . . . . . . . . . . . . . 10 66 6.4 Scaling and Reliability . . . . . . . . . . . . . . . . . 11 67 7. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. Configuring Emergency Dial Strings . . . . . . . . . . . . . 11 69 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 10.1 Normative References . . . . . . . . . . . . . . . . . . 14 72 10.2 Informative References . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 74 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . 16 77 1. Terminology 79 In this document, the key words "MUST", "MUSTNOT", "REQUIRED", 80 "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and 81 "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 82 indicate requirement levels for compliant implementations. 84 2. Definitions 86 [Note: The terminology below is still evolving and needs 87 refinement.] 89 In addition to the terms defined in [11], this document uses the 90 following terms to describe LUMP: 92 authoritative mapping server (AMS): Resolver that can provide the 93 authoritative answer to a particular set of queries, e.g., 94 covering a set of PIDF-LO civic labels or a particular region 95 described by a geometric shape. In some (rare) cases of 96 territorial disputes, two resolvers may be authoritative for the 97 same region. An AMS may redirect or forward a query to other AMS 98 within the tree. 99 caching resolver: A caching resolver is contacted by a seeker, 100 consults a forest mapping server and then resolves the query using 101 an appropriate tree. 102 child: A child is a resolver that is authoritative for a subregion of 103 a particular server. A child can in turn be parent. 104 cluster: A cluster is a group of resolver (servers) that all share 105 the same mapping information and return the same results for 106 queries. Clusters provide redundancy and share query load. 107 Clusters are fully-meshed, i.e., they all exchange updates with 108 each other. 109 complete: A civic mapping region is considered complete if it covers 110 a set of hierarchical labels in its entirety, i.e., there is no 111 other resolver that covers parts of the same region. (A complete 112 mapping may have children that cover strict subsets of this 113 region.) For example, a region spanning the whole country is 114 complete, but a region spanning only some of the streets in a city 115 is not. 116 forest guide: A forest guide has knowledge of the coverage region of 117 all trees. 118 hint: A hint provides a mapping from a region to a server name, used 119 to short-cut mapping operations. 120 mapping: A mapping is a short-hand for 'mapping from a location 121 object to one or more URLs describing either another mapping 122 server or the desired PSAP URLs.' 124 parent: A mapping server that covers the region of all of its 125 children. A mapping server without a parent is a root resolver. 126 peer: A resolver maintains associations other resolvers, called 127 peers. Peers synchronize their region maps. 128 seeker: The resolver, ESRP or end system requesting a mapping. 129 region map: A data object describing a contiguous area covered by a 130 resolver, either as a subset of a civic address or a geometric 131 object. 132 root region map: A data object describing a contiguous area covered 133 by a resolver, with no parent map. 134 resolver: The server providing (part of) the mapping service. 135 Resolvers cooperate to offer the mapping service to seekers. 136 tree: A tree consists of a hierarchy of authoritative mapping 137 servers. Each tree exports its coverage region to the forest 138 mapping servers. 140 3. Introduction 142 3.1 The Mapping Problem 144 One of the central problems of providing emergency services to 145 Internet systems is to map geographic location to a set of emergency 146 services, represented by PSAPs, that can provide assistance for that 147 particular location. This is a mapping problem, where a geographic 148 location is translated into a set of URIs that allow the Internet 149 system to contact an appropriate network entity. Other services may 150 also find such location-to-URI mappings of use. 152 The architecture separates mapping from placing calls or otherwise 153 invoking the service, so the same mechanism can be used to verify 154 that a mapping exists ("address validation") or to obtain test 155 service URIs. 157 Mapping locations to URIs describing services requires a distributed, 158 scalable and highly resilient infrastructure. Authoritative 159 knowledge about such mappings is distributed among a large number of 160 autonomous entities that may have no direct knowledge of each other. 161 In this document, we describe an architecture for such a global 162 service. It allows significant freedom to combine and split 163 functionality among actual servers and imposes few requirements as to 164 who should operate particular services. 166 Besides determining the PSAP URI, end systems also need to determine 167 the local emergency dial strings. As discussed in Section 8, the 168 architecture described here can also address that problem. 170 The architecture described below does not depend on a particular 171 mapping protocol, but naturally assumes that such protocols provide 172 certain features, such as the ability to discover the coverage region 173 of tree nodes. In this introduction, we describe the four 174 participants in the system at a high level. Each role will later be 175 introduced in more detail. 177 3.2 Overview of Operation 179 In short, end users of the mechanism, called seekers, contact 180 resolvers that cache query results and know one or more "forest 181 guides". Forest guides know the coverage region of trees and direct 182 queries to the node at the top of the appropriate tree. Trees 183 maintain the authoritative mapping information. Figure 1 shows the 184 interaction of the components. 186 /-\ /-\ +-----+ +-----+ 187 | S +******* R ********* FG *-----------------+ FG | 188 \-/ \-/ | |* | | 189 +--+--+ * +--+--+ 190 | * | 191 | * | 192 | * | 193 | * | 194 /-\ +--+--+ * +--+--+ 195 | R +------>+ FG +-----*-----------+ FG | 196 \-/ | | * | | 197 +--+--+ * +--+--+ 198 | * | 199 | * | 200 | * | 201 |*** ^ 202 / \ / \ 203 / \ / \ 204 / \ / \ 205 / \ / \ 206 ----------- ----------- 207 tree tree 209 Architecture diagram, showing seekers (S), resolvers (R), forest 210 guides (FG) and trees. The star (*) line indicates the flow of the 211 query and responses in recursive mode. 213 Figure 1 215 3.3 Seekers: The Users of the Mapping System 217 Clients desiring mappings are known as seekers. Thus, seekers are 218 the end users of the mapping information. Examples of such clients 219 include SIP proxy servers or SIP end systems wishing to place an 220 emergency call. Seekers provide location information describing a 221 small geographic area and obtain one or more URIs describing the 222 service. Seekers may need to obtain this information in several 223 steps, i.e., they may obtain pointers to intermediate servers that 224 lead them closer to the final mapping. Seekers MAY cache query 225 results for later use, but otherwise have no obligations to other 226 entities in the system. 228 3.4 Trees: Authoritative Knowledge 230 The architecture assumes that authoritative knowledge about the 231 mapping data is distributed among many independent administrative 232 entities, but clients (seekers) needing the information may 233 potentially need to find out mapping about any spot on earth. 234 (Extensions to extra-terrestrial applications are left for future 235 exploration.) Different types of services may divide responsibility 236 differently and are independent of each other. Each node 237 participating in the system has authoritative knowledge about 238 mappings within its coverage region, typically, but not necessarily, 239 a contiguous geographic region described by a polygon in geospatial 240 coordinates or a set of civic address descriptors (e.g., "country = 241 DE, A1 = Bavaria"). These coverage regions may be aligned with 242 political boundaries, but that is not required. In most cases, to 243 avoid confusion, only one node is responsible for a particular 244 geographic or civic location, but the system can also deal with cases 245 where coverage regions overlap. 247 The architecture assumes that knowledge about mappings is 248 hierarchical, represented as a tree. Each tree node knows the 249 coverage region of its children and sends queries to the appropriate 250 server "down" the tree. There are no assumptions about the coverage 251 region of a tree. For example, a tree could cover a single city, or 252 a state/province or a whole country. Nodes within a tree need to 253 loosely coordinate their operation, but they do not need to be 254 operated by the same administrator. 256 Thus, the mapping function for the world is divided among trees. The 257 collection of trees may not cover the whole world and trees are added 258 and removed as the organization of mapping data changes. We call the 259 collection of trees a forest. There is no limit on the number of 260 trees within the forest, but the author pictures that the number of 261 trees will likely be somewhere between a few hundred and a few 262 thousand. The lower estimate would apply if each country operates 263 one tree. We assume that tree coverage information changes 264 relatively slowly, on the order of a few changes per year per tree, 265 although the system imposes no specific threshold. (To be sure, 266 information within a tree is likely to change much more frequently.) 268 3.5 Forest Guides: Finding the Right Tree 270 Unfortunately, just having trees covering various regions of the 271 world is not sufficient as a client of the mapping protocol would not 272 generally be able to keep track of all the trees in the forest. To 273 facilitate orientation among the trees, we introduce a "forest 274 guide". It is a server that keeps track of the coverage regions of 275 the trees. For scalability and reliability, there will need to be a 276 large number of forest guides, all providing the same information. A 277 seeker can contact any forest guide and will then be directed to the 278 right tree or, rarely, set of trees. 280 3.6 Resolvers: Finding Forest Guides and Caching Data 282 A seeker can contact a forest guide directly, but may not be able to 283 easily locate such a guide. In addition, seekers in the same 284 geographic area may already have asked the same question. Thus, it 285 makes sense to introduce another entity, a resolver, that knows how 286 to contact one or more forest guides and caches earlier queries to 287 accelerate the response to mapping queries. 289 3.7 Minimal System Architecture 291 It is possible to build a functioning system consisting only of 292 seekers and resolvers if these resolvers have other means of 293 obtaining mapping data. For example, a company acting as a mapping 294 service provider could collect mapping records manually and make them 295 available to their customers through the resolver. While feasible as 296 a starting point, such an architecture is unlikely to scale globally. 297 Among other problems, it becomes very hard for providers of 298 authoritative data to ensure that all such providers have up-to-date 299 information. If new trees are set up, they would somehow make 300 themselves known to these providers. Such a mechanism would be 301 similar to the old "hosts.txt" mechanism for distributing host 302 information in the early Internet. 304 4. Seeker 306 Seekers are consumers of mapping data and originate queries. Seekers 307 do not answer queries. They contact either forest guides or 308 resolvers to find the appropriate tree that can authoritatively 309 answer their questions. As noted in the introduction, seekers can be 310 end systems or call routing entities such as SIP proxy servers. 312 Seekers need to be able to identify appropriate resolvers. The 313 mechanism for providing seekers with that information is likely to 314 differ depending on who operates the resolvers. For example, if the 315 voice service provider operates the resolver, it might include the 316 location of the resolver in the SIP configuration information it 317 distributes to its user agents. An Internet access provider might 318 provide a pointer to a resolver via DHCP. In an ad-hoc or zero- 319 configuration environment, appropriate service directories may 320 advertise resolvers. 322 For emergency calling, seekers could issue queries at boot time, 323 periodically when cached information expires or only when placing an 324 emergency call. It is probably unnecessary to continuously update 325 mapping information for seekers representing a small user population, 326 e.g., a single phone or residential SIP proxy. 328 Like other entities in the system, seekers can cache responses. This 329 is particularly useful if the response describes the result for a 330 region, not just a point. For example, for mobile nodes, seekers 331 would only have to update their resolution results when they leave 332 the coverage area of a PSAP and can avoid polling for this 333 information. This will likely be of particular benefit for seekers 334 representing a large user population, such as the outbound proxy in a 335 corporate network. For example, rather than having to query 336 separately for each cubicle, information provided by the 337 authoritative node may indicate that the whole campus is covered by 338 the same PSAP. 340 5. Resolver 342 Resolvers mediate between seekers and forest guides. Their primary 343 role is to avoid having seekers find forest guides on their own. 344 Unlike forest guides, resolvers do not store worldwide coverage maps, 345 but they may cache regions returned as part of query results. 347 As noted earlier, seekers can contact forest guides directly. From a 348 protocol perspective, a resolver acts in the same way as a seeker, 349 except that it knows one or more forest guide. 351 6. Trees 353 6.1 Basic Operation 355 As noted in the introduction, trees are the authoritative source of 356 mapping data. Each tree can map location information for one type of 357 service (such as 'police' or 'fire'), although nothing prevents re- 358 using the same tree for multiple different services. The collection 359 of trees for one service is known as a forest. 361 The tree architecture is similar to the domain name system, except 362 that delegation is not by label, but rather by region. 364 Tree nodes maintain two types of information, namely coverage regions 365 and mappings. Coverage regions describe the region served by a child 366 node in the tree and point to a child node for further resolution. 367 Mappings contain an actual service URI leading to a PSAP or another 368 signaling server representing a group of PSAPs. 370 Leaf nodes, i.e., nodes without children, only maintain mappings, 371 while tree nodes above the leaf nodes only maintain coverage regions. 372 An example of a leaf node entry is shown below, indicating how 373 queries for three towns are directed to different PSAPs. 375 country A1 A2 A3 resource 376 US NJ Bergen Leonia sip:psap@leonianj.gov 377 US NJ Bergen Fort Lee sip:emergency@fortleenj.org 378 US NJ Bergen Teaneck sip:police@teanecknjgov.org 379 .... 381 Coverage regions are described by sets of polygons enclosing 382 contiguous geographic areas or by descriptors enumerating groups of 383 civic locations. 385 For example, a state-level tree node for New Jersey in the United 386 States may contain the following coverage region entries, indicating 387 that any query matching a location in Bergen County, for example, 388 would be redirected or forwarded to the node located at 389 bergen.nj.example.org. There is no requirement that all child nodes 390 cover the same level within the civic hierarchy. For example, in the 391 table below, the city of Newark has decided to be listed directly 392 within the state node, rather than through the county. Longest-match 393 rules allow partial coverage, so that for queries for all other towns 394 within Essex county would be directed to the county node for further 395 resolution. 397 C A1 A2 A3 resource 398 US NJ Atlantic * lump://atlantic.nj.example.org/sos 399 US NJ Bergen * lump://bergen.nj.example.org/sos 400 US NJ Monmouth * lump://monmouth.nj.example.org/sos 401 US NJ Essex * lump://essex.nj.example.org/sos 402 US NJ Essex Newark lump://newark.example.com/sos 403 .... 405 Thus, there is no substantial difference between coverage region and 406 mapping data. The only difference is that coverage regions return 407 mapping protocol URLs, while mapping entries contain PSAP URLs. 408 Mapping entries may be specific down to the house or floor level or 409 may only contain street-level information. For example, in the 410 United States, civic mapping data is generally limited to address 411 ranges ("MSAG data"), so initial mapping databases may only contain 412 street-level information. 414 To automate operations, a suitable mapping protocol would thus need 415 to be able to query nodes for their coverage region. In the example 416 above, the state-run node would query the county nodes and thus 417 aggregagate the coverage data. Conversely, nodes could also contact 418 their parent nodes. There is some benefit of child nodes contacting 419 their parents, as this allows changes in coverage region to propagate 420 quickly up the tree. 422 6.2 Answering Queries 424 Within a tree, the basic operation is straightforward: A query 425 reaches the root of the tree. That node determines which coverage 426 region matches that request and forwards the request to the URL 427 indicated in the coverage region record, returning a response to the 428 querier when it in turns receives an answer (recursion). 429 Alternatively, the node returns the URL of that child node to the 430 querier. This process applies to each node, i.e., a node does not 431 need to know whether the original query came from a parent node, a 432 seeker, a forest guide or a resolver. 434 For efficiency, a node MAY return region information instead of a 435 point answer. Thus, instead of returning that a particular 436 geospatial coordinate maps to a service or mapping URL, it MAY return 437 a polygon indicating the region for which this answer would be 438 returned, along with expiration time (time-to-live) information. The 439 querying node can then cache this information for future use. 441 6.3 Overlapping Coverage Regions 443 In some cases, coverage regions may overlap, either because there is 444 a dispute as to who handles a particular geographic region or, more 445 likely, since the resolution of the coverage map may not be 446 sufficiently high. For example, a node may "shave some corners" off 447 its polygon, so that its coverage region appears to overlap with its 448 geographic neighbor. For civic coordinates, houses on the same 449 street may be served by different PSAPs. The mapping mechanism needs 450 to work even if a coverage map is imprecise or if there are disputes 451 about coverage. 453 The solution for overlapping coverage regions is relatively simple. 454 If a query matches multiple coverage regions, the node returns all 455 URLs, in redirection mode, or queries both children, if in recursive 456 mode. If the overlapping coverage is caused by imprecise coverage 457 maps, only one will return a result and the others will return an 458 error indication. If the particular location is disputed territory, 459 the response will contain all answers, leaving it to the querier to 460 choose the preferred solution or trying to contact all services in 461 turn. 463 6.4 Scaling and Reliability 465 Since they provide authoritative information, tree nodes need to be 466 highly reliable. Thus, while this document refers to tree nodes as 467 logical entities within the tree, an actual implementation would 468 likely replicate node information across several servers, forming a 469 cluster. Each such node would have the same information. Standard 470 techniques such as DNS SRV records can be used to select one of the 471 servers. Replication within the cluster can use any suitable 472 protocol mechanism, but a standardized incremental update mechanism 473 makes it easier to spread those nodes across multiple independently- 474 administered locations. The techniques developed for meshed SLP [7] 475 are applicable here. 477 7. Forest Guides 479 Forest guides distribute records describing the coverage region for 480 trees. For authenticity, the records are digitally signed. They are 481 used by resolvers and possibly seekers to find the appropriate tree 482 for a particular area. All forest guides should have consistent 483 information. A tree node at the top of a tree can contact any forest 484 guide and inject new coverage region information into the system. 485 Each forest guide peers with one or more other guides and distributes 486 new coverage region announcements to all other guides. 488 Forest guides fulfill a similar role to root servers in DNS. 489 However, their number is likely to be larger, possibly counted in 490 hundreds. They distribute information, signed for authenticity, 491 offered by trees. 493 Forest guides can, in principle, be operated by anybody, including 494 voice service providers, Internet access providers, dedicated 495 services providers and enterprises. 497 As in routing, peering with other forest guides implies a certain 498 amount of trust in the peer. Thus, peering is likely to require some 499 negotiation between the administering parties concerned, rather than 500 automatic configuration. The mechanism itself does not imply a 501 particular policy as to who gets to advertise a particular coverage 502 region. 504 8. Configuring Emergency Dial Strings 506 For the foreseeable future, some user devices and software will 507 emulate the user interface of a telephone, i.e., the only way to 508 enter call address information is via a 12-button keypad. Also, 509 emergency numbers are likely to used until essentially all 510 communication devices feature IP connectivity and an alphanumeric 511 keyboard. Unfortunately, more than 60 emergency numbers are in use 512 throughout the world, with many of those numbers serving non- 513 emergency purposes elsewhere, e.g., identifying repair or directory 514 services. Countries also occasionally change their emergency 515 numbers, for example, by selecting a number already in use in other 516 countries of a region (such as 112 in Europe). 518 Thus, a system that allows devices to be used internationally to 519 place emergency calls needs to allow devices to discover emergency 520 numbers automatically. In the system proposed, these numbers are 521 strictly of local significance and are generally not visible in call 522 signaling messages. 524 For simplicity of presentation, this section assumes that emergency 525 numbers are valid throughout a country, rather than, say, be 526 restricted to a particular city. This appears likely to be true in 527 countries likely to deploy IP-based emergency calling solutions. In 528 addition, the solution proposed also works if certain countries do 529 not use a national emergency number. There is no requirement that a 530 country uses a single emergency number for all emergency services, 531 such as fire, police, or rescue. 533 For the best user experience, systems should be able to discover two 534 sets of numbers, namely those used in the user's home country and in 535 the country the user is currently visiting. The user is most likely 536 to remember the former, but a companion borrowing a device in an 537 emergency may only know the local emergency numbers. 539 Determining home and local emergency numbers is a configuration 540 problem, but unfortunately, existing configuration mechanisms are 541 ill-suited for this purpose. For example, a DHCP server might be 542 able to provide the local emergency number, but not the home numbers. 543 Similarly, SIP configuration would be able to provide the numbers 544 valid at the location of the SIP service provider, but even a SIP 545 service provider with national footprint may serve customers that are 546 visiting any number of other countries. 548 Since dial strings are represented as URLs [5], the problem of 549 determining local and home emergency numbers is a problem of mapping 550 locations to a set of URLs, i.e., exactly the problem that the 551 mapping architecture is solving already. 553 The mapping operation is almost exactly the same as for determining 554 the emergency service URL. The only difference is that if a seeker 555 knows the civic location at least to the country level, it will use a 556 query where the PIDF-LO only includes the country code. If it only 557 knows its geospatial location, it has to include that longitude and 558 latitude. The querier uses the service identifiers "dialstring.sos", 559 "dialstring.sos.fire", etc. The resolver returns the appropriate set 560 of URLs and, if a geospatial location was used in the query, the 561 current region map for the country. 563 Within the mapping system, emergency calling regions are global 564 information, i.e., they are distributed using the forest guide 565 replication mechanism described earlier. Thus, every forest guide 566 has access to all region mappings. This makes it possible that a 567 querier can ask any resolver for this information, reducing the 568 privacy threat of revealing its location outside of an emergency 569 call. The privacy threat is further reduced by the long-lived nature 570 of the information, i.e., in almost all cases, the querier will have 571 already cached the national boundary information or country 572 information on its first visit to the country. 574 9. Security 576 The architecture addresses the following security issues, usually 577 through the underlying transport security associations: 579 Server impersonation: Queriers, cluster members and peers can assure 580 themselves of the identity of the remote party by using the 581 facilities in the underlying channel security mechanism, such as 582 TLS. 583 Query or query result corruption: To avoid that an attacker can 584 modify the query or its result, the architecture RECOMMENDS the 585 use of channel security, such as TLS. 586 Region corruption: To avoid that a third party or an untrustworthy 587 member of a server population introduces a region map that it is 588 not authorized for, any node introducing a new region map MUST 589 sign the object by encapsulating the data into a CMS wrapper. A 590 recipient MUST verify, through a local policy mechanism, that the 591 signing entity is indeed authorized to speak for that region. 592 Determining who can speak for a particular region is inherently 593 difficult unless there is a small set of authorizing entities that 594 participants in the mapping architecture can trust. Receiving 595 systems should be particularly suspicious if an existing region 596 map is replaced with a new one with a new mapping address. In 597 many cases, trust will be mediated: A seeker will have a trust 598 relationship with a resolver. The resolver, in turn, will contact 599 a trusted forest guide. 601 Additional threats that need to be addressed by operational measures 602 include denial-of-service attacks. 604 10. References 606 10.1 Normative References 608 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 609 Levels", BCP 14, RFC 2119, March 1997. 611 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 612 March 1997. 614 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 615 specifying the location of services (DNS SRV)", RFC 2782, 616 February 2000. 618 [4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 619 draft-ietf-geopriv-pidf-lo-03 (work in progress), 620 September 2004. 622 [5] Rosen, B., "Dialstring parameter for the sip URI", 623 draft-rosen-iptel-dialstring-02 (work in progress), July 2005. 625 10.2 Informative References 627 [6] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 628 Location Protocol, Version 2", RFC 2608, June 1999. 630 [7] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced 631 Service Location Protocol (mSLP)", RFC 3528, April 2003. 633 [8] Newton, A. and M. Sanz, "IRIS: The Internet Registry 634 Information Service (IRIS) Core Protocol", RFC 3981, 635 January 2005. 637 [9] Krochmal, M. and S. Cheshire, "DNS-Based Service Discovery", 638 draft-cheshire-dnsext-dns-sd-03 (work in progress), July 2005. 640 [10] Petrie, D., "A Framework for Session Initiation Protocol User 641 Agent Profile Delivery", draft-ietf-sipping-config-framework-07 642 (work in progress), July 2005. 644 [11] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 645 Context Resolution with Internet Technologies", 646 draft-schulzrinne-ecrit-requirements-01 (work in progress), 647 July 2005. 649 Author's Address 651 Henning Schulzrinne 652 Columbia University 653 Department of Computer Science 654 450 Computer Science Building 655 New York, NY 10027 656 US 658 Phone: +1 212 939 7004 659 Email: hgs+ecrit@cs.columbia.edu 660 URI: http://www.cs.columbia.edu 662 Appendix A. Acknowledgments 664 Richard Stastny, ... provided helpful comments. 666 Intellectual Property Statement 668 The IETF takes no position regarding the validity or scope of any 669 Intellectual Property Rights or other rights that might be claimed to 670 pertain to the implementation or use of the technology described in 671 this document or the extent to which any license under such rights 672 might or might not be available; nor does it represent that it has 673 made any independent effort to identify any such rights. Information 674 on the procedures with respect to rights in RFC documents can be 675 found in BCP 78 and BCP 79. 677 Copies of IPR disclosures made to the IETF Secretariat and any 678 assurances of licenses to be made available, or the result of an 679 attempt made to obtain a general license or permission for the use of 680 such proprietary rights by implementers or users of this 681 specification can be obtained from the IETF on-line IPR repository at 682 http://www.ietf.org/ipr. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary 686 rights that may cover technology that may be required to implement 687 this standard. Please address the information to the IETF at 688 ietf-ipr@ietf.org. 690 Disclaimer of Validity 692 This document and the information contained herein are provided on an 693 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 694 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 695 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 696 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 697 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 698 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 700 Copyright Statement 702 Copyright (C) The Internet Society (2005). This document is subject 703 to the rights, licenses and restrictions contained in BCP 78, and 704 except as set forth therein, the authors retain all their rights. 706 Acknowledgment 708 Funding for the RFC Editor function is currently provided by the 709 Internet Society.