idnits 2.17.1 draft-ietf-ecrit-additional-data-37.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 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document updates RFC6443, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6881, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6443, updated by this document, for RFC5378 checks: 2006-10-26) (Using the creation date from RFC6881, updated by this document, for RFC5378 checks: 2006-10-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2015) is 3117 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) -- Looks like a reference, but probably isn't: '1' on line 3979 -- Looks like a reference, but probably isn't: '2' on line 3981 == Missing Reference: 'This RFC' is mentioned on line 3239, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-gellens-slim-negotiating-human-language-02 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Qualcomm Technologies, Inc. 4 Updates: 6443, 6881 (if approved) B. Rosen 5 Intended status: Standards Track NeuStar 6 Expires: April 14, 2016 H. Tschofenig 8 R. Marshall 9 TeleCommunication Systems, Inc. 10 J. Winterbottom 12 October 12, 2015 14 Additional Data Related to an Emergency Call 15 draft-ietf-ecrit-additional-data-37.txt 17 Abstract 19 When an emergency call is sent to a Public Safety Answering Point 20 (PSAP), the originating device, the access network provider to which 21 the device is connected, and all service providers in the path of the 22 call have information about the call, the caller or the location 23 which is helpful for the PSAP to have in handling the emergency. 24 This document describes data structures and mechanisms to convey such 25 data to the PSAP. The intent is that every emergency call carry as 26 much as possible of the information described here using the 27 mechanisms described here. 29 The mechanisms permit the data to be conveyed by reference (as an 30 external resource) or by value (within the body of a SIP message or a 31 location object). This follows the tradition of prior emergency 32 services standardization work where data can be conveyed by value 33 within the call signaling (i.e., in the body of the SIP message) or 34 by reference. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 14, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Data Provider Information . . . . . . . . . . . . . . . . 9 75 4.1.1. Data Provider String . . . . . . . . . . . . . . . . 9 76 4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 10 77 4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 10 78 4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 11 79 4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 12 80 4.1.6. Data Provider Languages(s) Supported . . . . . . . . 13 81 4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 14 82 4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 14 83 4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 15 84 4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 15 85 4.2. Service Information . . . . . . . . . . . . . . . . . . . 17 86 4.2.1. Service Environment . . . . . . . . . . . . . . . . . 18 87 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 19 88 4.2.3. Service Mobility Environment . . . . . . . . . . . . 20 89 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21 90 4.3. Device Information . . . . . . . . . . . . . . . . . . . 22 91 4.3.1. Device Classification . . . . . . . . . . . . . . . . 22 92 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23 93 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24 94 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24 95 4.3.5. Device/Service-Specific Additional Data Structure . . 25 96 4.3.6. Device/Service-Specific Additional Data Structure 97 Type . . . . . . . . . . . . . . . . . . . . . . . . 26 98 4.3.7. EmergencyCallData.DeviceInfo Example . . . . . . . . 26 99 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 27 100 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 27 101 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 28 102 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 28 103 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 31 105 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 31 106 5. Issues with getting new types of data into use . . . . . . . 32 107 5.1. Choosing between defining a new type of block or new type 108 of device/service-specific additional data . . . . . . . 32 109 6. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33 110 6.1. Transmitting Blocks using Call-Info . . . . . . . . . . . 35 111 6.2. Transmitting Blocks by Reference using the 112 Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 6.3. Transmitting Blocks by Value using the 114 Element . . . . . . . . . . . . . . . . . . . . . . . . . 38 115 6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39 116 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 117 8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53 118 8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 53 119 8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 55 120 8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 56 121 8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 58 122 8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 59 123 8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 60 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 125 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64 126 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 127 11.1. Registry creation . . . . . . . . . . . . . . . . . . . 67 128 11.1.1. Provider ID Series Registry . . . . . . . . . . . . 67 129 11.1.2. Service Environment Registry . . . . . . . . . . . . 68 130 11.1.3. Service Type Registry . . . . . . . . . . . . . . . 68 131 11.1.4. Service Mobility Registry . . . . . . . . . . . . . 68 132 11.1.5. Service Provider Type Registry . . . . . . . . . . . 69 133 11.1.6. Device Classification Registry . . . . . . . . . . . 69 134 11.1.7. Device ID Type Type Registry . . . . . . . . . . . . 70 135 11.1.8. Device/Service Data Type Registry . . . . . . . . . 70 136 11.1.9. Emergency Call Data Types Registry . . . . . . . . . 70 137 11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 72 138 11.3. URN Sub-Namespace Registration for 139 Registry Entry . . . . . . . . . . . . . . . . . . . . . 72 140 11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72 141 11.4.1. MIME Content-type Registration for 142 'application/EmergencyCallData.ProviderInfo+xml' . . 72 143 11.4.2. MIME Content-type Registration for 144 'application/EmergencyCallData.ServiceInfo+xml' . . 73 145 11.4.3. MIME Content-type Registration for 146 'application/EmergencyCallData.DeviceInfo+xml' . . . 75 147 11.4.4. MIME Content-type Registration for 148 'application/EmergencyCallData.SubscriberInfo+xml' . 76 149 11.4.5. MIME Content-type Registration for 150 'application/EmergencyCallData.Comment+xml' . . . . 77 151 11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 78 152 11.5.1. Registration for 153 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 78 154 11.5.2. Registration for 155 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf 156 o . . . . . . . . . . . . . . . . . . . . . . . . . 79 157 11.5.3. Registration for 158 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 79 159 11.5.4. Registration for 160 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 80 161 11.5.5. Registration for 162 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI 163 nfo . . . . . . . . . . . . . . . . . . . . . . . . 81 164 11.5.6. Registration for 165 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 82 166 11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 83 167 11.7. VCard Parameter Value Registration . . . . . . . . . . . 84 168 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 169 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 170 13.1. Normative References . . . . . . . . . . . . . . . . . . 85 171 13.2. Informational References . . . . . . . . . . . . . . . . 86 172 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 88 173 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 89 174 Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 111 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 177 1. Introduction 179 When an IP-based emergency call is initiated, a rich set of data from 180 multiple data sources is conveyed to the Public Safety Answering 181 Point (PSAP). This data includes information about the calling party 182 identity, the multimedia capabilities of the device, the request for 183 emergency services, location information, and meta-data about the 184 sources of the data. In addition, the device, the access network 185 provider, and any service provider in the call path has even more 186 information that is useful for a PSAP when handling an emergency. 188 This document extends the basic set of data communicated with a 189 Session Initiation Protocol (SIP) based emergency call, as described 190 in [RFC6443] and [RFC6881], in order to carry additional data which 191 is useful to an entity or call taker handling the call. This data is 192 "additional" to the basic information found in the emergency call 193 signaling used. The intent is that every emergency call carry as 194 much as possible of the information described here using the 195 mechanisms described here. 197 This document defines three categories of this additional data that 198 can be transmitted with an emergency call: 200 Data Associated with a Location: Primary location data is conveyed 201 in the Presence Information Data Format Location Object (PIDF-LO) 202 data structure as defined in RFC 4119 [RFC4119] and extended by 203 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 204 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 205 geodetic location information), and [RFC7035] (for relative 206 location). This primary location data identifies the location or 207 estimated location of the caller. However, there might exist 208 additional, secondary data which is specific to the location, such 209 as floor plans, tenant and building owner contact data, heating, 210 ventilation and air conditioning (HVAC) status, etc. Such 211 secondary location data is not included in the location data 212 structure but can be transmitted using the mechanisms defined in 213 this document. Although this document does not define any 214 structures for such data, future documents can do so following the 215 procedures defined here. 217 Data Associated with a Call: While some information is carried in 218 the call setup procedure itself (as part of the SIP headers as 219 well as in the body of the SIP message), there is additional data 220 known by the device making the call, the access network to which 221 the device is connected, and service providers along the path of 222 the call. This information includes service provider contact 223 information, subscriber identity and contact information, the type 224 of service the service provider and the access network provide, 225 what type of device is being used, etc. Some data is broadly 226 applicable, while other data is dependent on the type of device or 227 service. For example, a medical monitoring device might have 228 sensor data. The data structures defined in this document (Data 229 Provider Information, Device Information, and Owner/Subscriber 230 Information) all fall into the category of "Data Associated with a 231 Call". Note that the Owner/Subscriber Information includes the 232 subscriber's vCard, which might contain personal information such 233 as birthday, anniversary, etc., but the data block itself is still 234 considered to be about the call, not the caller. 236 Data Associated with a Caller: This is personal data about a caller, 237 such as medical information and emergency contact data. Although 238 this document does not define any structures within this category, 239 future documents can do so following the procedures defined here. 241 While this document defines data structures only within the category 242 of Data Associated with a Call, by establishing the overall framework 243 of Additional Data, along with general mechanisms for transport of 244 such data, extension points and procedures for future extensions, it 245 minimizes the work needed to carry data in the other categories. 246 Other specifications can make use of the facilities provided here. 248 For interoperability, there needs to be a common way for the 249 information conveyed to a PSAP to be encoded and identified. 250 Identification allows emergency services authorities to know during 251 call processing which types of data are present and to determine if 252 they wish to access it. A common encoding allows the data to be 253 successfully accessed. 255 This document defines an extensible set of data structures, and 256 mechanisms to transmit this data either by value or by reference, 257 either in the Session Initiation Protocol (SIP) call signaling or in 258 the Presence Information Data Format Location Object (PIDF-LO). The 259 data structures are usable by other communication systems and 260 transports as well. The data structures are defined in Section 4, 261 and the transport mechanisms (using SIP and HTTPS) are defined in 262 Section 6. 264 Each data structure described in this document is encoded as a 265 "block" of information. Each block is an XML structure with an 266 associated Multipurpose Internet Mail Extensions (MIME) media type 267 for identification within transport such as SIP and HTTPS. The set 268 of blocks is extensible. Registries are defined to identify the 269 block types that can be used and to allow blocks to be included in 270 emergency call signaling. 272 Much of the information supplied by service providers and devices is 273 private and confidential; service providers and devices generally go 274 to lengths to protect this information; disclosing it in the context 275 of an emergency call is a trade-off to protect the greater interest 276 of the customer in an emergency. 278 2. Terminology 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in RFC 2119 [RFC2119]. 284 This document also uses terminology from [RFC5012]. We use the term 285 service provider to refer to an Application Service Provider (ASP). 286 A Voice Service Provider (VSP) is a special type of ASP. With the 287 term "Access Network Provider" we refer to the Internet Access 288 Provider (IAP) and the Internet Service Provider (ISP) without 289 further distinguishing these two entities, since the difference 290 between the two is not relevant for this document. Note that the 291 roles of ASP and access network provider might be provided by a 292 single company. An Emergency Services Provider is an entity directly 293 involved in providing emergency services. This includes PSAPs, 294 dispatch, police, fire, emergency medical, other responders, and 295 other similar agencies. 297 Within each data block definition (see Section 4), the values for the 298 "Use:" label are specified as one of the following: 300 'Required': means it MUST be present in the data structure. 302 'Conditional': means it MUST be present if the specified 303 condition(s) is met. It MAY be present if the condition(s) is not 304 met. 306 'Optional': means it MAY be present. 308 vCard [RFC6350] is a data format for representing and exchanging a 309 variety of information about individuals and other entities. For 310 applications that use XML, the format defined in vCard is not 311 immediately applicable. For this reason, an XML-based encoding of 312 the information elements defined in the vCard specification has been 313 defined and the name of that specification is xCard [RFC6351]. Since 314 the term vCard is more familiar to most readers, we use the terms 315 xCard and vCard interchangeably. 317 3. Document Scope 319 The scope of this document is explicitly limited to emergency calls. 320 The data structures defined here are not appropriate to be conveyed 321 in non-emergency calls because they carry sensitive and private data. 322 However, in certain private-use situations between a specialized 323 service provider (such as a vehicle telematics service provider) and 324 dedicated equipment (such as in a vehicle) where the endpoints have a 325 preexisting relationship and privacy issues are addressed within the 326 relationship, the mechanisms and data structures defined here can be 327 used with communications within the limited context of the 328 preexisting relationship. 330 4. Data Structures 332 This section defines the following five data structures, each as a 333 data block. For each block we define the MIME media type, and the 334 XML encoding. The five data structures are: 336 'Data Provider': This block supplies name and contact information 337 for the entity that created the data. Section 4.1 provides the 338 details. 340 'Service Information': This block supplies information about the 341 service. The description can be found in Section 4.2. 343 'Device Information': This block supplies information about the 344 device placing the call. Device information can be found in 345 Section 4.3. 347 'Owner/Subscriber': This block supplies information about the owner 348 of the device or about the subscriber. Details can be found in 349 Section 4.4. 351 'Comment': This block provides a way to supply free form human 352 readable text to the PSAP or emergency responders. This simple 353 structure is defined in Section 4.5. 355 Each block contains a mandatory element. The 356 purpose of the element is to associate all 357 blocks added by the same data provider as a unit. The 358 element associates the data provider block to 359 each of the other blocks added as a unit. Consequently, when a data 360 provider adds additional data to an emergency call (such as device 361 information) it MUST add information about itself (via the data 362 provider block) and the blocks added contain the same value in the 363 element. All blocks added by a single entity 364 at the same time MUST have the same value. 365 (In certain situations, the same provider might process a call more 366 than once, likely in different roles, and in such cases, each time it 367 processes the call, it adds a new set of bocks with a new 368 value.) The value of the 369 element has the same syntax and properties 370 (specifically, world-uniqueness) as the value of the "Message-ID" 371 message body header field specified in RFC 5322 [RFC5322] except that 372 the element is not enclosed in brackets (the 373 "<" and ">" symbols are omitted). In other words, the value of a 374 element is syntactically a msg-id as 375 specified in RFC 5322 [RFC5322]. 377 Each block is added to the Additional Data Blocks Registry created in 378 Section 11.1.9 and categorized as providing data about the caller. 379 New blocks added to the registry in the future MUST also be 380 categorized per the description of the three categories in Section 1. 381 See Section 5 and Section 5.1 for additional considerations when 382 adding new blocks or types of data. 384 Note that the xCard format is re-used in some of the data structures 385 to provide contact information. In an xCard there is no way to 386 specify a "main" telephone number (that is, a primary or main contact 387 number, typically of an enterprise, as opposed to a direct dial 388 number of an individual). These numbers are useful to emergency 389 responders who are called to a large enterprise. This document adds 390 a new parameter value called "main-number" to the "TYPE" parameter of 391 the "tel" property. It can be used in any xCard in an emergency call 392 additional data block. 394 4.1. Data Provider Information 396 This block is intended to be supplied by any service provider in the 397 path of the call, or the access network provider, and the device. It 398 includes identification and contact information. This block MUST be 399 supplied by any entity that provides any other block; it SHOULD be 400 supplied by every service provider in the call path and by the access 401 network provider if those entities do not add any other blocks. 402 Devices SHOULD use this block to provide identifying information. 403 The MIME media type is "application/ 404 EmergencyCallData.ProviderInfo+xml". An access network provider 405 SHOULD provide this block either by value or by reference in the 406 element of a PIDF-LO 408 4.1.1. Data Provider String 410 Data Element: Data Provider String 412 Use: Conditional. Optional for blocks supplied by the originating 413 device, mandatory otherwise. 415 XML Element: 417 Description: This is a plain text string suitable for displaying the 418 name of the service provider that supplied the data structure. If 419 the device creates the structure, it SHOULD use the value of the 420 contact header field in the SIP INVITE. 422 Reason for Need: Inform the call taker of the identity of the entity 423 providing the data. 425 How Used by Call Taker: Allows the call taker to interpret the data 426 in this structure. The source of the information often influences 427 how the information is used, believed or verified. 429 4.1.2. Data Provider ID 431 Data Element: Data Provider ID 433 Use: Conditional. Optional for blocks supplied by the originating 434 device, mandatory otherwise. This data MUST be provided by all 435 entities other than the originating device in order to uniquely 436 identify the service provider or access provider. 438 XML Element: 440 Description: A jurisdiction-specific code for, or the fully- 441 qualified domain name of, the access network provider or service 442 provider shown in the element that created the 443 structure. NOTE: The value SHOULD be assigned by an organization 444 appropriate for the jurisdiction. In the U.S., if the provider is 445 registered with NENA, the provider's NENA Company ID MUST appear 446 here. Additional information can be found at NENA Company 447 Identifier Program [1] or NENA Company ID [2]. The NENA Company 448 ID MUST be in the form of a URI in the following format: 449 urn:nena:companyid:. If the organization does 450 not have an identifier registered with a jurisdiction-specific 451 emergency services registrar (such as NENA), then the value MAY be 452 the fully-qualified domain name of the service provider or access 453 provider. The device MAY use its IP address or fully-qualified 454 domain name (and set the "Data Provider ID Series" element to 455 "domain"). 457 Reason for Need: Inform the call taker of the identity of the entity 458 providing the data. 460 How Used by Call Taker: Where jurisdictions have lists of providers 461 the Data Provider ID provides useful information about the data 462 source. The Data Provider ID uniquely identifies the source of 463 the data, which might be needed especially during unusual 464 circumstances and for routine logging. 466 4.1.3. Data Provider ID Series 468 Data Element: Data Provider ID Series 470 Use: Conditional. Optional for blocks supplied by the originating 471 device, mandatory otherwise. 473 XML Element: 474 Description: Identifies the issuer of the . The 475 Provider ID Series Registry created in Section 11.1.1 initially 476 contains the entries shown in Figure 1. 478 Reason for Need: Identifies how to interpret the Data Provider ID. 479 The combination of ProviderIDSeries and ProviderID MUST be 480 globally unique. 482 How Used by Call Taker: Determines which provider ID registry to 483 consult for more information 485 +-----------+--------------------------+----------------------+ 486 | Name | Source | URL | 487 +-----------+--------------------------+----------------------+ 488 | NENA | National Emergency | http://www.nena.org | 489 | | Number Association | | 490 | EENA | European Emergency | http://www.eena.org | 491 | | Number Association | | 492 | domain | (The ID is a fully- | (not applicable) | 493 | | qualified domain name) | | 494 +-----------+--------------------------+----------------------+ 496 Figure 1: Provider ID Series Registry 498 4.1.4. Type of Data Provider 500 Data Element: Type of Data Provider 502 Use: Required. 504 XML Element: 506 Description: Identifies the type of data provider supplying the 507 data. The registry containing all valid values is created in 508 Section 11.1.5 and the initial set of values is shown in Figure 2. 510 Reason for Need: Identifies the category of data provider. 512 How Used by Call Taker: This information can be helpful when 513 deciding whom to contact when further information is needed. 515 +------------------------------+------------------------------------+ 516 | Token | Description | 517 +------------------------------+------------------------------------+ 518 |Client | Originating client/device | 519 |Access Network Provider | Access network service provider | 520 |Telecom Provider | Telecom service provider (including| 521 | | native and over-the-top VoIP | 522 | | services) | 523 |Telematics Provider | A sensor-based service provider, | 524 | | especially vehicle-based | 525 |Language Translation Provider | A spoken language translation | 526 | | service | 527 |Emergency Service Provider | An emergency service provider | 528 | | conveying information to another| 529 | | emergency service provider. | 530 |Emergency Modality Translation| An emergency-call-specific | 531 | | modality translation service | 532 | | e.g., for sign language | 533 |Relay Provider | A interpretation service, e.g., | 534 | | video relay for sign language | 535 | | interpreting | 536 |Other | Any other type of service provider | 537 +------------------------------+------------------------------------+ 539 Figure 2: Type of Data Provider Registry 541 4.1.5. Data Provider Contact URI 543 Data Element: Data Provider Contact URI 545 Use: Required 547 XML Element: 549 Description: When provided by a service provider or an access 550 network provider, this information is expected to be a URI to a 551 24/7 support organization tasked to provide PSAP support for this 552 emergency call. When provided by a device, this MUST be the 553 contact information of the user or owner of the device. (Ideally, 554 this is the contact information of the device user, but when the 555 owner and user are separate (e.g., the device owner is an 556 organization), this MAY be the contact information of the owner.) 557 The Data Provider Contact URI SHOULD be a TEL URI [RFC3966] in 558 E.164 format fully specified with country code. If a TEL URI is 559 not available, a generic SIP URI is acceptable. Note that this 560 contact information is not used by PSAPs for callbacks (a call 561 from a PSAP directly related to a recently terminated emergency 562 call, placed by the PSAP using a SIP Priority header field set to 563 "psap-callback", as described in [RFC7090]). 565 Reason for Need: Additional data providers might need to be 566 contacted in error cases or other unusual circumstances. 568 How Used by Call Taker: To contact the supplier of the additional 569 data for assistance in handling the call. 571 4.1.6. Data Provider Languages(s) Supported 573 Data Element: Data Provider Language(s) supported 575 Use: Required. 577 XML Element: 579 Description: This field encodes the language used by the entity at 580 the Data Provider Contact URI. The content of this field consists 581 of a single token from the language tags registry, which can be 582 found at [LanguageTagRegistry], and is defined in [RFC5646]. 583 Multiple instances of this element MAY occur but the order is 584 significant and the preferred language SHOULD appear first. The 585 content MUST reflect the languages supported at the contact URI. 587 (Note that this field informs the PSAP of the language(s) used by 588 the data provider. If the PSAP needs to contact the data 589 provider, it can be helpful to know in advance the language(s) 590 used by the data provider. If the PSAP uses a communication 591 protocol to reach the data provider, that protocol might have 592 language facilities of its own (such as the 'language' media 593 feature tag, defined in RFC 3840 [RFC3840] and the more extensive 594 language negotiation mechanism proposed with 595 [I-D.gellens-slim-negotiating-human-language]), and if so, those 596 are independent of this field.) 598 Reason for Need: This information indicates if the emergency service 599 authority can directly communicate with the service provider or if 600 an interpreter will be needed. 602 How Used by Call Taker: If the call taker cannot speak any language 603 supported by the service provider, a translation service will need 604 to be added to the conversation. Alternatively, other persons at 605 the PSAP, besides the call taker, might be consulted for help 606 (depending on the urgency and the type of interaction). 608 4.1.7. xCard of Data Provider 610 Data Element: xCard of Data Provider 612 Use: Optional 614 XML Element: 616 Description: Per [RFC6351] the xCard structure is represented within 617 a element. Although multiple elements can be 618 contained in a structure only one element SHOULD be 619 provided. If more than one appears, the first SHOULD be used. 620 There are many fields in the xCard and the creator of the data 621 structure is encouraged to provide all available information. N, 622 ORG, ADR, TEL, EMAIL are suggested at a minimum. N SHOULD contain 623 the name of the support group or device owner as appropriate. If 624 more than one TEL property is provided, a parameter from the vCard 625 Property Value registry SHOULD be specified for each TEL. For 626 encoding of the vCard this specification uses the XML-based 627 encoding specified in [RFC6351], referred to in this document as 628 "xCard". 630 Reason for Need: Information needed to determine additional contact 631 information. 633 How Used by Call Taker: Assists the call taker by providing 634 additional contact information aside from what is included in the 635 SIP INVITE or the PIDF-LO. 637 4.1.8. Subcontractor Principal 639 When the entity providing the data is a subcontractor, the Data 640 Provider Type is set to that of the primary service provider and this 641 entry is supplied to provide information regarding the subcontracting 642 entity. 644 Data Element: Subcontractor Principal 646 Use: Conditional. This data is required if the entity providing the 647 data is a subcontractor. 649 XML Element: 651 Description: Some providers outsource their obligations to handle 652 aspects of emergency services to specialized providers. If the 653 data provider is a subcontractor to another provider this element 654 contains the DataProviderString of the service provider to 655 indicate which provider the subcontractor is working for. 657 Reason for Need: Identify the entity the subcontractor works for. 659 How Used by Call Taker: Allows the call taker to understand what the 660 relationship between data providers and the service providers in 661 the path of the call are. 663 4.1.9. Subcontractor Priority 665 Data Element: Subcontractor Priority 667 Use: Conditional. This data is required if the entity providing the 668 data is a subcontractor. 670 XML Element: 672 Description: If the subcontractor is supposed to be contacted first 673 then this element MUST have the value "sub". If the provider the 674 subcontractor is working for is supposed to be contacted first 675 then this element MUST have the value "main". 677 Reason for Need: Inform the call taker whom to contact first, if 678 support is needed. 680 How Used by Call Taker: To decide which entity to contact first if 681 assistance is needed. 683 4.1.10. ProviderInfo Example 685 686 688 string0987654321@example.org 689 690 Example VoIP Provider 691 692 urn:nena:companyid:ID123 693 NENA 694 Telecom Provider 695 tel:+1-201-555-0123 696 en 697 699 700 Hannes Tschofenig 701 702 Hannes 703 Tschofenig 704 705 706 Dipl. Ing. 707 708 --0203 709 710 20090808T1430-0500 711 712 M 713 714 1 715 716 de 717 718 719 2 720 721 en 722 723 724 work 725 726 Example VoIP Provider 727 728 729 730 work 731 735 736 737 738 Linnoitustie 6 739 Espoo 740 Uusimaa 741 02600 742 Finland 743 744 745 746 747 work 748 voice 749 750 751 tel:+358 50 4871445 753 754 755 756 757 work 758 main-number 759 voice 760 761 762 tel:+358 50 5050505 763 764 765 work 766 767 hannes.tschofenig@nsn.com 768 769 770 work 771 772 geo:60.210796,24.812924 773 774 775 home 776 777 778 http://www.tschofenig.priv.at/key.asc 779 780 781 Finland/Helsinki 782 783 home 784 785 http://www.tschofenig.priv.at 786 787 788 789 791 Figure 3: EmergencyCallData.ProviderInfo Example. 793 4.2. Service Information 795 This block describes the service that the service provider provides 796 to the caller. It SHOULD be included by all service providers in the 797 path of the call. The MIME media type is "application/ 798 EmergencyCallData.ServiceInfo+xml". 800 4.2.1. Service Environment 802 Data Element: Service Environment 804 Use: Conditional: Required unless the 'ServiceType' value is 805 'wireless'. 807 XML Element: 809 Description: This element indicates whether a call is from a 810 business or residence. Currently, the only valid entries are 811 'Business', 'Residence', and 'unknown', as shown in Figure 4. New 812 values can be defined via the registry created in Section 11.1.2. 814 Reason for Need: To provide context and a hint when determining 815 equipment and manpower requirements. 817 How Used by Call Taker: Information can be used to provide context 818 and a hint to assist in determining equipment and manpower 819 requirements for emergency responders. This is non-authoritative: 820 There are situations where the service provider does not know the 821 type of service (e.g., anonymous pre-paid service). The type of 822 service does not necessarily reflect the nature of the premises 823 (e.g., a business line installed in a residence, or cellular 824 service). The registry does not contain all possible values for 825 all situations. Hence, this is at best advisory information, but 826 since it mimics a similar capability in some current emergency 827 calling systems (e.g., a field in the Automatic Location 828 Information (ALI) information used with legacy North American 829 wireline systems), it is known to be valuable to PSAPs. The 830 service provider uses its best information (such as a rate plan, 831 facilities used to deliver service or service description) to 832 determine the information and is not responsible for determining 833 the actual characteristics of the location from which the call 834 originated. Because the usefulness is unknown (and less clear) 835 for cellular, this element is OPTIONAL for commercial mobile radio 836 services (e.g., cellular) and REQUIRED otherwise. 838 +-----------+--------------------------+ 839 | Token | Description | 840 +-----------+--------------------------+ 841 | Business | Business service | 842 | Residence | Residential service | 843 | unknown | Type of service unknown | 844 | | (e.g., anonymous pre- | 845 | | paid service) | 846 +-----------+--------------------------+ 848 Figure 4: Service Environment Registry 850 4.2.2. Service Type 852 Data Element: Service Delivered by Provider to End User 854 Use: Required 856 XML Element: 858 Description: This defines the type of service over which the call is 859 placed (similar to the Class of Service delivered with legacy 860 emergency calls in some some regions). The implied mobility of 861 this service cannot be relied upon. A registry is created in 862 Section 11.1.3. The initial set of values is shown in Figure 5. 863 More than one value MAY be returned. For example, a VoIP inmate 864 telephone service is a reasonable combination. 866 Reason for Need: Knowing the type of service can assist the PSAP in 867 handling of the call. 869 How Used by Call Taker: Call takers often use this information to 870 determine what kinds of questions to ask callers, and how much to 871 rely on supportive information. As the information is not always 872 available, and the registry is not all-encompassing, this is at 873 best advisory information, but since it mimics a similar 874 capability in some legacy emergency calling systems, it is known 875 to be valuable. 877 +--------------+----------------------------------------+ 878 | Name | Description | 879 +--------------+----------------------------------------+ 880 | wireless | Wireless Telephone Service: Includes | 881 | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but | 882 | | not satellite) | 883 | coin | Fixed public pay/coin telephones: Any | 884 | | coin or credit card operated device | 885 | one-way | One way outbound service | 886 | temp | Soft dial tone/quick service/warm | 887 | | disconnect/suspended | 888 | MLTS-hosted | Hosted multi-line telephone system | 889 | | such as Centrex | 890 | MLTS-local | Local multi-line telephone system, | 891 | | includes all PBX, key systems, | 892 | | Shared Tenant Service | 893 | sensor- | These are devices that generate DATA | 894 | unattended | ONLY. This is a one-way information | 895 | | transmit without interactive media | 896 | sensor- | Devices that are supported by a | 897 | attended | monitoring service provider or that | 898 | | are capable of supporting interactive| 899 | | media | 900 | POTS | Wireline: Plain Old Telephone Service | 901 | OTT | An over-the-top service that provides | 902 | | communication over arbitrary Internet| 903 | | access (fixed, nomadic, mobile) | 904 | digital | Wireline non-OTT digital phone service | 905 | OPX | Off-premise extension | 906 | relay | A service where a human third-party | 907 | | agent provides additional assistance | 908 | | This includes sign language relay/ | 909 | | interpretation, telematics services | 910 | | that provide a human on the call, | 911 | | and similar services | 912 +--------------+----------------------------------------+ 914 Figure 5: Service Delivered by Provider to End User Registry 916 The initial set of values has been collected from sources of 917 currently-used systems, including [NENA-02-010], [nc911], [NANP], and 918 [LERG]. 920 4.2.3. Service Mobility Environment 922 Data Element: Service Mobility Environment 924 Use: Required 925 XML Element: 927 Description: This provides the service provider's view of the 928 mobility of the caller's device. As the service provider might 929 not know the characteristics of the actual device or access 930 network used, the value should be treated as advisory and not be 931 relied upon. A registry is created in Section 11.1.4 with the 932 initial valid entries shown in Figure 6. 934 Reason for Need: Knowing the service provider's belief of mobility 935 can assist the PSAP with the handling of the call. 937 How Used by Call Taker: To determine whether to assume the location 938 of the caller might change. 940 +-----------+----------------------------+ 941 | Token | Description | 942 +-----------+----------------------------+ 943 | Mobile | The device is able to move | 944 | | at any time | 945 | Fixed | The device is not expected | 946 | | to move unless the | 947 | | service is relocated | 948 | Nomadic | The device is not expected | 949 | | to change its point of | 950 | | attachment while on a | 951 | | call | 952 | Unknown | No information is known | 953 | | about the service | 954 | | mobility environment for | 955 | | the device | 956 +-----------+----------------------------+ 958 Figure 6: Service Environment Registry 960 4.2.4. EmergencyCallData.ServiceInfo Example 961 962 964 2468.IBOC.MLTS.1359@example.org 965 966 Business 967 MLTS-hosted 968 Fixed 969 971 Figure 7: EmergencyCallData.ServiceInfo Example. 973 4.3. Device Information 975 This block provides information about the device used to place the 976 call. It SHOULD be provided by any service provider that knows what 977 device is being used, and by the device itself. The MIME media type 978 is "application/EmergencyCallData.DeviceInfo+xml". 980 4.3.1. Device Classification 982 Data Element: Device Classification 984 Use: Optional 986 XML Element: 988 Description: This data element defines the kind of device making the 989 emergency call. If the device provides the data structure, the 990 device information SHOULD be provided. If the service provider 991 provides the structure and it knows what the device is, the 992 service provider SHOULD provide the device information. Often the 993 carrier does not know what the device is. It is possible to 994 receive two Device Information blocks, one provided by the device 995 and one from the service provider. This information describes the 996 device, not how it is being used. This data element defines the 997 kind of device making the emergency call. A registry is created 998 in Section 11.1.6 with the initial set of values as shown in 999 Figure 8. 1001 Reason for Need: The device classification implies the capability of 1002 the calling device and assists in identifying the meaning of the 1003 emergency call location information that is being presented. For 1004 example, does the device require human intervention to initiate a 1005 call or is this call the result of programmed instructions? Does 1006 the calling device have the ability to update location or 1007 condition changes? Is this device interactive or a one-way 1008 reporting device? 1010 How Used by Call Taker: Can provide the call taker context regarding 1011 the caller, the capabilities of the calling device or the 1012 environment in which the device is being used, and can assist in 1013 understanding the location information and capabilities of the 1014 calling device. For example, a cordless handset might be outside 1015 or next door. 1017 +---------------+----------------------------------------+ 1018 | Token | Description | 1019 +---------------+----------------------------------------+ 1020 |cordless | Cordless handset | 1021 |fixed | Fixed phone | 1022 |satellite | Satellite phone | 1023 |sensor-fixed | Fixed (non mobile) sensor/alarm device | 1024 |desktop | Soft client on desktop PC | 1025 |laptop | Soft client on laptop type device | 1026 |tablet | Soft client on tablet type device | 1027 |alarm-monitored| Alarm system | 1028 |sensor-mobile | Mobile sensor device | 1029 |aircraft | Aircraft telematics device | 1030 |automobile | Automobile/cycle/off-road telematics | 1031 |truck | Truck/construction telematics | 1032 |farm | Farm equipment telematics | 1033 |marine | Marine telematics | 1034 |personal | Personal telematics device | 1035 |feature-phone | Feature- (not smart-) cellular phone | 1036 |smart-phone | Smart-phone cellular phone (native) | 1037 |smart-phone-app| Soft client app on smart-phone | 1038 |unknown-device | Soft client on unknown device type | 1039 |game | Gaming console | 1040 |text-only | Other text device | 1041 |NA | Not Available | 1042 +---------------+----------------------------------------+ 1044 Figure 8: Device Classification Registry Initial Values 1046 4.3.2. Device Manufacturer 1048 Data Element: Device Manufacturer 1050 Use: Optional 1052 XML Element: 1054 Description: The plain language name of the manufacturer of the 1055 device. 1057 Reason for Need: Used by PSAP management for post-mortem 1058 investigation/resolution. 1060 How Used by Call Taker: Probably not used by the calltaker, but by 1061 PSAP management. 1063 4.3.3. Device Model Number 1065 Data Element: Device Model Number 1067 Use: Optional 1069 XML Element: 1071 Description: Model number of the device. 1073 Reason for Need: Used by PSAP management for after-action 1074 investigation/resolution. 1076 How Used by Call Taker: Probably not used by the calltaker, but by 1077 PSAP management. 1079 4.3.4. Unique Device Identifier 1081 Data Element: Unique Device Identifier 1083 Use: Optional 1085 XML Element: 1087 XML Attribute: 1089 Description: A string that identifies the specific device (or the 1090 device's current SIM) making the call or creating an event. Note 1091 that more than one can be present, to supply more 1092 than one of the identifying values. 1094 The attribute identifies the type of device 1095 identifier. A registry is created in Section 11.1.7 with an 1096 initial set of values shown in Figure 9. 1098 Reason for Need: Uniquely identifies the device (or, in the case of 1099 IMSI, a SIM), independent of any signaling identifiers present in 1100 the call signaling stream. 1102 How Used by Call Taker: Probably not used by the call taker; might 1103 be used by PSAP management during an investigation. (For example, 1104 if a PSAP experiences repeated false/accidental calls and there is 1105 no callback number or it isn't usable, the PSAP might need to try 1106 and track down the device using various means (e.g., contacting 1107 service providers in the area). In the case of handsets without 1108 current service, it might be possible to determine who last had 1109 service. Another example might be a disconnected call where the 1110 call taker believes there is a need for assistance but was not 1111 able to obtain a location or other information). 1113 Example: 12345 1115 +--------+------------------------------------------+ 1116 | Token | Description | 1117 +--------+------------------------------------------+ 1118 | MEID | Mobile Equipment Identifier (CDMA) | 1119 | ESN | Electronic Serial Number (GSM) | 1120 | MAC | Media Access Control Address (IEEE) | 1121 | WiMAX | Device Certificate Unique ID | 1122 | IMEI | International Mobile Equipment ID (GSM) | 1123 | IMSI | International Mobile Subscriber ID (GSM) | 1124 | UDI | Unique Device Identifier | 1125 | RFID | Radio Frequency Identification | 1126 | SN | Manufacturer Serial Number | 1127 +--------+------------------------------------------+ 1129 Figure 9: Registry of Device Identifier Types 1131 4.3.5. Device/Service-Specific Additional Data Structure 1133 Data Element: Device/service-specific additional data structure 1135 Use: Optional 1137 XML Element: 1139 Description: A URI representing additional data whose schema is 1140 specific to the device or service which created it. (For example, 1141 a medical device or medical device monitoring service might have a 1142 defined set of medical data). The URI, when dereferenced, MUST 1143 yield a data structure defined by the Device/service-specific 1144 additional data type value. Different data can be created by each 1145 classification; e.g., a medical device created data set. 1147 Reason for Need: Provides device/service-specific data that can be 1148 used by the call taker and/or responders. 1150 How Used by Call Taker: Provide information to guide call takers to 1151 select appropriate responders, give appropriate pre-arrival 1152 instructions to callers, and advise responders of what to be 1153 prepared for. May be used by responders to guide assistance 1154 provided. 1156 4.3.6. Device/Service-Specific Additional Data Structure Type 1158 Data Element: Type of device/service-specific additional data 1159 structure 1161 Use: Conditional: MUST be provided when a device/service-specific- 1162 additional URI is provided 1164 XML Element: 1166 Description: A value from the registry defined in Section 11.1.8 to 1167 describe the type of data located at the device/service-specific 1168 additional data structure. The initial values shown in Figure 10 1169 currently only include IEEE 1512, which is the USDoT model for 1170 traffic incidents. 1172 Reason for Need: This data element allows identification of 1173 externally defined schemas, which might have additional data that 1174 can assist in emergency response. 1176 How Used by Call Taker: This data element allows the end user (call 1177 taker or first responder) to know what type of additional data is 1178 available to aid in providing the needed emergency services. 1180 Note: This mechanism is not appropriate for information specific to 1181 a location or a caller (person). 1183 +----------+----------------------------+--------------------------------+ 1184 | Token | Description | Specification | 1185 +----------+----------------------------+--------------------------------+ 1186 | IEEE1512 | Common Incident Management |IEEE 1512-2006 | 1187 | | Message Set (USDoT model |https://standards.ieee.org/ | 1188 | | for traffic incidents) |findstds/standard/1512-2006.html| 1189 +----------+----------------------------+--------------------------------+ 1191 Figure 10: Device/Service Data Type Registry 1193 4.3.7. EmergencyCallData.DeviceInfo Example 1194 1195 1197 d4b3072df.201409182208075@example.org 1198 1199 fixed 1200 Nokia 1201 Lumia 800 1202 35788104 1203 1204 1206 Figure 11: EmergencyCallData.DeviceInfo Example. 1208 4.4. Owner/Subscriber Information 1210 This block describes the owner of the device (if provided by the 1211 device) or the subscriber information (if provided by a service 1212 provider). The contact location is not necessarily the location of 1213 the caller or incident, but is rather the nominal contact address. 1214 The MIME media type is "application/ 1215 EmergencyCallData.SubscriberInfo+xml". 1217 In some jurisdictions some or all parts of the subscriber-specific 1218 information are subject to privacy constraints. These constraints 1219 vary but dictate which information can be displayed and logged. A 1220 general privacy indicator expressing a desire for privacy by the 1221 subscriber is provided. The interpretation of how this is applied is 1222 left to the receiving jurisdiction as the custodians of the local 1223 regulatory requirements. This matches an equivalent privacy flag 1224 provided in some legacy emergency call systems. 1226 4.4.1. Subscriber Data Privacy Indicator 1228 Attribute: 'privacyRequested', Boolean. 1230 Use: Conditional. This attribute MUST be provided if the owner/ 1231 subscriber information block is not empty. 1233 Description: The subscriber data privacy indicator specifically 1234 expresses the subscriber's desire for privacy. In some 1235 jurisdictions subscriber services can have a specific "Type of 1236 Service" which prohibits information, such as the name of the 1237 subscriber, from being displayed. This attribute is provided to 1238 explicitly indicate whether the subscriber service includes such 1239 constraints. The interpretation of this indicator is left to each 1240 jurisdiction (in keeping with the semantics of the privacy 1241 indicator provided in some legacy emergency call systems). 1243 Because the interpretation of this indicator varies based on local 1244 regulations, this document cannot describe the exact semantics nor 1245 indicate which fields are affected (the application of this 1246 indicator might affect the display of data contained in any of the 1247 blocks). 1249 Reason for Need: Some jurisdictions require subscriber privacy to be 1250 observed when processing emergency calls. 1252 How Used by Call Taker: Where privacy is indicated the call taker 1253 might not have access to some aspects of the subscriber 1254 information. 1256 4.4.2. xCard for Subscriber's Data 1258 Data Element: xCARD for Subscriber's Data 1260 Use: Conditional. Subscriber data MUST be provided unless it is not 1261 available. Some services, such as prepaid phones, non-initialized 1262 phones, etc., do not have information about the subscriber. 1264 XML Element: 1266 Description: Information known by the service provider or device 1267 about the subscriber; e.g., Name, Address, Individual Telephone 1268 Number, Main Telephone Number and any other data. , (if 1269 appropriate), , , are suggested at a minimum. 1270 If more than one property is provided, a parameter from the 1271 vCard Property Value registry MUST be specified on each . 1272 While some data (such as ) might not seem obviously 1273 relevant for emergency services, any data is potentially useful in 1274 some emergency circumstances. 1276 Reason for Need: When the caller is unable to provide information, 1277 this data can be used to obtain it 1279 How Used by Call Taker: Obtaining critical information about the 1280 caller and possibly the location when it is not able to be 1281 obtained otherwise. While the location here is not necessarily 1282 that of caller, in some circumstances it can be helpful in 1283 locating the caller when other means have failed. 1285 4.4.3. EmergencyCallData.SubscriberInfo Example 1287 1288 1292 FEABFECD901@example.org 1293 1294 1295 1296 Simon Perreault 1297 1298 Perreault 1299 Simon 1300 1301 1302 ing. jr 1303 M.Sc. 1304 1305 --0203 1306 1307 20090808T1430-0500 1308 1309 M 1310 1311 1 1312 1313 fr 1314 1315 1316 2 1317 1318 en 1319 1320 1321 work 1322 1323 Viagenie 1324 1325 1326 1327 work 1328 1332 1333 1334 1335 2875 boul. Laurier, suite D2-630 1336 Quebec 1337 QC 1338 G1V 2M2 1339 Canada 1340 1341 1342 1343 1344 work 1345 voice 1346 1347 1348 tel:+1-418-656-9254;ext=102 1349 1350 1351 1352 1353 work 1354 voice 1355 main-number 1356 1357 1358 tel:+1-418-555-0000 1359 1360 1361 1362 1363 work 1364 text 1365 voice 1366 cell 1367 video 1368 1369 1370 tel:+1-418-262-6501 1371 1372 1373 work 1374 1375 simon.perreault@viagenie.ca 1376 1377 1378 work 1379 1380 geo:46.766336,-71.28955 1381 1382 1383 work 1384 1385 1386 http://www.viagenie.ca/simon.perreault/simon.asc 1387 1388 1389 America/Montreal 1390 1391 home 1392 1393 http://nomis80.org 1394 1395 1396 1397 1399 Figure 12: EmergencyCallData.SubscriberInfo Example. 1401 4.5. Comment 1403 This block provides a mechanism for the data provider to supply 1404 extra, human readable information to the PSAP. It is not intended 1405 for a general purpose extension mechanism nor does it aim to provide 1406 machine-readable content. The MIME media type is "application/ 1407 EmergencyCallData.Comment+xml" 1409 4.5.1. Comment 1411 Data Element: EmergencyCallData.Comment 1413 Use: Optional 1415 XML Element: 1417 Description: Human readable text providing additional information to 1418 the PSAP staff. 1420 Reason for Need: Explanatory information for values in the data 1421 structure. 1423 How Used by Call Taker: To interpret the data provided. 1425 4.5.2. EmergencyCallData.Comment Example 1426 1427 1429 string0987654321@example.org 1430 1431 This is an example text. 1432 1434 Figure 13: EmergencyCallData.Comment Example. 1436 5. Issues with getting new types of data into use 1438 This document describes two mechanisms that allow extension of the 1439 kind of data provided with an emergency call: define a new block or 1440 define a new service specific additional data URL for the DeviceInfo 1441 block (Section 4.3.5). While defining new data types and getting a 1442 new device or application to send the new data might be easy, getting 1443 PSAPs and responders to actually retrieve the data and use it will be 1444 difficult. New mechanism providers should understand that acquiring 1445 and using new forms of data usually require software upgrades at the 1446 PSAP and/or responders, as well as training of call takers and 1447 responders in how to interpret and use the information. Legal and 1448 operational review might also be needed. Overwhelming a call taker 1449 or responder with too much information is highly discouraged. Thus, 1450 the barrier to supporting new data is quite high. 1452 The mechanisms this document describes are meant to encourage 1453 development of widely supported, common data formats for classes of 1454 devices. If all manufacturers of a class of device use the same 1455 format, and the data can be shown to improve outcomes, then PSAPs and 1456 responders can be encouraged to upgrade their systems and train their 1457 staff to use the data. Variations, however well intentioned, are 1458 unlikely to be supported. 1460 Implementers should consider that data from sensor-based devices in 1461 some cases might not be useful to call takers or PSAPs (and privacy, 1462 liability, or other considerations might preclude the PSAP from 1463 accessing or handling the data), but might be of use to responders. 1464 Each data item provided with the call in conformance with this 1465 document can be accessed by responders or other entities in the 1466 emergency services, whether or not the data is accessed by the PSAP. 1468 5.1. Choosing between defining a new type of block or new type of 1469 device/service-specific additional data 1471 For devices that have device or service specific data, there are two 1472 choices to carry it. A new block can be defined, or the device/ 1473 service-specific additional data URL in the DeviceInfo block can be 1474 used and a new type for it defined. The data passed would likely be 1475 the same in either case. Considerations for choosing the mechanism 1476 under which to register include: 1478 Applicability: Information which will be supported by many kinds of 1479 devices or services are more appropriately defined as separate 1480 blocks. 1482 Privacy: Information sent as a device/service-specific additional 1483 data URL in the DeviceInfo block is by reference (not by value), 1484 which inherently provides some additional privacy protection 1485 (since the requester needs to supply a certificate which is 1486 verified by the supplier). 1488 Size: Information which can be very large might be better sent in 1489 the DeviceInfo block, rather than a new block, so that 1490 implementations are unable to send the data by value. Conversely, 1491 data which is small might best be sent in a separate block so that 1492 it can be sent by value. 1494 Availability of a server: Providing the data via the device block 1495 requires a server be available from which to retrieve the data. 1496 Providing the data via new block allows it to be sent by value. 1498 6. Data Transport Mechanisms 1500 This section defines how to convey additional data to an emergency 1501 service provider. Two different means are specified: the first uses 1502 the call signaling; the second uses the element of a 1503 PIDF-LO [RFC4119]. 1505 1. First, the ability to embed a Uniform Resource Identifier (URI) 1506 in an existing SIP header field, the Call-Info header field, is 1507 defined. The URI points to the additional data structure. The 1508 Call-Info header field is specified in Section 20.9 of [RFC3261]. 1510 This document adds a new compound token starting with the value 1511 'EmergencyCallData' for the Call-Info "purpose" parameter. If 1512 the "purpose" parameter is set to a value starting with 1513 'EmergencyCallData', then the Call-Info header field contains 1514 either an HTTPS URL pointing to an external resource or a CID 1515 (content indirection) URI that allows the data structure to be 1516 placed in the body of the SIP message. The "purpose" parameter 1517 also indicates the kind of data (by its MIME media subtype) that 1518 is available at the URI. 1520 As the data is conveyed using a URI in the SIP signaling, the 1521 data itself can reside on an external resource, or can be 1522 contained within the body of the SIP message. When the URI 1523 refers to data at an external resource, the data is said to be 1524 passed by reference. When the URI refers to data contained 1525 within the body of the SIP message, the data is said to be passed 1526 by value. A PSAP or emergency responder is able to examine the 1527 type of data provided and selectively access the data it is 1528 interested in, while forwarding all of it (the values or 1529 references) to downstream entities. 1531 To be conveyed in a SIP body, additional data about a call is 1532 defined as a series of MIME objects (also referred to as a 1533 "block" of data). Each block defined in this document is an XML 1534 data structure identified by its MIME media type. (Blocks 1535 defined by others can be encoded in XML or not, as identified by 1536 their MIME registration.) As usual, whenever more than one MIME 1537 part is included in the body of a message, MIME multipart (i.e., 1538 'multipart/mixed') encloses them all. 1540 This document defines a set of XML schemas and MIME media types 1541 used for each block defined here. When additional data is passed 1542 by value in the SIP signaling, each CID URL points to one block 1543 in the body. Multiple URIs are used within a Call-Info header 1544 field (or multiple Call-Info header fields) to point to multiple 1545 blocks. When additional data is provided by reference (in SIP 1546 signaling or the element of a PIDF-LO), each HTTPS 1547 URL references one block; the data is retrieved with an HTTPS GET 1548 operation, which returns the block as an object (the blocks 1549 defined here are returned as XML objects). 1551 2. Second, the ability to embed additional data structures in the 1552 element of a PIDF-LO [RFC4119] is defined. 1554 In addition to service providers in the call path, the access 1555 network provider generally has similar information that can be 1556 valuable to the PSAP. When the access network provider and 1557 service provider are separate entities, the access network does 1558 not participate in the application layer signaling (and hence 1559 cannot add a Call-Info header field to the SIP message), but can 1560 provide location information in a PIDF-LO. When the access 1561 network provider supplies location information in the form of a 1562 PIDF-LO from a location server via a location configuration 1563 protocol, it has the ability to add the data structures defined 1564 in this document (or references to them) within the PIDF-LO. 1566 The data in these data structures is not specific to the location 1567 itself, but rather provides descriptive information having to do 1568 with the immediate circumstances about the provider's provision 1569 of the location (e.g., the identity of the access network 1570 provider, how to contact that entity, what kind of service the 1571 access network provides, subscriber information, etc.). This 1572 data is similar in nearly every respect to the data known by 1573 service providers in the path of the call. The 1574 element of the PIDF-LO is a mechanism for the access network 1575 provider to supply the information. This document describes a 1576 namespace per [RFC4119] for inclusion in the 1577 element of a PIDF-LO for adding information known to the access 1578 network provider. The access network provider SHOULD provide 1579 additional data within a element of a PDIF-LO it 1580 returns for emergency use (e.g., if requested with a HELD 1581 "responseTime" attribute of "emergencyRouting" or 1582 "emergencyDispatch" [RFC5985]). 1584 One or more blocks of data registered in the Emergency Call 1585 Additional Data registry, as defined in Section 11.1.9, can be 1586 included or referenced in the SIP signaling (using the Call-Info 1587 header field) or in the element of a PIDF-LO. For 1588 interoperability, only blocks in the registry are permitted to be 1589 sent using the mechanisms specified in this document. Since multiple 1590 entities are expected to provide sets of data, the data itself needs 1591 information describing the source. Consequently, each entity adding 1592 additional data MUST supply a "Data Provider" block. All other 1593 blocks are optional, but each entity SHOULD supply all blocks where 1594 it has at least some of the information in the block. 1596 Note that, as with any mechanism, failures are possible. For 1597 example, a block (provided by value or by reference) might not be the 1598 type indicated by the "purpose" parameter, or might be badly formed, 1599 etc. The general principle that applies to emergency calls is that 1600 it is more important for the call to go through than for everything 1601 to be correct. Thus, most PSAPs will process a call if at all 1602 possible, even if data is missing or other failures occur. 1604 6.1. Transmitting Blocks using Call-Info 1606 A URI to a block MAY be inserted in any SIP request or response 1607 method (most often INVITE or MESSAGE) with a Call-Info header field 1608 containing a purpose value starting with 'EmergencyCallData', a dot 1609 ("."), and the type of data available at the URI. The type of data 1610 is denoted by including the root of the MIME media subtype (the 1611 'EmergencyCallData' prefix is not repeated), omitting any suffix such 1612 as '+xml'). For example, when referencing a block with MIME media 1613 type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 1614 parameter is set to 'EmergencyCallData.ProviderInfo'. An example 1615 "Call-Info" header field for this would be: 1617 Call-Info: https://www.example.com/23sedde3; 1618 purpose="EmergencyCallData.ProviderInfo" 1620 A Call-info header field with a purpose value starting with 1621 'EmergencyCallData' only has meaning in the context of an emergency 1622 call (as ascertained by the presence of an emergency service URN in a 1623 Request-URI header field of a SIP message), test emergency calls 1624 (using an appropriate service URN), and some private-use calls where 1625 the endpoints have a preexisting relationship and privacy concerns do 1626 not apply because of the relationship; use in other contexts is 1627 undefined and is likely to unnecessarily expose confidential data. 1629 If the data is provided by reference, an HTTPS URI MUST be included 1630 and consequently Transport Layer Security (TLS) protection is used 1631 during the retrieval of the information. 1633 The data can also be supplied by value in any SIP request or response 1634 method that is permitted to contain a body (i.e., not a BYE request) 1635 [RFC3261]. In this case, Content Indirection (CID) [RFC2392] is 1636 used, with the CID URL referencing the MIME body part containing the 1637 data. Note that [RFC3261] forbids proxies from altering message 1638 bodies, so entities in the call path that add blocks by value need to 1639 do so using an appropriate SIP entity (e.g., a back-to-back user 1640 agent). 1642 Transmitting data by value is especially useful in certain cases, 1643 such as when the data exists in or is generated by the originating 1644 device, but is not intended for very large data blocks. Additional 1645 security and privacy considerations apply to data transmitted by 1646 value, as discussed in Section 9 and Section 10. 1648 More than one Call-Info header field with a purpose value starting 1649 with 'EmergencyCallData' can be expected, but at least one MUST be 1650 provided. The device MUST provide one unless it knows that a service 1651 provider is in the path of the call. The device MAY insert one if it 1652 uses a service provider. Each service provider in the path of an 1653 emergency call MUST insert its own. For example, a device, a 1654 telematics service provider in the call path, as well as the mobile 1655 carrier handling the call will each provide one. There might be 1656 circumstances where there is a service provider who is unaware that 1657 the call is an emergency call and cannot reasonably be expected to 1658 determine that it is an emergency call. In that case, that service 1659 provider is not expected to provide EmergencyCallData. 1661 6.2. Transmitting Blocks by Reference using the Element 1663 The element is used to transmit an 1664 additional data block by reference within a element of 1665 a PIDF-LO. The element has two 1666 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1667 type of data block referenced. The value of 'ref' is an HTTPS URL 1668 that resolves to a data structure with information about the call. 1669 The value of 'purpose' is the same as used in a 'Call-Info' header 1670 field (as specified in Section 6.1). 1672 For example, to reference a block with MIME media type 'application/ 1673 EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set 1674 to 'EmergencyCallData.ProviderInfo'. An example 1675 element for this would be: 1677 1680 The element transmits one data block; 1681 multiple data blocks are transmitted by using multiple 1682 elements. Multiple 1683 elements MAY be included as child 1684 elements inside the element. 1686 The following is a simplified example: 1688 1689 1693 1697 1700 1702 Example by Reference 1704 For an example in context, Figure 18 shows a PIDF-LO example with an 1705 element pointing to an 1706 EmergencyCallData.ServiceInfo data block with the URL in the 'ref' 1707 attribute and the purpose attribute set to 1708 "EmergencyCallData.ServiceInfo". 1710 6.3. Transmitting Blocks by Value using the Element 1712 It is RECOMMENDED that access networks supply the data specified in 1713 this document by reference, because PIDF-LOs can be fetched by a 1714 client or other entity and stored locally, so providing the data by 1715 value risks exposing private information to a larger audience. 1717 The element is used to transmit one or more 1718 additional data blocks by value within a element of a 1719 PIDF-LO. Each block being transmitted is placed (as a child element) 1720 inside the element. (The same XML structure 1721 as would be contained in the corresponding MIME media type body part 1722 is placed inside the element.) Multiple 1723 elements MAY be included as child elements 1724 in the element. 1726 The following is a simplified example: 1728 1730 1732 1735 flurbit735@es.example.com 1736 1737 Access Network Examples, Inc 1738 1739 urn:nena:companyid:Test 1740 NENA 1741 Access Network Provider 1742 1743 tel:+1-555-555-0897 1744 en 1745 1747 1750 flurbit735@es.example.com 1751 1752 This is an example text. 1753 1754 1756 1758 1760 Example by Value 1762 For an example in context, Figure 18 shows a PIDF-LO example that 1763 contains a element with the 1764 and the 1765 elements as child elements of an element. 1767 6.4. The Content-Disposition Parameter 1769 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1770 It updates and clarifies handling originally defined in RFC 3261 1771 [RFC3261] based on implementation experience. While RFC 3261 did not 1772 mandate support for 'multipart' message bodies, 'multipart/mixed' 1773 MIME bodies are used by many extensions (including this document) 1774 today. For example, adding a PIDF-LO, SDP, and additional data in 1775 body of a SIP message requires a 'multipart' message body. 1777 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1778 parameter for the Content-Disposition header field. These RFCs 1779 describe how a UAS reacts if it receives a message body whose content 1780 type or disposition type it does not understand. If the 'handling' 1781 parameter has the value "optional", the UAS ignores the message body. 1782 If the 'handling' parameter has the value "required", the UAS returns 1783 a 415 (Unsupported Media Type) response. The 'by-reference' 1784 disposition type of [RFC5621] allows a SIP message to contain a 1785 reference to the body part, and the SIP UA processes the body part 1786 according to the reference. This is the case for a Call-info header 1787 field containing a Content Indirection (CID) URL. 1789 As an example, a SIP message indicates the Content-Disposition 1790 parameter in the body of the SIP message as shown in Figure 14. 1792 Content-Type: application/sdp 1793 ...Omit Content-Disposition here; defaults are ok 1795 ...SDP goes in here 1797 --boundary1 1798 Content-Type: application/pidf+xml 1799 Content-ID: 1800 Content-Disposition: by-reference;handling=optional 1802 ...PIDF-LO goes in here 1804 --boundary1 1805 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1806 Content-ID: <1234567890@atlanta.example.com> 1807 Content-Disposition: by-reference; handling=optional 1809 ...Data provider information data goes in here 1811 --boundary1-- 1813 Figure 14: Example for use of the Content-Disposition Parameter in 1814 SIP 1816 7. Examples 1818 This section illustrates a longer and more complex example, as shown 1819 in Figure 15. In this example additional data is added by the end 1820 device, included by the VoIP provider, and provided by the access 1821 network provider (via the PIDF-LO). 1823 O +----+ [============] [=============] 1824 /|\ | UA | [ Access ] [ VoIP ] 1825 | +----+ [ Network ] [ Provider ] 1826 / \ [ Provider ] [ example.org ] 1827 [ ] [ ] 1828 (1) [ ] (2) [ ] 1829 Emergency Call [ ] Emergency Call [ ] 1830 ------------------------------------------------------> ] 1831 +Device Info [ ] +Device Info [ ] 1832 +Data Prov. Info [ ^ ] +Data Provider Info [ | ] 1833 +Location URI [=======.====] +Location URI [====|========] 1834 . | 1835 . | 1836 +Location . [==============] | 1837 +Owner/Subscriber Info . [ ] (3) | 1838 +Device Info . (4) [ <------------+ 1839 +Data Provider Info #3 ..........> ] Emergency Call 1840 [ ] +Device Info 1841 [ PSAP ] +Data Prov. Info #2 1842 [ ] +Location URI 1843 [==============] 1845 Legend: 1847 --- Emergency Call Setup Procedure 1848 ... Location Retrieval/Response 1850 Figure 15: Additional Data Example Flow 1852 The example scenario starts with the end device itself adding device 1853 information, owner/subscriber information, a location URI, and data 1854 provider information to the outgoing emergency call setup message 1855 (see step #1 in Figure 15). The SIP INVITE example is shown in 1856 Figure 16. 1858 INVITE urn:service:sos SIP/2.0 1859 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1860 Max-Forwards: 70 1861 To: 1862 From: Hannes Tschofenig ;tag=9fxced76sl 1863 Call-ID: 3848276298220188511@example.com 1864 Call-Info: 1865 ;purpose=icon, 1866 ;purpose=info, 1867 1868 ;purpose=EmergencyCallData.ProviderInfo, 1869 1870 ;purpose=EmergencyCallData.DeviceInfo 1871 Geolocation: 1872 Geolocation-Routing: yes 1873 Accept: application/sdp, application/pidf+xml, 1874 application/EmergencyCallData.ProviderInfo+xml 1875 CSeq: 31862 INVITE 1876 Contact: 1877 Content-Type: multipart/mixed; boundary=boundary1 1878 Content-Length: ... 1880 --boundary1 1881 Content-Type: application/sdp 1883 ...SDP goes here 1885 --boundary1 1886 Content-Type: application/EmergencyCallData.DeviceInfo+xml 1887 Content-ID: <0123456789@atlanta.example.com> 1888 Content-Disposition: by-reference;handling=optional 1890 1891 1894 1895 d4b3072df09876543@[93.184.216.119] 1896 1897 laptop 1898 00-0d-4b-30-72-df 1900 1901 1903 --boundary1 1904 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1905 Content-ID: <1234567890@atlanta.example.com> 1906 Content-Disposition: by-reference;handling=optional 1907 1908 1910 d4b3072df09876543@[93.184.216.119] 1911 1912 Hannes Tschofenig 1913 Client 1914 tel:+1-555-555-0123 1915 en 1916 1918 1919 Hannes Tschofenig 1920 1921 Hannes 1922 Tschofenig 1923 1924 1925 Dipl. Ing. 1926 1927 --0203 1928 1929 20090808T1430-0500 1930 1931 M 1932 1933 1 1934 1935 de 1936 1937 1938 2 1939 1940 en 1941 1942 1943 1944 work 1945 1949 1950 1951 1952 Linnoitustie 6 1953 Espoo 1954 Uusimaa 1955 02600 1956 Finland 1957 1958 1959 1960 home 1961 1966 1967 1968 1969 42 W 11th St 1970 Wilmington 1971 DE 1972 19801 1973 USA 1974 1975 1976 1977 1978 work 1979 voice 1980 1981 1982 tel:+358 50 4871445 1983 1984 1985 1986 1987 home 1988 voice 1989 1990 1991 tel:+1 555 555 0123 1992 1993 1994 1995 1996 work 1997 voice 1998 main-number 1999 2000 2001 tel:+1 302 594-3100 2002 2003 2004 work 2005 2006 hannes.tschofenig@nsn.com 2007 2008 2009 work 2010 2011 geo:60.210796,24.812924 2012 2013 2014 home 2015 2016 geo:39.746537,-75.548027 2017 2018 2019 2020 home 2021 2022 https://www.example.com/key.asc 2023 2024 Finland/Helsinki 2025 2026 home 2027 2028 http://example.com/hannes.tschofenig 2029 2030 2031 2032 2033 2034 --boundary1-- 2036 Figure 16: End Device sending SIP INVITE with Additional Data 2038 In this example, information available to the access network provider 2039 is included in the call setup message only indirectly via the use of 2040 the location reference. The PSAP has to retrieve it via a separate 2041 look-up step. Since the access network provider and the VoIP service 2042 provider are two independent entities in this scenario, the access 2043 network provider is not involved in application layer exchanges; the 2044 SIP INVITE transits the access network transparently, as illustrated 2045 in steps #1 and #2 (the access network does not alter the SIP 2046 INVITE). 2048 The VoIP service provider receives the message and determines, based 2049 on the Service URN, that the incoming request is an emergency call. 2050 It performs typical emergency services related tasks (such as 2051 location-based routing), and adds additional data, namely service and 2052 subscriber information as well as data provider information #2, to 2053 the outgoing message. For the example we assume a VoIP service 2054 provider that deploys a back-to-back user agent allowing additional 2055 data to be included in the body of the SIP message (rather than by 2056 reference), which allows us to illustrate the use of multiple data 2057 provider info blocks. The resulting message is shown in Figure 17. 2058 The SIP INVITE is sent to the PSAP in step #3. 2060 INVITE sips:psap@example.org SIP/2.0 2061 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 2062 Max-Forwards: 70 2063 To: 2064 From: Hannes Tschofenig ;tag=9fxced76sl 2065 Call-ID: 3848276298220188511@example.com 2066 Call-Info: ; 2067 purpose=icon, 2068 ; purpose=info, 2069 ; 2070 purpose=EmergencyCallData.ProviderInfo 2071 ; 2072 purpose=EmergencyCallData.DeviceInfo 2073 Call-Info: ; 2074 purpose=EmergencyCallData.ServiceInfo 2075 Call-Info: ; 2076 purpose=EmergencyCallData.ProviderInfo 2077 Geolocation: 2078 Geolocation-Routing: yes 2079 Accept: application/sdp, application/pidf+xml, 2080 application/EmergencyCallData.ProviderInfo+xml 2081 CSeq: 31862 INVITE 2082 Contact: 2083 Content-Type: multipart/mixed; boundary=boundary1 2084 Content-Length: ... 2086 --boundary1 2087 Content-Type: application/sdp 2089 ...SDP goes here 2091 --boundary1 2092 Content-Type: application/EmergencyCallData.DeviceInfo+xml 2093 Content-ID: <0123456789@atlanta.example.com> 2094 Content-Disposition: by-reference;handling=optional 2096 2097 2100 d4b3072df09876543@[93.184.216.119] 2101 2102 laptop 2103 00-0d-4b-30-72-df 2105 2107 --boundary1 2108 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2109 Content-ID: <1234567890@atlanta.example.com> 2110 Content-Disposition: by-reference;handling=optional 2112 2113 2116 d4b3072df09876543@[93.184.216.119] 2117 2118 Hannes Tschofenig 2119 2120 Client 2121 tel:+1-555-555-0123 2122 en 2123 2125 2126 Hannes Tschofenig 2127 2128 Hannes 2129 Tschofenig 2130 2131 2132 Dipl. Ing. 2133 2134 --0203 2135 2136 20090808T1430-0500 2137 2138 M 2139 2140 1 2141 2142 de 2143 2144 2145 2 2146 2147 en 2148 2149 2150 2151 work 2152 2156 2157 2158 2159 Linnoitustie 6 2160 Espoo 2161 Uusimaa 2162 02600 2163 Finland 2164 2165 2166 2167 home 2168 2173 2174 2175 2176 42 W 11th St 2177 Wilmington 2178 DE 2179 19801 2180 USA 2181 2182 2183 2184 2185 work 2186 voice 2187 2188 2189 tel:+358 50 4871445 2190 2191 2192 2193 2194 home 2195 voice 2196 2197 2198 tel:+1 555 555 0123 2199 2200 2201 work 2202 2203 hannes.tschofenig@nsn.com 2204 2205 2206 work 2207 2208 geo:60.210796,24.812924 2209 2210 2211 home 2212 2213 geo:39.746537,-75.548027 2214 2215 2216 2217 home 2218 2219 https://www.example.com/key.asc 2220 2221 Finland/Helsinki 2222 2223 home 2224 2225 http://example.com/hannes.tschofenig 2226 2227 2228 2229 2231 --boundary1 2232 Content-Type: application/EmergencyCallData.ServiceInfo+xml 2233 Content-ID: 2234 Content-Disposition: by-reference;handling=optional 2236 2237 2239 string0987654321@example.org 2240 2241 Residence 2242 VOIP 2243 Unknown 2244 2246 --boundary1 2247 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2248 Content-ID: 2249 Content-Disposition: by-reference;handling=optional 2251 2252 2255 string0987654321@example.org 2256 2257 Exemplar VoIP Provider 2258 2259 urn:nena:companyid:ID123 2260 NENA 2261 Service Provider 2262 sip:voip-provider@example.com 2263 en 2264 2266 2267 John Doe 2268 2269 John 2270 Doe 2271 2272 2273 2274 2275 --0203 2276 2277 20090808T1430-0500 2278 2279 M 2280 2281 1 2282 2283 en 2284 2285 2286 work 2287 2288 Exemplar VoIP Provider 2289 2290 2291 2292 work 2293 2296 2297 2298 2299 123 Middle Street 2300 the Sticks 2301 IA 2302 50055 2303 USA 2304 2305 2306 2307 2308 work 2309 voice 2310 main-number 2311 2312 2313 sips:john.doe@example.com 2314 2315 2316 work 2317 2318 john.doe@example.com 2319 2320 2321 work 2322 2323 geo:41.761838,-92.963268 2324 2325 America/Chicago 2326 2327 home 2328 2329 http://www.example.com/john.doe 2330 2331 2332 2333 2334 --boundary1-- 2336 Figure 17: VoIP Provider sending SIP INVITE with Additional Data 2338 Finally, the PSAP requests location information from the access 2339 network provider. The response is shown in Figure 18. Along with 2340 the location information, additional data is provided in the 2341 element of the PIDF-LO. This request and response is 2342 step #4. 2344 2345 2350 2351 2352 2353 2355 US 2356 DE 2357 Wilmington 2358 W 2359 11th 2360 Street 2361 42 2362 The Hotel DuPont 2363 19801 2364 2365 2366 2367 true 2368 2369 2013-12-10T20:00:00Z 2370 2371 2372 802.11 2374 2377 2381 2382 2385 88QV4FpfZ976T@example.com 2386 2387 Diamond State Exemplar 2388 2389 urn:nena:companyid:diamond 2390 NENA 2391 Access Network Provider 2392 tel:+1-302-555-0000 2393 en 2394 2396 2398 88QV4FpfZ976T@example.com 2399 2400 This is an example text. 2401 2403 2404 2406 2407 mac:00-0d-4b-30-72-df 2408 2013-07-09T20:57:29Z 2409 2410 2412 Figure 18: Access Network Provider returning PIDF-LO with Additional 2413 Data 2415 8. XML Schemas 2417 This section defines the XML schemas of the five data blocks. 2418 Additionally, the provided-by schema is specified. 2420 8.1. EmergencyCallData.ProviderInfo XML Schema 2422 2423 2433 2436 2439 2443 2444 2445 2446 2447 2448 2450 2451 2452 2455 2458 2461 2464 2467 2470 2471 2472 2473 2479 2480 2481 2483 2485 2486 2487 2489 2490 2491 2493 2496 2500 2502 2503 2505 2507 Figure 19: EmergencyCallData.ProviderInfo XML Schema. 2509 8.2. EmergencyCallData.ServiceInfo XML Schema 2510 2511 2520 2523 2526 2527 2528 2531 2534 2538 2541 2543 2544 2546 2548 Figure 20: EmergencyCallData.ServiceInfo XML Schema. 2550 8.3. EmergencyCallData.DeviceInfo XML Schema 2552 2553 2562 2565 2568 2569 2570 2573 2576 2579 2582 2584 2585 2586 2587 2590 2591 2592 2593 2595 2598 2601 2603 2604 2606 2608 Figure 21: EmergencyCallData.DeviceInfo XML Schema. 2610 8.4. EmergencyCallData.SubscriberInfo XML Schema 2612 2613 2624 2627 2630 2633 2634 2635 2636 2637 2640 2641 2642 2643 2645 2646 2647 2649 2651 2652 2654 2655 2656 2658 2660 Figure 22: EmergencyCallData.SubscriberInfo XML Schema. 2662 8.5. EmergencyCallData.Comment XML Schema 2663 2664 2673 2676 2679 2680 2681 2684 2688 2690 2691 2693 2694 2695 2696 2697 2698 2699 2701 2703 Figure 23: EmergencyCallData.Comment XML Schema. 2705 8.6. provided-by XML Schema 2707 This section defines the provided-by schema. 2709 2710 2725 2728 2731 2734 2737 2741 2744 2747 2749 2750 2751 2752 2753 2755 2756 2759 2761 2762 2763 2765 2767 2768 2769 2772 2775 2778 2781 2785 2788 2789 2791 2793 Figure 24: provided-by XML Schema 2795 9. Security Considerations 2797 The data structures described in this document contain information 2798 usually considered private. When information is provided by value, 2799 entities that are a party to the SIP signaling (such as proxy servers 2800 and back-to-back user agents) will have access to it and need to 2801 protect it against inappropriate disclosure. An entity that is able 2802 to eavesdrop on the SIP signaling will also have access. Some access 2803 types (such as in-the-clear Wi-Fi) are more vulnerable than others 2804 (such as 3G or 4G cellular data traffic) to eavesdropping. 2805 Mechanisms that protect against eavesdropping (such as Transport 2806 Layer Security (TLS) version 1.2 or later) SHOULD be preferentially 2807 used whenever feasible. (This requirement is not a "MUST" because 2808 there is an existing deployed base of clear-text SIP, and also 2809 because, as an emergency call, it is more important for the call to 2810 go through than for it to be protected; e.g., the call MUST proceed 2811 even if the TLS negotiation or certificate verification fails for 2812 whatever reason.) When information is provided by reference, TLS 2813 mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for 2814 dereferencing, the requestor MUST use a client certificate to 2815 authenticate the HTTP request, and the provider of the information is 2816 REQUIRED to validate the credentials provided by the requester. 2817 While the creation of a public key infrastructure (PKI) that has 2818 global scope might be difficult, the alternatives to creating devices 2819 and services that can provide critical information securely are more 2820 daunting. The provider of the information MAY enforce any policy it 2821 wishes to use, but PSAPs and responder agencies are strongly advised 2822 to deploy a PKI so that providers of additional data can check the 2823 certificate of the client (the requester) and decide the appropriate 2824 policy to enforce based on that certificate. 2826 TLS MUST be version 1.2 or later. TLS MUST be version 1.2 or later. 2827 It is RECOMMENDED to use only cipher suites that offer Perfect 2828 Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), and to 2829 follow the recommendations in BCP 195 [RFC7525]. 2831 Ideally, the PSAP and emergency responders will be given credentials 2832 signed by an authority trusted by the data provider. In most 2833 circumstances, nationally recognized credentials are sufficient; the 2834 emergency services community within a country can arrange a PKI, data 2835 providers can be provisioned with the root CA public key for the 2836 country. Some nations are developing a PKI for this, and related, 2837 purposes. Since calls could be made from devices where the device 2838 and/or the service provider(s) are not local to the emergency 2839 services authorities, globally recognized credentials are useful. 2840 This might be accomplished by extending the notion of the "forest 2841 guide" described in [RFC5582] to allow the forest guide to provide 2842 the credential of the PKI root for areas for which it has coverage 2843 information, but standards for such a mechanism are not yet 2844 available. In its absence, the data provider needs to obtain by out 2845 of band means the root CA credentials for any areas to which it is 2846 willing to provide additional data. With the credential of the root 2847 CA for a national emergency services PKI, the data provider server 2848 can validate the credentials of an entity requesting additional data 2849 by reference. 2851 The data provider also needs a credential that can be verified by the 2852 emergency services to know that it is receiving data from an 2853 authorized server. The emergency services authorities could provide 2854 credentials, distinguishable from credentials provided to emergency 2855 responders and PSAPs, which could be used to validate data providers. 2856 Such credentials would have to be acceptable to any PSAP or responder 2857 that could receive a call with additional data supplied by that 2858 provider. This would be extensible to global credential validation 2859 using the forest guide as mentioned above. In the absence of such 2860 credentials, the emergency services authorities could maintain a list 2861 of local data providers' credentials as provided to them out of band. 2862 At a minimum, the emergency services authorities could obtain a 2863 credential from the DNS entry of the domain in the Additional Data 2864 URI (e.g., using DANE [RFC6698]) to at least validate that the server 2865 is known to the domain providing the URI. 2867 Data provided by devices by reference have similar credential 2868 validation issues as for service providers, and while the solutions 2869 are the same, the challenges of doing so for every device are 2870 obviously more difficult, especially when considering root 2871 certificate updates, revocation lists, etc. However, in general, 2872 devices are not expected to provide data directly by reference, but 2873 rather, to either provide data by value, or upload the data to a 2874 server which can more reliably make it available and more easily 2875 enforce security policy. Devices which do provide data directly by 2876 reference, which might include fixed-location sensors, will need to 2877 be capable of handling this. 2879 Neither service providers nor devices will supply private information 2880 unless the call is recognized as an emergency call. In cellular 2881 telephony systems (such as those using 3GPP IMS), there are different 2882 procedures for an originating device to place an emergency versus a 2883 normal call. If a call that is really an emergency call is initiated 2884 as a normal call and the cellular service provider recognizes this, 2885 3GPP IMS permits the service provider to either accept the call 2886 anyway or reject it with a specific code that instructs the device to 2887 retry the call as an emergency call. Service providers ought to 2888 choose the latter, because otherwise the device will not have 2889 included the information specified in this document (since the device 2890 didn't recognize the call as being an emergency call). 2892 10. Privacy Considerations 2894 This document enables functionality for conveying additional 2895 information about the caller and the caller's device and service to 2896 the callee. Some of this information is personal data and therefore 2897 privacy concerns arise. An explicit privacy indicator for 2898 information directly relating to the caller's identity is defined and 2899 use is mandatory. However, observance of this request for privacy 2900 and which information it relates to is determined by the destination 2901 jurisdiction (which replicates functionality provided in some legacy 2902 emergency services systems). 2904 There are a number of privacy concerns with non-emergency real-time 2905 communication services that are also applicable to emergency calling. 2906 Data protection regulation world-wide has, however, decided to create 2907 exceptions for emergency services since the drawbacks of disclosing 2908 personal data are outweighed by the benefit for the emergency caller. 2909 Hence, the data protection rights of individuals are commonly waived 2910 for emergency situations. There are, however, still various 2911 countries that offer some degree of anonymity for the caller towards 2912 PSAP call takers. 2914 The functionality defined in this document far exceeds the amount of 2915 information sharing available in the legacy POTS system. For this 2916 reason there are additional privacy threats to consider, which are 2917 described in more detail in [RFC6973]. 2919 Stored Data Compromise: There is an increased risk of stored data 2920 compromise since additional data is collected and stored in 2921 databases. Without adequate measures to secure stored data from 2922 unauthorized or inappropriate access at access network providers, 2923 service providers, end devices, as well as PSAPs, individuals are 2924 exposed to potential financial, reputational, or physical harm. 2926 Misattribution: If the personal data collected and conveyed is 2927 incorrect or inaccurate then this can lead to misattribution. 2928 Misattribution occurs when data or communications related to one 2929 individual are attributed to another. 2931 Identification: By the nature of the additional data and its 2932 capability to provide much richer information about the caller, 2933 the call, and the location, the calling party is identified in a 2934 much better way. Some users could feel uncomfortable with this 2935 degree of information sharing even in emergency services 2936 situations. 2938 Secondary Use: There is a risk of secondary use, which is the use of 2939 collected information about an individual without the individual's 2940 consent for a purpose different from that for which the 2941 information was collected. The stated purpose of the additional 2942 data is for emergency services purposes, but theoretically the 2943 same information could be used for any other call as well. 2944 Additionally, parties involved in the emergency call could retain 2945 the obtained information and re-use it for other, non-emergency 2946 services purposes. While technical measures are not in place to 2947 prevent such secondary re-use, policy, legal, regulatory, and 2948 other non-technical approaches can be effective. 2950 Disclosure: When the data defined in this document is not properly 2951 protected (while in transit with traditional communication 2952 security techniques, and while stored using access control 2953 mechanisms) there is the risk of disclosure, which is the 2954 revelation of private information about an individual. 2956 To mitigate these privacy risks the following countermeasures can be 2957 taken: 2959 In regions where callers can elect to suppress certain personally 2960 identifying information, network or PSAP functionality can inspect 2961 privacy flags within the SIP headers to determine what information 2962 can be passed, stored, or displayed to comply with local policy or 2963 law. RFC 3325 [RFC3325] defines the "id" priv-value token. The 2964 presence of this privacy type in a Privacy header field indicates 2965 that the user would like the network asserted identity to be kept 2966 private with respect to SIP entities outside the trust domain with 2967 which the user authenticated, including the PSAP. 2969 This document defines various data structures that contain privacy- 2970 sensitive data. For example, identifiers for the device (e.g., 2971 serial number, MAC address) or account/SIM (e.g., IMSI), contact 2972 information for the user, location of the caller. Local regulations 2973 may govern which data is provided in emergency calls, but in general, 2974 the emergency call system is aided by the information described in 2975 this document. There is a tradeoff between the privacy 2976 considerations and the utility of the data. For protection, this 2977 specification requires all retrieval of data passed by reference to 2978 be protected against eavesdropping and alteration via communication 2979 security techniques (namely TLS). Furthermore, security safeguards 2980 are required to prevent unauthorized access to stored data. Various 2981 security incidents over at least the past few decades have shown that 2982 data breaches are not uncommon and are often caused by lack of proper 2983 access control frameworks, software bugs (such as buffer overflows), 2984 or missing input parsing (such as SQL injection attacks). The risks 2985 of data breaches is increased with the obligation for emergency 2986 services to retain emergency call related data for extended periods 2987 (e.g., several years are the norm). 2989 Finally, it is also worth highlighting the nature of the SIP 2990 communication architecture, which introduces additional complications 2991 for privacy. Some forms of data can be sent by value in the SIP 2992 signaling or by reference (a URL in the SIP signaling). When data is 2993 sent by value, all intermediaries have access to the data. As such, 2994 these intermediaries could also introduce additional privacy risk. 2995 Therefore, in situations where the conveyed information is privacy- 2996 sensitive and intermediaries are involved, transmitting by reference 2997 might be appropriate, assuming the source of the data can operate a 2998 sufficient dereferencing infrastructure and that proper access 2999 control policies are available for distinguishing the different 3000 entities dereferencing the reference. Without access control 3001 policies any party in possession of the reference is able to resolve 3002 the reference and to obtain the data, including intermediaries. 3004 11. IANA Considerations 3006 11.1. Registry creation 3008 This document creates a new registry called 'Emergency Call 3009 Additional Data' with a number of sub-registries. 3011 For several of the sub-registries, "Expert Review" is the criteria 3012 for adding new entries. As discussed in Section 5, it can be 3013 counterproductive to register new types of data, and as discussed in 3014 Section 10, data sent as part of an emergency call can be very 3015 privacy-sensitive. In some cases, it is anticipated that various 3016 standards bodies dealing with emergency services might need to 3017 register new values, and in those cases text below advises the 3018 designed expert to verify that the entity requesting the registration 3019 is relevant (e.g., a recognized emergency services related SDO). In 3020 other cases, especially those where the trade-off between the 3021 potential benefit versus danger of new registrations is more 3022 conservative (such as Section 11.1.9), "Specification Required" is 3023 the criteria, which is a higher hurdle and also implicitly includes 3024 an expert review. 3026 The following sub-registries are created for this registry. 3028 11.1.1. Provider ID Series Registry 3030 This document creates a new sub-registry called "Provider ID Series". 3031 As defined in [RFC5226], this registry operates under "Expert Review" 3032 rules. The expert should determine that the entity requesting a new 3033 value is a legitimate issuer of service provider IDs suitable for use 3034 in Additional Call Data. 3036 Private entities issuing or using internally-generated IDs are 3037 encouraged to register here and to ensure that all IDs they issue or 3038 use are unique. This guarantees that IDs issued or used by the 3039 entity are globally unique and distinguishable from other IDs issued 3040 or used by the same or a different entity. (Some organizations, such 3041 as NENA, issue IDs that are unique among all IDs they issue, so an 3042 entity using a combination of its NENA ID and the fact that it is 3043 from NENA is globally unique. Other entities might not have an ID 3044 issued by an organization such as NENA, so they are permitted to use 3045 their domain name, but if so, it needs to be unique.) 3047 The content of this registry includes: 3049 Name: An identifier to be used in the 'ProviderIDSeries' element. 3051 Source: The full name of the organization issuing the identifiers. 3053 URL: A URL to the organization for further information. 3055 The initial set of values is listed in Figure 1. 3057 11.1.2. Service Environment Registry 3059 This document creates a new sub-registry called "Service 3060 Environment". As defined in [RFC5226], this registry operates under 3061 "Expert Review" rules. The expert should determine that the entity 3062 requesting a new value is relevant for this service element (e.g., a 3063 recognized emergency services related SDO), and that the new value is 3064 distinct from existing values, and its use is unambiguous. 3066 The content of this registry includes: 3068 Token: The value to be used in the element. 3070 Description: A short description of the value. 3072 The initial set of values is listed in Figure 4. 3074 11.1.3. Service Type Registry 3076 This document creates a new sub-registry called "Service Type". As 3077 defined in [RFC5226], this registry operates under "Expert Review" 3078 rules. The expert should determine that the entity requesting a new 3079 value is relevant for this service element (e.g., a recognized 3080 emergency services related SDO) and that the requested value is 3081 clearly distinct from other values so that there is no ambiguity as 3082 to when the value is to be used or which value is to be used. 3084 The content of this registry includes: 3086 Name: The value to be used in the element. 3088 Description: A short description of the value. 3090 The initial set of values is listed in Figure 5. 3092 11.1.4. Service Mobility Registry 3094 This document creates a new sub-registry called "Service Mobility". 3095 As defined in [RFC5226], this registry operates under "Expert Review" 3096 rules. The expert should determine that the entity requesting a new 3097 value is relevant for this service element (e.g., a recognized 3098 emergency services related SDO) and that the requested value is 3099 clearly distinct from other values so that there is no ambiguity as 3100 to when the value is to be used or which value is to be used. 3102 The content of this registry includes: 3104 Token: The value used in the element. 3106 Description: A short description of the value. 3108 The initial set of values is listed in Figure 6. 3110 11.1.5. Service Provider Type Registry 3112 This document creates a new sub-registry called "Service Provider 3113 Type". As defined in [RFC5226], this registry operates under "Expert 3114 Review". The expert should determine that the proposed new value is 3115 distinct from existing values and appropriate for use in the 3116 element 3118 The content of this registry includes: 3120 Token: The value used in the element. 3122 Description: A short description of the type of service provider. 3124 The initial set of values is defined in Figure 2. 3126 11.1.6. Device Classification Registry 3128 This document creates a new sub-registry called 'Device 3129 Classification'. As defined in [RFC5226], this registry operates 3130 under "Expert Review" rules. The expert should consider whether the 3131 proposed class is unique from existing classes and the definition of 3132 the class will be clear to implementors and PSAPs/responders. 3134 The content of this registry includes: 3136 Token: Value used in the element. 3138 Description: Short description identifying the device type. 3140 The initial set of values are defined in Figure 8. 3142 11.1.7. Device ID Type Type Registry 3144 This document creates a new sub-registry called "Device ID Type". As 3145 defined in [RFC5226], this registry operates under "Expert Review" 3146 rules. The expert should ascertain that the proposed type is well 3147 understood, and provides information which PSAPs and responders are 3148 able to use to uniquely identify a device. (For example, a biometric 3149 fingerprint used to authenticate a device would not normally be 3150 useful by a PSAP or responder to identify a device.) 3152 The content of this registry includes: 3154 Token: The value to be placed in the element. 3156 Description: Short description identifying the type of the device 3157 ID. 3159 The initial set of values are defined in Figure 9. 3161 11.1.8. Device/Service Data Type Registry 3163 This document creates a new sub-registry called "Device/Service Data 3164 Type". As defined in [RFC5226], this registry operates under 3165 "Specification Required" rules, which include an explicit expert 3166 review. The designated expert should ascertain that the proposed 3167 type is well understood, and provides information useful to PSAPs and 3168 responders. The specification must contain a complete description of 3169 the data, and a precise format specification suitable to allow 3170 interoperable implementations. 3172 The content of this registry includes: 3174 Token: The value to be placed in the element. 3176 Description: Short description identifying the data. 3178 Specification: Citation for the specification of the data. 3180 The initial set of values are listed in Figure 10. 3182 11.1.9. Emergency Call Data Types Registry 3184 This document creates a new sub-registry called 'Emergency Call Data 3185 Types'. As defined in [RFC5226], this registry operates under 3186 "Specification Required" rules, which include an explicit expert 3187 review. The expert is responsible for verifying that the document 3188 contains a complete and clear specification and the proposed 3189 functionality does not obviously duplicate existing functionality. 3191 The expert is also responsible for verifying that the block is 3192 correctly categorized per the description of the categories in 3193 Section 1. 3195 The registry contains an entry for every data block that can be sent 3196 with an emergency call using the mechanisms as specified in this 3197 document. Each data block is identified by the "root" of its MIME 3198 media subtype (which is the part after 'EmergencyCallData.'). If the 3199 MIME media subtype does not start with 'EmergencyCallData.', then it 3200 cannot be registered here nor used in a Call-Info header field as 3201 specified in this document. The subtype MAY exist under any MIME 3202 media type (although most commonly these are under 'Application/' 3203 this is NOT REQUIRED), however, to be added to the registry the 3204 "root" needs to be unique regardless of the MIME media type. 3206 The content of this registry includes: 3208 Token: The root of the data's MIME media subtype (not including the 3209 'EmergencyCallData' prefix and any suffix such as '+xml') 3211 Data About: A hint as to if the block is considered descriptive of 3212 the call, the caller, or the location (or is applicable to more 3213 than one), which can help PSAPs and other entities determine if 3214 they wish to process the block. Note that this is only a hint; 3215 entities need to consider the block's contents, not just this 3216 field, when determining if they wish to process the block (which 3217 is why the field only exists in the registry, and is not contained 3218 within the block). The value MUST be either "The Call", "The 3219 Caller", "The Location", or "Multiple". New values are created by 3220 extending this registry in a subsequent RFC. 3222 Reference: The document that describes the data object 3224 Note that the tokens in this registry are part of the 3225 'EmergencyCallData' compound value; when used as a value of the 3226 'purpose' parameter of a Call-Info header field, the values listed in 3227 this registry are prefixed by 'EmergencyCallData.' per the 3228 'EmergencyCallData' registration Section 11.2. 3230 The initial set of values are listed in Figure 25. 3232 +----------------+--------------+------------+ 3233 | Token | Data About | Reference | 3234 +----------------+--------------+------------+ 3235 | ProviderInfo | The Call | [This RFC] | 3236 | ServiceInfo | The Call | [This RFC] | 3237 | DeviceInfo | The Call | [This RFC] | 3238 | SubscriberInfo | The Call | [This RFC] | 3239 | Comment | The Call | [This RFC] | 3240 +----------------+--------------+------------+ 3242 Figure 25: Additional Data Blocks Registry 3244 11.2. 'EmergencyCallData' Purpose Parameter Value 3246 This document defines the 'EmergencyCallData' value for the 'purpose' 3247 parameter of the Call-Info header field [RFC3261]. IANA has added 3248 this document to the list of references for the 'purpose' value of 3249 Call-Info in the Header Field Parameters and Parameter Values sub- 3250 registry of the Session Initiation Protocol (SIP) Parameters 3251 registry. Note that 'EmergencyCallData' is a compound value; when 3252 used as a value of the 'purpose' parameter of a Call-Info header 3253 field, 'EmergencyCallData' is immediately followed by a dot ('.') and 3254 a value from the 'Emergency Call Data Types' registry Section 11.1.9. 3256 11.3. URN Sub-Namespace Registration for Registry Entry 3258 This section registers the namespace specified in Section 11.5.1 in 3259 the provided-by registry established by RFC 4119, for usage within 3260 the element of a PIDF-LO. 3262 The schema for the element used by this document is 3263 specified in Section 8.6. 3265 11.4. MIME Registrations 3267 11.4.1. MIME Content-type Registration for 'application/ 3268 EmergencyCallData.ProviderInfo+xml' 3270 This specification requests the registration of a new MIME media type 3271 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3272 RFC 7303 [RFC7303]. 3274 MIME media type name: application 3276 MIME media subtype name: EmergencyCallData.ProviderInfo+xml 3278 Mandatory parameters: none 3279 Optional parameters: charset (indicates the character encoding of 3280 the contents) 3282 Encoding considerations: Uses XML, which can contain 8-bit 3283 characters, depending on the character encoding. See Section 3.2 3284 of RFC 7303 [RFC7303]. 3286 Security considerations: This content type is designed to carry 3287 the data provider information, which is a sub-category of 3288 additional data about an emergency call. Since this data can 3289 contain personal information, appropriate precautions are needed 3290 to limit unauthorized access, inappropriate disclosure, and 3291 eavesdropping of personal information. Please refer to Section 9 3292 and Section 10 for more information. 3294 Interoperability considerations: None 3296 Published specification: [TBD: This specification] 3298 Applications which use this media type: Emergency Services 3300 Additional information: 3302 Magic Number: None 3304 File Extension: .xml 3306 Macintosh file type code: 'TEXT' 3308 Person and email address for further information: Hannes 3309 Tschofenig, Hannes.Tschofenig@gmx.net 3311 Intended usage: LIMITED USE 3313 Author: This specification is a work item of the IETF ECRIT 3314 working group, with mailing list address . 3316 Change controller: The IESG 3318 11.4.2. MIME Content-type Registration for 'application/ 3319 EmergencyCallData.ServiceInfo+xml' 3321 This specification requests the registration of a new MIME media type 3322 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3323 RFC 7303 [RFC7303]. 3325 MIME media type name: application 3326 MIME media subtype name: EmergencyCallData.ServiceInfo+xml 3328 Mandatory parameters: none 3330 Optional parameters: charset (indicates the character encoding of 3331 the contents) 3333 Encoding considerations: Uses XML, which can contain 8-bit 3334 characters, depending on the character encoding. See Section 3.2 3335 of RFC 7303 [RFC7303]. 3337 Security considerations: This content type is designed to carry 3338 the service information, which is a sub-category of additional 3339 data about an emergency call. Since this data can contain 3340 personal information, appropriate precautions are needed to limit 3341 unauthorized access, inappropriate disclosure, and eavesdropping 3342 of personal information. Please refer to Section 9 and Section 10 3343 for more information. 3345 Interoperability considerations: None 3347 Published specification: [TBD: This specification] 3349 Applications which use this media type: Emergency Services 3351 Additional information: 3353 Magic Number: None 3355 File Extension: .xml 3357 Macintosh file type code: 'TEXT' 3359 Person and email address for further information: Hannes 3360 Tschofenig, Hannes.Tschofenig@gmx.net 3362 Intended usage: LIMITED USE 3364 Author: This specification is a work item of the IETF ECRIT 3365 working group, with mailing list address . 3367 Change controller: The IESG 3369 11.4.3. MIME Content-type Registration for 'application/ 3370 EmergencyCallData.DeviceInfo+xml' 3372 This specification requests the registration of a new MIME media type 3373 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3374 RFC 7303 [RFC7303]. 3376 MIME media type name: application 3378 MIME media subtype name: EmergencyCallData.DeviceInfo+xml 3380 Mandatory parameters: none 3382 Optional parameters: charset (indicates the character encoding of 3383 the contents) 3385 Encoding considerations: Uses XML, which can contain 8-bit 3386 characters, depending on the character encoding. See Section 3.2 3387 of RFC 7303 [RFC7303]. 3389 Security considerations: This content type is designed to carry 3390 device information, which is a sub-category of additional data 3391 about an emergency call. Since this data contains personal 3392 information, appropriate precautions need to be taken to limit 3393 unauthorized access, inappropriate disclosure to third parties, 3394 and eavesdropping of this information. Please refer to Section 9 3395 and Section 10 for more information. 3397 Interoperability considerations: None 3399 Published specification: [TBD: This specification] 3401 Applications which use this media type: Emergency Services 3403 Additional information: 3405 Magic Number: None 3407 File Extension: .xml 3409 Macintosh file type code: 'TEXT' 3411 Person and email address for further information: Hannes 3412 Tschofenig, Hannes.Tschofenig@gmx.net 3414 Intended usage: LIMITED USE 3415 Author: This specification is a work item of the IETF ECRIT 3416 working group, with mailing list address . 3418 Change controller: The IESG 3420 11.4.4. MIME Content-type Registration for 'application/ 3421 EmergencyCallData.SubscriberInfo+xml' 3423 This specification requests the registration of a new MIME media type 3424 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3425 RFC 7303 [RFC7303]. 3427 MIME media type name: application 3429 MIME media subtype name: EmergencyCallData.SubscriberInfo+xml 3431 Mandatory parameters: none 3433 Optional parameters: charset (indicates the character encoding of 3434 the contents) 3436 Encoding considerations: Uses XML, which can contain 8-bit 3437 characters, depending on the character encoding. See Section 3.2 3438 of RFC 7303 [RFC7303]. 3440 Security considerations: This content type is designed to carry 3441 owner/subscriber information, which is a sub-category of 3442 additional data about an emergency call. Since this data contains 3443 personal information, appropriate precautions need to be taken to 3444 limit unauthorized access, inappropriate disclosure to third 3445 parties, and eavesdropping of this information. Please refer to 3446 Section 9 and Section 10 for more information. 3448 Interoperability considerations: None 3450 Published specification: [TBD: This specification] 3452 Applications which use this media type: Emergency Services 3454 Additional information: 3456 Magic Number: None 3458 File Extension: .xml 3460 Macintosh file type code: 'TEXT' 3462 Person and email address for further information: Hannes 3463 Tschofenig, Hannes.Tschofenig@gmx.net 3465 Intended usage: LIMITED USE 3467 Author: This specification is a work item of the IETF ECRIT 3468 working group, with mailing list address . 3470 Change controller: The IESG 3472 11.4.5. MIME Content-type Registration for 'application/ 3473 EmergencyCallData.Comment+xml' 3475 This specification requests the registration of a new MIME media type 3476 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3477 RFC 7303 [RFC7303]. 3479 MIME media type name: application 3481 MIME media subtype name: EmergencyCallData.Comment+xml 3483 Mandatory parameters: none 3485 Optional parameters: charset (indicates the character encoding of 3486 the contents) 3488 Encoding considerations: Uses XML, which can contain 8-bit 3489 characters, depending on the character encoding. See Section 3.2 3490 of RFC 7303 [RFC7303]. 3492 Security considerations: This content type is designed to carry a 3493 comment, which is a sub-category of additional data about an 3494 emergency call. This data can contain personal information. 3495 Appropriate precautions are needed to limit unauthorized access, 3496 inappropriate disclosure to third parties, and eavesdropping of 3497 this information. Please refer to Section 9 and Section 10 for 3498 more information. 3500 Interoperability considerations: None 3502 Published specification: [TBD: This specification] 3504 Applications which use this media type: Emergency Services 3506 Additional information: 3508 Magic Number: None 3509 File Extension: .xml 3511 Macintosh file type code: 'TEXT' 3513 Person and email address for further information: Hannes 3514 Tschofenig, Hannes.Tschofenig@gmx.net 3516 Intended usage: LIMITED USE 3518 Author: This specification is a work item of the IETF ECRIT 3519 working group, with mailing list address . 3521 Change controller: The IESG 3523 11.5. URN Sub-Namespace Registration 3525 11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 3527 This section registers a new XML namespace, as per the guidelines in 3528 RFC 3688 [RFC3688]. 3530 URI: urn:ietf:params:xml:ns:EmergencyCallData 3532 Registrant Contact: IETF, ECRIT working group, , as 3533 delegated by the IESG . 3535 XML: 3537 BEGIN 3538 3539 3541 3542 3543 3545 Namespace for Additional Emergency Call Data 3546 3547 3548

Namespace for Additional Data related to an Emergency Call 3549

3550

See [TBD: This document].

3551 3552 3553 END 3555 11.5.2. Registration for 3556 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3558 This section registers a new XML namespace, as per the guidelines in 3559 RFC 3688 [RFC3688]. 3561 URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3563 Registrant Contact: IETF, ECRIT working group, , as 3564 delegated by the IESG . 3566 XML: 3568 BEGIN 3569 3570 3572 3573 3574 3576 Namespace for Additional Emergency Call Data: 3577 Data Provider Information 3578 3579 3580

Namespace for Additional Data related to an Emergency Call 3581

3582

Data Provider Information

3583

See [TBD: This document].

3584 3585 3586 END 3588 11.5.3. Registration for 3589 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3591 This section registers a new XML namespace, as per the guidelines in 3592 RFC 3688 [RFC3688]. 3594 URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3596 Registrant Contact: IETF, ECRIT working group, , as 3597 delegated by the IESG . 3599 XML: 3601 BEGIN 3602 3603 3605 3606 3607 3609 Namespace for Additional Emergency Call Data: 3610 Service Information 3611 3612 3613

Namespace for Additional Data related to an Emergency Call 3614

3615

Service Information

3616

See [TBD: This document].

3617 3618 3619 END 3621 11.5.4. Registration for 3622 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3624 This section registers a new XML namespace, as per the guidelines in 3625 RFC 3688 [RFC3688]. 3627 URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3629 Registrant Contact: IETF, ECRIT working group, , as 3630 delegated by the IESG . 3632 XML: 3634 BEGIN 3635 3636 3638 3639 3640 3642 Namespace for Additional Emergency Call Data: 3643 Device Information 3644 3645 3646

Namespace for Additional Data related to an Emergency Call 3647

3648

Device Information

3649

See [TBD: This document].

3650 3651 3652 END 3654 11.5.5. Registration for 3655 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3657 This section registers a new XML namespace, as per the guidelines in 3658 RFC 3688 [RFC3688]. 3660 URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3662 Registrant Contact: IETF, ECRIT working group, , as 3663 delegated by the IESG . 3665 XML: 3667 BEGIN 3668 3669 3671 3672 3673 3675 Namespace for Additional Emergency Call Data: 3676 Owner/Subscriber Information 3677 3678 3679

Namespace for Additional Data related to an Emergency Call 3680

3681

Owner/Subscriber Information

3682

See [TBD: This document].

3683 3684 3685 END 3687 11.5.6. Registration for 3688 urn:ietf:params:xml:ns:EmergencyCallData:Comment 3690 This section registers a new XML namespace, as per the guidelines in 3691 RFC 3688 [RFC3688]. 3693 URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment 3695 Registrant Contact: IETF, ECRIT working group, , as 3696 delegated by the IESG . 3698 XML: 3700 BEGIN 3701 3702 3704 3705 3706 3708 Namespace for Additional Emergency Call Data:Comment 3709 3710 3711 3712

Namespace for Additional Data related to an Emergency Call 3713

3714

Comment

3715

See [TBD: This document].

3716 3717 3718 END 3720 11.6. Schema Registrations 3722 This specification registers five schemas, as per the guidelines in 3723 RFC 3688 [RFC3688]. 3725 URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo 3727 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3728 delegated by the IESG (iesg@ietf.org). 3730 XML: The XML schema can be found in Figure 19. 3732 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3734 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3735 delegated by the IESG (iesg@ietf.org). 3737 XML: The XML schema can be found in Figure 20. 3739 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3741 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3742 delegated by the IESG (iesg@ietf.org). 3744 XML: The XML schema can be found in Figure 21. 3746 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3747 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3748 delegated by the IESG (iesg@ietf.org). 3750 XML: The XML schema can be found in Section 8.4. 3752 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3754 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3755 delegated by the IESG (iesg@ietf.org). 3757 XML: The XML schema can be found in Section 8.5. 3759 11.7. VCard Parameter Value Registration 3761 This document registers a new value in the vCARD Parameter Values 3762 registry as defined by [RFC6350] with the following template: 3764 Value: main 3766 Purpose: The main telephone number, typically of an enterprise, as 3767 opposed to a direct dial number of an individual employee 3769 Conformance: This value can be used with the "TYPE" parameter 3770 applied on the "TEL" property. 3772 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3773 00 3775 12. Acknowledgments 3777 This work was originally started in NENA and has benefited from a 3778 large number of participants in NENA standardization efforts, 3779 originally in the Long Term Definition Working Group, the Data 3780 Technical Committee and most recently the Additional Data working 3781 group. The authors are grateful for the initial work and extended 3782 comments provided by many NENA participants, including Delaine 3783 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3784 Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, 3785 and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank 3786 Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback 3787 regarding the vCard/xCard use in this specification. 3789 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3790 Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris 3791 Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, and Francis 3792 Dupont for their review comments. Alissa Cooper, Guy Caron, Ben 3793 Campbell, and Barry Leiba deserves special mention for their detailed 3794 and extensive review comments, which were very helpful and 3795 appreciated. 3797 13. References 3799 13.1. Normative References 3801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3802 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3803 RFC2119, March 1997, 3804 . 3806 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3807 Locators", RFC 2392, August 1998. 3809 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3810 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3811 and QSIG Objects", RFC 3204, December 2001. 3813 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3814 A., Peterson, J., Sparks, R., Handley, M., and E. 3815 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3816 June 2002. 3818 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3819 Extensions (MIME) Parameter", RFC 3459, January 2003. 3821 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3822 DOI 10.17487/RFC3688, January 2004, 3823 . 3825 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3826 3966, December 2004. 3828 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3829 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 3830 . 3832 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3833 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3834 DOI 10.17487/RFC5226, May 2008, 3835 . 3837 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3838 October 2008. 3840 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3841 Initiation Protocol (SIP)", RFC 5621, September 2009. 3843 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3844 Languages", BCP 47, RFC 5646, September 2009. 3846 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3847 August 2011. 3849 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3850 6351, August 2011. 3852 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3853 Specifications and Registration Procedures", BCP 13, RFC 3854 6838, DOI 10.17487/RFC6838, January 2013, 3855 . 3857 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 3858 DOI 10.17487/RFC7303, July 2014, 3859 . 3861 13.2. Informational References 3863 [ECRIT-WG-wiki] 3864 IETF, "ECRIT WG Wiki"", July 2015, 3865 . 3868 [I-D.gellens-slim-negotiating-human-language] 3869 Gellens, R., "Negotiating Human Language in Real-Time 3870 Communications", draft-gellens-slim-negotiating-human- 3871 language-02 (work in progress), July 2015. 3873 [IANA-XML-Schemas] 3874 IANA, "IANA XML Schemas"", July 2015, 3875 . 3878 [LERG] Telcordia Technologies, Inc., "Local Exchange Routing 3879 Guide (LERG)", ANI II Digits Definitions , June 2015. 3881 [LanguageTagRegistry] 3882 IANA, "Language Subtag Registry", Feb 2015, 3883 . 3886 [NANP] North American Numbering Plan Administration, "ANI II 3887 Digits Assignments", September 2015, 3888 . 3891 [NENA-02-010] 3892 National Emergency Number Association (NENA), "NENA 3893 Standard Data Formats for 9-1-1 Data Exchange & GIS 3894 Mapping", NENA Standard 02-010, December 2010, 3895 . 3897 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3898 Extensions to the Session Initiation Protocol (SIP) for 3899 Asserted Identity within Trusted Networks", RFC 3325, 3900 November 2002. 3902 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3903 "Indicating User Agent Capabilities in the Session 3904 Initiation Protocol (SIP)", RFC 3840, August 2004. 3906 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 3907 Emergency Context Resolution with Internet Technologies", 3908 RFC 5012, DOI 10.17487/RFC5012, January 2008, 3909 . 3911 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3912 Format for Presence Information Data Format Location 3913 Object (PIDF-LO)", RFC 5139, February 2008. 3915 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3916 Presence Information Data Format Location Object (PIDF-LO) 3917 Usage Clarification, Considerations, and Recommendations", 3918 RFC 5491, DOI 10.17487/RFC5491, March 2009, 3919 . 3921 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 3922 Framework", RFC 5582, September 2009. 3924 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3925 Thomson, "Dynamic Extensions to the Presence Information 3926 Data Format Location Object (PIDF-LO)", RFC 5962, DOI 3927 10.17487/RFC5962, September 2010, 3928 . 3930 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3931 5985, September 2010. 3933 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3934 "Framework for Emergency Calling Using Internet 3935 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 3936 2011, . 3938 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3939 of Named Entities (DANE) Transport Layer Security (TLS) 3940 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3941 2012, . 3943 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3944 R. George, "Specifying Civic Address Extensions in the 3945 Presence Information Data Format Location Object (PIDF- 3946 LO)", RFC 6848, January 2013. 3948 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3949 Communications Services in Support of Emergency Calling", 3950 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 3951 . 3953 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3954 Morris, J., Hansen, M., and R. Smith, "Privacy 3955 Considerations for Internet Protocols", RFC 6973, July 3956 2013. 3958 [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3959 Thomson, "Relative Location Representation", RFC 7035, 3960 October 2013. 3962 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3963 Patel, "Public Safety Answering Point (PSAP) Callback", 3964 RFC 7090, DOI 10.17487/RFC7090, April 2014, 3965 . 3967 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3968 "Recommendations for Secure Use of Transport Layer 3969 Security (TLS) and Datagram Transport Layer Security 3970 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3971 2015, . 3973 [nc911] North Carolina 911 Board, "North Carolina Telecommunicator 3974 Reference", January 2009, . 3977 13.3. URIs 3979 [1] http://www.nena.org/?page=cid2014 3981 [2] http://www.nena.org/?page=CompanyID 3983 Appendix A. XML Schema for vCard/xCard 3985 This section contains the vCard/xCard XML schema version of the Relax 3986 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3987 XML schemas defined in this document. The schema in RFC 6351 3988 [RFC6351] is the normative source and this section is informative 3989 only. 3991 3992 3996 4002 4003 4004 vCard Format Specification 4005 4006 4007 4008 4009 4010 4011 4012 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4027 4028 4029 4032 4033 4034 4035 4036 4038 4039 4040 4042 4043 4044 4045 4046 4048 4049 4050 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4094 4095 4096 4097 4101 4102 4103 Section 5: Parameters 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5026 5027 5028 5029 5030 5031 5032 5034 5035 5036 5037 5038 5039 5040 5042 5043 5044 5046 5048 5049 5050 5052 5053 5054 5055 5057 Appendix B. XML Validation 5059 This document defines a number of XML schemas and contains various 5060 examples. Extracting the XML and validating the examples against the 5061 schemas can be challenging, especially due to the formatting 5062 limitations introduced by IETF RFCs. For those readers who copy the 5063 XML schemas and examples directly from this document, please consider 5064 that errors might be introduced due to line breaks and extra 5065 whitespaces in the regular expressions contained in the vcard schema 5066 in Appendix A. To validate the PIDF-LO from Figure 18 it is also 5067 necessary to consult the referenced RFCs and copy the schemas 5068 necessary for successful validation. 5070 The XML schemas found in this document include a 'SchemaLocation' 5071 attribute. Depending on the location of the downloaded schema files 5072 you may need to adjust this schema location or configure your XML 5073 editor to point to the location. 5075 For convenience of readers, the schemas are available at http://ip- 5076 emergency.net/additional-data.zip and the XML examples are available 5077 at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki]. 5079 Note to RFC Editor: After IANA has published the schemas, the above 5080 link to the schemas should be replaced with [IANA-XML-Schemas]. 5082 Authors' Addresses 5083 Randall Gellens 5084 Qualcomm Technologies, Inc. 5085 5775 Morehouse Drive 5086 San Diego, CA 92121 5087 US 5089 Email: rg+ietf@randy.pensive.org 5091 Brian Rosen 5092 NeuStar 5093 470 Conrad Dr. 5094 Mars, PA 16046 5095 US 5097 Phone: +1 724 382 1051 5098 Email: br@brianrosen.net 5100 Hannes Tschofenig 5101 Hall in Tirol 6060 5102 Austria 5104 Email: Hannes.tschofenig@gmx.net 5105 URI: http://www.tschofenig.priv.at 5107 Roger Marshall 5108 TeleCommunication Systems, Inc. 5109 2401 Elliott Avenue 5110 Seattle, WA 98121 5111 US 5113 Phone: +1 206 792 2424 5114 Email: rmarshall@telecomsys.com 5115 URI: http://www.telecomsys.com 5117 James Winterbottom 5118 AU 5120 Email: a.james.winterbottom@gmail.com