idnits 2.17.00 (12 Aug 2021) /tmp/idnits64183/draft-ietf-ecrit-additional-data-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 197 has weird spacing: '...rameter also ...' == Line 1493 has weird spacing: '...ll-Info pur...' == 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 18, 2013) is 3378 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 1493, but not defined == Unused Reference: 'I-D.iab-privacy-considerations' is defined on line 2110, 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: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B.R. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: August 20, 2013 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 February 18, 2013 12 Additional Data related to an Emergency Call 13 draft-ietf-ecrit-additional-data-06.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 20, 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 (http://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Block Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Transmitting Blocks of Additional Data . . . . . . . . . . . . 7 63 4.1. Transmitting blocks using Call-Info . . . . . . . . . . . 7 64 4.2. Transmitting blocks by reference using Provided-By . . . . 8 65 4.3. Transmitting blocks by value using Provided-By . . . . . . 9 66 5. Data Provider Information . . . . . . . . . . . . . . . . . . 9 67 5.1. Data Provider String . . . . . . . . . . . . . . . . . . . 9 68 5.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 10 69 5.3. Data Provider ID Series . . . . . . . . . . . . . . . . . 10 70 5.4. Type of Data Provider . . . . . . . . . . . . . . . . . . 11 71 5.5. Data Provider Contact URI . . . . . . . . . . . . . . . . 12 72 5.6. Data Provider Languages(s) Supported . . . . . . . . . . . 12 73 5.7. xCard of Data Provider . . . . . . . . . . . . . . . . . . 13 74 5.8. Subcontractor Principal . . . . . . . . . . . . . . . . . 13 75 5.9. Subcontractor Priority . . . . . . . . . . . . . . . . . . 14 76 5.10. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 14 77 6. Service Information . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Service Environment . . . . . . . . . . . . . . . . . . . 15 79 6.2. Service Delivered by Provider to End User . . . . . . . . 16 80 6.3. Service Mobility Environment . . . . . . . . . . . . . . . 17 81 6.4. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . . 18 82 7. Device Information . . . . . . . . . . . . . . . . . . . . . . 18 83 7.1. Device Classification . . . . . . . . . . . . . . . . . . 19 84 7.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 20 85 7.3. Device Model Number . . . . . . . . . . . . . . . . . . . 21 86 7.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 21 87 7.5. Type of Device Identifier . . . . . . . . . . . . . . . . 22 88 7.6. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . . 22 89 8. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 23 90 8.1. xCard for Subscriber\0x2019s Data . . . . . . . . . . . . 23 91 8.2. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . . 24 92 9. Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9.2. emergencyCall.Comment XML Schema . . . . . . . . . . . . . 25 95 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 11. Main Telephone Number . . . . . . . . . . . . . . . . . . . . 26 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 27 99 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 100 14.1. Registry creation . . . . . . . . . . . . . . . . . . . . 28 101 14.1.1. Additional Call Data Blocks Registry . . . . . . . . 28 102 14.1.2. Additional Call Data Service Provider Type Registry . 28 103 14.1.3. Additional Call Data Service Delivered Registry . . . 29 104 14.1.4. Additional Call Data Device Classification Registry . 30 105 14.1.5. Additional Call Data Device ID Type Registry . . . . 31 106 14.1.6. Additional Call Data Blocks Registry . . . . . . . . 32 107 14.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 32 108 14.3. URN Sub-Namespace Registration for provided-by Registry 109 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 14.3.1. Provided-By XML Schema . . . . . . . . . . . . . . . 33 111 14.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 33 112 14.4.1. MIME Content-type Registration for 113 'application/emergencyCall.ProviderInfo+xml' . . . . 34 114 14.4.2. MIME Content-type Registration for 115 'application/emergencyCall.SvcInfo+xml' . . . . . . . 35 116 14.4.3. MIME Content-type Registration for 117 'application/emergencyCall.DevInfo+xml' . . . . . . . 36 118 14.4.4. MIME Content-type Registration for 119 'application/emergencyCall.SubInfo+xml' . . . . . . . 37 120 14.4.5. MIME Content-type Registration for 121 'application/emergencyCall.Comment+xml' . . . . . . . 38 122 14.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 39 123 14.5.1. Registration for 124 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 39 125 14.5.2. Registration for 126 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 40 127 14.5.3. Registration for 128 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 40 129 14.5.4. Registration for 130 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 41 131 14.5.5. Registration for 132 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 42 133 14.5.6. Registration for 134 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 42 135 14.6. Schema Registrations . . . . . . . . . . . . . . . . . . 43 136 14.7. VCard Parameter Value Registration . . . . . . . . . . . 44 137 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 138 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 139 16.1. Normative References . . . . . . . . . . . . . . . . . . 44 140 16.2. Informational References . . . . . . . . . . . . . . . . 45 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 143 1. Introduction 145 This document extends the basic signaling of an emergency call as 146 described in [RFC6443] and [I-D.ietf-ecrit-phonebcp] in order to 147 carry additional data which may be useful to an entity handling the 148 call. This data is "additional" to the basic signaling used in 149 processing the call. 151 Three general categories of such data are defined, for the caller, 152 the location, the call, and the PSAP. An XML data structure is 153 defined for such data, and a means of conveying the data by including 154 a Uniform Resource Identifier (URI) in the SIP signaling which 155 resolves to the data. The data itself may reside on an external 156 resource, or may be contained within the BODY of the SIP message. 158 In general, there are three types of data exchanged: 160 Data Associated with a Call: While information is carried in the call 161 setup procedure itself (as part of the SIP headers as well as in 162 the body of the SIP message), there is additional data known by 163 the device making the call, or a service provider in the path of 164 the call. This information may include the identity and contact 165 information of the service provider, subscriber identity and 166 contact information, the type of service the provider offers, what 167 kind of device is being used, etc. Some data is device or service 168 dependent data. For example, a car telematics system or service 169 may have crash information. A medical monitoring device may have 170 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 172 data to a PSAP. 174 Data Associated with a Location: There may be data that is specific 175 to the location not available in the location data structure 176 (PIDF-LO [RFC4119]) itself, such as floor plan, tenant and 177 building owner contact data, HVAC status, etc. 179 Data Associated with a Caller: This is personal data about a caller, 180 such as medical information and emergency contact data. 182 When an emergency call is sent to a PSAP, while there is a rich set 183 of data in the SIP message used for the call setup, the device, as 184 well as any service provider in the path may have even more 185 information that may be useful for a PSAP. 187 This document focuses on additional data associated with an emergent 188 call and a mechanism for transporting it in an existing SIP header 189 field, the Call-Info header, which is specified in Section 20.9 of 190 [RFC3261]. For this purpose a new token, namely 'emergencyCallData' 191 is defined to be carried in the "purpose" parameter. If the 192 "purpose" parameter is set to 'emergencyCallData' then the Call-Info 193 header contains a HTTPS URL that resolves to a data structure with 194 information about the call, or is a CID that allows the data 195 structure itself to be placed in the body of the message. Section 10 196 shows a SIP INVITE example containing such a Call-Info header using 197 the purpose parameter. The "purpose" parameter also contains an 198 indication of what kind of data is available at the URI. 200 Besides a service provider in the path of a call, the access network 201 (which in the IETF emergency call architecture provides location in 202 the form of a PIDF-LO [RFC4119]) also has similar information that 203 may be valuable to the PSAP. This information is not specific to the 204 location itsef, but rather provides descriptive information having to 205 do with the immediate circumstances about the provision of the 206 location (who the access network is, how to contact that entity, what 207 kind of service the access network provides, possibly subscriber 208 data, etc.). This data is similar in nearly every respect with the 209 data known by service providers in the path of the call. When the 210 access network and service provider are separate, the access network 211 doesn't participate in the call path (and hence cannot add a Call- 212 Info' header field), but may provide a PIDF-LO for emergency 213 purposes. The 'provided-by' element of the PIDF-LO is a mechanism 214 for the access network to supply the information. For this reason, 215 this document describes a namespace per [RFC4119] for inclusion in 216 the "provided-by" element of a PDIF-LO for adding information known 217 to the access network. 219 The data described in this document is represented as one or more 220 "blocks" of information. Each of the blocks is a MIME type, and an 221 extensible set of these types constitute the data set. A registry is 222 defined to list the block types that may be included. This document 223 only defines blocks relevant to data associated with the call. Other 224 forms of additional data may use this mechanism to carry data, but 225 those blocks are not defined in this document. 227 Devices or services may have data useful to PSAPs and emergency 228 responders that is specific to the type of device or service 229 providing the data. An example is telematics data available from 230 vehicles equipped with sensors and mechanisms to provide the sensor 231 data (for example, the VEDS data set). The mechanism described in 232 this document can be used to provide such data by defining a MIME 233 type and including a reference to the data in the Call-Info header. 234 PSAPS and emergency responders have to be prepared in advance to 235 handle such data, and may or may not choose to accept it. To control 236 the types of data a PSAP or responder may encounter using this 237 mechanism, a registry of data sets is created by this document. The 238 registry allows the PSAP, responder, or entity processing the call to 239 identify in advance the types of data it is prepared to accept, and 240 fetch or access only those types. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in RFC 2119 [RFC2119]. 248 In the data block definitions, the "Use:" values are specified as one 249 of: 251 Mandatory which means they MUST be present in the data structure. 253 Conditional which means they MUST be present unless the specified 254 condition is met, in which case the they MAY be present. 256 Optional which means they MAY be present. 258 3. Block Overview 260 The following section defines an initial set of blocks which may be 261 sent by value or by reference in SIP signaling or within a PIDF-LO. 262 For each block, we define the MIME type, and the XML data structure 263 for the block. Blocks are defined for: 265 Data Provider which supplies name and contact information for the 266 entity that created the data. 268 Service Information which supplies information about the service 269 provided by a service provider. 271 Device Information which supplies information about the device 272 placing the call. 274 Owner/Subscriber which supplies information about the owner of the 275 device or the subscriber to the service provider. 277 Comment which provides a way to supply free form human readable text 278 to the PSAP or emergency responders. 280 PSAPs and emergency responders can examine the type of data provided 281 and selectively retrieve the data each is interested in, while 282 forwarding all of it (the values or references) to downstream 283 entities. 285 Blocks can be sent by value (the data in the SIP body or PIDF-LO) or 286 by reference (the data is retrieved via HTTPS from an external 287 server). Data may be provided by the device and/or one or more 288 service providers. For example, the device may provide device 289 specific information by value, a telematics service provider may 290 provide its contact data and data derived from the sensor data (e.g., 291 injury prediction) by reference, and a carrier may provide its 292 contact data by value, all in the same SIP INVITE. 294 The access network MAY supply additional data as well, by including 295 the data within a Provided-By element of a PDIF-LO object it returns 296 for emergency use (e.g., if requested with a HELD "responseTime" 297 attribute of "emergencyRouting" or "emergencyDispatch"). Access 298 networks are expected to normally supply such information by 299 reference (by including an HTTPS URI within the Provided-By element). 300 This document defines a namespace and adds the namespace to the 301 "provided-by" registry defined by PIDF-LO [RFC4119]. 303 4. Transmitting Blocks of Additional Data 305 One or more blocks of data registered in the Emergency Call 306 Additional Data registry as defined in Section 14.1 may be included 307 or referenced in the SIP signaling (using the Call-Info header field) 308 or in the provided-by element of a PIDF-LO. Each block is a MIME 309 type, and any set of blocks may be included. 311 Additional data about a call is defined as a series of MIME objects, 312 each with an XML data structure contained inside. As usual, whenever 313 more than one MIME part is included in the body of a message, MIME- 314 multipart (i.e., 'multipart/mixed') encloses them all. The sections 315 below define the XML schema and MIME types used for each block. When 316 additional data is passed by value in the SIP signaling, each CID URL 317 points to one block in the body. Multiple URIs are used within a 318 Call-Info header field (or multiple Call-Info header fields) to point 319 to multiple blocks. When additional data is provided by reference 320 (in SIP signaling or Provided-By), each HTTPS URL references one 321 block; the data is retrieved with an HTTP Get operation, which 322 returns one of the blocks as an XML object. 324 A registry of allowed types is created by this document. Every block 325 MUST be one of the types in the registry. 327 In regions where callers can elect to suppress certain personally 328 identifying information, the network or PSAP functionality can 329 inspect privacy flags within the SIP headers to determine what 330 information may be passed, stored, or displayed to comply with local 331 policy or law. 333 Each entity adding Additional Information MUST supply the "Data 334 Provider" block. All other blocks are optional, but each entity 335 SHOULD supply any blocks where it has at least some of the 336 information in the block. 338 4.1. Transmitting blocks using Call-Info 339 A URI to a block MAY be inserted in a SIP request or response method 340 (most often INVITE or MESSAGE) with a Call-Info header field 341 containing a purpose of "emergencyCallData" together with the type of 342 data available at the URI. The type of data is denoted by including 343 the root of the MIME type (not including the emergencyCall prefix and 344 the +xml suffix) with a "." separator. For example, when 345 referencing a block with MIME type 'application/ 346 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 347 'emergencyCallData.ProviderInfo'. An example "Call-Info" header 348 field for this would be: 350 Call-Info: https:23sedde3@example.com; 351 purpose="emergencyCallData.ProviderInfo" 353 The Call-info header with purpose='emergencyCallData' MUST only be 354 sent on an emergency call, which can be ascertained by the presence 355 of an emergency service urn in a Route header of a SIP message. 357 If the data is provided by reference, it may be retrieved with an 358 HTTPS Get from the URI. The URI MUST specify an HTTPS scheme, and 359 TLS protection for the data MUST be negotiated. 361 The data may also be supplied by value in a SIP message. In this 362 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 363 referencing the MIME body part. 365 More than one Call-Info header with an emergencyCallData purpose can 366 be expected, but at least one MUST be provided. The device MUST 367 provide one if it knows no service provider is in the path of the 368 call. The device MAY insert one if it uses a service provider. Any 369 service provider in the path of the call MUST insert its own. For 370 example, a device, a telematics service provider in the call path, as 371 well as the mobile carrier handling the call will each provide one. 372 There may be circumstances where there is a service provider who is 373 unaware that the call is an emergency call and cannot reasonably be 374 expected to determine that it is an emergency call. In that case, 375 that service provider is not expected to provide emergencyCallData. 377 4.2. Transmitting blocks by reference using Provided-By 379 The 'emergencyCallDataReference' element is used to transmit an 380 additional data block by reference within a 'Provided-By' element of 381 a PIDF-LO. The 'emergencyCallDataReference' element has two 382 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 383 type of data block referenced. The value of 'ref' is an HTTPS URL 384 that resolves to a data structure with information about the call. 385 The value of 'purpose' is the same as used in a 'Call-Info' header 386 field (as specified in section Section 4.1, Transmitting blocks using 387 Call-Info). 389 For example, to reference a block with MIME type 'application/ 390 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 391 'emergencyCallData.ProviderInfo'. An example 392 'emergencyCallDataReference' element for this would be: 394 397 4.3. Transmitting blocks by value using Provided-By 399 It is RECOMMENDED that access networks supply the data specified in 400 this document by reference, but they MAY provide the data by value. 402 The 'emergencyCallDataValue' element is used to transmit an 403 additional data block by value within a 'Provided-By' element of a 404 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 405 'purpose' to indicate the type of data block contained. The value of 406 'purpose' is the same as used in a 'Call-Info' header field (as 407 specified in section Section 4.1, Transmitting blocks using Call- 408 Info). The same XML structure as would be wrapped in the 409 corresponding MIME type is placed inside the emergencyCallDataValue 410 element. 412 For example: 414 416 418 HooThrooPoo 419 NENA 420 Access Infrastructure Provider 421 422 sip:15555550987@burf.example.com:user=phone 423 424 425 427 5. Data Provider Information 429 This block is intended to be provided by any service provider in the 430 path of the call or the access network provider. It includes 431 identification and contact information. This block SHOULD be 432 provided for every service provider in the path of the call, and the 433 access network provider. Devices MAY use this block to provide 434 identifying information. The MIME subtype is "application/ 435 emergencyCall.ProviderInfo+xml". 437 5.1. Data Provider String 439 Data Element: Data Provider String 440 Use: Required 442 XML Element: 444 Description: This is a plain language string suitable for displaying 445 the name of the service provider that created the additional data 446 structure. If the device created the structure the value is 447 identical to the contact header in the SIP INVITE. 449 Reason for Need: Inform the call taker of the identity of the entity 450 providing the additional call data structure. 452 How Used by Call Taker: Allows the call taker to interpret the data 453 in this structure. The source of the information often influences 454 how the information is used, believed or verified. 456 5.2. Data Provider ID 458 Data Element: Data Provider ID 460 Use: Conditional. Must be provided if the service provider is 461 located in a jurisdiction that maintains such ids. Devices are 462 not required to provide it. 464 XML Element: 466 Description: A jurisdiction specific code for the provider shown in 467 the element that created the structure of the 468 call. This data SHOULD be provided if the local jurisdiction 469 maintains such an ID list. For example, in North America, this 470 would be a "NENA Company ID". Devices SHOULD NOT use this 471 element. 473 Reason for Need: Inform the call taker of the identity of the entity 474 providing the additional call data structure. 476 How Used by Call Taker: Where jurisdictions have lists of providers 477 the Data Provider ID can be useful. 479 5.3. Data Provider ID Series 481 Data Element: Data Provider ID Series 483 Use: Conditional. If Data Provider ID is provided, Data Provider ID 484 Series is required. 486 XML Element: 488 Description: Identifies the issuer of the the ProviderId. A registry 489 will reflect the following valid entries: 491 * NENA 493 * EENA 495 Reason for Need: Identifies how to interpret the Data Provider ID. 497 How Used by Call Taker: Determines which provider ID registry to 498 consult for more information 500 5.4. Type of Data Provider 502 Data Element: Type of Data Provider ID 504 Use: Conditional. If Data Provider ID is provided, Type of Data 505 Provider ID is required. 507 XML Element: 509 Description: Identifies the type of data provider id being supplied 510 in the ProviderId data element. A registry will reflect the 511 following valid entries: 513 * Access Infrastructure Provider 515 * Service Provider 517 * Service Provider Subcontractor 519 * Telematics Provider 521 * Relay Provider 523 * Other 525 Reason for Need: Identifies what kind of data provider this is. 527 How Used by Call Taker: To decide who to contact when further 528 information is needed 530 5.5. Data Provider Contact URI 532 Data Element: Data Provider Contact URI 534 Use: Required 536 XML Element: 538 Description: For a service provider the contact SHOULD be a contact 539 URI. This MUST be a SIP URI. If a telephone number is the contact 540 address it should be provided in the form of 541 sip:telephonenumber@serviceprovider:user=phone. If the call is 542 from a device, this would reflect the contact information of the 543 owner of the device. When provided by a service provider, this 544 would be a URI to a 24/7 support organization tasked to provide 545 PSAP support for this emergency call. 547 Reason for Need: Additional data providers may need to be contacted 548 for error or other unusual circumstances. 550 How Used by Call Taker: To contact the supplier of the additional 551 data for assistance in handling the call. 553 5.6. Data Provider Languages(s) Supported 555 Data Element: Data Provider Language(s) supported 557 Use: Conditional 559 XML Element: 560 Description: The language used by the entity at the Data Provider 561 Contact URI as an alpha 2-character code as defined in ISO 562 639-1:2002 (http://www.iso.org/iso/ 563 catalogue_detail?csnumber=22109) Codes for the representation of 564 names of languages -- Part 1: Alpha-2 code Multiple instances of 565 this element may occur. Order is significant; preferred language 566 should appear first. This data is required if a Data Provider 567 Contact URI is provided. The content must reflect the languages 568 supported at the contact URI. 570 Reason for Need: Information needed to determine if emergency service 571 authority can communicate with the service provider or if an 572 interpreter will be needed. 574 How Used by Call Taker: If call taker cannot speak language(s) 575 supported by the service provider, a translation service will need 576 to be added to the conversation. 578 5.7. xCard of Data Provider 580 Data Element: xCard of Data Provider 582 Use: Optional 584 XML Element: 586 Description: There are many fields in the xCARD and the creator of 587 the data structure is encouraged to provide as much information as 588 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 589 minimum. N should contain name of support group or device owner 590 as appropriate. If more than one TEL property is provided, a 591 parameter from the vCard Property Value registry MUST be specified 592 on each TEL. For encoding of the xCard this specification uses 593 the XML-based encoding specified in [RFC6351]. 595 and is hereinafter referred to as "xCard" 597 Reason for Need: Information needed to determine additional contact 598 information. 600 How Used by Call Taker: Assists call taker by providing additional 601 contact information that may not be included in the SIP invite or 602 the PIDF-LO. 604 5.8. Subcontractor Principal 606 Data Element: Subcontractor Principal 607 XML Element: 609 Description: If the data provider is a subcontractor to another 610 provider such as an access infrastructure provider or telematics 611 provider, this element contains the DataProviderString of the 612 service provider to indicate which provider the subcontractor is 613 working for. This data is required if the Data Provider type is 614 subcontractor. 616 Reason for Need: Identify the entity the subcontractor works for. 618 How Used by Call Taker: Allows the call taker to understand what the 619 relationship between data providers and the service providers in 620 the path of the call are. 622 5.9. Subcontractor Priority 624 Data Element: Subcontractor Priority 626 Use: Required 628 XML Element: 630 Description: If the subcontractor should be contacted first, this 631 element should have a "sub" value. If the access or origination 632 service provider should be contacted first, this element should 633 have a "main" value. This data is required if the Data Provider 634 type is "subcontractor". 636 Reason for Need: Inform the call taker whether the network operator 637 or the subcontractor should be contacted first if support is 638 needed. 640 How Used by Call Taker: To decide which entity to contact first if 641 assistance is needed. 643 5.10. emergencyCall.ProviderInfo XML Schema 644 645 653 656 657 658 659 660 662 663 664 665 667 669 671 673 675 677 679 680 681 682 684 6. Service Information 686 This block describes the service that the service provider provides 687 to the caller. It SHOULD be included by all SPs in the path of the 688 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 690 6.1. Service Environment 692 Data Element: Service Environment 694 Use: Required 695 XML Element: 697 Description: This element defines whether a call is from a business 698 or residence caller. Currently, the only valid entries are 699 'Business' or 'Residence'. 701 Reason for Need: To assist in determining equipment and manpower 702 requirements. 704 How Used by Call Taker: Information may be used to assist in 705 determining equipment and manpower requirements for emergency 706 responders. As the information is not always available, and the 707 registry is not all encompassing, this is at best advisory 708 information, but since it mimics a similar capability in some 709 current emergency calling systems, it is known to be valuable. 710 The service provider uses its best information (such as a rate 711 plan, facilities used to deliver service or service description) 712 to determine the information and is not responsible for 713 determining the actual characteristics of the location where the 714 call originates from. 716 6.2. Service Delivered by Provider to End User 718 Data Element: Service Delivered by Provider to End User 720 Use: Required 722 XML Element: 724 Description: This defines the type of service the end user has 725 subscribed to. The implied mobility of this service can not be 726 relied upon. A registry defined in this document will reflect the 727 following initial valid entries: 729 * Wireless Telephone Service: Includes Satellite, CDMA, GSM, Wi- 730 Fi, WiMAX, UTMS/WCDMA, LTE (Long Term Evolution) 732 * Fixed Public Pay/Coin telephones: Any coin or credit card 733 operated device. 735 * One way outbound service 736 * Inmate call/service 738 * Soft dialtone/quick service/warm disconnect/suspended 740 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 741 key systems, Shared Tenant Service. 743 * Sensor, unattended: Includes devices that generate DATA ONLY. 744 This is one-way information exchange and there will be no other 745 form of communication. 747 * Sensor, attended: Includes devices that are supported by a 748 monitoring service provider or automatically open a two-way 749 communication path. 751 * Wireline: Plain Old Telephone Service (POTS). 753 * VoIP Telephone Service: A type of service that offers 754 communication over internet protocol, such as Fixed, Nomadic, 755 Mobile, Unknown 757 * Relay Service: a type of service where there is a human 3rd 758 party agent who provides some kind of additional assistance to 759 the caller. Includes sign language relay and telematics 760 services which provide a service assistant on the call. 762 * Remote (off premise extension) 764 There can be more than one value returned. For example, a VoIP 765 inmate telephone service is a reasonable combination. 767 Reason for Need: Knowing the type of service may assist the PSAP with 768 the handling of the call. 770 How Used by Call Taker: Call takers often use this information to 771 determine what kinds of questions to ask callers, and how much to 772 rely on supportive information. An emergency call from a prison 773 is treated differently that a call from a sensor device. As the 774 information is not always available, and the registry is not all 775 encompassing, this is at best advisory information, but since it 776 mimics a similar capability in some current emergency calling 777 systems, it is known to be valuable. 779 6.3. Service Mobility Environment 781 Data Element: Service Mobility Environment 783 Use: Required 785 XML Element: 786 Description: This provides the service providers view of the mobility 787 of the caller. As the service provider may not know the 788 characteristics of the actual access network used, the value not 789 be relied upon. A registry will reflect the following initial 790 valid entries: 792 * Mobile: the device should be able to move at any time 794 * Fixed: the device is not expected to move unless the service is 795 relocated 797 * Nomadic: the device is not expected to move while on a call, 798 but may move between calls 800 Reason for Need: Knowing the service provider's belief of mobility 801 may assist the PSAP with the handling of the call. 803 How Used by Call Taker: To determine whether to assume the location 804 of the caller might change. 806 6.4. emergencyCall.SvcInfo XML Schema 808 809 816 819 820 821 822 824 826 828 830 831 832 833 835 7. Device Information 837 This block provides information about the device used to place the 838 call. It should be provided by any service provider that knows what 839 device is being used, and by the device itself. The mime subtype is 840 "application/emergencyCall.DevInfo+xml". 842 7.1. Device Classification 844 Data Element: Device Classification 846 Use: Optional 848 XML Element: 850 Description: This data element defines the kind of device making the 851 emergency call. If the device provides the data structure, the 852 device information SHOULD be provided. If the service provider 853 provides the structure and it knows what the device is, the 854 service provider SHOULD provide the device information. Often the 855 carrier does not know what the device is. It is possible to 856 receive two Additional Data Associated with a Call data 857 structures, one created by the device and one created by the 858 service provider. This information describes the the device, not 859 how it is being used. This data element defines the kind of 860 device making the emergency call. A registry will reflect the 861 following valid entries: 863 * Cordless handset 865 * Fixed phone 867 * Mobile handset 869 * ATA (analog terminal adapter) 871 * Satellite phone 873 * Stationary computing device (alarm system, data sensor) 875 * Guardian devices 877 * Desktop PC 879 * Laptop computing device 881 * Tablet computing device 883 * Alarm system 885 * Data sensor 886 * Personal beacons (spot) 888 * Auto telematics (indicates VEDS data set) 890 * Trucking telematics 892 * Farm equipment telematics 894 * Marine telematics 896 * PDA (personal digital assistant) 898 * PND (personal navigation device) 900 * Smart phone 902 * Internet tablet 904 * Gaming console 906 * Video phone 908 * Other text device 910 * Not Available 912 Reason for Need: The device classification implies the capability of 913 the calling device and assists in identifying the meaning of the 914 emergency call location information that is being presented. For 915 example, does the device require human intervention to initiate a 916 call or is this call the result of programmed instructions? Does 917 the calling device have the ability to update location or 918 condition changes? Is this device interactive or a one-way 919 reporting device? 921 How Used by Call Taker: May assist with location of caller. For 922 example, a cordless handset may be outside or next door. May 923 provide calltaker some context about the caller, the capabilities 924 of the device used for the call or the environment the device is 925 being used in. 927 7.2. Device Manufacturer 929 Data Element: Device Manufacturer 931 Use: Optional 933 XML Element: 934 Description: The plain language name of the manufacturer of the 935 device. 937 Reason for Need: Used by PSAP management for post-mortem 938 investigation/resolution. 940 How Used by Call Taker: Probably not used by calltaker, but by PSAP 941 management. 943 7.3. Device Model Number 945 Data Element: Device Model Number 947 Use: Optional 949 XML Element: 951 Description: Model number of the device. 953 Reason for Need: Used by PSAP management for after action 954 investigation/resolution. 956 How Used by Call Taker: Probably not used by calltaker, but by PSAP 957 management. 959 7.4. Unique Device Identifier 961 Data Element: Unique Device Identifier 963 Use: Optional 965 XML Element: 967 Description: String that identifies the specific device making the 968 call or creating an event. 970 Reason for Need: Uniquely identifies the device as opposed to any 971 signaling identifiers encountered in the call signaling stream. 973 How Used by Call Taker: Probably not used by calltaker they would 974 need to refer to management for investigation. 976 7.5. Type of Device Identifier 978 Data Element: Type of Device Identifier 980 Use: Conditional: must be provided if DeviceID is provided 982 XML Element: 984 Description: Identifies the type of device identifier being generated 985 in the unique device identifier data element. A registry will 986 reflect the following valid entries: 988 * MEID (CDMA) 990 * ESN (Electronic Serial Number -- superseded by MEID) 992 * MAC (Media Access Control) Address -- IEEE-delegated address 993 of any of the interfaces of the device with a MAC address 994 (e.g., Ethernet, WiFi) 996 * WiMAX device certificate subject unique identifier 998 * IMEI (International Mobile Equipment Identifier - GSM) 1000 * Unique Device Identifier (UDI) assigned by US FDA for medical 1001 devices 1003 * RFID (Radio Frequency Identification) 1005 * Sensors (types to be identified in a future document version) 1007 * Manufacturer Serial Number 1009 * Other 1011 Reason for Need: Identifies how to interpret the Unique Device 1012 Identifier. 1014 How Used by Call Taker: Additional information that may be used to 1015 assist with call handling. 1017 7.6. emergencyCall.DevInfo XML Schema 1018 1019 1026 1029 1030 1031 1032 1034 1036 1038 1040 1042 1043 1044 1045 1047 8. Owner/Subscriber Information 1049 This block describes the owner of the device (if provided by the 1050 device) or the subscriber information, if provided by a service 1051 provider. The contact location is not necessarily the location of 1052 the caller or incident, but is rather the nominal contact address. 1053 The mime subtype is "application/emergencyCall.Subscriber+xml". 1055 8.1. xCard for Subscriber\0x2019s Data 1057 Data Element: xCARD for Subscriber\0x2019s Data 1059 Use: Conditional: Some services (e.g. prepaid phones, initialized 1060 phones, etc.) may not have this information. 1062 XML Element: 1063 Description: Information known by the service provider or device 1064 about the subscriber; e.g., Name, Address, Individual Telephone 1065 Number, Main Telephone Number and any other data. N, ORG (if 1066 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1067 than one TEL property is provided, a parameter from the vCard 1068 Property Value registry MUST be specified on each TEL. 1070 Reason for Need: When the caller is unable to provide information, 1071 this data may be used to obtain it 1073 How Used by Call Taker: Obtaining critical information about the 1074 caller and possibly the location when it is not able to be 1075 obtained otherwise. 1077 8.2. emergencyCall.SubInfo XML Schema 1079 1080 1088 1091 1092 1093 1094 1096 1097 1098 1099 1101 9. Comment 1103 This block Provides a mechanism for the data provider to supply 1104 extra, human readable information to the PSAP. It is not intended 1105 for a general purpose extension mechanism. The mime subtype is 1106 "application/emergencyCall.Comment+xml" 1108 9.1. Comment 1110 Data Element: EmergencyCall.Comment 1112 Use: Optional 1113 XML Element: 1115 Description: Human readable text providing additional information to 1116 the PSAP. 1118 Reason for Need: Explanatory information for values in the data 1119 structure 1121 How Used by Call Taker: To interpret the data provided 1123 9.2. emergencyCall.Comment XML Schema 1125 1126 1133 1136 1137 1138 1139 1141 1142 1143 1144 1146 10. Example 1147 INVITE sips:bob@biloxi.example.com SIP/2.0 1148 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1149 Max-Forwards: 70 1150 To: Bob 1151 From: Alice ;tag=9fxced76sl 1152 Call-ID: 3848276298220188511@atlanta.example.com 1153 Call-Info: ;purpose=icon, 1154 ;purpose=info, 1155 1156 ;purpose=emergencyCallData.ProviderInfo 1157 Geolocation: 1158 Geolocation-Routing: no 1159 Accept: application/sdp, application/pidf+xml, 1160 application/emergencyCallProviderinfo+xml 1161 CSeq: 31862 INVITE 1162 Contact: 1163 Content-Type: multipart/mixed; boundary=boundary1 1165 Content-Length: ... 1167 --boundary1 1169 Content-Type: application/sdp 1171 ...SDP goes here 1173 --boundary1 1175 Content-Type: application/pidf+xml 1176 Content-ID: 1178 \0x2026PIDF-LO goes here 1180 --boundary1-- 1182 Content-Type: application/emergencyCall.ProviderInfo+xml 1183 Content-ID: <1234567890@atlanta.example.com> 1185 \0x2026Additional Data goes here 1187 --boundary1-- 1189 11. Main Telephone Number 1191 In a xCard, used extensively in this document, there is no way to 1192 specify a "Main" telephone number. These numbers are useful to 1193 emergency responders who are called to a large enterprise. This 1194 document adds a new Property Value to the "tel" property of the TYPE 1195 parameter called "main". It can be used in any xCard in additional 1196 data. 1198 12. Security Considerations 1199 The information in this data structure will usually be considered 1200 private. HTTPS is specified to require the provider of the 1201 information to validate the credentials of the requester. While the 1202 creation of a PKI that has global scope may be difficult, the 1203 alternatives to creating devices and services that can provide 1204 critical information securely are more daunting. The provider may 1205 enforce any policy it wishes to use, but PSAPs and responder agencies 1206 should deploy a PKI so that providers of additional data can check 1207 the certificate of the client and decide the appropriate policy to 1208 enforce based on that certificate. 1210 Ideally, the PSAP and emergency responders will be given credentials 1211 signed by an authority trusted by the data provider. In most 1212 circumstances, nationally recognized credentials would be sufficient, 1213 and if the emergency services arranges a PKI, data providers could be 1214 provisioned with the root CA public key for a given nation. Some 1215 nations are developing a PKI for this, and related, purposes. Since 1216 calls could be made from devices where the device and/or the service 1217 provider(s) are not local to the emergency authorities, globally 1218 recognized credentials are useful. This might be accomplished by 1219 extending the notion of the "forest guide" described in [RFC5222] to 1220 allow the forest guide to provide the credential of the PKI root for 1221 areas that it has coverage information for, but standards for such a 1222 mechanism are not yet available. In its absence, the data provider 1223 will need to obtain the root CA credentials for any areas it is 1224 willing to provide additional data by out of band means. With the 1225 credential of the root CA for a national emergency services PKI, the 1226 data provider server can validate the credentials of an entity 1227 requesting additional data by reference. 1229 The data provider also needs a credential that can be verified by the 1230 emergency services to know that it is receiving data from the right 1231 server. The emergency authorities could provide credentials, 1232 distinguishable from credentials it provides to emergency responders 1233 and PSAPs, which could be used to validate data providers. Such 1234 credentials would have to be acceptable to any PSAP or responder that 1235 could receive a call with additional data supplied by that provider. 1236 This would be extensible to global credential validation using the 1237 forest guide as above. In the absence of such credentials, the 1238 emergency authorities could maintain a list of local data providers' 1239 credentials provided to it out of band. At a minimum, the emergency 1240 authorities could obtain a credential from the DNS entry of the 1241 domain in the Addional Data URI to at least validate that the server 1242 is known to the domain providing the URI. 1244 Data provided by devices by reference have similar credential 1245 validation issues to service providers, and the solutions are the 1246 same. 1248 13. Privacy Considerations 1249 There is much private data in this information. Local regulations 1250 may govern what data must be provided in emergency calls, but in 1251 general, the emergency call system is often aided by the kinds of 1252 information described in this document. There is a tradeoff between 1253 the privacy considerations and the utility of the data. Certainly, 1254 if the data cannot be protected, due to failure to establish (by TLS) 1255 a secure connection to the data provider, data SHOULD NOT be sent 1256 unless specifically required by regulation. 1258 14. IANA Considerations 1260 14.1. Registry creation 1262 This document creates a new registry called 'Emergency Call 1263 Additional Data'. The following subregistries are created in 1264 Emergency Call Additional Data: 1266 14.1.1. Additional Call Data Blocks Registry 1268 This document creates a new subregistry called \0x2019Provider ID 1269 Series\0x2019. As defined in [RFC5226], this registry operates under 1270 "Expert Review" rules. The expert should determine that the entity 1271 requesting a new value is a legitimate issuer of service provider IDs 1272 suitable for use in Additional Call Data. 1274 The content of this registry includes: 1276 Name: The identifier which will be used in the ProviderIDSeries 1277 element 1279 Source: The full name of the organization issuing the identifiers 1281 URL: A URL to the organization for further information 1283 The values defined are: 1285 +-----------+-----------+--------------+--------------+ 1286 | Name | Source | URL | 1287 +-----------+--------------------------+--------------+ 1288 | NENA | North American Emergency | www.nena.org | 1289 | | Number Association | | 1290 | EENA | European Emergency | www.eena.org | 1291 | | Number Association | | 1292 +-----------+--------------------------+--------------+ 1293 RFC Editor Note: 1294 replace XXXX in the table above with this documents RFC number 1296 14.1.2. Additional Call Data Service Provider Type Registry 1297 This document creates a new subregistry called \0x2019Service 1298 Provider Type\0x2019. As defined in [RFC5226], this registry 1299 operates under "Expert Review". The expert should determine that the 1300 proposed new value is distinct from existing values and appropriate 1301 for use in the TypeOfServicerProvider element 1303 The content of this registry includes: 1305 Name: Value to be used in TypeOfServiceProvider. 1307 Description: A short description of the type of service provider 1309 The values defined are: 1311 +------------------------------+------------------------------------+ 1312 | Name | Description | 1313 +------------------------------+------------------------------------+ 1314 |Access Infrastructure Provider| Access network service provider | 1315 |Service Provider | Calling or Origination telecom SP | 1316 |Service Provider Subcontractor| A contractor to another kind of SP | 1317 |Telematics Provider | A sensor based SP, especially | 1318 | | vehicle based | 1319 |Relay Provider | A interpretation SP, for example, | 1320 | | video relay for sign language | 1321 | | interpretors | 1322 |Other | Any other type of service provider | 1323 +------------------------------+------------------------------------+ 1324 RFC Editor Note: 1325 replace XXXX in the table above with this documents RFC number 1327 14.1.3. Additional Call Data Service Delivered Registry 1329 This document creates a new registry called \0x2019Additional Call 1330 Data Service Delivered\0x2019. As defined in [RFC5226], this 1331 registry operates under "Expert Review" rules. The expert should 1332 consider whether the proposed service is unique from existing 1333 services and the definition of the service will be clear to 1334 implementors and PSAPS/responders. 1336 The content of this registry includes: 1338 Name: enumeration token of the service. 1340 Description: Short description identifying the service. 1342 The values defined are: 1344 +--------+----------------------------------------+ 1345 | Name | description | 1346 +--------+-------+--------------------------------+ 1347 | Wrless | Wireless Telephone Service: Includes | 1348 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 1349 | | LTE (Long Term Evolution) | 1350 | Coin | Fixed Public Pay/Coin telephones: Any | 1351 | | coin or credit card operated device | 1352 | 1way | One way outbound service | 1353 | Prison | Inmate call/service | 1354 | Temp | Soft dialtone/quick service/warm | 1355 | | disconnect/suspended | 1356 | MLTS | Multi-line telephone system: Includes | 1357 | | all PBX, Centrex, key systems, | 1358 | | Shared Tenant Service | 1359 | SenseU | Sensor, unattended: Includes devices | 1360 | | that generate DATA ONLY. This is | 1361 | | one-way information exchange and | 1362 | | there will be no other form of | 1363 | | communication | 1364 | SenseA | Sensor, attended: Includes devices | 1365 | | that are supported by a monitoring | 1366 | | service provider or automatically | 1367 | | open a two-way communication path | 1368 | POTS | Wireline: Plain Old Telephone Service | 1369 | VOIP | VoIP Telephone Service: A type of | 1370 | | service that offers communication | 1371 | | over internet protocol, such as Fixed| 1372 | | Nomadic, Mobile, ... | 1373 +--------+-------+--------------------------------+ 1375 14.1.4. Additional Call Data Device Classification Registry 1377 This document creates a new registry called \0x2019Additional Call 1378 Data Device Classification\0x2019. As defined in [RFC5226], this 1379 registry operates under "Expert Review" rules. The expert should 1380 consider whether the proposed class is unique from existing classes 1381 and the definition of the class will be clear to implementors and 1382 PSAPS/responders. 1384 The content of this registry includes: 1386 Name: enumeration token of the device classification. 1388 Description: Short description identifying the device type. 1390 The values defined are: 1392 +--------+----------------------------------------+ 1393 | Name | description | 1394 +--------+-------+--------------------------------+ 1395 |Cordless| Cordless handset | 1396 | Fixed | Fixed phone | 1397 | Mobile | Mobile handset | 1398 | ATA | analog terminal adapter | 1399 |Satphone| Satellite phone | 1400 | FSense | Stationary computing device (alarm | 1401 | | system, data sensor) | 1402 | Guard | Guardian devices | 1403 | Desktop| Desktop PC | 1404 | Laptop | Laptop computing device | 1405 | Tablet | Tablet computing device | 1406 | Alarm | Alarm system | 1407 | MSense | Mobile Data sensor | 1408 | Beacon | Personal beacons (spot) | 1409 | Auto | Auto telematics | 1410 | Truck | Truck telematics | 1411 | Farm | Farm equipment telematics | 1412 | Marine | Marine telematics | 1413 | PDA | Personal digital assistant | 1414 | PND | Personal navigation device) | 1415 | SmrtPhn| Smart phone | 1416 | Itab | Internet tablet | 1417 | Game | Gaming console | 1418 | Video | Video phone | 1419 | Text | Other text device | 1420 | NA | Not Available | 1421 +--------+----------------------------------------+ 1423 14.1.5. Additional Call Data Device ID Type Registry 1425 This document creates a new registry called \0x2019Additional Call 1426 Data Device ID Type\0x2019. As defined in [RFC5226], this registry 1427 operates under "Expert Review" rules. The expert should ascertain 1428 that the proposed type is well understood, and provides the 1429 information useful to PSAPs and responders to uniquely identify a 1430 device. 1432 The content of this registry includes: 1434 Name: enumeration token of the device id type. 1436 Description: Short description identifying the type of device id. 1438 The values defined are: 1440 +--------+----------------------------------------+ 1441 | Name | description | 1442 +--------+-------+--------------------------------+ 1443 | MEID | Mobile Equipment Identifier (CDMA) | 1444 | ESN | Electronic Serial Number(GSM) | 1445 | MAC | Media Access Control Address (IEEE) | 1446 | WiMAX | device certificate unique id | 1447 | IMEI | International Mobile Equipment ID (GSM)| 1448 | UDI | Unique Device Identifier (medical) | 1449 | RFID | Radio Frequency Identification | 1450 | SN | Manufacturer Serial Number | 1451 +--------+----------------------------------------+ 1453 14.1.6. Additional Call Data Blocks Registry 1455 This document creates a new subregistry called \0x2019Additional Call 1456 Data Blocks\0x2019 in the purpose registry established by RFC3261. 1457 As defined in [RFC5226], this registry operates under "Expert Review" 1458 and "Specification Required" rules. The expert is responsible for 1459 verifying that the document contains a complete and clear 1460 specification of the block and the block does not obviously duplicate 1461 existing blocks. 1463 The content of this registry includes: 1465 Name: Element Name of enclosing block. 1467 Reference: The document that describes the block 1469 The values defined are: 1471 +-------------+-----------+ 1472 | Name | Reference | 1473 +-------------+-----------+ 1474 |ProviderInfo | RFCXXXX | 1475 | SvcInfo | RFCXXXX | 1476 | DevInfo | RFCXXXX | 1477 | Subscriber | RFCXXXX | 1478 | Comment | RFCXXXX | 1479 +-------------+-----------+ 1480 RFC Editor Note: 1481 replace XXXX in the table above with this documents RFC number 1483 14.2. 'emergencyCallData' Purpose Parameter Value 1485 This document defines the 'emergencyCall' value for the "purpose" 1486 parameter of the Call-Info header field. The Call-Info header and 1487 the corresponding registry for the 'purpose' parameter was 1488 established with RFC 3261 [RFC3261]. 1490 Header Parameter New 1491 Field Name Value Reference 1492 ---------- --------- ----------------- --------- 1493 Call-Info purpose emergencyCall [This RFC] 1495 14.3. URN Sub-Namespace Registration for provided-by Registry Entry 1497 This section registers the namespace specified in Section 14.5.1 in 1498 the provided-by registry established by RFC 4119, for usage within 1499 the 'provided-by' element of a PIDF-LO. 1501 14.3.1. Provided-By XML Schema 1503 1504 1513 1516 1517 1518 1519 1520 1522 1523 1524 1525 1527 1529 1530 1531 1533 1534 1536 1537 1539 14.4. MIME Registrations 1540 14.4.1. MIME Content-type Registration for 'application/ 1541 emergencyCall.ProviderInfo+xml' 1543 This specification requests the registration of a new MIME type 1544 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1545 RFC 3023 [RFC3023]. 1547 MIME media type name: application 1549 MIME subtype name: emergencyCall.ProviderInfo+xml 1551 Mandatory parameters: none 1553 Optional parameters: charset 1555 Indicates the character encoding of enclosed XML. 1557 Encoding considerations: 1559 Uses XML, which can employ 8-bit characters, depending on the 1560 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1562 Security considerations: 1564 This content type is designed to carry the data provider information, 1565 which is a sub-category of additional data about an emergency call. 1567 Since this data contains personal information appropriate precautions 1568 have to be taken to limit unauthorized access, inappropriate 1569 disclosure to third parties, and eavesdropping of this information. 1570 Please refer to Section 12 and Section 13 for more information. 1572 Interoperability considerations: None 1574 Published specification: [TBD: This specification] 1576 Applications which use this media type: Emergency Services 1578 Additional information: 1580 Magic Number: None 1582 File Extension: .xml 1584 Macintosh file type code: 'TEXT' 1586 Person and email address for further information: Hannes 1587 Tschofenig, Hannes.Tschofenig@gmx.net 1589 Intended usage: LIMITED USE 1590 Author: This specification is a work item of the IETF ECRIT 1591 working group, with mailing list address . 1593 Change controller: The IESG 1595 14.4.2. MIME Content-type Registration for 'application/ 1596 emergencyCall.SvcInfo+xml' 1598 This specification requests the registration of a new MIME type 1599 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1600 RFC 3023 [RFC3023]. 1602 MIME media type name: application 1604 MIME subtype name: emergencyCall.SvcInfo+xml 1606 Mandatory parameters: none 1608 Optional parameters: charset 1610 Indicates the character encoding of enclosed XML. 1612 Encoding considerations: 1614 Uses XML, which can employ 8-bit characters, depending on the 1615 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1617 Security considerations: 1619 This content type is designed to carry the service information, which 1620 is a sub-category of additional data about an emergency call. 1622 Since this data contains personal information appropriate precautions 1623 have to be taken to limit unauthorized access, inappropriate 1624 disclosure to third parties, and eavesdropping of this information. 1625 Please refer to Section 12 and Section 13 for more information. 1627 Interoperability considerations: None 1629 Published specification: [TBD: This specification] 1631 Applications which use this media type: Emergency Services 1633 Additional information: 1635 Magic Number: None 1637 File Extension: .xml 1639 Macintosh file type code: 'TEXT' 1640 Person and email address for further information: Hannes 1641 Tschofenig, Hannes.Tschofenig@gmx.net 1643 Intended usage: LIMITED USE 1645 Author: This specification is a work item of the IETF ECRIT 1646 working group, with mailing list address . 1648 Change controller: The IESG 1650 14.4.3. MIME Content-type Registration for 'application/ 1651 emergencyCall.DevInfo+xml' 1653 This specification requests the registration of a new MIME type 1654 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1655 RFC 3023 [RFC3023]. 1657 MIME media type name: application 1659 MIME subtype name: emergencyCall.DevInfo+xml 1661 Mandatory parameters: none 1663 Optional parameters: charset 1665 Indicates the character encoding of enclosed XML. 1667 Encoding considerations: 1669 Uses XML, which can employ 8-bit characters, depending on the 1670 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1672 Security considerations: 1674 This content type is designed to carry the device information 1675 information, which is a sub-category of additional data about an 1676 emergency call. 1678 Since this data contains personal information appropriate precautions 1679 have to be taken to limit unauthorized access, inappropriate 1680 disclosure to third parties, and eavesdropping of this information. 1681 Please refer to Section 12 and Section 13 for more information. 1683 Interoperability considerations: None 1685 Published specification: [TBD: This specification] 1687 Applications which use this media type: Emergency Services 1689 Additional information: 1691 Magic Number: None 1692 File Extension: .xml 1694 Macintosh file type code: 'TEXT' 1696 Person and email address for further information: Hannes 1697 Tschofenig, Hannes.Tschofenig@gmx.net 1699 Intended usage: LIMITED USE 1701 Author: This specification is a work item of the IETF ECRIT 1702 working group, with mailing list address . 1704 Change controller: The IESG 1706 14.4.4. MIME Content-type Registration for 'application/ 1707 emergencyCall.SubInfo+xml' 1709 This specification requests the registration of a new MIME type 1710 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1711 RFC 3023 [RFC3023]. 1713 MIME media type name: application 1715 MIME subtype name: emergencyCall.SubInfo+xml 1717 Mandatory parameters: none 1719 Optional parameters: charset 1721 Indicates the character encoding of enclosed XML. 1723 Encoding considerations: 1725 Uses XML, which can employ 8-bit characters, depending on the 1726 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1728 Security considerations: 1730 This content type is designed to carry owner/subscriber information, 1731 which is a sub-category of additional data about an emergency call. 1733 Since this data contains personal information appropriate precautions 1734 have to be taken to limit unauthorized access, inappropriate 1735 disclosure to third parties, and eavesdropping of this information. 1736 Please refer to Section 12 and Section 13 for more information. 1738 Interoperability considerations: None 1740 Published specification: [TBD: This specification] 1742 Applications which use this media type: Emergency Services 1744 Additional information: 1746 Magic Number: None 1748 File Extension: .xml 1750 Macintosh file type code: 'TEXT' 1752 Person and email address for further information: Hannes 1753 Tschofenig, Hannes.Tschofenig@gmx.net 1755 Intended usage: LIMITED USE 1757 Author: This specification is a work item of the IETF ECRIT 1758 working group, with mailing list address . 1760 Change controller: The IESG 1762 14.4.5. MIME Content-type Registration for 'application/ 1763 emergencyCall.Comment+xml' 1765 This specification requests the registration of a new MIME type 1766 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1767 RFC 3023 [RFC3023]. 1769 MIME media type name: application 1771 MIME subtype name: emergencyCall.Comment+xml 1773 Mandatory parameters: none 1775 Optional parameters: charset 1777 Indicates the character encoding of enclosed XML. 1779 Encoding considerations: 1781 Uses XML, which can employ 8-bit characters, depending on the 1782 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1784 Security considerations: 1786 This content type is designed to carry a comment, which is a sub- 1787 category of additional data about an emergency call. 1789 This data may contain personal information. Appropriate precautions 1790 may have to be taken to limit unauthorized access, inappropriate 1791 disclosure to third parties, and eavesdropping of this information. 1792 Please refer to Section 12 and Section 13 for more information. 1794 Interoperability considerations: None 1796 Published specification: [TBD: This specification] 1797 Applications which use this media type: Emergency Services 1799 Additional information: 1801 Magic Number: None 1803 File Extension: .xml 1805 Macintosh file type code: 'TEXT' 1807 Person and email address for further information: Hannes 1808 Tschofenig, Hannes.Tschofenig@gmx.net 1810 Intended usage: LIMITED USE 1812 Author: This specification is a work item of the IETF ECRIT 1813 working group, with mailing list address . 1815 Change controller: The IESG 1817 14.5. URN Sub-Namespace Registration 1819 14.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 1821 This section registers a new XML namespace, as per the guidelines in 1822 RFC 3688 [RFC3688]. 1824 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 1826 Registrant Contact: IETF, ECRIT working group, , as 1827 delegated by the IESG . 1829 XML: 1831 BEGIN 1832 1833 1835 1836 1837 1839 Namespace for Additional Emergency Call Data 1840 1841 1842

Namespace for Additional Data related to an Emergency Call

1843

See [TBD: This document].

1844 1845 1846 END 1848 14.5.2. Registration for 1849 urn:ietf:params:xml:ns:emergencyCallProviderInfo 1851 This section registers a new XML namespace, as per the guidelines in 1852 RFC 3688 [RFC3688]. 1854 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 1856 Registrant Contact: IETF, ECRIT working group, , as 1857 delegated by the IESG . 1859 XML: 1861 BEGIN 1862 1863 1865 1866 1867 1869 Namespace for Additional Emergency Call Data: 1870 Data Provider Information 1871 1872 1873

Namespace for Additional Data related to an Emergency Call

1874

Data Provider Information

1875

See [TBD: This document].

1876 1877 1878 END 1880 14.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 1882 This section registers a new XML namespace, as per the guidelines in 1883 RFC 3688 [RFC3688]. 1885 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 1887 Registrant Contact: IETF, ECRIT working group, , as 1888 delegated by the IESG . 1890 XML: 1892 BEGIN 1893 1894 1896 1897 1898 1900 Namespace for Additional Emergency Call Data: 1901 Service Information 1902 1903 1904

Namespace for Additional Data related to an Emergency Call

1905

Service Information

1906

See [TBD: This document].

1907 1908 1909 END 1911 14.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 1913 This section registers a new XML namespace, as per the guidelines in 1914 RFC 3688 [RFC3688]. 1916 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 1918 Registrant Contact: IETF, ECRIT working group, , as 1919 delegated by the IESG . 1921 XML: 1923 BEGIN 1924 1925 1927 1928 1929 1931 Namespace for Additional Emergency Call Data: 1932 Device Information 1933 1934 1935

Namespace for Additional Data related to an Emergency Call

1936

Device Information

1937

See [TBD: This document].

1938 1939 1940 END 1942 14.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 1944 This section registers a new XML namespace, as per the guidelines in 1945 RFC 3688 [RFC3688]. 1947 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 1949 Registrant Contact: IETF, ECRIT working group, , as 1950 delegated by the IESG . 1952 XML: 1954 BEGIN 1955 1956 1958 1959 1960 1962 Namespace for Additional Emergency Call Data: 1963 Owner/Subscriber Information 1964 1965 1966

Namespace for Additional Data related to an Emergency Call

1967

Owner/Subscriber Information

1968

See [TBD: This document].

1969 1970 1971 END 1973 14.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 1975 This section registers a new XML namespace, as per the guidelines in 1976 RFC 3688 [RFC3688]. 1978 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 1980 Registrant Contact: IETF, ECRIT working group, , as 1981 delegated by the IESG . 1983 XML: 1985 BEGIN 1986 1987 1989 1990 1991 1993 Namespace for Additional Emergency Call Data:Comment 1994 1995 1996

Namespace for Additional Data related to an Emergency Call

1997

Comment

1998

See [TBD: This document].

1999 2000 2001 END 2003 14.6. Schema Registrations 2005 This specification registers five schemas, as per the guidelines in 2006 RFC 3688 [RFC3688]. 2008 URI: urn:ietf:params:xml:schema:additional- 2009 data:emergencyCallProviderInfo 2011 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2012 delegated by the IESG (iesg@ietf.org). 2014 XML: The XML schema can be found in Figure 2. 2016 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2018 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2019 delegated by the IESG (iesg@ietf.org). 2021 XML: The XML schema can be found in Figure 3. 2023 URI: urn:ietf:params:xml:schema:additional- 2024 data:emergencyCallDevInfo 2026 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2027 delegated by the IESG (iesg@ietf.org). 2029 XML: The XML schema can be found in Figure 4. 2031 URI: urn:ietf:params:xml:schema:additional- 2032 data:emergencyCall.SubInfo 2034 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2035 delegated by the IESG (iesg@ietf.org). 2037 XML: The XML schema can be found in Section 8.2. 2039 URI: urn:ietf:params:xml:schema:additional- 2040 data:emergencyCall.Comment 2042 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2043 delegated by the IESG (iesg@ietf.org). 2045 XML: The XML schema can be found in Section 9.2. 2047 14.7. VCard Parameter Value Registration 2049 This document registers a new value in the vCARD Parameter Values 2050 registry as defined by [RFC6350] with the following template: 2052 Value: main 2054 Purpose: The main telephone number, typically of an enterprise, as 2055 opposed to a direct dial number of an individual employee 2057 Conformance: This value can be used with the "TYPE" parameter applied 2058 on the "TEL" property. 2060 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-900 2061 0 2063 15. Acknowledgments 2065 This work was originally started in NENA and has benefitted from a 2066 large number of participants in NENA standardization efforts, 2067 originally in the Long Term Definition Working Group, the Data 2068 Technical Committee and most recently the Additional Data working 2069 group. The authors are grateful for the initial work and extended 2070 comments provided by the many NENA participants. 2072 16. References 2074 16.1. Normative References 2076 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2077 Requirement Levels", BCP 14, RFC 2119, March 1997. 2079 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2080 Locators", RFC 2392, August 1998. 2082 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 2083 Types", RFC 3023, January 2001. 2085 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2086 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 2087 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 2089 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2090 January 2004. 2092 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2093 Format", RFC 4119, December 2005. 2095 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2096 Registration Procedures", RFC 4288, December 2005. 2098 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2099 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2100 May 2008. 2102 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2103 August 2011. 2105 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2106 6351, August 2011. 2108 16.2. Informational References 2110 [I-D.iab-privacy-considerations] 2111 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2112 Morris, J., Hansen, M. and R. Smith, "Privacy 2113 Considerations for Internet Protocols", Internet-Draft 2114 draft-iab-privacy-considerations-03, July 2012. 2116 [I-D.ietf-ecrit-phonebcp] 2117 Rosen, B. and J. Polk, "Best Current Practice for 2118 Communications Services in support of Emergency Calling", 2119 Internet-Draft draft-ietf-ecrit-phonebcp-20, September 2120 2011. 2122 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, 2123 "LoST: A Location-to-Service Translation Protocol", RFC 2124 5222, August 2008. 2126 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J. and A. Newton, 2127 "Framework for Emergency Calling Using Internet 2128 Multimedia", RFC 6443, December 2011. 2130 Authors' Addresses 2132 Brian Rosen 2133 NeuStar 2134 470 Conrad Dr. 2135 Mars, PA 16046 2136 US 2138 Phone: +1 724 382 1051 2139 Email: br@brianrosen.net 2140 Hannes Tschofenig 2141 Nokia Siemens Networks 2142 Linnoitustie 6 2143 Espoo, 02600 2144 Finland 2146 Phone: +358 (50) 4871445 2147 Email: Hannes.Tschofenig@gmx.net 2148 URI: http://www.tschofenig.priv.at 2150 Roger Marshall 2151 TeleCommunication Systems, Inc. 2152 2401 Elliott Avenue 2153 Seattle, WA 98121 2154 US 2156 Phone: +1 206 792 2424 2157 Email: rmarshall@telecomsys.com 2158 URI: http://www.telecomsys.com 2160 Randall Gellens 2161 Qualcomm Technologies, Inc. 2162 5775 Morehouse Drive 2163 San Diego, CA 92121 2164 US 2166 Email: rg+ietf@qti.qualcomm.com