idnits 2.17.00 (12 Aug 2021) /tmp/idnits4575/draft-ietf-ecrit-additional-data-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 941 has weird spacing: '...ll-Info pur...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: There is much private data in this information. Local regulations may govern what data must be provided in emergency calls, but in general, the emergency call system is often aided by the kinds of information described in this document. There is a tradeoff between the privacy considerations and the utility of the data. Certainly, if the data cannot be protected, due to failure of the TLS mechanisms described here, data not required by regulation SHOULD not be sent. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 31, 2011) is 3854 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) == Missing Reference: 'This RFC' is mentioned on line 941, but not defined ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 3, 2012 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 October 31, 2011 10 Additional Data related to an Emergency Call 11 draft-ietf-ecrit-additional-data-02.txt 13 Abstract 15 When an emergency call is sent to a Public Safety Answering Point 16 (PSAP), the device that sends it, as well as any service provider in 17 the path of the call, or access network may have information about 18 the call which the PSAP may be able to use. This document describes 19 an XML data structure that contains this kind of information in a 20 standardized form. A Uniform Resource Identifier (URI) that points 21 to the structure can be included in the SIP signaling with the call, 22 or the data may be included in the body of a SIP message. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 3, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 7 61 4. Data Provider Information . . . . . . . . . . . . . . . . . . 8 62 4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 8 63 4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. Data Provider Contact URI . . . . . . . . . . . . . . . . 9 65 4.4. Data Provider Languages(s) Supported . . . . . . . . . . . 9 66 4.5. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 10 67 4.6. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 11 68 5. Service Information . . . . . . . . . . . . . . . . . . . . . 12 69 5.1. Service Environment . . . . . . . . . . . . . . . . . . . 12 70 5.2. Service Delivered by Provider to End User . . . . . . . . 12 71 5.3. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 13 72 6. Device Information . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. Device Classification . . . . . . . . . . . . . . . . . . 15 74 6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 17 75 6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 17 76 6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 17 77 6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 18 78 6.6. Device/Service Specific Additional Data Structure Type . . 19 79 6.7. Device/Service Specific Additional Data Structure . . . . 20 80 6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 21 81 7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 22 82 7.1. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 22 83 7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 22 84 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 11.1. 'emergencyCallData' Purpose Parameter Value . . . . . . . 27 89 11.2. URN Sub-Namespace Registration for provided-by 90 Registry Entry . . . . . . . . . . . . . . . . . . . . . . 27 91 11.3. MIME Registrations . . . . . . . . . . . . . . . . . . . . 27 92 11.3.1. MIME Content-type Registration for 93 'application/addDataProviderInfo+xml' . . . . . . . . 27 94 11.3.2. MIME Content-type Registration for 95 'application/addCallSvcInfo+xml' . . . . . . . . . . 28 97 11.3.3. MIME Content-type Registration for 98 'application/addDataDevInfo+xml' . . . . . . . . . . 30 99 11.3.4. MIME Content-type Registration for 100 'application/addCallSub+xml' . . . . . . . . . . . . 31 101 11.4. URN Sub-Namespace Registration . . . . . . . . . . . . . . 32 102 11.4.1. Registration for 103 urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 32 104 11.4.2. Registration for 105 urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 33 106 11.4.3. Registration for 107 urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 34 108 11.4.4. Registration for urn:ietf:params:xml:ns:addCallSub . 35 109 11.5. Schema Registrations . . . . . . . . . . . . . . . . . . . 36 110 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 111 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 112 13.1. Normative References . . . . . . . . . . . . . . . . . . . 39 113 13.2. Informational References . . . . . . . . . . . . . . . . . 39 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 116 1. Introduction 118 As communications devices increasingly utilize the Internet to 119 interconnect and communicate, users will expect to use such devices 120 to request help. The Internet Protocol suite provides many 121 advantages but also requires re-thinking of the traditional emergency 122 calling architecture. The IETF emergency services architecture, as 123 described in [I-D.ietf-ecrit-framework] and 124 [I-D.ietf-ecrit-phonebcp], offers a much richer communication 125 exchange and thereby better situational awareness for call takers. 126 The richness comes in various forms, including the multi-media 127 communication capabilities (via voice, video, instant messaging, and 128 real-time text), but also via more extensive flow of information. 129 Sharing information between various actors will enable more 130 intelligent decision making and therefore better response in case of 131 an emergency. A pre-requisite is to offer the technical capabilities 132 to let call takers to gain access to this information stored 133 elsewhere (granted that they are authorized to access it). 135 In general, there are four types of data exchanged: 137 Data Associated with a Call: A lot of information is carried in the 138 call setup procedure itself (as part of the SIP headers as well as 139 in the body of the SIP message, e.g., for example supported 140 capabilities of the device). This also includes information about 141 the emergency caller's identity. 143 Data Associated with a Location: Location information is available 144 via the PIDF-LO element, which includes civic and geospatial 145 location, information about the entity that provided the data, 146 information about how the location was obtained (as expressed by 147 the element, see Section 2.2.3 of [RFC4119], and the 148 values registered in 149 http://www.iana.org/assignments/method-tokens/method-tokens.xml), 150 and which entity or organization supplied location information 151 (beyond the domain information that can be inferred from a signing 152 certificate) available via the element. 154 Data Associated with a Caller: This is personal data about a caller, 155 including medical information. 157 Data associated with a PSAP: When a PSAP handles a call it develops 158 information about the call, which must be passed to subsequent 159 PSAPs, dispatchers and/or responders. 161 When an emergency call is sent to a PSAP, there is a rich set of data 162 in the SIP message used for the call setup, but the device, as well 163 as any other service provider in the path may have even more 164 information useful for a PSAP. This information may include the 165 identity and contact information of the service provider, subscriber 166 identity and contact information, the type of service the provider 167 offers, what kind of device the user has, etc. Some data is device 168 or service dependent data. For example, a car telematics system or 169 service may have crash information. A medical monitoring device may 170 have sensor data. While the details of the information may vary by 171 device or service, there needs to be a common way to send such data 172 to a PSAP. 174 This document focuses on the data that can be obtained about a call 175 and a mechanism for transporting it in an existing SIP header field, 176 the Call-Info header, which is specified in Section 20.9 of 177 [RFC3261]. For this purpose a new token, namely 'emergencyCallData' 178 is defined to be carried in the "purpose" parameter. If the 179 "purpose" parameter is set to 'emergencyCallData' then the Call-Info 180 header contains a HTTPS URL that points to a data structure with 181 information about the call or a CID that allows the data structure to 182 be placed in the body of the message. Section 8 shows a SIP INVITE 183 example containing such a Call-Info header. 185 Besides a service provider in the path of a call, the access network 186 (which in the IETF emergency call architecture provides location in 187 the form of a PIDF-LO [RFC4119]) also has similar information that 188 would be valuable to the PSAP. This information is not specific to 189 the location itsef, but rather to the immmediate circumstances about 190 the provision of the location (who the access network is, how to 191 contact that entity, what kind of service the access network 192 provides, possibly subscriber data, etc.). This data is in nearly 193 every respect similar to the data known by services providers in the 194 path of the call. For this reason, this document describes a 195 "provided-by" namespace per [RFC4119] for passing information known 196 to the access network. 198 The data is defined as a series of "blocks" that represent a class of 199 information. Each of the blocks is a MIME type, and an extensible 200 set of these types constitute the data structure. A registry is 201 defined to list the block types that may be included. 203 The data structure contains an element which itself is a URI that has 204 device or service dependent data. Thus the common Additional Data 205 about a Call defined by this document contains a 'hook', in the form 206 of a URI, for a device or service dependent data structure. 208 2. Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 3. Call-Info Specification 216 The Additional Data about a Call is information specific to a call 217 known by the device that sends it or a service provider in the path 218 of a call or in the access network the call originates in. The 219 Additional Data about a Call is a set of information blocks. Each 220 block is a MIME type, and any set of blocks may be included in the 221 set. 223 Two mechanisms are provided to transport the data set, namely 225 1. A URI to the data set MAY be inserted in a SIP INVITE or MESSAGE 226 transaction with a Call-Info header containing a purpose of 227 "emergenyCallData". If the data is provided by reference, it may 228 be retrieved with an HTTPS Get from the URI. The URI MUST 229 specify an HTTPS scheme, and TLS protection for the data MUST be 230 negotiated. 232 2. The data may be supplied by value in a SIP INVITE or MESSAGE 233 message. In this case, Content Indirection (CID) [RFC2392] is 234 used, with the CID URL pointing to the body of the message. 236 More than one Call-Info header with an emergencyCallData purpose can 237 be expected. The device MAY insert one, and any intermediary service 238 provider MAY insert its own. When there are multiple intermediaries, 239 each intermediary MAY each insert one. For example, a device may 240 provide one, a telematics service provider may provide one and the 241 mobile carrier handling the call may provide one. 243 Note: The access network MAY supply additional data as well. For 244 this purpose, this document defines a namespace and adds the 245 namespace to the "provided-by" registry defined by PIDF-LO [RFC4119]. 247 Additional data about a call is defined as a series of MIME objects, 248 each with an XML data structure contained inside. MIME-multipart is 249 used to enclose the XML documents and the sections below define them. 251 4. Data Provider Information 253 This block is intended to be provided by any service provider in the 254 path of the call or the access network provider. It includes 255 identification and contact information. This block SHOULD be 256 provided for every service provider in the path of the call, and the 257 access network provider. Devices also use this block to provide 258 identifying information. The MIME type is "addDataProviderInfo+xml". 260 4.1. Data Provider String 262 Data Element: Data Provider String 264 Use: Required 266 XML Element: 268 Description: This is a plain language string suitable for displaying 269 the name of the service provider that created the additional data 270 structure. If the device created the structure the value is 271 identical to the contact header in the SIP INVITE. 273 Reason for Need: Inform the call taker about the identity of the 274 entity providing the additional call data structure. 276 How Used by Call Taker: Allows the call taker to interpret the data 277 in this structure. The source of the information often influences 278 how the information is used, believed or verified. 280 4.2. Data Provider ID 282 Data Element: Data Provider ID 284 Use: Conditional 286 XML Element: 288 Description: A jurisdiction specific code for the provider shown in 289 the element that created the structure of the 290 call. This data SHOULD be provided if the local jurisdiction 291 maintains such an ID list. For example, in North America, this 292 would be a "NENA Company ID". Devices would not typically use 293 this element. 295 Reason for Need: Inform the call taker about the identity of the 296 entity providing the additional call data structure. 298 How Used by Call Taker: Where jurisdictions have lists of providers 299 the Data Provider ID can lead to a wealth of information. 301 4.3. Data Provider Contact URI 303 Data Element: Data Provider Contact URI 305 Use: Required 307 XML Element: 309 Description: For a service provider the contact SHOULD be a contact 310 URI. This must be a SIP URI. If a telephone number is the 311 contact address it should be provided in the form of 312 sip:telephonenumber@serviceprovider:user=phone. If the call is 313 from a device, this data is required and should reflect the 314 contact information of the owner of the device. This should be a 315 URI to a 24/7 support organization tasked to provide PSAP support 316 for this emergency call. 318 Reason for Need: Additional data providers may need to be contacted 319 for error or other unusual circumstances. 321 How Used by Call Taker: To contact the supplier of the additional 322 data provider structure. 324 4.4. Data Provider Languages(s) Supported 326 Data Element: Data Provider Language(s) supported 328 Use: Conditional 329 XML Element: 331 Description: Provided by's alpha 2-character code as defined in ISO 332 639-1:2002 333 (http://www.iso.org/iso/catalogue_detail?csnumber=22109) Codes for 334 the representation of names of languages -- Part 1: Alpha-2 code 335 Multiple instances of this element may occur. Order is 336 significant; preferred language should appear first. This data is 337 required if a Data Provider Contact URI is provided. The content 338 must reflect the languages supported at the contact URI. 340 Reason for Need: Information needed to determine if emergency 341 service authority can communicate with the service provider or if 342 language line will be needed. 344 How Used by Call Taker: If call taker cannot speak language(s) 345 supported by the service provider, at translation service will 346 need to be added in to the conversation. 348 4.5. vCARD of Data Provider 350 Data Element: vCARD of Data Provider 352 Use: Optional 354 XML Element: 356 Description: There are many fields in the vCARD and the creator of 357 the data structure is encouraged to provide as much information as 358 they have available. For encoding of the vCard this specification 359 uses the XML-based encoding specified in [RFC6351]. 361 Reason for Need: Information needed to determine additional contact 362 information. 364 How Used by Call Taker: Assists call taker by providing additional 365 contact information that may not be included in the SIP invite or 366 the PIDF-LO. 368 4.6. addDataProviderInfo XML Schema 370 371 379 382 383 384 385 386 388 389 390 391 393 395 397 399 401 402 403 404 406 Figure 1: addDataProviderInfo XML Schema 408 5. Service Information 410 This block describes the service that the service provider provides 411 to the caller. It SHOULD be included by all SPs in the path of the 412 call. The mime type is "addCallSvcInfo+xml". 414 5.1. Service Environment 416 Data Element: Service Environment 418 Use: Required 420 XML Element: 422 Description: This element defines whether a call is from a business 423 or residence caller. Currently, the only valid entries are 424 'Business' or 'Residence'. 426 Reason for Need: To assist in determining equipment and manpower 427 requirements. 429 How Used by Call Taker: Information may be used to determine 430 equipment and manpower requirements for emergency responders. 432 5.2. Service Delivered by Provider to End User 434 Data Element: Service Delivered by Provider to End User 436 Use: Required 438 XML Element: 440 Description: This defines the type of service the end user has 441 subscribed to. The implied mobility of this service can not be 442 relied upon. A registry will reflect the following initial valid 443 entries: 445 * Mobile Telephone Service: Includes Satellite, CDMA, GSM, Wi-Fi, 446 WiMAX, LTE (Long Term Evolution) 448 * Fixed Public Pay/Coin telephones: Any coin or credit card 449 operated device. 451 * One way outbound service 453 * Inmate call/service 455 * Soft dialtone/quick service/warm disconnect/suspended 457 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 458 key systems, Shared Tenant Service. 460 * Sensor, unattended: Includes devices that generate DATA ONLY. 461 This is one-way information exchange and there will be no other 462 form of communication. 464 * Sensor, attended: Includes devices that are supported by a 465 monitoring service provider or automatically open a two-way 466 communication path. 468 * Wireline: Plain Old Telephone Service (POTS). 470 * VoIP Telephone Service: A type of service that offers 471 communication over internet protocol, such as Fixed, Nomadic, 472 Mobile, Unknown 474 There can be more than one value returned. For example, a VoIP 475 prison telephone service is a reasonable conbination. 477 Reason for Need: Knowing the type of service may assist the PSAP 478 with the handling of the call. 480 How Used by Call Taker: Calltakers often use this information to 481 determine what kinds of questions to ask callers, and how much to 482 rely on supportive information. An emergency call from a prison 483 is treated differently that a call from a sensor device. 485 5.3. addCallSvcInfo XML Schema 486 487 494 497 498 499 500 502 504 505 506 507 509 Figure 2: addCallSvcInfo XML Schema 511 6. Device Information 513 This block provides information about the device used to place the 514 call. It should be provided by any service provider that knows what 515 device is being used, and by the device itself. The mime type is 516 "addDataDevInfo+xml". 518 6.1. Device Classification 520 Data Element: Device Classification 522 Use: Optional 524 XML Element: 526 Description: If the device provides the data structure, the device 527 information should be provided. If the service provider provides 528 the structure and it knows what the device is, the service 529 provider should provide the device information. Often the carrier 530 does not know what the device is. It is possible to receive 2 531 data structures, one created by the device and one created by the 532 service provider. Information about the device, not how it is 533 being used. This data element defines the kind of device making 534 the emergency call. A registry will reflect the following valid 535 entries: 537 * Cordless handset 539 * Fixed phone 541 * Mobile handset 543 * ATA - analog terminal adapter 545 * Satellite phone 547 * Stationary computing device (alarm system, data sensor) 549 * Guardian devices 551 * Desktop PC 553 * Laptop computing device 554 * Tablet computing device 556 * Alarm system 558 * Data sensor 560 * Personal beacons (spot) 562 * Auto telematics (indicates VEDS data set) 564 * Trucking telematics 566 * Farm equipment telematics 568 * Marine telematics 570 * PDA (personal digital assistant) 572 * PND (personal navigation device) 574 * Smart phone 576 * Internet tablet 578 * Gaming console 580 * Video phone 582 * Other text device 584 * Not Available 586 Reason for Need: The device classification describes the capability 587 of the calling device. For example, does the device require human 588 intervention to initiate a call or is this call the result of 589 programmed instructions. Does the calling device have the ability 590 to rebid for location or condition changes? Is this device 591 interactive or a one-way reporting device? 593 How Used by Call Taker: May assist with location of caller. For 594 example, a cordless handset may be outside or next door. May 595 provide calltaker some context about the caller. 597 6.2. Device Manufacturer 599 Data Element: Device Manufacturer 601 Use: Optional 603 XML Element: 605 Description: The plain language name of the manufacturer of the 606 device. 608 Reason for Need: Used by PSAP management for post-mortem 609 investigation/resolution. 611 How Used by Call Taker: Probably not used by calltaker, but by PSAP 612 management. 614 6.3. Device Model Number 616 Data Element: Device Model Number 618 Use: Optional 620 XML Element: 622 Description: Model number of the device. 624 Reason for Need: Used by PSAP management for after action 625 investigation/resolution. 627 How Used by Call Taker: Probably not used by calltaker, but by PSAP 628 management. 630 6.4. Unique Device Identifier 631 Data Element: Unique Device Identifier 633 Use: Optional 635 XML Element: 637 Description: String that identify the specific device making the 638 call or creating an event. 640 Reason for Need: Uniquely identifies the device as opposed to any 641 signaling identifiers encountered in the call signaling stream. 643 How Used by Call Taker: Probably not used by calltaker they would 644 need to refer to management for investigation. 646 6.5. Type of Device Identifier 648 Data Element: Type of Device Identifier 650 Use: Optional 652 XML Element: 654 Description: Identifies the type of device identifier being 655 generated in the unique device identifier data element. A 656 registry will reflect the following valid entries: 658 * MEID (CDMA) 660 * ESN (Electronic Serial Number - superseded by MEID) 662 * MAC (Media Access Control) Address - any IEEE device with an 663 Ethernet, Wi-Fi connection 665 * WiMAX has a device certificate 667 * IMEI (International Mobile Equipment Identifier - GSM) 669 * Unique Device Identifier (Unique identifier for medical 670 devices) 672 * RFID (Radio Frequency Identification) 674 * Sensors (types to be identified in a future document version) 676 * Manufacturer Serial Number 678 * Other 680 Reason for Need: Identifies how to interpret the Unique Device 681 Identifier. 683 How Used by Call Taker: Additional information that may be used to 684 assist with call handling. 686 6.6. Device/Service Specific Additional Data Structure Type 688 Data Element: Type of Device/service specific additional data 689 structure 691 Use: Conditional. MUST be provided when Device/service specific 692 additional URI is provided 694 XML Element: 696 Description: Value from a registry defined by this document to 697 describe the type of data that can be retrieved from the Device/ 698 service specific additional data structure. Initial values are: 700 * NPAC 702 * Hazmat International Association of Fire Chiefs 704 * DHS/EPA E-Plan for HazMat 706 * NFPA - National Fire Protection Association 708 * National Alliance for Public Safety GIS (NA-PSG) 710 * US DOT Pipeline and Hazardous Materials Safety Administration 711 (PHMSA) examples of additional data. 713 * Fire Service Data Model 714 * IEEE 1512 - USDOT Model for traffic incidents 716 * Smart Building (NIST) 718 * VEDS 720 Reason for Need: This data element will allow for identification of 721 externally defined schemas, which may have additional data that 722 will assist in emergency response. 724 How Used by Call Taker: This data element will allow the end user 725 (calltaker or first responder) to know what type of additional 726 data may be available to aid in providing the needed emergency 727 services. 729 6.7. Device/Service Specific Additional Data Structure 731 Data Element: Device/service specific additional data structure 733 Use: Optional 735 XML Element: 737 Description: A URI representing additional data whose schema is 738 specific to the device or service which created it. An example is 739 the VEDs structure for a vehicle telematics device. The URI, when 740 dereferenced, MUST yield a data structure defined by the Device/ 741 service specific additional data type value. Different data may 742 be created by each classification; i.e., telematics creates VEDS 743 data set - can be different types of data depending on device. 744 May want to describe type of data for each device. 746 Reason for Need: Provides device/service specific data that may be 747 used by the call taker and/or responders. 749 How Used by Call Taker: Provide information to guide call takers to 750 select appropriate responders, give appropriate pre-arrival 751 instructions to callers, and advise responders of what to be 752 prepared for. May be used by responders to guide assistance 753 provided. 755 6.8. addDataDevInfo XML Schema 757 758 765 768 769 770 771 773 775 777 779 781 783 785 786 787 788 790 Figure 3: addDataDevInfo XML Schema 792 7. Owner/Subscriber Information 794 This block describes the owner of the device (if provided by the 795 device) or the subscriber information, if provided by a service 796 provider. The contact location is not necessarily the location of 797 the caller or incident, but is rather the nominal contact address. 798 The mime type is "addCallSub+xml". 800 7.1. vCARD for Subscriber's Data 802 Data Element: vCARD for Subscriber's Data 804 Use: Required 806 XML Element: 808 Description: Information known by the service provider or device 809 about the subscriber; i.e., Name, Address, Calling Party Number, 810 Main Telephone Number and any other data. If the subscriber is an 811 enterprise, this is the vCARD of the enterprise and the Company 812 Name is used not the Name of the Caller. The telephone number is 813 the main telephone number at the location of the call. The 814 address should be where the call is originating from. 816 Reason for Need: Critical information required for proper call 817 handling and dispatching. 819 How Used by Call Taker: Critical information required for proper 820 call handling and dispatching. 822 7.2. addCallSub XML Schema 823 824 832 835 836 837 838 840 841 842 843 845 Figure 4: addCallSub XML Schema 847 8. Example 849 INVITE sips:bob@biloxi.example.com SIP/2.0 850 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 851 Max-Forwards: 70 852 To: Bob 853 From: Alice ;tag=9fxced76sl 854 Call-ID: 3848276298220188511@atlanta.example.com 855 Call-Info: ;purpose=icon, 856 ;purpose=info, 857 ;purpose=emergencyCallData 858 Geolocation: 859 Geolocation-Routing: no 860 Accept: application/sdp, application/pidf+xml 861 CSeq: 31862 INVITE 862 Contact: 863 Content-Type: multipart/mixed; boundary=boundary1 865 Content-Length: ... 867 --boundary1 869 Content-Type: application/sdp 871 ...SDP goes here 873 --boundary1 875 Content-Type: application/pidf+xml 876 Content-ID: 878 ...PIDF-LO goes here 880 --boundary1-- 882 Content-Type: application/pidf+xml 883 Content-ID: <1234567890@atlanta.example.com> 885 ...Additional Data goes here 887 --boundary1-- 889 Example: Attaching Additional Data via CID to a SIP INVITE 891 9. Security Considerations 893 The information in this data structure will usually be considered 894 private. HTTPS is specified to require the provider of the 895 information to validate the credentials of the requester. While the 896 creation of a PKI that has global scope may be difficult, the 897 alternatives to creating devices and services that can provide 898 critical information securely are more daunting. 900 The Call-info header with purpose='emergencyCallData' MUST only be 901 sent on an emergency call, which can be ascertained by the presence 902 of an emergency service urn in a Route header of a SIP message. 904 906 908 911 10. Privacy Considerations 913 [Editor's Note: The privacy considerations outlined in 914 [I-D.iab-privacy-considerations] need to be addressed here in a 915 future version of this document. 917 There is much private data in this information. Local regulations 918 may govern what data must be provided in emergency calls, but in 919 general, the emergency call system is often aided by the kinds of 920 information described in this document. There is a tradeoff between 921 the privacy considerations and the utility of the data. Certainly, 922 if the data cannot be protected, due to failure of the TLS mechanisms 923 described here, data not required by regulation SHOULD not be sent. 925 11. IANA Considerations 927 [Editor's Note: The IANA section is missing the description of new 928 registries. A future version of this draft will contain the 929 necessary information.] 931 11.1. 'emergencyCallData' Purpose Parameter Value 933 This document defines the 'emergencyCallData' value for the "purpose" 934 parameter of the Call-Info header field. The Call-Info header and 935 the corresponding registry for the 'purpose' parameter was 936 established with RFC 3261 [RFC3261]. 938 Header Parameter New 939 Field Name Value Reference 940 ---------- --------- ----------------- --------- 941 Call-Info purpose emergencyCallData [This RFC] 943 11.2. URN Sub-Namespace Registration for provided-by Registry Entry 945 This section registers the namespace specified in ??? in the 946 provided-by registry established by RFC 4119. 948 11.3. MIME Registrations 950 11.3.1. MIME Content-type Registration for 'application/ 951 addDataProviderInfo+xml' 953 This specification requests the registration of a new MIME type 954 according to the procedures of RFC 4288 [RFC4288] and guidelines in 955 RFC 3023 [RFC3023]. 957 MIME media type name: application 959 MIME subtype name: addDataProviderInfo+xml 961 Mandatory parameters: none 963 Optional parameters: charset 965 Indicates the character encoding of enclosed XML. 967 Encoding considerations: 969 Uses XML, which can employ 8-bit characters, depending on the 970 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 972 Security considerations: 974 This content type is designed to carry the data provider 975 information, which is a sub-category of additional data about an 976 emergency call. 978 Since this data contains personal information appropriate 979 precautions have to be taken to limit unauthorized access, 980 inappropriate disclosure to third parties, and eavesdropping of 981 this information. Please refer to Section 9 and Section 10 for 982 more information. 984 Interoperability considerations: None 986 Published specification: [TBD: This specification] 988 Applications which use this media type: Emergency Services 990 Additional information: 992 Magic Number: None 994 File Extension: .xml 996 Macintosh file type code: 'TEXT' 998 Personal and email address for further information: Hannes 999 Tschofenig, Hannes.Tschofenig@gmx.net 1001 Intended usage: LIMITED USE 1003 Author: This specification is a work item of the IETF ECRIT 1004 working group, with mailing list address . 1006 Change controller: The IESG 1008 11.3.2. MIME Content-type Registration for 'application/ 1009 addCallSvcInfo+xml' 1011 This specification requests the registration of a new MIME type 1012 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1013 RFC 3023 [RFC3023]. 1015 MIME media type name: application 1017 MIME subtype name: addCallSvcInfo+xml 1018 Mandatory parameters: none 1020 Optional parameters: charset 1022 Indicates the character encoding of enclosed XML. 1024 Encoding considerations: 1026 Uses XML, which can employ 8-bit characters, depending on the 1027 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1029 Security considerations: 1031 This content type is designed to carry the service information, 1032 which is a sub-category of additional data about an emergency 1033 call. 1035 Since this data contains personal information appropriate 1036 precautions have to be taken to limit unauthorized access, 1037 inappropriate disclosure to third parties, and eavesdropping of 1038 this information. Please refer to Section 9 and Section 10 for 1039 more information. 1041 Interoperability considerations: None 1043 Published specification: [TBD: This specification] 1045 Applications which use this media type: Emergency Services 1047 Additional information: 1049 Magic Number: None 1051 File Extension: .xml 1053 Macintosh file type code: 'TEXT' 1055 Personal and email address for further information: Hannes 1056 Tschofenig, Hannes.Tschofenig@gmx.net 1058 Intended usage: LIMITED USE 1060 Author: This specification is a work item of the IETF ECRIT 1061 working group, with mailing list address . 1063 Change controller: The IESG 1065 11.3.3. MIME Content-type Registration for 'application/ 1066 addDataDevInfo+xml' 1068 This specification requests the registration of a new MIME type 1069 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1070 RFC 3023 [RFC3023]. 1072 MIME media type name: application 1074 MIME subtype name: addDataDevInfo+xml 1076 Mandatory parameters: none 1078 Optional parameters: charset 1080 Indicates the character encoding of enclosed XML. 1082 Encoding considerations: 1084 Uses XML, which can employ 8-bit characters, depending on the 1085 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1087 Security considerations: 1089 This content type is designed to carry the device information 1090 information, which is a sub-category of additional data about an 1091 emergency call. 1093 Since this data contains personal information appropriate 1094 precautions have to be taken to limit unauthorized access, 1095 inappropriate disclosure to third parties, and eavesdropping of 1096 this information. Please refer to Section 9 and Section 10 for 1097 more information. 1099 Interoperability considerations: None 1101 Published specification: [TBD: This specification] 1103 Applications which use this media type: Emergency Services 1105 Additional information: 1107 Magic Number: None 1109 File Extension: .xml 1111 Macintosh file type code: 'TEXT' 1112 Personal and email address for further information: Hannes 1113 Tschofenig, Hannes.Tschofenig@gmx.net 1115 Intended usage: LIMITED USE 1117 Author: This specification is a work item of the IETF ECRIT 1118 working group, with mailing list address . 1120 Change controller: The IESG 1122 11.3.4. MIME Content-type Registration for 'application/addCallSub+xml' 1124 This specification requests the registration of a new MIME type 1125 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1126 RFC 3023 [RFC3023]. 1128 MIME media type name: application 1130 MIME subtype name: addCallSub+xml 1132 Mandatory parameters: none 1134 Optional parameters: charset 1136 Indicates the character encoding of enclosed XML. 1138 Encoding considerations: 1140 Uses XML, which can employ 8-bit characters, depending on the 1141 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1143 Security considerations: 1145 This content type is designed to carry owner/subscriber 1146 information, which is a sub-category of additional data about an 1147 emergency call. 1149 Since this data contains personal information appropriate 1150 precautions have to be taken to limit unauthorized access, 1151 inappropriate disclosure to third parties, and eavesdropping of 1152 this information. Please refer to Section 9 and Section 10 for 1153 more information. 1155 Interoperability considerations: None 1157 Published specification: [TBD: This specification] 1158 Applications which use this media type: Emergency Services 1160 Additional information: 1162 Magic Number: None 1164 File Extension: .xml 1166 Macintosh file type code: 'TEXT' 1168 Personal and email address for further information: Hannes 1169 Tschofenig, Hannes.Tschofenig@gmx.net 1171 Intended usage: LIMITED USE 1173 Author: This specification is a work item of the IETF ECRIT 1174 working group, with mailing list address . 1176 Change controller: The IESG 1178 11.4. URN Sub-Namespace Registration 1180 11.4.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo 1182 This section registers a new XML namespace, as per the guidelines in 1183 RFC 3688 [RFC3688]. 1185 URI: urn:ietf:params:xml:ns:addDataProviderInfo 1187 Registrant Contact: IETF, ECRIT working group, , as 1188 delegated by the IESG . 1190 XML: 1192 BEGIN 1193 1194 1196 1197 1198 1200 Namespace for Additional Emergency Call Data: 1201 Data Provider Information 1202 1203 1204

Namespace for Additional Data related to an Emergency Call

1205

Data Provider Information

1206

See [TBD: This document].

1207 1208 1209 END 1211 11.4.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo 1213 This section registers a new XML namespace, as per the guidelines in 1214 RFC 3688 [RFC3688]. 1216 URI: urn:ietf:params:xml:ns:addCallSvcInfo 1218 Registrant Contact: IETF, ECRIT working group, , as 1219 delegated by the IESG . 1221 XML: 1223 BEGIN 1224 1225 1227 1228 1229 1231 Namespace for Additional Emergency Call Data: 1232 Service Information 1233 1234 1235

Namespace for Additional Data related to an Emergency Call

1236

Service Information

1237

See [TBD: This document].

1238 1239 1240 END 1242 11.4.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo 1244 This section registers a new XML namespace, as per the guidelines in 1245 RFC 3688 [RFC3688]. 1247 URI: urn:ietf:params:xml:ns:addDataDevInfo 1249 Registrant Contact: IETF, ECRIT working group, , as 1250 delegated by the IESG . 1252 XML: 1254 BEGIN 1255 1256 1258 1259 1260 1262 Namespace for Additional Emergency Call Data: 1263 Device Information 1264 1265 1266

Namespace for Additional Data related to an Emergency Call

1267

Device Information

1268

See [TBD: This document].

1269 1270 1271 END 1273 11.4.4. Registration for urn:ietf:params:xml:ns:addCallSub 1275 This section registers a new XML namespace, as per the guidelines in 1276 RFC 3688 [RFC3688]. 1278 URI: urn:ietf:params:xml:ns:addCallSub 1280 Registrant Contact: IETF, ECRIT working group, , as 1281 delegated by the IESG . 1283 XML: 1285 BEGIN 1286 1287 1289 1290 1291 1293 Namespace for Additional Emergency Call Data: 1294 Owner/Subscriber Information 1295 1296 1297

Namespace for Additional Data related to an Emergency Call

1298

Owner/Subscriber Information

1299

See [TBD: This document].

1300 1301 1302 END 1304 11.5. Schema Registrations 1306 This specification registers four schemas, as per the guidelines in 1307 RFC 3688 [RFC3688]. 1309 URI: 1310 urn:ietf:params:xml:schema:additional-data:addDataProviderInfo 1312 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1313 delegated by the IESG (iesg@ietf.org). 1315 XML: The XML schema can be found in Figure 1. 1317 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 1319 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 1320 delegated by the IESG (iesg@ietf.org). 1322 XML: The XML schema can be found in Figure 2. 1324 URI: urn:ietf:params:xml:schema:additional-data:addDataDevInfo 1326 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1327 delegated by the IESG (iesg@ietf.org). 1329 XML: The XML schema can be found in Figure 3. 1331 URI: urn:ietf:params:xml:schema:additional-data:addCallSub 1333 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1334 delegated by the IESG (iesg@ietf.org). 1336 XML: The XML schema can be found in Figure 4. 1338 12. Acknowledgments 1340 The authors would like to thank the following persons for their work 1341 in the NENA Data Technical Committee: Delaine Arnold (Data Technical 1342 Committee Chair), Marc Berryman, Erica Aubut (Data Technical 1343 Committee Vice-Chair), Susan Sherwood, Ric Atkins, Patty Bluhm, 1344 Eileen Boroski, David Connel, Maryls Davis, Paul-David de la Rosby, 1345 Gordon Chinander, David Froneberger, Marilyn Haroutunian, Roger 1346 Hixson, Rick Jones, Roger Marshall, Tom Muehleisen, Ira Pyles, Carl 1347 Reed, Susan Seet, and Skip Walls. The authors would also like to 1348 thank Tom Breen, Technical Committee Chair/Liaison; Busam, Technical 1349 Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee 1350 Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison; 1351 Roger Hixson, Technical Director; and Rick Jones, Operations Issues 1352 Director for their support and assistance. 1354 [Editor's Note: Add the participants of the NENA Additional Data 1355 Working group lead by Matt Serra.] 1357 13. References 1359 13.1. Normative References 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, March 1997. 1364 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1365 Locators", RFC 2392, August 1998. 1367 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1368 Types", RFC 3023, January 2001. 1370 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1371 A., Peterson, J., Sparks, R., Handley, M., and E. 1372 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1373 June 2002. 1375 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1376 January 2004. 1378 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1379 Format", RFC 4119, December 2005. 1381 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1382 Registration Procedures", BCP 13, RFC 4288, December 2005. 1384 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1385 RFC 6351, August 2011. 1387 13.2. Informational References 1389 [I-D.iab-privacy-considerations] 1390 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and 1391 J. Morris, "Privacy Considerations for Internet 1392 Protocols", draft-iab-privacy-considerations-01 (work in 1393 progress), October 2011. 1395 [I-D.ietf-ecrit-framework] 1396 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1397 "Framework for Emergency Calling using Internet 1398 Multimedia", draft-ietf-ecrit-framework-13 (work in 1399 progress), September 2011. 1401 [I-D.ietf-ecrit-phonebcp] 1402 Rosen, B. and J. Polk, "Best Current Practice for 1403 Communications Services in support of Emergency Calling", 1404 draft-ietf-ecrit-phonebcp-20 (work in progress), 1405 September 2011. 1407 Authors' Addresses 1409 Brian Rosen 1410 NeuStar 1411 470 Conrad Dr. 1412 Mars, PA 16046 1413 US 1415 Phone: +1 724 382 1051 1416 Email: br@brianrosen.net 1418 Hannes Tschofenig 1419 Nokia Siemens Networks 1420 Linnoitustie 6 1421 Espoo 02600 1422 Finland 1424 Phone: +358 (50) 4871445 1425 Email: Hannes.Tschofenig@gmx.net 1426 URI: http://www.tschofenig.priv.at 1428 Roger Marshall 1429 TeleCommunication Systems, Inc. 1430 2401 Elliott Avenue 1431 Seattle, WA 98121 1432 US 1434 Phone: +1 206 792 2424 1435 Email: rmarshall@telecomsys.com 1436 URI: http://www.telecomsys.com