Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Expires: January 14, 2006 A. Newton Verisign, Inc. H. Tschofenig Siemens July 13, 2005 An IRIS schema for Emergency Service contact URIs draft-hardie-ecrit-iris-02.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 January 14, 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 January 14, 2006 [Page 1] Internet-Draft ECON July 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 . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Query . . . . . . . . . . . . . . . 9 3.1.2 Query . . . . . . . . . . . . . . . . 9 3.1.3 Query . . . . . . . . . . . . . . . . . 10 3.2 Service Types . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Result Derivatives . . . . . . . . . . . . . . . . . . . . 11 3.3.1 Result . . . . . . . . . . . . . . 11 3.3.2 Result . . . . . . . . . . . . . . 12 3.4 Error Derivatives . . . . . . . . . . . . . . . . . . . . 12 3.4.1 . . . . . . . . . . . . . . . . . . 12 3.4.2 . . . . . . . . . . . . . . . . . . . 12 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Database Replication . . . . . . . . . . . . . . . . . . . . . 17 5.1 ECONREP Model . . . . . . . . . . . . . . . . . . . . . . 17 5.2 ECONREP Formal Syntax . . . . . . . . . . . . . . . . . . 18 6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 23 6.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 23 6.2 Server Authentication . . . . . . . . . . . . . . . . . . 23 7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1 Application Service Label . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Internationalization Considerations . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 10.1 XML Namespace URN Registration . . . . . . . . . . . . . . 27 10.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 27 10.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1 Normative References . . . . . . . . . . . . . . . . . . . 29 11.2 Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 A. Object Signing . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 32 Hardie, et al. Expires January 14, 2006 [Page 2] Internet-Draft ECON July 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 January 14, 2006 [Page 3] Internet-Draft ECON July 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 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. Hardie, et al. Expires January 14, 2006 [Page 4] Internet-Draft ECON July 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 January 14, 2006 [Page 5] Internet-Draft ECON July 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: C: C: C: C: C: C: C: US C: New York C: New York C: Broadway C: 123 C: Suite 75 C: 10027-0401 C: C: C: police C: C: C: C: C: C: 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 January 14, 2006 [Page 6] Internet-Draft ECON July 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: S: S: S: S: S: S: S: S: New York City Police Department S: S: police S: S: sip:nypd@example.com S: xmpp:nypd@example.com S: S: S: S: S: S: S: S: S: 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 January 14, 2006 [Page 7] Internet-Draft ECON July 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 | | | +-----------+ Hardie, et al. Expires January 14, 2006 [Page 8] Internet-Draft ECON July 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 Query The query allows a client to search for an emergency contact using civic information. Civic information is communicated via a 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 service type elements 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 Query The query allows a client to search for an emergency contact using geo-spatial location information. This geo-spatial information is communicated via a element defined by GML [7]. This query may also have service type elements as defined in Section 3.2. Hardie, et al. Expires January 14, 2006 [Page 9] Internet-Draft ECON July 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 Query The 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 three elements: , and . Each element is optional as each may not apply to all types of emergency service. Each element holds a single token. The element describes which emergency function is to be performed. Its well-known values are: 1. fire 2. rescue 3. police 4. ambulance 5. medical 6. psychological 7. utility The element describes the type area in which the service function will need to be performed. Its well-known values are: 1. mountain 2. marine 3. urban 4. rural The element describes the people in need of emergency Hardie, et al. Expires January 14, 2006 [Page 10] Internet-Draft ECON July 2005 service. Its well-known values are: 1. infant 2. child 3. adult 4. crowd This information is provided as a hint from the client to the server and is not intended to produce no results should the 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 well-known lists for these elements 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 query. 3.3 Result Derivatives 3.3.1 Result The result describes the URIs to be used to reach an emergency contact. It may have an optional element and service type elements (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 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 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. Hardie, et al. Expires January 14, 2006 [Page 11] Internet-Draft ECON July 2005 3.3.2 Result The result describes an emergency service provided by the ECON server. It consists of a display name and the service type elements 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 Servers may use the 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 Servers may use the 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 January 14, 2006 [Page 12] Internet-Draft ECON July 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]. A schema for finding Emergency Contacts (ECON) using the Internet Registry Information Service (IRIS) Hardie, et al. Expires January 14, 2006 [Page 13] Internet-Draft ECON July 2005 Hardie, et al. Expires January 14, 2006 [Page 14] Internet-Draft ECON July 2005 Hardie, et al. Expires January 14, 2006 [Page 15] Internet-Draft ECON July 2005 Figure 5: econ.xsd Hardie, et al. Expires January 14, 2006 [Page 16] Internet-Draft ECON July 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 and , for civic addresses and geospatial Hardie, et al. Expires January 14, 2006 [Page 17] Internet-Draft ECON July 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 results or 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 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 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 January 14, 2006 [Page 18] Internet-Draft ECON July 2005 A schema for replicating Emergency Contact (ECON) data stores. Hardie, et al. Expires January 14, 2006 [Page 19] Internet-Draft ECON July 2005 Hardie, et al. Expires January 14, 2006 [Page 20] Internet-Draft ECON July 2005 Figure 6: econrep.xsd Hardie, et al. Expires January 14, 2006 [Page 22] Internet-Draft ECON July 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. Additionally, it is envisioned that an ECONREP service will be deployed with [10], but it is still possible to use ECONREP with [4]. The use of [4] 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 These registry types use the default message pattern as described in IRIS-BEEP [4]. 6.2 Server Authentication These registry types use the default server authentication method as described in IRIS-BEEP [4]. Hardie, et al. Expires January 14, 2006 [Page 23] Internet-Draft ECON July 2005 7. URI Resolution 7.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 January 14, 2006 [Page 24] Internet-Draft ECON July 2005 8. 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 January 14, 2006 [Page 25] Internet-Draft ECON July 2005 9. Internationalization Considerations Implementers should be aware of considerations for internationalization in IRIS [3]. Hardie, et al. Expires January 14, 2006 [Page 26] Internet-Draft ECON July 2005 10. IANA Considerations 10.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 * Ted Hardie 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 * Ted Hardie o XML: * The XML Schema specified in Section 5.2 10.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 January 14, 2006 [Page 27] Internet-Draft ECON July 2005 ECON1 ECON1REP1 10.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 January 14, 2006 [Page 28] Internet-Draft ECON July 2005 11. References 11.1 Normative References [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . [2] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [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. 11.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 January 14, 2006 [Page 29] Internet-Draft ECON July 2005 Authors' Addresses Ted Hardie Qualcomm, Inc. Andrew Newton Verisign, Inc. Hannes Tschofenig Siemens Hardie, et al. Expires January 14, 2006 [Page 30] Internet-Draft ECON July 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 January 14, 2006 [Page 31] Internet-Draft ECON July 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 January 14, 2006 [Page 32]