idnits 2.17.00 (12 Aug 2021) /tmp/idnits65074/draft-ietf-ecrit-ecall-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2016) is 2149 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-ecrit-additional-data - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ecrit-additional-data' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Consultant 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 2, 2017 Individual 6 July 1, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-08.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the Pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles, providing real-time communications and an 19 integrated set of related data. 21 This document also registers a MIME Content Type and an Emergency 22 Call Additional Data Block for the eCall vehicle data and metadata/ 23 control data. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 63 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 9 68 8.1. The eCall Control Block . . . . . . . . . . . . . . . . . 10 69 8.1.1. The element . . . . . . . . . . . . . . . . . . 11 70 8.1.1.1. Attributes of the element . . . . . . . . . 11 71 8.1.1.2. Child Elements of the element . . . . . . . 12 72 8.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 12 73 8.1.2. The element . . . . . . . . . . . . . . . . 12 74 8.1.2.1. Attributes of the element . . . . . . . 12 75 8.1.2.2. Request Example . . . . . . . . . . . . . . . . . 13 76 9. The emergencyCallData.eCall INFO package . . . . . . . . . . 13 77 9.1. INFO Package Requirements . . . . . . . . . . . . . . . . 13 78 9.1.1. Overall Description . . . . . . . . . . . . . . . . . 14 79 9.1.2. Applicability . . . . . . . . . . . . . . . . . . . . 14 80 9.1.3. Info Package Name . . . . . . . . . . . . . . . . . . 15 81 9.1.4. Info Package Parameters . . . . . . . . . . . . . . . 15 82 9.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . 15 83 9.1.6. INFO Message Body Parts . . . . . . . . . . . . . . . 15 84 9.1.7. Info Package Usage Restrictions . . . . . . . . . . . 15 85 9.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . . 15 86 9.1.9. Info Package Security Considerations . . . . . . . . 15 87 9.1.10. Implementation Details . . . . . . . . . . . . . . . 16 88 9.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 16 89 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 92 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 14.1. Service URN Registrations . . . . . . . . . . . . . . . 22 95 14.2. MIME Content-type Registration for 96 'application/emergencyCallData.eCall.MSD+per' . . . . . 23 98 14.3. MIME Content-type Registration for 99 'application/emergencyCallData.eCall.control+xml' . . . 24 100 14.4. Registration of the 'eCall.MSD' entry in the Emergency 101 Call Additional Data Blocks registry . . . . . . . . . . 26 102 14.5. Registration of the 'eCall.control' entry in the 103 Emergency Call Additional Data Blocks registry . . . . . 26 104 14.6. Registration of the emergencyCallData.eCall Info Package 26 105 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 26 106 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 26 107 14.7.2. Registration for 108 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 27 109 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 28 110 14.8.1. eCall Control Action Registry . . . . . . . . . . . 28 111 14.8.2. eCall Control Extension Registry . . . . . . . . . . 29 112 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 113 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 114 17. Changes from Previous Versions . . . . . . . . . . . . . . . 30 115 17.1. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 30 116 17.2. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 30 117 17.3. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 30 118 17.4. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 31 119 17.5. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 31 120 17.6. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 31 121 17.7. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 31 122 17.8. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 31 123 17.9. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 32 124 17.10. Changes from draft-gellens-02 to -03 . . . . . . . . . . 32 125 17.11. Changes from draft-gellens-01 to -02 . . . . . . . . . . 32 126 17.12. Changes from draft-gellens-00 to -01 . . . . . . . . . . 32 127 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 128 18.1. Normative References . . . . . . . . . . . . . . . . . . 32 129 18.2. Informative references . . . . . . . . . . . . . . . . . 34 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 132 1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 This document re-uses terminology defined in Section 3 of [RFC5012]. 140 Additionally, we use the following abbreviations: 142 +--------+----------------------------------------+ 143 | Term | Expansion | 144 +--------+----------------------------------------+ 145 | 3GPP | 3rd Generation Partnership Project | 146 | | | 147 | CEN | European Committee for Standardization | 148 | | | 149 | EENA | European Emergency Number Association | 150 | | | 151 | ESInet | Emergency Services IP network | 152 | | | 153 | IMS | IP Multimedia Subsystem | 154 | | | 155 | IVS | In-Vehicle System | 156 | | | 157 | MNO | Mobile Network Operator | 158 | | | 159 | MSD | Minimum Set of Data | 160 | | | 161 | PSAP | Public Safety Answering Point | 162 +--------+----------------------------------------+ 164 2. Document Scope 166 This document is limited to the signaling, data exchange, and 167 protocol needs of next-generation eCall (NG-eCall, also referred to 168 as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP 169 framework for emergency calls, as described in [RFC6443] and 170 [RFC6881]. eCall itself is specified by 3GPP and CEN and these 171 specifications include far greater scope than is covered here. 173 The eCall service operates over cellular wireless communication, but 174 this document does not address cellular-specific details, nor client 175 domain selection (e.g., circuit-switched versus packet-switched). 176 All such aspects are the purview of their respective standards 177 bodies. The scope of this document is limited to eCall operating 178 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 180 The technical contents of this document can be suitable for use in 181 other vehicle-initiated emergency call systems, but this is out of 182 scope for this document. 184 Vehicles designed for multiple regions might need to support eCall 185 and other Advanced Automatic Crash Notification (AACN) systems, such 186 as described in [I-D.ietf-ecrit-car-crash]. That system is 187 compatible with eCall, differing primarily in the specific data set 188 that is sent. 190 3. Introduction 192 Emergency calls made from vehicles (e.g., in the event of a crash) 193 assist in significantly reducing road deaths and injuries by allowing 194 emergency services to be aware of the incident, the state of the 195 vehicle, the location of the vehicle, and to have a voice channel 196 with the vehicle occupants. This enables a quick and appropriate 197 response. 199 The European Commission initiative of eCall was conceived in the late 200 1990s, and has evolved to a European Parliament decision requiring 201 the implementation of a compliant in-vehicle system (IVS) in new 202 vehicles and the deployment of eCall in the European Member States in 203 the very near future. Other regions are developing eCall-compatible 204 systems. 206 The pan-European eCall system provides a standardized and mandated 207 mechanism for emergency calls by vehicles. eCall establishes 208 procedures for such calls to be placed by in-vehicle systems, 209 recognized and processed by the mobile network, and routed to a 210 specialized PSAP where the vehicle data is available to assist the 211 call taker in assessing and responding to the situation. eCall 212 provides a standard set of vehicle, sensor (e.g., crash related), and 213 location data. 215 An eCall can be either user-initiated or automatically triggered. 216 Automatically triggered eCalls indicate a car crash or some other 217 serious incident. Manually triggered eCalls might be reports of 218 witnessed crashes or serious hazards. PSAPs might apply specific 219 operational handling to manual and automatic eCalls. 221 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 222 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 223 call setup mark the call as an eCall, and further indicate if the 224 call was automatically or manually triggered. The call is routed to 225 an eCall-capable PSAP, a voice channel is established between the 226 vehicle and the PSAP, and an eCall in-band modem is used to carry a 227 defined set of vehicle, sensor (e.g., crash related), and location 228 data (the Minimum Set of Data or MSD) within the voice channel. The 229 same in-band mechanism is used for the PSAP to acknowledge successful 230 receipt of the MSD, and to request the vehicle to send a new MSD 231 (e.g., to check if the state of or location of the vehicle or its 232 occupants has changed). NG-eCall moves from circuit switched to all- 233 IP, and carries the vehicle data and other eCall-specific data as 234 additional data carried with the call. This document describes how 235 IETF mechanisms for IP-based emergency calls, including [RFC6443] and 236 [I-D.ietf-ecrit-additional-data] are used to provide the signaling 237 and data exchange of the next generation of pan-European eCall. 239 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 240 has published a Technical Report titled "Mobile Standards Group 241 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 242 recommendations regarding support for eCall in an all-IP environment. 243 The recommendations include the use of 3GPP IMS emergency calling 244 with additional elements identifying the call as an eCall and as 245 carrying eCall data and with mechanisms for carrying the data and 246 eCall-specific signaling. 3GPP IMS emergency services support 247 multimedia, providing the ability to carry voice, text, and video. 248 This capability is referred to within 3GPP as Multimedia Emergency 249 Services (MMES). 251 A transition period will exist during which time the various entities 252 involved in initiating and handling an eCall might support next- 253 generation eCall, legacy eCall, or both. The issues of migration and 254 co-existence during the transition period is outside the scope of 255 this document. 257 4. eCall Requirements 259 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 260 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 261 data are contained in EN 15722 [msd]. 263 5. Vehicle Data 265 Pan-European eCall provides a standardized and mandated set of 266 vehicle related data, known as the Minimum Set of Data (MSD). The 267 European Committee for Standardization (CEN) has specified this data 268 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 269 MSD [msd]. Both circuit-switched eCall and this document use the 270 ASN.1 PER encoding, which is specified in Annex A of EN 15722 [msd] 271 (the XML encoding specified in Annex C is not used in this document). 273 The "Additional Data related to an Emergency Call" document 274 [I-D.ietf-ecrit-additional-data] establishes a general mechanism for 275 attaching blocks of data to a SIP emergency call. This document 276 makes use of that mechanism to carry the eCall MSD in a SIP emergency 277 call. 279 This document registers the 'application/ 280 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 281 to be carried in SIP. As an ASN.1 PER encoded object, the data is 282 binary and transported using binary content transfer encoding within 283 SIP messages. This document also adds the 'eCall.MSD' entry to the 284 Emergency Call Additional Data Blocks registry (established by 285 [I-D.ietf-ecrit-additional-data]) to enable the MSD to be recognized 286 as such in a SIP-based eCall emergency call. 288 Note that if additional data sets are defined and registered (e.g., 289 in the future or in other regions) and transmitted using the same 290 mechanisms, the size and frequency of transmission during a dialog 291 need to be evaluated to be sure it is appropriate to use the 292 signaling channel. 294 6. Call Setup 296 In circuit-switched eCall, the IVS places a special form of a 112 297 emergency call which carries an eCall flag (indicating that the call 298 is an eCall and also if the call was manually or automatically 299 triggered); the mobile network operator (MNO) recognizes the eCall 300 flag and routes the call to an eCall-capable PSAP; vehicle data is 301 transmitted to the PSAP via the eCall in-band modem (in the voice 302 channel). 304 ///----\\\ 112 voice call with eCall flag +------+ 305 ||| IVS |||---------------------------------------->+ PSAP | 306 \\\----/// vehicle data via eCall in-band modem +------+ 308 Figure 1: circuit-switched eCall 310 An In-Vehicle System (IVS) initiating an NG-eCall transmits the MSD 311 in accordance with [I-D.ietf-ecrit-additional-data] by encoding it as 312 specified (per Annex A of EN 15722 [msd]) and attaching it to an 313 INVITE as a MIME body part. The body part is identified by its MIME 314 content-type ('application/emergencyCallData.eCall.MSD+per') in the 315 Content-Type header field of the body part. The body part is 316 assigned a unique identifier which is listed in a Content-ID header 317 field in the body part. The INVITE is marked as containing the MSD 318 by adding (or appending to) a Call-Info header field at the top level 319 of the INVITE. This Call-Info header field contains a CID URL 320 referencing the body part's unique identifier, and a 'purpose' 321 parameter identifying the data as the eCall MSD per the registry 322 entry; the 'purpose' parameter's value is 'emergencyCallData.' plus 323 the root of the MIME type (not including the 'emergencyCallData.' 324 prefix and any suffix such as '+per', so in this case, 325 'purpose=emergencyCallData.eCall.MSD'. 327 For NG-eCall, the IVS establishes an emergency call using a Request- 328 URI indicating a manual or automatic eCall; the MNO (or ESInet) 329 recognizes the eCall URN and routes the call to an NG-eCall capable 330 PSAP; the PSAP interpets the vehicle data sent with the call and 331 makes it available to the call taker. 333 ///----\\\ IMS emergency call with eCall URN +------+ 334 IVS ----------------------------------------->+ PSAP | 335 \\\----/// vehicle data included in call setup +------+ 337 Figure 2: NG-eCall 339 This document registers new service URN children within the "sos" 340 subservice. These URNs provide the mechanism by which an eCall is 341 identified, and differentiate between manually and automatically 342 triggered eCalls (which might be subject to different treatment, 343 depending on policy). The two service URNs are: 344 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 346 6.1. Call Routing 348 The routing applied to eCalls might differ from those of other 349 emergency calls, as eCalls are intended to be handled by PSAPs that 350 support eCall. In regions without ESInets, typically the emergency 351 services authorities and the originating network determine how such 352 calls are routed. In a region that uses ESInets, the originating 353 network passes all types of emergency calls to an ESInet (calls which 354 have a request URI containing the "SOS" service URN). The ESInet is 355 then responsible for routing such calls to the appropriate PSAP. 357 7. Test Calls 359 eCall requires the ability to place test calls. These are calls that 360 are recognized and treated to some extent as eCalls but are not given 361 emergency call treatment and are not handled by call takers. The 362 specific handling of test eCalls is not itself standardized; 363 typically, the test call facility allows the IVS or user to verify 364 that an eCall can be successfully established with voice 365 communication. The IVS might also be able to verify that the MSD was 366 successfully received. 368 A service URN starting with "test." indicates a test call. For 369 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 370 This functionality is defined in [RFC6881]. 372 This document registers "urn:service:test.sos.ecall" for eCall test 373 calls. 375 The CS-eCall test call facility is a non-emergency number so does not 376 get treated as an emergency call. For NG-eCall, MNOs, emergency 377 authorities, and PSAPs can determine how to treat a vehicle call 378 requesting the "test" service URN so that the desired functionality 379 is tested, but this is outside the scope of this document. (One 380 possibility is that MNOs route such calls as non-emergency calls to a 381 PSAP that supports NG-eCall; the PSAP accepts test calls, sends an 382 MSD acknowledgment, and plays an audio clip (for example, saying that 383 the call reached an eCall PSAP) in addition to supporting media 384 loopback per [RFC6881]). 386 8. eCall-Specific Control/Metadata 388 eCall requires the ability for the PSAP to acknowledge successful 389 receipt of an MSD sent by the IVS, and for the PSAP to request that 390 the IVS send an MSD (e.g., the call taker can initiate a request for 391 a new MSD to see if there have been changes in the vehicle's state, 392 e.g., location, direction, number of fastened seatbelts). 394 The mechanism established in [I-D.ietf-ecrit-additional-data], used 395 in Section 5 of this document to carry the MSD from the IVS to the 396 PSAP, is also used to carry a block of metadata/control data from the 397 PSAP to the IVS. This eCall control block (sometimes referred to as 398 eCall metadata) is an XML structure containing eCall-specific 399 elements. When the PSAP needs to send an eCall control block that is 400 in response to data sent by the IVS in a SIP request (e.g., the MSD 401 in the initial INVITE), the control block can be sent in the SIP 402 response to that request (e.g., the response to the INVITE request). 403 When the PSAP needs to send an eCall control block in other 404 circumstances (e.g., mid-call), the control block can be transmitted 405 from the PSAP to the IVS in a SIP INFO request within the established 406 dialog. The IVS sends the requested data (the MSD) in a new INFO 407 request. This mechanism flexibly allows the PSAP to send eCall- 408 specific data to the IVS and the IVS to respond. 410 This mechanism requires 412 o An XML definition of the eCall control object 413 o An extension mechanism by which new elements, attributes, and 414 values can be added to the control object definition 415 o A MIME type registration for the control object (so it can be 416 carried in SIP messages and responses) 417 o An entry in the Emergency Call Additional Data Blocks sub-registry 418 (established by [I-D.ietf-ecrit-additional-data]) so that the 419 control block can be recognized as emergency call specific data 420 within SIP messages 421 o An Info-Package registration per [RFC6086] permitting data blocks 422 registered in the Emergency Call Additional Data Blocks sub- 423 registry (established by [I-D.ietf-ecrit-additional-data]) within 424 Info messages 426 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 427 initial INVITE), the PSAP sends a metadata/control block indicating 428 successful/unsuccessful receipt of the MSD in the SIP response to the 429 request. This also informs the IVS that an NG-eCall is in operation. 430 If the IVS receives a SIP response without the metadata/control 431 block, it indicates that the SIP dialog is not an NG-eCall. When the 432 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 433 receipt of a SIP INFO request containing a metadata/control block 434 requesting an MSD), the PSAP does not send a metadata/control block 435 indicating successful or unsuccessful receipt of the MSD. (Normal 436 SIP retransmission handles non-receipt of requested data; if the IVS 437 sends a requested MSD in an INFO request and does not receive a SIP 438 status message for the INFO request, it resends it; if the PSAP 439 requests an MSD and does not receive a SIP status message for the 440 INFO request, it resends it.) 442 This provides flexibility to handle various circumstances. For 443 example, if a PSAP is unable to accept an eCall (e.g., due to 444 overload or too many calls from the same location), it can reject the 445 INVITE. Since a metadata/control object is also included in the SIP 446 response that rejects the call, the IVS knows if the PSAP received 447 the MSD, and can inform the occupants that the PSAP successfully 448 received the vehicle location and information but can't talk to the 449 occupants at that time. Especially for SIP response codes that 450 indicate an inability to conduct a call (as opposed to a technical 451 inability to process the request), the IVS can also determine that 452 the call was successful on a technical level (e.g., not necessary to 453 retry as a CS-eCall). The SIP response code 600 (Busy Everywhere) 454 can be used to indicate this. Other SIP response codes that can be 455 interpreted in this way include 480 (Temporarily Unavailable), 486 456 (Busy Here), and 603 (Decline). 458 8.1. The eCall Control Block 460 The eCall control block is an XML data structure allowing for 461 acknowledgments and requests. It is carried in a SIP body part with 462 a specific MIME content type. It can be extended via an IANA 463 registry to add additional elements, attributes, and values. Two 464 top-level elements are defined for use within an eCall control block: 466 ack Used in a control block sent by the PSAP to acknowledge 467 receipt of a data set sent by the IVS. 469 request Used in a control block sent by the PSAP to request the 470 vehicle to perform an action. The only action defined 471 in this document is a request for the IVS to send an 472 MSD. 474 Mandatory Actions (the IVS and the PSAP MUST support): 476 o Transmit data object 477 Optional Actions (the IVS and the PSAP MAY support): 479 o None 481 The element indicates the object being acknowledged (e.g., the 482 MSD), and reports success or failure. 484 The element contains attributes to indicate the request and 485 to supply related information. The 'action' attribute is mandatory 486 and indicates the specific action. An IANA registry is created in 487 Section 14.8.1 to contain the allowed values. 489 Extensibility: New elements, child elements, attributes of new and 490 existing elements, and values for new and existing attributes can be 491 added in the IANA registry created in Section 14.8.2. The registry 492 permits implementors to see what has been added, with a reference to 493 the defining document. (Implementations are not expected to 494 dynamically check the registry.) Implementations MUST ignore 495 unsupported elements, attributes, and values. 497 8.1.1. The element 499 The element is transmitted by the PSAP to acknowledge receipt 500 of an eCall data object. An element sent by a PSAP references 501 the unique ID of the data object that was sent by the IVS, and 502 further indicates if the PSAP considers the receipt successful or 503 not. 505 The element has the following attributes: 507 8.1.1.1. Attributes of the element 509 The element has the following attributes: 511 Name: ref 512 Usage: Mandatory 513 Type: anyURI 514 Description: References the Content-ID of the body part that 515 contained the data object being acknowledged. 516 Example: 518 Name: received 519 Usage: Conditional: mandatory in an >ack< element sent by a PSAP 520 Type: Boolean 521 Description: Indicates if the referenced object was successfully 522 received or not 523 Example: 525 8.1.1.2. Child Elements of the element 527 The element has no child elements 529 8.1.1.3. Ack Examples 531 532 538 540 542 Figure 3: Ack Example from PSAP to IVS 544 8.1.2. The element 546 A element allows the PSAP to request that the IVS send an 547 MSD. The following attributes are defined: 549 8.1.2.1. Attributes of the element 551 The element has the following attributes: 553 Name: action 554 Usage: Mandatory 555 Type: token 556 Description: Identifies the action that the vehicle is requested to 557 perform. An IANA registry is established in Section 14.8.1 to 558 contain the allowed values. 559 Example: action="send-data" 561 Name: datatype 562 Usage: Conditional 563 Type: token 564 Description: Mandatory with a "send-data" action. Specifies the 565 data block that the IVS is requested to transmit, using the same 566 identifier as in the 'purpose' attribute set in a Call-Info header 567 field to point to the data block. Permitted values are contained 568 in the 'Emergency Call Data Types' IANA registry established in 569 [I-D.ietf-ecrit-additional-data]. 570 Example: datatype="eCall.MSD" 572 8.1.2.2. Request Example 574 575 581 583 585 Figure 4: Request Example 587 9. The emergencyCallData.eCall INFO package 589 This document registers the 'emergencyCallData.eCall' INFO package. 591 Both endpoints (the IVS and the PSAP equipment) include 592 'emergencyCallData.eCall' in a Recv-Info header field per [RFC6086] 593 to indicate ability to receive INFO messages carrying data as 594 described here. 596 Support for the 'emergencyCallData.eCall' INFO package indicates the 597 ability to receive body parts registered in the 'Emergency Call Data 598 Types' IANA registry established in [I-D.ietf-ecrit-additional-data]. 600 An INFO request message carrying data related to an emergency call 601 has an Info-Package header field set to 'emergencyCallData.eCall' per 602 [RFC6086]. Per [I-D.ietf-ecrit-additional-data], the INFO request 603 message contains one or more Call-Info header fields containing a CID 604 URL referencing the unique identifier of a body part, and a 'purpose' 605 parameter identifying the data. Because the data is being carried in 606 an INFO request message, the body part also carries a Content- 607 Disposition header field set to "Info-Package". 609 9.1. INFO Package Requirements 611 The requirements of Section 10 of [RFC6086] are addressed in the 612 following sections. 614 9.1.1. Overall Description 616 This section describes "what type of information is carried in INFO 617 requests associated with the Info Package, and for what types of 618 applications and functionalities UAs can use the Info Package." 620 INFO requests associated with the emergencyCallData.eCall INFO 621 package carry data associated with emergency calls as registered in 622 the 'Emergency Call Data Types' IANA registry established in 623 [I-D.ietf-ecrit-additional-data]. The application is emergency calls 624 established using SIP. The functionality is to carry data, metadata, 625 and control information (requests) between vehicles and PSAPs. Refer 626 to [TBD: THIS DOCUMENT] for more information. 628 9.1.2. Applicability 630 This section describes "why the Info Package mechanism, rather than 631 some other mechanism, has been chosen for the specific use-case...." 633 The use of INFO is based on an analysis of the requirements against 634 the intent and effects of INFO versus other approaches (which 635 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 636 transport, and non-SIP protocols). In particular, the transport of 637 emergency call data blocks occurs within a SIP emergency dialog, 638 using the mechanism established in [I-D.ietf-ecrit-additional-data], 639 and is normally carried in the initial INVITE and its response; the 640 use of INFO only occurs when emergency-call-related data needs to be 641 sent mid-call. While MESSAGE could be used, it is not tied to a SIP 642 dialog as is INFO and thus might not be associated with the dialog. 643 SIP OPTIONS or re-INVITE could also be used, but is seen as less 644 clean than INFO. SUBSCRIBE/NOTIFY could be coerced into service, but 645 the semantics are not a good fit, e.g., the subscribe/notify 646 mechanism provides one-way communication consisting of (often 647 multiple) notifications from notifier to subscriber indicating that 648 certain events in notifier have occurred, whereas what's needed here 649 is two-way communication of data related to the emergency dialog. 650 Use of the media plane mechanisms was discounted because the number 651 of messages needing to be exchanged in a dialog is normally zero or 652 very few, and the size of the data is likewise very small. The 653 overhead caused by user plane setup (e.g., to use MSRP as transport) 654 would be disproportionately large, and further, a high-level 655 application protocol identifying the specific data block being sent 656 within the media plane (as provided by the Call-Info header field 657 parameters and MIME body part content type within INFO) would need to 658 be defined. 660 Based on the the analyses, the SIP INFO method was chosen to provide 661 for mid-call data transport. 663 9.1.3. Info Package Name 665 The info package name is emergencyCallData.eCall. 667 9.1.4. Info Package Parameters 669 None. 671 9.1.5. SIP Option-Tags 673 None. 675 9.1.6. INFO Message Body Parts 677 Only those body parts registered in the 'Emergency Call Data Types' 678 IANA registry established in [I-D.ietf-ecrit-additional-data] are 679 associated with this INFO package. 681 When more than one body part is included, they are enclosed in a 682 multipart body part (e.g., multipart/mixed). When a body part is 683 digitally signed or encrypted, it is enclosed in an appropriate body 684 part (e.g., multipart/signed or multipart/encrypted). 686 The Content-Disposition value of a message body part associated with 687 the emergencyCallData.eCall info package is "info-package". 689 9.1.7. Info Package Usage Restrictions 691 None. 693 9.1.8. Rate of INFO Requests 695 The rate of SIP INFO requests associated with the 696 emergencyCallData.eCall info package is expected to be quite low 697 (most dialogs are likely to contain zero INFO requests, while others 698 can be expected to carry occasional requests). 700 9.1.9. Info Package Security Considerations 702 The MIME content type registation for each data block registered in 703 the 'Emergency Call Data Types' IANA registry established in 704 [I-D.ietf-ecrit-additional-data] contains a discussion of the 705 security and/or privacy considerations specific to that data block. 706 The "Security Considerations" and "Privacy Considerations" sections 707 of [TBD: THIS DOCUMENT] discuss security and privacy considerations 708 of the data carried in eCealls. 710 9.1.10. Implementation Details 712 See [TBD: THIS DOCUMENT] for protocol details. 714 9.1.11. Examples 716 See [TBD: THIS DOCUMENT] for protocol examples. 718 10. Examples 720 Figure 5 illustrates an eCall. The call uses the request URI 721 'urn:service:sos.ecall.automatic' service URN and is recognized as an 722 eCall, and further as one that was invoked automatically by the IVS 723 due to a crash or other serious incident. In this example, the 724 originating network routes the call to an ESInet which routes the 725 call to the appropriate NG-eCall capable PSAP. The emergency call is 726 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 727 the entry point into the ESInet. The ESRP routes the call to a PSAP, 728 where it is received by a call taker. In deployments where there is 729 no ESInet, the originating network routes the call directly to the 730 appropriate NG-eCall capable PSAP, an illustration of which would be 731 identical to the one below except without an ESInet or ESRP. 733 +------------+ +---------------------------------------+ 734 | | | +-------+ | 735 | | | | PSAP2 | | 736 | | | +-------+ | 737 | | | | 738 | | | +------+ +-------+ | 739 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 740 | | | +------+ +-------+ | 741 | | | | 742 | | | +-------+ | 743 | | | | PSAP3 | | 744 | Originating| | +-------+ | 745 | Mobile | | | 746 | Network | | ESInet | 747 +------------+ +---------------------------------------+ 749 Figure 5: Example of NG-eCall Message Flow 751 The example, shown in Figure 6, illustrates a SIP eCall INVITE that 752 contains an MSD. For simplicity, the example does not show all SIP 753 headers, nor the SDP contents, nor does it show any additional data 754 blocks added by the IVS or the originating mobile network. Because 755 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 756 contents cannot be included in a text document. 758 INVITE urn:service:sos.ecall.automatic SIP/2.0 759 To: urn:service:sos.ecall.automatic 760 From: ;tag=9fxced76sl 761 Call-ID: 3848276298220188511@atlanta.example.com 762 Geolocation: 763 Geolocation-Routing: no 764 Call-Info: cid:1234567890@atlanta.example.com; 765 purpose=emergencyCallData.eCall.MSD; 766 cid:2345678901@atlanta.example.com; 767 purpose=emergencyCallData.eCall.control; 768 Accept: application/sdp, application/pidf+xml, 769 application/emergencyCallData.eCall.control+xml 770 CSeq: 31862 INVITE 771 Recv-Info: emergencyCallData.eCall 772 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 773 SUBSCRIBE, NOTIFY, UPDATE 774 Content-Type: multipart/mixed; boundary=boundary1 775 Content-Length: ... 777 --boundary1 778 Content-Type: application/sdp 780 ...Session Description Protocol (SDP) goes here... 782 --boundary1 783 Content-Type: application/emergencyCallData.eCall.MSD+per 784 Content-ID: 1234567890@atlanta.example.com 785 Content-Disposition: by-reference;handling=optional 786 Content-Transfer-Encoding: binary 788 ...MSD in ASN.1 PER encoding goes here... 790 --boundary1-- 792 Figure 6: SIP NG-eCall INVITE 794 Continuing the example, Figure 7 illustrates a SIP 200 OK response to 795 the INVITE of Figure 6, containing an eCall control block 796 acknowledging successful receipt of the eCall MSD. (For simplicity, 797 the example does not show all SIP headers.) 798 SIP/2.0 200 OK 799 To: ;tag=9fxced76sl 800 From: Exemplar PSAP 801 Call-ID: 3848276298220188511@atlanta.example.com 802 Call-Info: cid:2345678901@atlanta.example.com; 803 purpose=emergencyCallData.eCall.control; 804 Accept: application/sdp, application/pidf+xml, 805 application/emergencyCallData.eCall.control+xml, 806 application/emergencyCallData.eCall.MSD+per 807 CSeq: 31862 INVITE 808 Recv-Info: emergencyCallData.eCall 809 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 810 SUBSCRIBE, NOTIFY, UPDATE 811 Content-Type: multipart/mixed; boundary=boundaryX 812 Content-Length: ... 814 --boundaryX 815 Content-Type: application/sdp 817 ...Session Description Protocol (SDP) goes here... 819 --boundaryX 820 Content-Type: application/EmergencyCallData.eCall.control+xml 821 Content-ID: 2345678901@atlanta.example.com 822 Content-Disposition: by-reference;handling=optional 824 825 831 833 835 --boundaryX-- 837 Figure 7: 200 OK response to INVITE 839 11. Security Considerations 841 The security considerations described in [RFC5069] apply here. 843 In addition to any network-provided location (which might be 844 determined solely by the network, or in cooperation with or possibly 845 entirely by the originating device), an eCall carries an IVS-supplied 846 location within the MSD. This is likely to be useful to the PSAP, 847 especially when no network-provided location is included, or when the 848 two locations are independently determined. Even in situations where 849 the network-supplied location is limited to the cell site, this can 850 be useful as a sanity check on the device-supplied location contained 851 in the MSD. 853 The document [RFC7378] discusses trust issues regarding location 854 provided by or determined in cooperation with end devices. 856 Security considerations specific to the mechanism by which the PSAP 857 sends acknowledgments and requests to the vehicle are discussed in 858 the "Security Considerations" block of Section 14.3. 860 Data received from external sources inherently carries implementation 861 risks. For example, depending on the platform, buffer overflows can 862 introduce remote code execution vulnerabilities, null characters can 863 corrupt strings, numeric values used for internal calculations can 864 result in underflow/overflow errors, malformed XML objects can expose 865 parsing bugs, etc. Implementations need to be cognizant of the 866 potential risks, observe best practices (which might include 867 sufficiently capable static code analysis, fuzz testing, component 868 isolation, avoiding use of unsafe coding techniques, third-party 869 attack tests, signed software, over-the-air updates, etc.), and have 870 multiple levels of protection. Implementors need to be aware that, 871 potentially, the data objects described here and elsewhere might be 872 malformed, might contain unexpected characters, excessively long 873 attribute values, elements, etc. 875 Since this document depends on [I-D.ietf-ecrit-additional-data], the 876 security considerations discussed there apply here (see especially 877 the discussion of TLS, TLS versions, cypher suites, and PKI). 879 When vehicle data or control/metadata is contained in a signed or 880 encrypted body part, the enclosing multipart (e.g., multipart/signed 881 or multipart/encrypted) has the same Content-ID as the enclosed data 882 part. This allows an entity to identify and access the data blocks 883 it is interested in without having to dive deeply into the message 884 structure or decrypt parts it is not interested in. (The 'purpose' 885 parameter in a Call-Info header field identifies the data and 886 contains a CID URL pointing to the data block in the body, which has 887 a matching Content-ID body part header field). 889 12. Privacy Considerations 891 Since this document builds on [I-D.ietf-ecrit-additional-data], the 892 data structures specified there, and the corresponding privacy 893 considerations discussed there, apply here as well. The MSD carries 894 some additional identifying and personal information (mostly about 895 the vehicle and less about the owner), as well as location 896 information, and so needs to be protected against unauthorized 897 disclosure. Local regulations may impose additional privacy 898 protection requirements. 900 Privacy considerations specific to the data structure containing 901 vehicle information are discussed in the "Security Considerations" 902 block of Section 14.2. 904 Privacy considerations specific to the mechanism by which the PSAP 905 sends acknowledgments and requests to the vehicle are discussed in 906 the "Security Considerations" block of Section 14.3. 908 13. XML Schema 910 This section defines an XML schema for the eCall control block. The 911 text description of the eCall control block in Section 8.1 is 912 normative and supersedes any conflicting aspect of this schema. 914 915 924 927 930 931 932 Permitted values specified in IANA 933 registries 934 935 936 937 938 939 940 941 943 945 948 949 950 951 952 954 955 956 957 959 963 964 966 969 971 972 973 974 976 977 978 979 980 983 984 985 987 990 991 992 993 995 997 Figure 8: eCall Control Block Schema 999 14. IANA Considerations 1001 14.1. Service URN Registrations 1003 IANA is requested to register the URN 'urn:service:sos.ecall' under 1004 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1006 This service requests resources associated with an emergency call 1007 placed by an in-vehicle system, carrying a standardized set of data 1008 related to the vehicle and incident. Two sub-services are registered 1009 as well: 1011 urn:service:sos.ecall.manual 1013 Used with an eCall invoked due to manual interaction by a vehicle 1014 occupant. 1016 urn:service:sos.ecall.automatic 1018 Used with an eCall invoked automatically, for example, due to a 1019 crash or other serious incident. 1021 IANA is also requested to register the URN 1022 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1023 defined in Setcion 17.2 of [RFC6881]. 1025 14.2. MIME Content-type Registration for 'application/ 1026 emergencyCallData.eCall.MSD+per' 1028 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1029 as a MIME content type, with a reference to this document, in 1030 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1031 RFC 7303 [RFC7303]. 1033 MIME media type name: application 1035 MIME subtype name: emergencyCallData.eCall.MSD+per 1037 Mandatory parameters: none 1039 Optional parameters: none 1041 Encoding scheme: binary 1043 Encoding considerations: Uses ASN.1 PER, which is a binary 1044 encoding; when transported in SIP, binary content transfer 1045 encoding is used. 1047 Security considerations: This content type is designed to carry 1048 vehicle and incident-related data during an emergency call. This 1049 data contains personal information including vehicle VIN, 1050 location, direction, etc. Appropriate precautions need to be 1051 taken to limit unauthorized access, inappropriate disclosure to 1052 third parties, and eavesdropping of this information. In general, 1053 it is acceptable for the data to be unprotected while briefly in 1054 transit within the Mobile Network Operator (MNO); the MNO is 1055 trusted to not permit the data to be accessed by third parties. 1056 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1057 contain more discussion. 1059 Interoperability considerations: None 1061 Published specification: Annex A of EN 15722 [msd] 1063 Applications which use this media type: Pan-European eCall 1064 compliant systems 1066 Additional information: None 1068 Magic Number: None 1070 File Extension: None 1072 Macintosh file type code: 'BINA' 1073 Person and email address for further information: Randall Gellens, 1074 rg+ietf@randy.pensive.org 1076 Intended usage: LIMITED USE 1078 Author: The MSD specification was produced by the European 1079 Committee For Standardization (CEN). For contact information, 1080 please see . 1082 Change controller: The European Committee For Standardization 1083 (CEN) 1085 14.3. MIME Content-type Registration for 'application/ 1086 emergencyCallData.eCall.control+xml' 1088 IANA is requested to add application/ 1089 emergencyCallData.eCall.control+xml as a MIME content type, with a 1090 reference to this document, in accordance to the procedures of RFC 1091 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1093 MIME media type name: application 1095 MIME subtype name: emergencyCallData.eCall.control+xml 1097 Mandatory parameters: none 1099 Optional parameters: charset 1101 Indicates the character encoding of the XML content. 1103 Encoding considerations: Uses XML, which can employ 8-bit 1104 characters, depending on the character encoding used. See 1105 Section 3.2 of RFC 7303 [RFC7303]. 1107 Security considerations: 1109 This content type carries metadata and control information and 1110 requests, such as from a Public Safety Answering Point (PSAP) 1111 to an In-Vehicle System (IVS) during an emergency call. 1113 Metadata (such as an acknowledgment that data sent by the IVS 1114 to the PSAP was successfully received) has limited privacy and 1115 security implications. Control information (such as requests 1116 from the PSAP that the vehicle perform an action) has some 1117 privacy and security implications. The privacy concern arises 1118 from the ability to request the vehicle to transmit a data set, 1119 which as described in Section 14.2, can contain personal 1120 information. The security concern is the ability to request 1121 the vehicle to perform an action. Control information needs to 1122 originate only from a PSAP or other emergency services 1123 provider, and not be modified en-route. The level of integrity 1124 of the cellular network over which the emergency call is placed 1125 is a consideration: when the IVS initiates an eCall over a 1126 cellular network, in most cases it relies on the MNO to route 1127 the call to a PSAP. (Calls placed using other means, such as 1128 Wi-Fi or over-the-top services, generally incur somewhat higher 1129 levels of risk than calls placed "natively" using cellular 1130 networks.) A call-back from a PSAP merits additional 1131 consideration, since current mechanisms are not ideal for 1132 verifying that such a call is indeed a call-back from a PSAP in 1133 response to an emergency call placed by the IVS. See the 1134 discussion in Section 11 and the PSAP Callback document 1135 [RFC7090]. One potential safeguard, applicable regardless of 1136 which end initiated the call and the means of the call, is for 1137 the PSAP or emergency service provider to sign the body part 1138 using a certificate issued by a known emergency services 1139 certificate authority and for which the IVS can verify the root 1140 certificate; however, this depends on deployed key 1141 infrastructure including a recognized certificate authority, 1142 certificate revocation mechanisms, etc. 1144 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1145 contain more discussion. 1147 Interoperability considerations: None 1149 Published specification: This document 1151 Applications which use this media type: Pan-European eCall 1152 compliant systems 1154 Additional information: None 1156 Magic Number: None 1158 File Extension: .xml 1160 Macintosh file type code: 'TEXT' 1162 Person and email address for further information: Randall Gellens, 1163 rg+ietf@randy.pensive.org 1165 Intended usage: LIMITED USE 1167 Author: The IETF ECRIT WG. 1169 Change controller: The IETF ECRIT WG. 1171 14.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1172 Additional Data Blocks registry 1174 This specification requests IANA to add the 'eCall.MSD' entry to the 1175 Emergency Call Additional Data Blocks registry (established by 1176 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1178 14.5. Registration of the 'eCall.control' entry in the Emergency Call 1179 Additional Data Blocks registry 1181 This specification requests IANA to add the 'eCall.control' entry to 1182 the Emergency Call Additional Data Blocks registry (established by 1183 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1185 14.6. Registration of the emergencyCallData.eCall Info Package 1187 IANA is requested to add emergencyCallData.eCall to the Info Packages 1188 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1189 reference to this document. 1191 14.7. URN Sub-Namespace Registration 1193 14.7.1. Registration for urn:ietf:params:xml:ns:eCall 1195 This section registers a new XML namespace, as per the guidelines in 1196 RFC 3688 [RFC3688]. 1198 URI: urn:ietf:params:xml:ns:eCall 1200 Registrant Contact: IETF, ECRIT working group, , as 1201 delegated by the IESG . 1203 XML: 1205 BEGIN 1206 1207 1209 1210 1211 1213 Namespace for eCall Data 1214 1215 1216

Namespace for eCall Data

1217

See [TBD: This document].

1218 1219 1220 END 1222 14.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1224 This section registers a new XML namespace, as per the guidelines in 1225 RFC 3688 [RFC3688]. 1227 URI: urn:ietf:params:xml:ns:eCall:control 1229 Registrant Contact: IETF, ECRIT working group, , as 1230 delegated by the IESG . 1232 XML: 1234 BEGIN 1235 1236 1238 1239 1240 1242 Namespace for eCall Data: 1243 Control Block 1244 1245 1246

Namespace for eCall Data

1247

Control Block

1248

See [TBD: This document].

1249 1250 1251 END 1253 14.8. Registry creation 1255 This document creates a new registry called 'eCall Control Data'. 1256 The following sub-registries are created for this registry. 1258 14.8.1. eCall Control Action Registry 1260 This document creates a new sub-registry called "eCall Control Action 1261 Registry". As defined in [RFC5226], this registry operates under 1262 "Expert Review" rules. The expert should determine that the proposed 1263 action is within the purview of a vehicle, is sufficiently 1264 distinguishable from other actions, and the action is clearly and 1265 fully described. In most cases, a published and stable document is 1266 referenced for the description of the action. 1268 The content of this registry includes: 1270 Name: The identifier to be used in the 'action' attribute of an 1271 eCall control element. 1273 Description: A description of the action. In most cases this will 1274 be a reference to a published and stable document. The 1275 description MUST specify if any attributes or child elements are 1276 optional or mandatory, and describe the action to be taken by the 1277 vehicle. 1279 The initial set of values is listed in Table 2. 1281 +-----------+------------------------------------------+ 1282 | Name | Description | 1283 +-----------+------------------------------------------+ 1284 | send-data | Section Section 8.1.2.1 of this document | 1285 +-----------+------------------------------------------+ 1287 Table 2: eCall Control Action Registry Initial Values 1289 14.8.2. eCall Control Extension Registry 1291 This document creates a new sub-registry called "eCall Control 1292 Extension Registry". This registry contains elements, attributes, 1293 and values for the eCall metadata/control object. As defined in 1294 [RFC5226], this registry operates under "Expert Review" rules. The 1295 expert should determine that the proposed elements, attributes, and/ 1296 or values are within the purview of a vehicle, are sufficiently 1297 distinguishable, and clearly and fully described. In most cases, a 1298 published and stable document is referenced for the description of 1299 each element, attribute, or value. New values MUST indicate for 1300 which attributes or elements they are appropriate. New attributes 1301 MUST indicate in which elements they can appear and to which values 1302 that can be set. New elements MUST indicate if they can appear as 1303 child elements within other elements, and if so which elements, and/ 1304 or if they can appear at the top level of an eCall metadata/control 1305 object. New elements MUST also describe which attributes and/or sub- 1306 elements they can contain and which are optional and which are 1307 mandatory. Note that this mechanism allows new items to be added 1308 while maintaining compatibility with existing implementations, since 1309 unrecognized items are ignored. 1311 The content of this registry includes: 1313 Type: 'Element', 'Attribute', or 'Value'. 1315 Name: The name of the new element or attribute. Not used for new 1316 values. 1318 Description: A description of the element, attribute, or value. In 1319 most cases this will be a reference to a published and stable 1320 document. 1322 15. Contributors 1324 Brian Rosen was a co-author of the original document upon which this 1325 document is based. 1327 16. Acknowledgements 1329 We would like to thank Bob Williams and Ban Al-Bakri for their 1330 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith 1331 Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and 1332 James Winterbottom for their review and comments; Robert Sparks and 1333 Paul Kyzivat for their help with the SIP mechanisms. We would like 1334 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1335 Ulrich Dietz for their help with the original document upon which 1336 this document is based. 1338 17. Changes from Previous Versions 1340 17.1. Changes from draft-ietf-07 to draft-ietf-08 1342 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1343 encoding 1344 o Added text to point out aspects of call handling and metadata/ 1345 control usage, such as use in rejected calls, call-backs, and 1346 solicited MSDs 1347 o Revised use of INFO to require that when a request for an MSD is 1348 sent in INFO, the MSD sent in response is in its own INFO, not the 1349 response to the requesting INFO 1350 o Added material to INFO package registation to comply with 1351 Section 10 of [RFC6086] 1352 o Moved material not required by 3GPP into 1353 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1354 control elements, attributes, and values 1355 o Revised test call wording to clarify that specific handling is out 1356 of scope 1357 o Revised wording throughout the document to simplify 1358 o Moved new Section Section 6.1 to be a subsection of Section 6 1359 o Moved new Section Section 9 to be a main section instead of a 1360 subsection of Section 8 1361 o Revised SIP INFO usage and package registration per advice from 1362 Robert Sparks and Paul Kyzivat 1364 17.2. Changes from draft-ietf-06 to draft-ietf-07 1366 o Fixed typo in Acknowledgements 1368 17.3. Changes from draft-ietf-05 to draft-ietf-06 1370 o Added additional security and privacy clarifications regarding 1371 signed and encrypted data 1372 o Additional security and privacy text 1373 o Deleted informative section on ESINets as unnecessary. 1375 17.4. Changes from draft-ietf-04 to draft-ietf-05 1377 o Reworked the security and privacy considerations material in the 1378 document as a whole and in the MIME registation sections of the 1379 MSD and control objects 1380 o Clarified that the element can appear multiple 1381 times within an element 1382 o Fixed IMS definition 1383 o Added clarifying text for the 'msgid' attribute 1385 17.5. Changes from draft-ietf-03 to draft-ietf-04 1387 o Added Privacy Considerations section 1388 o Reworded most uses of non-normative "may", "should", "must", and 1389 "recommended." 1390 o Fixed nits in examples 1392 17.6. Changes from draft-ietf-02 to draft-ietf-03 1394 o Added request to enable cameras 1395 o Improved examples and XML schema 1396 o Clarifications and wording improvements 1398 17.7. Changes from draft-ietf-01 to draft-ietf-02 1400 o Added clarifying text reinforcing that the data exchange is for 1401 small blocks of data infrequently transmitted 1402 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1403 establish a one-way media stream 1404 o Clarified that the scope is the needs of eCall within the SIP 1405 emergency call environment 1406 o Added informative statement that the document may be suitable for 1407 reuse by other ACN systems 1408 o Clarified that normative language for the control block applies to 1409 both IVS and PSAP 1410 o Removed 'ref', 'supported-mime', and elements 1411 o Minor wording improvements and clarifications 1413 17.8. Changes from draft-ietf-00 to draft-ietf-01 1415 o Added further discussion of test calls 1416 o Added further clarification to the document scope 1417 o Mentioned that multi-region vehicles may need to support other 1418 crash notification specifications in addition to eCall 1419 o Added details of the eCall metadata and control functionality 1420 o Added IANA registration for the MIME content type for the eCall 1421 control object 1423 o Added IANA registries for protocol elements and tokens used in the 1424 eCall control object 1425 o Minor wording improvements and clarifications 1427 17.9. Changes from draft-gellens-03 to draft-ietf-00 1429 o Renamed from draft-gellens- to draft-ietf-. 1430 o Added mention of and reference to ETSI TR "Mobile Standards Group 1431 (MSG); eCall for VoIP" 1432 o Added text to Introduction regarding migration/co-existence being 1433 out of scope 1434 o Added mention in Security Considerations that even if the network- 1435 supplied location is just the cell site, this can be useful as a 1436 sanity check on the IVS-supplied location 1437 o Minor wording improvements and clarifications 1439 17.10. Changes from draft-gellens-02 to -03 1441 o Clarifications and editorial improvements. 1443 17.11. Changes from draft-gellens-01 to -02 1445 o Minor wording improvements 1446 o Removed ".automatic" and ".manual" from 1447 "urn:service:test.sos.ecall" registration and discussion text. 1449 17.12. Changes from draft-gellens-00 to -01 1451 o Now using 'EmergencyCallData' for purpose parameter values and 1452 MIME subtypes, in accordance with changes to 1453 [I-D.ietf-ecrit-additional-data] 1454 o Added reference to RFC 6443 1455 o Fixed bug that caused Figure captions to not appear 1457 18. References 1459 18.1. Normative References 1461 [EN_16072] 1462 CEN, , "Intelligent transport systems - eSafety - Pan- 1463 European eCall operating requirements, EN 16072", April 1464 2015. 1466 [I-D.ietf-ecrit-additional-data] 1467 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1468 J. Winterbottom, "Additional Data Related to an Emergency 1469 Call", draft-ietf-ecrit-additional-data-38 (work in 1470 progress), April 2016. 1472 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1473 minimum set of data (MSD), EN 15722", April 2015. 1475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1476 Requirement Levels", BCP 14, RFC 2119, 1477 DOI 10.17487/RFC2119, March 1997, 1478 . 1480 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1481 DOI 10.17487/RFC3688, January 2004, 1482 . 1484 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1485 Emergency and Other Well-Known Services", RFC 5031, 1486 DOI 10.17487/RFC5031, January 2008, 1487 . 1489 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1490 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1491 DOI 10.17487/RFC5226, May 2008, 1492 . 1494 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1495 "Framework for Emergency Calling Using Internet 1496 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1497 2011, . 1499 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1500 Specifications and Registration Procedures", BCP 13, 1501 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1502 . 1504 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1505 Communications Services in Support of Emergency Calling", 1506 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1507 . 1509 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1510 DOI 10.17487/RFC7303, July 2014, 1511 . 1513 [TS22.101] 1514 3GPP, , "3GPP TS 22.101: Technical Specification Group 1515 Services and System Aspects; Service aspects; Service 1516 principles". 1518 18.2. Informative references 1520 [CEN] "European Committee for Standardization", 1521 . 1523 [I-D.ietf-ecrit-car-crash] 1524 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1525 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1526 ecrit-car-crash-07 (work in progress), February 2016. 1528 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1529 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1530 April 2014. 1532 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1533 Emergency Context Resolution with Internet Technologies", 1534 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1535 . 1537 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1538 Shanmugam, "Security Threats and Requirements for 1539 Emergency Call Marking and Mapping", RFC 5069, 1540 DOI 10.17487/RFC5069, January 2008, 1541 . 1543 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1544 Initiation Protocol (SIP) INFO Method and Package 1545 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1546 . 1548 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1549 Patel, "Public Safety Answering Point (PSAP) Callback", 1550 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1551 . 1553 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1554 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1555 December 2014, . 1557 [SDO-3GPP] 1558 "3d Generation Partnership Project", 1559 . 1561 [SDO-ETSI] 1562 "European Telecommunications Standards Institute (ETSI)", 1563 . 1565 Authors' Addresses 1567 Randall Gellens 1568 Consultant 1569 6755 Mira Mesa Blvd 123-151 1570 San Diego 92121 1571 US 1573 Email: rg+ietf@randy.pensive.org 1575 Hannes Tschofenig 1576 Individual 1578 Email: Hannes.Tschofenig@gmx.net 1579 URI: http://www.tschofenig.priv.at