idnits 2.17.00 (12 Aug 2021) /tmp/idnits44610/draft-ietf-ecrit-ecall-13.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 10 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (September 22, 2016) is 2066 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) ** 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Core Technology Consulting 4 Intended status: Standards Track H. Tschofenig 5 Expires: March 26, 2017 Individual 6 September 22, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-13.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 MIME Content Types and an Emergency Call 22 Additional Data Blocks 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 March 26, 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. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 10 68 9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 12 69 9.1.1. The element . . . . . . . . . . . . . . . . . . 13 70 9.1.1.1. Attributes of the element . . . . . . . . . 13 71 9.1.1.2. Child Element of the element . . . . . . . 13 72 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 73 9.1.2. The element . . . . . . . . . . . . . 15 74 9.1.2.1. Child Elements of the element . . 15 75 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 76 9.1.3. The element . . . . . . . . . . . . . . . . 16 77 9.1.3.1. Attributes of the element . . . . . . . 16 78 9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18 79 10. The emergencyCallData.eCall.MSD INFO package . . . . . . . . 18 80 10.1. Overall Description . . . . . . . . . . . . . . . . . . 18 81 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 19 82 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 19 83 10.4. Info Package Parameters . . . . . . . . . . . . . . . . 19 84 10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 19 85 10.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 20 86 10.7. Info Package Usage Restrictions . . . . . . . . . . . . 20 87 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 20 88 10.9. Info Package Security Considerations . . . . . . . . . . 20 89 10.10. Implementation Details . . . . . . . . . . . . . . . . . 21 90 10.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21 91 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 94 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 15.1. Service URN Registrations . . . . . . . . . . . . . . . 30 97 15.2. MIME Content-type Registration for 98 'application/emergencyCallData.eCall.MSD+per' . . . . . 31 99 15.3. MIME Content-type Registration for 100 'application/emergencyCallData.control+xml' . . . . . . 32 101 15.4. Registration of the 'eCall.MSD' entry in the Emergency 102 Call Additional Data Blocks registry . . . . . . . . . . 33 103 15.5. Registration of the 'control' entry in the Emergency 104 Call Additional Data Blocks registry . . . . . . . . . . 34 105 15.6. Registration of the emergencyCallData.eCall Info Package 34 106 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 107 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 108 15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35 109 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 110 15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 35 111 15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 36 112 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 113 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 114 18. Changes from Previous Versions . . . . . . . . . . . . . . . 37 115 18.1. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 37 116 18.2. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 38 117 18.3. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 38 118 18.4. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 119 18.5. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 120 18.6. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 121 18.7. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 122 18.8. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 123 18.9. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 124 18.10. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 125 18.11. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 126 18.12. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 127 18.13. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40 128 18.14. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40 129 18.15. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41 130 18.16. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41 131 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 132 19.1. Normative References . . . . . . . . . . . . . . . . . . 41 133 19.2. Informative references . . . . . . . . . . . . . . . . . 42 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 136 1. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 This document re-uses terminology defined in Section 3 of [RFC5012]. 144 Additionally, we use the following abbreviations: 146 +--------+----------------------------------------+ 147 | Term | Expansion | 148 +--------+----------------------------------------+ 149 | 3GPP | 3rd Generation Partnership Project | 150 | | | 151 | CEN | European Committee for Standardization | 152 | | | 153 | EENA | European Emergency Number Association | 154 | | | 155 | ESInet | Emergency Services IP network | 156 | | | 157 | IMS | IP Multimedia Subsystem | 158 | | | 159 | IVS | In-Vehicle System | 160 | | | 161 | MNO | Mobile Network Operator | 162 | | | 163 | MSD | Minimum Set of Data | 164 | | | 165 | PSAP | Public Safety Answering Point | 166 +--------+----------------------------------------+ 168 2. Document Scope 170 This document is focused on the signaling, data exchange, and 171 protocol needs of next-generation eCall (NG-eCall, also referred to 172 as packet-switched eCall or all-IP eCall) within the SIP framework 173 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 174 itself is specified by 3GPP and CEN and these specifications include 175 far greater scope than is covered here. 177 The eCall service operates over cellular wireless communication, but 178 this document does not address cellular-specific details, nor client 179 domain selection (e.g., circuit-switched versus packet-switched). 180 All such aspects are the purview of their respective standards 181 bodies. The scope of this document is limited to eCall operating 182 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 184 The technical contents of this document also provide a basis for 185 reuse and extension for other vehicle-initiated emergency call 186 systems. 188 Vehicles designed for multiple regions might need to support eCall 189 and other Advanced Automatic Crash Notification (AACN) systems, such 190 as described in [I-D.ietf-ecrit-car-crash]. 192 3. Introduction 194 Emergency calls made from vehicles (e.g., in the event of a crash) 195 assist in significantly reducing road deaths and injuries by allowing 196 emergency services to be aware of the incident, the state of the 197 vehicle, the location of the vehicle, and to have a voice channel 198 with the vehicle occupants. This enables a quick and appropriate 199 response. 201 The European Commission initiative of eCall was conceived in the late 202 1990s, and has evolved to a European Parliament decision requiring 203 the implementation of a compliant in-vehicle system (IVS) in new 204 vehicles and the deployment of eCall in the European Member States in 205 the very near future. Other regions are developing eCall-compatible 206 systems. 208 The pan-European eCall system provides a standardized and mandated 209 mechanism for emergency calls by vehicles. eCall establishes 210 procedures for such calls to be placed by in-vehicle systems, 211 recognized and processed by the mobile network, and routed to a 212 specialized PSAP where the vehicle data is available to assist the 213 call taker in assessing and responding to the situation. eCall 214 provides a standard set of vehicle, sensor (e.g., crash related), and 215 location data. 217 An eCall can be either user-initiated or automatically triggered. 218 Automatically triggered eCalls indicate a car crash or some other 219 serious incident. Manually triggered eCalls might be reports of 220 witnessed crashes or serious hazards. PSAPs might apply specific 221 operational handling to manual and automatic eCalls. 223 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 224 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 225 call setup mark the call as an eCall, and further indicate if the 226 call was automatically or manually triggered. The call is routed to 227 an eCall-capable PSAP, a voice channel is established between the 228 vehicle and the PSAP, and an eCall in-band modem is used to carry a 229 defined set of vehicle, sensor (e.g., crash related), and location 230 data (the Minimum Set of Data or MSD) within the voice channel. The 231 same in-band mechanism is used for the PSAP to acknowledge successful 232 receipt of the MSD, and to request the vehicle to send a new MSD 233 (e.g., to check if the state of or location of the vehicle or its 234 occupants has changed). NG-eCall moves from circuit switched to all- 235 IP, and carries the vehicle data and eCall signaling as additional 236 data carried with the call. This document describes how IETF 237 mechanisms for IP-based emergency calls, including [RFC6443] and 238 [RFC7852] are used to provide the signaling and data exchange of the 239 next generation of pan-European eCall. 241 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 242 has published a Technical Report titled "Mobile Standards Group 243 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 244 recommendations regarding support for eCall in an all-IP environment. 245 The recommendations include the use of 3GPP IMS emergency calling 246 with additional elements identifying the call as an eCall and as 247 carrying eCall data and with mechanisms for carrying the data and 248 eCall signaling. 3GPP IMS emergency services support multimedia, 249 providing the ability to carry voice, text, and video. This 250 capability is referred to within 3GPP as Multimedia Emergency 251 Services (MMES). 253 A transition period will exist during which time the various entities 254 involved in initiating and handling an eCall might support next- 255 generation eCall, legacy eCall, or both. The issues of migration and 256 co-existence during the transition period are outside the scope of 257 this document. 259 The MSD is carried in the MIME type 'application/ 260 emergencyCallData.eCall.MSD+per' and the metadata/control block is 261 carried in the MIME type 'application/emergencyCallData.control+xml' 262 (both of which are registered in Section 15) An INFO package is 263 defined (in Section 10) to enable these MIME types to be carried in 264 SIP INFO requests, per [RFC6086]. 266 4. eCall Requirements 268 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 269 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 270 data are contained in EN 15722 [msd]. 272 5. Vehicle Data 274 Pan-European eCall provides a standardized and mandated set of 275 vehicle related data, known as the Minimum Set of Data (MSD). The 276 European Committee for Standardization (CEN) has specified this data 277 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 278 circuit-switched eCall and this document use the ASN.1 PER encoding, 279 which is specified in Annex A of EN 15722 [msd] (the XML encoding 280 specified in Annex C is not used in this document). 282 This document registers the 'application/ 283 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 284 to be carried in SIP. As an ASN.1 PER encoded object, the data is 285 binary and transported using binary content transfer encoding within 286 SIP messages. This document also adds the 'eCall.MSD' entry to the 287 Emergency Call Additional Data Blocks registry to enable the MSD to 288 be recognized as such in a SIP-based eCall emergency call. (See 290 [RFC7852] for more information about the registry and how it is 291 used.) 293 See Section 6 for a discussion of how the MSD vehicle data is 294 conveyed in an NG-eCall. 296 6. Data Transport 298 [RFC7852] establishes a general mechanism for attaching blocks of 299 data to a SIP emergency call. This mechanism permits certain 300 emergency call MIME types to be attached to SIP messages. This 301 document makes use of that mechanism. This document also registers 302 an INFO package (in Section 10) to enable eCall related data blocks 303 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 304 require the definition of an INFO package). 306 Note that if other data sets need to be transmitted in the future, 307 the appropriate signalling mechanism for such data needs to be 308 evaluated, including factors such as the size and frequency of such 309 data. 311 An In-Vehicle System (IVS) transmits the MSD (see Section 5) by 312 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 313 message as a MIME body part per [RFC7852]. The body part is 314 identified by its MIME content-type ('application/ 315 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 316 the body part. The body part is assigned a unique identifier which 317 is listed in a Content-ID header field in the body part. The SIP 318 message is marked as containing the MSD by adding (or appending to) a 319 Call-Info header field at the top level of the SIP message. This 320 Call-Info header field contains a CID URL referencing the body part's 321 unique identifier, and a 'purpose' parameter identifying the data as 322 the eCall MSD per the Emergency Call Additional Data Blocks registry 323 entry; the 'purpose' parameter's value is 324 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 325 SIP INFO request by using the INFO package defined in Section 10. 327 A PSAP or IVS transmits a metadata/control object (see Section 9) by 328 encoding it per the description in this document and attaching it to 329 a SIP message as a MIME body part per [RFC7852]. The body part is 330 identified by its MIME content-type ('application/ 331 emergencyCallData.control+xml') in the Content-Type header field of 332 the body part. The body part is assigned a unique identifier which 333 is listed in a Content-ID header field in the body part. The SIP 334 message is marked as containing the metadata/control object by adding 335 (or appending to) a Call-Info header field at the top level of the 336 SIP message. This Call-Info header field contains a CID URL 337 referencing the body part's unique identifier, and a 'purpose' 338 parameter identifying the data as an eCall metadata/control block per 339 the Emergency Call Additional Data Blocks registry entry; the 340 'purpose' parameter's value is 'emergencyCallData.control'. Per 341 [RFC6086], a metadata/control object is carried in a SIP INFO request 342 by using the INFO package defined in Section 10. 344 As is necessary with message bodies, if an MSD or a metadata/control 345 block is sent in the same message with another body part, a 346 multipart/mixed body part encloses all body parts. In some cases, 347 there are intermediate multipart body parts between the top level 348 multipart/mixed and the body part containing the MSD or metadata/ 349 control object. 351 A body part containing an MSD or metadata/control object has a 352 Content-Disposition header field value containing "By-Reference" 353 unless it is the only body part in a SIP INFO request, in which case, 354 per [RFC6086], "INFO-Package" is used. 356 An In-Vehicle System (IVS) initiating an NG-eCall attaches the MSD to 357 the initial INVITE and optionally attaches a metadata/control object 358 informing the PSAP of its capabilities. The MSD body part (and 359 metadata/control and PIDF-LO body parts if included) have a Content- 360 Disposition header field with the value "By-Reference; 361 handling=optional". Specifying handling=optional prevents the INVITE 362 from being rejected if it is processed by a legacy element (e.g., a 363 gateway between SIP and circuit-switched environments) that does not 364 understand the MSD (or metadata/control object or PIDF-LO). The PSAP 365 creates a metadata/control object acknowledging receipt of the MSD 366 and attaches it to the SIP final response to the INVITE. The 367 metadata/control object is not attached to provisional (e.g., 180) 368 responses. 370 If the IVS receives an acknowledgment for an MSD with received=false, 371 it indicates some fault with the transfer of the MSD, the MSD 372 content, or the PSAP's ability to properly receive, decode and act on 373 the MSD. The IVS action is not defined (e.g., it might only log an 374 error). Since the PSAP is able to request an updated MSD during the 375 call, if an initial MSD is unsatisfactory in any way, the PSAP can 376 choose to request another one. 378 A PSAP can request that the vehicle send an updated MSD during a 379 call. To do so, the PSAP creates a metadata/control object 380 requesting an MSD and attaches it to a SIP INFO request and sends it 381 within the dialog. The IVS then attaches an updated MSD to a SIP 382 INFO request and sends it within the dialog. If the IVS is unable to 383 send an MSD, it instead sends a metadata/control object acknowledging 384 the request with the 'success' parameter set to 'false' and a 385 'reason' parameter (and optionally a 'details' parameter) indicating 386 why the request cannot be accomplished. Per [RFC6086], metadata/ 387 control objects and MSDs are sent using the INFO package defined in 388 Section 10 . In addition, to align with how an MSD or metadata/ 389 control block is transmitted in a SIP message other than an INFO 390 request, one or more Call-Info header fields are included in the SIP 391 INFO request to reference the MSD or metadata/control block. See 392 Section 10 for information about the use of INFO requests to carry 393 data within an eCall. 395 The IVS is not expected to send an unsolicited MSD during the call. 397 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 398 conformance with this document. 400 7. Call Setup 402 In circuit-switched eCall, the IVS places a special form of a 112 403 emergency call which carries an eCall flag (indicating that the call 404 is an eCall and also if the call was manually or automatically 405 triggered); the mobile network operator (MNO) recognizes the eCall 406 flag and routes the call to an eCall-capable PSAP; vehicle data is 407 transmitted to the PSAP via the eCall in-band modem (in the voice 408 channel). 410 ///----\\\ 112 voice call with eCall flag +------+ 411 ||| IVS |||---------------------------------------->+ PSAP | 412 \\\----/// vehicle data via eCall in-band modem +------+ 414 Figure 1: circuit-switched eCall 416 For NG-eCall, the IVS establishes an emergency call using a Request- 417 URI indicating a manual or automatic eCall; the MNO (or ESInet) 418 recognizes the eCall URN and routes the call to an NG-eCall capable 419 PSAP; the PSAP interpets the vehicle data sent with the call and 420 makes it available to the call taker. 422 ///----\\\ IMS emergency call with eCall URN +------+ 423 IVS ----------------------------------------->+ PSAP | 424 \\\----/// vehicle data included in call setup +------+ 426 Figure 2: NG-eCall 428 See Section 6 for information on how the MSD is transported within an 429 NG-eCall. 431 This document registers new service URN children within the "sos" 432 subservice. These URNs provide the mechanism by which an eCall is 433 identified, and differentiate between manually and automatically 434 triggered eCalls (which might be subject to different treatment, 435 depending on policy). The two service URNs are: 436 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 437 which requests resources associated with an emergency call placed by 438 an in-vehicle system, carrying a standardized set of data related to 439 the vehicle and incident. 441 Call routing is outside the scope of this document. 443 8. Test Calls 445 eCall requires the ability to place test calls (see [TS22.101] clause 446 10.7 and [EN_16062] clause 7.2.2). These are calls that are 447 recognized and treated to some extent as eCalls but are not given 448 emergency call treatment and are not handled by call takers. The 449 specific handling of test eCalls is not itself standardized; 450 typically, the test call facility allows the IVS or user to verify 451 that an eCall can be successfully established with voice 452 communication. The IVS might also be able to verify that the MSD was 453 successfully received. 455 A service URN starting with "test." indicates a test call. For 456 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 457 This functionality is defined in [RFC6881]. 459 This document registers "urn:service:test.sos.ecall" for eCall test 460 calls. 462 The CS-eCall test call facility is a non-emergency number so does not 463 get treated as an emergency call. For NG-eCall, MNOs, emergency 464 authorities, and PSAPs can determine how to treat a vehicle call 465 requesting the "test" service URN so that the desired functionality 466 is tested, but this is outside the scope of this document. 468 9. The Metadata/Control Object 470 eCall requires the ability for the PSAP to acknowledge successful 471 receipt of an MSD sent by the IVS, and for the PSAP to request that 472 the IVS send an MSD (e.g., the call taker can initiate a request for 473 a new MSD to see if there have been changes in the vehicle's state, 474 e.g., location, direction, number of fastened seatbelts). 476 This document defines a block of metadata/control data as an XML 477 structure containing elements used for eCall and other vehicle- 478 initiated emergency call systems (i.e., in other regions) and 479 extension points. (This metadata/control block is in effect a high- 480 level protocol between the PSAP and IVS.) When the PSAP sends an 481 eCall metadata/control block in response to data sent by the IVS in a 482 SIP request other than INFO (e.g., the MSD in the initial INVITE), 483 the metadata/control block is sent in the SIP response to that 484 request (e.g., the response to the INVITE request). When the PSAP 485 sends a control block in other circumstances (e.g., mid-call), the 486 control block is transmitted from the PSAP to the IVS in a SIP INFO 487 request within the established dialog. The IVS sends the requested 488 data (the MSD) in a new INFO request (per [RFC6086]). This mechanism 489 flexibly allows the PSAP to send eCall-specific data to the IVS and 490 the IVS to respond. INFO requests are sent using an appropriate INFO 491 Package. See Section 6 for more information on attaching a metadata/ 492 control block to a SIP message. See Section 10 for information about 493 the use of INFO requests to carry data within an eCall. 495 This mechanism requires 497 o An XML definition of the control object 498 o Extension points for use by eCall-like systems in other regions 499 o A MIME type registration for the control object (so it can be 500 carried in SIP messages and responses) 501 o An entry in the Emergency Call Additional Data Blocks registry so 502 that the control block can be recognized as emergency call 503 specific data within SIP messages 504 o An Info-Package registration per [RFC6086] permitting the 505 metadata/control block and the MSD within INFO requests 507 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 508 initial INVITE), the PSAP sends a metadata/control block indicating 509 successful/unsuccessful receipt of the MSD in the SIP response to the 510 request. This also informs the IVS that an NG-eCall is in operation. 511 If the IVS receives a SIP response without the metadata/control 512 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 513 some part of the call is being handled as a legacy call). When the 514 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 515 receipt of a SIP INFO request containing a metadata/control block 516 requesting an MSD), the PSAP does not send a metadata/control block 517 indicating successful or unsuccessful receipt of the MSD. (Normal 518 SIP retransmission handles non-receipt of requested data; if the IVS 519 sends a requested MSD in an INFO request and does not receive a SIP 520 status message for the INFO request, it resends it; if the PSAP 521 requests an MSD and does not receive a SIP status message for the 522 INFO request, it resends it.) If the IVS receives a request to send 523 an MSD but it is unable to do so for any reason, the IVS sends a 524 metadata/control object acknowledging the request and containing 525 "success=false" and "reason" set to an appropriate code. 527 This provides flexibility to handle various circumstances. For 528 example, if a PSAP is unable to accept an eCall (e.g., due to 529 overload or too many calls from the same location), it can reject the 530 INVITE. Since a metadata/control object is also included in the SIP 531 response that rejects the call, the IVS knows if the PSAP received 532 the MSD, and can inform the vehicle occupants that the PSAP 533 successfully received the vehicle location and information but can't 534 talk to the occupants at that time. Especially for SIP response 535 codes that indicate an inability to conduct a call (as opposed to a 536 technical inability to process the request), the IVS can also 537 determine that the call was successful on a technical level (e.g., 538 not helpful to retry as a CS-eCall). The SIP response codes 600 539 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when 540 the PSAP wants to reject a call but inform the vehicle occupants that 541 it is aware of the situation. (Note that there could be edge cases 542 where the PSAP response is not received by the IVS, e.g., if an 543 intermediary sends a CANCEL, and an error response is forwarded 544 towards the IVS before the error response from the PSAP is received, 545 the response will be dropped, but these are unlikely to occur here.) 547 The metadata/control block is carried in the MIME type 'application/ 548 emergencyCallData.control+xml'. 550 The metadata/control block is designed for use with pan-European 551 eCall and also eCall-like systems (i.e., in other regions), and has 552 extension points to accomodate variances. Note that eCall-like 553 systems might define their own vehicle data blocks, and so might need 554 to register a new INFO package to accomodate the new data content 555 type and the metadata/control object. 557 9.1. The Control Block 559 The control block is an XML data structure allowing for 560 acknowledgments, requests, and capabilities information. It is 561 carried in a body part with a specific MIME content type. Three 562 elements are defined for use within a control block: 564 ack Acknowledges receipt of data or a request. 566 capabilities: Used in a control block sent from the IVS to the PSAP 567 (e.g., in the initial INVITE) to inform the PSAP of the 568 vehicle capabilities. Child elements contain all 569 actions and data types supported by the vehicle. It is 570 OPTIONAL for the IVS to send this block. Omitting the 571 block indicates that the IVS supports only the 572 mandatory functionality defined in this document. 574 request Used in a control block sent by the PSAP to the IVS, to 575 request the vehicle to perform an action. 577 The element indicates the object being acknowledged and reports 578 success or failure. 580 The element contains attributes to indicate the request and 581 to supply related information. The 'action' attribute is mandatory 582 and indicates the specific action. An IANA registry is created in 583 Section 15.8.1 to contain the allowed values. 585 The element has child elements to indicate 586 the actions supported by the IVS. 588 9.1.1. The element 590 The element acknowledges receipt of an eCall data object or 591 request. An element references the unique ID of the data 592 object being acknowledged. The PSAP MUST send an element 593 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 594 the INVITE); this element indicates if the PSAP considers the 595 MSD successfully received or not. An element is not sent for a 596 element. 598 The element has the following attributes: 600 9.1.1.1. Attributes of the element 602 The element has the following attributes: 604 Name: ref 605 Usage: Mandatory 606 Type: anyURI 607 Direction: In this document, sent from the PSAP to the IVS 608 Description: References the Content-ID of the body part being 609 acknowledged. 610 Example: 612 Name: received 613 Usage: Conditional: mandatory in an >ack< element sent by a PSAP 614 Type: Boolean 615 Direction: In this document, sent from the PSAP to the IVS 616 Description: Indicates if the referenced object was considered 617 successfully received or not. 618 Example: 620 9.1.1.2. Child Element of the element 622 For extensibility, the element has the following child element: 624 Name: actionResult 625 Usage: Optional 626 Direction: Provided for extension, sent from the IVS to the PSAP 627 Description: An element indicates the result of an 628 action (other than a 'send-data' action). When an element 629 is in response to a control object with multiple 630 elements, the element contains an element for 631 each element that is not a 'send-data' action. The 632 element has the following attributes: 634 Name: action 635 Usage: Mandatory 636 Type: token 637 Direction: In this document, sent from the PSAP to the IVS 638 Description: Contains the value of the 'action' attribute of the 639 element 641 Name: success 642 Usage: Mandatory 643 Type: Boolean 644 Direction: Sent from the IVS to the PSAP 645 Description: Indicates if the action was successfully 646 accomplished 648 Name: reason 649 Usage: Conditional 650 Type: token 651 Direction: Sent from the IVS to the PSAP 652 Description: Used when 'success' is "false", this attribute 653 contains a reason code for a failure. A registry for reason 654 codes is defined in Section 15.8.2. 656 Name: details 657 Usage: optional 658 Type: string 659 Direction: Sent from the IVS to the PSAP 660 Description: Contains further explanation of the circumstances of 661 a success or failure. The contents are implementation-specific 662 and human-readable. 664 9.1.1.3. Ack Examples 665 666 672 674 676 Figure 3: Ack Example from PSAP to IVS 678 9.1.2. The element 680 The element is transmitted by the IVS to indicate to 681 the PSAP its capabilities. No attributes for this element are 682 currently defined. The following child elements are defined: 684 9.1.2.1. Child Elements of the element 686 The element has the following child elements: 688 Name: request 689 Usage: Mandatory 690 Description: The element contains a child 691 element per action supported by the vehicle. 693 Examples: 694 696 It is OPTIONAL for the IVS to support the element. If 697 the IVS does not send a element, this indicates that 698 the only action supported by the IVS is 'send-data' with 699 'datatype' set to 'eCall.MSD'. 701 9.1.2.2. Capabilities Example 702 703 708 709 710 712 714 Figure 4: Capabilities Example 716 9.1.3. The element 718 A element appears one or more times on its own or as a 719 child of a element. It allows the PSAP to request 720 that the IVS perform an action. The only action that MUST be 721 supported is to send an MSD. The following attributes and child 722 elements are defined: 724 9.1.3.1. Attributes of the element 726 The element has the following attributes: 728 Name: action 729 Usage: Mandatory 730 Type: token 731 Direction: In this document, sent from the PSAP to the IVS; for 732 extension, sent from the IVS to the PSAP 733 Description: Identifies the action that the vehicle is requested to 734 perform. An IANA registry is established in Section 15.8.1 to 735 contain the allowed values. 736 Example: action="send-data" 738 Name: msgid 739 Usage: Conditional 740 Type: int 741 Direction: Sent from the PSAP to the IVS 742 Description: Defined for extensibility. 743 Example: msgid="3" 745 Name: persistance 746 Usage: Optional 747 Type: duration 748 Direction: Sent from the PSAP to the IVS 749 Description: Defined for extensibility. Specifies how long to carry 750 on the specified action. If absent, the default is for the 751 duration of the call. 752 Example: persistance="PT1H" 754 Name: datatype 755 Usage: Conditional 756 Type: token 757 Direction: In this document, sent from the PSAP to the IVS; as an 758 extension, sent from the IVS to the PSAP 759 Description: Mandatory with a "send-data" action within a 760 element that is not within a element. Specifies 761 the data block that the IVS is requested to transmit, using the 762 same identifier as in the 'purpose' attribute set in a Call-Info 763 header field to point to the data block. Permitted values are 764 contained in the 'Emergency Call Data Types' IANA registry 765 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 766 to support. 767 Example: datatype="eCall.MSD" 769 Name: supported-values 770 Usage: Conditional 771 Type: string 772 Direction: Sent from the IVS to the PSAP 773 Description: Defined for extensibility. Used in a element 774 that is a child of a element, this attribute lists 775 all supported values of the action type. Permitted values depend 776 on the action value. Multiple values are separated with a 777 semicolon. 779 Name: requested-state 780 Usage: Conditional 781 Type: token 782 Direction: Sent from the PSAP to the IVS 783 Description: Defined for extension. Indicates the requested state 784 of an element associated with the request type. Permitted values 785 depend on the request type. 787 Name: element-ID 788 Usage: Conditional 789 Type: token 790 Direction: Sent from the PSAP to the IVS 791 Description: Defined for extension. Identifies the element to be 792 acted on. Permitted values depend on the request type. 794 9.1.3.2. Request Example 796 797 803 805 807 Figure 5: Request Example 809 10. The emergencyCallData.eCall.MSD INFO package 811 This document registers the 'emergencyCallData.eCall.MSD' INFO 812 package. 814 Both endpoints (the IVS and the PSAP equipment) include 815 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 816 [RFC6086] to indicate ability to receive INFO requests carrying data 817 as described here. 819 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 820 the ability to receive eCall related body parts as specified in [TBD: 821 THIS DOCUMENT]. 823 An INFO request message carrying body parts related to an emergency 824 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 825 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 827 The requirements of Section 10 of [RFC6086] are addressed in the 828 following sections. 830 10.1. Overall Description 832 This section describes "what type of information is carried in INFO 833 requests associated with the Info Package, and for what types of 834 applications and functionalities UAs can use the Info Package." 836 INFO requests associated with the emergencyCallData.eCall.MSD INFO 837 package carry data associated with emergency calls as defined in 838 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 839 calls established using SIP. The functionality is to carry vehicle 840 data and metadata/control information between vehicles and PSAPs. 841 Refer to [TBD: THIS DOCUMENT] for more information. 843 10.2. Applicability 845 This section describes "why the Info Package mechanism, rather than 846 some other mechanism, has been chosen for the specific use-case...." 848 The use of INFO is based on an analysis of the requirements against 849 the intent and effects of INFO versus other approaches (which 850 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 851 transport, and non-SIP protocols). In particular, the transport of 852 emergency call data blocks occurs within a SIP emergency dialog, per 853 Section 6, and is normally carried in the initial INVITE and its 854 response; the use of INFO only occurs when emergency-call-related 855 data needs to be sent mid-call. While MESSAGE could be used, it is 856 not tied to a SIP dialog as is INFO and thus might not be associated 857 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 858 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 859 service, but the semantics are not a good fit, e.g., the subscribe/ 860 notify mechanism provides one-way communication consisting of (often 861 multiple) notifications from notifier to subscriber indicating that 862 certain events in notifier have occurred, whereas what's needed here 863 is two-way communication of data related to the emergency dialog. 864 Use of the media plane mechanisms was discounted because the number 865 of messages needing to be exchanged in a dialog is normally zero or 866 very few, and the size of the data is likewise very small. The 867 overhead caused by user plane setup (e.g., to use MSRP as transport) 868 would be disproportionately large. 870 Based on the the analyses, the SIP INFO method was chosen to provide 871 for mid-call data transport. 873 10.3. Info Package Name 875 The info package name is emergencyCallData.eCall.MSD 877 10.4. Info Package Parameters 879 None 881 10.5. SIP Option-Tags 883 None 885 10.6. INFO Request Body Parts 887 The body for an emergencyCallData.eCall.MSD info package is: 889 o an application/emergencyCallData.eCall.MSD+per (containing an 890 MSD), or 892 o an application/emergencyCallData.control+xml (containing a 893 metadata/control object), or 895 o a multipart body containing: 897 * zero or one application/emergencyCallData.eCall.MSD+per part 898 (containing an MSD), 900 * zero or more application/emergencyCallData.control+xml 901 (containing a metadata/control object), 903 The body parts are sent per [RFC6086], and in addition, to align with 904 with how these body parts are sent in SIP messages other than INFO 905 requests, each associated body part is referenced by a Call-Info 906 header field at the top level of the SIP message. If the body part 907 is the only body part, it has a Content-Disposition header field 908 value of "INFO-Package". If the body part is contained within a 909 multipart, it has a Content-Disposition header field value of "By- 910 Reference". 912 See [TBD: THIS DOCUMENT] for more information. 914 10.7. Info Package Usage Restrictions 916 Usage is limited to vehicle-initiated emergency calls as defined in 917 [TBD: THIS DOCUMENT]. 919 10.8. Rate of INFO Requests 921 The rate of SIP INFO requests associated with the 922 emergencyCallData.eCall.MSD info package is normally quite low (most 923 dialogs are likely to contain zero INFO requests, while others can be 924 expected to carry an occasional request). 926 10.9. Info Package Security Considerations 928 The MIME content type registations for the data blocks that can be 929 carried using this INFO package contains a discussion of the security 930 and/or privacy considerations specific to that data block. The 931 "Security Considerations" and "Privacy Considerations" sections of 933 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 934 the data carried in eCalls. 936 10.10. Implementation Details 938 See [TBD: THIS DOCUMENT] for protocol details. 940 10.11. Examples 942 See [TBD: THIS DOCUMENT] for protocol examples. 944 11. Examples 946 Figure 6 illustrates an eCall. The call uses the request URI 947 'urn:service:sos.ecall.automatic' service URN and is recognized as an 948 eCall, and further as one that was invoked automatically by the IVS 949 due to a crash or other serious incident. In this example, the 950 originating network routes the call to an ESInet which routes the 951 call to the appropriate NG-eCall capable PSAP. The emergency call is 952 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 953 the entry point into the ESInet. The ESRP routes the call to a PSAP, 954 where it is received by a call taker. In deployments where there is 955 no ESInet, the originating network routes the call directly to the 956 appropriate NG-eCall capable PSAP, an illustration of which would be 957 identical to the one below except without an ESInet or ESRP. 959 +------------+ +---------------------------------------+ 960 | | | +-------+ | 961 | | | | PSAP2 | | 962 | | | +-------+ | 963 | | | | 964 | | | +------+ +-------+ | 965 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 966 | | | +------+ +-------+ | 967 | | | | 968 | | | +-------+ | 969 | | | | PSAP3 | | 970 | Originating| | +-------+ | 971 | Mobile | | | 972 | Network | | ESInet | 973 +------------+ +---------------------------------------+ 975 Figure 6: Example of NG-eCall Message Flow 977 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 978 for an updated MSD. The call flow shows the IVS initiating an 979 emergency call, including the MSD in the INVITE. The PSAP includes 980 in the 200 OK response a metadata/control object acknowledging 981 receipt of the MSD. During the call, the PSAP sends a request for an 982 MSD in an INFO request. The IVS sends the requested MSD in a new 983 INFO request. 985 IVS PSAP 986 |(1) INVITE (eCall MSD) | 987 |------------------------------------------->| 988 | | 989 |(2) 200 OK (eCall metadata [ack MSD]) | 990 |<-------------------------------------------| 991 | | 992 |(3) start media stream(s) | 993 |............................................| 994 | | 995 |(4) INFO (eCall metadata [request MSD]) | 996 |<-------------------------------------------| 997 | | 998 |(5) 200 OK | 999 |------------------------------------------->| 1000 | | 1001 |(6) INFO (eCall MSD) | 1002 |------------------------------------------->| 1003 | | 1004 |(7) 200 OK | 1005 |<-------------------------------------------| 1006 | | 1007 |(8) BYE | 1008 |<-------------------------------------------| 1009 | | 1010 |(9) end media streams | 1011 |............................................| 1012 | | 1013 |(10) 200 OK | 1014 |------------------------------------------->| 1016 Figure 7: NG-eCall Call Flow Illustration 1018 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1019 contains an MSD. For simplicity, the example does not show all SIP 1020 headers, nor the SDP contents, nor does it show any additional data 1021 blocks added by the IVS or the originating mobile network. Because 1022 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1023 contents cannot be included in a text document. 1025 INVITE urn:service:sos.ecall.automatic SIP/2.0 1026 To: urn:service:sos.ecall.automatic 1027 From: ;tag=9fxced76sl 1028 Call-ID: 3848276298220188511@atlanta.example.com 1029 Geolocation: 1030 Geolocation-Routing: no 1031 Call-Info: ; 1032 purpose=emergencyCallData.eCall.MSD 1033 Accept: application/sdp, application/pidf+xml, 1034 application/emergencyCallData.control+xml 1035 CSeq: 31862 INVITE 1036 Recv-Info: emergencyCallData.eCall.MSD 1037 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1038 SUBSCRIBE, NOTIFY, UPDATE 1039 Content-Type: multipart/mixed; boundary=boundary1 1040 Content-Length: ... 1042 --boundary1 1043 Content-Type: application/sdp 1045 ...Session Description Protocol (SDP) goes here... 1047 --boundary1 1048 Content-Type: application/emergencyCallData.eCall.MSD+per 1049 Content-ID: <1234567890@atlanta.example.com> 1050 Content-Disposition: by-reference;handling=optional 1052 ...MSD in ASN.1 PER encoding goes here... 1054 --boundary1-- 1056 Figure 8: SIP NG-eCall INVITE 1058 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1059 the INVITE of Figure 8, containing a control block acknowledging 1060 successful receipt of the eCall MSD. (For simplicity, the example 1061 does not show all SIP headers.) 1062 SIP/2.0 200 OK 1063 To: ;tag=9fxced76sl 1064 From: Exemplar PSAP 1065 Call-ID: 3848276298220188511@atlanta.example.com 1066 Call-Info: ; 1067 purpose=emergencyCallData.control 1068 Accept: application/sdp, application/pidf+xml, 1069 application/emergencyCallData.control+xml, 1070 application/emergencyCallData.eCall.MSD+per 1071 CSeq: 31862 INVITE 1072 Recv-Info: emergencyCallData.eCall.MSD 1073 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1074 SUBSCRIBE, NOTIFY, UPDATE 1075 Content-Type: multipart/mixed; boundary=boundaryX 1076 Content-Length: ... 1078 --boundaryX 1079 Content-Type: application/sdp 1081 ...Session Description Protocol (SDP) goes here... 1083 --boundaryX 1084 Content-Type: application/emergencyCallData.control+xml 1085 Content-ID: <2345678901@atlanta.example.com> 1086 Content-Disposition: by-reference 1088 1089 1095 1097 1099 --boundaryX-- 1101 Figure 9: 200 OK response to INVITE 1103 Figure 10 illustrates an INFO request containing an eCall metadata/ 1104 control block requesting an eCall MSD. (For simplicity, the example 1105 does not show all SIP headers.) 1106 INFO sip:+13145551111@example.com SIP/2.0 1107 To: ;tag=9fxced76sl 1108 From: Exemplar PSAP 1109 Call-ID: 3848276298220188511@atlanta.example.com 1110 Call-Info: ; 1111 purpose=emergencyCallData.control 1112 Accept: application/sdp, application/pidf+xml, 1113 application/emergencyCallData.control+xml, 1114 application/emergencyCallData.eCall.MSD+per 1115 CSeq: 41862 INFO 1116 Info-Package: emergencyCallData.eCall.MSD 1117 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1118 SUBSCRIBE, NOTIFY, UPDATE 1119 Content-Disposition: info-package 1120 Content-Type: application/emergencyCallData.control+xml 1121 Content-ID: <3456789012@atlanta.example.com> 1123 1124 1130 1132 1134 Figure 10: INFO requesting MSD 1136 Figure 11 illustrates a SIP eCall INFO that contains an MSD. For 1137 simplicity, the example does not show all SIP headers. Because the 1138 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1139 cannot be included in a text document. 1141 INFO urn:service:sos.ecall.automatic SIP/2.0 1142 To: urn:service:sos.ecall.automatic 1143 From: ;tag=9fxced76sl 1144 Call-ID: 3848276298220188511@atlanta.example.com 1145 Call-Info: ; 1146 purpose=emergencyCallData.eCall.MSD 1147 Accept: application/sdp, application/pidf+xml, 1148 application/emergencyCallData.control+xml 1149 CSeq: 51862 INFO 1150 Info-Package: emergencyCallData.eCall.MSD 1151 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1152 SUBSCRIBE, NOTIFY, UPDATE 1153 Content-Type: application/emergencyCallData.eCall.MSD+per 1154 Content-ID: <4567890123@atlanta.example.com> 1155 Content-Disposition: info-package 1157 ...MSD in ASN.1 PER encoding goes here... 1159 Figure 11: INFO containing MSD 1161 12. Security Considerations 1163 The security considerations described in [RFC5069] apply here. 1165 In addition to any network-provided location (which might be 1166 determined solely by the network, or in cooperation with or possibly 1167 entirely by the originating device), an eCall carries an IVS-supplied 1168 location within the MSD. This is likely to be useful to the PSAP, 1169 especially when no network-provided location is included, or when the 1170 two locations are independently determined. Even in situations where 1171 the network-supplied location is limited to the cell site, this can 1172 be useful as a sanity check on the device-supplied location contained 1173 in the MSD. 1175 The document [RFC7378] discusses trust issues regarding location 1176 provided by or determined in cooperation with end devices. 1178 Security considerations specific to the mechanism by which the PSAP 1179 sends acknowledgments and requests to the vehicle are discussed in 1180 the "Security Considerations" block of Section 15.3. 1182 Data received from external sources inherently carries implementation 1183 risks. For example, depending on the platform, buffer overflows can 1184 introduce remote code execution vulnerabilities, null characters can 1185 corrupt strings, numeric values used for internal calculations can 1186 result in underflow/overflow errors, malformed XML objects can expose 1187 parsing bugs, etc. Implementations need to be cognizant of the 1188 potential risks, observe best practices (which might include 1189 sufficiently capable static code analysis, fuzz testing, component 1190 isolation, avoiding use of unsafe coding techniques, third-party 1191 attack tests, signed software, over-the-air updates, etc.), and have 1192 multiple levels of protection. Implementors need to be aware that, 1193 potentially, the data objects described here and elsewhere might be 1194 malformed, might contain unexpected characters, excessively long 1195 attribute values, elements, etc. 1197 The security considerations discussed in [RFC7852] apply here (see 1198 especially the discussion of TLS, TLS versions, cypher suites, and 1199 PKI). 1201 When vehicle data or control/metadata is contained in a signed or 1202 encrypted body part, the enclosing multipart (e.g., multipart/signed 1203 or multipart/encrypted) has the same Content-ID as the enclosed data 1204 part. This allows an entity to identify and access the data blocks 1205 it is interested in without having to dive deeply into the message 1206 structure or decrypt parts it is not interested in. (The 'purpose' 1207 parameter in a Call-Info header field identifies the data and 1208 contains a CID URL pointing to the data block in the body, which has 1209 a matching Content-ID body part header field). 1211 13. Privacy Considerations 1213 The privacy considerations discussed in [RFC7852] apply here. The 1214 MSD carries some identifying and personal information (mostly about 1215 the vehicle and less about the owner), as well as location 1216 information, and so needs to be protected against unauthorized 1217 disclosure. Local regulations may impose additional privacy 1218 protection requirements. 1220 Privacy considerations specific to the data structure containing 1221 vehicle information are discussed in the "Security Considerations" 1222 block of Section 15.2. 1224 Privacy considerations specific to the mechanism by which the PSAP 1225 sends acknowledgments and requests to the vehicle are discussed in 1226 the "Security Considerations" block of Section 15.3. 1228 14. XML Schema 1230 This section defines an XML schema for the control block. The text 1231 description of the control block in Section 9.1 is normative and 1232 supersedes any conflicting aspect of this schema. 1234 1235 1237 1245 1248 1251 1252 1253 1254 1255 1257 1258 1259 1262 1263 1264 1265 1266 1268 1269 1270 1271 1272 1274 1275 1278 1281 1284 1285 conditionally 1286 mandatory when @success='false" 1287 to indicate reason code for a 1288 failure 1289 1290 1291 1293 1294 1295 1296 1299 1300 1303 1305 1306 1307 1308 1310 1311 1312 1313 1314 1318 1321 1322 1323 1324 1325 1327 1328 1329 1330 1331 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1347 1349 Figure 12: Control Block Schema 1351 15. IANA Considerations 1353 15.1. Service URN Registrations 1355 IANA is requested to register the URN 'urn:service:sos.ecall' under 1356 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1358 This service requests resources associated with an emergency call 1359 placed by an in-vehicle system, carrying a standardized set of data 1360 related to the vehicle and incident. Two sub-services are registered 1361 as well: 1363 urn:service:sos.ecall.manual 1365 Used with an eCall invoked due to manual interaction by a vehicle 1366 occupant. 1368 urn:service:sos.ecall.automatic 1370 Used with an eCall invoked automatically, for example, due to a 1371 crash or other serious incident. 1373 IANA is also requested to register the URN 1374 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1375 defined in Setcion 17.2 of [RFC6881]. 1377 15.2. MIME Content-type Registration for 'application/ 1378 emergencyCallData.eCall.MSD+per' 1380 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1381 as a MIME content type, with a reference to this document, in 1382 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1383 RFC 7303 [RFC7303]. 1385 MIME media type name: application 1387 MIME subtype name: emergencyCallData.eCall.MSD+per 1389 Mandatory parameters: none 1391 Optional parameters: none 1393 Encoding scheme: binary 1395 Encoding considerations: Uses ASN.1 PER, which is a binary 1396 encoding; when transported in SIP, binary content transfer 1397 encoding is used. 1399 Security considerations: This content type is designed to carry 1400 vehicle and incident-related data during an emergency call. This 1401 data contains personal information including vehicle VIN, 1402 location, direction, etc. Appropriate precautions need to be 1403 taken to limit unauthorized access, inappropriate disclosure to 1404 third parties, and eavesdropping of this information. In general, 1405 it is acceptable for the data to be unprotected while briefly in 1406 transit within the Mobile Network Operator (MNO); the MNO is 1407 trusted to not permit the data to be accessed by third parties. 1408 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1410 Interoperability considerations: None 1412 Published specification: Annex A of EN 15722 [msd] 1414 Applications which use this media type: Pan-European eCall 1415 compliant systems 1417 Additional information: None 1419 Magic Number: None 1421 File Extension: None 1423 Macintosh file type code: 'BINA' 1424 Person and email address for further information: Randall Gellens, 1425 rg+ietf@randy.pensive.org 1427 Intended usage: LIMITED USE 1429 Author: The MSD specification was produced by the European 1430 Committee For Standardization (CEN). For contact information, 1431 please see . 1433 Change controller: The European Committee For Standardization 1434 (CEN) 1436 15.3. MIME Content-type Registration for 'application/ 1437 emergencyCallData.control+xml' 1439 IANA is requested to add application/emergencyCallData.control+xml as 1440 a MIME content type, with a reference to this document, in accordance 1441 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1442 [RFC7303]. 1444 MIME media type name: application 1446 MIME subtype name: emergencyCallData.control+xml 1448 Mandatory parameters: none 1450 Optional parameters: charset 1452 Indicates the character encoding of the XML content. 1454 Encoding considerations: Uses XML, which can employ 8-bit 1455 characters, depending on the character encoding used. See 1456 Section 3.2 of RFC 7303 [RFC7303]. 1458 Security considerations: 1460 This content type carries metadata and control information and 1461 requests, such as from a Public Safety Answering Point (PSAP) 1462 to an In-Vehicle System (IVS) during an emergency call. 1464 Metadata (such as an acknowledgment that data sent by the IVS 1465 to the PSAP was successfully received) has limited privacy and 1466 security implications. Control information (such as requests 1467 from the PSAP that the vehicle perform an action) has some 1468 privacy and security implications. The privacy concern arises 1469 from the ability to request the vehicle to transmit a data set, 1470 which as described in Section 15.2, can contain personal 1471 information. The security concern is the ability to request 1472 the vehicle to perform an action. Control information needs to 1473 originate only from a PSAP or other emergency services 1474 provider, and not be modified en-route. The level of integrity 1475 of the cellular network over which the emergency call is placed 1476 is a consideration: when the IVS initiates an eCall over a 1477 cellular network, in most cases it relies on the MNO to route 1478 the call to a PSAP. (Calls placed using other means, such as 1479 Wi-Fi or over-the-top services, generally incur somewhat higher 1480 levels of risk than calls placed "natively" using cellular 1481 networks.) A call-back from a PSAP merits additional 1482 consideration, since current mechanisms are not ideal for 1483 verifying that such a call is indeed a call-back from a PSAP in 1484 response to an emergency call placed by the IVS. See the 1485 discussion in Section 12 and the PSAP Callback document 1486 [RFC7090]. 1488 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1490 Interoperability considerations: None 1492 Published specification: This document 1494 Applications which use this media type: Pan-European eCall 1495 compliant systems 1497 Additional information: None 1499 Magic Number: None 1501 File Extension: .xml 1503 Macintosh file type code: 'TEXT' 1505 Person and email address for further information: Randall Gellens, 1506 rg+ietf@randy.pensive.org 1508 Intended usage: LIMITED USE 1510 Author: The IETF ECRIT WG. 1512 Change controller: The IETF ECRIT WG. 1514 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1515 Additional Data Blocks registry 1517 This specification requests IANA to add the 'eCall.MSD' entry to the 1518 Emergency Call Additional Data Blocks registry, with a reference to 1519 this document. 1521 15.5. Registration of the 'control' entry in the Emergency Call 1522 Additional Data Blocks registry 1524 This specification requests IANA to add the 'control' entry to the 1525 Emergency Call Additional Data Blocks registry, with a reference to 1526 this document. 1528 15.6. Registration of the emergencyCallData.eCall Info Package 1530 IANA is requested to add emergencyCallData.eCall to the Info Packages 1531 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1532 reference to this document. 1534 15.7. URN Sub-Namespace Registration 1536 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1538 This section registers a new XML namespace, as per the guidelines in 1539 RFC 3688 [RFC3688]. 1541 URI: urn:ietf:params:xml:ns:eCall 1543 Registrant Contact: IETF, ECRIT working group, , as 1544 delegated by the IESG . 1546 XML: 1548 BEGIN 1549 1550 1552 1553 1554 1556 Namespace for eCall Data 1557 1558 1559

Namespace for eCall Data

1560

See [TBD: This document].

1561 1562 1563 END 1565 15.7.2. Registration for urn:ietf:params:xml:ns:control 1567 This section registers a new XML namespace, as per the guidelines in 1568 RFC 3688 [RFC3688]. 1570 URI: urn:ietf:params:xml:ns:control 1572 Registrant Contact: IETF, ECRIT working group, , as 1573 delegated by the IESG . 1575 XML: 1577 BEGIN 1578 1579 1581 1582 1583 1585 Namespace for eCall Data: 1586 Control Block 1587 1588 1589

Namespace for eCall Data

1590

Control Block

1591

See [TBD: This document].

1592 1593 1594 END 1596 15.8. Registry creation 1598 This document creates a new registry called 'eCall Metadata/Control 1599 Data'. The following sub-registries are created for this registry. 1601 15.8.1. Action Registry 1603 This document creates a new sub-registry called "Action Registry". 1604 As defined in [RFC5226], this registry operates under "Expert Review" 1605 rules. The expert should determine that the proposed action is 1606 within the purview of a vehicle, is sufficiently distinguishable from 1607 other actions, and the action is clearly and fully described. In 1608 most cases, a published and stable document is referenced for the 1609 description of the action. 1611 The content of this registry includes: 1613 Name: The identifier to be used in the 'action' attribute of a 1614 control element. 1616 Description: A description of the action. In most cases this will 1617 be a reference to a published and stable document. The 1618 description MUST specify if any attributes or child elements are 1619 optional or mandatory, and describe the action to be taken by the 1620 vehicle. 1622 The initial set of values is listed in Table 2. 1624 +-----------+--------------------------------------+ 1625 | Name | Description | 1626 +-----------+--------------------------------------+ 1627 | send-data | See Section 9.1.3.1 of this document | 1628 +-----------+--------------------------------------+ 1630 Table 2: Action Registry Initial Values 1632 15.8.2. Reason Registry 1634 This document creates a new sub-registry called "Reason Registry" 1635 which contains values for the 'reason' attribute of the 1636 element. As defined in [RFC5226], this registry 1637 operates under "Expert Review" rules. The expert should determine 1638 that the proposed reason is sufficiently distinguishable from other 1639 reasons and that the proposed description is understandable and 1640 correctly worded. 1642 The content of this registry includes: 1644 ID: A short string identifying the reason, for use in the 'reason' 1645 attribute of an element. 1647 Description: A description of the reason. 1649 The initial set of values is listed in Table 3. 1651 +------------------+------------------------------------------------+ 1652 | ID | Description | 1653 +------------------+------------------------------------------------+ 1654 | unsupported | The 'action' value is not supported. | 1655 | | | 1656 | damaged | Required components are damaged. | 1657 | | | 1658 | unable | The action could not be accomplished (a | 1659 | | generic error for use when no other code is | 1660 | | appropriate). | 1661 | | | 1662 | data-unsupported | The data item referenced in a 'send-data' | 1663 | | request is not supported. | 1664 | | | 1665 | security-failure | The authenticity of the request or the | 1666 | | authority of the requestor could not be | 1667 | | verified. | 1668 +------------------+------------------------------------------------+ 1670 Table 3: Reason Registry 1672 16. Contributors 1674 Brian Rosen was a co-author of the original document upon which this 1675 document is based. 1677 17. Acknowledgements 1679 We would like to thank Bob Williams and Ban Al-Bakri for their 1680 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith 1681 Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and 1682 James Winterbottom for their review and comments; Robert Sparks and 1683 Paul Kyzivat for their help with the SIP mechanisms. We would like 1684 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1685 Ulrich Dietz for their help with the original document upon which 1686 this document is based. 1688 18. Changes from Previous Versions 1690 18.1. Changes from draft-ietf-12 to draft-ietf-13 1692 o Clarifications suggested by Christer 1693 o Corrections to Content-Disposition text and examples as suggested 1694 by Paul Kyzivat 1695 o Clarifications to Content-Disposition text and examples to clarify 1696 that handling=optional is only used in the initial INVITE 1698 18.2. Changes from draft-ietf-11 to draft-ietf-12 1700 o Fixed errors in examples found by Dale 1701 o Removed enclosing sub-section of INFO package registration section 1702 o Added text per Christer and Dale's suggestions that the MSD and 1703 metadata/control blocks are sent in INFO with a Call-Info header 1704 field referencing them 1705 o Deleted Call Routing section (7.1) in favor of a statement that 1706 call routing is outside the scope of the document 1707 o Other text changes per comments received from Christer and Ivo. 1709 18.3. Changes from draft-ietf-09 to draft-ietf-11 1711 o Renamed INFO package to emergencyCallData.eCall.MSD 1712 o Changed INFO package to only permit MSD and metadata/control MIME 1713 types 1714 o Moved element back from car-crash but made it 1715 OPTIONAL 1716 o Moved other extension points back from car-crash so that extension 1717 points are in base spec (and also to get XML schema to compile) 1718 o Text changes for clarification. 1720 18.4. Changes from draft-ietf-08 to draft-ietf-09 1722 o Created a new "Data Transport" section that describes how the MSD 1723 and metadata/control blocks are attached, and then referred to 1724 that section rather than repeat the information about the CID and 1725 Call-Info and so forth, which means most references to the 1726 additional-data draft have now been deleted 1727 o Mentioned edge cases where a PSAP response to INVITE isn't 1728 received by the IVS 1729 o Reworded description of which status codes are used when a PSAP 1730 wishes to reject a call but inform the vehicle occupants that it 1731 is aware of the situation to be more definite 1732 o Added examples showing INFO 1733 o Added references for eCall test call requirement 1734 o Described meaning of eCall URNs in Section 8 as well as in IANA 1735 registration 1737 18.5. Changes from draft-ietf-07 to draft-ietf-08 1739 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1740 encoding 1741 o Added text to point out aspects of call handling and metadata/ 1742 control usage, such as use in rejected calls, and solicited MSDs 1743 o Revised use of INFO to require that when a request for an MSD is 1744 sent in INFO, the MSD sent in response is in its own INFO, not the 1745 response to the requesting INFO 1747 o Added material to INFO package registation to comply with 1748 Section 10 of [RFC6086] 1749 o Moved material not required by 3GPP into 1750 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1751 control elements, attributes, and values 1752 o Revised test call wording to clarify that specific handling is out 1753 of scope 1754 o Revised wording throughout the document to simplify 1755 o Moved new Section 7.1 to be a subsection of 7 1756 o Moved new Section Section 10 to be a main section instead of a 1757 subsection of Section 9 1758 o Revised SIP INFO usage and package registration per advice from 1759 Robert Sparks and Paul Kyzivat 1761 18.6. Changes from draft-ietf-06 to draft-ietf-07 1763 o Fixed typo in Acknowledgements 1765 18.7. Changes from draft-ietf-05 to draft-ietf-06 1767 o Added additional security and privacy clarifications regarding 1768 signed and encrypted data 1769 o Additional security and privacy text 1770 o Deleted informative section on ESINets as unnecessary. 1772 18.8. Changes from draft-ietf-04 to draft-ietf-05 1774 o Reworked the security and privacy considerations material in the 1775 document as a whole and in the MIME registation sections of the 1776 MSD and control objects 1777 o Clarified that the element can appear multiple 1778 times within an element 1779 o Fixed IMS definition 1780 o Added clarifying text for the 'msgid' attribute 1782 18.9. Changes from draft-ietf-03 to draft-ietf-04 1784 o Added Privacy Considerations section 1785 o Reworded most uses of non-normative "may", "should", "must", and 1786 "recommended." 1787 o Fixed nits in examples 1789 18.10. Changes from draft-ietf-02 to draft-ietf-03 1791 o Added request to enable cameras 1792 o Improved examples and XML schema 1793 o Clarifications and wording improvements 1795 18.11. Changes from draft-ietf-01 to draft-ietf-02 1797 o Added clarifying text reinforcing that the data exchange is for 1798 small blocks of data infrequently transmitted 1799 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1800 establish a one-way media stream 1801 o Clarified that the scope is the needs of eCall within the SIP 1802 emergency call environment 1803 o Added informative statement that the document may be suitable for 1804 reuse by other ACN systems 1805 o Clarified that normative language for the control block applies to 1806 both IVS and PSAP 1807 o Removed 'ref', 'supported-mime', and elements 1808 o Minor wording improvements and clarifications 1810 18.12. Changes from draft-ietf-00 to draft-ietf-01 1812 o Added further discussion of test calls 1813 o Added further clarification to the document scope 1814 o Mentioned that multi-region vehicles may need to support other 1815 crash notification specifications in addition to eCall 1816 o Added details of the eCall metadata and control functionality 1817 o Added IANA registration for the MIME content type for the control 1818 object 1819 o Added IANA registries for protocol elements and tokens used in the 1820 control object 1821 o Minor wording improvements and clarifications 1823 18.13. Changes from draft-gellens-03 to draft-ietf-00 1825 o Renamed from draft-gellens- to draft-ietf-. 1826 o Added mention of and reference to ETSI TR "Mobile Standards Group 1827 (MSG); eCall for VoIP" 1828 o Added text to Introduction regarding migration/co-existence being 1829 out of scope 1830 o Added mention in Security Considerations that even if the network- 1831 supplied location is just the cell site, this can be useful as a 1832 sanity check on the IVS-supplied location 1833 o Minor wording improvements and clarifications 1835 18.14. Changes from draft-gellens-02 to -03 1837 o Clarifications and editorial improvements. 1839 18.15. Changes from draft-gellens-01 to -02 1841 o Minor wording improvements 1842 o Removed ".automatic" and ".manual" from 1843 "urn:service:test.sos.ecall" registration and discussion text. 1845 18.16. Changes from draft-gellens-00 to -01 1847 o Now using 'EmergencyCallData' for purpose parameter values and 1848 MIME subtypes, in accordance with changes to [RFC7852] 1849 o Added reference to RFC 6443 1850 o Fixed bug that caused Figure captions to not appear 1852 19. References 1854 19.1. Normative References 1856 [EN_16062] 1857 CEN, , "Intelligent transport systems - eSafety - eCall 1858 High Level Application Requirements (HLAP) Using GSM/UMTS 1859 Circuit Switched Networks, EN 16062", April 2015. 1861 [EN_16072] 1862 CEN, , "Intelligent transport systems - eSafety - Pan- 1863 European eCall operating requirements, EN 16072", April 1864 2015. 1866 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1867 minimum set of data (MSD), EN 15722", April 2015. 1869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1870 Requirement Levels", BCP 14, RFC 2119, 1871 DOI 10.17487/RFC2119, March 1997, 1872 . 1874 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1875 DOI 10.17487/RFC3688, January 2004, 1876 . 1878 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1879 Emergency and Other Well-Known Services", RFC 5031, 1880 DOI 10.17487/RFC5031, January 2008, 1881 . 1883 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1884 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1885 DOI 10.17487/RFC5226, May 2008, 1886 . 1888 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1889 "Framework for Emergency Calling Using Internet 1890 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1891 2011, . 1893 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1894 Specifications and Registration Procedures", BCP 13, 1895 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1896 . 1898 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1899 Communications Services in Support of Emergency Calling", 1900 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1901 . 1903 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1904 DOI 10.17487/RFC7303, July 2014, 1905 . 1907 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1908 J. Winterbottom, "Additional Data Related to an Emergency 1909 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1910 . 1912 [TS22.101] 1913 3GPP, , "3GPP TS 22.101: Technical Specification Group 1914 Services and System Aspects; Service aspects; Service 1915 principles". 1917 19.2. Informative references 1919 [CEN] "European Committee for Standardization", 1920 . 1922 [I-D.ietf-ecrit-car-crash] 1923 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1924 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1925 ecrit-car-crash-09 (work in progress), August 2016. 1927 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1928 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1929 April 2014. 1931 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1932 Emergency Context Resolution with Internet Technologies", 1933 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1934 . 1936 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1937 Shanmugam, "Security Threats and Requirements for 1938 Emergency Call Marking and Mapping", RFC 5069, 1939 DOI 10.17487/RFC5069, January 2008, 1940 . 1942 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1943 Initiation Protocol (SIP) INFO Method and Package 1944 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1945 . 1947 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1948 Patel, "Public Safety Answering Point (PSAP) Callback", 1949 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1950 . 1952 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1953 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1954 December 2014, . 1956 [SDO-3GPP] 1957 "3d Generation Partnership Project", 1958 . 1960 [SDO-ETSI] 1961 "European Telecommunications Standards Institute (ETSI)", 1962 . 1964 Authors' Addresses 1966 Randall Gellens 1967 Core Technology Consulting 1969 Email: rg+ietf@randy.pensive.org 1971 Hannes Tschofenig 1972 Individual 1974 Email: Hannes.Tschofenig@gmx.net 1975 URI: http://www.tschofenig.priv.at