dnsext B. Rosen Internet-Draft Marconi Expires: July 1, 2004 January 2004 Emergency Call Information in the Domain Name System draft-rosen-dns-sos-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Location of a caller is essential to processing an emergency call. Location is needed to correctly route the call, and to correctly dispatch help to the right place. Location can be specified in geographic (lat/lon/altitude) or civil (country/provin ce/city/ street/floor/room) forms. Determining which Emergency Response Center (ERC) should receive the call requires comparing the callers location to a service area boundary description, which may require location in geo form. Dispatching a call generally requires a civil location. There is a need for a way to translate a civil to a geo or vice versa to the resolution of a room. There is also a need to publish the service area boundary of the ERC and the emergency responders. Further, there is a need for a database of legal civil addresses (sometimes called a Master Street Address Guide) that civil Rosen Expires July 1, 2004 [Page 1] Internet-Draft Emergency Call Info in the DNS January 2004 locations may be verified against to assure correctness, and uniformity of naming so that dispatch is accurate. The memo proposes a new DDDS application and a new POLY RR to assist emergency calls. Those who believe that this is a misuse of the DNS are invited to look at the discussion in Section 8 on how it is possible that this idea is realized in a completely separate database not connected to the real DNS, but using the same architecture, protocols and data structures. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the Solution . . . . . . . . . . . . . . . . . . 5 4. POLY RR . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 IANA Registration for POLY Format . . . . . . . . . . . . . 10 5. The SOS Application Specifications . . . . . . . . . . . . . 10 5.1 Application Unique String . . . . . . . . . . . . . . . . . 10 5.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 10 5.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 10 5.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 10 5.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 11 5.5 What constitutes an 'Sos Resolver'? . . . . . . . . . . . . 12 6. Registration mechanism for sosservices . . . . . . . . . . . 12 6.1 Registration Requirements . . . . . . . . . . . . . . . . . 12 6.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 13 6.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 13 6.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 13 6.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 13 6.2 Registration procedure . . . . . . . . . . . . . . . . . . . 14 6.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 14 6.2.2 Initial Registrations . . . . . . . . . . . . . . . . . . . 14 7. Obscuring Lower Level Information . . . . . . . . . . . . . 16 8. Notes and things to do . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 19 Rosen Expires July 1, 2004 [Page 2] Internet-Draft Emergency Call Info in the DNS January 2004 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Problem Placing an emergency call to get help depends on location = where the caller is located at the time of the call. Location is needed for two fundamental reasons: 1. To determine which Public Safety Answering Point (PSAP) also known as an Emergency Response Center (ERC) to direct the call to. 2. To direct responders (police, fire, ambulance) to the caller. Location, within the context of emergency calls, can be expressed in two different forms, geographic (geo) - lat/lon/altitude and civil - country/state/city/street/building/floor/room. Determining the correct ERC is not trivial. ERCs have service boundaries. If you are inside the service boundary, that ERC should get your call. Nearest ERC, home ERC or other, simpler mechanisms will not work. One must either know from some kind of authenticated database the ERC that serves a given civil Address, or have a geo location, know the service boundaries, and compare the location of the caller with all of the ERC service boundaries to determine which boundary the geo location falls within. There are about 6,000 ERCs in North America, and perhaps 3X that in the rest of the world (ed note, anyone have a better number?). As a practical matter, service boundaries are defined by a combination of civil and geo forms, but can reasonably be converted to an all-geo representation, which is the most practical form to use when determining within which boundary the caller lies. With the advent of Voice over IP, the Internet presents daunting problems to emergency calls because users can be anywhere in the world relative to the elements that are processing the call. Consider for example, a user sitting in a café in Chicago with a laptop connected to the Internet via a hotspot, communicating with her employer's SIP proxy through a VPN tunnel. An accident occurs and the patron calls for help. What if the employer is in Sierra Leone, and has a local VoIP service provider? The employer's proxy server must determine based on the actual location of the user that the ERC is in Chicago! In processing a call to an ERC using a protocol such as SIP, a routing element must determine the location of the caller, and either Rosen Expires July 1, 2004 [Page 3] Internet-Draft Emergency Call Info in the DNS January 2004 have access to all the ERC service boundaries, and run an intersection algorithm determine the ERC, or have a civil address and a database that contains the ERC that serves that address. Having determined the correct ERC, the routing element must forward the call to it (which implies knowing the URI of that ERC). At present, there is no universal mechanism to learn the service boundaries of the ERCs. There are commercial databases available for some areas that have such information. This memo discusses a mechanism by which an ERC may publish its service boundary in a publicly available, standardized form. Once the correct ERC is determined, the call will be forwarded to it. The ERC will then answer the call, and determine what response is required. The responders are then dispatched to the location of the caller. Dispatch is always based on civil location. If the location is reported by the caller in geographic form, it must be translated to civil form in the ERC. Furthermore, responders also have service boundaries, and the service boundaries of the responders do not necessarily match the service boundary of the ERC. It is very common for there to be multiple response units dispatched by one ERC, and it is possible for a responder's service boundary to cross ERC service boundaries, although this is much less common. Once again, there is no standardized way to determine the service boundaries of the responders, although this problem is less important to solve in a standardized way because only the ERCs need the information. Nevertheless, if the same mechanism used to publish ERC service boundaries could be used for responder service boundaries, it would be very desirable. Because dispatch is always to a civil location, ERCs must translate location reported as geo to civil. At present, the way this is done is to employ a commercial "graphical information system" to capture street address data, often by manual digitization of aerial photographs. Location to the range of a street address is possible using this mechanism, but it is essential for larger buildings to have much finer grained location information. Accuracy to a room on a floor in a building is desired, and dispatch to that level is essential in a large multistory structure. There are no standardized mechanisms for this, and in fact there are no mechanisms short of a fire marshal carrying a box of paper floor plans in his car for interior layout information. If location is available as a civil, access to a database that enumerates all known street addresses and indicates the ERC, and responders, can provide the caller and the ERC with the information they need without any geo conversions or comparisons. However, this database (MSAG) must be made available to the routing elements, and Rosen Expires July 1, 2004 [Page 4] Internet-Draft Emergency Call Info in the DNS January 2004 mechanisms used to determine the civil address of a device must be verified against the MSAG, because there are many variations in naming locations (First Street vs 1st Street, New York Avenue Northwest, vs New York Avenue). Accurate dispatch requires uniformity of reporting civil addresses, and thus all addresses must be verified against the MSAG prior to an emergency. This implies the MSAG, which is commonly available and in use by ERCs, must be more publicly available. Notice that the routing proxy server may require a geo, but the ERC requires a civil. That implies that regardless of what form the original location is reported, either the routing proxy server or the ERC may have to translate Location in calls to the other form. Translation databases from geo to civil and civil to geo are thus required for many emergency calls. This memo describes a standardized mechanism for publishing such databases. Organizing ERCs and responders is a government function. Governments determine where boundaries are, how coverage is handled in less populated areas, etc. In smaller countries, the national government organizes the entire system. More commonly, while some aspects are organized and regulated at the national level, much of the organization is delegated to state/province/district level, and often further delegation to country and/or city/township level is done. Any organization of the data here are must mirror this delegation. There is a specific problem that occurs because ERCs and responders are government organized. There are areas of the world that are disputed - more than one country claims the area as part of its territory. This gives rise to multiple ERCs having a service boundary including disputed territory. While such areas are few and relatively small, the problem exists and must be accounted for in the design of systems and databases. 3. Overview of the Solution We propose to use the DNS to publish the service boundary, MSAG and civil-geo-civil translation databases. We think the DNS is particularly appropriate for this purpose because of its delegation mechanism, which we will show matches the need very closely. Starting at the root sos.arpa (sos being the universal symbol for emergency), we propose that the next level be a two-character iso country code, e.g. cn.sos.arpa. We propose that an international agency, probably the ITU be delegated the sos.arpa domain, and that it delegate cn.sos.arpa to an agency selected by the government of China. The national agency can, if appropriate, make further delegations. For example, there might be a domain such as pittsburgh.allegheny.pa.us.sos.arpa representing the City of Rosen Expires July 1, 2004 [Page 5] Internet-Draft Emergency Call Info in the DNS January 2004 Pittsburgh, in the Commonwealth (state) of Pennsylvania, in the United States. The city would create subdomains in its domain representing streets, and within those street domains, subdomains for addresses. For example, we might find an entry at 123.Main.Pittsburgh.Allegheny.pa.us.sos.arpa. At each of the levels of this hierarchy, we propose that the boundary of that area be defined with a new RR called "POLY". A POLY would have a sequence of points represented as lat/lon pairs or lat/lon/ altitude triples. The domain could have more than one POLY because: o Some boundaries have multiple independent areas (several islands for example) o Holes may exist within the boundary In addition, some of these domains may have NAPTR records representing the service URIs for the ERC or responders that cover that boundary. These may exist at any level. For interior layout information, a city/township may delegate a street address to a building owner. In turn, the building owner may delegate subdomains to Suite tenants. The tenant, or building owner, would enter floor subdomains, and within those, room domains. Each, as above, would have POLY boundaries. Of course, any administrative entity in the hierarchy could contract with a registrar to manage the delegation of its subdomains if it so chose. It could also create an administrative mechanism to obtain lower level data, and publish lower levels itself, rather than delegate. Interior information could be considered a privacy concern. For that reason, the domain names of the lower level hierarchies can be obscured (sequential or random numbers for example), with the actual name placed inside the entry (CNAME) and the contents encrypted. We note that the actual meaning of any level in this hierarchy is not defined, and the number of levels is not significant. What matters is that the names (unobscured) mean something to the (human) dispatcher and responder. The above information, in theory at least, is sufficient to solve the problem. Given a civil location, the routing proxy looks it up in the sos.arpa tree, and locates the ERC NAPTR. If there is no ERC entry, it looks upward in the tree until one is found. Given a geo location, one starts at the top of the sos.arpa tree, and examines the entire zone, intersecting the location with the boundaries (of the countries). Finding the country (or countries if in a disputed area) boundary(s) within which the location lies, drop down one level Rosen Expires July 1, 2004 [Page 6] Internet-Draft Emergency Call Info in the DNS January 2004 and repeat until one reaches the bottom of the hierarchy. That yields a civil location, and the procedure above can be used for determining the ERC uri and responders. Of course, the solution as presented depends on the entire tree being available. Clearly, while some jurisdictions have at least street level information in existing Geographic Information Systems, not every jurisdiction has that level of automation yet. Due to the way mobile telephone systems report location (which is nearly always in some form of geo), such GIS systems are becoming more common and will be ubiquitous eventually. However, to be practical, solutions should not entirely depend on such extensive databases. Therefore, we propose that in addition to the civil boundary information, we also provide service boundary information - that is the POLYs representing the service boundaries for the ERCs. A routing proxy with a geo would need only the complete list of ERC service boundaries in order to do an intersection to determine the correct ERC. That information is much more readily available and deployable in a short time. Further, in most cases, ERC boundaries are aligned to political boundaries. A large city, for example, typically has only one ERC, whose service boundary matches the city boundary. Thus, street level information is not needed for a civil location to find the serving ERC, if the city entry has an ERC NAPTR. In is common for an ERC to serve more than one township or smaller city, but the mechanism would work equally well for such a circumstance. There are some circumstances where ERC boundaries do not align well. Some ERCs only serve a part of a city, and an adjacent ERC serves the remainder. To ease deployment, we propose that in those circumstances, a SIP routing proxy be designated as the ERC NAPTR for the entire city, and that proxy has the information needed to determine which of the two ERCs serve the caller location, forwarding the call to the correct ERC. Of course, the DNS is not organized to search the breadth of a level, and the time required to do multiple intersections is costly (the time between initiating an emergency call and answering it is ideally under two seconds). For this reason we expect that the civil-to-geo information represented in the DNS will be cached by the routing server, which will compute an inverse geo-to-civil database, and make the operations very fast. In fact, we expect that the DNS would not be used directly during processing of an emergency call. Rather, the DNS is the PUBLISHING mechanism, which will be cached and used by the route server and the ERC. Typically, for example, we would expect a routing server to know the general location of its clients and cache that area of the DNS tree, plus the inverse data. Clearly, the existence of a street address entry indicates a valid Rosen Expires July 1, 2004 [Page 7] Internet-Draft Emergency Call Info in the DNS January 2004 civil Location. The jurisdiction responsible for defining valid addresses within its domain would enter its preferred spelling/ representation of that name. Any entity assigning civil locations would verify an address by looking it up in the sos.arpa tree. In this regard, the tree is the MSAG. 4. POLY RR The packet format of the POLY RR is given below. The DNS type code for POLY is ?? The first 3 bytes are a header +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NUMBER OF POINTS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FORMAT | Datum | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The number of points in the polygon is first. FORMAT is a code from an IANA registry defining the interpretation of the subsequent location data. Code points defined in this memo are: Code 0 = 3DAm All points have 3 coordinates, altitude is expressed in meters. Code 1 = 3DAf All points have 3 coordinates, altitude is expressed in floors. Code 2 = 2D All points have 2 coordinates. Code 3 = P3Dam Like 3Dam, but all points except the first are represented in 2s complement 16 bit delta fractions of a degree (for Lat/Lon) and 8 bit 2s complement integer, 8 bit fraction delta meters. Code 4 = P3Daf Like 3Dam, but all points except the first are represented in 2s complement 16 bit delta fractions of a degree (for Lat/Lon) and 8 bit signed floor number. Code 5 = P2D Like 2D, but all points except the first are represented in 2s complemented 16 bit delta fractions of a degree. Datum is a code for the reference model the points represent. Codes are the same as in [DHCPLCI]. Rosen Expires July 1, 2004 [Page 8] Internet-Draft Emergency Call Info in the DNS January 2004 The basic point location format is copied from [DHCPLCI]. Latitude: a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. Latitude SHOULD be normalized to within +/- 90 degrees. Positive numbers are north of the equator and negative numbers are south of the equator. Longitude: a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. Longitude SHOULD be normalized to within +/- 180 degrees. Positive values are East of the prime meridian and negative (2s complement) numbers are West of the prime meridian. Altitude: A 30 bit value in 2s-complement fixed-point 22-bit integer part with 8-bit fraction, expressed as meters or floors depending on the value of FORMAT The meaning of altitude measured in floors is the same as that specified in [DHCPLCI]. The values of Latitude, Longitude, and if appropriate, Altitude are packed sequentially into bytes with no filler. This means that a 2D point would be 68 bits, and a 3D point would be 98 bits. The next point follows immediately (bit-wise). The last byte would be zero filled. For example, a POLY with Format 0 and 100 points would be 1228 bytes long: 3 byte header plus 100*98/8 = 1225 bytes of data. Multiple POLYs can exist in an entry. The meaning of multiple POLYs depends on whether one POLY completely encloses another. Multiple POLYs that are not boundaries within another boundaries are additive (multiple islands). POLYs that are contained within another POLY are subtractive (holes). If there are multiple levels of enclosing POLYs, they define islands within holes. For For example: +------------------------+ | | | +------------------+ | | |//////////////////| | | |//+---+////+---+//| | | |//| |////| |//| | | |//| |////| |//| | | |//+---+////+---+//| | | |//////////////////| | | +------------------+ | | | +------------------------+ Rosen Expires July 1, 2004 [Page 9] Internet-Draft Emergency Call Info in the DNS January 2004 4.1 IANA Registration for POLY Format IANA shall create a registry for the format of a POLY. The registry shall initially contain the 3 entries enumerated above. An RFC shall be required to add a new code in the registry. 5. The SOS Application Specifications The following text is based on the equivalent text in [RFC2916]. This template defines the SOS DDDS Application according to the rules and requirements found in [RFC3402]. The DDDS database used by this Application is found in [RFC3403] which is the document that defines the NAPTR DNS Resource Record type. 5.1 Application Unique String The Application Unique String is a civil location expressed as a series of increasingly specific regions starting at national (country), with the components separated by periods, and in reverse order (i.e. country is rightmost). There is no significance to the meaning of the components as long as the civil location is interpretable by residents in the specified location, and they are in increasingly specific. 5.2 First Well Known Rule The First Well Known Rule for this Application is the identity rule. The output of this rule is the same as the input. This is because this Application's databases are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself. 5.3 Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in [RFC2396] 5.4 Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. The output of the First Well Known Rule for the SOS Application is Rosen Expires July 1, 2004 [Page 10] Internet-Draft Emergency Call Info in the DNS January 2004 the input string with the string "sos.arpa" appended. This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS. The character set used to encode the substitution expression is UTF-8. The allowed input characters are and the characters allowed to be in a Key are those that are currently defined for DNS domain-names. 5.4.1 Flags This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI. See [RFC3403]. If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields. A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target. If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new Key in the DDDS loop (i.e. causing the client to query for new NAPTR records at the domain-name that is the result of this Rule). 5.4.2 Services Parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. service_field = "SOS" 1*(servicespec) servicespec = "+" sosservice sosservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) In other words, a non-optional "SOS" (used to denote SOS only Rewrite Rules in order to mitigate record collisions) followed by 1 or more or more sosservices which indicate what class of functionality a given end point offers. Each sosservice is indicated by an initial '+' character. Rosen Expires July 1, 2004 [Page 11] Internet-Draft Emergency Call Info in the DNS January 2004 No use for subtypes is presently contemplated, but is left defined as in [RFC2916] for possible future use. 5.4.2.1 SOS Services sosservice specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the sosservice and URI schemes or protocols. The mapping, if any, must be made explicit in the specification for the sosservice itself. A registration of a specific Type also has to specify the Subtypes allowed. The registration mechanism is specified in Section 6. 5.5 What constitutes an 'Sos Resolver'? The sos algorithm always returns a single rule. Specific applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm. 6. Registration mechanism for sosservices As specified in the ABNF found in Section 5.4.2, an 'sosservice' is made up of 'types' and 'subtypes'. For any given 'type', the allowable 'subtypes' must be specified in the registration. There is currently no concept of a registered 'subtype' outside the scope of a given 'type'. Thus the registration process uses the 'type' as the main key within the IANA Registry. While the combination of each type and all of its subtypes constitutes the allowed values for the 'enumservice' field, it is not sufficient to simply document those values. A complete registration will also include the allowed URI schemes, a functional specification, security considerations, intended usage, and any other information needed to allow for interoperability within the application. In order to be a registered sos service, the entire specification, including the template, requires publication of the sosservice registration specification as an RFC. 6.1 Registration Requirements Service registration proposals are all expected to conform to various requirements laid out in the following sections. Rosen Expires July 1, 2004 [Page 12] Internet-Draft Emergency Call Info in the DNS January 2004 6.1.1 Functionality Requirement A registered sosservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI that is the outcome of the use of it. 6.1.2 Naming requirement An sosservice MUST be unique in order to be useful as a selection criteria. Since an sosservice is made up of a type and a type-dependent subtype, it is sufficient to require that the 'type' itself be unique. The 'type' MUST be unique, conform to the ABNF specified in Section 5.4.2. The subtype, being dependent on the type, MUST be unique within a given 'type'. It must conform to the ABNF specified in Section 5.4.2. The subtype for one type MAY be the same as a subtype for a different registered type but it is not sufficient to simply reference another type's subtype. The function of each subtype must be specified in the context of the type being registered. 6.1.3 Security requirement An analysis of security issues is required for all registered sosservices. (This is in accordance with the basic requirements for all IETF protocols.) In most cases, it is expected that the security considerations will be the same as those services defined in this memo, but new services could have different security considerations. All descriptions of security issues must be as accurate as possibly regardless of registration tree. In particular, a statement that there are "no security issues associated with this sosservice" must not be confused with "the security issues associated with this sosservice have not been assessed". There is no requirement that an sosservice must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of an sosservice. The security considerations section of all registrations is subject to continuing evaluation and modification. 6.1.4 Publication Requirements Proposals for sosservice registrations MUST be published as an RFC, or as a BCP. Rosen Expires July 1, 2004 [Page 13] Internet-Draft Emergency Call Info in the DNS January 2004 6.2 Registration procedure 6.2.1 IANA Registration IANA will register the sosservice and make the sosservice registration available to the community in addition to the RFC/BCP publication. 6.2.1.1 Location of sosservice Registrations sosservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI: "ftp:// ftp.iana.org/assignments/sos-services/". 6.2.1.2 Change Control Change control of sosservice stay with the IETF via the RFC publication process. sosservice registrations may not be deleted; sosservice which are no longer believed appropriate for use can be declared OBSOLETE by publication of a new RFC and a change to their "intended use" field; such sosservices will be clearly marked OBSOLETE in the lists published by IANA. Registration Template sosservice Type: sosservice Subtype(s): URI Scheme(s): Functional Specification: Security considerations: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author: Any other information that the author deems interesting: Note: In the case where a particular field has no value, that field is left completely blank, especially in the case where a given type has no subtypes. 6.2.2 Initial Registrations The following services are defined in this memo Type sos+erc Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the public service access point that serves the civil address corresponding to this DDDS entry. Rosen Expires July 1, 2004 [Page 14] Internet-Draft Emergency Call Info in the DNS January 2004 Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: None Type_sos+fire Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the fire department/brigade that serves the civil address corresponding to this DDDS entry. Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: In many jurisdictions, emergency calls should be routed to an ERC rather than a specific service such as a direct call to the fire department/brigade. Type_sos+rescue Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the rescue/ ambulance service that serves the civil address corresponding to this DDDS entry. Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: In many jurisdictions, emergency calls should be routed to an ERC rather than a specific service such as a direct call to the rescue/ambulance service. Type_sos+marine Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the maritime rescue service that serves the civil address corresponding to this DDDS entry. Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: The concept of a "civil address" for a marine emergency is somewhat strange. Entries should be made in the DDDS for territory within a jurisdiction that is served by a maritime emergency response service. For example, one could have an entry such as 5.atlantic.us for the Coast Guard District 5 in the Atlantic region of the United States. Type_sos+police Rosen Expires July 1, 2004 [Page 15] Internet-Draft Emergency Call Info in the DNS January 2004 Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the police department that serves the civil address corresponding to this DDDS entry. Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: In many jurisdictions, emergency calls should be routed to an ERC rather than a specific service such as a direct call to the police. Type_sos+mountain Subtypes: none URI Schemes: sip: [RFC3261] and tel: [RFC2806] Functional Specification: Provides a contact uri for the public service access point that serves the civil address corresponding to this DDDS entry. Security considerations: see Section 9 Intended usage: COMMON Author: Brian Rosen Other Information: None 7. Obscuring Lower Level Information Most of the information in the sos.arpa domain is public, but information interior to a building may not be. In these cases, the domain names may be obscured by substituting a string (perhaps a random or sequentially assigned number) for the parts of the domain name to be obscured, and placing the actual name in the entry using CNAME. The contents of the entry would be encrypted by: Placing the certificate of the entity obscuring the data in a CERT RR Encrypting the data to be obscured (CNAME and POLY) using RSA-1024 with the Private Key of the entity obscuring the data, and the Public key of the ERC serving the area obscured. Placing the resulting data in a ENCRYPT RR 8. Notes and things to do It's clearly possible to make this database be entirely independent of the DNS. We would use the same namespace (sos.arpa) subtree to avoid conflicts, but have entirely separate root servers, etc. One reason not to do this is that the civil to geo and geo to civil data is useful for other applications, but this proposal is really limited to supporting emergency calls. The author would strongly prefer not to have to develop a new root server infrastructure, modified code for accessing, etc. Rosen Expires July 1, 2004 [Page 16] Internet-Draft Emergency Call Info in the DNS January 2004 I've waffled back and forth on whether the contact URI should be a NAPTR, thus making this a DDDS application like ENUM, or making it an SRV. The problem with an SRV is that you can't easily encode a SIP URI. There is some precedence for using the first component of the name as the access protocol. We would have to use the second one for the userpart, so sip:alice@example.com becomes sip.alice.example.com in the SRV. The wording would be considerably simpler if we did. The case for DDDS is that it just works, like ENUM just works, as long as the REGEXP is straight replacement. You don't really "call" the civil location, but you do call the ERC corresponding to the civil location, so it works At times, I have advocated actually having the reverse tree (geo to civil). I note that you can mechanically create geo to civil from the civil to geo this proposes. There is no really good way that has occurred to me to construct the name hierarchy. The SRI geo proposal isn't appropriate. I haven't put in the section that defines how you know the entry is an ERC (or fire or police). I have to pick or define an appropriate RR. The ENCRYPT thing needs work. I could put the CNAME inside the ENCRYPT. Need to define what the exact format of ENCRYPT is. At times, I have considered Extending DNSSEC to include privacy, but I don't want to encrypt the whole thing, just the POLY and CNAME. Need text on size of entries. These are going to be big. Need text on i18n names. 9. Security Considerations Up to street address level, the information in the proposed DNS tree is public. Where the data is not public, the entry SHOULD be encrypted. If the data in the DNS is forged, or a man in the middle attack is mounted, emergency calls could be directed to the wrong place, causing harm to a caller. DNSSEC [RFC2535] SHOULD be used for clients accessing the data. It is more important, however, that the data be used, than it be assured that it is genuine, and in general, the emergency response community would prefer that failure be that the data is provided, but denoted as possibly inaccurate. Thus if DNSSEC mechanisms fail, the request should be allowed to proceed, with a failure indicator returned. References Rosen Expires July 1, 2004 [Page 17] Internet-Draft Emergency Call Info in the DNS January 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. Author's Address Brian Rosen Marconi 2000 Marconi Drive Warrendale, PA 15086 US Phone: +1 724 742 6826 EMail: brian.rosen@marconi.com Rosen Expires July 1, 2004 [Page 18] Internet-Draft Emergency Call Info in the DNS January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosen Expires July 1, 2004 [Page 19] Internet-Draft Emergency Call Info in the DNS January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosen Expires July 1, 2004 [Page 20]