sipping B. Rosen
Internet-Draft Marconi
Expires: January 14, 2005 July 16, 2004
Emergency Call Information in the Domain Name System
draft-rosen-dns-sos-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 January 14, 2005.
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 (latitude, longitude) or civic (country, province,
locality) forms. This document proposes a DNS-based mechanism to
lookup emergency calling URIs and related emergency information from
a known civic location in a specific form. Other companion documents
propose a non DNS-based approach to determine civic location from
Rosen Expires January 14, 2005 [Page 1]
Internet-Draft Emergency Call Info in the DNS July 2004
geographic location, and describe how to discover a civic location in
the appropriate local form(s) for this application.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. What's Changed . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of the Solution . . . . . . . . . . . . . . . . . . . 5
5. The SOS Application Specifications . . . . . . . . . . . . . . 7
5.1 Application Unique String . . . . . . . . . . . . . . . . 7
5.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 8
5.3 Expected Output . . . . . . . . . . . . . . . . . . . . . 8
5.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . 8
5.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4.2 Services Parameters . . . . . . . . . . . . . . . . . 9
5.5 What constitutes an 'Sos Resolver'? . . . . . . . . . . . 10
6. Registration mechanism for sosservices . . . . . . . . . . . . 10
6.1 Registration Requirements . . . . . . . . . . . . . . . . 10
6.1.1 Functionality Requirement . . . . . . . . . . . . . . 10
6.1.2 Naming requirement . . . . . . . . . . . . . . . . . . 10
6.1.3 Security requirement . . . . . . . . . . . . . . . . . 11
6.1.4 Publication Requirements . . . . . . . . . . . . . . . 11
6.2 Registration procedure . . . . . . . . . . . . . . . . . . 11
6.2.1 IANA Registration . . . . . . . . . . . . . . . . . . 11
6.2.2 Initial Registrations . . . . . . . . . . . . . . . . 12
7. Polygon Document . . . . . . . . . . . . . . . . . . . . . . . 15
8. Subdomain Document . . . . . . . . . . . . . . . . . . . . . . 16
9. Structure Document . . . . . . . . . . . . . . . . . . . . . . 16
10. Notes and things to do . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
13. Normative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Rosen Expires January 14, 2005 [Page 2]
Internet-Draft Emergency Call Info in the DNS July 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. What's Changed
Major simplifications have been made to this version from the
initial.
The contents of proposed entries in the DNS has been simplified to
several NAPTRs; no new DNS objects are proposed, and specifically,
the proposed POLY object is replaced with a NAPTR to a boundary
description document in XML.
3. 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 Communications Center (ECC) 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) - latitude, longitude, altitude
and civic - county, province or state, city, ...
Determining the correct ECC is not trivial. ECCs have service
boundaries. If a caller is inside the service boundary, that ECC
should get the call. Nearest ECC, home ECC or other, simpler
mechanisms will not work. One must either know from some kind of
authenticated database the ECC that serves a given civic address, or
have a geo location and use a network service or local algorithm to
determine the correct ECC from the geographic coordinates. (For
example, a service may know the service boundaries for a region and
compare the location of the caller with all of the ECC service
boundaries to determine which boundary the geo location falls
within.) There are about 6,000 ECCs in North America, and perhaps 3
times that number in the rest of the world (ed note, anyone have a
better number?).
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 cafe' in Chicago with a
Rosen Expires January 14, 2005 [Page 3]
Internet-Draft Emergency Call Info in the DNS July 2004
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 Sierra Leone based VoIP service provider? The
employer's proxy server must determine based on the actual location
of the user that the ECC is in Chicago!
In processing a call to an ECC using a protocol such as SIP
[RFC3261], a routing element must determine the location of the
caller, and depending on the form of the location either have access
to all the ECC service boundaries, run an intersection algorithm
between a geo location of the caller and all possible ECC boundaries,
or have a civic address and a database that contains the ECC that
serves that address. Having determined the correct ECC, the routing
element must forward the call to it (which implies knowing the URI of
that ECC). At present, there is no standard mechanism to discover
the correct ECC from either civil or geographic addresses.
Once the correct ECC is determined, the call will be forwarded to it.
The ECC will then answer the call, and determine what response is
required. The responders are then dispatched to the location of the
caller. Dispatch is typically based on civic location. If the
location is reported by the caller in geo form, it must be translated
to civic form in the ECC, which requires an accurate translation
database.
Each of the responders (e.g. police, fire, emergency medical) have
their own service boundaries, and they do not correspond to the
service boundary of the ECC. A mechanism is needed to publish
responder service boundaries.
If location is available as a civic, access to a database that
enumerates all known street addresses is used to validate the address
prior to its being used for an emergency call. This database (called
a "Master Street Address Guide" or "MSAG") must be made available to
the entities that supply location to the endpoints. Validation
against the MSAG is essential because there are many variations in
naming locations (First Street vs 1st Street, New York Avenue
Northwest, vs New York Ave. NW). Accurate dispatch requires
uniformity of reporting civic addresses, and thus all addresses must
be verified against the MSAG prior to an emergency. This implies the
MSAG, which in some areas is commonly available to PSTN carriers and
in use by ECCs, must be more publicly available.
Organizing ECCs 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
Rosen Expires January 14, 2005 [Page 4]
Internet-Draft Emergency Call Info in the DNS July 2004
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 must mirror this delegation. On
the other hand, for historical reasons, many service boundaries do
not follow government entity boundaries. Therefore, there is not
necessarily a correlation between the delegation boundaries and the
service boundaries.
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 ECCs 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.
4. Overview of the Solution
SIP has been extended to carry a location object [REF]. Emergency
calls will be required to include this object in the first message
(INVITE) of an emergency call. The location can be determined by a
measurement method (such as a Global Positioning Satellite (GPS)
receiver in the endpoint, or the endpoint can learn its location from
the local infrastructure using, for example, the location option of
Dynamic Host Configuration Protocol (DHCP) [REF].
We propose to use the Domain Name System (DNS) to hold a hierarchy of
civic locations. 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. au.sos.arpa. We
propose that an international agency be delegated the sos.arpa
domain, and that it delegate au.sos.arpa to an agency selected by the
government of Australia. 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
Pittsburgh, Allegheny County, in the Commonwealth (state) of
Pennsylvania, in the United States. A city could, for example,
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.
There is no requirement for each subdomain in a domain to have the
same semantics (for example, rural and urban areas might use
different parallel civic location schemes). Nor is there a
requirement for a particular level of hierarchy within two different
countries or regions to share the same semantics.
The contents of the domains are primarily Naming Authority Pointers
Rosen Expires January 14, 2005 [Page 5]
Internet-Draft Emergency Call Info in the DNS July 2004
(NAPTRs) [RFC2915]. For example, some of these domains may have
NAPTR records representing the service URIs for the ECC or responders
that cover that boundary. These may exist at any level.
Besides NAPTRs that represent service boundaries for ECCs or
responders, there can also be NAPTRs to additional information.
These NAPTRs are expected to resolve to HTPPS URLs which point to XML
documents with specific semantics. This document describes several
such NAPTRs:
o a pointer to a document containing a set of polygons: each a
sequence of geospatial coordinates describing the boundary of a
domain;
o a pointer to a list of subdomains of a domain to facilitate
searching;
o a pointer to a set of information about a structure (building)
provided by the actual owner of the domain, and not essential for
routing or dispatch, but potentially usefull for the ECC and
responder. For example, an after hours contact;
For location information within a building, a city or 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. For example, one might find a entry at
235-5.5.123.main.pittsburgh.allegheny.pa.us.sos.arpa representing
cubicle 235-5 on the 5th floor of 123 Main Street. Interior
information is optional, and intended for non-private data.
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.
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 mean something to the (human) dispatcher and
responder.
Creation of the database may look daunting, but in many areas it
already exists, albeit in different forms. The hierarchical nature
of DNS can simplify the data that needs to be assembled where the
data does not yet exist. In many cases, ECC boundaries actually are
aligned to political boundaries. A large city, for example,
typically has only one ECC, whose service boundary matches the city
boundary. Thus, street level information is not needed for a civic
location to find the serving ECC, if the city entry has an ECC NAPTR.
It is common for an ECC to serve more than one township or smaller
Rosen Expires January 14, 2005 [Page 6]
Internet-Draft Emergency Call Info in the DNS July 2004
city, but the mechanism would work equally well for such a
circumstance. There are some circumstances where ECC boundaries do
not align well. Some ECCs only serve a part of a city, and an
adjacent ECC serves the remainder. The basic mechanism works quite
well, because an ECC NAPTR can be put in the upper level domain that
covers the majority of the served area, and only subdomains for
exception, either within the majority area -- all except these
streets -- or within the minority area -- all plus these streets,
need be populated with domains containing the correct ECC NAPTR. It
is also possible for a routing proxy to be designated as the ECC
NAPTR for an entire city, state, or even a country, and for that
proxy to have the information needed to determine which ECC serves
the caller location, forwarding the call to it.
Clearly, the existence of a street address entry indicates a valid
civic Location. The jurisdiction responsible for defining valid
addresses within its domain would enter its preferred spelling/
representation of that name. Any entity assigning civic locations
would verify an address by looking it up in the sos.arpa tree. In
this regard, the tree is the MSAG. Alternate spellings, and
alternate forms of the address (for example, a postal address) can
also be placed in the sos.arpa tree, with a CNAME element pointing to
the correctly spelled DNS entry.
For locations provided in geo form, we propose that the sos.arpa
domain have entries for each ECC, which contains a NAPTR with the URI
to reach that ECC and a NAPTR with the polygon lists defining its
service boundaries. Polygon data for each level of the civil
hierarchy can be used by callers with geographic information to
verify if they are in the right service area. Other services can
provide facilities to provide the URI of the correct ECC given
geographic location.
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 civic 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 code appears just to the left of "sos.arpa").
Rosen Expires January 14, 2005 [Page 7]
Internet-Draft Emergency Call Info in the DNS July 2004
There is no significance to the meaning of the components as long as
the civic location is interpretable by residents in the specified
location, and they are in increasingly specific. Implementations
SHOULD use the components listed in [DHCP civic ref] to allow direct
mapping between locations reported by DHCP and locations in the DNS.
Where local convention omits levels of hierarchy that are required in
other regions within a country (for example, use of county in some
provinces but not in others), the omitted element would be specified
as ".null".
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 set of Uniform Resource
Identifiers in 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
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. Spellings SHOULD use local conventions, but MUST match
the same conventions used for DHCP reported location.
Rosen Expires January 14, 2005 [Page 8]
Internet-Draft Emergency Call Info in the DNS July 2004
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.
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
Rosen Expires January 14, 2005 [Page 9]
Internet-Draft Emergency Call Info in the DNS July 2004
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 algorithm defined above 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.
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
Rosen Expires January 14, 2005 [Page 10]
Internet-Draft Emergency Call Info in the DNS July 2004
type-dependent subtype, it is sufficient to require that the 'type'
itself be unique. The 'type' MUST be unique, and 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.
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://
Rosen Expires January 14, 2005 [Page 11]
Internet-Draft Emergency Call Info in the DNS July 2004
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+ecc
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the emergency
call center (public safety answering point) that serves the civic
address corresponding to this DDDS entry.
Security considerations: As this URI reaches the PSAP, directly or
indirectly, it can be a target for a denial of service attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: None
Type sos+fire
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the fire
department/brigade that serves the civic address corresponding to
this DDDS entry.
Rosen Expires January 14, 2005 [Page 12]
Internet-Draft Emergency Call Info in the DNS July 2004
Security considerations: As this URI reaches the responder,
directly or indirectly, it can be a target for a denial of service
attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ECC rather than a specific service such as a
direct call to the fire department/brigade. The agency can refuse
such direct calls by, e.g. requiring authentication.
Type sos+rescue
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the rescue/
emergency medical service/ambulance service that serves the civic
address corresponding to this DDDS entry.
Security considerations: As this URI reaches the responder,
directly or indirectly, it can be a target for a denial of service
attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ECC rather than a specific service such as a
direct call to the rescue/EMS/ambulance service. The agency can
refuse such direct calls by, e.g. requiring authentication.
Type sos+marine
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the maritime
rescue service that serves the civic address corresponding to this
DDDS entry.
Security considerations: As this URI reaches the responder,
directly or indirectly, it can be a target for a denial of service
attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: The concept of a "civic 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 January 14, 2005 [Page 13]
Internet-Draft Emergency Call Info in the DNS July 2004
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the police
department that serves the civic address corresponding to this
DDDS entry.
Security considerations: As this URI reaches the responder,
directly or indirectly, it can be a target for a denial of service
attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ECC rather than a specific service such as a
direct call to the police. The agency can refuse such direct
calls by, e.g. requiring authentication.
Type sos+mountain
Subtypes: none
URI Schemes: sips: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the mountain
rescue service point that serves the civic address corresponding
to this DDDS entry.
Security considerations: As this URI reaches the responder,
directly or indirectly, it can be a target for a denial of service
attack.
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ECC rather than a specific service such as a
direct call to the mountain rescue. The agency can refuse such
direct calls by, e.g. requiring authentication.
Type sos+subdomain
Subtypes: none
URI Schemes: http or https [RFC2616]
Functional Specification: Pointer to an XML document as defined in
Section 8 containing a list of subdomains. Facilitates searching
the sos.arpa tree.
Security considerations: none
Intended usage: COMMON
Author: Brian Rosen
Other Information: none.
Type sos+polygon
Subtypes: none
URI Schemes: http or https [RFC2616]
Rosen Expires January 14, 2005 [Page 14]
Internet-Draft Emergency Call Info in the DNS July 2004
Functional Specification: Pointer to an XML document as defined in
Section 7 containing a list of polygons describing the boundary of
the domain. May be protected by TLS if needed.
Security considerations: If the information must be kept private,
the document should be protected with TLS. Polygons representing
boundaries within a building are often considered private and thus
should be protected.
Intended usage: COMMON
Author: Brian Rosen
Other Information: none.
Type sos+structure
Subtypes: none
URI Schemes: http or https [RFC2616]
Functional Specification: Pointer to an XML document as defined in
Section 9.
Security considerations: In many cases, this information is
private and the document should be protected with TLS.
Intended usage: COMMON
Author: Brian Rosen
Other Information: none.
7. Polygon Document
The Polygon document MUST be a well-formed XML document meeting the
following schema, which is derived from Geography Markup Language
(GML) as defined by the OpenGIS Consortium [1].
Rosen Expires January 14, 2005 [Page 15]
Internet-Draft Emergency Call Info in the DNS July 2004
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sos-boundary"
xmlns:gml="http://www.opengis.net/gml"
xmlns:sos-boundary="urn:ietf:params:xml:ns:sos-boundary"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.opengis.net/gml"
schemaLocation="feature.xsd"/>
<xs:import namespace="http://www.opengis.net/gml"
schemaLocation="geometryPrimitives.xsd"/>
<xs:complexType name="boundary">
<!--xs:restriction base="gml:AbstractFeatureType"-->
<xs:sequence>
<xs:sequence>
<xs:element ref="gml:boundedBy" minOccurs="0"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="gml:extentOf"/>
</xs:sequence>
</xs:sequence>
<!--/xs:restriction-->
</xs:complexType>
</xs:schema>
8. Subdomain Document
The subdomain document shall be a well-structured XML document
accessed by HTTP or HTTPS. The schema of this document is:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sos-subdomain"
xmlns:sos-sd="urn:ietf:params:xml:ns:sos-sd"
elementFormDefault="qualified">
<xs:element name="sos-subdomain">
<xs:complexType>
<xs:list type="xs:anyURI" minOccurs="0"/>
</xs:complexType>
</xs:element>
</xs:schema>
9. Structure Document
The structure document shall be a well-structured XML document
accessed by HTTP or HTTPS. The schema of this document is:
Rosen Expires January 14, 2005 [Page 16]
Internet-Draft Emergency Call Info in the DNS July 2004
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sos-structure"
xmlns:sos-sd="urn:ietf:params:xml:ns:sos-sr"
elementFormDefault="qualified">
<xs:element name="sos-structure">
<xs:complexType>
<TBD>
</xs:complexType>
</xs:element>
</xs:schema>
10. Notes and things to do
I haven't put in the section that defines where in the tree the ECC
entries go.
Need text on i18n names.
11. Security Considerations
Details of building interiors and structure documents may not be
public data. Revealing this data to unauthorized users (ECCs and
responders) could provide attackers with information that could be
exploited to burgle, inflict damage on, or otherwise do significant
harm to the owners and occupants of the structure. Where the data is
not public, accessing the data MUST be restricted to authorized
entities using HTTPS.
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. The
call could be directed to the wrong ECC, could be directed to a valid
URI which was not an ECC, to a completely invalid URI. Worse the
call could be directed to an entity impersonating an ECC, which could
leave the caller believing help was coming when in fact it was not.
Data in the DNS sos.arpa tree includes a URI that can directly or
indirectly reach the ECC, which may be used to mount a Denial of
Service attack.
For these reasons, clients and servers SHOULD use protected services
such as HTTPS and sips: which could authenticate that the destination
is the desired one.
If the caller provides an incorrect location, the call could be
directed to the wrong ECC. An inadvertent error could be detected
before a call by verifying that the call exists in the sos.arpa tree.
Rosen Expires January 14, 2005 [Page 17]
Internet-Draft Emergency Call Info in the DNS July 2004
Indeed validation of address is one of the reasons we propose that
the address data be in a publicly accessible database.
12. Acknowledgements
This document has benefited greatly from numerous comments from both
Henning Schulzrinne and Rohan Mahy.
13 Normative References
[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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
April 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 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.
[1] <http://www.opengis.org>
Rosen Expires January 14, 2005 [Page 18]
Internet-Draft Emergency Call Info in the DNS July 2004
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 January 14, 2005 [Page 19]
Internet-Draft Emergency Call Info in the DNS July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosen Expires January 14, 2005 [Page 20]