Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
Expires: December 29, 2005 A. Newton
Verisign, Inc.
H. Tschofenig
Siemens
June 27, 2005
An IRIS schema for Emergency Service contact URIs
draft-hardie-ecrit-iris-01.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 December 29, 2005.
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 December 29, 2005 [Page 1]
Internet-Draft ECON June 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
2.5 Beyond Scope . . . . . . . . . . . . . . . . . . . . . . . 8
3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 9
3.1.1 <findEconByCivic> Query . . . . . . . . . . . . . . . 9
3.1.2 <findEconByGeo> Query . . . . . . . . . . . . . . . . 9
3.2 Service Types . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Result Derivatives . . . . . . . . . . . . . . . . . . . . 10
3.3.1 <emergencyContact> Result . . . . . . . . . . . . . . 10
3.4 Error Derivatives . . . . . . . . . . . . . . . . . . . . 11
3.4.1 <invalidCivicData> . . . . . . . . . . . . . . . . . . 11
3.4.2 <invalidGeoData> . . . . . . . . . . . . . . . . . . . 11
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 16
6.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 16
6.2 Server Authentication . . . . . . . . . . . . . . . . . . 16
7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Application Service Label . . . . . . . . . . . . . . . . 17
8. Internationalization Considerations . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1 XML Namespace URN Registration . . . . . . . . . . . . . . 19
9.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 19
9.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1 Normative References . . . . . . . . . . . . . . . . . . . 20
10.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
A. Example Request and Response . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 25
Hardie, et al. Expires December 29, 2005 [Page 2]
Internet-Draft ECON June 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 December 29, 2005 [Page 3]
Internet-Draft ECON June 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 Capable of using multiple transfer mechanisms, including a
lightweight UDP transfer protocol for minimal overhead and the
reduction of roundtrips.
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 one or many
URIs, 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.
Hardie, et al. Expires December 29, 2005 [Page 4]
Internet-Draft ECON June 2005
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
small XML interactions and stateless transactions so that the UDP-
based transfer protocol LWZ [9] may be employeed for fast response
times. IRIS may also be used with TLS-protected protocols such as
XPC [10] when security is needed. ECON service operators may
determine which transfer protocol most meets their needs, and
advertise their availability using the DNS DDDS application S-NAPTR
[11].
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 and 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 for help from
the police) the following protocol interaction takes place using UDP-
based transfer protocol LWZ. The client encapsulates the received
Hardie, et al. Expires December 29, 2005 [Page 5]
Internet-Draft ECON June 2005
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.
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>police</service>
C:
C: </findEconByCivic>
C:
C: </searchSet>
C:
C: </request>
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 December 29, 2005 [Page 6]
Internet-Draft ECON June 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="nyc.example" registryType="econ1"
S: entityClass="econ" entityName="nypd" >
S:
S: <displayName>
S: New York City Police Department
S: </displayName>
S: <uri>
S: sip://nypd.example/
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.
Or the client may be directed to a server that performs further
resolution on behalf of the client.
Hardie, et al. Expires December 29, 2005 [Page 7]
Internet-Draft ECON June 2005
2.5 Beyond Scope
The aspect of high-availability, server redundancy, and IP-based load
balancing is beyond the scope of this document and the work of the
ECRIT working group. Because ECON services use IRIS and IRIS uses
S-NAPTR [11], ECON services may be made redudant and load-balanced
using well understood DNS-based priorities (via SRV records). This
is basically the same technique used to make SMTP mail services
redundant and load-balanced.
The aspect of updating information stored at ECON servers is an
orthogonal issue (since it is outside the scope of the working
group). IRIS, with its modular architecture, offers advantages in
this area because of the support for different transfer protocols
that can be selectively tailored to the particular communication
purpose. For example, end host to ECON server communication
typically should provide proper performance charactistics (e.g.,
regarding roundtrip-time, size of individual messages, number of
exchanged messages, supported security mechanisms, etc.). ECON
server to server communication to be subject to different
constraints, particular regarding update operation.
Hardie, et al. Expires December 29, 2005 [Page 8]
Internet-Draft ECON June 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 the <service> (Section 3.2) element.
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 the <service> (Section 3.2) element.
Finally, this query has an optional 'validate' attribute that can
either be true or false (the default is false). This attribute
Hardie, et al. Expires December 29, 2005 [Page 9]
Internet-Draft ECON June 2005
indicates that the query is being performed for validation purposes.
3.2 Service Types
Queries may be focused on certain types of emergency contact using
the optional <service> element. This element may contain the
following well-known tokens:
1. ecc
2. fire
3. rescue
4. marine
5. police
6. mountain
7. gas
8. ambulance
9. doctor
10. pyschological
11. kids
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.
3.3 Result Derivatives
3.3.1 <emergencyContact> Result
The <emergencyContact> result provides describes the URIs to be used
to reach an emergency contact. It may have an optional <displayName>
element 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
Hardie, et al. Expires December 29, 2005 [Page 10]
Internet-Draft ECON June 2005
in the list. Server MUST NOT provide more than one URI of the scheme
in a result (e.g. two "sip:" URIs are not allowed). The purpose of
providing multiple URIs is to offer multiple methods of contact.
3.4 Error Derivatives
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 December 29, 2005 [Page 11]
Internet-Draft ECON June 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="econ:serviceType" minOccurs="0"/>
</sequence>
<attribute name="validate" type="boolean"
default="false" />
</extension>
Hardie, et al. Expires December 29, 2005 [Page 12]
Internet-Draft ECON June 2005
</complexContent>
</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="econ:serviceType" minOccurs="0"/>
</sequence>
<attribute name="validate" type="boolean"
default="false" />
</extension>
</complexContent>
</complexType>
<element name="findEconByGeo"
type="econ:findEconByGeoType"
substitutionGroup="iris:query" />
<simpleType
name="serviceType">
<restriction
base="string">
<enumeration value="ecc" />
<enumeration value="fire" />
<enumeration value="rescue" />
<enumeration value="marine" />
<enumeration value="police" />
<enumeration value="mountain" />
<enumeration value="gas" />
<enumeration value="ambulance" />
<enumeration value="doctor" />
<enumeration value="psychological" />
<enumeration value="kids" />
</restriction>
</simpleType>
<!-- -->
<!-- Result types -->
<!-- -->
Hardie, et al. Expires December 29, 2005 [Page 13]
Internet-Draft ECON June 2005
<complexType name="emergencyContactType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="displayName"
type="normalizedString" minOccurs="0" />
<element name="uri"
type="anyURI"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="emergencyContact"
type="econ:emergencyContactType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Error types -->
<!-- -->
<element name="invalidCivicData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
<element name="invalidGeoData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
</schema>
Figure 4: econ.xsd
Hardie, et al. Expires December 29, 2005 [Page 14]
Internet-Draft ECON June 2005
5. 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 December 29, 2005 [Page 15]
Internet-Draft ECON June 2005
6. BEEP Transport Compliance
Though it is envisioned that an ECON service will be deployed with a
lightweight transport such as [9], it is still possible to use ECON
with the [4] transport. The use of this transport is completely at
the descretion of the server operator.
IRIS allows several extensions of the core capabilities. This
section outlines those extensions allowable by IRIS-BEEP [4].
6.1 Message Pattern
This registry type uses the default message pattern as described in
IRIS-BEEP [4].
6.2 Server Authentication
This registry type uses the default server authentication method as
described in IRIS-BEEP [4].
Hardie, et al. Expires December 29, 2005 [Page 16]
Internet-Draft ECON June 2005
7. URI Resolution
7.1 Application Service Label
The application service label associated with this registry type MUST
be "ECON1". This is the abbreviated form of the URN for this
registry type, urn:ietf:params:xml:ns:econ1.
Hardie, et al. Expires December 29, 2005 [Page 17]
Internet-Draft ECON June 2005
8. Internationalization Considerations
Implementers should be aware of considerations for
internationalization in IRIS [3].
Hardie, et al. Expires December 29, 2005 [Page 18]
Internet-Draft ECON June 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:
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
9.2 S-NAPTR Registration
The following S-NAPTR application service label will need to be
registered with IANA according to the IANA considerations defined in
IRIS [3]:
ECON1
9.3 BEEP Registration
The following BEEP Profile URI is to be registeried with IANA, in
addition to the registration provided in IRIS-BEEP [4].
http://iana.org/beep/iris1/econ1
Hardie, et al. Expires December 29, 2005 [Page 19]
Internet-Draft ECON June 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 December 29, 2005 [Page 20]
Internet-Draft ECON June 2005
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Andrew Newton
Verisign, Inc.
Hannes Tschofenig
Siemens
Hardie, et al. Expires December 29, 2005 [Page 21]
Internet-Draft ECON June 2005
Appendix A. Example Request and Response
The example in this section use the string "C:" to denote data sent
by a client to a server and the string "S:" to denote data sent by a
server to a client.
The following example demonstrates a query based on civil location
information and a response to that query.
Hardie, et al. Expires December 29, 2005 [Page 22]
Internet-Draft ECON June 2005
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>police</service>
C:
C: </findEconByCivic>
C:
C: </searchSet>
C:
C: </request>
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="nyc.example" registryType="econ1"
S: entityClass="econ" entityName="nypd" >
S:
S: <displayName>
S: New York City Police Department
S: </displayName>
S: <uri>
S: sip://nypd.example/
S: </uri>
S:
S: </emergencyContact>
S:
S: </answer>
S:
S: </resultSet>
S:
S: </response>
Hardie, et al. Expires December 29, 2005 [Page 23]
Internet-Draft ECON June 2005
Figure 5: Example 1
Hardie, et al. Expires December 29, 2005 [Page 24]
Internet-Draft ECON June 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 December 29, 2005 [Page 25]