ECRIT Working Group James Polk Internet-Draft Cisco Systems Expires: August 27th, 2006 Feb 27th, 2006 Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling draft-polk-ecrit-mapping-events-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 August 27th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Emergency calling is a localized event, requiring a caller to place an specially identified local emergency call to a Public Safety Answering Point (PSAP), while including the location of the caller in that signaling. The function of routing the set-up messaging to the appropriate PSAP is performed by a mapping function that binds a given location with one or more PSAP SIP(S)-URIs. This function is done by the ECRIT mapping protocol. This document analyzes when the ECRIT mapping protocol function can occur, and what general components are involved in that mapping. Polk Expires August 27th, 2006 [Page 1] Internet-Draft ECRIT Mapping Events Feb 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Message Flow Assumptions and Rules Outlined . . . . . . . . . 3 3. Mapping Scenarios Outlined . . . . . . . . . . . . . . . . . 5 3.1 Scenario #1 - Alice Needs Configuration Data . . . . . . . 5 3.2 Scenario #2 - Alice Invokes Early ECRIT Mapping . . . . . 6 3.2.1 Scenario #2a - DHCP Requested ECRIT Mapping . . . . . . . 6 3.2.2 Scenario #2b - SIP REGISTER Requested ECRIT Mapping . . . 7 3.3 Scenario #3 - Message Flow to PSAP without Early ECRIT Mapping . 9 4. Can Failures of the ECRIT Mapping Function Fail Call Attempts 10 4.1 Reactive ECRIT Mapping Function After Failure . . . . . . . 11 4.2 ESRP Reacts ECRIT Mapping Failure . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 16 1. Introduction Emergency calling is a highly localized event, dependent on the location of the caller, and the caller's ability to input an emergency address, most often this is the calling digits, of the emergency call center. This is highly localized because the first responders that that will render aid to the caller will also be local to the caller. In IP, with its decomposed nature of call control separated from access infrastructure, routing entities requiring knowledge of the location of the caller is more challenging, because there may not be a relationship between the call control organization and the access infrastructure organization. The calling device, here a Session Initiation Protocol (SIP) User Agent (UA), needs to learn its location from the network and include that information in the emergency call signaling to ensure the call set-up messages have the information necessary to route them to the PSAP. There needs to be a mechanism to take the location of the caller and map that location to a emergency address. Compounding this problem is that generally useful national emergency dialstrings are not granular enough to address the specific PSAP that serves a caller's location, which is a byproduct of IP networks: one address gets to one location. The ECRIT Mapping mechanism takes a given location of a device, for example a SIP user agent (UA), and returns the appropriate PSAP URI for that device to use if it initiates a call for emergency help Polk Expires August 27th, 2006 [Page 2] Internet-Draft ECRIT Mapping Events Feb 2006 [ID-ECRIT-REQS]. The mapping mechanism hinges on knowing, or being given, a location to perform a mapping function against. How a device learns its location is not specified here, but can be from a number of means, including: - Manual configuration - Internal GPS measurement - Lower layer triangulation, then informing the UA of its position - Layer 2 interaction with network attachment point (i.e. LLDP-MED or 802.11) - A Layer 7 protocol (i.e. HELD or LCP, etc) - DHCP (for geo [RFC3825] or civic [ID-CIVIC]) The latter appears likely to be the most common non-cellular means of an endpoint learning its location. The PSAP community really wants (demands?) the freshest mapping data possible when a user calls for help. Thus, a working model was envisioned in which the caller, while their call set-up signaling was being routed through the network with the user's location in the set-up message, would have a really smart device understand that this is an emergency call, and perform the mapping to the appropriate PSAP. A question was raised sometime after this model was envisioned that if this mapping function was only performed during the call and failed, for whatever reason, would the call set-up fail. Most agree, this would be a bad thing. Therefore, some folks went off and started working on ideas about when this mapping really was needed, knowing it was needed at some point. This document focuses on when that mapping can occur. 2. Message Flow Assumptions and Rules Outlined This section starts by generalizing when "mapping" can occur. Through this, it is assumed that - SIP is the signaling protocol for call set-up. - Location is included in the SIP Request either by-value or by-reference - SIP messages are well formed Polk Expires August 27th, 2006 [Page 3] Internet-Draft ECRIT Mapping Events Feb 2006 - there are value layer 3 routes between all components in any message flow shown - All URIs within this document use the SIP or SIPS-URI scheme, this includes anywhere there are PSAP-URI or SIP(S)-URI indications written This document will put together rough message flows involving a number of well known components foreseen in emergency calling infrastructures, but without any IP routers, Ethernet switches or other lower layer nodes. The devices included in message flows are: - Alice and her UA - DHCP Server - SIP Registrar - SIP Proxy Server - ECRIT Mapping Server - Emergency Services Routing Proxy (ESRP) - PSAP and all that goes with it ** NOTE - Not all components will be in every message flow, and in fact, rarely will all the above list be in the same message flow. That would make the flow too crowded for the point being made in that subsection. An ESRP is a special instance of a SIP server, be that a SIP Proxy, Session Border Controller (SBC) or Back-to-Back-User-Agent (B2BUA), that understands: a) the concept of location within a SIP message, and b) recognizes calls by their emergency identifier ("urn:services:sos" as specified in [ID-SOS], and c) to perform a mapping function, regardless of the fact that a SIP Request may have a valid PSAP-URI as a Request-URI Ultimately, we're after this message flow: Alice PSAP [M1] INVITE (sos & location) --------------------------> [M2] 200 OK <-------------------------- [M3] ACK --------------------------> Polk Expires August 27th, 2006 [Page 4] Internet-Draft ECRIT Mapping Events Feb 2006 Media Session Established <=========================> Figure 1. Basic Message Flow Then first responders would be racing to Alice's location to help her. Unfortunately, calling a IP-enabled PSAP isn't that easy, as there are a few more components in the network that are necessary, some in certain situations, some in other situations. The rest of this section will be building the network out between Alice and her appropriate PSAP, to place this call above. We will see that Alice needs to certain configuration information, but this can be from at least two different types of sources. The general configuration server message flow will be shown in Section 3.1. We will see that these two configuration servers can communicate with a location-to-PSAP-URI mapping server, i.e. an ECRIT mapping server. Here we show a DHCP server and a SIP Registrar server. Message flows will be shown for either case in Section 3.2 We know that Alice will almost certainly require communicating with an ESRP server prior to her messages being routed to the PSAP. This message flow will be shown in Section 3.3. Finally, we will show how Alice will get her configuration information, and likely still have to communicate through a first hop proxy server prior to communicating with an ESRP, and on to the PSAP. This message flow will be shown in Section 3.4. 3. Mapping Scenarios Outlined Here we have 4 message flow scenarios with one of them having two parts. These build on each other, more or less, so if a piece isn't shown in a later scenario, assume it was covered in an earlier scenario. These are *NOT* exactly how the message flows will exist on the wires/radios between a user agent and the PSAP. This are basic models so readers can focus on where ECRIT mapping functionality can take place in a flow. 3.1 Scenario #1 - Alice Needs Configuration Data Figure 1 above showed the perfect world scenario in which Alice knew everything she needed to route her emergency call set-up to the right PSAP with the first message. That was shown with a 'wink', because everyone should know it isn't that easy. First of all, Alice's UA needs configuration information. Why do we show this seemingly mundane message flow, because ECRIT mapping can exist, or be requested here. Polk Expires August 27th, 2006 [Page 5] Internet-Draft ECRIT Mapping Events Feb 2006 Alice Configuration Server PSAP Configuration Data Request --------------------------> Configuration Data Reply <-------------------------- Call set-up (sos & location included) <----------------------------------------------------> Emergency Call Established <====================================================> Figure 2. Basic Message Flow with Config Server Included Alice, when she requests and receives her local configuration information to communicate using IP, and when she does the equivalent booting her SIP processes in the UA, can request a ECRIT mapping be done. Sections 3.2.1 and 3.2.2 show two different possibilities of this, based on the model show in Figure 2 above. 3.2 Scenario #2 - Alice Invokes Early ECRIT Mapping Here we show Alice requesting that one of her configuration servers, via a configuration protocol, invokes an ECRIT mapping procedure to provide Alice with the most current PSAP URI at the this time. Two protocols will be shown here: DHCP and SIP. Of course there are other protocols that can be used, such as an HTTP query from Alice once she has her device on-line, or another protocol, perhaps at layer 2 via an extension to either IEEE's 802.11 or TIA's LLDP-MED. 3.2.1 Scenario #2a - DHCP Requested ECRIT Mapping Figure 3a shows Alice's UA at initial boot time, sending out a DHCP DISCOVER message to learn her IP address, default gateway, subnet mask, and other basic configuration information to just communicate over IP. It is conceivable that this is the first point that an ECRIT mapping can be requested. Alice's DHCP client can send out a request to her DHCP Server to do this ECRIT mapping. This DHCP Option is documented here [ID-DHC-URI] as one of the URIs that can be requested of the DHCP Server. In fact, a secondary PSAP-URI can be requested within this same DHCP Option. That effort is still in Internet Draft form. Alice DHCP Server Registrar Mapping Server [M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc) ----------------> [M2] DHCP OFFER <---------------- [M3] DHCP REQUEST or INFORM (Location, PSAP-URI) ----------------> Polk Expires August 27th, 2006 [Page 6] Internet-Draft ECRIT Mapping Events Feb 2006 [M4] ECRIT Protocol Query (contains Location) -----------------------------------------> [M5] ECRIT Protocol Response (contains PSAP-URI) <----------------------------------------- [M6] DHCP ACK (contains location & PSAP-URI) <---------------- Emergency Call set-up initiated -----------..........------------.....--> Figure 3a. ECRIT Mapping Performed by DHCP Server Essentially, the DHCP client requests this PSAP-URI from the DHCP Server in a DHCP REQUEST or INFORM message (in message [M3]). The DHCP Server can then using the ECRIT mapping protocol to query the backend mapping server for this SIP(S)-URI (in message [M4]). This communication can be secured using whatever mechanisms are available or specified between the DHCP Server and the Mapping Server to protect the information from eavesdroppers or anyone messing with the data. This document can be used to review this fact of these models as well, but that is not the intent at this time. Upon reception of the ECRIT mapping response (in message [M5]), the DHCP server can respond to Alice's client in a DHCP ACK message (in message [M6]). At this point, Alice's UA has a PSAP SIP(S)-URI, though, unless Alice calls for help immediately, the information will be considered 'old' from the PSAP community. This does not make the information bad, just less reliable. 3.2.2 Scenario #2b - SIP REGISTER Requested ECRIT Mapping The second means of transferring configuration information to Alice's UA is during the SIP processes boot time. In SIP, this is accomplished with a SIP REGISTER Request message [RFC3261]. Included in Figure 3b is the DHCP messages, but without DHCP doing the ECRIT mapping function. It is important to understand that Alice's UA could have tried to learn this PSAP URI from DHCP, but the DHCP ACK message did not return an answer. The DHCP protocol ignores requests for Options the Server does not understand [RFC2131]. As a result, Alice's SIP processes should know this, based on its upgraded code, and requested the information at the SIP layer as a backup. Polk Expires August 27th, 2006 [Page 7] Internet-Draft ECRIT Mapping Events Feb 2006 Alice DHCP Server Registrar Mapping Server [M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc) ----------------> [M2] DHCP OFFER <---------------- [M3] DHCP REQUEST or INFORM (Location) ----------------> [M4] DHCP ACK <---------------- [M5] REGISTER (PIDF-LO) -------------------------------------> [M6] ECRIT Protocol Query (contains Location) -------------------> [M7] ECRIT Protocol Response (contains PSAP-URI) <------------------- [M8] 200 OK (PSAP URI) <------------------------------------- Emergency Call set-up initiated -----------..........------------.....--> Figure 3b. Basic Message Flow with Config Server Included After Alice's UA requests [M3] and receives location [M4] from her DHCP server, and perhaps after it doesn't receive a PSAP URI in DHCP, Figure 3b shows her UA transmitting a SIP REGISTER Request message to her Registrar server [M5] [ID-L7-MAP]. If she wants her PSAP URI, she'll need to include a PIDF-LO of her location [RFC4119], and request that the Registrar server perform an ECRIT mapping function [M6]. A positive response to this request, with PSAP-URI will be a 200 OK response message [M8]. At this point *or* just as it was true after receiving has a PSAP SIP(S)-URI though DHCP, unless Alice calls for help immediately, the information will also be considered 'old' as far as the PSAP community is concerned. This also does not make the information bad, just less reliable. NOTE - this message flow could be reduced by not including the DHCP messages if Alice's UA were manually configured with location, or location was learned from either an internal GPS measurements, or a non-IP communication such as something a cellular network or 802.11 WiFi communication. The focus of the flow in Figure 3b is on SIP requesting the PSAP URI at device registration time. UA configuration, perhaps bound by local regulation, would handle what to do if a UA were to initiate an ECRIT mapping function at Polk Expires August 27th, 2006 [Page 8] Internet-Draft ECRIT Mapping Events Feb 2006 DHCP and via a SIP REGISTER (or SUBSCRIBE) Request, and receive more than one answer, perhaps one per protocol attempted. Perhaps someone should write up a UA Device configuration document specifying what a UA needs to be able to do, at a minimum, with this and many other situations (wink). 3.3 Scenario #3 - Message Flow to PSAP without Early ECRIT Mapping Figure 4. is a bit of a step backwards, because there is no early ECRIT mapping performed, but this is the current basic ECRIT message flow model, with the liberty taken to include DHCP to learn location. Either the device requested a PSAP URI in the DHCP INFORM (in [M3]) and didn't get it in the response DHCP ACK (in [M4]), or the device did not request for early ECRIT mapping to performed. This scenario also omits using SIP REGISTER to invoke the ECRIT mapping query (all from Section 3.2). Alice DHCP ESRP Mapping Server PSAP [M1] DHCP DISCOVER (IP add, etc) ----------> [M2] DHCP OFFER <--------- [M3] DHCP REQUEST or INFORM (Location) ----------> [M4] DHCP ACK (includes location) <--------- [M5] INVITE (sos, PIDF-LO) ---------------------> [M6] ECRIT Query -----------------> [M7] ECRIT Response <----------------- [M8] INVITE (Request-URI to PSAP) --------------------------------------> [M9] 200 OK <-------------------------------------------------------------- [M10] ACK --------------------------------------------------------------> Session Established <=============================================================> Figure 4. Basic Message Flow without Early ECRIT Mapping Messages 1-4 are normal DHCP messages. [M3] includes a request for the UA's location. [M4] includes the UA's location in the DHCP ACK Polk Expires August 27th, 2006 [Page 9] Internet-Draft ECRIT Mapping Events Feb 2006 message. Message [M5] is Alice calling for emergency help. Her UA understands this is an emergency call, so it sets the Request-URI appropriately to urn:services:sos and includes the PIDF-LO either by-value in a message body or by-reference in a SIP Location header [ID-SIP-LOC]. This message is routed to an ESRP, which recognizes it as an emergency request, and invokes a ECRIT mapping query to the Emergency Mapping Server (in message [M6]). The ECRIT response is in message [M7]. The ESRP modifies the INVITE through normal SIP procedures outlined in [RFC3261], plus replaces the Request-URI field of urn:services:sos with the PSAP-URI, likely a SIPS-URI. This message retains the Location information of Alice's UA. [M9] and [M10] compete this simplistic call set-up and the emergency call is established between Alice and the PSAP. A choice in this message flow that has not been discussed, but can be brought up here, is whether or not the ESRP will become dialog stateful in this call? If so, a Record-Route header is inserted in [M8], and [M9] is destined for the ESRP, which sends the 200 OK to Alice in a different [M10]. Her ACK would not be until [M11], and it will go to the ESRP, which will pass this message along in a new [M12]. 4. Can Failures of the ECRIT Mapping Function Fail Call Attempts Given the scenarios outlined in Section 3.3, and reviewing the scenarios in Section 3.2 (other imagining others not shown, but like DHCP and SIP, but with other mechanisms or protocols involved), it appears prudent to discuss what to do if there is an ECRIT mapping failure here: Alice DHCP ESRP Mapping Server PSAP [M1] DHCP DISCOVER (IP add, etc) ----------> [M2] DHCP OFFER <--------- [M3] DHCP REQUEST or INFORM (Location) ----------> [M4] DHCP ACK (includes location) <--------- [M5] INVITE (sos, PIDF-LO) ---------------------> [M6] ECRIT Query -----------------> [M7] ECRIT Response FAILS <----------------- ? Polk Expires August 27th, 2006 [Page 10] Internet-Draft ECRIT Mapping Events Feb 2006 Figure 6. ECRIT Mapping Failure During Call Establishment What happens if an ESRP receives a failure indication in message [M7]? Or if it doesn't receive any reply, regardless of the number of retries? What happens to this emergency call if there has not been an early ECRIT mapping function performed? Would this be the next message in the flow above? Alice DHCP ESRP Mapping Server PSAP [M1] DHCP DISCOVER (IP add, etc) ----------> [M2] DHCP OFFER <--------- [M3] DHCP REQUEST or INFORM (Option 123, URI Option) ----------> [M4] DHCP ACK <--------- [M5] INVITE (sos, PIDF-LO) ---------------------> [M6] ECRIT Protocol -----------------> [M7] Map Failure <----------------- [M8] 4XX (New Mapping Failure) <----------------------- [M9] ACK ---------------------> Figure 7. ECRIT Mapping Failure During Call Establishment If Alice's UA received this new 4XX Mapping Failure response, how would it react? 4.1 Reactive ECRIT Mapping Function After Failure It appears likely that in order to get to a PSAP, Alice will need to traverse a ESRP somewhere. Current thinking is that the PSAP will not trust any request it receives unless it receives it from a trusted ESRP. This document does not hope to define that trust relationship establishment. But this would likely go a long way towards DOS attacks to a raw/direct PSAP-URI. With this thinking in mind, this likely cannot be the subsequent message flow to Figures 6 and 7: Polk Expires August 27th, 2006 [Page 11] Internet-Draft ECRIT Mapping Events Feb 2006 Alice DHCP ESRP Mapping Server PSAP [M1] DHCP DISCOVER (IP add, etc) ----------> [M2] DHCP OFFER <--------- [M3] DHCP REQUEST or INFORM (Location) ----------> [M4] DHCP ACK <--------- [M5] INVITE (sos, PIDF-LO) ---------------------> [M6] ECRIT Protocol -----------------> [M7] Map Failure <----------------- [M8] 4XX (New Mapping Failure) <----------------------- [M9] ACK ---------------------> [M10] DHCP REQUEST or INFORM (Location, URI) ----------> [M11] ECRIT Protocol Query (contains Location) ------------------------------> [M12] ECRIT Protocol Response (contains PSAP-URI) ------------------------------> [M13] DHCP ACK <--------- [M14] INVITE (Request-URI of DHCP learned PSAP URI) --------------------------------------------------------------> [M15] 200 OK (after PSAP questions if this is an attack because this message didn't come from an ESRP) <------------------------------------------------------------- [M16] ACK --------------------------------------------------------------> Session Established <=============================================================> Figure 8. Reactive Mapping Failure and Recovery Messages 1-9 are identical to Figure 7. Figure 8 shows that Alice's UA, upon receiving the new 4XX (Mapping Failure) response message querying for a fallback ECRIT mapping function. Message 10-13 are identical from those shown in Section 3.2. Another protocol could have been used here, such as SIP REGISTER (Section 3.2) for Polk Expires August 27th, 2006 [Page 12] Internet-Draft ECRIT Mapping Events Feb 2006 instance. The point is that in this case, Alice waits for a failure to make her own query to a server that can make an ECRIT Mapping query for her. Perhaps she can do this ECRIT query on her own, but why wouldn't she have done this already? This scenario in Figure 8 appears to be a inefficient, and prone to failure for the reason stated above, the PSAP will likely treat any inbound request with a high degree of skepticism if it does not come from an ESRP (which failed its ECRIT map). 4.2 ESRP Reacts ECRIT Mapping Failure It appears that a more successful scenario is shown in Figure 9, in which Alice's UA request for an early ECRIT mapping be done (in message [M3]), here showing via DHCP, but it could be any protocol with this functionality. The key to this message flow verses previous flows, and the one that bring the whole idea of early ECRIT mapping together in case of a mapping failure at the ESRP, is that the ESRP has the fallback map in the SIP INVITE. It doesn't have to generate a new failure message to Alice's UA to have her react to this event. Her UA has already accounted for this as a possibility. Message [M7] contains the early ECRIT mapping in a loose route header, to be used in case the ESRP mapping fails. Alice DHCP ESRP Mapping Server PSAP [M1] DHCP DISCOVER (IP add, etc) ----------> [M2] DHCP OFFER <--------- [M3] DHCP REQUEST or INFORM (Location, URI) ----------> [M4] ECRIT Protocol Query (contains Location) ------------------------------> [M5] ECRIT Protocol Response (contains PSAP-URI) ------------------------------> [M6] DHCP ACK <--------- [M7] INVITE (sos, PIDF-LO & early Mapping URI) ---------------------> [M6] ECRIT Protocol -----------------> [M7] Map Failure <----------------- [M8] INVITE (fallback of Route header) --------------------------------------> Polk Expires August 27th, 2006 [Page 13] Internet-Draft ECRIT Mapping Events Feb 2006 [M9] 200 OK <-------------------------------------------------------------- [M10] ACK --------------------------------------------------------------> Session Established <=============================================================> Figure 9. ECRIT Mapping Failure and Recovery During Call Establishment Once message [M7 returns with a mapping failure indication, or doesn't return any indication (a timeout condition), the ESRP will use what's in the SIP Route header and route message based on that header field. The ESRP may choose to remove the Route header and place header field contents with in the INVITE's Request-URI. This would remove downstream elements from any point of confusion, even though standard practice in SIP is to route based on the contents of the top entry in the (loose) Route header. This document does not make that recommendation, as that ought to be addressed elsewhere. 5. IANA Considerations This document makes no request of the IANA. Note to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC. 6. Security Considerations This document outlines message flows and has no normative text. The only normative reference is to the ECRIT WG Requirements ID. Other documents with normative text defining the ECRIT mapping protocol, as well as DHCP and SIP address how those protocols needs to address the security considerations. 7. Acknowledgements Your name here 8. References 8.1 Normative References [ID-ECRIT-REQS] H. Schulzrinne, R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-04.txt, "work in progress", January 2006 Polk Expires August 27th, 2006 [Page 14] Internet-Draft ECRIT Mapping Events Feb 2006 8.2 Informative References [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", draft-ietf-geopriv-dhcp-civil-09, "work in progress", January 2006 [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-00, "work in progress", January 2006 [ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers", draft-polk-dhc-uri-02.txt, "work in progress", October 2005 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-01.txt, "work in progress", June 2005 [ID-L7-MAP] J. Polk, " ECRIT Mapping During Session Initiation Protocol Registration", draft-polk-ecrit-mapping-during-registration-00, "work in progress", February 2006 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com Polk Expires August 27th, 2006 [Page 15] Internet-Draft ECRIT Mapping Events Feb 2006 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 (2006). 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. Polk Expires August 27th, 2006 [Page 16]