idnits 2.17.00 (12 Aug 2021) /tmp/idnits23940/draft-ietf-ecrit-additional-data-05.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 225 has weird spacing: '...ndatory which...' == Line 227 has weird spacing: '...itional which...' == Line 230 has weird spacing: '...ptional which...' == Line 1421 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 (October 22, 2012) is 3497 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 1421, but not defined == Unused Reference: 'I-D.iab-privacy-considerations' is defined on line 1976, 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 (~~), 11 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: April 25, 2013 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 October 22, 2012 10 Additional Data related to an Emergency Call 11 draft-ietf-ecrit-additional-data-05.txt 13 Abstract 15 When an emergency call is sent to a Public Safety Answering Point 16 (PSAP), the device that sends it, as well as any service provider in 17 the path of the call, or access network through which the call 18 originated may have information about the call which the PSAP may be 19 able to use. This document describes an XML data structure to 20 contains such data and a Uniform Resource Identifier (URI) for 21 conveying the data to the PSAP. The URI may point to either an 22 external resource, or the body of the SIP message. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 7 61 4. Data Provider Information . . . . . . . . . . . . . . . . . . 9 62 4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 9 63 4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 9 64 4.3. Data Provider ID Series . . . . . . . . . . . . . . . . . 10 65 4.4. Type of Data Provider . . . . . . . . . . . . . . . . . . 10 66 4.5. Data Provider Contact URI . . . . . . . . . . . . . . . . 11 67 4.6. Data Provider Languages(s) Supported . . . . . . . . . . . 12 68 4.7. xCard of Data Provider . . . . . . . . . . . . . . . . . . 12 69 4.8. Subcontractor Principal . . . . . . . . . . . . . . . . . 13 70 4.9. Subcontractor Priority . . . . . . . . . . . . . . . . . . 14 71 4.10. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 15 72 5. Service Information . . . . . . . . . . . . . . . . . . . . . 16 73 5.1. Service Environment . . . . . . . . . . . . . . . . . . . 16 74 5.2. Service Delivered by Provider to End User . . . . . . . . 16 75 5.3. Service Mobility Environment . . . . . . . . . . . . . . . 18 76 5.4. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 19 77 6. Device Information . . . . . . . . . . . . . . . . . . . . . . 20 78 6.1. Device Classification . . . . . . . . . . . . . . . . . . 20 79 6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 22 80 6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 22 81 6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 23 82 6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 23 83 6.6. Device/Service Specific Additional Data Structure . . . . 24 84 6.7. Device/Service Specific Additional Data Structure Type . . 25 85 6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 26 86 7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 27 87 7.1. xCard for Subscriber's Data . . . . . . . . . . . . . . . 27 88 7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 28 89 8. Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 8.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 8.2. Comment XML Schema . . . . . . . . . . . . . . . . . . . . 30 92 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 10. Main Telephone Number . . . . . . . . . . . . . . . . . . . . 32 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 95 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 34 96 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 97 13.1. Registry creation . . . . . . . . . . . . . . . . . . . . 35 98 13.1.1. Additional Call Data Blocks Registry . . . . . . . . 35 99 13.1.2. Service Provider Type . . . . . . . . . . . . . . . . 35 100 13.1.3. Additional Call Data Blocks Registry . . . . . . . . 36 101 13.1.4. Additional Call Data Service Delivered Registry . . . 37 102 13.1.5. Additional Call Data Device Classification 103 Registry . . . . . . . . . . . . . . . . . . . . . . 38 104 13.1.6. Additional Call Data Device ID Type Registry . . . . 39 105 13.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 39 106 13.3. URN Sub-Namespace Registration for provided-by 107 Registry Entry . . . . . . . . . . . . . . . . . . . . . . 39 108 13.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 40 109 13.4.1. MIME Content-type Registration for 110 'application/addDataProviderInfo+xml' . . . . . . . . 40 111 13.4.2. MIME Content-type Registration for 112 'application/addCallSvcInfo+xml' . . . . . . . . . . 41 113 13.4.3. MIME Content-type Registration for 114 'application/addDataDevInfo+xml' . . . . . . . . . . 42 115 13.4.4. MIME Content-type Registration for 116 'application/addCallSub+xml' . . . . . . . . . . . . 43 117 13.4.5. MIME Content-type Registration for 118 'application/addCallComment+xml' . . . . . . . . . . 45 119 13.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46 120 13.5.1. Registration for 121 urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 46 122 13.5.2. Registration for 123 urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 47 124 13.5.3. Registration for 125 urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 47 126 13.5.4. Registration for urn:ietf:params:xml:ns:addCallSub . 48 127 13.5.5. Registration for 128 urn:ietf:params:xml:ns:addCallComment . . . . . . . . 49 129 13.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 50 130 13.7. VCard Parameter Value Registration . . . . . . . . . . . . 51 131 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 132 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 133 15.1. Normative References . . . . . . . . . . . . . . . . . . . 53 134 15.2. Informational References . . . . . . . . . . . . . . . . . 53 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 137 1. Introduction 139 This document extends the basic signaling of an emergency call as 140 described in [RFC6443] and [I-D.ietf-ecrit-phonebcp] in order to 141 carry additional data which may be useful to an entity handling the 142 call. This data is "additional" to the basic signaling used in 143 processing the call. Four general categories of such data are 144 defined, for the caller, the location, the call, and the PSAP. An 145 XML data structure is defined for such data, and a means of conveying 146 the data by including a Uniform Resource Identifier (URI) in the SIP 147 signaling which resolves to the data. The data itself may reside on 148 an external resource, or may be contained within the BODY of the SIP 149 message. 151 In general, there are three types of data exchanged: 153 Data Associated with a Call: While information is carried in the 154 call setup procedure itself (as part of the SIP headers as well as 155 in the body of the SIP message), there is additional data known by 156 the device making the call, or a service provider in the path of 157 the call including contact data, subscriber data, service data and 158 device data. 160 Data Associated with a Location: There may be data that is specific 161 to the location not available in the location data structure 162 (PIDF-LO [RFC4119]) itself, such as floor plan, tenant and 163 building owner contact data, HVAC status, etc. 165 Data Associated with a Caller: This is personal data about a caller, 166 such as medical information and emergency contact data. 168 When an emergency call is sent to a PSAP, while there is a rich set 169 of data in the SIP message used for the call setup, the device, as 170 well as any service provider in the path may have even more 171 information that may be useful for a PSAP. This information may 172 include the identity and contact information of the service provider, 173 subscriber identity and contact information, the type of service the 174 provider offers, what kind of device is being used, etc. Some data 175 is device or service dependent data. For example, a car telematics 176 system or service may have crash information. A medical monitoring 177 device may have sensor data. While the details of the information 178 may vary by device or service, there needs to be a common way to send 179 such data to a PSAP. 181 This document focuses only four types of additional data associated 182 with an emergent call and a mechanism for transporting it in an 183 existing SIP header field, the Call-Info header, which is specified 184 in Section 20.9 of [RFC3261]. For this purpose a new token, namely 185 'emergencyCallData' is defined to be carried in the "purpose" 186 parameter. If the "purpose" parameter is set to 'emergencyCallData' 187 then the Call-Info header contains a HTTPS URL that points to a 188 service and data structure with information about the call or is a 189 CID that allows the data structure itself to be placed in the body of 190 the message. Section 9 shows a SIP INVITE example containing such a 191 Call-Info header using the purpose parameter. 193 Besides a service provider in the path of a call, the access network 194 (which in the IETF emergency call architecture provides location in 195 the form of a PIDF-LO [RFC4119]) also has similar information that 196 may be valuable to the PSAP. This information is not specific to the 197 location itsef, but rather would provide descriptive information 198 having to do with the immediate circumstances about the provision of 199 the location (who the access network is, how to contact that entity, 200 what kind of service the access network provides, possibly subscriber 201 data, etc.). This data is similar in nearly every respect with the 202 data known by services providers in the path of the call. For this 203 reason, this document describes a "provided-by" namespace per 204 [RFC4119] for passing information known to the access network. 206 The data is defined as a series of "blocks" that represent a class of 207 information. Each of the blocks is a MIME type, and an extensible 208 set of these types constitute the data structure. A registry is 209 defined to list the block types that may be included. 211 The data structure contains an element which itself is a URI that has 212 device or service dependent data. Thus the common Additional Data 213 about a Call defined by this document contains a 'hook', in the form 214 of a URI, for a device or service dependent data structure. 216 2. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 In the data block definitions, the "Use:" values are specified as one 223 of: 225 Mandatory which means they MUST be present in the data structure. 227 Conditional which means they MUST be present unless the specified 228 condition is met, in which case the they MAY be present. 230 Optional which means they MAY be present. 232 3. Call-Info Specification 234 The Additional Data about a Call is information specific to a call 235 known by the device that sends it or a service provider in the path 236 of a call or in the access network the call originates in. The 237 Additional Data about a Call is a set of information blocks. Each 238 block is a MIME type, and any set of blocks may be included in the 239 set. 241 Two mechanisms are provided to transport the data set, namely 243 1. A URI to the data set MAY be inserted in a SIP INVITE or MESSAGE 244 transaction with a Call-Info header containing a purpose of 245 "emergencyCallData". The Call-info header with 246 purpose='emergencyCallData' MUST only be sent on an emergency 247 call, which can be ascertained by the presence of an emergency 248 service urn in a Route header of a SIP message. If the data is 249 provided by reference, it may be retrieved with an HTTPS Get from 250 the URI. The URI MUST specify an HTTPS scheme, and TLS 251 protection for the data MUST be negotiated. 253 2. The data may be supplied by value in a SIP INVITE or MESSAGE 254 message. In this case, Content Indirection (CID) [RFC2392] is 255 used, with the CID URL pointing to the body of the message. 257 More than one Call-Info header with an emergencyCallData purpose can 258 be expected, but at least one MUST be provided. The device MUST 259 provide one if no service provider is in the path of the call. The 260 device MAY insert one if it uses a service provider. Any service 261 provider in the path of the call MUST insert its own. For example, a 262 device, a telematics service provider in the call path, as well as 263 the mobile carrier handling the call will each provide one. There 264 may be circumstances where there is a service provider who is unaware 265 that the call is an emergency call and cannot reasonably be expected 266 to determine that it is an emergency call. In that case, that 267 service provider is not expected to provide emergencyCallData. 269 Note: The access network MAY supply additional data as well. For 270 this purpose, this document defines a namespace and adds the 271 namespace to the "provided-by" registry defined by PIDF-LO [RFC4119]. 273 In regions where callers can elect to suppress certain personally 274 identifying information, the network or PSAP functionality can 275 inspect privacy flags within the SIP headers to determine what 276 information may be passed, stored, or displayed to comply with local 277 policy or law. 279 Additional data about a call is defined as a series of MIME objects, 280 each with an XML data structure contained inside. MIME-multipart is 281 used to enclose the XML documents and the sections below define them. 282 When additional data is passed by value, the CID URL points one 283 block. Multiple URIs must be used within a Call-Info header to point 284 to each of the blocks. When additional data is provided by 285 reference, the data is retrieved with an HTTP Get operation, which 286 returns a multi-part MIME header and a set of MIME blocks defined by 287 this document. A registry of allowed types is created by this 288 document. Every block MUST be one of the types in the registry. 290 4. Data Provider Information 292 This block is intended to be provided by any service provider in the 293 path of the call or the access network provider. It includes 294 identification and contact information. This block SHOULD be 295 provided for every service provider in the path of the call, and the 296 access network provider. Devices MAY use this block to provide 297 identifying information. The MIME type is "addDataProviderInfo+xml". 299 4.1. Data Provider String 301 Data Element: Data Provider String 303 Use: Required 305 XML Element: 307 Description: This is a plain language string suitable for displaying 308 the name of the service provider that created the additional data 309 structure. If the device created the structure the value is 310 identical to the contact header in the SIP INVITE. 312 Reason for Need: Inform the call taker of the identity of the entity 313 providing the additional call data structure. 315 How Used by Call Taker: Allows the call taker to interpret the data 316 in this structure. The source of the information often influences 317 how the information is used, believed or verified. 319 4.2. Data Provider ID 321 Data Element: Data Provider ID 323 Use: Conditional. Must be provided if the service provider is 324 located in a jurisdiction that maintains such ids. Devices are 325 not required to provide it. 327 XML Element: 328 Description: A jurisdiction specific code for the provider shown in 329 the element that created the structure of the 330 call. This data SHOULD be provided if the local jurisdiction 331 maintains such an ID list. For example, in North America, this 332 would be a "NENA Company ID". Devices SHOULD NOT use this 333 element. 335 Reason for Need: Inform the call taker of the identity of the entity 336 providing the additional call data structure. 338 How Used by Call Taker: Where jurisdictions have lists of providers 339 the Data Provider ID can be useful. 341 4.3. Data Provider ID Series 343 Data Element: Data Provider ID Series 345 Use: Conditional. If Data Provider ID is provided, Data Provider ID 346 Series is required. 348 XML Element: 350 Description: Identifies the issuer of the the ProviderId. A 351 registry will reflect the following valid entries: 353 * NENA 355 * EENA 357 Reason for Need: Identifies how to interpret the Data Provider ID. 359 How Used by Call Taker: Determines which provider ID registry to 360 consult for more information 362 4.4. Type of Data Provider 364 Data Element: Type of Data Provider ID 365 Use: Conditional. If Data Provider ID is provided, Type of Data 366 Provider ID is required. 368 XML Element: 370 Description: Identifies the type of data provider id being supplied 371 in the ProviderId data element. A registry will reflect the 372 following valid entries: 374 * Access Infrastructure Provider 376 * Service Provider 378 * Service Provider Subcontractor 380 * Telematics Provider 382 * Relay Provider 384 * Other 386 Reason for Need: Identifies what kind of data provider this is. 388 How Used by Call Taker: To decide who to contact when further 389 information is needed 391 4.5. Data Provider Contact URI 393 Data Element: Data Provider Contact URI 395 Use: Required 397 XML Element: 399 Description: For a service provider the contact SHOULD be a contact 400 URI. This MUST be a SIP URI. If a telephone number is the 401 contact address it should be provided in the form of 402 sip:telephonenumber@serviceprovider:user=phone. If the call is 403 from a device, this would reflect the contact information of the 404 owner of the device. When provided by a service provider, this 405 would be a URI to a 24/7 support organization tasked to provide 406 PSAP support for this emergency call. 408 Reason for Need: Additional data providers may need to be contacted 409 for error or other unusual circumstances. 411 How Used by Call Taker: To contact the supplier of the additional 412 data for assistance in handling the call. 414 4.6. Data Provider Languages(s) Supported 416 Data Element: Data Provider Language(s) supported 418 Use: Conditional 420 XML Element: 422 Description: The language used by the entity at the Data Provider 423 Contact URI as an alpha 2-character code as defined in ISO 639- 424 1:2002 (http://www.iso.org/iso/catalogue_detail?csnumber=22109) 425 Codes for the representation of names of languages -- Part 1: 426 Alpha-2 code Multiple instances of this element may occur. Order 427 is significant; preferred language should appear first. This data 428 is required if a Data Provider Contact URI is provided. The 429 content must reflect the languages supported at the contact URI. 431 Reason for Need: Information needed to determine if emergency 432 service authority can communicate with the service provider or if 433 an interpreter will be needed. 435 How Used by Call Taker: If call taker cannot speak language(s) 436 supported by the service provider, a translation service will need 437 to be added to the conversation. 439 4.7. xCard of Data Provider 441 Data Element: xCard of Data Provider 442 Use: Optional 444 XML Element: 446 Description: There are many fields in the xCARD and the creator of 447 the data structure is encouraged to provide as much information as 448 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 449 minimum. N should contain name of support group or device owner 450 as appropriate. If more than one TEL property is provided, a 451 parameter from the vCard Property Value registry MUST be specified 452 on each TEL. For encoding of the xCard this specification uses 453 the XML-based encoding specified in [RFC6351]. 455 and is hereinafter referred to as "xCard" 457 Reason for Need: Information needed to determine additional contact 458 information. 460 How Used by Call Taker: Assists call taker by providing additional 461 contact information that may not be included in the SIP invite or 462 the PIDF-LO. 464 4.8. Subcontractor Principal 466 Data Element: Subcontractor Principal 468 XML Element: 470 Description: If the data provider is a subcontractor to another 471 provider such as an access infrastructure provider or telematics 472 provider, this element contains the DataProviderString of the 473 service provider to indicate which provider the subcontractor is 474 working for. This data is required if the Data Provider type is 475 subcontractor. 477 Reason for Need: Identify the entity the subcontractor works for. 479 How Used by Call Taker: Allows the call taker to understand what the 480 relationship between data providers and the service providers in 481 the path of the call are. 483 4.9. Subcontractor Priority 485 Data Element: Subcontractor Priority 487 Use: Required 489 XML Element: 491 Description: If the subcontractor should be contacted first, this 492 element should have a "sub" value. If the access or origination 493 service provider should be contacted first, this element should 494 have a "main" value. This data is required if the Data Provider 495 type is "subcontractor". 497 Reason for Need: Inform the call taker whether the network operator 498 or the subcontractor should be contacted first if support is 499 needed. 501 How Used by Call Taker: To decide which entity to contact first if 502 assistance is needed. 504 4.10. addDataProviderInfo XML Schema 506 507 515 518 519 520 521 522 524 525 526 527 529 531 533 535 537 539 541 542 543 544 546 Figure 1: addDataProviderInfo XML Schema 548 5. Service Information 550 This block describes the service that the service provider provides 551 to the caller. It SHOULD be included by all SPs in the path of the 552 call. The mime type is "addCallSvcInfo+xml". 554 5.1. Service Environment 556 Data Element: Service Environment 558 Use: Required 560 XML Element: 562 Description: This element defines whether a call is from a business 563 or residence caller. Currently, the only valid entries are 564 'Business' or 'Residence'. 566 Reason for Need: To assist in determining equipment and manpower 567 requirements. 569 How Used by Call Taker: Information may be used to assist in 570 determining equipment and manpower requirements for emergency 571 responders. As the information is not always available, and the 572 registry is not all encompassing, this is at best advisory 573 information, but since it mimics a similar capability in some 574 current emergency calling systems, it is known to be valuable. 575 The service provider uses it's best information (such as a rate 576 plan, facilities used to deliver service or service description) 577 to determine the information and is not responsible for 578 determining the actual characteristics of the location where the 579 call originates from. 581 5.2. Service Delivered by Provider to End User 583 Data Element: Service Delivered by Provider to End User 585 Use: Required 586 XML Element: 588 Description: This defines the type of service the end user has 589 subscribed to. The implied mobility of this service can not be 590 relied upon. A registry will reflect the following initial valid 591 entries: 593 * Wireless Telephone Service: Includes Satellite, CDMA, GSM, 594 Wi-Fi, WiMAX, LTE (Long Term Evolution) 596 * Fixed Public Pay/Coin telephones: Any coin or credit card 597 operated device. 599 * One way outbound service 601 * Inmate call/service 603 * Soft dialtone/quick service/warm disconnect/suspended 605 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 606 key systems, Shared Tenant Service. 608 * Sensor, unattended: Includes devices that generate DATA ONLY. 609 This is one-way information exchange and there will be no other 610 form of communication. 612 * Sensor, attended: Includes devices that are supported by a 613 monitoring service provider or automatically open a two-way 614 communication path. 616 * Wireline: Plain Old Telephone Service (POTS). 618 * VoIP Telephone Service: A type of service that offers 619 communication over internet protocol, such as Fixed, Nomadic, 620 Mobile, Unknown 622 * Relay Service: a type of service where there is a human 3rd 623 party agent who provides some kind of additional assistance to 624 the caller. Includes sign language relay and telematics 625 services which provide a service assistant on the call. 627 * Remote (off premise extension) 629 There can be more than one value returned. For example, a VoIP 630 inmate telephone service is a reasonable combination. 632 Reason for Need: Knowing the type of service may assist the PSAP 633 with the handling of the call. 635 How Used by Call Taker: Call takers often use this information to 636 determine what kinds of questions to ask callers, and how much to 637 rely on supportive information. An emergency call from a prison 638 is treated differently that a call from a sensor device. As the 639 information is not always available, and the registry is not all 640 encompassing, this is at best advisory information, but since it 641 mimics a similar capability in some current emergency calling 642 systems, it is known to be valuable. 644 5.3. Service Mobility Environment 646 Data Element: Service Mobility Environment 648 Use: Required 650 XML Element: 652 Description: This provides the service providers view of the 653 mobility of the caller. As the service provider may not know the 654 characteristics of the actual access network used, the value not 655 be relied upon. A registry will reflect the following initial 656 valid entries: 658 * Mobile: the device should be able to move at any time 660 * Fixed: the device is not expected to move unless the service is 661 relocated 663 * Nomadic: the device is not expected to move while on a call, 664 but may move between calls 666 Reason for Need: Knowing the service provider's belief of mobility 667 may assist the PSAP with the handling of the call. 669 How Used by Call Taker: To determine whether to assume the location 670 of the caller might change. 672 5.4. addCallSvcInfo XML Schema 674 675 682 685 686 687 688 690 692 694 696 697 698 699 701 Figure 2: addCallSvcInfo XML Schema 703 6. Device Information 705 This block provides information about the device used to place the 706 call. It should be provided by any service provider that knows what 707 device is being used, and by the device itself. The mime type is 708 "addDataDevInfo+xml". 710 6.1. Device Classification 712 Data Element: Device Classification 714 Use: Optional 716 XML Element: 718 Description: This data element defines the kind of device making the 719 emergency call. If the device provides the data structure, the 720 device information SHOULD be provided. If the service provider 721 provides the structure and it knows what the device is, the 722 service provider SHOULD provide the device information. Often the 723 carrier does not know what the device is. It is possible to 724 receive two Additional Data Associated with a Call data 725 structures, one created by the device and one created by the 726 service provider. This information describes the the device, not 727 how it is being used. This data element defines the kind of 728 device making the emergency call. A registry will reflect the 729 following valid entries: 731 * Cordless handset 733 * Fixed phone 735 * Mobile handset 737 * ATA (analog terminal adapter) 739 * Satellite phone 741 * Stationary computing device (alarm system, data sensor) 743 * Guardian devices 745 * Desktop PC 746 * Laptop computing device 748 * Tablet computing device 750 * Alarm system 752 * Data sensor 754 * Personal beacons (spot) 756 * Auto telematics (indicates VEDS data set) 758 * Trucking telematics 760 * Farm equipment telematics 762 * Marine telematics 764 * PDA (personal digital assistant) 766 * PND (personal navigation device) 768 * Smart phone 770 * Internet tablet 772 * Gaming console 774 * Video phone 776 * Other text device 778 * Not Available 780 Reason for Need: The device classification implies the capability of 781 the calling device and assists in identifying the meaning of the 782 emergency call location information that is being presented. For 783 example, does the device require human intervention to initiate a 784 call or is this call the result of programmed instructions? Does 785 the calling device have the ability to update location or 786 condition changes? Is this device interactive or a one-way 787 reporting device? 789 How Used by Call Taker: May assist with location of caller. For 790 example, a cordless handset may be outside or next door. May 791 provide calltaker some context about the caller, the capabilities 792 of the device used for the call or the environment the device is 793 being used in. 795 6.2. Device Manufacturer 797 Data Element: Device Manufacturer 799 Use: Optional 801 XML Element: 803 Description: The plain language name of the manufacturer of the 804 device. 806 Reason for Need: Used by PSAP management for post-mortem 807 investigation/resolution. 809 How Used by Call Taker: Probably not used by calltaker, but by PSAP 810 management. 812 6.3. Device Model Number 814 Data Element: Device Model Number 816 Use: Optional 818 XML Element: 820 Description: Model number of the device. 822 Reason for Need: Used by PSAP management for after action 823 investigation/resolution. 825 How Used by Call Taker: Probably not used by calltaker, but by PSAP 826 management. 828 6.4. Unique Device Identifier 830 Data Element: Unique Device Identifier 832 Use: Optional 834 XML Element: 836 Description: String that identifies the specific device making the 837 call or creating an event. 839 Reason for Need: Uniquely identifies the device as opposed to any 840 signaling identifiers encountered in the call signaling stream. 842 How Used by Call Taker: Probably not used by calltaker they would 843 need to refer to management for investigation. 845 6.5. Type of Device Identifier 847 Data Element: Type of Device Identifier 849 Use: Conditional: must be provided if DeviceID is provided 851 XML Element: 853 Description: Identifies the type of device identifier being 854 generated in the unique device identifier data element. A 855 registry will reflect the following valid entries: 857 * MEID (CDMA) 859 * ESN (Electronic Serial Number -- superseded by MEID) 861 * MAC (Media Access Control) Address -- IEEE-delegated address of 862 any of the interfaces of the device with a MAC address (e.g., 863 Ethernet, WiFi) 865 * WiMAX device certificate subject unique identifier 867 * IMEI (International Mobile Equipment Identifier - GSM) 869 * Unique Device Identifier (UDI) assigned by US FD for medical 870 devices 872 * RFID (Radio Frequency Identification) 874 * Sensors (types to be identified in a future document version) 876 * Manufacturer Serial Number 878 * Other 880 Reason for Need: Identifies how to interpret the Unique Device 881 Identifier. 883 How Used by Call Taker: Additional information that may be used to 884 assist with call handling. 886 6.6. Device/Service Specific Additional Data Structure 888 Data Element: Device/service specific additional data structure 890 Use: Optional 892 XML Element: 894 Description: A URI representing additional data whose schema is 895 specific to the device or service which created it. An example is 896 the VEDs structure for a vehicle telematics device. The URI, when 897 dereferenced, MUST yield a data structure defined by the Device/ 898 service specific additional data type value. Different data may 899 be created by each classification; e.g., telematics creates VEDS 900 data set. 902 Reason for Need: Provides device/service specific data that may be 903 used by the call taker and/or responders. 905 How Used by Call Taker: Provide information to guide call takers to 906 select appropriate responders, give appropriate pre-arrival 907 instructions to callers, and advise responders of what to be 908 prepared for. May be used by responders to guide assistance 909 provided. 911 6.7. Device/Service Specific Additional Data Structure Type 913 Data Element: Type of Device/service specific additional data 914 structure 916 Use: Conditional. MUST be provided when Device/service specific 917 additional URI is provided 919 XML Element: 921 Description: Value from a registry defined by this document to 922 describe the type of data that can be retrieved from the Device/ 923 service specific additional data structure. Initial values are: 925 * IEEE 1512 - USDOT Model for traffic incidents 927 * VEDS 929 Reason for Need: This data element allows identification of 930 externally defined schemas, which may have additional data that 931 may assist in emergency response. 933 How Used by Call Taker: This data element allows the end user 934 (calltaker or first responder) to know what type of additional 935 data may be available to aid in providing the needed emergency 936 services. 938 Note: Information which is specific to a location or a caller 939 (person) should not be placed in this section. 941 6.8. addDataDevInfo XML Schema 943 944 951 954 955 956 957 959 961 963 965 967 969 971 972 973 974 976 Figure 3: addDataDevInfo XML Schema 978 7. Owner/Subscriber Information 980 This block describes the owner of the device (if provided by the 981 device) or the subscriber information, if provided by a service 982 provider. The contact location is not necessarily the location of 983 the caller or incident, but is rather the nominal contact address. 984 The mime type is "addCallSub+xml". 986 7.1. xCard for Subscriber's Data 988 Data Element: xCARD for Subscriber's Data 990 Use: Conditional: Some services (e.g. prepaid phones, initialized 991 phones, etc.) may not have this information. 993 XML Element: 995 Description: Information known by the service provider or device 996 about the subscriber; e.g., Name, Address, Individual Telephone 997 Number, Main Telephone Number and any other data. N, ORG (if 998 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 999 than one TEL property is provided, a parameter from the vCard 1000 Property Value registry MUST be specified on each TEL. 1002 Reason for Need: When the caller is unable to provide information, 1003 this data may be used to obtain it 1005 How Used by Call Taker: Obtaining critical information about the 1006 caller and possibly the location when it is not able to be 1007 obtained otherwise. 1009 7.2. addCallSub XML Schema 1011 1012 1020 1023 1024 1025 1026 1028 1029 1030 1031 1033 Figure 4: addCallSub XML Schema 1035 8. Comment 1037 This block Provides a mechanism for the data provider to supply 1038 extra, human readable information to the PSAP. It is not intended 1039 for a general purpose extension mechanism 1041 8.1. Comment 1043 Data Element: Comment 1045 Use: Optional 1047 XML Element: 1049 Description: Human readable text providing additional information to 1050 the PSAP. 1052 Reason for Need: Explanatory information for values in the data 1053 structure 1055 How Used by Call Taker: To interpret the data provided 1057 8.2. Comment XML Schema 1059 1060 1067 1070 1071 1072 1073 1075 1076 1077 1078 1080 Figure 5: Comment XML Schema 1082 9. Example 1084 INVITE sips:bob@biloxi.example.com SIP/2.0 1085 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1086 Max-Forwards: 70 1087 To: Bob 1088 From: Alice ;tag=9fxced76sl 1089 Call-ID: 3848276298220188511@atlanta.example.com 1090 Call-Info: ;purpose=icon, 1091 ;purpose=info, 1092 ;purpose=emergencyCallData 1093 Geolocation: 1094 Geolocation-Routing: no 1095 Accept: application/sdp, application/pidf+xml, 1096 application/addDataProviderinfo+xml 1097 CSeq: 31862 INVITE 1098 Contact: 1099 Content-Type: multipart/mixed; boundary=boundary1 1101 Content-Length: ... 1103 --boundary1 1105 Content-Type: application/sdp 1107 ...SDP goes here 1109 --boundary1 1111 Content-Type: application/pidf+xml 1112 Content-ID: 1114 ...PIDF-LO goes here 1116 --boundary1-- 1118 Content-Type: application/addDataProviderinfo+xml 1119 Content-ID: <1234567890@atlanta.example.com> 1121 ...Additional Data goes here 1123 --boundary1-- 1125 Example: Attaching Additional Data via CID to a SIP INVITE 1127 10. Main Telephone Number 1129 In a xCard, used extensively in this document, there is no way to 1130 specify a "Main" telephone number. These numbers are useful to 1131 emergency responders who are called to a large enterprise. This 1132 document adds a new Property Value to the "tel" property of the TYPE 1133 parameter called "main". It can be used in any xCard in additional 1134 data. 1136 11. Security Considerations 1138 The information in this data structure will usually be considered 1139 private. HTTPS is specified to require the provider of the 1140 information to validate the credentials of the requester. While the 1141 creation of a PKI that has global scope may be difficult, the 1142 alternatives to creating devices and services that can provide 1143 critical information securely are more daunting. The provider may 1144 enforce any policy it wishes to use, but PSAPs and responder agencies 1145 should deploy a PKI so that providers of additional data can check 1146 the certificate of the client and decide the appropriate policy to 1147 enforce based on that certificate. 1149 Ideally, the PSAP and emergency responders will be given credentials 1150 signed by an authority trusted by the data provider. In most 1151 circumstances, nationally recognized credentials would be sufficient, 1152 and if the emergency services arranges a PKI, data providers could be 1153 provisioned with the root CA public key for a given nation. Some 1154 nations are developing a PKI for this, and related, purposes. Since 1155 calls could be made from devices where the device and/or the service 1156 provider(w) are not local to the emergency authorities, globally 1157 recognized credentials are useful. This might be accomplished by 1158 extending the notion of the "forest guide" described in [RFC5222] to 1159 allow the forest guide to provide the credential of the PKI root for 1160 areas that it has coverage information for, but standards for such a 1161 mechanism are not yet available. In its absence, the data provider 1162 will need to obtain the root CA credentials for any areas it is 1163 willing to provide additional data by out of band means. With the 1164 credential of the root CA for a national emergency services PKI, the 1165 data provider server can validate the credentials of an entity 1166 requesting additional data by reference. 1168 The data provider also needs a credential that can be verified by the 1169 emergency services to know that it is receiving data from the right 1170 server. The emergency authorities could provide credentials, 1171 distinguishable from credentials it provides to emergency responders 1172 and PSAPs, which could be used to validate data providers. This 1173 would be extensible to global credential validation using the forest 1174 guide as above. In the absence of such credentials, the emergency 1175 authorities could maintain a list of local data providers' 1176 credentials provided to it out of band. At a minimum, the emergency 1177 authorities could obtain a credential from the DNS entry of the 1178 domain in the Addional Data URI to at least validate that the server 1179 is known to the domain providing the URI. 1181 Data provided by devices by reference have similar credential 1182 validation issues to service providers, and the solutions are the 1183 same. 1185 12. Privacy Considerations 1187 There is much private data in this information. Local regulations 1188 may govern what data must be provided in emergency calls, but in 1189 general, the emergency call system is often aided by the kinds of 1190 information described in this document. There is a tradeoff between 1191 the privacy considerations and the utility of the data. Certainly, 1192 if the data cannot be protected, due to failure to establish (by TLS) 1193 a secure connection to the data provider, data SHOULD NOT be sent 1194 unless specifically required by regulation. 1196 13. IANA Considerations 1198 13.1. Registry creation 1200 This document creates a new registry called 'Emergency Call 1201 Additional Data'. The following subregistries are created in 1202 Emergency Call Additional Data: 1204 13.1.1. Additional Call Data Blocks Registry 1206 This document creates a new subregistry called 'Provider ID Series'. 1207 As defined in [RFC5226], this registry operates under "Expert Review" 1208 rules. The expert should determine that the entity requesting a new 1209 value is a legitimate issuer of service provider IDs suitable for use 1210 in Additional Call Data. 1212 The content of this registry includes: 1214 Name: The identifier which will be used in the ProviderIDSeries 1215 element 1217 Source: The full name of the organization issuing the identifiers 1219 URL: A URL to the organization for further information 1221 The values defined are: 1223 +-----------+-----------+--------------+--------------+ 1224 | Name | Source | URL | 1225 +-----------+--------------------------+--------------+ 1226 | NENA | North American Emergency | www.nena.org | 1227 | | Number Association | | 1228 | EENA | European Emergency | www.eena.org | 1229 | | Number Association | | 1230 +-----------+--------------------------+--------------+ 1231 RFC Editor Note: 1232 replace XXXX in the table above with this documents RFC number 1234 13.1.2. Service Provider Type 1236 This document creates a new subregistry called 'Service Provider 1237 Type'. As defined in [RFC5226], this registry operates under "Expert 1238 Review". The expert should determine that the proposed new value is 1239 distinct from existing values and appropriate for use in the 1240 TypeOfServicerProvider element 1242 The content of this registry includes: 1244 Name: Value to be used in TypeOfServiceProvider. 1246 Description: A short description of the type of service provider 1248 The values defined are: 1250 +------------------------------+------------------------------------+ 1251 | Name | Description | 1252 +------------------------------+------------------------------------+ 1253 |Access Infrastructure Provider| Access network service provider | 1254 |Service Provider | Calling or Origination telecom SP | 1255 |Service Provider Subcontractor| A contractor to another kind of SP | 1256 |Telematics Provider | A sensor based SP, especially | 1257 | | vehicle based | 1258 |Relay Provider | A interpretation SP, for example, | 1259 | | video relay for sign language | 1260 | | interpretors | 1261 |Other | Any other type of service provider | 1262 +------------------------------+------------------------------------+ 1263 RFC Editor Note: 1264 replace XXXX in the table above with this documents RFC number 1266 13.1.3. Additional Call Data Blocks Registry 1268 This document creates a new subregistry called 'Additional Call Data 1269 Blocks'. As defined in [RFC5226], this registry operates under 1270 "Expert Review" and "Specification Required" rules. 1272 The content of this registry includes: 1274 Name: Element Name of enclosing block. 1276 Reference: The document that describes the block 1278 The values defined are: 1280 +---------------------+-----------+ 1281 | Name | Reference | 1282 +---------------------+-----------+ 1283 | addDataProviderInfo | RFCXXXX | 1284 | addCallSvcInfo | RFCXXXX | 1285 | addCallSvcInfo | RFCXXXX | 1286 | addCallSub | RFCXXXX | 1287 | addCallComment | RFCXXXX | 1288 +---------------------+-----------+ 1289 RFC Editor Note: 1290 replace XXXX in the table above with this documents RFC number 1292 13.1.4. Additional Call Data Service Delivered Registry 1294 This document creates a new registry called 'Additional Call Data 1295 Service Delivered'. As defined in [RFC5226], this registry operates 1296 under "Expert Review" rules. 1298 The content of this registry includes: 1300 Name: enumeration token of the service. 1302 Description: Short description identifying the service. 1304 The values defined are: 1306 +--------+----------------------------------------+ 1307 | Name | description | 1308 +--------+-------+--------------------------------+ 1309 | Wrless | Wireless Telephone Service: Includes | 1310 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 1311 | | LTE (Long Term Evolution) | 1312 | Coin | Fixed Public Pay/Coin telephones: Any | 1313 | | coin or credit card operated device | 1314 | 1way | One way outbound service | 1315 | Prison | Inmate call/service | 1316 | Temp | Soft dialtone/quick service/warm | 1317 | | disconnect/suspended | 1318 | MLTS | Multi-line telephone system: Includes | 1319 | | all PBX, Centrex, key systems, | 1320 | | Shared Tenant Service | 1321 | SenseU | Sensor, unattended: Includes devices | 1322 | | that generate DATA ONLY. This is | 1323 | | one-way information exchange and | 1324 | | there will be no other form of | 1325 | | communication | 1326 | SenseA | Sensor, attended: Includes devices | 1327 | | that are supported by a monitoring | 1328 | | service provider or automatically | 1329 | | open a two-way communication path | 1330 | POTS | Wireline: Plain Old Telephone Service | 1331 | VOIP | VoIP Telephone Service: A type of | 1332 | | service that offers communication | 1333 | | over internet protocol, such as Fixed| 1334 | | Nomadic, Mobile, ... | 1335 +--------+-------+--------------------------------+ 1337 13.1.5. Additional Call Data Device Classification Registry 1339 This document creates a new registry called 'Additional Call Data 1340 Device Classification'. As defined in [RFC5226], this registry 1341 operates under "Expert Review" rules. 1343 The content of this registry includes: 1345 Name: enumeration token of the device classification. 1347 Description: Short description identifying the device type. 1349 The values defined are: 1351 +--------+----------------------------------------+ 1352 | Name | description | 1353 +--------+-------+--------------------------------+ 1354 |Cordless| Cordless handset | 1355 | Fixed | Fixed phone | 1356 | Mobile | Mobile handset | 1357 | ATA | analog terminal adapter | 1358 |Satphone| Satellite phone | 1359 | FSense | Stationary computing device (alarm | 1360 | | system, data sensor) | 1361 | Guard | Guardian devices | 1362 | Desktop| Desktop PC | 1363 | Laptop | Laptop computing device | 1364 | Tablet | Tablet computing device | 1365 | Alarm | Alarm system | 1366 | MSense | Mobile Data sensor | 1367 | Beacon | Personal beacons (spot) | 1368 | Auto | Auto telematics | 1369 | Truck | Truck telematics | 1370 | Farm | Farm equipment telematics | 1371 | Marine | Marine telematics | 1372 | PDA | Personal digital assistant | 1373 | PND | Personal navigation device) | 1374 | SmrtPhn| Smart phone | 1375 | Itab | Internet tablet | 1376 | Game | Gaming console | 1377 | Video | Video phone | 1378 | Text | Other text device | 1379 | NA | Not Available | 1380 +--------+----------------------------------------+ 1382 13.1.6. Additional Call Data Device ID Type Registry 1384 This document creates a new registry called 'Additional Call Data 1385 Device ID Type'. As defined in [RFC5226], this registry operates 1386 under "Expert Review" rules. 1388 The content of this registry includes: 1390 Name: enumeration token of the device id type. 1392 Description: Short description identifying the type of device id. 1394 The values defined are: 1396 +--------+----------------------------------------+ 1397 | Name | description | 1398 +--------+-------+--------------------------------+ 1399 | MEID | Mobile Equipment Identifier (CDMA) | 1400 | ESN | Electronic Serial Number(GSM) | 1401 | MAC | Media Access Control Address (IEEE) | 1402 | WiMAX | device certificate unique id | 1403 | IMEI | International Mobile Equipment ID (GSM)| 1404 | UDI | Unique Device Identifier (medical) | 1405 | RFID | Radio Frequency Identification | 1406 | Sense | Sensors (types to be identified ) | 1407 | SN | Manufacturer Serial Number | 1408 | Other | Other | 1409 +--------+----------------------------------------+ 1411 13.2. 'emergencyCallData' Purpose Parameter Value 1413 This document defines the 'emergencyCallData' value for the "purpose" 1414 parameter of the Call-Info header field. The Call-Info header and 1415 the corresponding registry for the 'purpose' parameter was 1416 established with RFC 3261 [RFC3261]. 1418 Header Parameter New 1419 Field Name Value Reference 1420 ---------- --------- ----------------- --------- 1421 Call-Info purpose emergencyCallData [This RFC] 1423 13.3. URN Sub-Namespace Registration for provided-by Registry Entry 1425 This section registers the namespace specified in ??? in the 1426 provided-by registry established by RFC 4119. 1428 13.4. MIME Registrations 1430 13.4.1. MIME Content-type Registration for 'application/ 1431 addDataProviderInfo+xml' 1433 This specification requests the registration of a new MIME type 1434 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1435 RFC 3023 [RFC3023]. 1437 MIME media type name: application 1439 MIME subtype name: addDataProviderInfo+xml 1441 Mandatory parameters: none 1443 Optional parameters: charset 1445 Indicates the character encoding of enclosed XML. 1447 Encoding considerations: 1449 Uses XML, which can employ 8-bit characters, depending on the 1450 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1452 Security considerations: 1454 This content type is designed to carry the data provider 1455 information, which is a sub-category of additional data about an 1456 emergency call. 1458 Since this data contains personal information appropriate 1459 precautions have to be taken to limit unauthorized access, 1460 inappropriate disclosure to third parties, and eavesdropping of 1461 this information. Please refer to Section 11 and Section 12 for 1462 more information. 1464 Interoperability considerations: None 1466 Published specification: [TBD: This specification] 1468 Applications which use this media type: Emergency Services 1470 Additional information: 1472 Magic Number: None 1474 File Extension: .xml 1475 Macintosh file type code: 'TEXT' 1477 Person and email address for further information: Hannes 1478 Tschofenig, Hannes.Tschofenig@gmx.net 1480 Intended usage: LIMITED USE 1482 Author: This specification is a work item of the IETF ECRIT 1483 working group, with mailing list address . 1485 Change controller: The IESG 1487 13.4.2. MIME Content-type Registration for 'application/ 1488 addCallSvcInfo+xml' 1490 This specification requests the registration of a new MIME type 1491 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1492 RFC 3023 [RFC3023]. 1494 MIME media type name: application 1496 MIME subtype name: addCallSvcInfo+xml 1498 Mandatory parameters: none 1500 Optional parameters: charset 1502 Indicates the character encoding of enclosed XML. 1504 Encoding considerations: 1506 Uses XML, which can employ 8-bit characters, depending on the 1507 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1509 Security considerations: 1511 This content type is designed to carry the service information, 1512 which is a sub-category of additional data about an emergency 1513 call. 1515 Since this data contains personal information appropriate 1516 precautions have to be taken to limit unauthorized access, 1517 inappropriate disclosure to third parties, and eavesdropping of 1518 this information. Please refer to Section 11 and Section 12 for 1519 more information. 1521 Interoperability considerations: None 1523 Published specification: [TBD: This specification] 1525 Applications which use this media type: Emergency Services 1527 Additional information: 1529 Magic Number: None 1531 File Extension: .xml 1533 Macintosh file type code: 'TEXT' 1535 Person and email address for further information: Hannes 1536 Tschofenig, Hannes.Tschofenig@gmx.net 1538 Intended usage: LIMITED USE 1540 Author: This specification is a work item of the IETF ECRIT 1541 working group, with mailing list address . 1543 Change controller: The IESG 1545 13.4.3. MIME Content-type Registration for 'application/ 1546 addDataDevInfo+xml' 1548 This specification requests the registration of a new MIME type 1549 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1550 RFC 3023 [RFC3023]. 1552 MIME media type name: application 1554 MIME subtype name: addDataDevInfo+xml 1556 Mandatory parameters: none 1558 Optional parameters: charset 1560 Indicates the character encoding of enclosed XML. 1562 Encoding considerations: 1564 Uses XML, which can employ 8-bit characters, depending on the 1565 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1567 Security considerations: 1569 This content type is designed to carry the device information 1570 information, which is a sub-category of additional data about an 1571 emergency call. 1573 Since this data contains personal information appropriate 1574 precautions have to be taken to limit unauthorized access, 1575 inappropriate disclosure to third parties, and eavesdropping of 1576 this information. Please refer to Section 11 and Section 12 for 1577 more information. 1579 Interoperability considerations: None 1581 Published specification: [TBD: This specification] 1583 Applications which use this media type: Emergency Services 1585 Additional information: 1587 Magic Number: None 1589 File Extension: .xml 1591 Macintosh file type code: 'TEXT' 1593 Person and email address for further information: Hannes 1594 Tschofenig, Hannes.Tschofenig@gmx.net 1596 Intended usage: LIMITED USE 1598 Author: This specification is a work item of the IETF ECRIT 1599 working group, with mailing list address . 1601 Change controller: The IESG 1603 13.4.4. MIME Content-type Registration for 'application/addCallSub+xml' 1605 This specification requests the registration of a new MIME type 1606 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1607 RFC 3023 [RFC3023]. 1609 MIME media type name: application 1611 MIME subtype name: addCallSub+xml 1612 Mandatory parameters: none 1614 Optional parameters: charset 1616 Indicates the character encoding of enclosed XML. 1618 Encoding considerations: 1620 Uses XML, which can employ 8-bit characters, depending on the 1621 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1623 Security considerations: 1625 This content type is designed to carry owner/subscriber 1626 information, which is a sub-category of additional data about an 1627 emergency call. 1629 Since this data contains personal information appropriate 1630 precautions have to be taken to limit unauthorized access, 1631 inappropriate disclosure to third parties, and eavesdropping of 1632 this information. Please refer to Section 11 and Section 12 for 1633 more information. 1635 Interoperability considerations: None 1637 Published specification: [TBD: This specification] 1639 Applications which use this media type: Emergency Services 1641 Additional information: 1643 Magic Number: None 1645 File Extension: .xml 1647 Macintosh file type code: 'TEXT' 1649 Person and email address for further information: Hannes 1650 Tschofenig, Hannes.Tschofenig@gmx.net 1652 Intended usage: LIMITED USE 1654 Author: This specification is a work item of the IETF ECRIT 1655 working group, with mailing list address . 1657 Change controller: The IESG 1659 13.4.5. MIME Content-type Registration for 'application/ 1660 addCallComment+xml' 1662 This specification requests the registration of a new MIME type 1663 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1664 RFC 3023 [RFC3023]. 1666 MIME media type name: application 1668 MIME subtype name: addCallComment+xml 1670 Mandatory parameters: none 1672 Optional parameters: charset 1674 Indicates the character encoding of enclosed XML. 1676 Encoding considerations: 1678 Uses XML, which can employ 8-bit characters, depending on the 1679 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1681 Security considerations: 1683 This content type is designed to carry a comment, which is a sub- 1684 category of additional data about an emergency call. 1686 This data may contain personal information. Appropriate 1687 precautions may have to be taken to limit unauthorized access, 1688 inappropriate disclosure to third parties, and eavesdropping of 1689 this information. Please refer to Section 11 and Section 12 for 1690 more information. 1692 Interoperability considerations: None 1694 Published specification: [TBD: This specification] 1696 Applications which use this media type: Emergency Services 1698 Additional information: 1700 Magic Number: None 1702 File Extension: .xml 1704 Macintosh file type code: 'TEXT' 1705 Person and email address for further information: Hannes 1706 Tschofenig, Hannes.Tschofenig@gmx.net 1708 Intended usage: LIMITED USE 1710 Author: This specification is a work item of the IETF ECRIT 1711 working group, with mailing list address . 1713 Change controller: The IESG 1715 13.5. URN Sub-Namespace Registration 1717 13.5.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo 1719 This section registers a new XML namespace, as per the guidelines in 1720 RFC 3688 [RFC3688]. 1722 URI: urn:ietf:params:xml:ns:addDataProviderInfo 1724 Registrant Contact: IETF, ECRIT working group, , as 1725 delegated by the IESG . 1727 XML: 1729 BEGIN 1730 1731 1733 1734 1735 1737 Namespace for Additional Emergency Call Data: 1738 Data Provider Information 1739 1740 1741

Namespace for Additional Data related to an Emergency Call

1742

Data Provider Information

1743

See [TBD: This document].

1744 1745 1746 END 1748 13.5.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo 1750 This section registers a new XML namespace, as per the guidelines in 1751 RFC 3688 [RFC3688]. 1753 URI: urn:ietf:params:xml:ns:addCallSvcInfo 1755 Registrant Contact: IETF, ECRIT working group, , as 1756 delegated by the IESG . 1758 XML: 1760 BEGIN 1761 1762 1764 1765 1766 1768 Namespace for Additional Emergency Call Data: 1769 Service Information 1770 1771 1772

Namespace for Additional Data related to an Emergency Call

1773

Service Information

1774

See [TBD: This document].

1775 1776 1777 END 1779 13.5.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo 1781 This section registers a new XML namespace, as per the guidelines in 1782 RFC 3688 [RFC3688]. 1784 URI: urn:ietf:params:xml:ns:addDataDevInfo 1786 Registrant Contact: IETF, ECRIT working group, , as 1787 delegated by the IESG . 1789 XML: 1791 BEGIN 1792 1793 1795 1796 1797 1799 Namespace for Additional Emergency Call Data: 1800 Device Information 1801 1802 1803

Namespace for Additional Data related to an Emergency Call

1804

Device Information

1805

See [TBD: This document].

1806 1807 1808 END 1810 13.5.4. Registration for urn:ietf:params:xml:ns:addCallSub 1812 This section registers a new XML namespace, as per the guidelines in 1813 RFC 3688 [RFC3688]. 1815 URI: urn:ietf:params:xml:ns:addCallSub 1817 Registrant Contact: IETF, ECRIT working group, , as 1818 delegated by the IESG . 1820 XML: 1822 BEGIN 1823 1824 1826 1827 1828 1830 Namespace for Additional Emergency Call Data: 1831 Owner/Subscriber Information 1832 1833 1834

Namespace for Additional Data related to an Emergency Call

1835

Owner/Subscriber Information

1836

See [TBD: This document].

1837 1838 1839 END 1841 13.5.5. Registration for urn:ietf:params:xml:ns:addCallComment 1843 This section registers a new XML namespace, as per the guidelines in 1844 RFC 3688 [RFC3688]. 1846 URI: urn:ietf:params:xml:ns:addCallComment 1848 Registrant Contact: IETF, ECRIT working group, , as 1849 delegated by the IESG . 1851 XML: 1853 BEGIN 1854 1855 1857 1858 1859 1861 Namespace for Additional Emergency Call Data:Comment 1862 1863 1864

Namespace for Additional Data related to an Emergency Call

1865

Comment

1866

See [TBD: This document].

1867 1868 1869 END 1871 13.6. Schema Registrations 1873 This specification registers five schemas, as per the guidelines in 1874 RFC 3688 [RFC3688]. 1876 URI: 1877 urn:ietf:params:xml:schema:additional-data:addDataProviderInfo 1879 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1880 delegated by the IESG (iesg@ietf.org). 1882 XML: The XML schema can be found in Figure 1. 1884 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 1886 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 1887 delegated by the IESG (iesg@ietf.org). 1889 XML: The XML schema can be found in Figure 2. 1891 URI: urn:ietf:params:xml:schema:additional-data:addDataDevInfo 1893 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1894 delegated by the IESG (iesg@ietf.org). 1896 XML: The XML schema can be found in Figure 3. 1898 URI: urn:ietf:params:xml:schema:additional-data:addCallSub 1900 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1901 delegated by the IESG (iesg@ietf.org). 1903 XML: The XML schema can be found in Figure 4. 1905 URI: urn:ietf:params:xml:schema:additional-data:addCallComment 1907 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 1908 delegated by the IESG (iesg@ietf.org). 1910 XML: The XML schema can be found in Figure 5. 1912 13.7. VCard Parameter Value Registration 1914 This document registers a new value in the vCARD Parameter Values 1915 registry as defined by [RFC6350] with the following template: 1917 Value: main 1919 Purpose: The main telephone number, typically of an enterprise, as 1920 opposed to a direct dial number of an individual employee 1922 Conformance: This value can be used with the "TYPE" parameter 1923 applied on the "TEL" property. 1925 Example(s): 1926 TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-9000 1928 14. Acknowledgments 1930 This work was originally started in NENA and has benefitted from a 1931 large number of participants in NENA standardization efforts, 1932 originally in the Long Term Definition Working Group, the Data 1933 Technical Committee and most recently the Additional Data working 1934 group. The authors are grateful for the initial work and extended 1935 comments provided by the many NENA participants. 1937 15. References 1939 15.1. Normative References 1941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1942 Requirement Levels", BCP 14, RFC 2119, March 1997. 1944 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1945 Locators", RFC 2392, August 1998. 1947 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1948 Types", RFC 3023, January 2001. 1950 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1951 A., Peterson, J., Sparks, R., Handley, M., and E. 1952 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1953 June 2002. 1955 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1956 January 2004. 1958 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1959 Format", RFC 4119, December 2005. 1961 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1962 Registration Procedures", BCP 13, RFC 4288, December 2005. 1964 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1965 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1966 May 2008. 1968 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 1969 August 2011. 1971 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1972 RFC 6351, August 2011. 1974 15.2. Informational References 1976 [I-D.iab-privacy-considerations] 1977 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1978 Morris, J., Hansen, M., and R. Smith, "Privacy 1979 Considerations for Internet Protocols", 1980 draft-iab-privacy-considerations-03 (work in progress), 1981 July 2012. 1983 [I-D.ietf-ecrit-phonebcp] 1984 Rosen, B. and J. Polk, "Best Current Practice for 1985 Communications Services in support of Emergency Calling", 1986 draft-ietf-ecrit-phonebcp-20 (work in progress), 1987 September 2011. 1989 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1990 Tschofenig, "LoST: A Location-to-Service Translation 1991 Protocol", RFC 5222, August 2008. 1993 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1994 "Framework for Emergency Calling Using Internet 1995 Multimedia", RFC 6443, December 2011. 1997 Authors' Addresses 1999 Brian Rosen 2000 NeuStar 2001 470 Conrad Dr. 2002 Mars, PA 16046 2003 US 2005 Phone: +1 724 382 1051 2006 Email: br@brianrosen.net 2008 Hannes Tschofenig 2009 Nokia Siemens Networks 2010 Linnoitustie 6 2011 Espoo 02600 2012 Finland 2014 Phone: +358 (50) 4871445 2015 Email: Hannes.Tschofenig@gmx.net 2016 URI: http://www.tschofenig.priv.at 2018 Roger Marshall 2019 TeleCommunication Systems, Inc. 2020 2401 Elliott Avenue 2021 Seattle, WA 98121 2022 US 2024 Phone: +1 206 792 2424 2025 Email: rmarshall@telecomsys.com 2026 URI: http://www.telecomsys.com