idnits 2.17.00 (12 Aug 2021) /tmp/idnits55835/draft-winterbottom-ecrit-direct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 583 has weird spacing: '...ects in emerg...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 19, 2009) is 4596 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 477, but not defined == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-geopriv-held-identity-extensions has been published as RFC 6155 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 == Outdated reference: A later version (-03) exists of draft-schulzrinne-ecrit-psap-callback-00 ** Downref: Normative reference to an Informational draft: draft-schulzrinne-ecrit-psap-callback (ref. 'I-D.schulzrinne-ecrit-psap-callback') == Outdated reference: A later version (-04) exists of draft-thomson-geopriv-res-gw-lis-discovery-02 ** Downref: Normative reference to an Informational draft: draft-thomson-geopriv-res-gw-lis-discovery (ref. 'I-D.thomson-geopriv-res-gw-lis-discovery') == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-ecrit-lost-servicelistboundary has been published as RFC 6197 == Outdated reference: A later version (-11) exists of draft-patel-ecrit-sos-parameter-06 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: BCP Andrew Corporation 5 Expires: April 22, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 H. Schulzrinne 8 Columbia University 9 October 19, 2009 11 ECRIT Direct Emergency Calling 12 draft-winterbottom-ecrit-direct-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document describes a generic emergency calling client. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. The Jurisdictional Problem . . . . . . . . . . . . . . . . . . 5 57 4. Network Reference model . . . . . . . . . . . . . . . . . . . 6 58 5. ESRP Route Determination . . . . . . . . . . . . . . . . . . . 7 59 6. Emergency Client Registration . . . . . . . . . . . . . . . . 8 60 7. Emergency Client Call Intitiation . . . . . . . . . . . . . . 12 61 8. Call Termination Control . . . . . . . . . . . . . . . . . . . 13 62 9. SIP Feature Restrictions . . . . . . . . . . . . . . . . . . . 14 63 10. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 10.1. Test Registration . . . . . . . . . . . . . . . . . . . . 15 65 10.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 11. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . . . 16 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 72 15.2. Informative References . . . . . . . . . . . . . . . . . 21 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 75 1. Introduction 77 The current IETF ECRIT architecture, as described in 78 [I-D.ietf-ecrit-phonebcp] and in [I-D.ietf-ecrit-framework], focuses 79 on devices where emergency calls are routed primarily through the 80 subscriber's home VSP and the direct signaling communication between 81 the end host and the PSAP that contains the IP-based PSAP is only an 82 exception. This is a convenient assumption if one considers the 83 regular communication patterns of the device and the potential 84 proprietary protocol implementations used between the end host and 85 the VSP and the ability to move the interoperability challenges away 86 from the end device and closer to VSPs. There are, however, 87 challenges for regulators to enforce emergency services functionality 88 when the VSP is located in a different jurisdiction with the current 89 model. Inclusion of a VSP introduces unnecessary elements into the 90 emergency call path making the overall solution more cumbersome. 92 This document describes the regulatory challenge and illustrates a 93 model for direct communication between the end host and the PSAP that 94 is supported by the basic SIP communication patterns. With the help 95 of the Location-to-Service Translation protocol a PSAP URI is 96 discovered that allows the end device to directly send SIP 97 communication requests towards the PSAP. 99 Note that the information returned by LoST may not necessarily be the 100 address of the PSAP itself but might rather be an entity that gets 101 the emergency call closer to the PSAP by returning the address of an 102 Emergency Services Routing Proxy (ESRP). 104 This memo attempts to address the issues raised above and describe 105 the requirements, procedures and operations necessary for a generic 106 IP emergency calling client. The intent of this client is that it 107 will be able to use the available ECRIT building blocks to allow any 108 IP enabled device with access to the Internet to make an emergency 109 call without requiring a voice service subscription. Further more, a 110 means for call-back in the event of a dropped call is also described. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. The Jurisdictional Problem 120 The jurisdictional problem is illustrated with Figure 1 that 121 highlights that providing the data in the Location Information Server 122 (LIS) and the LoST server are correct, that the caller and the PSAP 123 are assured of being in the same regulatory jurisdiction. This is 124 important, because it shows that it is the access component of the 125 network and not the service component against which reguatory 126 obligations can be imposed with any hope of enforcement. Regulation 127 without the possibility of enforcement is challenging as there is 128 very little coordination between regulators world wide in this area, 129 consequently any emergency calling procedure should ensure that all 130 nodes against which the procedures apply fall within the same 131 regulatory boundary. 133 +-----+ 134 | VSP | 135 | # | 136 +-----+ 138 o-------------o----------------------o-------------o 139 / \ 140 / +---------+ +--------+ \ 141 / | Access \ ASSURED / ESINet \ \ 142 o | Network \ / \ o 143 | + + COMMON + O + | 144 | / O | / | NAT | --->: ISP :----->| ESRP | 167 +--------+ +----------+ ; ; +------+ 168 `, ,', ,' 169 { } { } 170 ```` ```` 172 Figure 2: Network Configuration 174 5. ESRP Route Determination 176 The ESRP is discovered by the emergency client obtaing its location 177 from a LIS, for example, using HELD, and then using LoST to resolve 178 the location and 'urn:services.sos' Service URN to the ESRP URI. 180 When the emergency client is started the device needs to perform LIS 181 and LoST server discovery, as described in Section 7 of 182 [I-D.ietf-ecrit-phonebcp]. 184 The emergency client MUST support location acquisition and the LCPs 185 described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The 186 description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] 187 regarding the interaction between the device and the LIS applies to 188 this document. 190 The emergency client MUST use LoST [RFC5222] to obtain an ESRP URI. 191 The exact timing of individual LoST lookups may vary based on a 192 number of factors, including the design of the user interface. For 193 example, a hypothetical user interface may offer an emergency call 194 button that triggers a interaction to learn 195 about the available emergency services (potentially using the 196 serviceListBoundary extension defined in 197 [I-D.ietf-ecrit-lost-servicelistboundary]). The service options may 198 be presented to the emergency caller in a graphical fashion and once 199 a specific service is selected a LoST query would be initiated 200 (unless a cached mapping is available that makes this request 201 obsolete). The LoST query to obtain the ESRP URI for 202 the selected service is in this example initiated at the time the 203 emergency call setup is performed. It is recommended that ESRP 204 discovery occurs at call time. 206 6. Emergency Client Registration 208 Emergency registration is only necessary when an emergency call 209 procedure is initiated. Immediately prior to making an emergency 210 call, the emergency client performs a SIP emergency registration with 211 the registrar in the ESRP, the ESRP-registrar. The emergency 212 registration is a SIP registration with specific options and headers 213 which are required in order to guard the emergency network and ensure 214 callback should it be required. 216 Each emergency client MUST provide an instance-id, as defined in 217 [I-D.ietf-sip-outbound], this allows the ESRP-registrar to generate a 218 GRUU [I-D.ietf-sip-gruu] that can be used as a callback identifier. 219 A GRUU is necessary as the callback identifier because the emergency 220 client does not provide a longer-term contact address to the ESRP- 221 registrar prior to registration, and the GRUU provides a handle by 222 which the PSAP can identify the calling emergency client. To 223 simplify the emergency client and ESRP-registrar implementations, 224 only public GRUUs are provided by the ESRP-registrar. The public 225 GRUU is guaranteed to be the same for a device regardless of re- 226 registration with a different call-id, which may occur if the device 227 unexpectedly reboots. This is not true for temporary GRUUs, which 228 makes temporary GRUUs undesriable in the scope of this application 229 space. 231 The PSAP is able to define and mandate the time over which callback 232 is possible. This needs to be a reasonable period of time, nominally 233 10s of minutes, as the device may well be transient with regards to 234 network attachment. The ESRP-registrar reflects the regulatory 235 callback period in the expiry value of emergency registration 236 responses. Emergency clients claiming compliance to this 237 specification MUST honour the value in the registration response from 238 the ESRP-registrar, up to a maximum of 60 minutes. An emergency 239 client SHOULD respect a registration expiry of longer than 60 240 minutes, but MAY terminate its registration with and ESRP-registrar 241 at 60 minutes if the expiry value provided by the ESRP-registrar was 242 longer. 244 In the event that a registration is lost by the emergency client 245 prior to reaching registration expiry then the emergency client MUST 246 re-register with the ESRP-registrar and SHOULD use the same call-id. 247 In this circumstance the ESRP-registrar SHOULD match the instance-id 248 and the call-id to recognize that it is a re-registration for a 249 dropped connection, and expiry time in the registration response 250 SHOULD be set to the time remaining from the original registration 251 occurred. 253 [I-D.ietf-sip-outbound] requires a device to support at least 2 254 registrations to different proxies. The emergency client 255 requirements in this memo relax this requirement down to one 256 registration, but more than one is allowed. There are several 257 reasons for relaxing the connection redundancy requirement. Firstly, 258 ESRPs are expected to have inbuilt redundancy, so if a connection is 259 dropped due to a failed proxy in the ESRP, then a new connection or 260 registration will automatically be directed to an active proxy in the 261 ESRP cluster. If the connection dropped because of some other 262 failure along the path from the emergency client to the ESRP, then 263 multiple SIP registrations are unlikely to provide any measurable 264 reliability improvements since single points of failure in this path 265 are inherently likely. Secondly, re-registrations only occur 266 immediately prior to call placement, so any outbound failure will 267 also likely result in the call dropping. If this occurs then the 268 emergency client MUST re-register with the ESRP-registrar, and since 269 instance-id and public GRUU will remain unchanged as a result of 270 this, the emergency client can either receive a callback from the 271 PSAP, or it can initiate a new call to the emergency network. 273 Location information is critical to emergency calling. Providing 274 location information to the calling-entity with sufficient 275 granularity to allow ESRP route determination is crucial. Since this 276 must occur prior to the emergency client registering with the ESRP- 277 registrar, the emergency client must have access to a certain amount 278 of location information (and the amount varies depending on the 279 specific emergency services deployment architecture). 281 The device SHOULD include all the location information it has when 282 registering with the ERSP-registrar. Inclusion of location 283 information in SIP REGISTER messages is specified in 284 [I-D.ietf-sipcore-location-conveyance]. There are three possible 285 execution paths for the ESRP-registrar when receiving a REGISTER 286 message: 288 1. If the REGISTER message does not include location information the 289 ESRP-registrar MUST use HELD identity 290 [I-D.ietf-geopriv-held-identity-extensions] to obtain the 291 location of the device as both a location value and reference. 292 In order to contact the LIS the ESRP-registrar SHOULD determine 293 the LIS address using the mechanism described in 294 [I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar 295 MAY use other methods for LIS determination where available. 297 2. If the REGISTER message contains a location URI then the ESRP- 298 registrar MUST dereference it so that it has a location available 299 to route the impending emergency call. The ESRP-registrar MAY 300 validate the LIS address in the location URI with that of the LIS 301 serving the network from which the REGISTER message originated. 303 LIS determination MAY be performed using the methods described in 304 [I-D.thomson-geopriv-res-gw-lis-discovery]. 306 3. The REGISTER message contains location information by value. Any 307 actions performed by the ESRP-registrar to valid this information 308 are specific to the jurisdiction in which the ESRP operates and 309 are out of the scope of this document. 311 Where location conveyance is used confidentiality protection SHOULD 312 be provided using Transport Layer Security (TLS). 314 Figure 3 show the registration message exchange graphically. 316 +--------+ +-----+ +------+ +------+ 317 | Device | | LIS | | LoST | | ESRP | 318 +--------+ +-----+ +------+ +------+ 319 | | | | 320 +<----LIS Discovery---->+ | | 321 | | | | 322 +----locationRequest--->+ | | 323 | | | | 324 +<---locationResponse---| | | 325 | | | | 326 +------------------findService------------->+ | 327 | | | | 328 +<--------------findServiceResponse---------+ | 329 | | | | 330 +------------------------REGISTER------------------------>+ 331 | | | | 332 | +<------locationRequest-----------+ 333 | | | | 334 | +-------locationResponse--------->+ 335 | | | | 336 +<-------------------------200 OK ------------------------+ 337 | | | | 339 Figure 3: Registration message flow 341 REGISTER sip:sos.example.com SIP/2.0 342 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 343 Max-Forwards: 70 344 From: anon ;tag=7F94778B653B 345 To: anon 346 Call-ID: 16CB75F21C70 347 CSeq: 1 REGISTER 348 Geolocation: 349 ;inserted-by="anon@192.0.2.2" 350 ;routing-allowed=yes 351 Geolocation: 352 ;inserted-by="anon@192.0.2.2" 353 ;routing-allowed=no 354 Require: gruu, geolocation 355 Supported: outbound, gruu 356 Contact: 357 ;+sip.instance="" 358 Content-Type: multipart/mixed; boundary=boundary1 359 Content-Length: ... 361 Figure 4: Sample REGISTER message 363 Since the emergency client does not have a nominal domain, it MUST 364 register in the same domain as the ESRP. This is illustrated in the 365 example REGISTER message show in Figure 4. 367 7. Emergency Client Call Intitiation 369 Immediately subsequent to the registration a SIP INVITE request is 370 sent to the ESRP in the following form: 372 1. The Request URI MUST be the service URN [RFC5031] in the "sos" 373 tree. 375 2. The To header MUST be a service URN in the "sos" tree. 377 3. The From header MUST be present and MUST be the public GRUU 378 returned from the registration with the ESRP-registrar. 380 4. A Route header MUST be present with an ESRP URI, obtained from 381 LoST. 383 5. A Contact header MUST be present and contain the public GRUU 384 [I-D.ietf-sip-gruu], and be valid for several minutes following 385 the termination of the call, provided that the UAC remains 386 registered with the same registrar, to permit an immediate call- 387 back to the specific device which placed the emergency call. 389 6. A SDP offer MUST be included in the INVITE. If voice is 390 supported the offer MUST include the G.711 codec, see Section 14 391 of [I-D.ietf-ecrit-phonebcp]. 393 7. SIP Caller Preferences [RFC3841] SHOULD be used to signal how the 394 PSAP should handle the call. For example, a language preference 395 expressed in an Accept-Language header may be used as a hint to 396 cause the PSAP to route the call to a call taker who speaks the 397 requested language. SIP Caller Preferences may also be used to 398 indicate a need to invoke a relay service for communication with 399 people with disabilities in the call. 401 8. Call Termination Control 403 The description in [I-D.rosen-ecrit-premature-disconnect-rqmts] is 404 relevant for this document. 406 9. SIP Feature Restrictions 408 The functionality defined in Section 9.3 in [I-D.ietf-ecrit-phonebcp] 409 regarding disabling of certain features is relevant for this document 410 and an emergency client MUST NOT implement the the features listed in 411 ED-70, and ED-71. 413 10. Testing 415 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] regarding 416 emergency call testing is used by this specification. Since this 417 specification mandates a registration with the ESRP-registrar a 418 similar tagging URI to that described in 419 [I-D.patel-ecrit-sos-parameter] is used to indicate a test 420 registration. 422 Test registrations SHALL be of short durations, but MUST be long 423 enough to allow completion of a "test call" as described in 424 [I-D.ietf-ecrit-phonebcp]. 426 10.1. Test Registration 428 When the emergency client sends a REGISTER request for emergency test 429 registration, the "sos.test" URI parameter MUST be appended to the 430 URI in the Contact header. This indicates to the ESRP-registrar that 431 the request is for emergency test registration. 433 ... 434 Contact: 435 ;+sip.instance="" 436 Content-Type: multipart/mixed; boundary=boundary1 437 Content-Length: ... 439 Figure 5: Test REGISTER Message Fragment 441 Only one Contact header field SHOULD be included in the emergency 442 REGISTER test request. If more than one Contact header is included 443 then the presence of the "sos.test" URI in any of the Contact fields 444 SHALL result in the ESRP-registrar treating the registration as a 445 test registration. 447 10.2. Format 449 The following syntax specification uses the augmented Backus-Naur 450 Form (BNF) as described in [RFC5234]. 452 The "sos.test" URI parameter is a "uri-parameter", as defined by 453 [RFC3261]. 455 uri-parameter =/ sos-param-test 457 sos-param-test = "sos.test" 459 11. PSAP Callback 461 PSAP callback occurs as described in 462 [I-D.schulzrinne-ecrit-psap-callback]. 464 12. Security Considerations 466 TBD 468 13. IANA Considerations 470 This specification defines one new SIP URI parameter, as per the 471 registry created by [RFC3969]. 473 Parameter Name: sos.test 475 Predefined Values: none 477 Reference: [RFCXXXX] 479 [NOTE TO IANA: Please replace XXXX with the RFC number of this 480 specification.] 482 14. Acknowledgements 484 Thanks to Elaine Quah for being a sounding board. 486 15. References 488 15.1. Normative References 490 [I-D.ietf-ecrit-phonebcp] 491 Rosen, B. and J. Polk, "Best Current Practice for 492 Communications Services in support of Emergency Calling", 493 draft-ietf-ecrit-phonebcp-13 (work in progress), 494 July 2009. 496 [I-D.ietf-geopriv-held-identity-extensions] 497 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 498 Barnes, "Use of Device Identity in HTTP-Enabled Location 499 Delivery (HELD)", 500 draft-ietf-geopriv-held-identity-extensions-01 (work in 501 progress), October 2009. 503 [I-D.ietf-sip-gruu] 504 Rosenberg, J., "Obtaining and Using Globally Routable User 505 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 506 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 507 October 2007. 509 [I-D.ietf-sip-outbound] 510 Jennings, C., "Managing Client Initiated Connections in 511 the Session Initiation Protocol (SIP)", 512 draft-ietf-sip-outbound-20 (work in progress), June 2009. 514 [I-D.ietf-sipcore-location-conveyance] 515 Polk, J. and B. Rosen, "Location Conveyance for the 516 Session Initiation Protocol", 517 draft-ietf-sipcore-location-conveyance-01 (work in 518 progress), July 2009. 520 [I-D.schulzrinne-ecrit-psap-callback] 521 Schulzrinne, H. and H. Tschofenig, "Marking of Calls 522 initiated by Public Safety Answering Points (PSAPs)", 523 draft-schulzrinne-ecrit-psap-callback-00 (work in 524 progress), March 2009. 526 [I-D.thomson-geopriv-res-gw-lis-discovery] 527 Thomson, M. and R. Bellis, "Location Information Server 528 (LIS) Discovery From Behind Residential Gateways", 529 draft-thomson-geopriv-res-gw-lis-discovery-02 (work in 530 progress), July 2009. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 536 A., Peterson, J., Sparks, R., Handley, M., and E. 537 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 538 June 2002. 540 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 541 Preferences for the Session Initiation Protocol (SIP)", 542 RFC 3841, August 2004. 544 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 545 (IANA) Uniform Resource Identifier (URI) Parameter 546 Registry for the Session Initiation Protocol (SIP)", 547 BCP 99, RFC 3969, December 2004. 549 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 550 Emergency and Other Well-Known Services", RFC 5031, 551 January 2008. 553 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 554 Tschofenig, "LoST: A Location-to-Service Translation 555 Protocol", RFC 5222, August 2008. 557 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 558 Specifications: ABNF", STD 68, RFC 5234, January 2008. 560 15.2. Informative References 562 [I-D.ietf-ecrit-framework] 563 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 564 "Framework for Emergency Calling using Internet 565 Multimedia", draft-ietf-ecrit-framework-10 (work in 566 progress), July 2009. 568 [I-D.ietf-ecrit-lost-servicelistboundary] 569 Wolf, K., "Location-to-Service Translation Protocol (LoST) 570 Extension: ServiceListBoundary", 571 draft-ietf-ecrit-lost-servicelistboundary-00 (work in 572 progress), October 2009. 574 [I-D.patel-ecrit-sos-parameter] 575 Patel, M., "SOS Uniform Resource Identifier (URI) 576 Parameter for Marking of Session Initiation Protocol 577 (SIP) Requests related to Emergency Services", 578 draft-patel-ecrit-sos-parameter-06 (work in progress), 579 May 2009. 581 [I-D.rosen-ecrit-premature-disconnect-rqmts] 582 Rosen, B., "Requirements for handling abandoned calls and 583 premature disconnects in emergency calls on the 584 Internet", draft-rosen-ecrit-premature-disconnect-rqmts-02 585 (work in progress), January 2009. 587 Authors' Addresses 589 James Winterbottom 590 Andrew Corporation 591 Andrew Building (39) 592 University of Wollongong, NSW 2500 593 AU 595 Email: james.winterbottom@andrew.com 597 Martin Thomson 598 Andrew Corporation 599 Andrew Building (39) 600 University of Wollongong, NSW 2500 601 AU 603 Email: martin.thomson@andrew.com 605 Hannes Tschofenig 606 Nokia Siemens Networks 607 Linnoitustie 6 608 Espoo, 02 600 609 Finland 611 Email: Hannes.Tschofenig@gmx.net 613 Henning Schulzrinne 614 Columbia University 615 Department of Computer Science 616 450 Computer Science Building 617 New York, NY 10027 618 US 620 Phone: +1 212 939 7004 621 Email: hgs+ecrit@cs.columbia.edu 622 URI: http://www.cs.columbia.edu