idnits 2.17.1 draft-ietf-ecrit-additional-data-35.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 (September 16, 2015) is 3143 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 3957 -- Looks like a reference, but probably isn't: '2' on line 3959 == Missing Reference: 'This RFC' is mentioned on line 3217, 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: March 19, 2016 H. Tschofenig 8 R. Marshall 9 TeleCommunication Systems, Inc. 10 J. Winterbottom 12 September 16, 2015 14 Additional Data Related to an Emergency Call 15 draft-ietf-ecrit-additional-data-35.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 March 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 6.3. Transmitting Blocks by Value using the 114 Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39 116 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 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 . . . . . . . . . . . . 67 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 . . . . . . . . . . . . 69 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 . . . . . . 71 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' . . . 74 147 11.4.4. MIME Content-type Registration for 148 'application/EmergencyCallData.SubscriberInfo+xml' . 75 149 11.4.5. MIME Content-type Registration for 150 'application/EmergencyCallData.Comment+xml' . . . . 76 151 11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 77 152 11.5.1. Registration for 153 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 77 154 11.5.2. Registration for 155 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf 156 o . . . . . . . . . . . . . . . . . . . . . . . . . 78 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 an IP- 189 based emergency call, as described in [RFC6443] and [RFC6881], in 190 order to carry additional data which is useful to an entity or call 191 taker handling the call. This data is "additional" to the basic 192 information found in the emergency call signaling used. The intent 193 is that every emergency call carry as much as possible of the 194 information described here using the mechanisms described here. 196 This document defines three categories of this additional data that 197 can be transmitted with an emergency call: 199 Data Associated with a Location: Primary location data is conveyed 200 in the Presence Information Data Format Location Object (PIDF-LO) 201 data structure as defined in RFC 4119 [RFC4119] and extended by 202 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 203 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 204 geodetic location information), and [RFC7035] (for relative 205 location). This primary location data identifies the location or 206 estimated location of the caller. However, there might exist 207 additional, secondary data which is specific to the location, such 208 as floor plans, tenant and building owner contact data, heating, 209 ventilation and air conditioning (HVAC) status, etc. Such 210 secondary location data is not included in the location data 211 structure but can be transmitted using the mechanisms defined in 212 this document. Although this document does not define any 213 structures for such data, future documents can do so following the 214 procedures defined here. 216 Data Associated with a Call: While some information is carried in 217 the call setup procedure itself (as part of the SIP headers as 218 well as in the body of the SIP message), there is additional data 219 known by the device making the call, the access network to which 220 the device is connected, and service providers along the path of 221 the call. This information includes service provider contact 222 information, subscriber identity and contact information, the type 223 of service the service provider and the access network provide, 224 what type of device is being used, etc. Some data is broadly 225 applicable, while other data is dependent on the type of device or 226 service. For example, a medical monitoring device might have 227 sensor data. The data structures defined in this document (Data 228 Provider Information, Device Information, and Owner/Subscriber 229 Information) all fall into the category of "Data Associated with a 230 Call". Note that the Owner/Subscriber Information includes the 231 subscriber's vCard, which might contain personal information such 232 as birthday, anniversary, etc., but the data block itself is still 233 considered to be about the call, not the caller. 235 Data Associated with a Caller: This is personal data about a caller, 236 such as medical information and emergency contact data. Although 237 this document does not define any structures within this category, 238 future documents can do so following the procedures defined here. 240 While this document defines data structures only within the category 241 of Data Associated with a Call, by establishing the overall framework 242 of Additional Data, along with general mechanisms for transport of 243 such data, extension points and procedures for future extensions, it 244 minimizes the work needed to carry data in the other categories. 245 Other specifications can make use of the facilities provided here. 247 For interoperability, there needs to be a common way for the 248 information conveyed to a PSAP to be encoded and identified. 249 Identification allows emergency services authorities to know during 250 call processing which types of data are present and to determine if 251 they wish to access it. A common encoding allows the data to be 252 successfully accessed. 254 This document defines an extensible set of data structures, and 255 mechanisms to transmit this data either by value or by reference, 256 either in the Session Initiation Protocol (SIP) call signaling or in 257 the Presence Information Data Format Location Object (PIDF-LO). The 258 data structures are usable by other communication systems and 259 transports as well. The data structures are defined in Section 4, 260 and the transport mechanisms (using SIP and HTTPS) are defined in 261 Section 6. 263 Each data structure described in this document is encoded as a 264 "block" of information. Each block is an XML structure with an 265 associated Multipurpose Internet Mail Extensions (MIME) media type 266 for identification within transport such as SIP and HTTPS. The set 267 of blocks is extensible. Registries are defined to identify the 268 block types that can be used and to allow blocks to be included in 269 emergency call signaling. 271 Much of the information supplied by service providers and devices is 272 private and confidential; service providers and devices generally go 273 to lengths to protect this information; disclosing it in the context 274 of an emergency call is a trade-off to protect the greater interest 275 of the customer in an emergency. 277 2. Terminology 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 281 document are to be interpreted as described in RFC 2119 [RFC2119]. 283 This document also uses terminology from [RFC5012]. We use the term 284 service provider to refer to an Application Service Provider (ASP). 285 A Voice Service Provider (VSP) is a special type of ASP. With the 286 term "Access Network Provider" we refer to the Internet Access 287 Provider (IAP) and the Internet Service Provider (ISP) without 288 further distinguishing these two entities, since the difference 289 between the two is not relevant for this document. Note that the 290 roles of ASP and access network provider might be provided by a 291 single company. An Emergency Services Provider is an entity directly 292 involved in providing emergency services. This includes PSAPs, 293 dispatch, police, fire, emergency medical, other responders, and 294 other similar agencies. 296 Within each data block definition (see Section 4), the values for the 297 "Use:" label are specified as one of the following: 299 'Required': means it MUST be present in the data structure. 301 'Conditional': means it MUST be present if the specified 302 condition(s) is met. It MAY be present if the condition(s) is not 303 met. 305 'Optional': means it MAY be present. 307 vCard [RFC6350] is a data format for representing and exchanging a 308 variety of information about individuals and other entities. For 309 applications that use XML, the format defined in vCard is not 310 immediately applicable. For this reason, an XML-based encoding of 311 the information elements defined in the vCard specification has been 312 defined and the name of that specification is xCard [RFC6351]. Since 313 the term vCard is more familiar to most readers, we use the terms 314 xCard and vCard interchangeably. 316 3. Document Scope 318 The scope of this document is explicitly limited to emergency calls. 319 The data structures defined here are not appropriate to be conveyed 320 with non-emergency calls because they carry sensitive and private 321 data. However, in certain private-use situations (such as 322 communications between a telematics or other service provider and 323 dedicated equipment such as in a vehicle) where the endpoints have a 324 preexisting relationship and privacy issues are addressed within the 325 relationship, the mechanisms and data structures defined here can be 326 used. 328 4. Data Structures 330 This section defines the following five data structures, each as a 331 data block. For each block we define the MIME media type, and the 332 XML encoding. The five data structures are: 334 'Data Provider': This block supplies name and contact information 335 for the entity that created the data. Section 4.1 provides the 336 details. 338 'Service Information': This block supplies information about the 339 service. The description can be found in Section 4.2. 341 'Device Information': This block supplies information about the 342 device placing the call. Device information can be found in 343 Section 4.3. 345 'Owner/Subscriber': This block supplies information about the owner 346 of the device or about the subscriber. Details can be found in 347 Section 4.4. 349 'Comment': This block provides a way to supply free form human 350 readable text to the PSAP or emergency responders. This simple 351 structure is defined in Section 4.5. 353 Each block contains a mandatory element. The 354 purpose of the element is to associate all 355 blocks added by the same data provider as a unit. The 356 element associates the data provider block to 357 each of the other blocks added as a unit. Consequently, when a data 358 provider adds additional data to an emergency call (such as device 359 information) it MUST add information about itself (via the data 360 provider block) and the blocks added contain the same value in the 361 element. All blocks added by a single entity 362 at the same time MUST have the same value. 363 (In certain situations, the same provider might process a call more 364 than once, likely in different roles, and in such cases, each time it 365 processes the call, it adds a new set of bocks with a new 366 value.) The value of the 367 element has the same syntax and properties 368 (specifically, world-uniqueness) as the value of the "Message-ID" 369 message body header field specified in RFC 5322 [RFC5322] except that 370 the element is not enclosed in brackets (the 371 "<" and ">" symbols are omitted). In other words, the value of a 372 element is syntactically a msg-id as 373 specified in RFC 5322 [RFC5322]. 375 Each block is added to the Additional Data Blocks Registry created in 376 Section 11.1.9 and categorized as providing data about the caller. 377 New blocks added to the registry in the future MUST also be 378 categorized per the description of the three categories in Section 1. 379 See Section 5 and Section 5.1 for additional considerations when 380 adding new blocks or types of data. 382 Note that the xCard format is re-used in some of the data structures 383 to provide contact information. In an xCard there is no way to 384 specify a "main" telephone number (that is, a primary or main contact 385 number, typically of an enterprise, as opposed to a direct dial 386 number of an individual). These numbers are useful to emergency 387 responders who are called to a large enterprise. This document adds 388 a new parameter value called "main-number" to the "TYPE" parameter of 389 the "tel" property. It can be used in any xCard in an emergency call 390 additional data block. 392 4.1. Data Provider Information 394 This block is intended to be supplied by any service provider in the 395 path of the call, or the access network provider, and the device. It 396 includes identification and contact information. This block MUST be 397 supplied by any entity that provides any other block; it SHOULD be 398 supplied by every service provider in the call path and by the access 399 network provider if those entities do not add any other blocks. 400 Devices SHOULD use this block to provide identifying information. 401 The MIME media type is "application/ 402 EmergencyCallData.ProviderInfo+xml". An access network provider 403 SHOULD provide this block either by value or by reference in the 404 element of a PIDF-LO 406 4.1.1. Data Provider String 408 Data Element: Data Provider String 410 Use: Conditional. Optional for blocks supplied by the originating 411 device, mandatory otherwise. 413 XML Element: 415 Description: This is a plain text string suitable for displaying the 416 name of the service provider that supplied the data structure. If 417 the device creates the structure, it SHOULD use the value of the 418 contact header field in the SIP INVITE. 420 Reason for Need: Inform the call taker of the identity of the entity 421 providing the data. 423 How Used by Call Taker: Allows the call taker to interpret the data 424 in this structure. The source of the information often influences 425 how the information is used, believed or verified. 427 4.1.2. Data Provider ID 429 Data Element: Data Provider ID 431 Use: Conditional. Optional for blocks supplied by the originating 432 device, mandatory otherwise. This data MUST be provided by all 433 entities other than the originating device in order to uniquely 434 identify the service provider or access provider. 436 XML Element: 438 Description: A jurisdiction-specific code for, or the fully- 439 qualified domain name of, the access network provider or service 440 provider shown in the element that created the 441 structure. NOTE: The value SHOULD be assigned by an organization 442 appropriate for the jurisdiction. In the U.S., if the provider is 443 registered with NENA, the provider's NENA Company ID MUST appear 444 here. Additional information can be found at NENA Company 445 Identifier Program [1] or NENA Company ID [2]. The NENA Company 446 ID MUST be in the form of a URI in the following format: 447 urn:nena:companyid:. If the organization does 448 not have an identifier registered with a jurisdiction-specific 449 emergency services registrar (such as NENA), then the value MAY be 450 the fully-qualified domain name of the service provider or access 451 provider. The device MAY use its IP address or fully-qualified 452 domain name (and set the "Data Provider ID Series" element to 453 "domain"). 455 Reason for Need: Inform the call taker of the identity of the entity 456 providing the data. 458 How Used by Call Taker: Where jurisdictions have lists of providers 459 the Data Provider ID provides useful information about the data 460 source. The Data Provider ID uniquely identifies the source of 461 the data, which might be needed especially during unusual 462 circumstances and for routine logging. 464 4.1.3. Data Provider ID Series 466 Data Element: Data Provider ID Series 468 Use: Conditional. Optional for blocks supplied by the originating 469 device, mandatory otherwise. 471 XML Element: 472 Description: Identifies the issuer of the . The 473 Provider ID Series Registry created in Section 11.1.1 initially 474 contains the entries shown in Figure 1. 476 Reason for Need: Identifies how to interpret the Data Provider ID. 477 The combination of ProviderIDSeries and ProviderID MUST be 478 globally unique. 480 How Used by Call Taker: Determines which provider ID registry to 481 consult for more information 483 +-----------+--------------------------+----------------------+ 484 | Name | Source | URL | 485 +-----------+--------------------------+----------------------+ 486 | NENA | National Emergency | http://www.nena.org | 487 | | Number Association | | 488 | EENA | European Emergency | http://www.eena.org | 489 | | Number Association | | 490 | domain | (The ID is a fully- | (not applicable) | 491 | | qualified domain name) | | 492 +-----------+--------------------------+----------------------+ 494 Figure 1: Provider ID Series Registry 496 4.1.4. Type of Data Provider 498 Data Element: Type of Data Provider 500 Use: Required. 502 XML Element: 504 Description: Identifies the type of data provider supplying the 505 data. The registry containing all valid values is created in 506 Section 11.1.5 and the initial set of values is shown in Figure 2. 508 Reason for Need: Identifies the category of data provider. 510 How Used by Call Taker: This information can be helpful when 511 deciding whom to contact when further information is needed. 513 +------------------------------+------------------------------------+ 514 | Token | Description | 515 +------------------------------+------------------------------------+ 516 |Client | Originating client/device | 517 |Access Network Provider | Access network service provider | 518 |Telecom Provider | Telecom service provider (including| 519 | | native and over-the-top VoIP | 520 | | services) | 521 |Telematics Provider | A sensor-based service provider, | 522 | | especially vehicle-based | 523 |Language Translation Provider | A spoken language translation | 524 | | service | 525 |Emergency Service Provider | An emergency service provider | 526 | | conveying information to another| 527 | | emergency service provider. | 528 |Emergency Modality Translation| An emergency-call-specific | 529 | | modality translation service | 530 | | e.g., for sign language | 531 |Relay Provider | A interpretation service, e.g., | 532 | | video relay for sign language | 533 | | interpreting | 534 |Other | Any other type of service provider | 535 +------------------------------+------------------------------------+ 537 Figure 2: Type of Data Provider Registry 539 4.1.5. Data Provider Contact URI 541 Data Element: Data Provider Contact URI 543 Use: Required 545 XML Element: 547 Description: When provided by a service provider or an access 548 network provider, this information MUST be a URI to a 24/7 support 549 organization tasked to provide PSAP support for this emergency 550 call. When provided by a device, this MUST be the contact 551 information of the user or owner of the device. (Ideally, this is 552 the contact information of the device user, but when the owner and 553 user are separate (e.g., the device owner is an organization), 554 this MAY be the contact information of the owner.) The Data 555 Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format 556 fully specified with country code. If a TEL URI is not available, 557 a generic SIP URI is acceptable. Note that this contact 558 information is not used by PSAPs for callbacks (a call from a PSAP 559 directly related to a recently terminated emergency call, placed 560 by the PSAP using a SIP Priority header field set to "psap- 561 callback", as described in [RFC7090]). 563 Reason for Need: Additional data providers might need to be 564 contacted in error cases or other unusual circumstances. 566 How Used by Call Taker: To contact the supplier of the additional 567 data for assistance in handling the call. 569 4.1.6. Data Provider Languages(s) Supported 571 Data Element: Data Provider Language(s) supported 573 Use: Required. 575 XML Element: 577 Description: This field encodes the language used by the entity at 578 the Data Provider Contact URI. The content of this field consists 579 of a single token from the language tags registry, which can be 580 found at [LanguageTagRegistry], and is defined in [RFC5646]. 581 Multiple instances of this element MAY occur but the order is 582 significant and the preferred language SHOULD appear first. The 583 content MUST reflect the languages supported at the contact URI. 585 (Note that this field informs the PSAP of the language(s) used by 586 the data provider. If the PSAP needs to contact the data 587 provider, it can be helpful to know in advance the language(s) 588 used by the data provider. If the PSAP uses a communication 589 protocol to reach the data provider, that protocol might have 590 language facilities of its own (such as the 'language' media 591 feature tag, defined in RFC 3840 [RFC3840] and the more extensive 592 language negotiation mechanism proposed with 593 [I-D.gellens-slim-negotiating-human-language]), and if so, those 594 are independent of this field.) 596 Reason for Need: This information indicates if the emergency service 597 authority can directly communicate with the service provider or if 598 an interpreter will be needed. 600 How Used by Call Taker: If the call taker cannot speak any language 601 supported by the service provider, a translation service will need 602 to be added to the conversation. Alternatively, other persons at 603 the PSAP, besides the call taker, might be consulted for help 604 (depending on the urgency and the type of interaction). 606 4.1.7. xCard of Data Provider 608 Data Element: xCard of Data Provider 610 Use: Optional 612 XML Element: 614 Description: Per [RFC6351] the xCard structure is represented within 615 a element. Although multiple elements can be 616 contained in a structure only one element SHOULD be 617 provided. If more than one appears, the first SHOULD be used. 618 There are many fields in the xCard and the creator of the data 619 structure is encouraged to provide all available information. N, 620 ORG, ADR, TEL, EMAIL are suggested at a minimum. N SHOULD contain 621 the name of the support group or device owner as appropriate. If 622 more than one TEL property is provided, a parameter from the vCard 623 Property Value registry SHOULD be specified for each TEL. For 624 encoding of the vCard this specification uses the XML-based 625 encoding specified in [RFC6351], referred to in this document as 626 "xCard". 628 Reason for Need: Information needed to determine additional contact 629 information. 631 How Used by Call Taker: Assists the call taker by providing 632 additional contact information aside from what is included in the 633 SIP INVITE or the PIDF-LO. 635 4.1.8. Subcontractor Principal 637 When the entity providing the data is a subcontractor, the Data 638 Provider Type is set to that of the primary service provider and this 639 entry is supplied to provide information regarding the subcontracting 640 entity. 642 Data Element: Subcontractor Principal 644 Use: Conditional. This data is required if the entity providing the 645 data is a subcontractor. 647 XML Element: 649 Description: Some providers outsource their obligations to handle 650 aspects of emergency services to specialized providers. If the 651 data provider is a subcontractor to another provider this element 652 contains the DataProviderString of the service provider to 653 indicate which provider the subcontractor is working for. 655 Reason for Need: Identify the entity the subcontractor works for. 657 How Used by Call Taker: Allows the call taker to understand what the 658 relationship between data providers and the service providers in 659 the path of the call are. 661 4.1.9. Subcontractor Priority 663 Data Element: Subcontractor Priority 665 Use: Conditional. This data is required if the entity providing the 666 data is a subcontractor. 668 XML Element: 670 Description: If the subcontractor is supposed to be contacted first 671 then this element MUST have the value "sub". If the provider the 672 subcontractor is working for is supposed to be contacted first 673 then this element MUST have the value "main". 675 Reason for Need: Inform the call taker whom to contact first, if 676 support is needed. 678 How Used by Call Taker: To decide which entity to contact first if 679 assistance is needed. 681 4.1.10. ProviderInfo Example 683 684 686 string0987654321@example.org 687 688 Example VoIP Provider 689 690 urn:nena:companyid:ID123 691 NENA 692 Telecom Provider 693 tel:+1-201-555-0123 694 en 695 697 698 Hannes Tschofenig 699 700 Hannes 701 Tschofenig 702 703 704 Dipl. Ing. 705 706 --0203 707 708 20090808T1430-0500 709 710 M 711 712 1 713 714 de 715 716 717 2 718 719 en 720 721 722 work 723 724 Example VoIP Provider 725 726 727 728 work 729 733 734 735 736 Linnoitustie 6 737 Espoo 738 Uusimaa 739 02600 740 Finland 741 742 743 744 745 work 746 voice 747 748 749 tel:+358 50 4871445 751 752 753 754 755 work 756 main-number 757 voice 758 759 760 tel:+358 50 5050505 761 762 763 work 764 765 hannes.tschofenig@nsn.com 766 767 768 work 769 770 geo:60.210796,24.812924 771 772 773 home 774 775 776 http://www.tschofenig.priv.at/key.asc 777 778 779 Finland/Helsinki 780 781 home 782 783 http://www.tschofenig.priv.at 784 785 786 787 789 Figure 3: EmergencyCallData.ProviderInfo Example. 791 4.2. Service Information 793 This block describes the service that the service provider provides 794 to the caller. It SHOULD be included by all service providers in the 795 path of the call. The mime media type is "application/ 796 EmergencyCallData.ServiceInfo+xml". 798 4.2.1. Service Environment 800 Data Element: Service Environment 802 Use: Conditional: Required unless the 'ServiceType' value is 803 'wireless'. 805 XML Element: 807 Description: This element indicates whether a call is from a 808 business or residence. Currently, the only valid entries are 809 'Business', 'Residence', and 'unknown', as shown in Figure 4. New 810 values can be defined via the registry created in Section 11.1.2. 812 Reason for Need: To provide context and a hint when determining 813 equipment and manpower requirements. 815 How Used by Call Taker: Information can be used to provide context 816 and a hint to assist in determining equipment and manpower 817 requirements for emergency responders. This is non-authoritative: 818 There are situations where the service provider does not know the 819 type of service (e.g., anonymous pre-paid service). The type of 820 service does not necessarily reflect the nature of the premises 821 (e.g., a business line installed in a residence, or cellular 822 service). The registry does not contain all possible values for 823 all situations. Hence, this is at best advisory information, but 824 since it mimics a similar capability in some current emergency 825 calling systems (e.g., a field in the Automatic Location 826 Information (ALI) information used with legacy North American 827 wireline systems), it is known to be valuable to PSAPs. The 828 service provider uses its best information (such as a rate plan, 829 facilities used to deliver service or service description) to 830 determine the information and is not responsible for determining 831 the actual characteristics of the location from which the call 832 originated. Because the usefulness is unknown (and less clear) 833 for cellular, this element is OPTIONAL for commercial mobile radio 834 services (e.g., cellular) and REQUIRED otherwise. 836 +-----------+--------------------------+ 837 | Token | Description | 838 +-----------+--------------------------+ 839 | Business | Business service | 840 | Residence | Residential service | 841 | unknown | Type of service unknown | 842 | | (e.g., anonymous pre- | 843 | | paid service) | 844 +-----------+--------------------------+ 846 Figure 4: Service Environment Registry 848 4.2.2. Service Type 850 Data Element: Service Delivered by Provider to End User 852 Use: Required 854 XML Element: 856 Description: This defines the type of service over which the call is 857 placed (similar to the Class of Service delivered with legacy 858 emergency calls in some some regions). The implied mobility of 859 this service cannot be relied upon. A registry is created in 860 Section 11.1.3. The initial set of values is shown in Figure 5. 861 More than one value MAY be returned. For example, a VoIP inmate 862 telephone service is a reasonable combination. 864 Reason for Need: Knowing the type of service can assist the PSAP in 865 handling of the call. 867 How Used by Call Taker: Call takers often use this information to 868 determine what kinds of questions to ask callers, and how much to 869 rely on supportive information. As the information is not always 870 available, and the registry is not all-encompassing, this is at 871 best advisory information, but since it mimics a similar 872 capability in some legacy emergency calling systems, it is known 873 to be valuable. 875 +--------------+----------------------------------------+ 876 | Name | Description | 877 +--------------+----------------------------------------+ 878 | wireless | Wireless Telephone Service: Includes | 879 | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but | 880 | | not satellite) | 881 | coin | Fixed public pay/coin telephones: Any | 882 | | coin or credit card operated device | 883 | one-way | One way outbound service | 884 | temp | Soft dial tone/quick service/warm | 885 | | disconnect/suspended | 886 | MLTS-hosted | Hosted multi-line telephone system | 887 | | such as Centrex | 888 | MLTS-local | Local multi-line telephone system, | 889 | | includes all PBX, key systems, | 890 | | Shared Tenant Service | 891 | sensor- | These are devices that generate DATA | 892 | unattended | ONLY. This is a one-way information | 893 | | transmit without interactive media | 894 | sensor- | Devices that are supported by a | 895 | attended | monitoring service provider or that | 896 | | are capable of supporting interactive| 897 | | media | 898 | POTS | Wireline: Plain Old Telephone Service | 899 | OTT | An over-the-top service that provides | 900 | | communication over arbitrary Internet| 901 | | access (fixed, nomadic, mobile) | 902 | digital | Wireline non-OTT digital phone service | 903 | OPX | Off-premise extension | 904 | relay | A service where a human third-party | 905 | | agent provides additional assistance | 906 | | This includes sign language relay/ | 907 | | interpretation, telematics services | 908 | | that provide a human on the call, | 909 | | and similar services | 910 +--------------+----------------------------------------+ 912 Figure 5: Service Delivered by Provider to End User Registry 914 The initial set of values has been collected from sources of 915 currently-used systems, including [NENA-02-010], [nc911], [NANP], and 916 [LERG]. 918 4.2.3. Service Mobility Environment 920 Data Element: Service Mobility Environment 922 Use: Required 923 XML Element: 925 Description: This provides the service provider's view of the 926 mobility of the caller's device. As the service provider might 927 not know the characteristics of the actual device or access 928 network used, the value should be treated as advisory and not be 929 relied upon. A registry is created in Section 11.1.4 with the 930 initial valid entries shown in Figure 6. 932 Reason for Need: Knowing the service provider's belief of mobility 933 can assist the PSAP with the handling of the call. 935 How Used by Call Taker: To determine whether to assume the location 936 of the caller might change. 938 +-----------+----------------------------+ 939 | Token | Description | 940 +-----------+----------------------------+ 941 | Mobile | The device is able to move | 942 | | at any time | 943 | Fixed | The device is not expected | 944 | | to move unless the | 945 | | service is relocated | 946 | Nomadic | The device is not expected | 947 | | to change its point of | 948 | | attachment while on a | 949 | | call | 950 | Unknown | No information is known | 951 | | about the service | 952 | | mobility environment for | 953 | | the device | 954 +-----------+----------------------------+ 956 Figure 6: Service Environment Registry 958 4.2.4. EmergencyCallData.ServiceInfo Example 959 960 962 2468.IBOC.MLTS.1359@example.org 963 964 Business 965 MLTS-hosted 966 Fixed 967 969 Figure 7: EmergencyCallData.ServiceInfo Example. 971 4.3. Device Information 973 This block provides information about the device used to place the 974 call. It SHOULD be provided by any service provider that knows what 975 device is being used, and by the device itself. The mime media type 976 is "application/EmergencyCallData.DeviceInfo+xml". 978 4.3.1. Device Classification 980 Data Element: Device Classification 982 Use: Optional 984 XML Element: 986 Description: This data element defines the kind of device making the 987 emergency call. If the device provides the data structure, the 988 device information SHOULD be provided. If the service provider 989 provides the structure and it knows what the device is, the 990 service provider SHOULD provide the device information. Often the 991 carrier does not know what the device is. It is possible to 992 receive two Device Information blocks, one provided by the device 993 and one from the service provider. This information describes the 994 device, not how it is being used. This data element defines the 995 kind of device making the emergency call. A registry is created 996 in Section 11.1.6 with the initial set of values as shown in 997 Figure 8. 999 Reason for Need: The device classification implies the capability of 1000 the calling device and assists in identifying the meaning of the 1001 emergency call location information that is being presented. For 1002 example, does the device require human intervention to initiate a 1003 call or is this call the result of programmed instructions? Does 1004 the calling device have the ability to update location or 1005 condition changes? Is this device interactive or a one-way 1006 reporting device? 1008 How Used by Call Taker: Can provide the call taker context regarding 1009 the caller, the capabilities of the calling device or the 1010 environment in which the device is being used, and can assist in 1011 understanding the location information and capabilities of the 1012 calling device. For example, a cordless handset might be outside 1013 or next door. 1015 +---------------+----------------------------------------+ 1016 | Token | Description | 1017 +---------------+----------------------------------------+ 1018 |cordless | Cordless handset | 1019 |fixed | Fixed phone | 1020 |satellite | Satellite phone | 1021 |sensor-fixed | Fixed (non mobile) sensor/alarm device | 1022 |desktop | Soft client on desktop PC | 1023 |laptop | Soft client on laptop type device | 1024 |tablet | Soft client on tablet type device | 1025 |alarm-monitored| Alarm system | 1026 |sensor-mobile | Mobile sensor device | 1027 |aircraft | Aircraft telematics device | 1028 |automobile | Automobile/cycle/off-road telematics | 1029 |truck | Truck/construction telematics | 1030 |farm | Farm equipment telematics | 1031 |marine | Marine telematics | 1032 |personal | Personal telematics device | 1033 |feature-phone | Feature- (not smart-) cellular phone | 1034 |smart-phone | Smart-phone cellular phone (native) | 1035 |smart-phone-app| Soft client app on smart-phone | 1036 |unknown-device | Soft client on unknown device type | 1037 |game | Gaming console | 1038 |text-only | Other text device | 1039 |NA | Not Available | 1040 +---------------+----------------------------------------+ 1042 Figure 8: Device Classification Registry Initial Values 1044 4.3.2. Device Manufacturer 1046 Data Element: Device Manufacturer 1048 Use: Optional 1050 XML Element: 1052 Description: The plain language name of the manufacturer of the 1053 device. 1055 Reason for Need: Used by PSAP management for post-mortem 1056 investigation/resolution. 1058 How Used by Call Taker: Probably not used by the calltaker, but by 1059 PSAP management. 1061 4.3.3. Device Model Number 1063 Data Element: Device Model Number 1065 Use: Optional 1067 XML Element: 1069 Description: Model number of the device. 1071 Reason for Need: Used by PSAP management for after-action 1072 investigation/resolution. 1074 How Used by Call Taker: Probably not used by the calltaker, but by 1075 PSAP management. 1077 4.3.4. Unique Device Identifier 1079 Data Element: Unique Device Identifier 1081 Use: Optional 1083 XML Element: 1085 XML Attribute: 1087 Description: A string that identifies the specific device (or the 1088 device's current SIM) making the call or creating an event. Note 1089 that more than one can be present, to supply more 1090 than one of the identifying values. 1092 The attribute identifies the type of device 1093 identifier. A registry is created in Section 11.1.7 with an 1094 initial set of values shown in Figure 9. 1096 Reason for Need: Uniquely identifies the device (or, in the case of 1097 IMSI, a SIM), independent of any signaling identifiers present in 1098 the call signaling stream. 1100 How Used by Call Taker: Probably not used by the call taker; might 1101 be used by PSAP management during an investigation. (For example, 1102 if a PSAP experiences repeated false/accidental calls and there is 1103 no callback number or it isn't usable, the PSAP might need to try 1104 and track down the device using various means (e.g., contacting 1105 service providers in the area). In the case of handsets without 1106 current service, it might be possible to determine who last had 1107 service. Another example might be a disconnected call where the 1108 call taker believes there is a need for assistance but was not 1109 able to obtain a location or other information). 1111 Example: 12345 1113 +--------+------------------------------------------+ 1114 | Token | Description | 1115 +--------+------------------------------------------+ 1116 | MEID | Mobile Equipment Identifier (CDMA) | 1117 | ESN | Electronic Serial Number (GSM) | 1118 | MAC | Media Access Control Address (IEEE) | 1119 | WiMAX | Device Certificate Unique ID | 1120 | IMEI | International Mobile Equipment ID (GSM) | 1121 | IMSI | International Mobile Subscriber ID (GSM) | 1122 | UDI | Unique Device Identifier | 1123 | RFID | Radio Frequency Identification | 1124 | SN | Manufacturer Serial Number | 1125 +--------+------------------------------------------+ 1127 Figure 9: Registry of Device Identifier Types 1129 4.3.5. Device/Service-Specific Additional Data Structure 1131 Data Element: Device/service-specific additional data structure 1133 Use: Optional 1135 XML Element: 1137 Description: A URI representing additional data whose schema is 1138 specific to the device or service which created it. (For example, 1139 a medical device or medical device monitoring service might have a 1140 defined set of medical data). The URI, when dereferenced, MUST 1141 yield a data structure defined by the Device/service-specific 1142 additional data type value. Different data can be created by each 1143 classification; e.g., a medical device created data set. 1145 Reason for Need: Provides device/service-specific data that can be 1146 used by the call taker and/or responders. 1148 How Used by Call Taker: Provide information to guide call takers to 1149 select appropriate responders, give appropriate pre-arrival 1150 instructions to callers, and advise responders of what to be 1151 prepared for. May be used by responders to guide assistance 1152 provided. 1154 4.3.6. Device/Service-Specific Additional Data Structure Type 1156 Data Element: Type of device/service-specific additional data 1157 structure 1159 Use: Conditional: MUST be provided when a device/service-specific- 1160 additional URI is provided 1162 XML Element: 1164 Description: A value from the registry defined in Section 11.1.8 to 1165 describe the type of data located at the device/service-specific 1166 additional data structure. The initial values shown in Figure 10 1167 currently only include IEEE 1512, which is the USDoT model for 1168 traffic incidents. 1170 Reason for Need: This data element allows identification of 1171 externally defined schemas, which might have additional data that 1172 can assist in emergency response. 1174 How Used by Call Taker: This data element allows the end user (call 1175 taker or first responder) to know what type of additional data is 1176 available to aid in providing the needed emergency services. 1178 Note: This mechanism is not appropriate for information specific to 1179 a location or a caller (person). 1181 +----------+----------------------------+--------------------------------+ 1182 | Token | Description | Specification | 1183 +----------+----------------------------+--------------------------------+ 1184 | IEEE1512 | Common Incident Management |IEEE 1512-2006 | 1185 | | Message Set (USDoT model |https://standards.ieee.org/ | 1186 | | for traffic incidents) |findstds/standard/1512-2006.html| 1187 +----------+----------------------------+--------------------------------+ 1189 Figure 10: Device/Service Data Type Registry 1191 4.3.7. EmergencyCallData.DeviceInfo Example 1192 1193 1195 d4b3072df.201409182208075@example.org 1196 1197 fixed 1198 Nokia 1199 Lumia 800 1200 35788104 1201 1202 1204 Figure 11: EmergencyCallData.DeviceInfo Example. 1206 4.4. Owner/Subscriber Information 1208 This block describes the owner of the device (if provided by the 1209 device) or the subscriber information (if provided by a service 1210 provider). The contact location is not necessarily the location of 1211 the caller or incident, but is rather the nominal contact address. 1212 The MIME media type is "application/ 1213 EmergencyCallData.SubscriberInfo+xml". 1215 In some jurisdictions some or all parts of the subscriber-specific 1216 information are subject to privacy constraints. These constraints 1217 vary but dictate which information can be displayed and logged. A 1218 general privacy indicator expressing a desire for privacy by the 1219 subscriber is provided. The interpretation of how this is applied is 1220 left to the receiving jurisdiction as the custodians of the local 1221 regulatory requirements. This matches an equivalent privacy flag 1222 provided in some legacy emergency call systems. 1224 4.4.1. Subscriber Data Privacy Indicator 1226 Attribute: 'privacyRequested', Boolean. 1228 Use: Conditional. This attribute MUST be provided if the owner/ 1229 subscriber information block is not empty. 1231 Description: The subscriber data privacy indicator specifically 1232 expresses the subscriber's desire for privacy. In some 1233 jurisdictions subscriber services can have a specific "Type of 1234 Service" which prohibits information, such as the name of the 1235 subscriber, from being displayed. This attribute is provided to 1236 explicitly indicate whether the subscriber service includes such 1237 constraints. The interpretation of this indicator is left to each 1238 jurisdiction (in keeping with the semantics of the privacy 1239 indicator provided in some legacy emergency call systems). 1241 Because the interpretation of this indicator varies based on local 1242 regulations, this document cannot describe the exact semantics nor 1243 indicate which fields are affected (the application of this 1244 indicator might affect the display of data contained in any of the 1245 blocks). 1247 Reason for Need: Some jurisdictions require subscriber privacy to be 1248 observed when processing emergency calls. 1250 How Used by Call Taker: Where privacy is indicated the call taker 1251 might not have access to some aspects of the subscriber 1252 information. 1254 4.4.2. xCard for Subscriber's Data 1256 Data Element: xCARD for Subscriber's Data 1258 Use: Conditional. Subscriber data MUST be provided unless it is not 1259 available. Some services, such as prepaid phones, non-initialized 1260 phones, etc., do not have information about the subscriber. 1262 XML Element: 1264 Description: Information known by the service provider or device 1265 about the subscriber; e.g., Name, Address, Individual Telephone 1266 Number, Main Telephone Number and any other data. , (if 1267 appropriate), , , are suggested at a minimum. 1268 If more than one property is provided, a parameter from the 1269 vCard Property Value registry MUST be specified on each . 1270 While some data (such as ) might not seem obviously 1271 relevant for emergency services, any data is potentially useful in 1272 some emergency circumstances. 1274 Reason for Need: When the caller is unable to provide information, 1275 this data can be used to obtain it 1277 How Used by Call Taker: Obtaining critical information about the 1278 caller and possibly the location when it is not able to be 1279 obtained otherwise. While the location here is not necessarily 1280 that of caller, in some circumstances it can be helpful in 1281 locating the caller when other means have failed. 1283 4.4.3. EmergencyCallData.SubscriberInfo Example 1285 1286 1290 FEABFECD901@example.org 1291 1292 1293 1294 Simon Perreault 1295 1296 Perreault 1297 Simon 1298 1299 1300 ing. jr 1301 M.Sc. 1302 1303 --0203 1304 1305 20090808T1430-0500 1306 1307 M 1308 1309 1 1310 1311 fr 1312 1313 1314 2 1315 1316 en 1317 1318 1319 work 1320 1321 Viagenie 1322 1323 1324 1325 work 1326 1330 1331 1332 1333 2875 boul. Laurier, suite D2-630 1334 Quebec 1335 QC 1336 G1V 2M2 1337 Canada 1338 1339 1340 1341 1342 work 1343 voice 1344 1345 1346 tel:+1-418-656-9254;ext=102 1347 1348 1349 1350 1351 work 1352 voice 1353 main-number 1354 1355 1356 tel:+1-418-555-0000 1357 1358 1359 1360 1361 work 1362 text 1363 voice 1364 cell 1365 video 1366 1367 1368 tel:+1-418-262-6501 1369 1370 1371 work 1372 1373 simon.perreault@viagenie.ca 1374 1375 1376 work 1377 1378 geo:46.766336,-71.28955 1379 1380 1381 work 1382 1383 1384 http://www.viagenie.ca/simon.perreault/simon.asc 1385 1386 1387 America/Montreal 1388 1389 home 1390 1391 http://nomis80.org 1392 1393 1394 1395 1397 Figure 12: EmergencyCallData.SubscriberInfo Example. 1399 4.5. Comment 1401 This block provides a mechanism for the data provider to supply 1402 extra, human readable information to the PSAP. It is not intended 1403 for a general purpose extension mechanism nor does it aim to provide 1404 machine-readable content. The mime media type is "application/ 1405 EmergencyCallData.Comment+xml" 1407 4.5.1. Comment 1409 Data Element: EmergencyCallData.Comment 1411 Use: Optional 1413 XML Element: 1415 Description: Human readable text providing additional information to 1416 the PSAP staff. 1418 Reason for Need: Explanatory information for values in the data 1419 structure. 1421 How Used by Call Taker: To interpret the data provided. 1423 4.5.2. EmergencyCallData.Comment Example 1424 1425 1427 string0987654321@example.org 1428 1429 This is an example text. 1430 1432 Figure 13: EmergencyCallData.Comment Example. 1434 5. Issues with getting new types of data into use 1436 This document describes two mechanisms that allow extension of the 1437 kind of data provided with an emergency call: define a new block or 1438 define a new service specific additional data URL for the DeviceInfo 1439 block (Section 4.3.5). While defining new data types and getting a 1440 new device or application to send the new data might be easy, getting 1441 PSAPs and responders to actually retrieve the data and use it will be 1442 difficult. New mechanism providers should understand that acquiring 1443 and using new forms of data usually require software upgrades at the 1444 PSAP and/or responders, as well as training of call takers and 1445 responders in how to interpret and use the information. Legal and 1446 operational review might also be needed. Overwhelming a call taker 1447 or responder with too much information is highly discouraged. Thus, 1448 the barrier to supporting new data is quite high. 1450 The mechanisms this document describes are meant to encourage 1451 development of widely supported, common data formats for classes of 1452 devices. If all manufacturers of a class of device use the same 1453 format, and the data can be shown to improve outcomes, then PSAPs and 1454 responders can be encouraged to upgrade their systems and train their 1455 staff to use the data. Variations, however well intentioned, are 1456 unlikely to be supported. 1458 Implementers should consider that data from sensor-based devices in 1459 some cases might not be useful to call takers or PSAPs (and privacy, 1460 liability, or other considerations might preclude the PSAP from 1461 accessing or handling the data), but might be of use to responders. 1462 Each data item provided with the call in conformance with this 1463 document can be accessed by responders or other entities in the 1464 emergency services, whether or not the data is accessed by the PSAP. 1466 5.1. Choosing between defining a new type of block or new type of 1467 device/service-specific additional data 1469 For devices that have device or service specific data, there are two 1470 choices to carry it. A new block can be defined, or the device/ 1471 service-specific additional data URL in the DeviceInfo block can be 1472 used and a new type for it defined. The data passed would likely be 1473 the same in either case. Considerations for choosing the mechanism 1474 under which to register include: 1476 Applicability: Information which will be supported by many kinds of 1477 devices or services are more appropriately defined as separate 1478 blocks. 1480 Privacy: Information sent as a device/service-specific additional 1481 data URL in the DeviceInfo block is by reference (not by value), 1482 which inherently provides some additional privacy protection 1483 (since the requester needs to supply a certificate which is 1484 verified by the supplier). 1486 Size: Information which can be very large might be better sent in 1487 the DeviceInfo block, rather than a new block, so that 1488 implementations are unable to send the data by value. Conversely, 1489 data which is small might best be sent in a separate block so that 1490 it can be sent by value. 1492 Availability of a server: Providing the data via the device block 1493 requires a server be available from which to retrieve the data. 1494 Providing the data via new block allows it to be sent by value. 1496 6. Data Transport Mechanisms 1498 This section defines how to convey additional data to an emergency 1499 service provider. Two different means are specified: the first uses 1500 the call signaling; the second uses the element of a 1501 PIDF-LO [RFC4119]. 1503 1. First, the ability to embed a Uniform Resource Identifier (URI) 1504 in an existing SIP header field, the Call-Info header field, is 1505 defined. The URI points to the additional data structure. The 1506 Call-Info header field is specified in Section 20.9 of [RFC3261]. 1508 This document adds a new compound token starting with the value 1509 'EmergencyCallData' for the Call-Info "purpose" parameter. If 1510 the "purpose" parameter is set to a value starting with 1511 'EmergencyCallData', then the Call-Info header field contains 1512 either an HTTPS URL pointing to an external resource or a CID 1513 (content indirection) URI that allows the data structure to be 1514 placed in the body of the SIP message. The "purpose" parameter 1515 also indicates the kind of data (by its MIME media subtype) that 1516 is available at the URI. 1518 As the data is conveyed using a URI in the SIP signaling, the 1519 data itself can reside on an external resource, or can be 1520 contained within the body of the SIP message. When the URI 1521 refers to data at an external resource, the data is said to be 1522 passed by reference. When the URI refers to data contained 1523 within the body of the SIP message, the data is said to be passed 1524 by value. A PSAP or emergency responder is able to examine the 1525 type of data provided and selectively inspect the data it is 1526 interested in, while forwarding all of it (the values or 1527 references) to downstream entities. 1529 To be conveyed in a SIP body, additional data about a call is 1530 defined as a series of MIME objects (also referred to as a 1531 "block" of data). Each block defined in this document is an XML 1532 data structure identified by its MIME media type. (Blocks 1533 defined by others can be encoded in XML or not, as identified by 1534 their MIME registration.) As usual, whenever more than one MIME 1535 part is included in the body of a message, MIME multipart (i.e., 1536 'multipart/mixed') encloses them all. 1538 This document defines a set of XML schemas and MIME media types 1539 used for each block defined here. When additional data is passed 1540 by value in the SIP signaling, each CID URL points to one block 1541 in the body. Multiple URIs are used within a Call-Info header 1542 field (or multiple Call-Info header fields) to point to multiple 1543 blocks. When additional data is provided by reference (in SIP 1544 signaling or the element of a PIDF-LO), each HTTPS 1545 URL references one block; the data is retrieved with an HTTPS GET 1546 operation, which returns the block as an object (the blocks 1547 defined here are returned as XML objects). 1549 2. Second, the ability to embed additional data structures in the 1550 element of a PIDF-LO [RFC4119] is defined. 1552 In addition to service providers in the call path, the access 1553 network provider generally has similar information that can be 1554 valuable to the PSAP. When the access network provider and 1555 service provider are separate entities, the access network does 1556 not participate in the application layer signaling (and hence 1557 cannot add a Call-Info header field to the SIP message), but can 1558 provide location information in a PIDF-LO. When the access 1559 network provider supplies location information in the form of a 1560 PIDF-LO from a location server via a location configuration 1561 protocol, it has the ability to add the data structures defined 1562 in this document (or references to them) within the PIDF-LO. 1564 The data in these data structures is not specific to the location 1565 itself, but rather provides descriptive information having to do 1566 with the immediate circumstances about the provider's provision 1567 of the location (e.g., the identity of the access network 1568 provider, how to contact that entity, what kind of service the 1569 access network provides, subscriber information, etc.). This 1570 data is similar in nearly every respect to the data known by 1571 service providers in the path of the call. The 1572 element of the PIDF-LO is a mechanism for the access network 1573 provider to supply the information. This document describes a 1574 namespace per [RFC4119] for inclusion in the 1575 element of a PIDF-LO for adding information known to the access 1576 network provider. The access network provider SHOULD provide 1577 additional data within a element of a PDIF-LO it 1578 returns for emergency use (e.g., if requested with a HELD 1579 "responseTime" attribute of "emergencyRouting" or 1580 "emergencyDispatch" [RFC5985]). 1582 One or more blocks of data registered in the Emergency Call 1583 Additional Data registry, as defined in Section 11.1.9, can be 1584 included or referenced in the SIP signaling (using the Call-Info 1585 header field) or in the element of a PIDF-LO. For 1586 interoperability, only blocks in the registry are permitted to be 1587 sent using the mechanisms specified in this document. Since multiple 1588 entities are expected to provide sets of data, the data itself needs 1589 information describing the source. Consequently, each entity adding 1590 additional data MUST supply a "Data Provider" block. All other 1591 blocks are optional, but each entity SHOULD supply all blocks where 1592 it has at least some of the information in the block. 1594 6.1. Transmitting Blocks using Call-Info 1596 A URI to a block MAY be inserted in any SIP request or response 1597 method (most often INVITE or MESSAGE) with a Call-Info header field 1598 containing a purpose value starting with 'EmergencyCallData', a dot 1599 ("."), and the type of data available at the URI. The type of data 1600 is denoted by including the root of the MIME media subtype (the 1601 'EmergencyCallData' prefix is not repeated), omitting any suffix such 1602 as '+xml'). For example, when referencing a block with MIME media 1603 type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 1604 parameter is set to 'EmergencyCallData.ProviderInfo'. An example 1605 "Call-Info" header field for this would be: 1607 Call-Info: https://www.example.com/23sedde3; 1608 purpose="EmergencyCallData.ProviderInfo" 1610 A Call-info header field with a purpose value starting with 1611 'EmergencyCallData' only has meaning in the context of an emergency 1612 call (as ascertained by the presence of an emergency service URN in a 1613 Request-URI header field of a SIP message), test emergency calls 1614 (using an appropriate service URN), and some private-use calls where 1615 the endpoints have a preexisting relationship and privacy concerns do 1616 not apply because of the relationship; use in other contexts is 1617 undefined and is likely to unnecessarily expose confidential data. 1619 If the data is provided by reference, an HTTPS URI MUST be included 1620 and consequently Transport Layer Security (TLS) protection is used 1621 during the retrieval of the information. 1623 The data can also be supplied by value in any SIP request or response 1624 method that is permitted to contain a body (i.e., not a BYE request) 1625 [RFC3261]. In this case, Content Indirection (CID) [RFC2392] is 1626 used, with the CID URL referencing the MIME body part containing the 1627 data. Note that [RFC3261] forbids proxies from altering message 1628 bodies, so entities in the call path that add blocks by value need to 1629 do so using an appropriate SIP entity (e.g., a back-to-back user 1630 agent). 1632 Transmitting data by value is especially useful in certain cases, 1633 such as when the data exists in or is generated by the originating 1634 device, but is not intended for very large data blocks. Additional 1635 security and privacy considerations apply to data transmitted by 1636 value, as discussed in Section 9 and Section 10. 1638 More than one Call-Info header field with a purpose value starting 1639 with 'EmergencyCallData' can be expected, but at least one MUST be 1640 provided. The device MUST provide one unless it knows that a service 1641 provider is in the path of the call. The device MAY insert one if it 1642 uses a service provider. Each service provider in the path of an 1643 emergency call MUST insert its own. For example, a device, a 1644 telematics service provider in the call path, as well as the mobile 1645 carrier handling the call will each provide one. There might be 1646 circumstances where there is a service provider who is unaware that 1647 the call is an emergency call and cannot reasonably be expected to 1648 determine that it is an emergency call. In that case, that service 1649 provider is not expected to provide EmergencyCallData. 1651 6.2. Transmitting Blocks by Reference using the Element 1653 The element is used to transmit an 1654 additional data block by reference within a element of 1655 a PIDF-LO. The element has two 1656 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1657 type of data block referenced. The value of 'ref' is an HTTPS URL 1658 that resolves to a data structure with information about the call. 1659 The value of 'purpose' is the same as used in a 'Call-Info' header 1660 field (as specified in Section 6.1). 1662 For example, to reference a block with MIME media type 'application/ 1663 EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set 1664 to 'EmergencyCallData.ProviderInfo'. An example 1665 element for this would be: 1667 1670 The element transmits one data block; 1671 multiple data blocks are transmitted by using multiple 1672 elements. Multiple 1673 elements MAY be included as child 1674 elements inside the element. 1676 The following is a simplified example: 1678 1679 1683 1687 1690 1692 Example by Reference 1694 For an example in context, Figure 18 shows a PIDF-LO example with an 1695 element pointing to an 1696 EmergencyCallData.ServiceInfo data block with the URL in the 'ref' 1697 attribute and the purpose attribute set to 1698 "EmergencyCallData.ServiceInfo". 1700 6.3. Transmitting Blocks by Value using the Element 1702 It is RECOMMENDED that access networks supply the data specified in 1703 this document by reference, because PIDF-LOs can be fetched by a 1704 client or other entity and stored locally, so providing the data by 1705 value risks exposing private information to a larger audience. 1707 The element is used to transmit one or more 1708 additional data blocks by value within a element of a 1709 PIDF-LO. Each block being transmitted is placed (as a child element) 1710 inside the element. (The same XML structure 1711 as would be contained in the corresponding MIME media type body part 1712 is placed inside the element.) Multiple 1713 elements MAY be included as child elements 1714 in the element. 1716 The following is a simplified example: 1718 1720 1722 1725 flurbit735@es.example.com 1726 1727 Access Network Examples, Inc 1728 1729 urn:nena:companyid:Test 1730 NENA 1731 Access Network Provider 1732 1733 tel:+1-555-555-0897 1734 en 1735 1737 1740 flurbit735@es.example.com 1741 1742 This is an example text. 1743 1744 1746 1748 1750 Example by Value 1752 For an example in context, Figure 18 shows a PIDF-LO example that 1753 contains a element with the 1754 and the 1755 elements as child elements of an element. 1757 6.4. The Content-Disposition Parameter 1759 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1760 It updates and clarifies handling originally defined in RFC 3261 1761 [RFC3261] based on implementation experience. While RFC 3261 did not 1762 mandate support for 'multipart' message bodies, 'multipart/mixed' 1763 MIME bodies are used by many extensions (including this document) 1764 today. For example, adding a PIDF-LO, SDP, and additional data in 1765 body of a SIP message requires a 'multipart' message body. 1767 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1768 parameter for the Content-Disposition header field. These RFCs 1769 describe how a UAS reacts if it receives a message body whose content 1770 type or disposition type it does not understand. If the 'handling' 1771 parameter has the value "optional", the UAS ignores the message body. 1772 If the 'handling' parameter has the value "required", the UAS returns 1773 a 415 (Unsupported Media Type) response. The 'by-reference' 1774 disposition type of [RFC5621] allows a SIP message to contain a 1775 reference to the body part, and the SIP UA processes the body part 1776 according to the reference. This is the case for a Call-info header 1777 field containing a Content Indirection (CID) URL. 1779 As an example, a SIP message indicates the Content-Disposition 1780 parameter in the body of the SIP message as shown in Figure 14. 1782 Content-Type: application/sdp 1783 ...Omit Content-Disposition here; defaults are ok 1785 ...SDP goes in here 1787 --boundary1 1788 Content-Type: application/pidf+xml 1789 Content-ID: 1790 Content-Disposition: by-reference;handling=optional 1792 ...PIDF-LO goes in here 1794 --boundary1 1795 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1796 Content-ID: <1234567890@atlanta.example.com> 1797 Content-Disposition: by-reference; handling=optional 1799 ...Data provider information data goes in here 1801 --boundary1-- 1803 Figure 14: Example for use of the Content-Disposition Parameter in 1804 SIP 1806 7. Examples 1808 This section illustrates a longer and more complex example, as shown 1809 in Figure 15. In this example additional data is added by the end 1810 device, included by the VoIP provider, and provided by the access 1811 network provider (via the PIDF-LO). 1813 O +----+ [============] [=============] 1814 /|\ | UA | [ Access ] [ VoIP ] 1815 | +----+ [ Network ] [ Provider ] 1816 / \ [ Provider ] [ example.org ] 1817 [ ] [ ] 1818 (1) [ ] (2) [ ] 1819 Emergency Call [ ] Emergency Call [ ] 1820 ------------------------------------------------------> ] 1821 +Device Info [ ] +Device Info [ ] 1822 +Data Prov. Info [ ^ ] +Data Provider Info [ | ] 1823 +Location URI [=======.====] +Location URI [====|========] 1824 . | 1825 . | 1826 +Location . [==============] | 1827 +Owner/Subscriber Info . [ ] (3) | 1828 +Device Info . (4) [ <------------+ 1829 +Data Provider Info #3 ..........> ] Emergency Call 1830 [ ] +Device Info 1831 [ PSAP ] +Data Prov. Info #2 1832 [ ] +Location URI 1833 [==============] 1835 Legend: 1837 --- Emergency Call Setup Procedure 1838 ... Location Retrieval/Response 1840 Figure 15: Additional Data Example Flow 1842 The example scenario starts with the end device itself adding device 1843 information, owner/subscriber information, a location URI, and data 1844 provider information to the outgoing emergency call setup message 1845 (see step #1 in Figure 15). The SIP INVITE example is shown in 1846 Figure 16. 1848 INVITE urn:service:sos SIP/2.0 1849 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1850 Max-Forwards: 70 1851 To: 1852 From: Hannes Tschofenig ;tag=9fxced76sl 1853 Call-ID: 3848276298220188511@example.com 1854 Call-Info: 1855 ;purpose=icon, 1856 ;purpose=info, 1857 1858 ;purpose=EmergencyCallData.ProviderInfo, 1860 1861 ;purpose=EmergencyCallData.DeviceInfo 1862 Geolocation: 1863 Geolocation-Routing: yes 1864 Accept: application/sdp, application/pidf+xml, 1865 application/EmergencyCallData.ProviderInfo+xml 1866 CSeq: 31862 INVITE 1867 Contact: 1868 Content-Type: multipart/mixed; boundary=boundary1 1869 Content-Length: ... 1871 --boundary1 1872 Content-Type: application/sdp 1874 ...SDP goes here 1876 --boundary1 1877 Content-Type: application/EmergencyCallData.DeviceInfo+xml 1878 Content-ID: <0123456789@atlanta.example.com> 1879 Content-Disposition: by-reference;handling=optional 1881 1882 1885 1886 d4b3072df09876543@[93.184.216.119] 1887 1888 laptop 1889 00-0d-4b-30-72-df 1891 1892 1894 --boundary1 1895 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1896 Content-ID: <1234567890@atlanta.example.com> 1897 Content-Disposition: by-reference;handling=optional 1899 1900 1902 d4b3072df09876543@[93.184.216.119] 1903 1904 Hannes Tschofenig 1905 Client 1906 tel:+1-555-555-0123 1907 en 1908 1910 1911 Hannes Tschofenig 1912 1913 Hannes 1914 Tschofenig 1915 1916 1917 Dipl. Ing. 1918 1919 --0203 1920 1921 20090808T1430-0500 1922 1923 M 1924 1925 1 1926 1927 de 1928 1929 1930 2 1931 1932 en 1933 1934 1935 1936 work 1937 1941 1942 1943 1944 Linnoitustie 6 1945 Espoo 1946 Uusimaa 1947 02600 1948 Finland 1949 1950 1951 1952 home 1953 1958 1959 1960 1961 42 W 11th St 1962 Wilmington 1963 DE 1964 19801 1965 USA 1966 1967 1968 1969 1970 work 1971 voice 1972 1973 1974 tel:+358 50 4871445 1975 1976 1977 1978 1979 home 1980 voice 1981 1982 1983 tel:+1 555 555 0123 1984 1985 1986 1987 1988 work 1989 voice 1990 main-number 1991 1992 1993 tel:+1 302 594-3100 1994 1995 1996 work 1997 1998 hannes.tschofenig@nsn.com 1999 2000 2001 work 2002 2003 geo:60.210796,24.812924 2005 2006 2007 home 2008 2009 geo:39.746537,-75.548027 2010 2011 2012 2013 home 2014 2015 https://www.example.com/key.asc 2016 2017 Finland/Helsinki 2018 2019 home 2020 2021 http://example.com/hannes.tschofenig 2022 2023 2024 2025 2026 2027 --boundary1-- 2029 Figure 16: End Device sending SIP INVITE with Additional Data 2031 In this example, information available to the access network provider 2032 is included in the call setup message only indirectly via the use of 2033 the location reference. The PSAP has to retrieve it via a separate 2034 look-up step. Since the access network provider and the VoIP service 2035 provider are two independent entities in this scenario, the access 2036 network provider is not involved in application layer exchanges; the 2037 SIP INVITE transits the access network transparently, as illustrated 2038 in steps #1 and #2 (the access network does not alter the SIP 2039 INVITE). 2041 The VoIP service provider receives the message and determines, based 2042 on the Service URN, that the incoming request is an emergency call. 2043 It performs typical emergency services related tasks (such as 2044 location-based routing), and adds additional data, namely service and 2045 subscriber information as well as data provider information #2, to 2046 the outgoing message. For the example we assume a VoIP service 2047 provider that deploys a back-to-back user agent allowing additional 2048 data to be included in the body of the SIP message (rather than by 2049 reference), which allows us to illustrate the use of multiple data 2050 provider info blocks. The resulting message is shown in Figure 17. 2051 The SIP INVITE is sent to the PSAP in step #3. 2053 INVITE sips:psap@example.org SIP/2.0 2054 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 2055 Max-Forwards: 70 2056 To: 2057 From: Hannes Tschofenig ;tag=9fxced76sl 2058 Call-ID: 3848276298220188511@example.com 2059 Call-Info: ; 2060 purpose=icon, 2061 ; purpose=info, 2062 ; 2063 purpose=EmergencyCallData.ProviderInfo 2064 ; 2065 purpose=EmergencyCallData.DeviceInfo 2066 Call-Info: ; 2067 purpose=EmergencyCallData.ServiceInfo 2068 Call-Info: ; 2069 purpose=EmergencyCallData.ProviderInfo 2070 Geolocation: 2071 Geolocation-Routing: yes 2072 Accept: application/sdp, application/pidf+xml, 2073 application/EmergencyCallData.ProviderInfo+xml 2074 CSeq: 31862 INVITE 2075 Contact: 2076 Content-Type: multipart/mixed; boundary=boundary1 2077 Content-Length: ... 2079 --boundary1 2080 Content-Type: application/sdp 2082 ...SDP goes here 2084 --boundary1 2085 Content-Type: application/EmergencyCallData.DeviceInfo+xml 2086 Content-ID: <0123456789@atlanta.example.com> 2087 Content-Disposition: by-reference;handling=optional 2089 2090 2093 d4b3072df09876543@[93.184.216.119] 2094 2095 laptop 2096 00-0d-4b-30-72-df 2098 2100 --boundary1 2101 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2102 Content-ID: <1234567890@atlanta.example.com> 2103 Content-Disposition: by-reference;handling=optional 2105 2106 2109 d4b3072df09876543@[93.184.216.119] 2110 2111 Hannes Tschofenig 2112 2113 Client 2114 tel:+1-555-555-0123 2115 en 2116 2118 2119 Hannes Tschofenig 2120 2121 Hannes 2122 Tschofenig 2123 2124 2125 Dipl. Ing. 2126 2127 --0203 2128 2129 20090808T1430-0500 2130 2131 M 2132 2133 1 2134 2135 de 2136 2137 2138 2 2139 2140 en 2141 2142 2143 2144 work 2145 2150 2151 2152 2153 Linnoitustie 6 2154 Espoo 2155 Uusimaa 2156 02600 2157 Finland 2158 2159 2160 2161 home 2162 2167 2168 2169 2170 42 W 11th St 2171 Wilmington 2172 DE 2173 19801 2174 USA 2175 2176 2177 2178 2179 work 2180 voice 2181 2182 2183 tel:+358 50 4871445 2184 2185 2186 2187 2188 home 2189 voice 2190 2191 2192 tel:+1 555 555 0123 2193 2194 2195 work 2196 2197 hannes.tschofenig@nsn.com 2199 2200 2201 work 2202 2203 geo:60.210796,24.812924 2204 2205 2206 home 2207 2208 geo:39.746537,-75.548027 2209 2210 2211 2212 home 2213 2214 https://www.example.com/key.asc 2215 2216 Finland/Helsinki 2217 2218 home 2219 2220 http://example.com/hannes.tschofenig 2221 2222 2223 2224 2226 --boundary1 2227 Content-Type: application/EmergencyCallData.ServiceInfo+xml 2228 Content-ID: 2229 Content-Disposition: by-reference;handling=optional 2231 2232 2234 string0987654321@example.org 2235 2236 Residence 2237 VOIP 2238 Unknown 2239 2241 --boundary1 2242 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2243 Content-ID: 2244 Content-Disposition: by-reference;handling=optional 2246 2247 2250 string0987654321@example.org 2251 2252 Exemplar VoIP Provider 2253 2254 urn:nena:companyid:ID123 2255 NENA 2256 Service Provider 2257 sip:voip-provider@example.com 2258 en 2259 2261 2262 John Doe 2263 2264 John 2265 Doe 2266 2267 2268 2269 2270 --0203 2271 2272 20090808T1430-0500 2273 2274 M 2275 2276 1 2277 2278 en 2279 2280 2281 work 2282 2283 Exemplar VoIP Provider 2284 2285 2286 2287 work 2288 2291 2292 2293 2294 123 Middle Street 2295 the Sticks 2296 IA 2297 50055 2298 USA 2299 2300 2301 2302 2303 work 2304 voice 2305 main-number 2306 2307 2308 sips:john.doe@example.com 2309 2310 2311 work 2312 2313 john.doe@example.com 2314 2315 2316 work 2317 2318 geo:41.761838,-92.963268 2319 2320 America/Chicago 2321 2322 home 2323 2324 http://www.example.com/john.doe 2325 2326 2327 2328 2329 --boundary1-- 2331 Figure 17: VoIP Provider sending SIP INVITE with Additional Data 2333 Finally, the PSAP requests location information from the access 2334 network provider. The response is shown in Figure 18. Along with 2335 the location information, additional data is provided in the 2336 element of the PIDF-LO. This request and response is 2337 step #4. 2339 2340 2345 2346 2347 2348 2350 US 2351 DE 2352 Wilmington 2353 W 2354 11th 2355 Street 2356 42 2357 The Hotel DuPont 2358 19801 2359 2360 2361 2362 true 2363 2364 2013-12-10T20:00:00Z 2365 2366 2367 802.11 2369 2372 2376 2377 2380 88QV4FpfZ976T@example.com 2381 2382 Diamond State Exemplar 2383 2384 urn:nena:companyid:diamond 2385 NENA 2386 Access Network Provider 2387 tel:+1-302-555-0000 2388 en 2389 2390 2392 88QV4FpfZ976T@example.com 2393 2394 This is an example text. 2395 2397 2398 2400 2401 mac:00-0d-4b-30-72-df 2402 2013-07-09T20:57:29Z 2403 2404 2406 Figure 18: Access Network Provider returning PIDF-LO with Additional 2407 Data 2409 8. XML Schemas 2411 This section defines the XML schemas of the five data blocks. 2412 Additionally, the provided-by schema is specified. 2414 8.1. EmergencyCallData.ProviderInfo XML Schema 2416 2417 2427 2430 2433 2437 2438 2439 2440 2441 2442 2444 2445 2446 2449 2452 2455 2458 2461 2464 2465 2466 2467 2473 2474 2475 2477 2479 2480 2481 2484 2485 2486 2488 2491 2495 2497 2498 2500 2502 Figure 19: EmergencyCallData.ProviderInfo XML Schema. 2504 8.2. EmergencyCallData.ServiceInfo XML Schema 2505 2506 2515 2518 2521 2522 2523 2526 2529 2533 2536 2538 2539 2541 2543 Figure 20: EmergencyCallData.ServiceInfo XML Schema. 2545 8.3. EmergencyCallData.DeviceInfo XML Schema 2547 2548 2557 2560 2563 2564 2565 2568 2571 2574 2577 2579 2580 2581 2582 2585 2586 2587 2588 2590 2593 2596 2598 2599 2601 2603 Figure 21: EmergencyCallData.DeviceInfo XML Schema. 2605 8.4. EmergencyCallData.SubscriberInfo XML Schema 2607 2608 2619 2622 2625 2628 2629 2630 2631 2632 2635 2636 2637 2638 2640 2641 2642 2644 2646 2647 2649 2650 2651 2653 2655 Figure 22: EmergencyCallData.SubscriberInfo XML Schema. 2657 8.5. EmergencyCallData.Comment XML Schema 2658 2659 2668 2671 2674 2675 2676 2679 2683 2685 2686 2688 2689 2690 2691 2692 2693 2694 2696 2698 Figure 23: EmergencyCallData.Comment XML Schema. 2700 8.6. provided-by XML Schema 2702 This section defines the provided-by schema. 2704 2705 2720 2723 2726 2729 2732 2736 2739 2742 2744 2745 2746 2747 2748 2750 2751 2754 2756 2757 2758 2760 2762 2763 2764 2767 2770 2773 2776 2780 2783 2784 2786 2788 Figure 24: provided-by XML Schema 2790 9. Security Considerations 2792 The data structures described in this document contain information 2793 usually considered private. When information is provided by value, 2794 entities that are a party to the SIP signaling (such as proxy servers 2795 and back-to-back user agents) will have access to it and need to 2796 protect it against inappropriate disclosure. An entity that is able 2797 to eavesdrop on the SIP signaling will also have access. Some access 2798 types (such as in-the-clear Wi-Fi) are more vulnerable than others 2799 (such as 3G or 4G cellular data traffic) to eavesdropping. 2800 Mechanisms that protect against eavesdropping (such as Transport 2801 Layer Security (TLS) version 1.2 or later) SHOULD be preferentially 2802 used whenever feasible. (This requirement is not a "MUST" because 2803 there is an existing deployed base of clear-text SIP, and also 2804 because, as an emergency call, it is more important for the call to 2805 go through than for it to be protected; e.g., the call MUST proceed 2806 even if the TLS negotiation or certificate verification fails for 2807 whatever reason.) When information is provided by reference, TLS 2808 mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for 2809 dereferencing, the requestor MUST use a client certificate to 2810 authenticate the HTTP request, and the provider of the information is 2811 REQUIRED to validate the credentials provided by the requester. 2812 While the creation of a public key infrastructure (PKI) that has 2813 global scope might be difficult, the alternatives to creating devices 2814 and services that can provide critical information securely are more 2815 daunting. The provider of the information MAY enforce any policy it 2816 wishes to use, but PSAPs and responder agencies are strongly advised 2817 to deploy a PKI so that providers of additional data can check the 2818 certificate of the client (the requester) and decide the appropriate 2819 policy to enforce based on that certificate. 2821 TLS MUST be version 1.2 or later. TLS MUST be version 1.2 or later. 2822 It is RECOMMENDED to use only cipher suites that offer Perfect 2823 Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), and to 2824 follow the recommendations in BCP 195 [RFC7525]. 2826 Ideally, the PSAP and emergency responders will be given credentials 2827 signed by an authority trusted by the data provider. In most 2828 circumstances, nationally recognized credentials are sufficient; the 2829 emergency services community within a country can arrange a PKI, data 2830 providers can be provisioned with the root CA public key for the 2831 country. Some nations are developing a PKI for this, and related, 2832 purposes. Since calls could be made from devices where the device 2833 and/or the service provider(s) are not local to the emergency 2834 services authorities, globally recognized credentials are useful. 2835 This might be accomplished by extending the notion of the "forest 2836 guide" described in [RFC5582] to allow the forest guide to provide 2837 the credential of the PKI root for areas for which it has coverage 2838 information, but standards for such a mechanism are not yet 2839 available. In its absence, the data provider needs to obtain by out 2840 of band means the root CA credentials for any areas to which it is 2841 willing to provide additional data. With the credential of the root 2842 CA for a national emergency services PKI, the data provider server 2843 can validate the credentials of an entity requesting additional data 2844 by reference. 2846 The data provider also needs a credential that can be verified by the 2847 emergency services to know that it is receiving data from an 2848 authorized server. The emergency services authorities could provide 2849 credentials, distinguishable from credentials provided to emergency 2850 responders and PSAPs, which could be used to validate data providers. 2851 Such credentials would have to be acceptable to any PSAP or responder 2852 that could receive a call with additional data supplied by that 2853 provider. This would be extensible to global credential validation 2854 using the forest guide as mentioned above. In the absence of such 2855 credentials, the emergency services authorities could maintain a list 2856 of local data providers' credentials as provided to them out of band. 2857 At a minimum, the emergency services authorities could obtain a 2858 credential from the DNS entry of the domain in the Additional Data 2859 URI (e.g., using DANE [RFC6698]) to at least validate that the server 2860 is known to the domain providing the URI. 2862 Data provided by devices by reference have similar credential 2863 validation issues as for service providers, and while the solutions 2864 are the same, the challenges of doing so for every device are 2865 obviously more difficult, especially when considering root 2866 certificate updates, revocation lists, etc. However, in general, 2867 devices are not expected to provide data directly by reference, but 2868 rather, to either provide data by value, or upload the data to a 2869 server which can more reliably make it available and more easily 2870 enforce security policy. Devices which do provide data directly by 2871 reference, which might include fixed-location sensors, will need to 2872 be capable of handling this. 2874 Neither service providers nor devices will supply private information 2875 unless the call is recognized as an emergency call. In cellular 2876 telephony systems (such as those using 3GPP IMS), there are different 2877 procedures for an originating device to place an emergency versus a 2878 normal call. If a call that is really an emergency call is initiated 2879 as a normal call and the cellular service provider recognizes this, 2880 3GPP IMS permits the service provider to either accept the call 2881 anyway or reject it with a specific code that instructs the device to 2882 retry the call as an emergency call. Service providers ought to 2883 choose the latter, because otherwise the device will not have 2884 included the information specified in this document (since the device 2885 didn't recognize the call as being an emergency call). 2887 10. Privacy Considerations 2889 This document enables functionality for conveying additional 2890 information about the caller and the caller's device and service to 2891 the callee. Some of this information is personal data and therefore 2892 privacy concerns arise. An explicit privacy indicator for 2893 information directly relating to the caller's identity is defined and 2894 use is mandatory. However, observance of this request for privacy 2895 and which information it relates to is determined by the destination 2896 jurisdiction (which replicates functionality provided in some legacy 2897 emergency services systems). 2899 There are a number of privacy concerns with non-emergency real-time 2900 communication services that are also applicable to emergency calling. 2901 Data protection regulation world-wide has, however, decided to create 2902 exceptions for emergency services since the drawbacks of disclosing 2903 personal data are outweighed by the benefit for the emergency caller. 2904 Hence, the data protection rights of individuals are commonly waived 2905 for emergency situations. There are, however, still various 2906 countries that offer some degree of anonymity for the caller towards 2907 PSAP call takers. 2909 The functionality defined in this document far exceeds the amount of 2910 information sharing available in the legacy POTS system. For this 2911 reason there are additional privacy threats to consider, which are 2912 described in more detail in [RFC6973]. 2914 Stored Data Compromise: There is an increased risk of stored data 2915 compromise since additional data is collected and stored in 2916 databases. Without adequate measures to secure stored data from 2917 unauthorized or inappropriate access at access network providers, 2918 service providers, end devices, as well as PSAPs, individuals are 2919 exposed to potential financial, reputational, or physical harm. 2921 Misattribution: If the personal data collected and conveyed is 2922 incorrect or inaccurate then this can lead to misattribution. 2923 Misattribution occurs when data or communications related to one 2924 individual are attributed to another. 2926 Identification: By the nature of the additional data and its 2927 capability to provide much richer information about the caller, 2928 the call, and the location, the calling party is identified in a 2929 much better way. Some users could feel uncomfortable with this 2930 degree of information sharing even in emergency services 2931 situations. 2933 Secondary Use: There is a risk of secondary use, which is the use of 2934 collected information about an individual without the individual's 2935 consent for a purpose different from that for which the 2936 information was collected. The stated purpose of the additional 2937 data is for emergency services purposes, but theoretically the 2938 same information could be used for any other call as well. 2939 Additionally, parties involved in the emergency call could retain 2940 the obtained information and re-use it for other, non-emergency 2941 services purposes. While technical measures are not in place to 2942 prevent such secondary re-use, policy, legal, regulatory, and 2943 other non-technical approaches can be effective. 2945 Disclosure: When the data defined in this document is not properly 2946 protected (while in transit with traditional communication 2947 security techniques, and while stored using access control 2948 mechanisms) there is the risk of disclosure, which is the 2949 revelation of private information about an individual. 2951 To mitigate these privacy risks the following countermeasures can be 2952 taken: 2954 In regions where callers can elect to suppress certain personally 2955 identifying information, network or PSAP functionality can inspect 2956 privacy flags within the SIP headers to determine what information 2957 can be passed, stored, or displayed to comply with local policy or 2958 law. RFC 3325 [RFC3325] defines the "id" priv-value token. The 2959 presence of this privacy type in a Privacy header field indicates 2960 that the user would like the network asserted identity to be kept 2961 private with respect to SIP entities outside the trust domain with 2962 which the user authenticated, including the PSAP. 2964 This document defines various data structures that contain privacy- 2965 sensitive data. For example, identifiers for the device (e.g., 2966 serial number, MAC address) or account/SIM (e.g., IMSI), contact 2967 information for the user, location of the caller. Local regulations 2968 may govern which data is provided in emergency calls, but in general, 2969 the emergency call system is aided by the information described in 2970 this document. There is a tradeoff between the privacy 2971 considerations and the utility of the data. For protection, this 2972 specification requires all retrieval of data passed by reference to 2973 be protected against eavesdropping and alteration via communication 2974 security techniques (namely TLS). Furthermore, security safeguards 2975 are required to prevent unauthorized access to stored data. Various 2976 security incidents over at least the past few decades have shown that 2977 data breaches are not uncommon and are often caused by lack of proper 2978 access control frameworks, software bugs (such as buffer overflows), 2979 or missing input parsing (such as SQL injection attacks). The risks 2980 of data breaches is increased with the obligation for emergency 2981 services to retain emergency call related data for extended periods 2982 (e.g., several years are the norm). 2984 Finally, it is also worth highlighting the nature of the SIP 2985 communication architecture, which introduces additional complications 2986 for privacy. Some forms of data can be sent by value in the SIP 2987 signaling or by reference (a URL in the SIP signaling). When data is 2988 sent by value, all intermediaries have access to the data. As such, 2989 these intermediaries could also introduce additional privacy risk. 2990 Therefore, in situations where the conveyed information is privacy- 2991 sensitive and intermediaries are involved, transmitting by reference 2992 might be appropriate, assuming the source of the data can operate a 2993 sufficient dereferencing infrastructure and that proper access 2994 control policies are available for distinguishing the different 2995 entities dereferencing the reference. Without access control 2996 policies any party in possession of the reference is able to resolve 2997 the reference and to obtain the data, including intermediaries. 2999 11. IANA Considerations 3001 11.1. Registry creation 3003 This document creates a new registry called 'Emergency Call 3004 Additional Data'. The following sub-registries are created for this 3005 registry. 3007 11.1.1. Provider ID Series Registry 3009 This document creates a new sub-registry called "Provider ID Series". 3010 As defined in [RFC5226], this registry operates under "Expert Review" 3011 rules. The expert should determine that the entity requesting a new 3012 value is a legitimate issuer of service provider IDs suitable for use 3013 in Additional Call Data. 3015 Private entities issuing or using internally-generated IDs are 3016 encouraged to register here and to ensure that all IDs they issue or 3017 use are unique. This guarantees that IDs issued or used by the 3018 entity are globally unique and distinguishable from other IDs issued 3019 or used by the same or a different entity. (Some organizations, such 3020 as NENA, issue IDs that are unique among all IDs they issue, so an 3021 entity using a combination of its NENA ID and the fact that it is 3022 from NENA is globally unique. Other entities might not have an ID 3023 issued by an organization such as NENA, so they are permitted to use 3024 their domain name, but if so, it needs to be unique.) 3026 The content of this registry includes: 3028 Name: An identifier to be used in the 'ProviderIDSeries' element. 3030 Source: The full name of the organization issuing the identifiers. 3032 URL: A URL to the organization for further information. 3034 The initial set of values is listed in Figure 1. 3036 11.1.2. Service Environment Registry 3038 This document creates a new sub-registry called "Service 3039 Environment". As defined in [RFC5226], this registry operates under 3040 "Expert Review" rules. The expert should determine that the entity 3041 requesting a new value is relevant for this service element (e.g., a 3042 recognized emergency services related SDO), and that the new value is 3043 distinct from existing values, and its use is unambiguous. 3045 The content of this registry includes: 3047 Token: The value to be used in the element. 3049 Description: A short description of the value. 3051 The initial set of values is listed in Figure 4. 3053 11.1.3. Service Type Registry 3055 This document creates a new sub-registry called "Service Type". As 3056 defined in [RFC5226], this registry operates under "Expert Review" 3057 rules. The expert should determine that the entity requesting a new 3058 value is relevant for this service element (e.g., a recognized 3059 emergency services related SDO) and that the requested value is 3060 clearly distinct from other values so that there is no ambiguity as 3061 to when the value is to be used or which value is to be used. 3063 The content of this registry includes: 3065 Name: The value to be used in the element. 3067 Description: A short description of the value. 3069 The initial set of values is listed in Figure 5. 3071 11.1.4. Service Mobility Registry 3073 This document creates a new sub-registry called "Service Mobility". 3074 As defined in [RFC5226], this registry operates under "Expert Review" 3075 rules. The expert should determine that the entity requesting a new 3076 value is relevant for this service element (e.g., a recognized 3077 emergency services related SDO) and that the requested value is 3078 clearly distinct from other values so that there is no ambiguity as 3079 to when the value is to be used or which value is to be used. 3081 The content of this registry includes: 3083 Token: The value used in the element. 3085 Description: A short description of the value. 3087 The initial set of values is listed in Figure 6. 3089 11.1.5. Service Provider Type Registry 3091 This document creates a new sub-registry called "Service Provider 3092 Type". As defined in [RFC5226], this registry operates under "Expert 3093 Review". The expert should determine that the proposed new value is 3094 distinct from existing values and appropriate for use in the 3095 element 3097 The content of this registry includes: 3099 Token: The value used in the element. 3101 Description: A short description of the type of service provider. 3103 The initial set of values is defined in Figure 2. 3105 11.1.6. Device Classification Registry 3107 This document creates a new sub-registry called 'Device 3108 Classification'. As defined in [RFC5226], this registry operates 3109 under "Expert Review" rules. The expert should consider whether the 3110 proposed class is unique from existing classes and the definition of 3111 the class will be clear to implementors and PSAPs/responders. 3113 The content of this registry includes: 3115 Token: Value used in the element. 3117 Description: Short description identifying the device type. 3119 The initial set of values are defined in Figure 8. 3121 11.1.7. Device ID Type Type Registry 3123 This document creates a new sub-registry called "Device ID Type". As 3124 defined in [RFC5226], this registry operates under "Expert Review" 3125 rules. The expert should ascertain that the proposed type is well 3126 understood, and provides information which PSAPs and responders are 3127 able to use to uniquely identify a device. (For example, a biometric 3128 fingerprint used to authenticate a device would not normally be 3129 useful by a PSAP or responder to identify a device.) 3131 The content of this registry includes: 3133 Token: The value to be placed in the element. 3135 Description: Short description identifying the type of the device 3136 ID. 3138 The initial set of values are defined in Figure 9. 3140 11.1.8. Device/Service Data Type Registry 3142 This document creates a new sub-registry called "Device/Service Data 3143 Type". As defined in [RFC5226], this registry operates under 3144 "Specification Required" rules, which include an explicit expert 3145 review. The designated expert should ascertain that the proposed 3146 type is well understood, and provides information useful to PSAPs and 3147 responders. The specification must contain a complete description of 3148 the data, and a precise format specification suitable to allow 3149 interoperable implementations. 3151 The content of this registry includes: 3153 Token: The value to be placed in the element. 3155 Description: Short description identifying the data. 3157 Specification: Citation for the specification of the data. 3159 The initial set of values are listed in Figure 10. 3161 11.1.9. Emergency Call Data Types Registry 3163 This document creates a new sub-registry called 'Emergency Call Data 3164 Types'. As defined in [RFC5226], this registry operates under 3165 "Specification Required" rules, which include an explicit expert 3166 review. The expert is responsible for verifying that the document 3167 contains a complete and clear specification and the proposed 3168 functionality does not obviously duplicate existing functionality. 3169 The expert is also responsible for verifying that the block is 3170 correctly categorized per the description of the categories in 3171 Section 1. 3173 The registry contains an entry for every data block that can be sent 3174 with an emergency call using the mechanisms as specified in this 3175 document. Each data block is identified by the "root" of its MIME 3176 media subtype (which is the part after 'EmergencyCallData.'). If the 3177 MIME media subtype does not start with 'EmergencyCallData.', then it 3178 cannot be registered here nor used in a Call-Info header field as 3179 specified in this document. The subtype MAY exist under any MIME 3180 media type (although most commonly these are under 'Application/' 3181 this is NOT REQUIRED), however, to be added to the registry the 3182 "root" needs to be unique regardless of the MIME media type. 3184 The content of this registry includes: 3186 Token: The root of the data's MIME media subtype (not including the 3187 'EmergencyCallData' prefix and any suffix such as '+xml') 3189 Data About: A hint as to if the block is considered descriptive of 3190 the call, the caller, or the location (or is applicable to more 3191 than one), which can help PSAPs and other entities determine if 3192 they wish to process the block. Note that this is only a hint; 3193 entities need to consider the block's contents, not just this 3194 field, when determining if they wish to process the block (which 3195 is why the field only exists in the registry, and is not contained 3196 within the block). The value MUST be either "The Call", "The 3197 Caller", "The Location", or "Multiple". New values are created by 3198 extending this registry in a subsequent RFC. 3200 Reference: The document that describes the data object 3202 Note that the tokens in this registry are part of the 3203 'EmergencyCallData' compound value; when used as a value of the 3204 'purpose' parameter of a Call-Info header field, the values listed in 3205 this registry are prefixed by 'EmergencyCallData.' per the 3206 'EmergencyCallData' registration Section 11.2. 3208 The initial set of values are listed in Figure 25. 3210 +----------------+--------------+------------+ 3211 | Token | Data About | Reference | 3212 +----------------+--------------+------------+ 3213 | ProviderInfo | The Call | [This RFC] | 3214 | ServiceInfo | The Call | [This RFC] | 3215 | DeviceInfo | The Call | [This RFC] | 3216 | SubscriberInfo | The Call | [This RFC] | 3217 | Comment | The Call | [This RFC] | 3218 +----------------+--------------+------------+ 3220 Figure 25: Additional Data Blocks Registry 3222 11.2. 'EmergencyCallData' Purpose Parameter Value 3224 This document defines the 'EmergencyCallData' value for the 'purpose' 3225 parameter of the Call-Info header field [RFC3261]. IANA has added 3226 this document to the list of references for the 'purpose' value of 3227 Call-Info in the Header Field Parameters and Parameter Values sub- 3228 registry of the Session Initiation Protocol (SIP) Parameters 3229 registry. Note that 'EmergencyCallData' is a compound value; when 3230 used as a value of the 'purpose' parameter of a Call-Info header 3231 field, 'EmergencyCallData' is immediately followed by a dot ('.') and 3232 a value from the 'Emergency Call Data Types' registry Section 11.1.9. 3234 11.3. URN Sub-Namespace Registration for Registry Entry 3236 This section registers the namespace specified in Section 11.5.1 in 3237 the provided-by registry established by RFC 4119, for usage within 3238 the element of a PIDF-LO. 3240 The schema for the element used by this document is 3241 specified in Section 8.6. 3243 11.4. MIME Registrations 3245 11.4.1. MIME Content-type Registration for 'application/ 3246 EmergencyCallData.ProviderInfo+xml' 3248 This specification requests the registration of a new MIME media type 3249 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3250 RFC 7303 [RFC7303]. 3252 MIME media type name: application 3254 MIME media subtype name: EmergencyCallData.ProviderInfo+xml 3256 Mandatory parameters: none 3258 Optional parameters: charset (indicates the character encoding of 3259 the contents) 3261 Encoding considerations: Uses XML, which can contain 8-bit 3262 characters, depending on the character encoding. See Section 3.2 3263 of RFC 7303 [RFC7303]. 3265 Security considerations: This content type is designed to carry 3266 the data provider information, which is a sub-category of 3267 additional data about an emergency call. Since this data can 3268 contain personal information, appropriate precautions are needed 3269 to limit unauthorized access, inappropriate disclosure, and 3270 eavesdropping of personal information. Please refer to Section 9 3271 and Section 10 for more information. 3273 Interoperability considerations: None 3275 Published specification: [TBD: This specification] 3277 Applications which use this media type: Emergency Services 3279 Additional information: 3281 Magic Number: None 3282 File Extension: .xml 3284 Macintosh file type code: 'TEXT' 3286 Person and email address for further information: Hannes 3287 Tschofenig, Hannes.Tschofenig@gmx.net 3289 Intended usage: LIMITED USE 3291 Author: This specification is a work item of the IETF ECRIT 3292 working group, with mailing list address . 3294 Change controller: The IESG 3296 11.4.2. MIME Content-type Registration for 'application/ 3297 EmergencyCallData.ServiceInfo+xml' 3299 This specification requests the registration of a new MIME media type 3300 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3301 RFC 7303 [RFC7303]. 3303 MIME media type name: application 3305 MIME media subtype name: EmergencyCallData.ServiceInfo+xml 3307 Mandatory parameters: none 3309 Optional parameters: charset (indicates the character encoding of 3310 the contents) 3312 Encoding considerations: Uses XML, which can contain 8-bit 3313 characters, depending on the character encoding. See Section 3.2 3314 of RFC 7303 [RFC7303]. 3316 Security considerations: This content type is designed to carry 3317 the service information, which is a sub-category of additional 3318 data about an emergency call. Since this data can contain 3319 personal information, appropriate precautions are needed to limit 3320 unauthorized access, inappropriate disclosure, and eavesdropping 3321 of personal information. Please refer to Section 9 and Section 10 3322 for more information. 3324 Interoperability considerations: None 3326 Published specification: [TBD: This specification] 3328 Applications which use this media type: Emergency Services 3329 Additional information: 3331 Magic Number: None 3333 File Extension: .xml 3335 Macintosh file type code: 'TEXT' 3337 Person and email address for further information: Hannes 3338 Tschofenig, Hannes.Tschofenig@gmx.net 3340 Intended usage: LIMITED USE 3342 Author: This specification is a work item of the IETF ECRIT 3343 working group, with mailing list address . 3345 Change controller: The IESG 3347 11.4.3. MIME Content-type Registration for 'application/ 3348 EmergencyCallData.DeviceInfo+xml' 3350 This specification requests the registration of a new MIME media type 3351 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3352 RFC 7303 [RFC7303]. 3354 MIME media type name: application 3356 MIME media subtype name: EmergencyCallData.DeviceInfo+xml 3358 Mandatory parameters: none 3360 Optional parameters: charset (indicates the character encoding of 3361 the contents) 3363 Encoding considerations: Uses XML, which can contain 8-bit 3364 characters, depending on the character encoding. See Section 3.2 3365 of RFC 7303 [RFC7303]. 3367 Security considerations: This content type is designed to carry 3368 device information, which is a sub-category of additional data 3369 about an emergency call. Since this data contains personal 3370 information, appropriate precautions need to be taken to limit 3371 unauthorized access, inappropriate disclosure to third parties, 3372 and eavesdropping of this information. Please refer to Section 9 3373 and Section 10 for more information. 3375 Interoperability considerations: None 3376 Published specification: [TBD: This specification] 3378 Applications which use this media type: Emergency Services 3380 Additional information: 3382 Magic Number: None 3384 File Extension: .xml 3386 Macintosh file type code: 'TEXT' 3388 Person and email address for further information: Hannes 3389 Tschofenig, Hannes.Tschofenig@gmx.net 3391 Intended usage: LIMITED USE 3393 Author: This specification is a work item of the IETF ECRIT 3394 working group, with mailing list address . 3396 Change controller: The IESG 3398 11.4.4. MIME Content-type Registration for 'application/ 3399 EmergencyCallData.SubscriberInfo+xml' 3401 This specification requests the registration of a new MIME media type 3402 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3403 RFC 7303 [RFC7303]. 3405 MIME media type name: application 3407 MIME media subtype name: EmergencyCallData.SubscriberInfo+xml 3409 Mandatory parameters: none 3411 Optional parameters: charset (indicates the character encoding of 3412 the contents) 3414 Encoding considerations: Uses XML, which can contain 8-bit 3415 characters, depending on the character encoding. See Section 3.2 3416 of RFC 7303 [RFC7303]. 3418 Security considerations: This content type is designed to carry 3419 owner/subscriber information, which is a sub-category of 3420 additional data about an emergency call. Since this data contains 3421 personal information, appropriate precautions need to be taken to 3422 limit unauthorized access, inappropriate disclosure to third 3423 parties, and eavesdropping of this information. Please refer to 3424 Section 9 and Section 10 for more information. 3426 Interoperability considerations: None 3428 Published specification: [TBD: This specification] 3430 Applications which use this media type: Emergency Services 3432 Additional information: 3434 Magic Number: None 3436 File Extension: .xml 3438 Macintosh file type code: 'TEXT' 3440 Person and email address for further information: Hannes 3441 Tschofenig, Hannes.Tschofenig@gmx.net 3443 Intended usage: LIMITED USE 3445 Author: This specification is a work item of the IETF ECRIT 3446 working group, with mailing list address . 3448 Change controller: The IESG 3450 11.4.5. MIME Content-type Registration for 'application/ 3451 EmergencyCallData.Comment+xml' 3453 This specification requests the registration of a new MIME media type 3454 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3455 RFC 7303 [RFC7303]. 3457 MIME media type name: application 3459 MIME media subtype name: EmergencyCallData.Comment+xml 3461 Mandatory parameters: none 3463 Optional parameters: charset (indicates the character encoding of 3464 the contents) 3466 Encoding considerations: Uses XML, which can contain 8-bit 3467 characters, depending on the character encoding. See Section 3.2 3468 of RFC 7303 [RFC7303]. 3470 Security considerations: This content type is designed to carry a 3471 comment, which is a sub-category of additional data about an 3472 emergency call. This data can contain personal information. 3473 Appropriate precautions are needed to limit unauthorized access, 3474 inappropriate disclosure to third parties, and eavesdropping of 3475 this information. Please refer to Section 9 and Section 10 for 3476 more information. 3478 Interoperability considerations: None 3480 Published specification: [TBD: This specification] 3482 Applications which use this media type: Emergency Services 3484 Additional information: 3486 Magic Number: None 3488 File Extension: .xml 3490 Macintosh file type code: 'TEXT' 3492 Person and email address for further information: Hannes 3493 Tschofenig, Hannes.Tschofenig@gmx.net 3495 Intended usage: LIMITED USE 3497 Author: This specification is a work item of the IETF ECRIT 3498 working group, with mailing list address . 3500 Change controller: The IESG 3502 11.5. URN Sub-Namespace Registration 3504 11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 3506 This section registers a new XML namespace, as per the guidelines in 3507 RFC 3688 [RFC3688]. 3509 URI: urn:ietf:params:xml:ns:EmergencyCallData 3511 Registrant Contact: IETF, ECRIT working group, , as 3512 delegated by the IESG . 3514 XML: 3516 BEGIN 3517 3518 3520 3521 3522 3524 Namespace for Additional Emergency Call Data 3525 3526 3527

Namespace for Additional Data related to an Emergency Call 3528

3529

See [TBD: This document].

3530 3531 3532 END 3534 11.5.2. Registration for 3535 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3537 This section registers a new XML namespace, as per the guidelines in 3538 RFC 3688 [RFC3688]. 3540 URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3542 Registrant Contact: IETF, ECRIT working group, , as 3543 delegated by the IESG . 3545 XML: 3547 BEGIN 3548 3549 3551 3552 3553 3555 Namespace for Additional Emergency Call Data: 3556 Data Provider Information 3557 3558 3559

Namespace for Additional Data related to an Emergency Call 3560

3561

Data Provider Information

3562

See [TBD: This document].

3563 3564 3565 END 3567 11.5.3. Registration for 3568 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3570 This section registers a new XML namespace, as per the guidelines in 3571 RFC 3688 [RFC3688]. 3573 URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3575 Registrant Contact: IETF, ECRIT working group, , as 3576 delegated by the IESG . 3578 XML: 3580 BEGIN 3581 3582 3584 3585 3586 3588 Namespace for Additional Emergency Call Data: 3589 Service Information 3590 3591 3592

Namespace for Additional Data related to an Emergency Call 3593

3594

Service Information

3595

See [TBD: This document].

3596 3597 3598 END 3600 11.5.4. Registration for 3601 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3603 This section registers a new XML namespace, as per the guidelines in 3604 RFC 3688 [RFC3688]. 3606 URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3608 Registrant Contact: IETF, ECRIT working group, , as 3609 delegated by the IESG . 3611 XML: 3613 BEGIN 3614 3615 3617 3618 3619 3621 Namespace for Additional Emergency Call Data: 3622 Device Information 3623 3624 3625

Namespace for Additional Data related to an Emergency Call 3626

3627

Device Information

3628

See [TBD: This document].

3629 3630 3631 END 3633 11.5.5. Registration for 3634 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3636 This section registers a new XML namespace, as per the guidelines in 3637 RFC 3688 [RFC3688]. 3639 URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3641 Registrant Contact: IETF, ECRIT working group, , as 3642 delegated by the IESG . 3644 XML: 3646 BEGIN 3647 3648 3650 3651 3652 3654 Namespace for Additional Emergency Call Data: 3655 Owner/Subscriber Information 3656 3657 3658

Namespace for Additional Data related to an Emergency Call 3659

3660

Owner/Subscriber Information

3661

See [TBD: This document].

3662 3663 3664 END 3666 11.5.6. Registration for 3667 urn:ietf:params:xml:ns:EmergencyCallData:Comment 3669 This section registers a new XML namespace, as per the guidelines in 3670 RFC 3688 [RFC3688]. 3672 URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment 3674 Registrant Contact: IETF, ECRIT working group, , as 3675 delegated by the IESG . 3677 XML: 3679 BEGIN 3680 3681 3683 3684 3685 3687 Namespace for Additional Emergency Call Data:Comment 3688 3689 3690 3691

Namespace for Additional Data related to an Emergency Call 3692

3693

Comment

3694

See [TBD: This document].

3695 3696 3697 END 3699 11.6. Schema Registrations 3701 This specification registers five schemas, as per the guidelines in 3702 RFC 3688 [RFC3688]. 3704 URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo 3706 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3707 delegated by the IESG (iesg@ietf.org). 3709 XML: The XML schema can be found in Figure 19. 3711 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3713 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3714 delegated by the IESG (iesg@ietf.org). 3716 XML: The XML schema can be found in Figure 20. 3718 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3720 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3721 delegated by the IESG (iesg@ietf.org). 3723 XML: The XML schema can be found in Figure 21. 3725 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3726 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3727 delegated by the IESG (iesg@ietf.org). 3729 XML: The XML schema can be found in Section 8.4. 3731 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3733 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3734 delegated by the IESG (iesg@ietf.org). 3736 XML: The XML schema can be found in Section 8.5. 3738 11.7. VCard Parameter Value Registration 3740 This document registers a new value in the vCARD Parameter Values 3741 registry as defined by [RFC6350] with the following template: 3743 Value: main 3745 Purpose: The main telephone number, typically of an enterprise, as 3746 opposed to a direct dial number of an individual employee 3748 Conformance: This value can be used with the "TYPE" parameter 3749 applied on the "TEL" property. 3751 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3752 00 3754 12. Acknowledgments 3756 This work was originally started in NENA and has benefited from a 3757 large number of participants in NENA standardization efforts, 3758 originally in the Long Term Definition Working Group, the Data 3759 Technical Committee and most recently the Additional Data working 3760 group. The authors are grateful for the initial work and extended 3761 comments provided by many NENA participants, including Delaine 3762 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3763 Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, 3764 and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank 3765 Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback 3766 regarding the vCard/xCard use in this specification. 3768 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3769 Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris 3770 Santer, Archie Cobbs, Magnus Nystrom, and Francis Dupont for their 3771 review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry 3772 Leiba deserves special mention for their detailed and extensive 3773 review comments, which were very helpful and appreciated. 3775 13. References 3777 13.1. Normative References 3779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3780 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3781 RFC2119, March 1997, 3782 . 3784 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3785 Locators", RFC 2392, August 1998. 3787 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3788 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3789 and QSIG Objects", RFC 3204, December 2001. 3791 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3792 A., Peterson, J., Sparks, R., Handley, M., and E. 3793 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3794 June 2002. 3796 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3797 Extensions (MIME) Parameter", RFC 3459, January 2003. 3799 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3800 DOI 10.17487/RFC3688, January 2004, 3801 . 3803 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3804 3966, December 2004. 3806 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3807 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 3808 . 3810 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3811 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3812 DOI 10.17487/RFC5226, May 2008, 3813 . 3815 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3816 October 2008. 3818 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3819 Initiation Protocol (SIP)", RFC 5621, September 2009. 3821 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3822 Languages", BCP 47, RFC 5646, September 2009. 3824 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3825 August 2011. 3827 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3828 6351, August 2011. 3830 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3831 Specifications and Registration Procedures", BCP 13, RFC 3832 6838, DOI 10.17487/RFC6838, January 2013, 3833 . 3835 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 3836 DOI 10.17487/RFC7303, July 2014, 3837 . 3839 13.2. Informational References 3841 [ECRIT-WG-wiki] 3842 IETF, "ECRIT WG Wiki"", July 2015, 3843 . 3846 [I-D.gellens-slim-negotiating-human-language] 3847 Gellens, R., "Negotiating Human Language in Real-Time 3848 Communications", draft-gellens-slim-negotiating-human- 3849 language-02 (work in progress), July 2015. 3851 [IANA-XML-Schemas] 3852 IANA, "IANA XML Schemas"", July 2015, 3853 . 3856 [LERG] Telcordia Technologies, Inc., "Local Exchange Routing 3857 Guide (LERG)", ANI II Digits Definitions , June 2015. 3859 [LanguageTagRegistry] 3860 IANA, "Language Subtag Registry", Feb 2015, 3861 . 3864 [NANP] North American Numbering Plan Administration, "ANI II 3865 Digits Assignments", September 2015, 3866 . 3869 [NENA-02-010] 3870 National Emergency Number Association (NENA), "NENA 3871 Standard Data Formats for 9-1-1 Data Exchange & GIS 3872 Mapping", NENA Standard 02-010, December 2010, 3873 . 3875 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3876 Extensions to the Session Initiation Protocol (SIP) for 3877 Asserted Identity within Trusted Networks", RFC 3325, 3878 November 2002. 3880 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3881 "Indicating User Agent Capabilities in the Session 3882 Initiation Protocol (SIP)", RFC 3840, August 2004. 3884 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 3885 Emergency Context Resolution with Internet Technologies", 3886 RFC 5012, DOI 10.17487/RFC5012, January 2008, 3887 . 3889 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3890 Format for Presence Information Data Format Location 3891 Object (PIDF-LO)", RFC 5139, February 2008. 3893 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3894 Presence Information Data Format Location Object (PIDF-LO) 3895 Usage Clarification, Considerations, and Recommendations", 3896 RFC 5491, DOI 10.17487/RFC5491, March 2009, 3897 . 3899 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 3900 Framework", RFC 5582, September 2009. 3902 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3903 Thomson, "Dynamic Extensions to the Presence Information 3904 Data Format Location Object (PIDF-LO)", RFC 5962, DOI 3905 10.17487/RFC5962, September 2010, 3906 . 3908 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3909 5985, September 2010. 3911 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3912 "Framework for Emergency Calling Using Internet 3913 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 3914 2011, . 3916 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3917 of Named Entities (DANE) Transport Layer Security (TLS) 3918 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3919 2012, . 3921 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3922 R. George, "Specifying Civic Address Extensions in the 3923 Presence Information Data Format Location Object (PIDF- 3924 LO)", RFC 6848, January 2013. 3926 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3927 Communications Services in Support of Emergency Calling", 3928 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 3929 . 3931 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3932 Morris, J., Hansen, M., and R. Smith, "Privacy 3933 Considerations for Internet Protocols", RFC 6973, July 3934 2013. 3936 [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3937 Thomson, "Relative Location Representation", RFC 7035, 3938 October 2013. 3940 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3941 Patel, "Public Safety Answering Point (PSAP) Callback", 3942 RFC 7090, DOI 10.17487/RFC7090, April 2014, 3943 . 3945 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3946 "Recommendations for Secure Use of Transport Layer 3947 Security (TLS) and Datagram Transport Layer Security 3948 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3949 2015, . 3951 [nc911] North Carolina 911 Board, "North Carolina Telecommunicator 3952 Reference", January 2009, . 3955 13.3. URIs 3957 [1] http://www.nena.org/?page=cid2014 3959 [2] http://www.nena.org/?page=CompanyID 3961 Appendix A. XML Schema for vCard/xCard 3963 This section contains the vCard/xCard XML schema version of the Relax 3964 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3965 XML schemas defined in this document. The schema in RFC 6351 3966 [RFC6351] is the normative source and this section is informative 3967 only. 3969 3970 3974 3980 3981 3982 vCard Format Specification 3983 3984 3985 3986 3987 3988 3989 3990 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4005 4006 4007 4010 4011 4012 4013 4014 4016 4017 4018 4020 4021 4022 4023 4024 4026 4027 4028 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4072 4073 4074 4075 4079 4080 4081 Section 5: Parameters 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 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 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 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 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 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 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 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 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 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 5004 5005 5006 5007 5008 5009 5010 5012 5013 5014 5015 5016 5017 5018 5020 5021 5022 5024 5026 5027 5028 5030 5031 5032 5033 5035 Appendix B. XML Validation 5037 This document defines a number of XML schemas and contains various 5038 examples. Extracting the XML and validating the examples against the 5039 schemas can be challenging, especially due to the formatting 5040 limitations introduced by IETF RFCs. For those readers who copy the 5041 XML schemas and examples directly from this document, please consider 5042 that errors might be introduced due to line breaks and extra 5043 whitespaces in the regular expressions contained in the vcard schema 5044 in Appendix A. To validate the PIDF-LO from Figure 18 it is also 5045 necessary to consult the referenced RFCs and copy the schemas 5046 necessary for successful validation. 5048 The XML schemas found in this document include a 'SchemaLocation' 5049 attribute. Depending on the location of the downloaded schema files 5050 you may need to adjust this schema location or configure your XML 5051 editor to point to the location. 5053 For convenience of readers, the schemas are available at http://ip- 5054 emergency.net/additional-data.zip and the XML examples are available 5055 at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki]. 5057 Note to RFC Editor: After IANA has published the schemas, the above 5058 link to the schemas should be replaced with [IANA-XML-Schemas]. 5060 Authors' Addresses 5061 Randall Gellens 5062 Qualcomm Technologies, Inc. 5063 5775 Morehouse Drive 5064 San Diego, CA 92121 5065 US 5067 Email: rg+ietf@qti.qualcomm.com 5069 Brian Rosen 5070 NeuStar 5071 470 Conrad Dr. 5072 Mars, PA 16046 5073 US 5075 Phone: +1 724 382 1051 5076 Email: br@brianrosen.net 5078 Hannes Tschofenig 5079 Hall in Tirol 6060 5080 Austria 5082 Email: Hannes.tschofenig@gmx.net 5083 URI: http://www.tschofenig.priv.at 5085 Roger Marshall 5086 TeleCommunication Systems, Inc. 5087 2401 Elliott Avenue 5088 Seattle, WA 98121 5089 US 5091 Phone: +1 206 792 2424 5092 Email: rmarshall@telecomsys.com 5093 URI: http://www.telecomsys.com 5095 James Winterbottom 5096 AU 5098 Email: a.james.winterbottom@gmail.com