Internet DRAFT - draft-hardie-ecrit-iris
draft-hardie-ecrit-iris
Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
Expires: April 24, 2006 A. Newton
Verisign, Inc.
H. Tschofenig
Siemens
October 21, 2005
An IRIS schema for Emergency Service contact URIs
draft-hardie-ecrit-iris-03.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an XML-based protocol for passing location
information to a server that returns emergency service contact URIs.
It is intended to fit within a larger framework of standards.
Specifically, it presumes the existence of a URI scheme appropriate
for signalling that emergency service is required and distinguishing
Hardie, et al. Expires April 24, 2006 [Page 1]
Internet-Draft ECON October 2005
among emergency services if appropriate. It also presumes that an
entity requesting this response will be able to handle the URIs
returned as input to appropriate handlers.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 A Simple Example . . . . . . . . . . . . . . . . . . . . . 5
2.4 Deployment Methods . . . . . . . . . . . . . . . . . . . . 7
3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 11
3.1.1 <findEconByCivic> Query . . . . . . . . . . . . . . . 11
3.1.2 <findEconByGeo> Query . . . . . . . . . . . . . . . . 11
3.1.3 <listServices> Query . . . . . . . . . . . . . . . . . 12
3.2 Service Types . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Result Derivatives . . . . . . . . . . . . . . . . . . . . 12
3.3.1 <emergencyContact> Result . . . . . . . . . . . . . . 12
3.3.2 <emergencyService> Result . . . . . . . . . . . . . . 13
3.4 Error Derivatives . . . . . . . . . . . . . . . . . . . . 13
3.4.1 <invalidCivicData> . . . . . . . . . . . . . . . . . . 13
3.4.2 <invalidGeoData> . . . . . . . . . . . . . . . . . . . 13
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Database Replication . . . . . . . . . . . . . . . . . . . . . 18
5.1 ECONREP Model . . . . . . . . . . . . . . . . . . . . . . 18
5.2 ECONREP Formal Syntax . . . . . . . . . . . . . . . . . . 19
6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Application Service Label . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Internationalization Considerations . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1 XML Namespace URN Registration . . . . . . . . . . . . . . 27
9.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 27
9.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1 Normative References . . . . . . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
A. Object Signing . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
Hardie, et al. Expires April 24, 2006 [Page 2]
Internet-Draft ECON October 2005
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 [5].
Hardie, et al. Expires April 24, 2006 [Page 3]
Internet-Draft ECON October 2005
2. Introduction
This document describes a protocol for taking location information
compatible with PIDF-LO [8] and passing it to an IRIS [3] server
using an XML schema specific to the task of returning emergency
service contact URIs. These URIs may be of multiple forms, including
sip, xmpp, and tel, and multiple URIs may be returned to a single
query. This document does not presume that this activity takes place
at any specific point in a call flow. It is a feature of the overall
system of which this forms a part that multiple entities may request
the lookup and perform the substitution of the emergency service
contact URI.
This document names this protocol usage "ECON", short for Emergency
Contact. The features of ECON are:
o Supports queries using civic as well as geospatial location
information.
o Can be used in both recursive and iterative resolution.
o Through the re-use of an existing protocol, contains search-
oriented directory semantics.
o Can be used for civic address validation.
o Hierarchical deployment of ECON services is independent of civic
location labels.
o Can communicate erroneous requests to facillitate debugging and
proper user feedback while simultaneously providing best-effort
answers.
2.1 Usage
The intended usage of this protocol (ECON) is a simple client query
to a server that yields a result. The result may contain a URI for a
single contact method or URIs for multiple contact methods, a
reference to another server to which the client should send a query,
and error messages indicating problems with interpretation of
location information. The combination of these components are left
to the needs and policy of the jurisdiction where the server is being
operated.
The framing and formalization of these results are accomplished with
XML using the IRIS [3] framework. Though IRIS may be used with
multiple transfer protocols, this specification intends to target
Hardie, et al. Expires April 24, 2006 [Page 4]
Internet-Draft ECON October 2005
small XML interactions and stateless transactions so that the UDP-
based transfer protocol LWZ [9] may be employeed for fast response
times.
2.2 Discovery
Discovery of ECON services is to be provided by network elements
local to the client, hopefully via the same mechanisms providing
clients with location information. For instance, clients may obtain
their location information via DHCP using optional civic or location
request methods. Therefore, DHCP could also be used to provide
clients a reference to the most appropriate ECON server.
2.3 A Simple Example
After performing link layer attachment, an end host performs stateful
address autoconfiguration (in our example) using DHCP. DHCP provides
the end host with civic location information (encoded in UTF-8
format):
+--------+---------------+
| CAtype | CAvalue |
+--------+---------------+
| 0 | US |
| 1 | New York |
| 3 | New Yor |
| 6 | Broadway |
| 22 | Suite 75 |
| 24 | 10027-0401 |
+--------+---------------+
Figure 1: DHCP Civic Example
Additionally, DHCP provides information about the ECON server that
has to be contacted. An additional step of indirection is possible,
for example by referring to a domain name that has to be resolved to
one or multiple IP addresses referring to ECON servers).
When the user wants to make an emergency call (seeking help from the
police) the following protocol interaction takes place using UDP-
based transfer protocol LWZ. The client encapsulates the received
civic location information into XML and puts it into a UDP packet.
The header represents information from IRIS, as detailed in LWZ [9].
The search query is constructed according to Section 4. The message
flow is shown below.
Hardie, et al. Expires April 24, 2006 [Page 5]
Internet-Draft ECON October 2005
C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9)
C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1">
C:
C: <searchSet>
C:
C: <findEconByCivic
C: xmlns="urn:ietf:params:xml:ns:econ1" >
C:
C: <civilAddress>
C: <country>US</country>
C: <A1>New York</A1>
C: <A3>New York</A3>
C: <A6>Broadway</A6>
C: <HNO>123</HNO>
C: <LOC>Suite 75</LOC>
C: <PC>10027-0401</PC>
C: </civilAddress>
C:
C: <service>sos.police</service>
C:
C: </findEconByCivic>
C:
C: </searchSet>
C:
C: </request>
Figure 2
Since the contacted ECON server has the requested information
available the following response message is returned. The response
indicates, as a human readable display string that the 'New York City
Police Department' is responsible for the given geographical area.
The indicated URI allows the user to start SIP based communication.
Hardie, et al. Expires April 24, 2006 [Page 6]
Internet-Draft ECON October 2005
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <response xmlns="urn:ietf:params:xml:ns:iris1">
S:
S: <resultSet>
S: <answer>
S:
S: <emergencyContact xmlns="urn:ietf:params:xml:ns:econ1"
S: authority="example.com" registryType="econ1"
S: entityClass="econ" entityName="nypd" >
S:
S: <displayName>
S: New York City Police Department
S: </displayName>
S: <service>sos.police</service>
S: <uri>
S: sip:nypd@example.com
S: xmpp:nypd@example.com
S: </uri>
S:
S: </emergencyContact>
S:
S: </answer>
S:
S: </resultSet>
S:
S: </response>
2.4 Deployment Methods
Because services for emergency contact resolution may differ
depending jurisdiction need, this document only specifies the "wire
format" for ECON services and explicitly leaves open the possibility
for many different types of deployment.
For instance:
During discovery, a client may be directed to issue all queries to
an ECON service completely authoritative for a given jursidiction.
A client may be directed to issue queries to an ECON server that
acts as a reflector. In such a case, the ECON server analyzes the
query to determine the best server to wich to refer the client.
Hardie, et al. Expires April 24, 2006 [Page 7]
Internet-Draft ECON October 2005
Or the client may be directed to a server that performs further
resolution on behalf of the client.
An ECON service may also be represented by multiple ECON servers,
either grouped together or at multiple network locations. Section 5
discusses database replication of ECON data to multiple servers.
Using S-NAPTR [11], clients may be given a list of multiple servers
to which queries can be sent for a single service.
For instance, the service at emergency.example.com may advertise ECON
service at local1.emergency.example.com,
local2.emergency.example.com, and master.emergency.example.com. Each
server may given a different preference. In this case, 'local1' and
'local2' may be given a lower preference (more preferred) than
'master', which might be a busier server or located further away.
+-----------+ pref 10 +-----------+
| |-------------------->+ |
| client |------ | local1 |
| |--- \ | |
+-----------+ \ \ +-----------+
\ \
\ \ +-----------+
\ \ pref 10 | |
\ --------->| local2 |
\ | |
\ +-----------+
\
\ +-----------+
\ pref 20 | |
------------------------->| master |
| |
+-----------+
For scenarios requiring redirection, a contact ECON server can
instruct the client to redirect the query to another ECON server. If
a client were to issue a query (such as the one in Figure 2), the
responding ECON server could redirect the client to another ECON
server with the following response:
Hardie, et al. Expires April 24, 2006 [Page 8]
Internet-Draft ECON October 2005
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <response xmlns="urn:ietf:params:xml:ns:iris1">
S:
S: <resultSet>
S: <answer>
S:
S: <searchContinuation authority="another.server.example">
S:
S: <findEconByCivic
S: xmlns="urn:ietf:params:xml:ns:econ1" >
S:
S: <civilAddress>
S: <country>US</country>
S: <A1>New York</A1>
S: <A3>New York</A3>
S: <A6>Broadway</A6>
S: <HNO>123</HNO>
S: <LOC>Suite 75</LOC>
S: <PC>10027-0401</PC>
S: </civilAddress>
S:
S: <service>sos.police</service>
S:
S: </findEconByCivic>
S:
S: </searchContinuation>
S:
S: </answer>
S:
S: </resultSet>
S:
S: </response>
Finally, some deployment scenarios may find it necessary to minimize
the number of packets sent across the network for reasons of
performance. Given the same bootstrap process in Section 2.3, the
client would be given the following URIs:
Hardie, et al. Expires April 24, 2006 [Page 9]
Internet-Draft ECON October 2005
+--------------+-----------------------------+
| Purpose Type | URI Value |
+--------------+-----------------------------+
| 8 | iris.lwz:econ1//192.0.2.11/ |
| 9 | iris.lwz:econ1//192.0.2.22/ |
| 10 | iris.lwz:econ1//192.0.2.33/ |
| 11 | iris.lwz:econ1//192.0.2.44/ |
+--------------+-----------------------------+
Figure 6: DHCP URI Example
For the sake of redundancy, multiple URIs may be given pointing to
different servers or one URI may be given utilizing an anycast IP
address routing to multiple servers. Utilizing either method, there
is only one round-trip to map a location to a URI.
Hardie, et al. Expires April 24, 2006 [Page 10]
Internet-Draft ECON October 2005
3. Schema Description
IRIS [3] requires the derivation of both query and result elements by
a registry schema. These descriptions follow.
References to XML elements without a namespace qualifier are from the
schema defined in this document. References to elements and
attributes with the "iris" XML namespace qualifier are from the
schema defined in IRIS [3]. Reference to elements and attributes
with the "civilLoc" XML namespace qualifier are from the civil
location schema defined in PIDF-LO [8]. References to elements and
attributes with the "gml" XML namespace qualifier are from the GML
[7].
The descriptions contained within this section refer to XML elements
and attributes and their relation to the exchange of data within the
protocol. These descriptions also contain specifications outside the
scope of the formal XML syntax. This section will use terms defined
by RFC 2119 to describe these. While reading this section, please
refer below for needed details on the formal XML syntax.
3.1 Query Derivatives
3.1.1 <findEconByCivic> Query
The <findEconByCivic> query allows a client to search for an
emergency contact using civic information. Civic information is
communicated via a <civilAddress> element defined in the
urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc namespace defined by
the civil location schema in PIDF-LO [8].
This query may also have a <service> element as defined in
Section 3.2.
Finally, this query has an optional 'validate' attribute that can
either be true or false (the default is false). This attribute
indicates that the query is being performed for validation purposes.
3.1.2 <findEconByGeo> Query
The <findEconByGeo> query allows a client to search for an emergency
contact using geo-spatial location information. This geo-spatial
information is communicated via a <location> element defined by GML
[7].
This query may also have a <service> element as defined in
Section 3.2.
Hardie, et al. Expires April 24, 2006 [Page 11]
Internet-Draft ECON October 2005
Finally, this query has an optional 'validate' attribute that can
either be true or false (the default is false). This attribute
indicates that the query is being performed for validation purposes.
3.1.3 <listServices> Query
The <listServices> query allows a client to obtain a list of
emergency services supported by an ECON server. Like the other
queries, it to has a 'validate' attribute that can either be true or
false (the default is false).
3.2 Service Types
Types of emergency service are specified by the <service> element.
Its well-known values are:
1. sos.fire
2. sos.police
3. sos.medical
This information is provided as a hint from the client to the server
and is not intended to produce no results should the <service>
element not be given or if its specified type is not available. In
other words, servers MUST ignore this information if it would cause
no result to be returned.
The purpose of defining a well-known list for this element is so that
these tokens may be localized by client user interfaces. However,
ECON servers may recognize other tokens and may pass them back via
the <listServices> query.
3.3 Result Derivatives
3.3.1 <emergencyContact> Result
The <emergencyContact> result describes the URIs to be used to reach
an emergency contact. It may have an optional <displayName> element
and <service> element (see Section 3.2 which may be used by user
agents for user feedback purposes.
The primary information relayed in this result are URIs to be used to
make contact with emergency services. This result may contain
multiple URIs. These URIs are not provided in preference order, and
clients MUST NOT attach preference to any URI based upon its position
in the list. Server MUST NOT provide more than one URI of the same
URI scheme in a result (e.g. two "sip:" URIs are not allowed). The
Hardie, et al. Expires April 24, 2006 [Page 12]
Internet-Draft ECON October 2005
purpose of providing multiple URIs is to offer multiple methods of
contact.
This query has an optional 'timeToLive' attribute which expresses the
number of minutes a client SHOULD wait before requerying the ECON
server if the client's location has not changed. For clients with
knowledge of their geo-spatial location, this query may also contain
a <polygon> element as defined by GML [7]. This polygon indicates to
the client that the server considers a location change to mean that
the client has moved outside of the polygon.
3.3.2 <emergencyService> Result
The <emergencyService> result describes an emergency service provided
by the ECON server. It consists of a display name and a <service>
element as found in Section 3.2.
3.4 Error Derivatives
The following errors indicate that either a civic address or geo-
spatial location were in some way invalid. These errors provide for
free form text to further explain the error.
3.4.1 <invalidCivicData>
Servers may use the <invalidCivicData> error to inform clients of
semantically invalid civil address information sent in a query. When
the validate attribute on the query was set to true, a server MAY
return this error when the CivicData provided is not recognized as
valid even if the data provided would normally have returned a URI or
set of URIs. This can occur, for example, when an invalid street
name or number is provided but the algorithm for determining the
correct URI is satisfied when a valid county is provided. This
facility will normally only be used in debugging and by technical
professionals; it is not recommended outside of that context.
3.4.2 <invalidGeoData>
Servers may use the <invalidGeoData> error to inform clients of
semantically invalid geo-spatial data sent in a query. When the
validate attribute on the query was set to true, a server MAY return
this error when the GeoData provided is not recognized as valid even
if the data provided would normally return a URI or set of URIs.
This facility will normally only be used in debugging and by
technical professionals; it is not recommended outside of that
context.
Hardie, et al. Expires April 24, 2006 [Page 13]
Internet-Draft ECON October 2005
4. Formal Syntax
This registry schema is specified in the XML Schema notation (see [1]
and [2]). The formal syntax presented here is a complete schema
representation suitable for automated validation of an XML instance
when combined with the formal schema syntax of IRIS [3], PIDF-LO [8]
Civil Location, and GML [7].
<?xml version="1.0"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:econ="urn:ietf:params:xml:ns:econ1"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
xmlns:civilLoc="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:econ1"
elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" />
<import namespace="http://www.opengis.net/gml" />
<annotation>
<documentation>
A schema for finding Emergency Contacts (ECON)
using the Internet Registry Information Service (IRIS)
</documentation>
</annotation>
<!-- -->
<!-- Query types -->
<!-- -->
<complexType name="findEconByCivicType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element name="civilAddress"
type="civilLoc:civilAddress"/>
<element name="service"
type="token" minOccurs="0" />
</sequence>
<attribute name="validate" type="boolean"
default="false" />
</extension>
</complexContent>
Hardie, et al. Expires April 24, 2006 [Page 14]
Internet-Draft ECON October 2005
</complexType>
<element name="findEconByCivic"
type="econ:findEconByCivicType"
substitutionGroup="iris:query" />
<complexType name="findEconByGeoType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element
ref="gml:location"/>
<element name="service"
type="token" minOccurs="0" />
</sequence>
<attribute name="validate" type="boolean"
default="false" />
</extension>
</complexContent>
</complexType>
<element name="findEconByGeo"
type="econ:findEconByGeoType"
substitutionGroup="iris:query" />
<complexType name="listServicesType">
<complexContent>
<extension base="iris:queryType">
<attribute name="validate" type="boolean"
default="false" />
</extension>
</complexContent>
</complexType>
<element name="listServices"
type="econ:listServicesType"
substitutionGroup="iris:query" />
<!-- -->
<!-- Result types -->
<!-- -->
<complexType name="emergencyContactType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="displayName"
type="normalizedString" minOccurs="0" />
Hardie, et al. Expires April 24, 2006 [Page 15]
Internet-Draft ECON October 2005
<element name="service"
type="token"/>
<element ref="gml:Polygon" minOccurs="0" />
<element name="uri"
type="anyURI"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
<attribute name="timeToLive"
type="positiveInteger" />
</extension>
</complexContent>
</complexType>
<element name="emergencyContact"
type="econ:emergencyContactType"
substitutionGroup="iris:result" />
<complexType name="emergencyServiceType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="displayName"
type="normalizedString" minOccurs="0" />
<element name="service"
type="token"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="emergencyService"
type="econ:emergencyServiceType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Error types -->
<!-- -->
<element name="invalidCivicData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
<element name="invalidGeoData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
</schema>
Hardie, et al. Expires April 24, 2006 [Page 16]
Internet-Draft ECON October 2005
Figure 7: econ.xsd
Hardie, et al. Expires April 24, 2006 [Page 17]
Internet-Draft ECON October 2005
5. Database Replication
Local copies of the emergency contact database will need to have data
replicated from a master copy of the emergency contact database.
Three methods may be employeed to conduct this database replication:
1. Database contents may be serialized to a file using the format
specified in Section 5 of IRIS [3]. These files may then be
transfered using FTP or other appropriate file transfer
protocols.
2. Periodic and incremental database replication may be accomplished
using the ECONREP schema provided in Section 5.1.
3. Native database replication methods found with many commercial
and/or highly scalable database management systems may be used as
appropriate.
5.1 ECONREP Model
This section describes a method for replicating ECON databases using
a distinct IRIS profile. This is not the only mechanism for database
replication and any other method that produces synchronization of the
required atomicity and freshness is permitted. ECONREP has the
following characteristics:
o Replication may occur incrementally.
o Changes to ECON data may be replicated to local copies before the
effective date of the changes.
o Replication requests may conducted over XPC [10] allowing the
server to retain lower protocol overhead when transfering large
quantities of data.
o It is a distinctly different set of queries and results for the
purpose of database replication and does not muddle the semantics
of the ECON query and response semantics used between an ECON
client and an ECON service.
Utilizing ECONREP, local copies periodically query the master copy
for a list of changes. The master may reply with the entire list of
changes or may only provide a partial list of changes and inform the
local copy to requery later for the remainder of the change list.
The queries used to conduct replication are <listEconCivicChanges>
and <listEconGeoChanges>, for civic addresses and geospatial
Hardie, et al. Expires April 24, 2006 [Page 18]
Internet-Draft ECON October 2005
locations respectively. Both queries take three parameters: a
location (either geospatial or civic), an emergency service type, and
starting synchronization point (expressed either as a date or as a
starting change set).
Depending on the query, the server will return a series of
<civicChange> results or <geoChange> results. Both types of result
have the following components: the change set to which they belong,
the effective date for the change (may be in the future), a list of
covered locations, and the emergency contact for the covered
locations. The effective date allows replication of future changes
to the data. Its absence means the change is to be effective
immediately.
A change set is composed of two values, a serial number and a set
number. The serial number indicates an overall version of the
database. The set number is used to group results together in sets.
The method used to group sets of results is implementation dependent,
however this is the key used by the client to indicate the last set
of data that was replicated. Entire change sets SHOULD be set at one
time.
If a master becomes too busy or wishes to incrementally replicate
data for other reasons, it may issue a <replicationLimit> error.
This can be done after sending change sets in a response, such as:
response
change set 1
change set 2
change set 3
replication limit
The <replicationLimit> error may have an optional 'backOff' attribute
indicating the number of minutes that should elapse before a
subsequent replication query is attempted.
5.2 ECONREP Formal Syntax
This registry schema is specified in the XML Schema notation (see [1]
and [2]). The formal syntax presented here is a complete schema
representation suitable for automated validation of an XML instance
when combined with the formal schema syntax of IRIS [3], ECON,
PIDF-LO [8] Civil Location, and GML [7].
Hardie, et al. Expires April 24, 2006 [Page 19]
Internet-Draft ECON October 2005
<?xml version="1.0"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:econrep="urn:ietf:params:xml:ns:econ1rep1"
xmlns:econ="urn:ietf:params:xml:ns:econ1"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
xmlns:civilLoc="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:econ1rep1"
elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<import namespace="urn:ietf:params:xml:ns:econ1" />
<import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" />
<import namespace="http://www.opengis.net/gml" />
<annotation>
<documentation>
A schema for replicating Emergency Contact (ECON)
data stores.
</documentation>
</annotation>
<!-- -->
<!-- Query types -->
<!-- -->
<complexType name="listEconCivicChangesType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element name="civilAddress"
type="civilLoc:civilAddress"
minOccurs="0"/>
<element name="service"
type="token" minOccurs="0" />
<choice>
<element name="since" type="dateTime" />
<element name="startingChangeSet"
type="econrep:changeSetType" />
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Hardie, et al. Expires April 24, 2006 [Page 20]
Internet-Draft ECON October 2005
<element name="listEconCivicChanges"
type="econrep:listEconCivicChangesType"
substitutionGroup="iris:query" />
<complexType name="listEconGeoChangesType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element
ref="gml:location"
minOccurs="0"/>
<element name="service"
type="token" minOccurs="0" />
<choice>
<element name="since" type="dateTime" />
<element name="startingChangeSet"
type="econrep:changeSetType" />
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="listEconGeoChanges"
type="econrep:listEconGeoChangesType"
substitutionGroup="iris:query" />
<complexType name="changeSetType">
<attribute name="serialNumber"
type="positiveInteger" use="required" />
<attribute name="setNumber"
type="positiveInteger" use="required" />
</complexType>
<!-- -->
<!-- Result types -->
<!-- -->
<complexType name="civicChangeType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="changeSet"
type="econrep:changeSetType" />
<element name="effective"
type="dateTime" minOccurs="0" />
<element name="coveredLocations">
<complexType>
Hardie, et al. Expires April 24, 2006 [Page 21]
Internet-Draft ECON October 2005
<sequence>
<element name="civilAddress"
type="civilLoc:civilAddress"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute
name="coversAllMoreSpecificAddresses"
type="boolean" default="false"/>
</complexType>
</element>
<element ref="econ:emergencyContact"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="civicChange"
type="econrep:civicChangeType"
substitutionGroup="iris:result" />
<complexType name="geoChangeType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="changeSet"
type="econrep:changeSetType" />
<element name="effective"
type="dateTime" minOccurs="0" />
<element name="coveredLocations">
<complexType>
<sequence>
<element
ref="gml:location"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element ref="econ:emergencyContact"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="geoChange"
Hardie, et al. Expires April 24, 2006 [Page 22]
Internet-Draft ECON October 2005
type="econrep:geoChangeType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Error types -->
<!-- -->
<complexType name="replicationLimitType">
<complexContent>
<extension base="iris:codeType">
<attribute name="backOff"
type="positiveInteger" />
</extension>
</complexContent>
</complexType>
<element name="replicationLimit"
type="econrep:replicationLimitType"
substitutionGroup="iris:genericCode" />
</schema>
Figure 8: econrep.xsd
Hardie, et al. Expires April 24, 2006 [Page 23]
Internet-Draft ECON October 2005
6. URI Resolution
6.1 Application Service Label
The application service label associated with ECON MUST be "ECON1".
This is the abbreviated form of the URN for this registry type,
urn:ietf:params:xml:ns:econ1.
The application service label associated with ECONREP MUST be
"ECON1REP1". This is the abbreviated form of the URN for this
registry type, urn:ietf:params:xml:ns:econ1rep1.
Hardie, et al. Expires April 24, 2006 [Page 24]
Internet-Draft ECON October 2005
7. Security Considerations
There are multiple threats to the overall system of which this forms
a part. An attacker that can obtain emergency service contact URIs
can use those URIs to attempt to disrupt emergency services. An
attacker that can prevent the lookup of contact URIs can hinder the
request of emergency services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this as a
springboard to a physical attack.
Hardie, et al. Expires April 24, 2006 [Page 25]
Internet-Draft ECON October 2005
8. Internationalization Considerations
Implementers should be aware of considerations for
internationalization in IRIS [3].
Hardie, et al. Expires April 24, 2006 [Page 26]
Internet-Draft ECON October 2005
9. IANA Considerations
9.1 XML Namespace URN Registration
This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [6]. Accordingly, the following
registration information is provided for the IANA regarding ECON:
o URN/URI:
* urn:ietf:params:xml:ns:econ1
o Contact:
* Andrew Newton <andy@hxr.us>
* Ted Hardie <hardie@qualcomm.com>
o XML:
* The XML Schema specified in Section 4
This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [6]. Accordingly, the following
registration information is provided for the IANA regarding ECONREP:
o URN/URI:
* urn:ietf:params:xml:ns:econ1rep1
o Contact:
* Andrew Newton <andy@hxr.us>
* Ted Hardie <hardie@qualcomm.com>
o XML:
* The XML Schema specified in Section 5.2
9.2 S-NAPTR Registration
The following S-NAPTR application service labels will need to be
registered with IANA according to the IANA considerations defined in
IRIS [3]:
Hardie, et al. Expires April 24, 2006 [Page 27]
Internet-Draft ECON October 2005
ECON1
ECON1REP1
9.3 BEEP Registration
The following BEEP Profile URIs are to be registeried with IANA, in
addition to the registration provided in IRIS-BEEP [4].
http://iana.org/beep/iris1/econ1
http://iana.org/beep/iris1/econ1rep1
Hardie, et al. Expires April 24, 2006 [Page 28]
Internet-Draft ECON October 2005
10. References
10.1 Normative References
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[2] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[3] Newton, A. and M. Sanz, "Internet Registry Information Service",
RFC 3891, January 2005.
[4] Newton, A. and M. Sanz, "Internet Registry Information Service
(IRIS) over Blocks Extensible Exchange Protocol (BEEP)",
RFC 3893, January 2005.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[6] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001.
[7] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
[8] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004.
10.2 Informative References
[9] Newton, A., "A Lightweight UDP Transport for IRIS",
draft-ietf-crips-iris-lwz-03 (work in progress), June 2005.
[10] Newton, A., "XML Pipelining with Chunks",
draft-ietf-crips-iris-xpc-01 (work in progress), June 2005.
[11] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
Hardie, et al. Expires April 24, 2006 [Page 29]
Internet-Draft ECON October 2005
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Andrew Newton
Verisign, Inc.
Hannes Tschofenig
Siemens
Hardie, et al. Expires April 24, 2006 [Page 30]
Internet-Draft ECON October 2005
Appendix A. Object Signing
The authors considered several mechanisms for attaching digital
signatures to one or more parts of the ECON response. After this
consideration, they were all rejected. The authors believe that the
mechanisms available to check the validity of the digital signature
are too heavyweight for the use cases in which the query is made
immediately prior to an emergency call. In those cases, the authors
believe that the rational response is to attempt the emergency call
whether the digital signature is valid or invalid. Further, we
believe that the check could add significant time and network round
trips to the call set-up, which is clearly undesirable in this case.
Other use cases, for validation or replication, might benefit from
object signatures, but they have been omitted at this time as
requiring more implementation and deployment resources than are
justified by the return. Details on lightweight mechanisms which
might change the value of digital signatures for one or more of these
use cases would be welcomed by the authors.
Hardie, et al. Expires April 24, 2006 [Page 31]
Internet-Draft ECON October 2005
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 (2005). 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.
Hardie, et al. Expires April 24, 2006 [Page 32]
