ECRIT Working Group James Polk Internet-Draft Cisco Systems Expires: Aug 27th, 2006 Feb 27th, 2006 Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring draft-polk-ecrit-emergency-dialstring-00 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 Most efforts to address emergency calling challenges over IP (and cellular technologies such as GSM, TDMA, CDMA, etc, for that matter) have focused on locating the calling user in order to route the emergency call set-up request to the appropriate Public Safety Answering Point (PSAP). Little or no effort to date has focused on informing the caller what dialstring sequence they may need to use to initiate a call for emergency help. This document describes how the Session Initiation Protocol (SIP) REGISTER Request message is used to inform a user of which emergency dialstring (of the 60 known dialstring choices around the world) they should use, for where they are geographically. Polk Expires August 27th, 2006 [Page 1] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. SIP Options to Provide Dialstring . . . . . . . . . . . . . . 3 3. Requirements on Transaction to Learn Dialstring . . . . . . . 4 4. Basic Assumptions About Location . . . . . . . . . . . . . . 5 5. Transaction Overview . . . . . . . . . . . . . . . . . . . . 6 6. Option #1 - SIP REGISTER with a Header . . . . . . . . . . . 6 6.1 New Emergency-Dialstring Header in SIP . . . . . . . . . . 6 6.2 Usage of Emergency-Dialstring Header Fields . . . . . . . . 7 6.3 Emergency Dialstring Option Tag . . . . . . . . . . . . . . 7 6.4 SIP Element Rules . . . . . . . . . . . . . . . . . . . . . 7 7. Option #2 - SIP REGISTER with a new event package . . . . . . 11 8. Option #3 - UA Performs a HTTP Query to a Remote Server . . . 11 9. Option #4 - SIP SUBSCRIBE With a New Event Packet . . . . . . 11 10. Examples of All Four Options . . . . . . . . . . . . . . . . 12 10.1 Example of Emergency-Dialstring Header Transaction . . . . 12 10.2 Example of SIP REGISTER Event Package Transaction . . . . 15 10.3 Example of HTTP Transaction . . . . . . . . . . . . . . . 15 10.4 Example of SIP SUBSCRIBE Event Package Transaction . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 14.1 Normative References . . . . . . . . . . . . . . . . . . 16 14.2 Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 17 1. Introduction [ID-SOS] describes a universal emergency call URN to be used to identify a call as an emergency call. This URN is not intended to be dialed, but rather is to be used by the User Agent as an address. The intention is to translate (as with any other dial plan) the existing emergency dialstring to the universal URN. In many countries, short codes are used as emergency dialstrings to identify emergency calls. In others, a complete local telephone number is needed. These dialstrings are locally specific, typically by country, and may vary in length. In some countries, a single dialstring is used ('999' is the dialstring for all emergency calls in the United Kingdom). In other countries, there are different dialstrings for different emergency services; '116' is the dialstring for police in Switzerland, '117' is the dialstring for fire. Users are taught, often from a very early age, what the local Polk Expires August 27th, 2006 [Page 2] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 dialstrings for emergency calls are, and it is not practical to attempt to change the dialstring to a more uniform choice. When using systems that permit roaming, local laws often require that telephony systems recognize the local ("visited") emergency dialstrings. What is needed is a mechanism for a User Agent (or other device that can place emergency calls) to learn the local emergency dialstring(s) so that it can recognize an emergency call when that numeric sequence is dialed by the user. This visited emergency dialstring(s) may be displayed to the user in its screen when learned, if the phone has that capability. 1.1 Conventions used in this document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and indicate requirement levels for compliant implementations. 2. SIP Options to Provide Dialstring Fundamentally, there are 3 pieces of information specified in this document to be requested, and responded with: - an emergency dialstring, - a Service Identifier - a Country Code The need for the emergency dialstring is self evident. The reason for the Service Identifier, mentioned in [ID-SOS] and [ID-DHC-DIAL], is to identify what type of emergency dialstring this one is. Is this dialstring for police or fire or mountain-rescue? In countries that have these choices, this is really important to keep the existing functionality. The reason for the Country Code is two-fold. First, it matches the Service ID with the dialstring. In other words, having a Country Code for of 'US', and a Service ID of 'police' wouldn't make sense yet, because the US does not have this granularity. Secondly, this is a means of requesting the Country Code when location is in a Geo (Lat/Lon) format. There are four options given here on how to get an emergency dialstring to a SIP user agent: Polk Expires August 27th, 2006 [Page 3] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 Option #1 - SIP REGISTER with a header in the request Option #2 - SIP REGISTER with a new event package Option #3 - UA performs a HTTP Query to a remote server Option #4 - SIP SUBSCRIBE with a new event packet The advantages of placing this function in a SIP REGISTER message is that in travels with the device configuration. Meaning the UA would learn of this information at boot time, with appropriate indicators to tell the UA when the Registrar can and cannot perform this task. Using a new event package creates more flexibility in what information can be provided lateral to the dialstring, for example what the dialstring 116 is for in Switzerland. This would require two additional pieces of information: a ISO-3166 country code, and a type of use field to indicate what exactly this dialstring is used for. Most locations would have a single general purpose dialstring, but others would want to use at least the different offerings they have now. An event package also has the advantage of including more than one dialstring while listing each unique type of use. Constructing a dialstring request and response, to return at least these 3 pieces of information in a SIP header is challenging and not very flexible. It would be especially difficult, it appears, to have multiple dialstrings returned in the same header in the successful response to a REGISTER message. Creating this capability in HTTP should be fairly straight forward, but there have been some issues raised lately that not all HTTP implementations are created equal, and this would force HTTP onto every UA that wanted this capability, which may not be the case, and may not be desired. Here we talk about an HTTP server being any server running HTTP, and not a necessarily (any or all) traditional Web-server(s). It is possible that the same, or a similar, event package could be used in a SIP SUBSCRIBE message as is suggested above for a REGISTER message. 3. Requirements on Transaction to Learn Dialstring The following are the requirements necessary for a UA to learn its emergency dialstring in its registration transaction: Req#1 - A (SIP or HTTP) user agent MUST be able to indicate it requires an emergency dialstring during a transaction with a remote entity. Polk Expires August 27th, 2006 [Page 4] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 Req#2 - A (SIP or HTTP) user agent MUST be able to indicate it requires an ISO country code during a transaction with a remote entity. Req#3 - A (SIP or HTTP) user agent SHOULD be able to indicate which type of emergency dialstring it is seeking during a transaction with a remote entity (i.e. only police or fire). Req#4 - A (SIP or HTTP) user agent SHOULD be able to indicate more than one type of emergency dialstring it is seeking during a transaction with a remote entity (i.e. to a general request, respond with all that apply in that location/country). Req#5 - A server node (SIP Registrar Server or server running HTTP) MUST recognize a request for an emergency dialstring from the UA, then process and determine the emergency dialstring for the UA based on a well-formed PIDF-LO by-value or by- reference within the REGISTER Request message. Req#6 - A server node (SIP Registrar or HTTP Server) MUST be able to return the emergency dialstring, service ID, and country code to a registering (SIP or HTTP) user agent during the response part of the transaction. Req#7 - A server node (SIP Registrar or HTTP Server) MUST be able to respond with just a country code in the response of a transaction with the user agent. Req#8 - A server node (SIP Registrar or HTTP Server) MUST respond with which type of service indication the emergency dialstring is in the transaction response to the user agent. Req#9 - A (SIP or HTTP) user agent MUST be able to include more than one type of emergency dialstring in the response of a transaction with the user agent. Req#10 - A user agent MUST be able to request and update existing information at any time the device can contact the server. 4. Basic Assumptions About Location One basic assumption has to be made here: the UA knows its location, either by-value or by-reference. Without this knowledge, any request for the appropriate emergency dialstring would yield a known to be valid answer, because there is such a list to choose from. This document does not discuss how the UA was sent, retrieved or knows its location; just that it has to know where it is, at least at a country level, in order to expect a server to plausibly be able to answer this request for information. This document makes no assumptions nor dictates how a server Polk Expires August 27th, 2006 [Page 5] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 determines which dialstring or dialstrings to return to the SIP or HTTP UA from this request. 5. Transaction Overview Here is the basic message flow of this transaction, regardless of which option is chosen: Here Alice is registering to a (SIP or HTTP) server. Alice SIP or HTTP Server [M1] Request ------------------------> [M2] Response <------------------------ From a "where in the request is the request indication for the dialstring/service-ID/country-code"? It does not matter from a messaging point of view. The request indication could be in a Header or a new event package message body. The event package could be different for what goes in a SIP REGISTER and SUBSCRIBE Request, the transaction looks the same. It also looks similar to an HTTP transaction, even it the message body is different. The key facet of the request is two-fold: - That the message contains location by-value or by-reference, and - That the message requests what it seeks This message MAY be a device boot time in each of these messages, or it MAY be after device boot time with any of these messages. 6. Option #1 - SIP REGISTER with a Header 6.1 New Emergency-Dialstring Header in SIP Communicating the emergency dialstring in a request or response can be accomplished with a new header. The Emergency-dialstring header would have the following syntax (The "token-nodot" production is copied from [RFC3265]): Emergency-dialstring = "Emergency-dialstring " HCOLON Emergency-dialstring-value *(COMMA Emergency-dialstring-value) Emergency-dialstring-value = (numeric-string "." service-identifier / option-tag) numeric string = numeric-token service-identifier = token-nodot Polk Expires August 27th, 2006 [Page 6] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) option-tag = string NOTE: we aren't sure this BNF is correct. The goal is to get this Result as a Request: Emergency-Dialstring: , And this result in a Response (the example here is for the US): Emergency-Dialstring: <911.psap; country-code=us> 6.2 Usage of Emergency-Dialstring Header Fields The following table extends the values in Tables 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Emergency-dialstring Rr o - - - o o - Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Emergency-dialstring Rr o o o o - o - This header is opaque to proxy servers. It has optional usage in the INV [RFC3261], REG [RFC3261], OPT [RFC3261], SUB/NOT [RFC3265], UPD [RFC3311], INF [RFC2976] and MSG [RC3428] - all these are discussed in Section 8. 6.3 Emergency Dialstring Option Tag This document creates a new option tag "emergency-dialstring" to be used in Requires, Supported and Unsupported headers in SIP between compliant SIP elements of this extension. At this time, the authors do not see any need for this option tag to be placed in the Proxy-Requires header, as this extension should be opaque to proxies and merely propagated by B2BUAs. The IANA registration of this option tag is in Section 11. 6.4 SIP Element Rules Here are the behaviors of the relevant SIP elements within this operation. This SIP extension is opaque to SIP Proxies, SHOULD be copied unchanged from receiving request to transmitted request by B2BUAs and SBCs. Polk Expires August 27th, 2006 [Page 7] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 6.4.1 UAC Behavior with Emergency-Dialstring Header Option A UAC wanting an appropriate emergency dialstring be returned during registration process will do the following: - The UAC SHOULD include emergency-dialstring Option-tag in a Requires header, but MAY include option-tag in Supported header to prevent initial 420 if Registrar doesn't understand this extension. - The UAC MUST include location in the REGISTER Request message, by-value is RECOMMENDED, but MAY send location by-reference in Location header [ID-SIP-LOC]. - The UAC SHOULD include a Location header in the request, with a cid indication of where location is in the message body, even if there is only one message body part. - If the UAC has its location by-reference URI, it MUST include this in the Location header of the REGISTER request, unless location by-value is included. Both MUST NOT be included in the same message. - A UAC requesting an emergency dialstring MUST expect to receive a server identifier and country code in the response. - The UAC SHOULD use S/MIME to protect the PIDF-LO for e2e confidentiality. - The UAC MUST use TLS or IPSec for hop-by-hop confidentiality. - Upon reception of the emergency dialstring, it is RECOMMENDED the UAC display this dialstring on its screen for the user to see and read. This display may be "on" continuously, or may fade after some preconfigured period of time. - A UAC MAY request this emergency dialstring with every REGISTER Request, include a refresh, to ensure it has the freshest information. - There may be more than one valid emergency dialstring for where the UAC is at the moment. The UAC MUST be prepared to receive more than one dialstring in the Emergency-dialstring header. - Each emergency dialstring returned from the Registrar SHOULD augment, be included, in the UAC's digit-map as recognizable as an emergency dialstring sequence for the user to use. For example, a UAC from somewhere in Europe that travels to Switzerland may already know that 112 is a valid emergency dialstring. But through this extension, the UAC may learn that 116 Polk Expires August 27th, 2006 [Page 8] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 (police) and 117 (fire) are also valid in this jurisdiction. 6.4.2 Server Behavior with Emergency-Dialstring Header Option A Registrar server understanding the concept of emergency dialstrings will do the following: - The Registrar MUST understand Emergency-Dialstring header and emergency-dialstring option-tag in a Supported or Requires header. - If the Registrar does not understand the emergency-dialstring option-tag in a Requires header, the Registrar MUST reject the message with a 420 (Bad Extension) Response, including the emergency-dialstring option-tag in an Unsupported header. - A Registrar MUST respond to an OPTIONS request with emergency-dialstring option-tag in a Supported header with the emergency-dialstring option-tag in an Unsupported header. - Having understood the request to generate an emergency-dialstring, the Registrar MUST look for location within the Request message to determine where the UAC is geographically, or contact another server, perhaps using another protocol, that can do this operation. - The Registrar MUST look for the Location header in the Request message to indicate a location by-reference URI, or a cid value of where the location message body part is in the overall message body [ID-SIP-LOC]. - The Registrar MUST understand location by-reference, per [ID-SIP-LOC] and fetch the PIDF-LO from remote server to determine location of the UAC. - The Registrar MUST understand the content-type application/pidf+xml to properly parse the PIDF-LO fetched or from the by-value message body . - The Registrar MUST understand all 3 parts of the emergency dialstring header. - the Registrar MUST allow for the request of only the ISO country code, but MAY respond with the emergency dialstring and service identifier in the response. - a request for an emergency dialstring MUST include a service identifier in the response, with the default value being 'psap'. - If more than one emergency dialstring is used or appropriate within the UAC's current location, more than one dialstring MUST be returned in the Emergency-dialstring header, separated by a ',' Polk Expires August 27th, 2006 [Page 9] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 (comma), with each dialstring partnered with the respective service identifier - The Registrar MUST use TLS for hop-by-hop Confidentiality of these Transactions; IPSec usage is optional. - The Registrar MUST adhere to the location retention and distribution rules set in the PIDF-LO [RFC4119]. 6.4.3 Error Conditions with Emergency-Dialstring Header Option 6.4.3.1 UAC Error Conditions A user agent client, having included an Emergency-Dialstring indication in a request message, receives an error response, will do the following: - If the UAC receives a 420 (Bad Extension), if it placed the emergency-dialstring option tag in a Requires header, SHOULD resend the REGISTER request, but place the emergency-dialstring option tag in a Supported header. - If the UAC sent a REGISTER with an emergency-dialstring option tag in a Requires header, and receives a 503 (Service Unavailable) from the Registrar with an emergency-dialstring option tag in a Supported header, it knows the Registrar understood the request, but could not complete dialstring request. The UAC SHOULD retry registration with the emergency-dialstring option tag in a Supported header. - If the UAC receives a 415 (Unsupported Media type) from a Registrar to the content-type application/pidf+xml, the UAC SHOULD NOT attempt to send a PIDF-LO again to the Registrar, meaning the UAC cannot ask for its emergency-dialstring from that SIP element. 6.4.3.2 Registrar Error Conditions to Header A Registrar server understanding the concept of emergency dialstrings will do the following: - If the Registrar does not understand the emergency-dialstring option tag in a Requires header, the proper response is a 420 (Bad Extension), including emergency-dialstring option tag in an Unsupported header - If the Registrar does not understand the emergency-dialstring option tag in a Supported header, the proper response is to convey a lack of support for the option tag by including this in the Unsupported header in the response message Polk Expires August 27th, 2006 [Page 10] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 - If the Registrar does not understand the content-type application/pidf+xml, the proper error response is a 415 (Unsupported Media type) - an Unsupported header MUST be in the 415, which includes this option tag - If a Registrar server understands the concept of emergency dialstrings, and receives a request for an emergency dialstring from a UAC during registration in a Requires header, but for whatever reason cannot complete this part of the transaction, the server MUST return a 503 (Service Unavailable) response to the UAC. The Registrar MUST include the emergency-dialstring option tag in a Supported header to indicate this part of the request was understood, but could not be performed at this time. 7. Option #2 - SIP REGISTER with a new event package The creation of a new SIP REGISTER event package to request and respond for a emergency-dialstring, service identifier and/or ISO country-code in a request or response can be accomplished ... This section to be completed soon [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] 8. Option #3 - UA Performs a HTTP Query to a Remote Server The creation of a new HTTP Query to request and respond for a emergency-dialstring, service identifier and/or ISO country-code in a request or response can be accomplished ... This section to be completed soon [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] 9. Option #4 - SIP SUBSCRIBE With a New Event Packet The creation of a new SIP SUBSCRIBE event package to request and respond for a emergency-dialstring, service identifier and/or ISO country-code in a request or response can be accomplished ... This section to be completed soon [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] Polk Expires August 27th, 2006 [Page 11] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 10. Examples of All Four Options This section illustrates only one of the four options at this time. As soon as the event packages are completed in XML, they will be incorporated into the text here. However, if any of these options are not considered appropriate by the community, they will be dropped like a burning pan you didn't realize was hot before you picked it up. Thank you for your patience... 10.1 Example of Emergency-Dialstring Header Transaction Here is Alice's modified registration transaction. Alice Registrar Server [M1] REGISTER (with PIDF-LO, and Requires plus Emergency-Dialstring headers) ------------------------> [M2] 200 OK (with emergency-dialstring header) <------------------------ The following message are *not* well-formed. [Message 1 - REGISTER from Alice to Registrar Server] REGISTER registrar-server@example.com SIP/2.0 Via: Alice To: Alice From Alice Emergency-Dialstring: Requires: emergency-dialstring Location: cid Call-ID: 1 Content-type: application/pidf+xml Content-Length: ... cid [PIDF-LO message body (not shown)] [Message 2 - 200 OK from Registrar Server to Alice] SIP/2.0 200 OK Via: Alice To: Alice From Alice Emergency-Dialstring: <911.psap; country-code=us> Supported: emergency-dialstring Polk Expires August 27th, 2006 [Page 12] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 Call-ID: 1 Content-Length: 0 Location is sent to the Registrar in the form of the [RFC 4119] PIDF-LO message body in the above example. The Registrar is the destination UAS of this message, so it can read all that is in the message, even if encrypted. If the PIDF-LO is in a civic format, the Registrar can easily read the country and state/province the UA is in, and perhaps have its own mapping application/database of country-to-dialstring process, perhaps this is farmed out to another server. This will likely have to be sent to a back-end server if the location in the PIDF-LO is in a coordinate format, as the Registrar server shouldn't get bogged down in doing a coordinate-to- dialstring mapping function, but it is possible. This mapping function to a backend server, from the SIP Registrar's point of view, should be independent of the ECRIT Mapping Protocol, since that protocol's function is to return a PSAP URI from a given PIDF-LO, but that protocol may evolve into including this function down the road. Here is a series of Emergency-Dialstring examples in Requests, with their appropriate Response headers: #1 - UA requests emergency-dialstring and (ISO) country-code within the US: In the SIP Request Message Emergency-Dialstring: In the SIP Response Message Emergency-Dialstring: <911.psap; country-code=us> #2 - UA requests (ISO) country-code only within France: In the SIP Request Message Emergency-Dialstring: <0.0; country-code=country> In the SIP Response Message Emergency-Dialstring: <0.0; country-code=fr> #3 - UA requests only the police emergency-dialstring, service identifier and (ISO) country-code within Switzerland: In the SIP Request Message Emergency-Dialstring: In the SIP Response Message Emergency-Dialstring: <116.police; country-code=ch> #4 - UA requests for the police and fire emergency-dialstrings, Polk Expires August 27th, 2006 [Page 13] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 service Identifiers and (ISO) country-code within Switzerland: In the SIP Request Message Emergency-Dialstring: In the SIP Response Message Emergency-Dialstring: <116.police; country-code=ch>, <117.fire; country-code=ch> Which can also be returned like this (to be consistent with [RFC3261]): Emergency-Dialstring: <116.police; country-code=ch> Emergency-Dialstring: <117.fire; country-code=ch> Where there is no limit to the number of headers in the response. An advantage of using the REGISTER method to learn a dialstring is that the Registrar server can be anywhere in the world, and can successfully answer the request for a dialstring, as long as the Registrar can map the location of the user agent to a country's emergency dialstring. This can be done internally within the Registrar server, or through the ECRIT mapping protocol. This is all at layer 7 with no direct interaction with the underlying infrastructure. This mechanism is also independent of which access and internet service provider is giving the user agent its connectivity. Section 6 showed the creation of a new SIP header to convey emergency dialstring to the UAC from a Registrar Server. The authors are not picky for this string, and offers these alternatives in their header form: EMTEL: <911.psap; country-code=us> or EmTel-dialstring: <911.psap; country-code=us> or Emergency-dialstring: <112.psap; country-code=fr> or P-Emergency-dialstring: <999.psap; country-code=uk> The header value MUST limit the string to all numeric characters, as that is what is on a typical phone's keypad. Whenever an emergency dialstring is learned, or updated/modified, it may be only temporarily displayed on the phone, or could remain on the display whenever the phone is powered up. This document makes no distinction as to the future use of this timing. Polk Expires August 27th, 2006 [Page 14] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 10.2 Example of SIP REGISTER Event Package Transaction To be completed... 10.3 Example of HTTP Transaction To be completed... 10.4 Example of SIP SUBSCRIBE Event Package Transaction To be completed... 11. IANA Considerations This document will make IANA Registrations when one of the four options to these requirements has been decided upon. 12. Security Considerations A concern with this extension (in its current form) is making sure the header field is not changed in transit between the Registrar server and the UAC, as this could start a chain of events to occur that will have a user dial the wrong emergency number during an emergency. Therefore, message integrity is necessary. Normal SIP mechanisms, such as using TLS or IPSec for message transmissions, should suffice. Message body confidentiality needs to be used to protect the PIDF-LO message body to adhere to location information retention and distribution rules. Normal SIP mechanisms, such as using TLS or IPSec for message transmissions, as well as S/MIME encryption of the message body, should suffice. Learning a country's, or UAC's pertinent emergency dialstring could reveal which country the user is in, but this will likely only get coarse granularity to a set of countries or a continent (112 for all of Europe, for instance). Proper security mechanisms mentioned above will prevent any of this from revelation during transmissions. 13. Acknowledgements To Brian Rosen for helping scope this effort by contributing to the Intro section. To Marc Linsner for back this effort. Polk Expires August 27th, 2006 [Page 15] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006 14. References 14.1 Normative References [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-00, "work in progress", January 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft- ietf-sip-location-conveyance-01.txt, "work in progress", June 2005 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 14.2 Informative References [ID-DHC-DIAL] J. Polk, "A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring", draft-polk-dhc-emergency-dialstring-option-00, "work in progress", February 2006 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC 3428, December 2002 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com Polk Expires August 27th, 2006 [Page 16] Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 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 17]