idnits 2.17.00 (12 Aug 2021) /tmp/idnits12447/draft-ietf-ecrit-additional-data-07.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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 256 has weird spacing: '...ndatory which...' == Line 258 has weird spacing: '...itional which...' == Line 261 has weird spacing: '...ptional which...' == Line 270 has weird spacing: '...rovider which...' == Line 273 has weird spacing: '...rmation which...' == (4 more instances...) == 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 (February 26, 2013) is 3370 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 1581, but not defined == Unused Reference: 'I-D.iab-privacy-considerations' is defined on line 2212, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 3 errors (**), 0 flaws (~~), 13 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: August 30, 2013 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 February 26, 2013 12 Additional Data related to an Emergency Call 13 draft-ietf-ecrit-additional-data-07.txt 15 Abstract 17 When an emergency call is sent to a Public Safety Answering Point 18 (PSAP), the device that sends it, as well as any service provider in 19 the path of the call, or access network through which the call 20 originated may have information about the call which the PSAP may be 21 able to use. This document describes an XML data structure to 22 contains such data and a Uniform Resource Identifier (URI) for 23 conveying the data to the PSAP. The URI may point to either an 24 external resource, or the body of the SIP message. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 30, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Block Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Transmitting Blocks of Additional Data . . . . . . . . . . . . 10 64 4.1. Transmitting blocks using Call-Info . . . . . . . . . . . 10 65 4.2. Transmitting blocks by reference using Provided-By . . . . 11 66 4.3. Transmitting blocks by value using Provided-By . . . . . . 12 67 5. Data Provider Information . . . . . . . . . . . . . . . . . . 13 68 5.1. Data Provider String . . . . . . . . . . . . . . . . . . . 13 69 5.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 13 70 5.3. Data Provider ID Series . . . . . . . . . . . . . . . . . 14 71 5.4. Type of Data Provider . . . . . . . . . . . . . . . . . . 14 72 5.5. Data Provider Contact URI . . . . . . . . . . . . . . . . 15 73 5.6. Data Provider Languages(s) Supported . . . . . . . . . . . 16 74 5.7. xCard of Data Provider . . . . . . . . . . . . . . . . . . 16 75 5.8. Subcontractor Principal . . . . . . . . . . . . . . . . . 17 76 5.9. Subcontractor Priority . . . . . . . . . . . . . . . . . . 18 77 5.10. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 19 78 6. Service Information . . . . . . . . . . . . . . . . . . . . . 20 79 6.1. Service Environment . . . . . . . . . . . . . . . . . . . 20 80 6.2. Service Delivered by Provider to End User . . . . . . . . 20 81 6.3. Service Mobility Environment . . . . . . . . . . . . . . . 22 82 6.4. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . . 23 83 7. Device Information . . . . . . . . . . . . . . . . . . . . . . 24 84 7.1. Device Classification . . . . . . . . . . . . . . . . . . 24 85 7.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 26 86 7.3. Device Model Number . . . . . . . . . . . . . . . . . . . 26 87 7.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 27 88 7.5. Type of Device Identifier . . . . . . . . . . . . . . . . 27 89 7.6. Device/Service Specific Additional Data Structure . . . . 28 90 7.7. Device/Service Specific Additional Data Structure Type . . 29 91 7.8. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . . 30 92 8. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 31 93 8.1. xCard for Subscriber\\0x2019s Data . . . . . . . . . . . . 31 94 8.2. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . . 32 95 9. Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 9.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 9.2. emergencyCall.Comment XML Schema . . . . . . . . . . . . . 34 98 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 99 11. Main Telephone Number . . . . . . . . . . . . . . . . . . . . 36 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 39 102 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 103 14.1. Registry creation . . . . . . . . . . . . . . . . . . . . 40 104 14.1.1. Additional Call Data Blocks Registry . . . . . . . . 40 105 14.1.2. Additional Call Data Service Provider Type 106 Registry . . . . . . . . . . . . . . . . . . . . . . 40 107 14.1.3. Additional Call Data Service Delivered Registry . . . 41 108 14.1.4. Additional Call Data Device Classification 109 Registry . . . . . . . . . . . . . . . . . . . . . . 42 110 14.1.5. Additional Call Data Device ID Type Registry . . . . 43 111 14.1.6. Additional Call Data Blocks Registry . . . . . . . . 44 112 14.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 44 113 14.3. URN Sub-Namespace Registration for provided-by 114 Registry Entry . . . . . . . . . . . . . . . . . . . . . . 45 115 14.3.1. Provided-By XML Schema . . . . . . . . . . . . . . . 46 116 14.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 46 117 14.4.1. MIME Content-type Registration for 118 'application/emergencyCall.ProviderInfo+xml' . . . . 46 119 14.4.2. MIME Content-type Registration for 120 'application/emergencyCall.SvcInfo+xml' . . . . . . . 48 121 14.4.3. MIME Content-type Registration for 122 'application/emergencyCall.DevInfo+xml' . . . . . . . 49 123 14.4.4. MIME Content-type Registration for 124 'application/emergencyCall.SubInfo+xml' . . . . . . . 50 125 14.4.5. MIME Content-type Registration for 126 'application/emergencyCall.Comment+xml' . . . . . . . 51 127 14.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 53 128 14.5.1. Registration for 129 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 53 130 14.5.2. Registration for 131 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 53 132 14.5.3. Registration for 133 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 54 134 14.5.4. Registration for 135 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 55 136 14.5.5. Registration for 137 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 56 138 14.5.6. Registration for 139 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 57 140 14.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 58 141 14.7. VCard Parameter Value Registration . . . . . . . . . . . . 59 142 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 143 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 144 16.1. Normative References . . . . . . . . . . . . . . . . . . . 61 145 16.2. Informational References . . . . . . . . . . . . . . . . . 61 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 148 1. Introduction 150 This document extends the basic signaling of an emergency call as 151 described in [RFC6443] and [I-D.ietf-ecrit-phonebcp] in order to 152 carry additional data which may be useful to an entity handling the 153 call. This data is "additional" to the basic signaling used in 154 processing the call. 156 Three general categories of such data are defined, for the caller, 157 the location and the call. An XML data structure is defined for such 158 data, and a means of conveying the data by including a Uniform 159 Resource Identifier (URI) in the SIP signaling which resolves to the 160 data. The data itself may reside on an external resource, or may be 161 contained within the BODY of the SIP message. 163 In general, there are three types of data exchanged: 165 Data Associated with a Call: While information is carried in the 166 call setup procedure itself (as part of the SIP headers as well as 167 in the body of the SIP message), there is additional data known by 168 the device making the call, or a service provider in the path of 169 the call. This information may include the identity and contact 170 information of the service provider, subscriber identity and 171 contact information, the type of service the provider offers, what 172 kind of device is being used, etc. Some data is device or service 173 dependent data. For example, a car telematics system or service 174 may have crash information. A medical monitoring device may have 175 sensor data. While the details of the information may vary by 176 device or service, there needs to be a common way to send such 177 data to a PSAP. 179 Data Associated with a Location: There may be data that is specific 180 to the location not available in the location data structure 181 (PIDF-LO [RFC4119]) itself, such as floor plan, tenant and 182 building owner contact data, HVAC status, etc. 184 Data Associated with a Caller: This is personal data about a caller, 185 such as medical information and emergency contact data. 187 When an emergency call is sent to a PSAP, while there is a rich set 188 of data in the SIP message used for the call setup, the device, as 189 well as any service provider in the path may have even more 190 information that may be useful for a PSAP. 192 This document focuses on additional data associated with an emergency 193 call and a mechanism for transporting it in an existing SIP header 194 field, the Call-Info header, which is specified in Section 20.9 of 195 [RFC3261]. For this purpose a new token, namely 'emergencyCallData' 196 is defined to be carried in the "purpose" parameter. If the 197 "purpose" parameter is set to 'emergencyCallData' then the Call-Info 198 header contains a HTTPS URL that resolves to a data structure with 199 information about the call, or is a CID that allows the data 200 structure itself to be placed in the body of the message. Section 10 201 shows a SIP INVITE example containing such a Call-Info header using 202 the purpose parameter. The "purpose" parameter also contains an 203 indication of what kind of data is available at the URI. 205 Besides a service provider in the path of a call, the access network 206 (which in the IETF emergency call architecture provides location in 207 the form of a PIDF-LO [RFC4119]) also has similar information that 208 may be valuable to the PSAP. This information is not specific to the 209 location itsef, but rather provides descriptive information having to 210 do with the immediate circumstances about the provision of the 211 location (who the access network is, how to contact that entity, what 212 kind of service the access network provides, possibly subscriber 213 data, etc.). This data is similar in nearly every respect with the 214 data known by service providers in the path of the call. When the 215 access network and service provider are separate, the access network 216 doesn't participate in the call path (and hence cannot add a Call- 217 Info' header field), but may provide a PIDF-LO for emergency 218 purposes. The 'provided-by' element of the PIDF-LO is a mechanism 219 for the access network to supply the information. For this reason, 220 this document describes a namespace per [RFC4119] for inclusion in 221 the "provided-by" element of a PDIF-LO for adding information known 222 to the access network. 224 The data described in this document is represented as one or more 225 "blocks" of information. Each of the blocks is a MIME type, and an 226 extensible set of these types constitute the data set. A registry is 227 defined to list the block types that may be included. This document 228 only defines blocks relevant to data associated with the call. Other 229 forms of additional data may use this mechanism to carry data, but 230 those blocks are not defined in this document. 232 Devices or services may have data useful to PSAPs and emergency 233 responders that is specific to the type of device or service 234 providing the data. An example is telematics data available from 235 vehicles equipped with sensors and mechanisms to provide the sensor 236 data (for example, the VEDS data set). The mechanism described in 237 this document can be used to provide such data by defining a MIME 238 type and including a reference to the data in the Call-Info header. 239 PSAPS and emergency responders have to be prepared in advance to 240 handle such data, and may or may not choose to accept it. To control 241 the types of data a PSAP or responder may encounter using this 242 mechanism, a registry of data sets is created by this document. The 243 registry allows the PSAP, responder, or entity processing the call to 244 identify in advance the types of data it is prepared to accept, and 245 fetch or access only those types. 247 2. Terminology 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in RFC 2119 [RFC2119]. 253 In the data block definitions, the "Use:" values are specified as one 254 of: 256 Mandatory which means they MUST be present in the data structure. 258 Conditional which means they MUST be present unless the specified 259 condition is met, in which case the they MAY be present. 261 Optional which means they MAY be present. 263 3. Block Overview 265 The following section defines an initial set of blocks which may be 266 sent by value or by reference in SIP signaling or within a PIDF-LO. 267 For each block, we define the MIME type, and the XML data structure 268 for the block. Blocks are defined for: 270 Data Provider which supplies name and contact information for the 271 entity that created the data. 273 Service Information which supplies information about the service 274 provided by a service provider. 276 Device Information which supplies information about the device 277 placing the call. 279 Owner/Subscriber which supplies information about the owner of the 280 device or the subscriber to the service provider. 282 Comment which provides a way to supply free form human readable text 283 to the PSAP or emergency responders. 285 PSAPs and emergency responders can examine the type of data provided 286 and selectively retrieve the data each is interested in, while 287 forwarding all of it (the values or references) to downstream 288 entities. 290 Blocks can be sent by value (the data in the SIP body or PIDF-LO) or 291 by reference (the data is retrieved via HTTPS from an external 292 server). Data may be provided by the device and/or one or more 293 service providers. For example, the device may provide device 294 specific information by value, a telematics service provider may 295 provide its contact data and data derived from the sensor data (e.g., 296 injury prediction) by reference, and a carrier may provide its 297 contact data by value, all in the same SIP INVITE. 299 The access network MAY supply additional data as well, by including 300 the data within a Provided-By element of a PDIF-LO object it returns 301 for emergency use (e.g., if requested with a HELD "responseTime" 302 attribute of "emergencyRouting" or "emergencyDispatch"). Access 303 networks are expected to normally supply such information by 304 reference (by including an HTTPS URI within the Provided-By element). 305 This document defines a namespace and adds the namespace to the 306 "provided-by" registry defined by PIDF-LO [RFC4119]. 308 4. Transmitting Blocks of Additional Data 310 One or more blocks of data registered in the Emergency Call 311 Additional Data registry as defined in Section 14.1 may be included 312 or referenced in the SIP signaling (using the Call-Info header field) 313 or in the provided-by element of a PIDF-LO. Each block is a MIME 314 type, and any set of blocks may be included. 316 Additional data about a call is defined as a series of MIME objects, 317 each with an XML data structure contained inside. As usual, whenever 318 more than one MIME part is included in the body of a message, MIME- 319 multipart (i.e., 'multipart/mixed') encloses them all. The sections 320 below define the XML schema and MIME types used for each block. When 321 additional data is passed by value in the SIP signaling, each CID URL 322 points to one block in the body. Multiple URIs are used within a 323 Call-Info header field (or multiple Call-Info header fields) to point 324 to multiple blocks. When additional data is provided by reference 325 (in SIP signaling or Provided-By), each HTTPS URL references one 326 block; the data is retrieved with an HTTP Get operation, which 327 returns one of the blocks as an XML object. 329 A registry of allowed types is created by this document. Every block 330 MUST be one of the types in the registry. 332 In regions where callers can elect to suppress certain personally 333 identifying information, the network or PSAP functionality can 334 inspect privacy flags within the SIP headers to determine what 335 information may be passed, stored, or displayed to comply with local 336 policy or law. 338 Each entity adding Additional Information MUST supply the "Data 339 Provider" block. All other blocks are optional, but each entity 340 SHOULD supply any blocks where it has at least some of the 341 information in the block. 343 4.1. Transmitting blocks using Call-Info 345 A URI to a block MAY be inserted in a SIP request or response method 346 (most often INVITE or MESSAGE) with a Call-Info header field 347 containing a purpose of "emergencyCallData" together with the type of 348 data available at the URI. The type of data is denoted by including 349 the root of the MIME type (not including the emergencyCall prefix and 350 the +xml suffix) with a "." separator. For example, when referencing 351 a block with MIME type 'application/emergencyCall.ProviderInfo+xml', 352 the 'purpose' parameter is set to 'emergencyCallData.ProviderInfo'. 353 An example "Call-Info" header field for this would be: 355 Call-Info: https:23sedde3@example.com; 356 purpose="emergencyCallData.ProviderInfo" 358 The Call-info header with purpose='emergencyCallData' MUST only be 359 sent on an emergency call, which can be ascertained by the presence 360 of an emergency service urn in a Route header of a SIP message. 362 If the data is provided by reference, it may be retrieved with an 363 HTTPS Get from the URI. The URI MUST specify an HTTPS scheme, and 364 TLS protection for the data MUST be negotiated. 366 The data may also be supplied by value in a SIP message. In this 367 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 368 referencing the MIME body part. 370 More than one Call-Info header with an emergencyCallData purpose can 371 be expected, but at least one MUST be provided. The device MUST 372 provide one if it knows no service provider is in the path of the 373 call. The device MAY insert one if it uses a service provider. Any 374 service provider in the path of the call MUST insert its own. For 375 example, a device, a telematics service provider in the call path, as 376 well as the mobile carrier handling the call will each provide one. 377 There may be circumstances where there is a service provider who is 378 unaware that the call is an emergency call and cannot reasonably be 379 expected to determine that it is an emergency call. In that case, 380 that service provider is not expected to provide emergencyCallData. 382 4.2. Transmitting blocks by reference using Provided-By 384 The 'emergencyCallDataReference' element is used to transmit an 385 additional data block by reference within a 'Provided-By' element of 386 a PIDF-LO. The 'emergencyCallDataReference' element has two 387 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 388 type of data block referenced. The value of 'ref' is an HTTPS URL 389 that resolves to a data structure with information about the call. 390 The value of 'purpose' is the same as used in a 'Call-Info' header 391 field (as specified in section Section 4.1, Transmitting blocks using 392 Call-Info). 394 For example, to reference a block with MIME type 'application/ 395 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 396 'emergencyCallData.ProviderInfo'. An example 397 'emergencyCallDataReference' element for this would be: 399 402 4.3. Transmitting blocks by value using Provided-By 404 It is RECOMMENDED that access networks supply the data specified in 405 this document by reference, but they MAY provide the data by value. 407 The 'emergencyCallDataValue' element is used to transmit an 408 additional data block by value within a 'Provided-By' element of a 409 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 410 'purpose' to indicate the type of data block contained. The value of 411 'purpose' is the same as used in a 'Call-Info' header field (as 412 specified in section Section 4.1, Transmitting blocks using Call- 413 Info). The same XML structure as would be wrapped in the 414 corresponding MIME type is placed inside the emergencyCallDataValue 415 element. 417 For example: 419 421 423 HooThrooPoo 424 NENA 425 Access Infrastructure Provider 426 427 sip:15555550987@burf.example.com:user=phone 428 429 430 432 Example Provided-By by value 434 5. Data Provider Information 436 This block is intended to be provided by any service provider in the 437 path of the call or the access network provider. It includes 438 identification and contact information. This block SHOULD be 439 provided for every service provider in the path of the call, and the 440 access network provider. Devices MAY use this block to provide 441 identifying information. The MIME subtype is "application/ 442 emergencyCall.ProviderInfo+xml". 444 5.1. Data Provider String 446 Data Element: Data Provider String 448 Use: Required 450 XML Element: 452 Description: This is a plain language string suitable for displaying 453 the name of the service provider that created the additional data 454 structure. If the device created the structure the value is 455 identical to the contact header in the SIP INVITE. 457 Reason for Need: Inform the call taker of the identity of the entity 458 providing the additional call data structure. 460 How Used by Call Taker: Allows the call taker to interpret the data 461 in this structure. The source of the information often influences 462 how the information is used, believed or verified. 464 5.2. Data Provider ID 466 Data Element: Data Provider ID 468 Use: Conditional. Must be provided if the service provider is 469 located in a jurisdiction that maintains such ids. Devices are 470 not required to provide it. 472 XML Element: 473 Description: A jurisdiction specific code for the provider shown in 474 the element that created the structure of the 475 call. This data SHOULD be provided if the local jurisdiction 476 maintains such an ID list. For example, in North America, this 477 would be a "NENA Company ID". Devices SHOULD NOT use this 478 element. 480 Reason for Need: Inform the call taker of the identity of the entity 481 providing the additional call data structure. 483 How Used by Call Taker: Where jurisdictions have lists of providers 484 the Data Provider ID can be useful. 486 5.3. Data Provider ID Series 488 Data Element: Data Provider ID Series 490 Use: Conditional. If Data Provider ID is provided, Data Provider ID 491 Series is required. 493 XML Element: 495 Description: Identifies the issuer of the the ProviderId. A 496 registry will reflect the following valid entries: 498 * NENA 500 * EENA 502 Reason for Need: Identifies how to interpret the Data Provider ID. 504 How Used by Call Taker: Determines which provider ID registry to 505 consult for more information 507 5.4. Type of Data Provider 509 Data Element: Type of Data Provider ID 510 Use: Conditional. If Data Provider ID is provided, Type of Data 511 Provider ID is required. 513 XML Element: 515 Description: Identifies the type of data provider id being supplied 516 in the ProviderId data element. A registry will reflect the 517 following valid entries: 519 * Access Infrastructure Provider 521 * Service Provider 523 * Service Provider Subcontractor 525 * Telematics Provider 527 * Relay Provider 529 * Other 531 Reason for Need: Identifies what kind of data provider this is. 533 How Used by Call Taker: To decide who to contact when further 534 information is needed 536 5.5. Data Provider Contact URI 538 Data Element: Data Provider Contact URI 540 Use: Required 542 XML Element: 544 Description: For a service provider the contact SHOULD be a contact 545 URI. This MUST be a SIP URI. If a telephone number is the 546 contact address it should be provided in the form of 547 sip:telephonenumber@serviceprovider:user=phone. If the call is 548 from a device, this would reflect the contact information of the 549 owner of the device. When provided by a service provider, this 550 would be a URI to a 24/7 support organization tasked to provide 551 PSAP support for this emergency call. 553 Reason for Need: Additional data providers may need to be contacted 554 for error or other unusual circumstances. 556 How Used by Call Taker: To contact the supplier of the additional 557 data for assistance in handling the call. 559 5.6. Data Provider Languages(s) Supported 561 Data Element: Data Provider Language(s) supported 563 Use: Conditional 565 XML Element: 567 Description: The language used by the entity at the Data Provider 568 Contact URI as an alpha 2-character code as defined in ISO 639- 569 1:2002 (http://www.iso.org/iso/catalogue_detail?csnumber=22109) 570 Codes for the representation of names of languages -- Part 1: 571 Alpha-2 code Multiple instances of this element may occur. Order 572 is significant; preferred language should appear first. This data 573 is required if a Data Provider Contact URI is provided. The 574 content must reflect the languages supported at the contact URI. 576 Reason for Need: Information needed to determine if emergency 577 service authority can communicate with the service provider or if 578 an interpreter will be needed. 580 How Used by Call Taker: If call taker cannot speak language(s) 581 supported by the service provider, a translation service will need 582 to be added to the conversation. 584 5.7. xCard of Data Provider 586 Data Element: xCard of Data Provider 587 Use: Optional 589 XML Element: 591 Description: There are many fields in the xCARD and the creator of 592 the data structure is encouraged to provide as much information as 593 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 594 minimum. N should contain name of support group or device owner 595 as appropriate. If more than one TEL property is provided, a 596 parameter from the vCard Property Value registry MUST be specified 597 on each TEL. For encoding of the xCard this specification uses 598 the XML-based encoding specified in [RFC6351]. 600 and is hereinafter referred to as "xCard" 602 Reason for Need: Information needed to determine additional contact 603 information. 605 How Used by Call Taker: Assists call taker by providing additional 606 contact information that may not be included in the SIP invite or 607 the PIDF-LO. 609 5.8. Subcontractor Principal 611 Data Element: Subcontractor Principal 613 XML Element: 615 Description: If the data provider is a subcontractor to another 616 provider such as an access infrastructure provider or telematics 617 provider, this element contains the DataProviderString of the 618 service provider to indicate which provider the subcontractor is 619 working for. This data is required if the Data Provider type is 620 subcontractor. 622 Reason for Need: Identify the entity the subcontractor works for. 624 How Used by Call Taker: Allows the call taker to understand what the 625 relationship between data providers and the service providers in 626 the path of the call are. 628 5.9. Subcontractor Priority 630 Data Element: Subcontractor Priority 632 Use: Required 634 XML Element: 636 Description: If the subcontractor should be contacted first, this 637 element should have a "sub" value. If the access or origination 638 service provider should be contacted first, this element should 639 have a "main" value. This data is required if the Data Provider 640 type is "subcontractor". 642 Reason for Need: Inform the call taker whether the network operator 643 or the subcontractor should be contacted first if support is 644 needed. 646 How Used by Call Taker: To decide which entity to contact first if 647 assistance is needed. 649 5.10. emergencyCall.ProviderInfo XML Schema 651 652 660 663 664 665 666 667 669 670 671 672 674 676 678 680 682 684 686 687 688 689 691 Figure 1: emergencyCall.ProviderInfo XML Schema 693 6. Service Information 695 This block describes the service that the service provider provides 696 to the caller. It SHOULD be included by all SPs in the path of the 697 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 699 6.1. Service Environment 701 Data Element: Service Environment 703 Use: Required 705 XML Element: 707 Description: This element defines whether a call is from a business 708 or residence caller. Currently, the only valid entries are 709 'Business' or 'Residence'. 711 Reason for Need: To assist in determining equipment and manpower 712 requirements. 714 How Used by Call Taker: Information may be used to assist in 715 determining equipment and manpower requirements for emergency 716 responders. As the information is not always available, and the 717 registry is not all encompassing, this is at best advisory 718 information, but since it mimics a similar capability in some 719 current emergency calling systems, it is known to be valuable. 720 The service provider uses its best information (such as a rate 721 plan, facilities used to deliver service or service description) 722 to determine the information and is not responsible for 723 determining the actual characteristics of the location where the 724 call originates from. 726 6.2. Service Delivered by Provider to End User 728 Data Element: Service Delivered by Provider to End User 730 Use: Required 731 XML Element: 733 Description: This defines the type of service the end user has 734 subscribed to. The implied mobility of this service can not be 735 relied upon. A registry defined in this document will reflect the 736 following initial valid entries: 738 * Wireless Telephone Service: Includes Satellite, CDMA, GSM, 739 Wi-Fi, WiMAX, UTMS/WCDMA, LTE (Long Term Evolution) 741 * Fixed Public Pay/Coin telephones: Any coin or credit card 742 operated device. 744 * One way outbound service 746 * Inmate call/service 748 * Soft dialtone/quick service/warm disconnect/suspended 750 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 751 key systems, Shared Tenant Service. 753 * Sensor, unattended: Includes devices that generate DATA ONLY. 754 This is one-way information exchange and there will be no other 755 form of communication. 757 * Sensor, attended: Includes devices that are supported by a 758 monitoring service provider or automatically open a two-way 759 communication path. 761 * Wireline: Plain Old Telephone Service (POTS). 763 * VoIP Telephone Service: A type of service that offers 764 communication over internet protocol, such as Fixed, Nomadic, 765 Mobile, Unknown 767 * Relay Service: a type of service where there is a human 3rd 768 party agent who provides some kind of additional assistance to 769 the caller. Includes sign language relay and telematics 770 services which provide a service assistant on the call. 772 * Remote (off premise extension) 774 There can be more than one value returned. For example, a VoIP 775 inmate telephone service is a reasonable combination. 777 Reason for Need: Knowing the type of service may assist the PSAP 778 with the handling of the call. 780 How Used by Call Taker: Call takers often use this information to 781 determine what kinds of questions to ask callers, and how much to 782 rely on supportive information. An emergency call from a prison 783 is treated differently that a call from a sensor device. As the 784 information is not always available, and the registry is not all 785 encompassing, this is at best advisory information, but since it 786 mimics a similar capability in some current emergency calling 787 systems, it is known to be valuable. 789 6.3. Service Mobility Environment 791 Data Element: Service Mobility Environment 793 Use: Required 795 XML Element: 797 Description: This provides the service providers view of the 798 mobility of the caller. As the service provider may not know the 799 characteristics of the actual access network used, the value not 800 be relied upon. A registry will reflect the following initial 801 valid entries: 803 * Mobile: the device should be able to move at any time 805 * Fixed: the device is not expected to move unless the service is 806 relocated 808 * Nomadic: the device is not expected to move while on a call, 809 but may move between calls 811 Reason for Need: Knowing the service provider's belief of mobility 812 may assist the PSAP with the handling of the call. 814 How Used by Call Taker: To determine whether to assume the location 815 of the caller might change. 817 6.4. emergencyCall.SvcInfo XML Schema 819 820 827 830 831 832 833 835 837 839 841 842 843 844 846 Figure 2: emergencyCall.SvcInfo XML Schema 848 7. Device Information 850 This block provides information about the device used to place the 851 call. It should be provided by any service provider that knows what 852 device is being used, and by the device itself. The mime subtype is 853 "application/emergencyCall.DevInfo+xml". 855 7.1. Device Classification 857 Data Element: Device Classification 859 Use: Optional 861 XML Element: 863 Description: This data element defines the kind of device making the 864 emergency call. If the device provides the data structure, the 865 device information SHOULD be provided. If the service provider 866 provides the structure and it knows what the device is, the 867 service provider SHOULD provide the device information. Often the 868 carrier does not know what the device is. It is possible to 869 receive two Additional Data Associated with a Call data 870 structures, one created by the device and one created by the 871 service provider. This information describes the device, not how 872 it is being used. This data element defines the kind of device 873 making the emergency call. A registry will reflect the following 874 valid entries: 876 * Cordless handset 878 * Fixed phone 880 * Mobile handset 882 * ATA (analog terminal adapter) 884 * Satellite phone 886 * Stationary computing device (alarm system, data sensor) 888 * Guardian devices 890 * Desktop PC 891 * Laptop computing device 893 * Tablet computing device 895 * Alarm system 897 * Data sensor 899 * Personal beacons (spot) 901 * Auto telematics (indicates VEDS data set) 903 * Trucking telematics 905 * Farm equipment telematics 907 * Marine telematics 909 * PDA (personal digital assistant) 911 * PND (personal navigation device) 913 * Smart phone 915 * Internet tablet 917 * Gaming console 919 * Video phone 921 * Other text device 923 * Not Available 925 Reason for Need: The device classification implies the capability of 926 the calling device and assists in identifying the meaning of the 927 emergency call location information that is being presented. For 928 example, does the device require human intervention to initiate a 929 call or is this call the result of programmed instructions? Does 930 the calling device have the ability to update location or 931 condition changes? Is this device interactive or a one-way 932 reporting device? 934 How Used by Call Taker: May assist with location of caller. For 935 example, a cordless handset may be outside or next door. May 936 provide calltaker some context about the caller, the capabilities 937 of the device used for the call or the environment the device is 938 being used in. 940 7.2. Device Manufacturer 942 Data Element: Device Manufacturer 944 Use: Optional 946 XML Element: 948 Description: The plain language name of the manufacturer of the 949 device. 951 Reason for Need: Used by PSAP management for post-mortem 952 investigation/resolution. 954 How Used by Call Taker: Probably not used by calltaker, but by PSAP 955 management. 957 7.3. Device Model Number 959 Data Element: Device Model Number 961 Use: Optional 963 XML Element: 965 Description: Model number of the device. 967 Reason for Need: Used by PSAP management for after action 968 investigation/resolution. 970 How Used by Call Taker: Probably not used by calltaker, but by PSAP 971 management. 973 7.4. Unique Device Identifier 975 Data Element: Unique Device Identifier 977 Use: Optional 979 XML Element: 981 Description: String that identifies the specific device making the 982 call or creating an event. 984 Reason for Need: Uniquely identifies the device as opposed to any 985 signaling identifiers encountered in the call signaling stream. 987 How Used by Call Taker: Probably not used by calltaker they would 988 need to refer to management for investigation. 990 7.5. Type of Device Identifier 992 Data Element: Type of Device Identifier 994 Use: Conditional: must be provided if DeviceID is provided 996 XML Element: 998 Description: Identifies the type of device identifier being 999 generated in the unique device identifier data element. A 1000 registry will reflect the following valid entries: 1002 * MEID (CDMA) 1004 * ESN (Electronic Serial Number -- superseded by MEID) 1006 * MAC (Media Access Control) Address -- IEEE-delegated address of 1007 any of the interfaces of the device with a MAC address (e.g., 1008 Ethernet, WiFi) 1010 * WiMAX device certificate subject unique identifier 1012 * IMEI (International Mobile Equipment Identifier - GSM) 1014 * Unique Device Identifier (UDI) assigned by US FDA for medical 1015 devices 1017 * RFID (Radio Frequency Identification) 1019 * Sensors (types to be identified in a future document version) 1021 * Manufacturer Serial Number 1023 * Other 1025 Reason for Need: Identifies how to interpret the Unique Device 1026 Identifier. 1028 How Used by Call Taker: Additional information that may be used to 1029 assist with call handling. 1031 7.6. Device/Service Specific Additional Data Structure 1033 Data Element: Device/service specific additional data structure 1035 Use: Optional 1037 XML Element: 1039 Description: A URI representing additional data whose schema is 1040 specific to the device or service which created it. An example is 1041 the VEDs structure for a vehicle telematics device. The URI, when 1042 dereferenced, MUST yield a data structure defined by the Device/ 1043 service specific additional data type value. Different data may 1044 be created by each classification; e.g., telematics creates VEDS 1045 data set. 1047 Reason for Need: Provides device/service specific data that may be 1048 used by the call taker and/or responders. 1050 How Used by Call Taker: Provide information to guide call takers to 1051 select appropriate responders, give appropriate pre-arrival 1052 instructions to callers, and advise responders of what to be 1053 prepared for. May be used by responders to guide assistance 1054 provided. 1056 7.7. Device/Service Specific Additional Data Structure Type 1058 Data Element: Type of Device/service specific additional data 1059 structure 1061 Use: Conditional. MUST be provided when Device/service specific 1062 additional URI is provided 1064 XML Element: 1066 Description: Value from a registry defined by this document to 1067 describe the type of data that can be retrieved from the Device/ 1068 service specific additional data structure. Initial values are: 1070 * IEEE 1512 - USDOT Model for traffic incidents 1072 * VEDS 1074 Reason for Need: This data element allows identification of 1075 externally defined schemas, which may have additional data that 1076 may assist in emergency response. 1078 How Used by Call Taker: This data element allows the end user 1079 (calltaker or first responder) to know what type of additional 1080 data may be available to aid in providing the needed emergency 1081 services. 1083 Note: Information which is specific to a location or a caller 1084 (person) should not be placed in this section. 1086 7.8. emergencyCall.DevInfo XML Schema 1088 1089 1096 1099 1100 1101 1102 1104 1106 1108 1110 1112 1114 1116 1117 1118 1119 1121 Figure 3: emergencyCallDevInfo XML Schema 1123 8. Owner/Subscriber Information 1125 This block describes the owner of the device (if provided by the 1126 device) or the subscriber information, if provided by a service 1127 provider. The contact location is not necessarily the location of 1128 the caller or incident, but is rather the nominal contact address. 1129 The mime subtype is "application/emergencyCall.Subscriber+xml". 1131 8.1. xCard for Subscriber\\0x2019s Data 1133 Data Element: xCARD for Subscriber\0x2019s Data 1135 Use: Conditional: Some services (e.g. prepaid phones, initialized 1136 phones, etc.) may not have this information. 1138 XML Element: 1140 Description: Information known by the service provider or device 1141 about the subscriber; e.g., Name, Address, Individual Telephone 1142 Number, Main Telephone Number and any other data. N, ORG (if 1143 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1144 than one TEL property is provided, a parameter from the vCard 1145 Property Value registry MUST be specified on each TEL. 1147 Reason for Need: When the caller is unable to provide information, 1148 this data may be used to obtain it 1150 How Used by Call Taker: Obtaining critical information about the 1151 caller and possibly the location when it is not able to be 1152 obtained otherwise. 1154 8.2. emergencyCall.SubInfo XML Schema 1156 1157 1165 1168 1169 1170 1171 1173 1174 1175 1176 1178 Figure 4: emergencyCall.SubInfo XML Schema 1180 9. Comment 1182 This block Provides a mechanism for the data provider to supply 1183 extra, human readable information to the PSAP. It is not intended 1184 for a general purpose extension mechanism. The mime subtype is 1185 "application/emergencyCall.Comment+xml" 1187 9.1. Comment 1189 Data Element: EmergencyCall.Comment 1191 Use: Optional 1193 XML Element: 1195 Description: Human readable text providing additional information to 1196 the PSAP. 1198 Reason for Need: Explanatory information for values in the data 1199 structure 1201 How Used by Call Taker: To interpret the data provided 1203 9.2. emergencyCall.Comment XML Schema 1205 1206 1213 1216 1217 1218 1219 1221 1222 1223 1224 1226 Figure 5: EmergencyCall.Comment XML Schema 1228 10. Example 1230 INVITE sips:bob@biloxi.example.com SIP/2.0 1231 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1232 Max-Forwards: 70 1233 To: Bob 1234 From: Alice ;tag=9fxced76sl 1235 Call-ID: 3848276298220188511@atlanta.example.com 1236 Call-Info: ;purpose=icon, 1237 ;purpose=info, 1238 1239 ;purpose=emergencyCallData.ProviderInfo 1240 Geolocation: 1241 Geolocation-Routing: no 1242 Accept: application/sdp, application/pidf+xml, 1243 application/emergencyCallProviderinfo+xml 1244 CSeq: 31862 INVITE 1245 Contact: 1246 Content-Type: multipart/mixed; boundary=boundary1 1248 Content-Length: ... 1250 --boundary1 1252 Content-Type: application/sdp 1254 ...SDP goes here 1256 --boundary1 1258 Content-Type: application/pidf+xml 1259 Content-ID: 1261 \0x2026PIDF-LO goes here 1263 --boundary1-- 1265 Content-Type: application/emergencyCall.ProviderInfo+xml 1266 Content-ID: <1234567890@atlanta.example.com> 1268 \0x2026Additional Data goes here 1270 --boundary1-- 1272 Example: Attaching Additional Data via CID to a SIP INVITE 1274 11. Main Telephone Number 1276 In a xCard, used extensively in this document, there is no way to 1277 specify a "Main" telephone number. These numbers are useful to 1278 emergency responders who are called to a large enterprise. This 1279 document adds a new Property Value to the "tel" property of the TYPE 1280 parameter called "main". It can be used in any xCard in additional 1281 data. 1283 12. Security Considerations 1285 The information in this data structure will usually be considered 1286 private. HTTPS is specified to require the provider of the 1287 information to validate the credentials of the requester. While the 1288 creation of a PKI that has global scope may be difficult, the 1289 alternatives to creating devices and services that can provide 1290 critical information securely are more daunting. The provider may 1291 enforce any policy it wishes to use, but PSAPs and responder agencies 1292 should deploy a PKI so that providers of additional data can check 1293 the certificate of the client and decide the appropriate policy to 1294 enforce based on that certificate. 1296 Ideally, the PSAP and emergency responders will be given credentials 1297 signed by an authority trusted by the data provider. In most 1298 circumstances, nationally recognized credentials would be sufficient, 1299 and if the emergency services arranges a PKI, data providers could be 1300 provisioned with the root CA public key for a given nation. Some 1301 nations are developing a PKI for this, and related, purposes. Since 1302 calls could be made from devices where the device and/or the service 1303 provider(s) are not local to the emergency authorities, globally 1304 recognized credentials are useful. This might be accomplished by 1305 extending the notion of the "forest guide" described in [RFC5222] to 1306 allow the forest guide to provide the credential of the PKI root for 1307 areas that it has coverage information for, but standards for such a 1308 mechanism are not yet available. In its absence, the data provider 1309 will need to obtain the root CA credentials for any areas it is 1310 willing to provide additional data by out of band means. With the 1311 credential of the root CA for a national emergency services PKI, the 1312 data provider server can validate the credentials of an entity 1313 requesting additional data by reference. 1315 The data provider also needs a credential that can be verified by the 1316 emergency services to know that it is receiving data from the right 1317 server. The emergency authorities could provide credentials, 1318 distinguishable from credentials it provides to emergency responders 1319 and PSAPs, which could be used to validate data providers. Such 1320 credentials would have to be acceptable to any PSAP or responder that 1321 could receive a call with additional data supplied by that provider. 1322 This would be extensible to global credential validation using the 1323 forest guide as above. In the absence of such credentials, the 1324 emergency authorities could maintain a list of local data providers' 1325 credentials provided to it out of band. At a minimum, the emergency 1326 authorities could obtain a credential from the DNS entry of the 1327 domain in the Addional Data URI to at least validate that the server 1328 is known to the domain providing the URI. 1330 Data provided by devices by reference have similar credential 1331 validation issues to service providers, and the solutions are the 1332 same. 1334 13. Privacy Considerations 1336 There is much private data in this information. Local regulations 1337 may govern what data must be provided in emergency calls, but in 1338 general, the emergency call system is often aided by the kinds of 1339 information described in this document. There is a tradeoff between 1340 the privacy considerations and the utility of the data. Certainly, 1341 if the data cannot be protected, due to failure to establish (by TLS) 1342 a secure connection to the data provider, data SHOULD NOT be sent 1343 unless specifically required by regulation. 1345 14. IANA Considerations 1347 14.1. Registry creation 1349 This document creates a new registry called 'Emergency Call 1350 Additional Data'. The following subregistries are created in 1351 Emergency Call Additional Data: 1353 14.1.1. Additional Call Data Blocks Registry 1355 This document creates a new subregistry called \0x2019Provider ID 1356 Series\0x2019. As defined in [RFC5226], this registry operates under 1357 "Expert Review" rules. The expert should determine that the entity 1358 requesting a new value is a legitimate issuer of service provider IDs 1359 suitable for use in Additional Call Data. 1361 The content of this registry includes: 1363 Name: The identifier which will be used in the ProviderIDSeries 1364 element 1366 Source: The full name of the organization issuing the identifiers 1368 URL: A URL to the organization for further information 1370 The values defined are: 1372 +-----------+-----------+--------------+--------------+ 1373 | Name | Source | URL | 1374 +-----------+--------------------------+--------------+ 1375 | NENA | North American Emergency | www.nena.org | 1376 | | Number Association | | 1377 | EENA | European Emergency | www.eena.org | 1378 | | Number Association | | 1379 +-----------+--------------------------+--------------+ 1380 RFC Editor Note: 1381 replace XXXX in the table above with this documents RFC number 1383 14.1.2. Additional Call Data Service Provider Type Registry 1385 This document creates a new subregistry called \0x2019Service 1386 Provider Type\0x2019. As defined in [RFC5226], this registry 1387 operates under "Expert Review". The expert should determine that the 1388 proposed new value is distinct from existing values and appropriate 1389 for use in the TypeOfServicerProvider element 1391 The content of this registry includes: 1393 Name: Value to be used in TypeOfServiceProvider. 1395 Description: A short description of the type of service provider 1397 The values defined are: 1399 +------------------------------+------------------------------------+ 1400 | Name | Description | 1401 +------------------------------+------------------------------------+ 1402 |Access Infrastructure Provider| Access network service provider | 1403 |Service Provider | Calling or Origination telecom SP | 1404 |Service Provider Subcontractor| A contractor to another kind of SP | 1405 |Telematics Provider | A sensor based SP, especially | 1406 | | vehicle based | 1407 |Relay Provider | A interpretation SP, for example, | 1408 | | video relay for sign language | 1409 | | interpretors | 1410 |Other | Any other type of service provider | 1411 +------------------------------+------------------------------------+ 1412 RFC Editor Note: 1413 replace XXXX in the table above with this documents RFC number 1415 14.1.3. Additional Call Data Service Delivered Registry 1417 This document creates a new registry called \0x2019Additional Call 1418 Data Service Delivered\0x2019. As defined in [RFC5226], this 1419 registry operates under "Expert Review" rules. The expert should 1420 consider whether the proposed service is unique from existing 1421 services and the definition of the service will be clear to 1422 implementors and PSAPS/responders. 1424 The content of this registry includes: 1426 Name: enumeration token of the service. 1428 Description: Short description identifying the service. 1430 The values defined are: 1432 +--------+----------------------------------------+ 1433 | Name | description | 1434 +--------+-------+--------------------------------+ 1435 | Wrless | Wireless Telephone Service: Includes | 1436 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 1437 | | LTE (Long Term Evolution) | 1438 | Coin | Fixed Public Pay/Coin telephones: Any | 1439 | | coin or credit card operated device | 1440 | 1way | One way outbound service | 1441 | Prison | Inmate call/service | 1442 | Temp | Soft dialtone/quick service/warm | 1443 | | disconnect/suspended | 1444 | MLTS | Multi-line telephone system: Includes | 1445 | | all PBX, Centrex, key systems, | 1446 | | Shared Tenant Service | 1447 | SenseU | Sensor, unattended: Includes devices | 1448 | | that generate DATA ONLY. This is | 1449 | | one-way information exchange and | 1450 | | there will be no other form of | 1451 | | communication | 1452 | SenseA | Sensor, attended: Includes devices | 1453 | | that are supported by a monitoring | 1454 | | service provider or automatically | 1455 | | open a two-way communication path | 1456 | POTS | Wireline: Plain Old Telephone Service | 1457 | VOIP | VoIP Telephone Service: A type of | 1458 | | service that offers communication | 1459 | | over internet protocol, such as Fixed| 1460 | | Nomadic, Mobile, ... | 1461 +--------+-------+--------------------------------+ 1463 14.1.4. Additional Call Data Device Classification Registry 1465 This document creates a new registry called \0x2019Additional Call 1466 Data Device Classification\0x2019. As defined in [RFC5226], this 1467 registry operates under "Expert Review" rules. The expert should 1468 consider whether the proposed class is unique from existing classes 1469 and the definition of the class will be clear to implementors and 1470 PSAPS/responders. 1472 The content of this registry includes: 1474 Name: enumeration token of the device classification. 1476 Description: Short description identifying the device type. 1478 The values defined are: 1480 +--------+----------------------------------------+ 1481 | Name | description | 1482 +--------+-------+--------------------------------+ 1483 |Cordless| Cordless handset | 1484 | Fixed | Fixed phone | 1485 | Mobile | Mobile handset | 1486 | ATA | analog terminal adapter | 1487 |Satphone| Satellite phone | 1488 | FSense | Stationary computing device (alarm | 1489 | | system, data sensor) | 1490 | Guard | Guardian devices | 1491 | Desktop| Desktop PC | 1492 | Laptop | Laptop computing device | 1493 | Tablet | Tablet computing device | 1494 | Alarm | Alarm system | 1495 | MSense | Mobile Data sensor | 1496 | Beacon | Personal beacons (spot) | 1497 | Auto | Auto telematics | 1498 | Truck | Truck telematics | 1499 | Farm | Farm equipment telematics | 1500 | Marine | Marine telematics | 1501 | PDA | Personal digital assistant | 1502 | PND | Personal navigation device) | 1503 | SmrtPhn| Smart phone | 1504 | Itab | Internet tablet | 1505 | Game | Gaming console | 1506 | Video | Video phone | 1507 | Text | Other text device | 1508 | NA | Not Available | 1509 +--------+----------------------------------------+ 1511 14.1.5. Additional Call Data Device ID Type Registry 1513 This document creates a new registry called \0x2019Additional Call 1514 Data Device ID Type\0x2019. As defined in [RFC5226], this registry 1515 operates under "Expert Review" rules. The expert should ascertain 1516 that the proposed type is well understood, and provides the 1517 information useful to PSAPs and responders to uniquely identify a 1518 device. 1520 The content of this registry includes: 1522 Name: enumeration token of the device id type. 1524 Description: Short description identifying the type of device id. 1526 The values defined are: 1528 +--------+----------------------------------------+ 1529 | Name | description | 1530 +--------+-------+--------------------------------+ 1531 | MEID | Mobile Equipment Identifier (CDMA) | 1532 | ESN | Electronic Serial Number(GSM) | 1533 | MAC | Media Access Control Address (IEEE) | 1534 | WiMAX | device certificate unique id | 1535 | IMEI | International Mobile Equipment ID (GSM)| 1536 | UDI | Unique Device Identifier (medical) | 1537 | RFID | Radio Frequency Identification | 1538 | SN | Manufacturer Serial Number | 1539 +--------+----------------------------------------+ 1541 14.1.6. Additional Call Data Blocks Registry 1543 This document creates a new subregistry called \0x2019Additional Call 1544 Data Blocks\0x2019 in the purpose registry established by RFC3261. 1545 As defined in [RFC5226], this registry operates under "Expert Review" 1546 and "Specification Required" rules. The expert is responsible for 1547 verifying that the document contains a complete and clear 1548 specification of the block and the block does not obviously duplicate 1549 existing blocks. 1551 The content of this registry includes: 1553 Name: Element Name of enclosing block. 1555 Reference: The document that describes the block 1557 The values defined are: 1559 +-------------+-----------+ 1560 | Name | Reference | 1561 +-------------+-----------+ 1562 |ProviderInfo | RFCXXXX | 1563 | SvcInfo | RFCXXXX | 1564 | DevInfo | RFCXXXX | 1565 | Subscriber | RFCXXXX | 1566 | Comment | RFCXXXX | 1567 +-------------+-----------+ 1568 RFC Editor Note: 1569 replace XXXX in the table above with this documents RFC number 1571 14.2. 'emergencyCallData' Purpose Parameter Value 1573 This document defines the 'emergencyCall' value for the "purpose" 1574 parameter of the Call-Info header field. The Call-Info header and 1575 the corresponding registry for the 'purpose' parameter was 1576 established with RFC 3261 [RFC3261]. 1578 Header Parameter New 1579 Field Name Value Reference 1580 ---------- --------- ----------------- --------- 1581 Call-Info purpose emergencyCall [This RFC] 1583 14.3. URN Sub-Namespace Registration for provided-by Registry Entry 1585 This section registers the namespace specified in Section 14.5.1 in 1586 the provided-by registry established by RFC 4119, for usage within 1587 the 'provided-by' element of a PIDF-LO. 1589 14.3.1. Provided-By XML Schema 1591 1592 1601 1604 1605 1606 1607 1608 1610 1611 1612 1613 1615 1617 1618 1619 1621 1622 1624 1625 1627 Figure 6: Provided-By XML Schema 1629 14.4. MIME Registrations 1631 14.4.1. MIME Content-type Registration for 'application/ 1632 emergencyCall.ProviderInfo+xml' 1634 This specification requests the registration of a new MIME type 1635 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1636 RFC 3023 [RFC3023]. 1638 MIME media type name: application 1640 MIME subtype name: emergencyCall.ProviderInfo+xml 1642 Mandatory parameters: none 1644 Optional parameters: charset 1646 Indicates the character encoding of enclosed XML. 1648 Encoding considerations: 1650 Uses XML, which can employ 8-bit characters, depending on the 1651 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1653 Security considerations: 1655 This content type is designed to carry the data provider 1656 information, which is a sub-category of additional data about an 1657 emergency call. 1659 Since this data contains personal information appropriate 1660 precautions have to be taken to limit unauthorized access, 1661 inappropriate disclosure to third parties, and eavesdropping of 1662 this information. Please refer to Section 12 and Section 13 for 1663 more information. 1665 Interoperability considerations: None 1667 Published specification: [TBD: This specification] 1669 Applications which use this media type: Emergency Services 1671 Additional information: 1673 Magic Number: None 1675 File Extension: .xml 1677 Macintosh file type code: 'TEXT' 1679 Person and email address for further information: Hannes 1680 Tschofenig, Hannes.Tschofenig@gmx.net 1681 Intended usage: LIMITED USE 1683 Author: This specification is a work item of the IETF ECRIT 1684 working group, with mailing list address . 1686 Change controller: The IESG 1688 14.4.2. MIME Content-type Registration for 'application/ 1689 emergencyCall.SvcInfo+xml' 1691 This specification requests the registration of a new MIME type 1692 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1693 RFC 3023 [RFC3023]. 1695 MIME media type name: application 1697 MIME subtype name: emergencyCall.SvcInfo+xml 1699 Mandatory parameters: none 1701 Optional parameters: charset 1703 Indicates the character encoding of enclosed XML. 1705 Encoding considerations: 1707 Uses XML, which can employ 8-bit characters, depending on the 1708 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1710 Security considerations: 1712 This content type is designed to carry the service information, 1713 which is a sub-category of additional data about an emergency 1714 call. 1716 Since this data contains personal information appropriate 1717 precautions have to be taken to limit unauthorized access, 1718 inappropriate disclosure to third parties, and eavesdropping of 1719 this information. Please refer to Section 12 and Section 13 for 1720 more information. 1722 Interoperability considerations: None 1724 Published specification: [TBD: This specification] 1726 Applications which use this media type: Emergency Services 1727 Additional information: 1729 Magic Number: None 1731 File Extension: .xml 1733 Macintosh file type code: 'TEXT' 1735 Person and email address for further information: Hannes 1736 Tschofenig, Hannes.Tschofenig@gmx.net 1738 Intended usage: LIMITED USE 1740 Author: This specification is a work item of the IETF ECRIT 1741 working group, with mailing list address . 1743 Change controller: The IESG 1745 14.4.3. MIME Content-type Registration for 'application/ 1746 emergencyCall.DevInfo+xml' 1748 This specification requests the registration of a new MIME type 1749 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1750 RFC 3023 [RFC3023]. 1752 MIME media type name: application 1754 MIME subtype name: emergencyCall.DevInfo+xml 1756 Mandatory parameters: none 1758 Optional parameters: charset 1760 Indicates the character encoding of enclosed XML. 1762 Encoding considerations: 1764 Uses XML, which can employ 8-bit characters, depending on the 1765 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1767 Security considerations: 1769 This content type is designed to carry the device information 1770 information, which is a sub-category of additional data about an 1771 emergency call. 1773 Since this data contains personal information appropriate 1774 precautions have to be taken to limit unauthorized access, 1775 inappropriate disclosure to third parties, and eavesdropping of 1776 this information. Please refer to Section 12 and Section 13 for 1777 more information. 1779 Interoperability considerations: None 1781 Published specification: [TBD: This specification] 1783 Applications which use this media type: Emergency Services 1785 Additional information: 1787 Magic Number: None 1789 File Extension: .xml 1791 Macintosh file type code: 'TEXT' 1793 Person and email address for further information: Hannes 1794 Tschofenig, Hannes.Tschofenig@gmx.net 1796 Intended usage: LIMITED USE 1798 Author: This specification is a work item of the IETF ECRIT 1799 working group, with mailing list address . 1801 Change controller: The IESG 1803 14.4.4. MIME Content-type Registration for 'application/ 1804 emergencyCall.SubInfo+xml' 1806 This specification requests the registration of a new MIME type 1807 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1808 RFC 3023 [RFC3023]. 1810 MIME media type name: application 1812 MIME subtype name: emergencyCall.SubInfo+xml 1814 Mandatory parameters: none 1816 Optional parameters: charset 1818 Indicates the character encoding of enclosed XML. 1820 Encoding considerations: 1822 Uses XML, which can employ 8-bit characters, depending on the 1823 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1825 Security considerations: 1827 This content type is designed to carry owner/subscriber 1828 information, which is a sub-category of additional data about an 1829 emergency call. 1831 Since this data contains personal information appropriate 1832 precautions have to be taken to limit unauthorized access, 1833 inappropriate disclosure to third parties, and eavesdropping of 1834 this information. Please refer to Section 12 and Section 13 for 1835 more information. 1837 Interoperability considerations: None 1839 Published specification: [TBD: This specification] 1841 Applications which use this media type: Emergency Services 1843 Additional information: 1845 Magic Number: None 1847 File Extension: .xml 1849 Macintosh file type code: 'TEXT' 1851 Person and email address for further information: Hannes 1852 Tschofenig, Hannes.Tschofenig@gmx.net 1854 Intended usage: LIMITED USE 1856 Author: This specification is a work item of the IETF ECRIT 1857 working group, with mailing list address . 1859 Change controller: The IESG 1861 14.4.5. MIME Content-type Registration for 'application/ 1862 emergencyCall.Comment+xml' 1864 This specification requests the registration of a new MIME type 1865 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1866 RFC 3023 [RFC3023]. 1868 MIME media type name: application 1870 MIME subtype name: emergencyCall.Comment+xml 1872 Mandatory parameters: none 1874 Optional parameters: charset 1876 Indicates the character encoding of enclosed XML. 1878 Encoding considerations: 1880 Uses XML, which can employ 8-bit characters, depending on the 1881 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1883 Security considerations: 1885 This content type is designed to carry a comment, which is a sub- 1886 category of additional data about an emergency call. 1888 This data may contain personal information. Appropriate 1889 precautions may have to be taken to limit unauthorized access, 1890 inappropriate disclosure to third parties, and eavesdropping of 1891 this information. Please refer to Section 12 and Section 13 for 1892 more information. 1894 Interoperability considerations: None 1896 Published specification: [TBD: This specification] 1898 Applications which use this media type: Emergency Services 1900 Additional information: 1902 Magic Number: None 1904 File Extension: .xml 1906 Macintosh file type code: 'TEXT' 1908 Person and email address for further information: Hannes 1909 Tschofenig, Hannes.Tschofenig@gmx.net 1911 Intended usage: LIMITED USE 1913 Author: This specification is a work item of the IETF ECRIT 1914 working group, with mailing list address . 1916 Change controller: The IESG 1918 14.5. URN Sub-Namespace Registration 1920 14.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 1922 This section registers a new XML namespace, as per the guidelines in 1923 RFC 3688 [RFC3688]. 1925 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 1927 Registrant Contact: IETF, ECRIT working group, , as 1928 delegated by the IESG . 1930 XML: 1932 BEGIN 1933 1934 1936 1937 1938 1940 Namespace for Additional Emergency Call Data 1941 1942 1943

Namespace for Additional Data related to an Emergency Call

1944

See [TBD: This document].

1945 1946 1947 END 1949 14.5.2. Registration for 1950 urn:ietf:params:xml:ns:emergencyCallProviderInfo 1952 This section registers a new XML namespace, as per the guidelines in 1953 RFC 3688 [RFC3688]. 1955 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 1957 Registrant Contact: IETF, ECRIT working group, , as 1958 delegated by the IESG . 1960 XML: 1962 BEGIN 1963 1964 1966 1967 1968 1970 Namespace for Additional Emergency Call Data: 1971 Data Provider Information 1972 1973 1974

Namespace for Additional Data related to an Emergency Call

1975

Data Provider Information

1976

See [TBD: This document].

1977 1978 1979 END 1981 14.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 1983 This section registers a new XML namespace, as per the guidelines in 1984 RFC 3688 [RFC3688]. 1986 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 1988 Registrant Contact: IETF, ECRIT working group, , as 1989 delegated by the IESG . 1991 XML: 1993 BEGIN 1994 1995 1997 1998 1999 2001 Namespace for Additional Emergency Call Data: 2002 Service Information 2003 2004 2005

Namespace for Additional Data related to an Emergency Call

2006

Service Information

2007

See [TBD: This document].

2008 2009 2010 END 2012 14.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 2014 This section registers a new XML namespace, as per the guidelines in 2015 RFC 3688 [RFC3688]. 2017 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 2019 Registrant Contact: IETF, ECRIT working group, , as 2020 delegated by the IESG . 2022 XML: 2024 BEGIN 2025 2026 2028 2029 2030 2032 Namespace for Additional Emergency Call Data: 2033 Device Information 2034 2035 2036

Namespace for Additional Data related to an Emergency Call

2037

Device Information

2038

See [TBD: This document].

2039 2040 2041 END 2043 14.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 2045 This section registers a new XML namespace, as per the guidelines in 2046 RFC 3688 [RFC3688]. 2048 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 2050 Registrant Contact: IETF, ECRIT working group, , as 2051 delegated by the IESG . 2053 XML: 2055 BEGIN 2056 2057 2059 2060 2061 2063 Namespace for Additional Emergency Call Data: 2064 Owner/Subscriber Information 2065 2066 2067

Namespace for Additional Data related to an Emergency Call

2068

Owner/Subscriber Information

2069

See [TBD: This document].

2070 2071 2072 END 2074 14.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 2076 This section registers a new XML namespace, as per the guidelines in 2077 RFC 3688 [RFC3688]. 2079 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 2081 Registrant Contact: IETF, ECRIT working group, , as 2082 delegated by the IESG . 2084 XML: 2086 BEGIN 2087 2088 2090 2091 2092 2094 Namespace for Additional Emergency Call Data:Comment 2095 2096 2097

Namespace for Additional Data related to an Emergency Call

2098

Comment

2099

See [TBD: This document].

2100 2101 2102 END 2104 14.6. Schema Registrations 2106 This specification registers five schemas, as per the guidelines in 2107 RFC 3688 [RFC3688]. 2109 URI: urn:ietf:params:xml:schema:additional- 2110 data:emergencyCallProviderInfo 2112 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2113 delegated by the IESG (iesg@ietf.org). 2115 XML: The XML schema can be found in Figure 1. 2117 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2119 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2120 delegated by the IESG (iesg@ietf.org). 2122 XML: The XML schema can be found in Figure 2. 2124 URI: 2125 urn:ietf:params:xml:schema:additional-data:emergencyCallDevInfo 2127 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2128 delegated by the IESG (iesg@ietf.org). 2130 XML: The XML schema can be found in Figure 3. 2132 URI: 2133 urn:ietf:params:xml:schema:additional-data:emergencyCall.SubInfo 2135 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2136 delegated by the IESG (iesg@ietf.org). 2138 XML: The XML schema can be found in Section 8.2. 2140 URI: 2141 urn:ietf:params:xml:schema:additional-data:emergencyCall.Comment 2143 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2144 delegated by the IESG (iesg@ietf.org). 2146 XML: The XML schema can be found in Section 9.2. 2148 14.7. VCard Parameter Value Registration 2150 This document registers a new value in the vCARD Parameter Values 2151 registry as defined by [RFC6350] with the following template: 2153 Value: main 2155 Purpose: The main telephone number, typically of an enterprise, as 2156 opposed to a direct dial number of an individual employee 2158 Conformance: This value can be used with the "TYPE" parameter 2159 applied on the "TEL" property. 2161 Example(s): 2162 TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-9000 2164 15. Acknowledgments 2166 This work was originally started in NENA and has benefitted from a 2167 large number of participants in NENA standardization efforts, 2168 originally in the Long Term Definition Working Group, the Data 2169 Technical Committee and most recently the Additional Data working 2170 group. The authors are grateful for the initial work and extended 2171 comments provided by the many NENA participants. 2173 16. References 2175 16.1. Normative References 2177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2178 Requirement Levels", BCP 14, RFC 2119, March 1997. 2180 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2181 Locators", RFC 2392, August 1998. 2183 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2184 Types", RFC 3023, January 2001. 2186 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2187 A., Peterson, J., Sparks, R., Handley, M., and E. 2188 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2189 June 2002. 2191 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2192 January 2004. 2194 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2195 Format", RFC 4119, December 2005. 2197 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2198 Registration Procedures", RFC 4288, December 2005. 2200 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2201 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2202 May 2008. 2204 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2205 August 2011. 2207 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 2208 RFC 6351, August 2011. 2210 16.2. Informational References 2212 [I-D.iab-privacy-considerations] 2213 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2214 Morris, J., Hansen, M., and R. Smith, "Privacy 2215 Considerations for Internet Protocols", 2216 draft-iab-privacy-considerations-03 (work in progress), 2217 July 2012. 2219 [I-D.ietf-ecrit-phonebcp] 2220 Rosen, B. and J. Polk, "Best Current Practice for 2221 Communications Services in support of Emergency Calling", 2222 draft-ietf-ecrit-phonebcp-20 (work in progress), 2223 September 2011. 2225 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 2226 Tschofenig, "LoST: A Location-to-Service Translation 2227 Protocol", RFC 5222, August 2008. 2229 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2230 "Framework for Emergency Calling Using Internet 2231 Multimedia", RFC 6443, December 2011. 2233 Authors' Addresses 2235 Brian Rosen 2236 NeuStar 2237 470 Conrad Dr. 2238 Mars, PA 16046 2239 US 2241 Phone: +1 724 382 1051 2242 Email: br@brianrosen.net 2244 Hannes Tschofenig 2245 Nokia Siemens Networks 2246 Linnoitustie 6 2247 Espoo 02600 2248 Finland 2250 Phone: +358 (50) 4871445 2251 Email: Hannes.Tschofenig@gmx.net 2252 URI: http://www.tschofenig.priv.at 2254 Roger Marshall 2255 TeleCommunication Systems, Inc. 2256 2401 Elliott Avenue 2257 Seattle, WA 98121 2258 US 2260 Phone: +1 206 792 2424 2261 Email: rmarshall@telecomsys.com 2262 URI: http://www.telecomsys.com 2264 Randall Gellens 2265 Qualcomm Technologies, Inc. 2266 5775 Morehouse Drive 2267 San Diego, CA 92121 2268 US 2270 Email: rg+ietf@qti.qualcomm.com