ECRIT                                                          T. Hardie
Internet-Draft                                            Qualcomm, Inc.
Expires: November 14, 2005                                     A. Newton
                                                          Verisign, Inc.
                                                           H. Tschofenig
                                                                 Siemens
                                                            May 13, 2005


           An IRIS Schema for Emergency Service Contact URIs
                     draft-hardie-ecrit-iris-00.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 November 14, 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 based on IRIS, the Internet Registry Information Service, and
   starts from the premise that the search for emergency service
   contacts can be modelled as a database search that uses geolocation



Hardie, et al.          Expires November 14, 2005               [Page 1]

Internet-Draft                  IRIS-ECON                       May 2005


   or civic location as input and returns one or more contact URIs as
   output.  It is intended to fit within a larger framework of
   standards. specifically, it presumes the existence of a URI scheme
   appropriate for signaling that emergency service is required and
   distinguishing 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
   3.  Schema Description . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   Query Derivatives  . . . . . . . . . . . . . . . . . . . .  5
       3.1.1   <findEconByCivic> Query  . . . . . . . . . . . . . . .  5
       3.1.2   <findEconByGeo> Query  . . . . . . . . . . . . . . . .  5
     3.2   Service Types  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3   Result Derivatives . . . . . . . . . . . . . . . . . . . .  6
       3.3.1   <emergencyContact> Result  . . . . . . . . . . . . . .  6
     3.4   Error Derivatives  . . . . . . . . . . . . . . . . . . . .  6
       3.4.1   <invalidCivicData> . . . . . . . . . . . . . . . . . .  6
       3.4.2   <invalidGeoData> . . . . . . . . . . . . . . . . . . .  7
   4.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     5.1   Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 11
     5.2   Message Modification and Replay Attacks  . . . . . . . . . 11
     5.3   Loss of confidentiality  . . . . . . . . . . . . . . . . . 12
     5.4   Impersonating an IRIS Sever  . . . . . . . . . . . . . . . 12
     5.5   Denial of Service  . . . . . . . . . . . . . . . . . . . . 12
   6.  BEEP Transport Compliance  . . . . . . . . . . . . . . . . . . 14
     6.1   Message Pattern  . . . . . . . . . . . . . . . . . . . . . 14
     6.2   Server Authentication  . . . . . . . . . . . . . . . . . . 14
   7.  URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1   Application Service Label  . . . . . . . . . . . . . . . . 15
   8.  Internationalization Considerations  . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     9.1   XML Namespace URN Registration . . . . . . . . . . . . . . 17
     9.2   S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 17
     9.3   BEEP Registration  . . . . . . . . . . . . . . . . . . . . 17
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2  Informative References . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Example Request and Response . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 23






Hardie, et al.          Expires November 14, 2005               [Page 2]

Internet-Draft                  IRIS-ECON                       May 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 [8].














































Hardie, et al.          Expires November 14, 2005               [Page 3]

Internet-Draft                  IRIS-ECON                       May 2005


2.  Introduction

   This document describes a protocol for taking location information
   compatible with PIDF-LO [11] 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.

   One consequence of this flexibility is that there are multiple
   methods for discovering an IRIS server at which to start the query
   process.  An IRIS server may be preconfigured in the call processing
   software performing the lookup.  If an appropriate option is
   specified, it could be configured dynamically using DHCP [4].  It
   might also be discovered using a mechanism like DDDS [5].

   It is likely that a combination of these methods will be needed to
   ensure complete coverage; the delegation of an infrastructure domain
   or the deployment of well-known servers may also be required.  Note
   that once a server has been discovered, IRIS can use referrals to
   indicate that a different server will be a more appropriate query
   target.

























Hardie, et al.          Expires November 14, 2005               [Page 4]

Internet-Draft                  IRIS-ECON                       May 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 [11].  References to elements and
   attributes with the "gml" XML namespace qualifier are from the GML
   [10].

   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 [11].

   This query may also have the <service> (Section 3.2) element.

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
   [10].

   This query may also have the <service> (Section 3.2) element.

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:




Hardie, et al.          Expires November 14, 2005               [Page 5]

Internet-Draft                  IRIS-ECON                       May 2005


   1.  ecc

   2.  fire

   3.  rescue

   4.  marine

   5.  police

   6.  mountain

   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
   in the list.  Servers 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.  The protocols associated with specific contact methods may
   have internal mechanisms for forking or forwarding contacts, and,
   since these will likely be based on fresher data than that associated
   with a search service,  they are used in preference to multiple same-
   scheme URIS.

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.






Hardie, et al.          Expires November 14, 2005               [Page 6]

Internet-Draft                  IRIS-ECON                       May 2005


3.4.2  <invalidGeoData>

   Servers may use the <invalidGeoData> error to inform clients of
   semantically invalid geo-spatial data sent in a query.















































Hardie, et al.          Expires November 14, 2005               [Page 7]

Internet-Draft                  IRIS-ECON                       May 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 [11]
   Civil Location, and GML [10].

   <?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>
         </extension>
       </complexContent>
     </complexType>

     <element name="findEconByCivic"



Hardie, et al.          Expires November 14, 2005               [Page 8]

Internet-Draft                  IRIS-ECON                       May 2005


       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>
         </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" />
       </restriction>
     </simpleType>

     <!--              -->
     <!-- Result types -->
     <!--              -->

     <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>



Hardie, et al.          Expires November 14, 2005               [Page 9]

Internet-Draft                  IRIS-ECON                       May 2005


       </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 1: econ.xsd





























Hardie, et al.          Expires November 14, 2005              [Page 10]

Internet-Draft                  IRIS-ECON                       May 2005


5.  Security Considerations

   Security considerations specific to IRIS are treated in the general
   IRIS [3] document as well as in the specific transport documents
   IRIS-BEEP [7] IRIS-LWZ [12].  Security threats and requirements for
   ECRIT are treated in draft-tschofenig-ecrit-security-threats-00.txt
   [6].  Please note that IRIS-LWZ does not provide built-in security
   and relies on external mechanisms, such as IPsec, and might therefore
   not be suitable to fulfill the requirements listed in [6].
   Investigations regarding the suitability of the other transport
   mechanisms, such as the work in progress approach of IRIS-LWZ, are
   necessary since they do not allow TLS or SASL to be used.  Hence, the
   discussion of the security threats and their countermeasures mainly
   focus on transport mechanisms used by IRIS that can benefit from TLS
   and/or SASL security.

   In general, there are multiple threats to the overall emergency
   system.  A subset of them are applicable for this document.  More
   specifically the following security aspects need to be addressed:

5.1  Impersonating a PSAP

   Threat: An attacker might want to provide emergency callers with
      wrong information about emergency service contact URIs.  An
      adversary can accomplish this goal in various ways, including
      message modification, spoofing the IRIS server or corrupting the
      IRIS database.  Section 4.4 and 5.4 of [6] describe this threat in
      more detail.

   Countermeasure: In addition to the countermeasures described in
      subsequent sections (for example, countermeasures against message
      modification) it is necessary for the client to authenticate and
      to authorize the IRIS server that provides the emergency service
      contact URIs since these these URIs are later used to contact a
      PSAP.  This functionality is accomplished either using TLS (with
      server-side authentication), SASL or a combination of them as part
      of the transport mechanisms utilized by IRIS (such as BEEP or
      XPC).


5.2  Message Modification and Replay Attacks

   Threat: An adversary might attempt to modify the IRIS message
      communication described in this document.  A successful
      modification might prevent the emergency caller from contact
      further IRIS servers or PSAPs or might redirect them to wrong
      entities.  Additionaly it might be possible to replay past
      communication exchanges to fool an emergency caller by returning



Hardie, et al.          Expires November 14, 2005              [Page 11]

Internet-Draft                  IRIS-ECON                       May 2005


      incorrect or no results.

   Countermeasure: In order to prevent this threat integrity and replay
      protection mechanism must be provided as offered by the TLS Record
      Layer and by SASL.  The required session keys are established as
      part of the authentication and key exchange protocol, such as the
      TLS Handshake protocol in case of TLS.  SASL provides similar
      functionality by establishing an integrity and replay protected
      channel.


5.3  Loss of confidentiality

   Threat: 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.

   Countermeasure: To prevent an adversary from learning information
      about the content of the communication  between client and the
      server it is necessary to provide confidentiality protection.  The
      TLS Record Layer and SASL provide this type of protection as long
      as the respective cipher suites are negotiated.


5.4  Impersonating an IRIS Sever

   Threat: An adversary might run a faked IRIS server aiming to pretend
      that it is a legitimate server.

   Countermeasure: It is necessary for the client to authenticate and to
      authorize the IRIS server as part of the authentication and key
      exchange protocol.  Assuming that there is no prior relationship
      between the emergency caller and the IRIS server (in the worst
      case) public key based authentication seems to be the best choice.
      Additional approaches for bootstrapping the security
      associationship by exploiting existing relationships (such as
      between the network access infrastructure provider and an IRIS
      server) might simplify the key management.  The authorization
      aspects need further study.


5.5  Denial of Service








Hardie, et al.          Expires November 14, 2005              [Page 12]

Internet-Draft                  IRIS-ECON                       May 2005


   Threat: An adversary might want to mount a denial of service attack
      against one or multiple IRIS server to prevent an emergency caller
      from obtaining emergency service contact URIs.

   Countermeasure: Dealing with all sorts of denial of service attacks
      against the emergency infrastructure and at IRIS servers is
      difficult.  Protection needs to be provided at different protocol
      layers and also at different locations in the network.  From the
      viewpoint of this document it needs to be ensured that the used
      security mechanisms do not increase the vulnerability against
      denial of service attacks.  TLS, for example, does not provide the
      same degree of denial of service protection as IKEv2 (with its
      stateless cookie approach).  Still, it seems to provide enough
      protection to counter most attacks.  Additionally, it is essential
      to ensure that IRIS queries submitted by adversary towards the
      IRIS server do not cause a major performance impact for the server
      with the consequence that potentially genuine requests may need to
      be rejected due to overload and a timely response is not possible.
      It must be noted that clients will typically not be authenticated
      by the IRIS server either due to the missing client-side public
      key infrastructure and due to the authentication-override
      principle that exists for emergency calls.





























Hardie, et al.          Expires November 14, 2005              [Page 13]

Internet-Draft                  IRIS-ECON                       May 2005


6.  BEEP Transport Compliance

   Though it is envisioned that an ECON service will be deployed with a
   lightweight transport such as [12], it is still possible to use ECON
   with the [7] 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 [7].

6.1  Message Pattern

   This registry type uses the default message pattern as described in
   IRIS-BEEP [7].

6.2  Server Authentication

   This registry type uses the default server authentication method as
   described in IRIS-BEEP [7].
































Hardie, et al.          Expires November 14, 2005              [Page 14]

Internet-Draft                  IRIS-ECON                       May 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 November 14, 2005              [Page 15]

Internet-Draft                  IRIS-ECON                       May 2005


8.  Internationalization Considerations

   Implementers should be aware of considerations for
   internationalization in IRIS [3].















































Hardie, et al.          Expires November 14, 2005              [Page 16]

Internet-Draft                  IRIS-ECON                       May 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 [9].  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 [7].

      http://iana.org/beep/iris1/econ1













Hardie, et al.          Expires November 14, 2005              [Page 17]

Internet-Draft                  IRIS-ECON                       May 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]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [5]   Daigle, L. and A. Newton, "Domain-Based Application Service
         Location using SRV RRs and the Dynamic Delegation Discovery
         Service (DDDS)", RFC 3958, January 2005.

   [6]   Tschofenig, H., "Security Threats and Requirements for
         Emergency Calling",
         draft-tschofenig-ecrit-security-threats-00.txt (work in
         progress), May 2005.

   [7]   Newton, A. and M. Sanz, "Internet Registry Information Service
         (IRIS) over  Blocks Extensible Exchange Protocol (BEEP)",
         RFC 3893, January 2005.

   [8]   Bradner, S., "Key words for use in RFCs to  Indicate
         Requirement Levels", RFC 2119, BCP 14, March 1997.

   [9]   Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-03 (work in progress),
         November 2001.

   [10]  OpenGIS, "Open Geography Markup Language (GML) Implementation
         Specification", OGC OGC 02-023r4, January 2003.

   [11]  Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
         September 2004.







Hardie, et al.          Expires November 14, 2005              [Page 18]

Internet-Draft                  IRIS-ECON                       May 2005


10.2  Informative References

   [12]  Newton, A., "A Lightweight UDP Transport for IRIS",
         draft-ietf-crips-iris-lwz-01 (work in progress), January 2005.


Authors' Addresses

   Ted Hardie
   Qualcomm, Inc.
   675 Campbell Technology Parkway
   Campbell, CA
   USA

   Email: hardie@qualcomm.com


   Andrew Newton
   Verisign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   USA

   Email: anewton@verisignlabs.com; andy@hxr.us
   URI:   http://www.verisignlabs.com/


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com

















Hardie, et al.          Expires November 14, 2005              [Page 19]

Internet-Draft                  IRIS-ECON                       May 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 November 14, 2005              [Page 20]

Internet-Draft                  IRIS-ECON                       May 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 November 14, 2005              [Page 21]

Internet-Draft                  IRIS-ECON                       May 2005


                            Figure 2: Example 1


















































Hardie, et al.          Expires November 14, 2005              [Page 22]

Internet-Draft                  IRIS-ECON                       May 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 November 14, 2005              [Page 23]