idnits 2.17.1 draft-schulzrinne-ecrit-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 751. ** 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 199 has weird spacing: '...ss: The sip:u...' == Line 325 has weird spacing: '...ties of curre...' == 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 (May 2005) is 6921 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 683, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 701, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-01) exists of draft-tschofenig-ecrit-security-threats-00 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: November 2, 2005 R. Marshall, Ed. 5 TCS 6 May 2005 8 Requirements for Emergency Context Resolution with Internet Technologies 9 draft-schulzrinne-ecrit-requirements-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document enumerates requirements for emergency calls placed by 43 the public using voice-over-IP (VoIP) and general Internet multimedia 44 systems, where Internet protocols are used end-to-end. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. High-Level Requirements . . . . . . . . . . . . . . . . . . 9 51 4. Emergency Address . . . . . . . . . . . . . . . . . . . . . 11 52 5. Identifying the Caller Location . . . . . . . . . . . . . . 12 53 6. Identifying the Appropriate PSAP . . . . . . . . . . . . . . 13 54 7. Emergency Address Directory . . . . . . . . . . . . . . . . 16 55 8. Supplemental Information . . . . . . . . . . . . . . . . . . 17 56 9. Security Considerations . . . . . . . . . . . . . . . . . . 18 57 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 58 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 59 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 60 12.1 Normative References . . . . . . . . . . . . . . . . . . 21 61 12.2 Informative References . . . . . . . . . . . . . . . . . 21 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 63 Intellectual Property and Copyright Statements . . . . . . . 23 65 1. Introduction 67 Users of telephone-like services expect to be able to call for 68 emergency help, such as police, the fire department or an ambulance, 69 regardless of where they are, what (if any) service provider they are 70 using and what kind of device they are using. Unfortunately, the 71 mechanisms for emergency calls that have evolved in the public 72 circuit-switched telephone network (PSTN) are not quite appropriate 73 for evolving IP-based voice, text and real-time multimedia 74 communications. This document outlines the key requirements that end 75 systems and network elements such as SIP proxies need to satisfy in 76 order to provide emergency call services that offer at least the same 77 functionality as existing PSTN services, with the goal of making 78 emergency calling more robust, cheaper to implement and multimedia- 79 capable. 81 In the future, users of other real-time and near real-time services 82 may also expect to be able to summon emergency help. For example, 83 instant messaging (IM) users may want to use such services. IM is 84 particularly helpful for hearing-disabled users (RFC 3351 [4]) and in 85 cases where bandwidth is scarce. 87 This document only focuses on end-to-end IP-based calls, i.e., where 88 the emergency call originates from an IP end system, (Internet 89 device), and terminates to an IP-capable PSAP, done entirely over an 90 IP network. 92 This document identifies functional and security issues for 93 determining the correct emergency identifier, for identifying the 94 appropriate PSAP (emergency address) and for identifying the caller 95 and its current location. 97 Emergency calls need to be identified (Section 6). Emergency 98 identifiers are used by the emergency caller to declare a call to be 99 an emergency call. The device MUST recognize the emergency 100 identifiers used and convert them to an emergency address to guide 101 the call to a PSAP. The emergency address MUST be a predefined 102 "sip", "sips" or "tel" URI scheme. 104 Emergency calls need to be routed to the appropriate PSAP (ref. 105 Section 6). Several terms are used for causing the call signaling to 106 reach the geographically appropriate PSAP. This has been referred to 107 as call routing, (PSAP) lookup or location mapping, all capturing 108 aspects of the problem. 110 Emergency calls need to identify who placed the call (Section 7). In 111 most jurisdictions, callers do not have a choice as to whether they 112 want to reveal their location or identity; such disclosure is 113 typically mandated by law. 115 Emergency calls need to identify the location from which the call is 116 initiated (Section 5). The caller location needs to be identified 117 for two purposes, namely to route the call to the appropriate PSAP 118 and to display the caller location to the call taker to simplify 119 dispatching emergency assistance to the correct location. 121 Emergency calls may not be subject to access restrictions placed on 122 non-emergency calls. Also, some call features may interfere with 123 emergency calls, particularly if triggered accidentally (Section 7). 125 2. Terminology 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 130 indicate requirement levels for compliant implementations. 132 Since a requirements document does not directly specify an implement 133 able protocol, these compliance labels should be read as indicating 134 requirements for the protocol or architecture, rather than an 135 implementation. 137 For lack of a better term, we will use the term "caller" or 138 "emergency caller" to refer to the person placing an emergency call 139 or sending an emergency IM. 141 Access Infrastructure Provider (AIP): An organization that provides 142 physical network connectivity to its customers or users, e.g. 143 through digital subscriber lines, cable TV plants, Ethernet, 144 leased lines or radio frequencies. This entity may or may not 145 also provide IP routing, IP addresses, or other Internet protocol 146 services. Examples of such organizations include 147 telecommunication carriers, municipal utilities, larger 148 enterprises with their own network infrastructure, and government 149 organizations such as the military. 151 [Ed. AIP vs. IAP vs. ? not yet clear as to general agreement on a 152 single term.] 154 address: A description of a location of a person, organization, or 155 building, most often consisting of numerical and text elements 156 such as street number, street name, and city arranged in a 157 particular format. 159 administrative domain: An area or group of services falling with in a 160 specific category or jurisdictional boundary. 162 Application (Voice) Service Provider (ASP, VSP): The organization 163 that provides voice or other application-layer services, such as 164 call routing, a SIP URI or PSTN termination. This organization 165 can be a private individual, an enterprise, a government or a 166 service provider. We avoid the term voice service provider as 167 emergency calls are likely to use other media, including text and 168 video, in the future. For a particular user, the ASP may not be 169 the same organization as the AIP or ISP. 171 Basic Emergency Service: Basic Emergency Service allows a user to 172 reach a PSAP serving its current location, but the PSAP may not be 173 able to determine the identity or geographic location of the 174 caller (except by having the call taker ask the caller). 176 call taker: A call taker is an agent at the PSAP that accepts calls 177 and may dispatch emergency help. (Sometimes the functions of call 178 taking and dispatching are handled by different groups of people, 179 but these divisions of labor are not generally visible to the 180 outside and thus do not concern us here.) 182 civic location: A described location based on some defined grid, such 183 as a jurisdictional, postal, metropolitan, or rural reference 184 system (e.g. street address). 186 domain authentication and validation entity: A node that has 187 authority within a given domain to authenticate and validate user 188 location information. 190 Emergency Control Center (ECC): Facilities used by emergency 191 organizations to accept and handle emergency calls. A PSAP 192 (below) forwards emergency calls to the emergency control center, 193 which dispatches police, fire, rescue and other emergency 194 services. An ECC serves a limited geographic area. A PSAP and 195 ECC can be combined into one facility (ETSI SR 002 180 196 definition). We assume that the ECC is reachable by IP-based 197 protocols, such as SIP for call signaling and RTP for media. 199 emergency address: The sip:uri, sips:uri, or tel:uri which 200 represents the network address of the PSAP useful for the 201 completion of a VoIP emergency call. 203 emergency caller: The user or user device entity which sends his/her 204 location to another entity in the network. 206 emergency identifier: The numerical and/or text identifier which is 207 supplied by a user or a user device, which identifies the call as 208 an emergency call and is translated into an emergency address for 209 call routing and completion. 211 enhanced emergency service: Enhanced emergency services add the 212 ability to identify the caller identity and/or caller location to 213 basic emergency services. (Sometimes, only the caller location 214 may be known, e.g. from a public access point that is not owned by 215 an individual.) 217 ESRP (Emergency Services Routing Proxy): An ESRP is a call routing 218 entity that invokes the location-to-URL mapping, which in turn may 219 return either the URL for another ESRP or the PSAP. (In a SIP 220 system, the ESRP would typically be a SIP proxy, but could also be 221 a Back-to-back user agent (B2BUA). 223 geocoding: The process of finding the location of a street address on 224 a map. The location can be an x,y coordinate or a feature such as 225 a street segment, postal delivery location, or building. In GIS, 226 geocoding requires a reference dataset that contains address 227 attributes for the geographic features in the area of interest. 229 geographic coordinates: A representation (measurement) of a location 230 on the earth's surface expressed in degrees of latitude and 231 longitude. 233 geographic coordinate system: A reference system that uses latitude 234 and longitude to define the locations of points on the surface of 235 a sphere or spheroid. 237 geographic transformation: A method of converting data between two 238 geographic coordinate systems (datums). 240 geographic location: A reference to a locatable point described by a 241 set of defined coordinates within a geographic coordinate system, 242 (e.g. lat/lon within WGS-84 datum) 244 Internet Service Provider (ISP): An organization that provides IP 245 network-layer services to its customers or users. This entity may 246 or may not provide the physical-layer and layer-2 connectivity, 247 such as fiber or Ethernet. 249 location: A geographic identification assigned to a region or feature 250 based on a specific coordinate system, or by other precise 251 information such as a street address. In the geocoding process, 252 the location is defined with an x,y coordinate value according to 253 the distance north or south of the equator and east or west of the 254 prime meridian. 256 Location Key (LK): A key identifier used to query a location server 257 in order to retrieve a specific end user or end user device 258 location. 260 location validation: A caller location is considered valid if the 261 civic or geographic location is recognizable within an acceptable 262 location reference systems (e.g. USPS, WGS84, etc.), and can be 263 mapped to one or more PSAPs. Location validation ensures that a 264 location is reference able, but makes no assumption about the 265 association between the caller and the caller's location. 267 PSAP (Public Safety Answering Point): Physical location where 268 emergency calls are received under the responsibility of a public 269 authority. (This terminology is used by both ETSI, in ETSI SR 002 270 180, and NENA.) In the United Kingdom, PSAPs are called Operator 271 Assistance Centres, in New Zealand Communications Centres. Within 272 this document, it is assumed, unless stated otherwise, that PSAP 273 is that which supports the receipt of emergency calls over IP. It 274 is also assumed that the PSAP is reachable by IP-based protocols, 275 such as SIP for call signaling and RTP for media. 277 x,y coordinates: A pair of values that represents the distance from 278 an origin (0,0) along two axes, a horizontal axis (x) representing 279 east-west, and a vertical axis (y) representing north-south. On a 280 map, x,y coordinates are used to represent features at the 281 location they are found on the earth's spherical surface. 283 3. High-Level Requirements 285 Below, we summarize high-level architectural requirements that guide 286 some of the component requirements detailed later in the document. 288 R1. Application Service Provider: The existence of a Application 289 Service Provider (ASP) MUST NOT be assumed. 291 Motivation: The caller may not have a voice service provider, 292 i.e., a corporate entity that provides voice services as a 293 business. For example, a residence may have its own DNS domain 294 and run its own SIP proxy server for that domain. On a larger 295 scale, a university might provide voice services to its students 296 and staff, but not be a telecommunication provider. 298 R2. International: The protocols and protocol extensions developed 299 MUST support regional, political and organizational differences. 301 Motivation: It MUST be possible for a device or software developed 302 or purchased in one country to place emergency calls in another 303 country. System components should not be biased towards a 304 particular set of emergency numbers or languages. Also, different 305 countries have evolved different ways of organizing emergency 306 services, e.g. either centralizing them or having smaller regional 307 subdivisions such as United States counties or municipalities 308 handle emergency calls. 310 R3. Distributed Administration: Deployment of emergency services 311 MUST NOT depend on a sole central administration authority. 313 Motivation: Once common standards are established, it must be 314 possible to deploy and administer emergency calling features on a 315 regional or national basis without requiring coordination with 316 other regions or nations. The system cannot assume, for example, 317 that there is a single global entity issuing certificates for 318 PSAPs, ASPs, AIPs or other participants. 320 R4. Multiple Modes: Multiple communication modes, including 321 Multimedia data and services MUST be supported. 323 Motivation: Emergency calling must support a variety of media, not 324 just voice and TDD (telecommunication device for the deaf) beyond 325 the capabilities of current limitations. Such additional media 326 should include conversational text, instant messaging and video. 327 In addition, it should be possible to convey telemetry data, such 328 as data from automobile crash sensors. 330 R5. Minimum Connectivity: An emergency call should succeed as long 331 as there is a working network path between the caller and the 332 PSAP. In particular, reliance during call set-up and calls on 333 entities and network paths that are located elsewhere should be 334 minimized. 336 Example: A caller in New York who needs to contact a PSAP in the 337 same city shouldn't have to get information from some entity in 338 Texas to make that call, as the call would then fail if the New 339 York to Texas path is unavailable. (To avoid this, the caller 340 could, for example, have cached mapping information, use a local 341 server that has the necessary information, or use other mechanisms 342 to avoid such off-path dependencies.) 344 [Ed. No resolution yet agreed to for the above requirement.] 346 R6. Incremental Deployment The output of the ECRIT mapping protocol 347 will be one or more URIs that can be used as the target of an 348 emergency communication. These must be usable by an appropriately 349 capable device even if that device has no knowledge of the mapping 350 protocol. As an example, if the mapping protocol returns a SIP 351 URI any SIP-capable phone should be able to use it as a target of 352 the call; no special extension to SIP should be required. 354 4. Emergency Address 356 A1. Universal: Each device and all network elements MUST recognize 357 one or more universal (global) emergency identifiers, regardless 358 of the location of the device, the service provider used (if any) 359 or other factors. Examples of these might include: 911, 112, and 360 sos.* 362 Motivation: SIP and other call signaling protocols are not 363 specific to one country or service provider and devices are likely 364 to be used across national or service provider boundaries. Since 365 services such as disabling mandatory authentication for emergency 366 calls requires the cooperation of outbound proxies, the outbound 367 proxy has to be able to recognize the emergency address and be 368 assured that it will be routed as an emergency call. Thus, a 369 simple declaration on a random URI that it is an emergency call 370 will likely lead to fraud and possibly attacks on the network 371 infrastructure. A universal address also makes it possible to 372 create user interface elements that are correctly configured 373 without user intervention. UA features could be made to work 374 without such an identifier, but the user interface would then have 375 to provide an unambiguous way to declare a particular call an 376 emergency call. 378 A3. Recognizable: Emergency calls MUST be recognizable by user 379 agents, proxies and other network elements. To prevent fraud, an 380 address identified as an emergency number for call features or 381 authentication override MUST also cause routing to a PSAP. 383 A4. Minimal configuration: Any local emergency identifiers SHOULD be 384 configured automatically, without user intervention. 386 Motivation: A new UA "unofficially imported" into an organization 387 from elsewhere should have the same emergency capabilities as one 388 officially installed. 390 A6. Backwards-compatible: Existing devices that predate the 391 specification of emergency call-related protocols and conventions 392 MUST be able reach a PSAP. 394 5. Identifying the Caller Location 396 This section supplements the requirements outlined in RFC 3693 [5]. 397 Thus, the requirements enumerated there are not repeated here. In 398 general, we can distinguish three modes of operation: 400 UA-inserted: The caller's user agent inserts the location 401 information, derived from sources such as GPS, DHCP or link-layer 402 announcements (LLDP). 404 UA-referenced: The caller's user agent provides a reference, via a 405 permanent or temporary identifier, to the location which is stored 406 by a location service somewhere else and then retrieved by the 407 PSAP. 409 Proxy-inserted: A proxy along the call path inserts the location or 410 location reference. 412 L6. Validation of civic location: It MUST be possible to validate an 413 address prior to its use in an actual emergency call. 415 Motivation: Location validation refers to a process to determine 416 whether or not a given civic location is valid or not. A location 417 is said to be valid if it can be mapped exactly to a unique 418 emergency address for a PSAP, known to the emergency services 419 directory/mapping database. 421 L10. Preferred datum: The preferred geographic coordinate system for 422 emergency calls SHALL be WGS-84. 424 L28. Location Provided: If location is provided to the routing 425 proxy, it MUST be provided to the PSAP. 427 Motivation: Transmission of the current location of the 428 contacting device to the PSAP. 430 6. Identifying the Appropriate PSAP 432 From the previous section, we take the requirement of a single (or 433 small number of) emergency addresses which are independent of the 434 caller's location. However, since for reasons of robustness, 435 jurisdiction and local knowledge, PSAPs only serve a limited 436 geographic region, having the call reach the correct PSAP is crucial. 437 While a PSAP may be able to transfer an errant call, any such 438 transfer is likely to add tens of seconds to call setup latency and 439 is prone to errors. (In the United States, there are about 6,100 440 PSAPs.) 442 There appears to be two basic architectures for translating an 443 emergency identifier into the correct PSAP emergency address. We 444 refer to these as caller-based and mediated. In caller-based 445 resolution, the caller's user agent consults a directory and 446 determines the correct PSAP based on its location. We assume that 447 the user agent can determine its own location, either by knowing it 448 locally or asking some third party for it. A UA could conceivably 449 store a complete list of all PSAPs across the world, but that would 450 require frequent synchronization with a master database as PSAPs 451 merge or jurisdictional boundaries change. 453 For mediated resolution, a call signaling server, such as a SIP 454 (outbound) proxy or redirect server performs this function. Note 455 that the latter case includes the architecture where the call is 456 effectively routed to a copy of the database, rather than having some 457 non-SIP protocol query the database. Since servers may be used as 458 outbound proxy servers by clients that are not in the same geographic 459 area as the proxy server, any proxy server has to be able to 460 translate any caller location to the appropriate PSAP. (A traveler 461 may, for example, accidentally or intentionally configure its home 462 proxy server as its outbound proxy server, even while far away from 463 home.) 465 The resolution may take place well before the actual emergency call 466 is placed, or at the time of the call. 468 The problem is harder than for traditional web or email services. 469 There, the originator knows which entity it wants to reach, 470 identified by the email address or HTTP URL. However, the emergency 471 caller only dialed an emergency identifier. Depending on the 472 location, any of several ten thousand PSAPs around the world could be 473 valid. In addition, the caller probably does not care which specific 474 PSAP answers the call, but rather that it be an accredited PSAP, e.g. 475 one run by the local government authorities. (Many PSAPs are run by 476 private entities. For example, universities and corporations with 477 large campuses often have their own emergency response centers.) 478 I1. Correct PSAP: Calls Must be routed to the PSAP responsible for 479 this particular geographic area. 481 Motivation: In particular, the location determination should not 482 be fooled by the location of IP telephony gateways or dial-in 483 lines into a corporate LAN (and dispatch emergency help to the 484 gateway or campus, rather than the caller), multi-site LANs and 485 similar arrangements. 487 I3. Multi-stage resolution: A mapping server for a large geographic 488 area SHOULD be able to refer clients to mapping servers 489 responsible for subsets of the geographic area. 491 Motivation: In some cases, an initial mapping may provide a single 492 URL for a large geographic area. The ESRP identified by that URL 493 then re-invokes the mapping protocol on a different database to 494 obtain another URL for an ESRP or PSAP covering a smaller area. 496 I4. Return multiple PSAPs: The mapping protocol MUST be able to 497 return multiple URLs for different PSAPs that cover the same area. 499 The mapping protocol MUST provide additional information that 500 allows the querying entity to determine relevant properties of the 501 URL. 503 Motivation: In some cases, the same geographic area is served by 504 several PSAPs, for example, a corporate campus might be served by 505 both a corporate security department and the municipal PSAP. The 506 mapping protocol should then return URLs for both, with 507 information allowing the querying entity to choose one or the 508 other. The choice would typically be made by an ESRP based on 509 local policy, not by a human user. 511 I7. Traceable resolution: The entity requesting mapping SHOULD be 512 able to definitively and securely determine the entity or entities 513 who provided the emergency address resolution information. 515 I8. Resilience against server failure: A client MUST be able to fail 516 over to another replica of the mapping server, so that a failure 517 of a server does not endanger the ability to perform the mapping. 519 I10. Incrementally deployable: The mapping function MUST be capable 520 of being deployed incrementally. It must not be necessary, for 521 example, to have a global street level database before deploying 522 the system. It is acceptable to have some misrouting of calls 523 when the database does not (yet) contain accurate boundary 524 information. 526 I13. Existing infrastructure support: It SHOULD be possible for the 527 mapping function to provide information that allows the requesting 528 entity to determine if ecrit compatible emergency call support is 529 available in the jurisdiction where the location is proferred for 530 mapping. Where ecrit compatible emergency calling is NOT 531 available, the mapping function MAY yield information which could 532 be used to route emergency calls using existing, country specific 533 methods. For example, a tel URI may be provided for a PSTN routed 534 call, or a routing code which has meaning only within a country 535 specific routing mechanism. 537 I25. Mapping can be requested from anywhere: The mapping protocol 538 MUST be able to provide the mapping regardless of where the 539 querier is located, either geographically or by network location. 541 Motivation: The querier, such as the ESRP, may not necessarily be 542 anywhere close to the caller or the appropriate PSAP, but must 543 still be able to obtain a mapping. 545 I31: In response to a mapping request, a server will normally provide 546 a URI or set of URIs for contacting the appropriate PSAP. The 547 protocol must also be to return a URI or contact method explicitly 548 marked as an alternate contact. When this is used will be 549 described in an operational document. 551 I39: It SHOULD be possible to have updates of location (which may 552 occur when measuring devices provider early, but imprecise "first 553 fix" location) which can change routing of calls. 555 I40. The mapping protocol MUST be extensible to allow for the 556 inclusion of new location fields. 558 Motivation: This is needed, for example, to accommodate future 559 extensions to location information that might be included in the 560 PIDF-LO. 562 I41. Split responsibility: The mapping protocol MUST allow that 563 within a single level of the civic address hierarchy, multiple 564 mapping servers handle subsets of the data elements. 566 Motivation: For example, two directories for the same city or 567 county may handle different streets within that city or county. 569 I42. The mapping function MUST be able to be invoked at any time, 570 including while an emergency call is in process. 572 7. Emergency Address Directory 574 D1. PSAP Identification: The mapping information MUST be available 575 without having to enroll with a service provider. 577 Motivation: The mapping server may well be operated by a service 578 provider, but access to the server offering the mapping MUST NOT 579 require use of a specific ISP or VSP. 581 D5. Call setup latency: The directory lookup SHOULD minimize any 582 added delay to the call setup. 584 Motivation: Since outbound proxies will likely be asked to 585 resolve the same geographic coordinates repeatedly, a suitable 586 time-limited caching mechanism should be supported. 588 D7. Referral: The querier MUST be able to contact any server and be 589 referred to another server that is more qualified to answer the 590 query. 592 Motivation: This requirement alleviates the potential for 593 misconfigurations to cause calls to fail, particularly for caller- 594 based queries. 596 D9. Baseline query protocol: A mandatory-to-implement protocol MUST 597 be specified. 599 Motivation: An over-abundance of similarly-capable choices 600 appears undesirable for interoperability. 602 8. Supplemental Information 604 SD1 The format both of the query and of the result returned by the 605 protocol must be extensible to accommodate new types of 606 information. 608 Motivation: In addition to information sent with the call, 609 additional information may be available, supplemental to the call, 610 which is retrieved from internal or external databases using a key 611 to the information included with the call. This key may also 612 include information to identify/address the database. 614 SD2 Additional information MAY be available to the call taker based 615 on the location of the caller. 617 SD3 Additional information MAY be available to the call taker based 618 on the owner of the structure. 620 SD4 Additional information MAY be available to the call taker based 621 on the tenant of the structure. 623 SD5 Where a vehicle is involved, additional information MAY be 624 available. 626 SD6 Additional information MAY be available based on the Address of 627 Record (AoR) of the caller. In this context, AoR equates to the 628 caller. 630 SD7 Consideration SHOULD be given to permitting users to have domain 631 independent mechanisms to supply information related to the 632 caller, for example, another datum related to user. 634 SD8. Additional Data: Transfer of additional data SHOULD be 635 supported. 637 Motivation: Capabilities to contact PSAP by automatic means and 638 for the transfer of additional information (alarm equipment, cars, 639 buses, trucks with dangerous loads, ...) 641 SD9 Mechanism MUST be provided to automatically generate and provide 642 misroute and location error reports. 644 9. Security Considerations 646 Note: Security Considerations are referenced in the ECRIT security 647 document [3]. 649 10. Contributors 651 The information contained in this document is a result of a joint 652 effort based on individual contributions by those involved in the 653 ECRIT WG. The contributors include Nadine Abbott, Hideki Arai, 654 Martin Dawson, Motoharu Kawanishi, Brian Rosen, Richard Stastny, 655 Martin Thomson, James Winterbottom. 657 The contributors can be reached at: 659 Nadine Abbott nabbott@telcordia.com 661 Hideki Arai arai859@oki.com 663 Martin Dawson mdawson@nortelnetworks.com 665 Motoharu Kawanishi kawanishi381@oki.com 667 Brian Rosen br@brianrosen.net 669 Richard Stastny Richard.Stastny@oefeg.at 671 Martin Thomson marthom@nortelnetworks.com 673 James Winterbottom winterb@nortelnetworks.com 675 11. Acknowledgments 676 12. References 678 12.1 Normative References 680 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 681 Levels", BCP 14, RFC 2119, March 1997. 683 [2] Polk, J., "Requirements for Session Initiation Protocol Location 684 Conveyance", draft-ietf-sipping-location-requirements-02 (work 685 in progress), October 2004. 687 [3] Tschofenig, H., "Security Threats and Requirements for Emergency 688 Calling", draft-tschofenig-ecrit-security-threats-00 (work in 689 progress), May 2005. 691 12.2 Informative References 693 [4] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van 694 Wijk, "User Requirements for the Session Initiation Protocol 695 (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired 696 Individuals", RFC 3351, August 2002. 698 [5] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 699 Polk, "Geopriv Requirements", RFC 3693, February 2004. 701 [6] National Emergency Number Assocation, "NENA technical 702 information document on the interface between the E9-1-1 service 703 providers network and the Internet protocol (IP) PSAP", 704 NENA NENA-08-501, February 2003. 706 Authors' Addresses 708 Henning Schulzrinne 709 Columbia University 710 Department of Computer Science 711 450 Computer Science Building 712 New York, NY 10027 713 US 715 Phone: +1 212 939 7004 716 Email: hgs+ecrit@cs.columbia.edu 717 URI: http://www.cs.columbia.edu 718 Roger Marshall (editor) 719 TeleCommunication Systems 720 2401 Elliott Avenue 721 2nd Floor 722 Seattle, WA 98121 723 US 725 Phone: +1 206 792 2424 726 Email: rmarshall@telecomsys.com 727 URI: http://www.telecomsys.com 729 Intellectual Property Statement 731 The IETF takes no position regarding the validity or scope of any 732 Intellectual Property Rights or other rights that might be claimed to 733 pertain to the implementation or use of the technology described in 734 this document or the extent to which any license under such rights 735 might or might not be available; nor does it represent that it has 736 made any independent effort to identify any such rights. Information 737 on the procedures with respect to rights in RFC documents can be 738 found in BCP 78 and BCP 79. 740 Copies of IPR disclosures made to the IETF Secretariat and any 741 assurances of licenses to be made available, or the result of an 742 attempt made to obtain a general license or permission for the use of 743 such proprietary rights by implementers or users of this 744 specification can be obtained from the IETF on-line IPR repository at 745 http://www.ietf.org/ipr. 747 The IETF invites any interested party to bring to its attention any 748 copyrights, patents or patent applications, or other proprietary 749 rights that may cover technology that may be required to implement 750 this standard. Please address the information to the IETF at 751 ietf-ipr@ietf.org. 753 Disclaimer of Validity 755 This document and the information contained herein are provided on an 756 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 758 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 759 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 760 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 Copyright Statement 765 Copyright (C) The Internet Society (2005). This document is subject 766 to the rights, licenses and restrictions contained in BCP 78, and 767 except as set forth therein, the authors retain all their rights. 769 Acknowledgment 771 Funding for the RFC Editor function is currently provided by the 772 Internet Society.