idnits 2.17.00 (12 Aug 2021) /tmp/idnits38832/draft-ietf-ecrit-additional-data-33.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 3180 has weird spacing: '...ll-Info pur...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 19, 2015) is 2497 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 3861 -- Looks like a reference, but probably isn't: '2' on line 3863 == Missing Reference: 'This RFC' is mentioned on line 3180, 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-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 Intended status: Standards Track B. Rosen 5 Expires: January 20, 2016 NeuStar 6 H. Tschofenig 8 R. Marshall 9 TeleCommunication Systems, Inc. 10 J. Winterbottom 12 July 19, 2015 14 Additional Data Related to an Emergency Call 15 draft-ietf-ecrit-additional-data-33.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 the 26 information described here using the mechanisms described here. 28 The mechanisms permit the data to be conveyed by reference (as an 29 external resource) or by value (within the body of a SIP message or a 30 location object). This follows the tradition of prior emergency 31 services standardization work where data can be conveyed by value 32 within the call signaling (i.e., in the body of the SIP message) or 33 by reference. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 20, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Data Provider Information . . . . . . . . . . . . . . . . 9 73 4.1.1. Data Provider String . . . . . . . . . . . . . . . . 9 74 4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9 75 4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 10 76 4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 11 77 4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 12 78 4.1.6. Data Provider Languages(s) Supported . . . . . . . . 13 79 4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 13 80 4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 14 81 4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 15 82 4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 15 83 4.2. Service Information . . . . . . . . . . . . . . . . . . . 17 84 4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17 85 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18 86 4.2.3. Service Mobility Environment . . . . . . . . . . . . 20 87 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21 88 4.3. Device Information . . . . . . . . . . . . . . . . . . . 22 89 4.3.1. Device Classification . . . . . . . . . . . . . . . . 22 90 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23 91 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24 92 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24 93 4.3.5. Device/Service-Specific Additional Data Structure . . 25 94 4.3.6. Device/Service Specific Additional Data Structure 95 Type . . . . . . . . . . . . . . . . . . . . . . . . 26 96 4.3.7. Issues with getting new types of data into use . . . 26 97 4.3.8. Choosing between defining a new type of block or new 98 type of device/service specific additional data . . . 27 99 4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28 100 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28 101 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28 102 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29 103 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 30 104 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32 106 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32 107 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33 108 5.1. Transmitting Blocks using the Call-Info Header . . . . . 34 109 5.2. Transmitting Blocks by Reference using the 110 Element . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 5.3. Transmitting Blocks by Value using the 112 Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38 114 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 115 7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52 116 7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52 117 7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54 118 7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55 119 7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 57 120 7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 58 121 7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 59 122 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 123 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 63 124 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 125 10.1. Registry creation . . . . . . . . . . . . . . . . . . . 66 126 10.1.1. Provider ID Series Registry . . . . . . . . . . . . 66 127 10.1.2. Service Environment Registry . . . . . . . . . . . . 66 128 10.1.3. Service Type Registry . . . . . . . . . . . . . . . 67 129 10.1.4. Service Mobility Registry . . . . . . . . . . . . . 67 130 10.1.5. Service Provider Type Registry . . . . . . . . . . . 68 131 10.1.6. Device Classification Registry . . . . . . . . . . . 68 132 10.1.7. Device ID Type Type Registry . . . . . . . . . . . . 68 133 10.1.8. Device/Service Data Type Registry . . . . . . . . . 69 134 10.1.9. Emergency Call Data Types Registry . . . . . . . . . 69 135 10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 70 136 10.3. URN Sub-Namespace Registration for 137 Registry Entry . . . . . . . . . . . . . . . . . . . . . 71 138 10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 71 139 10.4.1. MIME Content-type Registration for 140 'application/EmergencyCallData.ProviderInfo+xml' . . 71 141 10.4.2. MIME Content-type Registration for 142 'application/EmergencyCallData.ServiceInfo+xml' . . 72 143 10.4.3. MIME Content-type Registration for 144 'application/EmergencyCallData.DeviceInfo+xml' . . . 73 146 10.4.4. MIME Content-type Registration for 147 'application/EmergencyCallData.SubscriberInfo+xml' . 74 148 10.4.5. MIME Content-type Registration for 149 'application/EmergencyCallData.Comment+xml' . . . . 75 150 10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 76 151 10.5.1. Registration for 152 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 76 153 10.5.2. Registration for 154 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf 155 o . . . . . . . . . . . . . . . . . . . . . . . . . 77 156 10.5.3. Registration for 157 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 78 158 10.5.4. Registration for 159 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 79 160 10.5.5. Registration for 161 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI 162 nfo . . . . . . . . . . . . . . . . . . . . . . . . 80 163 10.5.6. Registration for 164 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 81 165 10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 82 166 10.7. VCard Parameter Value Registration . . . . . . . . . . . 83 167 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 168 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 169 12.1. Normative References . . . . . . . . . . . . . . . . . . 84 170 12.2. Informational References . . . . . . . . . . . . . . . . 85 171 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 86 172 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 87 173 Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 109 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 176 1. Introduction 178 When an IP-based emergency call is initiated, a rich set of data from 179 multiple data sources is conveyed to the Public Safety Answering 180 Point (PSAP). This data includes information about the calling party 181 identity, the multimedia capabilities of the device, the request for 182 emergency services, location information, and meta-data about the 183 sources of the data. In addition, the device, the access network 184 provider, and any service provider in the call path has even more 185 information that is useful for a PSAP when handling an emergency. 187 This document extends the basic set of data communicated with an IP- 188 based emergency call, as described in [RFC6443] and [RFC6881], in 189 order to carry additional data which is useful to an entity or call 190 taker handling the call. This data is "additional" to the basic 191 information found in the emergency call signaling used. The intent 192 is that every emergency call carry the information described here 193 using the mechanisms described here. 195 This document defines three categories of this additional data that 196 can be transmitted with an emergency call: 198 Data Associated with a Location: Primary location data is conveyed 199 in the Presence Information Data Format Location Object (PIDF-LO) 200 data structure as defined in RFC 4119 [RFC4119] and extended by 201 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 202 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 203 geodetic location information), and [RFC7035] (for relative 204 location). This primary location data identifies the location or 205 estimated location of the caller. However, there may exist 206 additional, secondary data which is specific to the location, such 207 as floor plans, tenant and building owner contact data, heating, 208 ventilation and air conditioning (HVAC) status, etc. Such 209 secondary location data is not included in the location data 210 structure but can be transmitted using the mechanisms defined in 211 this document. Although this document does not define any 212 structures for such data, future documents may do so following the 213 procedures defined here. 215 Data Associated with a Call: While some information is carried in 216 the call setup procedure itself (as part of the SIP headers as 217 well as in the body of the SIP message), there is additional data 218 known by the device making the call, the access network to which 219 the device is connected, and service providers along the path of 220 the call. This information includes service provider contact 221 information, subscriber identity and contact information, the type 222 of service the service provider and the access network provide, 223 what type of device is being used, etc. Some data is broadly 224 applicable, while other data is dependent on the type of device or 225 service. For example, a medical monitoring device may have sensor 226 data. The data structures defined in this document (Data Provider 227 Information, Device Information, and Owner/Subscriber Information) 228 all fall into the category of "Data Associated with a Call". Note 229 that the Owner/Subscriber Information includes the subscriber's 230 vCard, which may contain personal information such as birthday, 231 anniversary, etc., but the data block itself is still considered 232 to be about the call, not the caller. 234 Data Associated with a Caller: This is personal data about a caller, 235 such as medical information and emergency contact data. Although 236 this document does not define any structures within this category, 237 future documents may do so following the procedures defined here. 239 While this document defines data structures only within the category 240 of Data Associated with a Call, by establishing the overall framework 241 of Additional Data, along with general mechanisms for transport of 242 such data, extension points and procedures for future extensions, it 243 minimizes the work needed to carry data in the other categories. 244 Other specifications may make use of the facilities provided here. 246 For interoperability, there needs to be a common way for the 247 information conveyed to a PSAP to be encoded and identified. 248 Identification allows emergency services authorities to know during 249 call processing which types of data are present and to determine if 250 they wish to access it. A common encoding allows the data to be 251 successfully accessed. 253 This document defines an extensible set of data structures, and 254 mechanisms to transmit this data either by value or by reference, 255 either in the Session Initiation Protocol (SIP) call signaling or in 256 the Presence Information Data Format Location Object (PIDF-LO). The 257 data structures are usable by other communication systems and 258 transports as well. The data structures are defined in Section 4, 259 and the transport mechanisms (using SIP and HTTPS) are defined in 260 Section 5. 262 Each data structure described in this document is encoded as a 263 "block" of information. Each block is an XML structure with an 264 associated Multipurpose Internet Mail Extensions (MIME) type for 265 identification within transport such as SIP and HTTPS. The set of 266 blocks is extensible. Registries are defined to identify the block 267 types that may be used and to allow blocks to be included in 268 emergency call signaling. 270 Much of the information supplied by service providers and devices is 271 private and confidential; service providers and devices generally go 272 to lengths to protect this information; disclosing it in the context 273 of an emergency call is a trade-off to protect the greater interest 274 of the customer in an emergency. 276 2. Terminology 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 280 document are to be interpreted as described in RFC 2119 [RFC2119]. 282 This document also uses terminology from [RFC5012]. We use the term 283 service provider to refer to an Application Service Provider (ASP). 284 A Voice Service Provider (VSP) is a special type of ASP. With the 285 term "Access Network Provider" we refer to the Internet Access 286 Provider (IAP) and the Internet Service Provider (ISP) without 287 further distinguishing these two entities, since the difference 288 between the two is not relevant for this document. Note that the 289 roles of ASP and access network provider may be provided by a single 290 company. An Emergency Services Provider is an entity directly 291 involved in providing emergency services. This includes PSAPs, 292 dispatch, police, fire, emergency medical, other responders, and 293 other similar agencies. 295 Within each data block definition (see Section 4), the values for the 296 "Use:" label are specified as one of the following: 298 'Required': means it MUST be present in the data structure. 300 'Conditional': means it MUST be present if the specified 301 condition(s) is met. It MAY be present if the condition(s) is not 302 met. 304 'Optional': means it MAY be present. 306 vCard [RFC6350] is a data format for representing and exchanging a 307 variety of information about individuals and other entities. For 308 applications that use XML, the format defined in vCard is not 309 immediately applicable. For this reason, an XML-based encoding of 310 the information elements defined in the vCard specification has been 311 defined and the name of that specification is xCard [RFC6351]. Since 312 the term vCard is more familiar to most readers, we use the terms 313 xCard and vCard interchangeably. 315 3. Document Scope 317 The scope of this document is explicitly limited to emergency calls. 318 The data structures defined here are not appropriate to be conveyed 319 with non-emergency calls because they carry sensitive and private 320 data. However, in certain private-use situations where the endpoints 321 have a preexisting relationship and privacy issues are addressed 322 within the relationship or do not apply because of it, the mechanisms 323 and data structures defined here MAY be used. 325 4. Data Structures 327 This section defines the following five data structures, each as a 328 data block. For each block we define the MIME type, and the XML 329 encoding. The five data structures are: 331 'Data Provider': This block supplies name and contact information 332 for the entity that created the data. Section 4.1 provides the 333 details. 335 'Service Information': This block supplies information about the 336 service. The description can be found in Section 4.2. 338 'Device Information': This block supplies information about the 339 device placing the call. Device information can be found in 340 Section 4.3. 342 'Owner/Subscriber': This block supplies information about the owner 343 of the device or about the subscriber. Details can be found in 344 Section 4.4. 346 'Comment': This block provides a way to supply free form human 347 readable text to the PSAP or emergency responders. This simple 348 structure is defined in Section 4.5. 350 Each block contains a mandatory element. The 351 purpose of the element is to associate all 352 blocks added by the same data provider as a unit. The 353 element associates the data provider block to 354 each of the other blocks added as a unit. Consequently, when a data 355 provider adds additional data to an emergency call (such as device 356 information) it MUST add information about itself (via the data 357 provider block) and the blocks added contain the same value in the 358 element. All blocks added by a single entity 359 at the same time MUST have the same value. 360 The value of the element has the same syntax 361 and properties (specifically, world-uniqueness) as the value of the 362 "Message-ID" message body header field specified in RFC 5322 363 [RFC5322] except that the element is not 364 enclosed in brackets (the "<" and ">" symbols are omitted). In other 365 words, the value of a element is 366 syntactically a msg-id as specified in RFC 5322 [RFC5322]. 368 Each block is added to the Additional Data Blocks Registry created in 369 Section 10.1.9 and categorized as providing data about the caller. 370 New blocks added to the registry in the future MUST also be 371 categorized per the description of the three categories in Section 1. 372 See Section 4.3.7 and Section 4.3.8 for additional considerations 373 when adding new blocks or types of data. 375 Note that the xCard format is re-used in some of the data structures 376 to provide contact information. In an xCard there is no way to 377 specify a "main" telephone number. These numbers are useful to 378 emergency responders who are called to a large enterprise. This 379 document adds a new property value to the "tel" property of the TYPE 380 parameter called "main". It can be used in any xCard in additional 381 data. 383 4.1. Data Provider Information 385 This block is intended to be supplied by any service provider in the 386 path of the call, or the access network provider, and the device. It 387 includes identification and contact information. This block MUST be 388 supplied by any entity that provides any other block; it SHOULD be 389 supplied by every service provider in the call path and by the access 390 network provider if those entities do not add any other blocks. 391 Devices SHOULD use this block to provide identifying information. 392 The MIME subtype is "application/EmergencyCallData.ProviderInfo+xml". 393 An access network provider SHOULD provide this block either by value 394 or by reference in the element of a PIDF-LO 396 4.1.1. Data Provider String 398 Data Element: Data Provider String 400 Use: Conditional. Optional for blocks supplied by the originating 401 device, mandatory otherwise. 403 XML Element: 405 Description: This is a plain text string suitable for displaying the 406 name of the service provider that supplied the data structure. If 407 the device creates the structure, it SHOULD use the value of the 408 contact header in the SIP INVITE. 410 Reason for Need: Inform the call taker of the identity of the entity 411 providing the data. 413 How Used by Call Taker: Allows the call taker to interpret the data 414 in this structure. The source of the information often influences 415 how the information is used, believed or verified. 417 4.1.2. Data Provider ID 419 Data Element: Data Provider ID 421 Use: Conditional. Optional for blocks supplied by the originating 422 device, mandatory otherwise. This data MUST be provided by all 423 entities other than the originating device in order to uniquely 424 identify the service provider or access provider. 426 XML Element: 428 Description: A jurisdiction-specific code for, or the fully- 429 qualified domain name of, the access network provider or service 430 provider shown in the element that created the 431 structure. NOTE: The value SHOULD be assigned by an organization 432 appropriate for the jurisdiction. In the U.S., if the provider is 433 registered with NENA, the provider's NENA Company ID MUST appear 434 here. Additional information can be found at NENA Company 435 Identifier Program [1] or NENA Company ID [2]. The NENA Company 436 ID MUST be in the form of a URI in the following format: 437 urn:nena:companyid:. If the organization does 438 not have an identifier registered with a jurisdiction-specific 439 emergency services registrar (such as NENA), then the value MAY be 440 the fully-qualified domain name of the service provider or access 441 provider. The device MAY use its IP address or fully-qualified 442 domain name (and set the "Data Provider ID Series" element to 443 "domain"). 445 Reason for Need: Inform the call taker of the identity of the entity 446 providing the data. 448 How Used by Call Taker: Where jurisdictions have lists of providers 449 the Data Provider ID provides useful information about the data 450 source. The Data Provider ID uniquely identifies the source of 451 the data, which might be needed especially during unusual 452 circumstances and for routine logging. 454 4.1.3. Data Provider ID Series 456 Data Element: Data Provider ID Series 458 Use: Conditional. Optional for blocks supplied by the originating 459 device, mandatory otherwise. 461 XML Element: 463 Description: Identifies the issuer of the . The 464 Provider ID Series Registry created in Section 10.1.1 initially 465 contains the entries shown in Figure 1. 467 Reason for Need: Identifies how to interpret the Data Provider ID. 468 The combination of ProviderIDSeries and ProviderID MUST be 469 globally unique. 471 How Used by Call Taker: Determines which provider ID registry to 472 consult for more information 473 +-----------+--------------------------+----------------------+ 474 | Name | Source | URL | 475 +-----------+--------------------------+----------------------+ 476 | NENA | National Emergency | http://www.nena.org | 477 | | Number Association | | 478 | EENA | European Emergency | http://www.eena.org | 479 | | Number Association | | 480 | domain | (The ID is a fully- | (not applicable) | 481 | | qualified domain name) | | 482 +-----------+--------------------------+----------------------+ 484 Figure 1: Provider ID Series Registry 486 4.1.4. Type of Data Provider 488 Data Element: Type of Data Provider 490 Use: Required. 492 XML Element: 494 Description: Identifies the type of data provider supplying the 495 data. The registry containing all valid values is created in 496 Section 10.1.5 and the initial set of values is shown in Figure 2. 498 Reason for Need: Identifies the category of data provider. 500 How Used by Call Taker: This information may be helpful when 501 deciding whom to contact when further information is needed. 503 +------------------------------+------------------------------------+ 504 | Token | Description | 505 +------------------------------+------------------------------------+ 506 |Client | Originating client/device | 507 |Access Network Provider | Access network service provider | 508 |Telecom Provider | Telecom service provider (including| 509 | | over-the-top VoIP services) | 510 |Telematics Provider | A sensor-based service provider, | 511 | | especially vehicle-based | 512 |Language Translation Provider | A spoken language translation | 513 | | service | 514 |Emergency Service Provider | An emergency service provider | 515 | | conveying information to another| 516 | | emergency service provider. | 517 |Emergency Modality Translation| An emergency-call-specific | 518 | | modality translation service | 519 | | e.g., for sign language | 520 |Relay Provider | A interpretation service, e.g., | 521 | | video relay for sign language | 522 | | interpreting | 523 |Other | Any other type of service provider | 524 +------------------------------+------------------------------------+ 526 Figure 2: Type of Data Provider Registry 528 4.1.5. Data Provider Contact URI 530 Data Element: Data Provider Contact URI 532 Use: Required 534 XML Element: 536 Description: When provided by a service provider or an access 537 network provider, this information MUST be a URI to a 24/7 support 538 organization tasked to provide PSAP support for this emergency 539 call. When provided by a device, this MUST be the contact 540 information of the user or owner of the device. (Ideally, this is 541 the contact information of the device user, but when the owner and 542 user are separate (e.g., the device owner is an organization), 543 this MAY be the contact information of the owner.) The Data 544 Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format 545 fully specified with country code. If a TEL URI is not available, 546 it MAY be a generic SIP URI. Note that this contact information 547 is not used by PSAPs for callbacks (a call from a PSAP directly 548 related to a recently terminated emergency call, placed by the 549 PSAP using a SIP Priority header field set to "psap-callback", as 550 described in [RFC7090]). 552 Reason for Need: Additional data providers may need to be contacted 553 in error cases or other unusual circumstances. 555 How Used by Call Taker: To contact the supplier of the additional 556 data for assistance in handling the call. 558 4.1.6. Data Provider Languages(s) Supported 560 Data Element: Data Provider Language(s) supported 562 Use: Required. 564 XML Element: 566 Description: This field encodes the language used by the entity at 567 the Data Provider Contact URI. The content of this field consists 568 of a single token from the language tags registry, which can be 569 found at [LanguageTagRegistry], and is defined in [RFC5646]. 570 Multiple instances of this element may occur but the order is 571 significant and the preferred language should appear first. The 572 content MUST reflect the languages supported at the contact URI. 574 (Note that this field informs the PSAP of the language(s) used by 575 the data provider. If the PSAP needs to contact the data 576 provider, it can be helpful to know in advance the language(s) 577 used by the data provider. If the PSAP uses a communication 578 protocol to reach the data provider, that protocol may have 579 language facilities of its own (such as the 'language' media 580 feature tag, defined in RFC 3840 [RFC3840] and the more extensive 581 language negotiation mechanism proposed with 582 [I-D.gellens-slim-negotiating-human-language]), and if so, those 583 are independent of this field.) 585 Reason for Need: This information indicates if the emergency service 586 authority can directly communicate with the service provider or if 587 an interpreter will be needed. 589 How Used by Call Taker: If the call taker cannot speak any language 590 supported by the service provider, a translation service will need 591 to be added to the conversation. Alternatively, other persons at 592 the PSAP, besides the call taker, might be consulted for help 593 (depending on the urgency and the type of interaction). 595 4.1.7. xCard of Data Provider 597 Data Element: xCard of Data Provider 599 Use: Optional 600 XML Element: 602 Description: Per [RFC6351] the xCard structure is represented within 603 a element. Although multiple elements may be 604 contained in a structure only one element SHOULD be 605 provided. If more than one appears, the first SHOULD be used. 606 There are many fields in the xCard and the creator of the data 607 structure is encouraged to provide all available information. N, 608 ORG, ADR, TEL, EMAIL are suggested at a minimum. N SHOULD contain 609 the name of the support group or device owner as appropriate. If 610 more than one TEL property is provided, a parameter from the vCard 611 Property Value registry MUST be specified for each TEL. For 612 encoding of the vCard this specification uses the XML-based 613 encoding specified in [RFC6351], referred to in this document as 614 "xCard". 616 Reason for Need: Information needed to determine additional contact 617 information. 619 How Used by Call Taker: Assists the call taker by providing 620 additional contact information aside from what may be included in 621 the SIP INVITE or the PIDF-LO. 623 4.1.8. Subcontractor Principal 625 When the entity providing the data is a subcontractor, the Data 626 Provider Type is set to that of the primary service provider and this 627 entry is supplied to provide information regarding the subcontracting 628 entity. 630 Data Element: Subcontractor Principal 632 Use: Conditional. This data is required if the entity providing the 633 data is a subcontractor. 635 XML Element: 637 Description: Some providers outsource their obligations to handle 638 aspects of emergency services to specialized providers. If the 639 data provider is a subcontractor to another provider this element 640 contains the DataProviderString of the service provider to 641 indicate which provider the subcontractor is working for. 643 Reason for Need: Identify the entity the subcontractor works for. 645 How Used by Call Taker: Allows the call taker to understand what the 646 relationship between data providers and the service providers in 647 the path of the call are. 649 4.1.9. Subcontractor Priority 651 Data Element: Subcontractor Priority 653 Use: Conditional. This data is required if the entity providing the 654 data is a subcontractor. 656 XML Element: 658 Description: If the subcontractor is supposed to be contacted first 659 then this element MUST have the value "sub". If the provider the 660 subcontractor is working for is supposed to be contacted first 661 then this element MUST have the value "main". 663 Reason for Need: Inform the call taker whom to contact first, if 664 support is needed. 666 How Used by Call Taker: To decide which entity to contact first if 667 assistance is needed. 669 4.1.10. ProviderInfo Example 671 672 674 string0987654321@example.org 675 676 Example VoIP Provider 677 678 urn:nena:companyid:ID123 679 NENA 680 Telecom Provider 681 tel:+1-201-555-0123 682 en 683 685 686 Hannes Tschofenig 687 688 Hannes 689 Tschofenig 690 691 692 Dipl. Ing. 693 694 --0203 695 696 20090808T1430-0500 697 698 M 699 700 1 701 702 de 703 704 705 2 706 707 en 708 709 710 work 711 712 Example VoIP Provider 713 714 715 716 work 717 721 722 723 724 Linnoitustie 6 725 Espoo 726 Uusimaa 727 02600 728 Finland 729 730 731 732 733 work 734 voice 735 736 737 tel:+358 50 4871445 738 739 740 work 741 742 hannes.tschofenig@nsn.com 743 744 745 work 746 747 geo:60.210796,24.812924 748 749 750 home 751 752 753 http://www.tschofenig.priv.at/key.asc 754 755 756 Finland/Helsinki 757 758 home 759 760 http://www.tschofenig.priv.at 761 762 763 764 766 Figure 3: EmergencyCallData.ProviderInfo Example. 768 4.2. Service Information 770 This block describes the service that the service provider provides 771 to the caller. It SHOULD be included by all service providers in the 772 path of the call. The mime subtype is "application/ 773 EmergencyCallData.ServiceInfo+xml". 775 4.2.1. Service Environment 777 Data Element: Service Environment 779 Use: Conditional: Required unless the 'ServiceType' value is 780 'wireless'. 782 XML Element: 784 Description: This element indicates whether a call is from a 785 business or residence. Currently, the only valid entries are 786 'Business', 'Residence', and 'unknown', as shown in Figure 4. New 787 values can be defined via the registry created in Section 10.1.2. 789 Reason for Need: To provide context and a hint when determining 790 equipment and manpower requirements. 792 How Used by Call Taker: Information may be used to provide context 793 and a hint to assist in determining equipment and manpower 794 requirements for emergency responders. Because there are 795 situations where the service provider does not know (such as 796 anonymous pre-paid service), and because the type of service does 797 not neccessarily reflect the nature of the premises (for example, 798 a business line installed in a residence, or wireless service), 799 and the registry is not all-encompassing, this is at best advisory 800 information, but since it mimics a similar capability in some 801 current emergency calling systems (e.g., a field in the Automatic 802 Location Information (ALI) information used with legacy North 803 American wireline systems), it is known to be valuable. The 804 service provider uses its best information (such as a rate plan, 805 facilities used to deliver service or service description) to 806 determine the information and is not responsible for determining 807 the actual characteristics of the location from which the call 808 originated. Because the usefulness is unknown (and less clear) 809 for wireless, this element is OPTIONAL for wireless and REQUIRED 810 otherwise. 812 +-----------+--------------------------+ 813 | Token | Description | 814 +-----------+--------------------------+ 815 | Business | Business service | 816 | Residence | Residential service | 817 | unknown | Type of service unknown | 818 | | (e.g., anonymous pre- | 819 | | paid service) | 820 +-----------+--------------------------+ 822 Figure 4: Service Environment Registry 824 4.2.2. Service Type 826 Data Element: Service Delivered by Provider to End User 828 Use: Required 830 XML Element: 832 Description: This defines the type of service over which the call is 833 placed (similar to the Class of Service delivered with legacy 834 emergency calls in some some regions). The implied mobility of 835 this service cannot be relied upon. A registry is created in 836 Section 10.1.3. The initial set of values is shown in Figure 5. 837 More than one value MAY be returned. For example, a VoIP inmate 838 telephone service is a reasonable combination. 840 Reason for Need: Knowing the type of service may assist the PSAP in 841 handling of the call. 843 How Used by Call Taker: Call takers often use this information to 844 determine what kinds of questions to ask callers, and how much to 845 rely on supportive information. An emergency call from a prison 846 is treated differently than a call from a sensor device. As the 847 information is not always available, and the registry is not all- 848 encompassing, this is at best advisory information, but since it 849 mimics a similar capability in some legacy emergency calling 850 systems, it is known to be valuable. 852 +--------------+----------------------------------------+ 853 | Name | Description | 854 +--------------+----------------------------------------+ 855 | wireless | Wireless Telephone Service: Includes | 856 | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but | 857 | | not satellite) | 858 | coin | Fixed public pay/coin telephones: Any | 859 | | coin or credit card operated device | 860 | one-way | One way outbound service | 861 | prison | Inmate call/service | 862 | temp | Soft dial tone/quick service/warm | 863 | | disconnect/suspended | 864 | MLTS-hosted | Hosted multi-line telephone system | 865 | | such as Centrex | 866 | MLTS-local | Local multi-line telephone system, | 867 | | includes all PBX, key systems, | 868 | | Shared Tenant Service | 869 | sensor- | These are devices that generate DATA | 870 | unattended | ONLY. This is a one-way information | 871 | | transmit without interactive media | 872 | sensor- | Devices that are supported by a | 873 | attended | monitoring service provider or that | 874 | | are capable of supporting interactive| 875 | | media | 876 | POTS | Wireline: Plain Old Telephone Service | 877 | VOIP | An over-the-top service that provides | 878 | | communication over arbitrary Internet| 879 | | access (fixed, nomadic, mobile) | 880 | remote | Off-premise extension | 881 | relay | A service where a human third-party | 882 | | agent provides additional assistance | 883 | | This includes sign language relay/ | 884 | | interpretation, telematics services | 885 | | that provide a human on the call, | 886 | | and similar services. | 887 +--------------+----------------------------------------+ 889 Figure 5: Service Delivered by Provider to End User Registry 891 4.2.3. Service Mobility Environment 893 Data Element: Service Mobility Environment 895 Use: Required 897 XML Element: 898 Description: This provides the service provider's view of the 899 mobility of the caller's device. As the service provider might 900 not know the characteristics of the actual device or access 901 network used, the value should be treated as advisory and not be 902 relied upon. A registry is created in Section 10.1.4 with the 903 initial valid entries shown in Figure 6. 905 Reason for Need: Knowing the service provider's belief of mobility 906 may assist the PSAP with the handling of the call. 908 How Used by Call Taker: To determine whether to assume the location 909 of the caller might change. 911 +-----------+----------------------------+ 912 | Token | Description | 913 +-----------+----------------------------+ 914 | Mobile | The device is able to move | 915 | | at any time | 916 | Fixed | The device is not expected | 917 | | to move unless the | 918 | | service is relocated | 919 | Nomadic | The device is not expected | 920 | | to change its point of | 921 | | attachment while on a | 922 | | call | 923 | Unknown | No information is known | 924 | | about the service | 925 | | mobility environment for | 926 | | the device | 927 +-----------+----------------------------+ 929 Figure 6: Service Environment Registry 931 4.2.4. EmergencyCallData.ServiceInfo Example 933 934 936 2468.IBOC.MLTS.1359@example.org 937 938 Business 939 MLTS-hosted 940 Fixed 941 943 Figure 7: EmergencyCallData.ServiceInfo Example. 945 4.3. Device Information 947 This block provides information about the device used to place the 948 call. It should be provided by any service provider that knows what 949 device is being used, and by the device itself. The mime subtype is 950 "application/EmergencyCallData.DeviceInfo+xml". 952 4.3.1. Device Classification 954 Data Element: Device Classification 956 Use: Optional 958 XML Element: 960 Description: This data element defines the kind of device making the 961 emergency call. If the device provides the data structure, the 962 device information SHOULD be provided. If the service provider 963 provides the structure and it knows what the device is, the 964 service provider SHOULD provide the device information. Often the 965 carrier does not know what the device is. It is possible to 966 receive two Additional Data Associated with a Call data 967 structures, one created by the device and one created by the 968 service provider. This information describes the device, not how 969 it is being used. This data element defines the kind of device 970 making the emergency call. A registry is created in 971 Section 10.1.6 with the initial set of values as shown in 972 Figure 8. 974 Reason for Need: The device classification implies the capability of 975 the calling device and assists in identifying the meaning of the 976 emergency call location information that is being presented. For 977 example, does the device require human intervention to initiate a 978 call or is this call the result of programmed instructions? Does 979 the calling device have the ability to update location or 980 condition changes? Is this device interactive or a one-way 981 reporting device? 983 How Used by Call Taker: May provide the call taker context regarding 984 the caller, the capabilities of the calling device or the 985 environment in which the device is being used, and may assist in 986 understanding the location information and capabilities of the 987 calling device. For example, a cordless handset may be outside or 988 next door. 990 +---------------+----------------------------------------+ 991 | Token | Description | 992 +---------------+----------------------------------------+ 993 |cordless | Cordless handset | 994 |fixed | Fixed phone | 995 |satellite | Satellite phone | 996 |sensor-fixed | Fixed (non mobile) sensor/alarm device | 997 |desktop | Soft client on desktop PC | 998 |laptop | Soft client on laptop type device | 999 |tablet | Soft client on tablet type device | 1000 |alarm-monitored| Alarm system | 1001 |sensor-mobile | Mobile sensor device | 1002 |aircraft | Aircraft telematics device | 1003 |automobile | Automobile/cycle/off-road telematics | 1004 |truck | Truck/construction telematics | 1005 |farm | Farm equipment telematics | 1006 |marine | Marine telematics | 1007 |personal | Personal telematics device | 1008 |feature-phone | Feature- (not smart-) cellular phone | 1009 |smart-phone | Smart-phone cellular phone (native) | 1010 |smart-phone-app| Soft client app on smart-phone | 1011 |unknown-device | Soft client on unknown device type | 1012 |game | Gaming console | 1013 |text-only | Other text device | 1014 |NA | Not Available | 1015 +---------------+----------------------------------------+ 1017 Figure 8: Device Classification Registry Initial Values 1019 4.3.2. Device Manufacturer 1021 Data Element: Device Manufacturer 1023 Use: Optional 1025 XML Element: 1027 Description: The plain language name of the manufacturer of the 1028 device. 1030 Reason for Need: Used by PSAP management for post-mortem 1031 investigation/resolution. 1033 How Used by Call Taker: Probably not used by the calltaker, but by 1034 PSAP management. 1036 4.3.3. Device Model Number 1038 Data Element: Device Model Number 1040 Use: Optional 1042 XML Element: 1044 Description: Model number of the device. 1046 Reason for Need: Used by PSAP management for after-action 1047 investigation/resolution. 1049 How Used by Call Taker: Probably not used by the calltaker, but by 1050 PSAP management. 1052 4.3.4. Unique Device Identifier 1054 Data Element: Unique Device Identifier 1056 Use: Optional 1058 XML Element: 1060 XML Attribute: 1062 Description: A string that identifies the specific device (or the 1063 device's current SIM) making the call or creating an event. Note 1064 that more than one may be present, to supply more 1065 than one of the identifying values. 1067 The attribute identifies the type of device 1068 identifier. A registry is created in Section 10.1.7 with an 1069 initial set of values shown in Figure 9. 1071 Reason for Need: Uniquely identifies the device (or, in the case of 1072 IMSI, a SIM), independent of any signaling identifiers present in 1073 the call signaling stream. 1075 How Used by Call Taker: Probably not used by the call taker; may be 1076 used by PSAP management during an investigation. (For example, if 1077 a PSAP experiences repeated false/accidental calls and there is no 1078 callback number or it isn't usable, the PSAP may need to try and 1079 track down the device using various means (e.g., contacting 1080 service providers in the area). In the case of handsets without 1081 current service, it may be possible to determine who last had 1082 service. Another example might be a disconnected call where the 1083 call taker believes there is a need for assistance but was not 1084 able to obtain a location or other information). 1086 Example: 12345 1088 +--------+------------------------------------------+ 1089 | Token | Description | 1090 +--------+------------------------------------------+ 1091 | MEID | Mobile Equipment Identifier (CDMA) | 1092 | ESN | Electronic Serial Number (GSM) | 1093 | MAC | Media Access Control Address (IEEE) | 1094 | WiMAX | Device Certificate Unique ID | 1095 | IMEI | International Mobile Equipment ID (GSM) | 1096 | IMSI | International Mobile Subscriber ID (GSM) | 1097 | UDI | Unique Device Identifier | 1098 | RFID | Radio Frequency Identification | 1099 | SN | Manufacturer Serial Number | 1100 +--------+------------------------------------------+ 1102 Figure 9: Registry of Device Identifier Types 1104 4.3.5. Device/Service-Specific Additional Data Structure 1106 Data Element: Device/service-specific additional data structure 1108 Use: Optional 1110 XML Element: 1112 Description: A URI representing additional data whose schema is 1113 specific to the device or service which created it. (For example, 1114 a medical device or medical device monitoring service may have a 1115 defined set of medical data). The URI, when dereferenced, MUST 1116 yield a data structure defined by the Device/service specific 1117 additional data type value. Different data may be created by each 1118 classification; e.g., a medical device created data set. 1120 Reason for Need: Provides device/service specific data that may be 1121 used by the call taker and/or responders. 1123 How Used by Call Taker: Provide information to guide call takers to 1124 select appropriate responders, give appropriate pre-arrival 1125 instructions to callers, and advise responders of what to be 1126 prepared for. May be used by responders to guide assistance 1127 provided. 1129 4.3.6. Device/Service Specific Additional Data Structure Type 1131 Data Element: Type of device/service-specific additional data 1132 structure 1134 Use: Conditional. MUST be provided when device/service specific- 1135 additional URI is provided 1137 XML Element: 1139 Description: A value from the registry defined in Section 10.1.8 to 1140 describe the type of data located at the device/service-specific 1141 additional data structure. The initial values shown in Figure 10 1142 currently only include IEEE 1512, which is the USDoT model for 1143 traffic incidents. 1145 Reason for Need: This data element allows identification of 1146 externally defined schemas, which may have additional data that 1147 may assist in emergency response. 1149 How Used by Call Taker: This data element allows the end user (call 1150 taker or first responder) to know what type of additional data may 1151 be available to aid in providing the needed emergency services. 1153 Note: Information which is specific to a location or a caller 1154 (person) should not be placed in this section. 1156 +----------+----------------------------+--------------------------------+ 1157 | Token | Description | Specification | 1158 +----------+----------------------------+--------------------------------+ 1159 | IEEE1512 | Common Incident Management |IEEE 1512-2006 | 1160 | | Message Set (USDoT model |https://standards.ieee.org/ | 1161 | | for traffic incidents) |findstds/standard/1512-2006.html| 1162 +----------+----------------------------+--------------------------------+ 1164 Figure 10: Device/Service Data Type Registry 1166 4.3.7. Issues with getting new types of data into use 1168 This document describes two mechanisms that allow extension of the 1169 kind of data provided with an emergency call: define a new block or 1170 define a new service specific additional data URL for the DeviceInfo 1171 block. While defining new data types and getting a new device or 1172 application to send the new data may be easy, getting PSAPs and 1173 responders to actually retrieve the data and use it will be 1174 difficult. New mechanism providers should understand that acquiring 1175 and using new forms of data usually require software upgrades at the 1176 PSAP and/or responders, as well as training of call takers and 1177 responders in how to interpret and use the information. Legal and 1178 operational review may also be needed. Overwhelming a call taker or 1179 responder with too much information is highly discouraged. Thus, the 1180 barrier to supporting new data is quite high. 1182 The mechanisms this document describes are meant to encourage 1183 development of widely supported, common data formats for classes of 1184 devices. If all manufacturers of a class of device use the same 1185 format, and the data can be shown to improve outcomes, then PSAPs and 1186 responders may be encouraged to upgrade their systems and train their 1187 staff to use the data. Variations, however well intentioned, are 1188 unlikely to be supported. 1190 Implementers should consider that data from sensor-based devices in 1191 some cases may not be useful to call takers or PSAPs (and privacy, 1192 liability, or other considerations might preclude the PSAP from 1193 touching the data), but may be of use to responders. Each data item 1194 provided with the call in conformance with this document can be 1195 accessed by responders or other entities in the emergency services, 1196 whether or not the data is accessed by the PSAP. 1198 4.3.8. Choosing between defining a new type of block or new type of 1199 device/service specific additional data 1201 For devices that have device or service specific data, there are two 1202 choices to carry it. A new block can be defined, or the device/ 1203 service specific additional data URL the DeviceInfo block can be used 1204 and a new type for it defined . The data passed would likely be the 1205 same in both cases. Considerations for choosing which mechanism to 1206 register under include: 1208 Applicability: Information which will be carried by many kinds of 1209 devices or services are more appropriately defined as separate 1210 blocks. 1212 Privacy: Information which may contain private data may be better 1213 sent in the DeviceInfo block, rather than a new block so that 1214 implementations are not tempted to send the data by value, and 1215 thus having more exposure to the data than forcing the data to be 1216 retrieved via the URL in DeviceInfo. 1218 Size: Information which may be very large may be better sent in the 1219 DeviceInfo block, rather than a new block so that implementations 1220 are not tempted to send the data by value. Conversely, data which 1221 is small may best be sent in a separate block so that it can be 1222 sent by value 1224 Availability of a server: Providing the data via the device block 1225 requires a server be made available to retrieve the data. 1226 Providing the data via new block allows it to be sent by value 1227 (CID). 1229 4.3.9. EmergencyCallData.DeviceInfo Example 1231 1232 1234 d4b3072df.201409182208075@example.org 1235 1236 fixed 1237 Nokia 1238 Lumia 800 1239 35788104 1240 1241 1243 Figure 11: EmergencyCallData.DeviceInfo Example. 1245 4.4. Owner/Subscriber Information 1247 This block describes the owner of the device (if provided by the 1248 device) or the subscriber information (if provided by a service 1249 provider). The contact location is not necessarily the location of 1250 the caller or incident, but is rather the nominal contact address. 1251 The MIME type is "application/EmergencyCallData.SubscriberInfo+xml". 1253 In some jurisdictions some or all parts of the subscriber-specific 1254 information are subject to privacy constraints. These constraints 1255 vary but dictate which information can be displayed and logged. A 1256 general privacy indicator expressing a desire for privacy by the 1257 subscriber is provided. The interpretation of how this is applied is 1258 left to the receiving jurisdiction as the custodians of the local 1259 regulatory requirements. This matches an equivalent privacy flag 1260 provided in some legacy emergency call systems. 1262 4.4.1. Subscriber Data Privacy Indicator 1264 Attribute: 'privacyRequested', Boolean. 1266 Use: Conditional. This attribute MUST be provided if the owner/ 1267 subscriber information block is not empty. 1269 Description: The subscriber data privacy indicator specifically 1270 expresses the subscriber's desire for privacy. In some 1271 jurisdictions subscriber services can have a specific "Type of 1272 Service" which prohibits information, such as the name of the 1273 subscriber, from being displayed. This attribute is provided to 1274 explicitly indicate whether the subscriber service includes such 1275 constraints. The interpretation of this indicator is left to each 1276 jurisdiction (in keeping with the semantics of the privacy 1277 indicator provided in some legacy emergency call systems). 1278 Because the interpretation of this indicator varies based on local 1279 regulations, this document cannot describe the exact semantics nor 1280 indicate which fields are affected (the application of this 1281 indicator might affect the display of data contained in any of the 1282 blocks). 1284 Reason for Need: Some jurisdictions require subscriber privacy to be 1285 observed when processing emergency calls. 1287 How Used by Call Taker: Where privacy is indicated the call taker 1288 may not have access to some aspects of the subscriber information. 1290 4.4.2. xCard for Subscriber's Data 1292 Data Element: xCARD for Subscriber's Data 1294 Use: Conditional. Subscriber data MUST be provided unless it is not 1295 available. Some services, such as prepaid phones, non-initialized 1296 phones, etc., do not have information about the subscriber. 1298 XML Element: 1300 Description: Information known by the service provider or device 1301 about the subscriber; e.g., Name, Address, Individual Telephone 1302 Number, Main Telephone Number and any other data. , (if 1303 appropriate), , , are suggested at a minimum. 1304 If more than one property is provided, a parameter from the 1305 vCard Property Value registry MUST be specified on each . 1306 While some data (such as ) might not seem obviously 1307 relevant for emergency services, any data is potentially useful in 1308 some emergency circumstances. 1310 Reason for Need: When the caller is unable to provide information, 1311 this data may be used to obtain it 1313 How Used by Call Taker: Obtaining critical information about the 1314 caller and possibly the location when it is not able to be 1315 obtained otherwise. While the location here is not necessarily 1316 that of caller, in some circumstances it can be helpful in 1317 locating the caller when other means have failed. 1319 4.4.3. EmergencyCallData.SubscriberInfo Example 1321 1322 1326 FEABFECD901@example.org 1327 1328 1329 1330 Simon Perreault 1331 1332 Perreault 1333 Simon 1334 1335 1336 ing. jr 1337 M.Sc. 1338 1339 --0203 1340 1341 20090808T1430-0500 1342 1343 M 1344 1345 1 1346 1347 fr 1348 1349 1350 2 1351 1352 en 1353 1354 1355 work 1356 1357 Viagenie 1358 1359 1360 1361 work 1362 1367 1368 1369 1370 2875 boul. Laurier, suite D2-630 1371 Quebec 1372 QC 1373 G1V 2M2 1374 Canada 1375 1376 1377 1378 1379 work 1380 voice 1381 1382 1383 tel:+1-418-656-9254;ext=102 1384 1385 1386 1387 1388 work 1389 text 1390 voice 1391 cell 1392 video 1393 1394 1395 tel:+1-418-262-6501 1396 1397 1398 work 1399 1400 simon.perreault@viagenie.ca 1401 1402 1403 work 1404 1405 geo:46.766336,-71.28955 1406 1407 1408 work 1409 1410 1411 http://www.viagenie.ca/simon.perreault/simon.asc 1412 1413 1414 America/Montreal 1415 1416 home 1417 1418 http://nomis80.org 1419 1420 1421 1422 1424 Figure 12: EmergencyCallData.SubscriberInfo Example. 1426 4.5. Comment 1428 This block provides a mechanism for the data provider to supply 1429 extra, human readable information to the PSAP. It is not intended 1430 for a general purpose extension mechanism nor does it aim to provide 1431 machine-readable content. The mime subtype is "application/ 1432 EmergencyCallData.Comment+xml" 1434 4.5.1. Comment 1436 Data Element: EmergencyCallData.Comment 1438 Use: Optional 1440 XML Element: 1442 Description: Human readable text providing additional information to 1443 the PSAP staff. 1445 Reason for Need: Explanatory information for values in the data 1446 structure. 1448 How Used by Call Taker: To interpret the data provided. 1450 4.5.2. EmergencyCallData.Comment Example 1452 1453 1455 string0987654321@example.org 1456 1457 This is an example text. 1458 1460 Figure 13: EmergencyCallData.Comment Example. 1462 5. Data Transport Mechanisms 1464 This section defines how to convey additional data to an emergency 1465 service provider. Two different means are specified: the first uses 1466 the call signaling; the second uses the element of a 1467 PIDF-LO [RFC4119]. 1469 1. First, the ability to embed a Uniform Resource Identifier (URI) 1470 in an existing SIP header field, the Call-Info header, is 1471 defined. The URI points to the additional data structure. The 1472 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1473 document adds a new compound token starting with the value 1474 'EmergencyCallData' for the Call-Info "purpose" parameter. If 1475 the "purpose" parameter is set to a value starting with 1476 'EmergencyCallData', then the Call-Info header contains either an 1477 HTTPS URL pointing to an external resource or a CID (content 1478 indirection) URI that allows the data structure to be placed in 1479 the body of the SIP message. The "purpose" parameter also 1480 indicates the kind of data (by its MIME subtype) that is 1481 available at the URI. As the data is conveyed using a URI in the 1482 SIP signaling, the data itself may reside on an external 1483 resource, or may be contained within the body of the SIP message. 1484 When the URI refers to data at an external resource, the data is 1485 said to be passed by reference. When the URI refers to data 1486 contained within the body of the SIP message, the data is said to 1487 be passed by value. A PSAP or emergency responder is able to 1488 examine the type of data provided and selectively inspect the 1489 data it is interested in, while forwarding all of it (the values 1490 or references) to downstream entities. To be conveyed in a SIP 1491 body, additional data about a call is defined as a series of MIME 1492 objects. Each block defined in this document is an XML data 1493 structure identified by its MIME type. (Blocks defined by others 1494 may be encoded in XML or not, as identified by their MIME 1495 registration.) As usual, whenever more than one MIME part is 1496 included in the body of a message, MIME multipart (i.e., 1497 'multipart/mixed') encloses them all. This document defines a 1498 set of XML schemas and MIME types used for each block defined 1499 here. When additional data is passed by value in the SIP 1500 signaling, each CID URL points to one block in the body. 1501 Multiple URIs are used within a Call-Info header field (or 1502 multiple Call-Info header fields) to point to multiple blocks. 1503 When additional data is provided by reference (in SIP signaling 1504 or the element of a PIDF-LO), each HTTPS URL 1505 references one block; the data is retrieved with an HTTPS GET 1506 operation, which returns the block as an object (the blocks 1507 defined here are returned as XML objects). 1509 2. Second, the ability to embed additional data structures in the 1510 element of a PIDF-LO [RFC4119] is defined. In 1511 addition to service providers in the call path, the access 1512 network provider may also have similar information that can be 1513 valuable to the PSAP. When the access network provider supplies 1514 location information in the form of a PIDF-LO from a location 1515 server via a location configuration protocol, it has the ability 1516 to add the data structures defined in this document within the 1517 PIDF-LO. The data in these data structures is not specific to 1518 the location itself, but rather provides descriptive information 1519 having to do with the immediate circumstances about the provision 1520 of the location (e.g., the identity of the access network 1521 provider, how to contact that entity, what kind of service the 1522 access network provides, subscriber information, etc.). This 1523 data is similar in nearly every respect to the data known by 1524 service providers in the path of the call. When the access 1525 network provider and service provider are separate entities, the 1526 access network does not participate in the application layer 1527 signaling (and hence cannot add a Call-Info header field to the 1528 SIP message), but can provide location information in a PIDF-LO. 1529 The element of the PIDF-LO is a mechanism for the 1530 access network provider to supply the information. For this 1531 reason, this document describes a namespace per [RFC4119] for 1532 inclusion in the element of a PIDF-LO for adding 1533 information known to the access network provider. The access 1534 network provider SHOULD provide additional data within a 1535 element of a PDIF-LO it returns for emergency use 1536 (e.g., if requested with a HELD "responseTime" attribute of 1537 "emergencyRouting" or "emergencyDispatch" [RFC5985]). 1539 One or more blocks of data registered in the Emergency Call 1540 Additional Data registry, as defined in Section 10.1.9, can be 1541 included or referenced in the SIP signaling (using the Call-Info 1542 header field) or in the element of a PIDF-LO. For 1543 interoperability, only blocks in the registry are permitted to be 1544 sent using the mechanisms specified in this document. Since multiple 1545 entities are expected to provide sets of data, the data itself needs 1546 information describing the source. Consequently, each entity adding 1547 additional data MUST supply a "Data Provider" block. All other 1548 blocks are optional, but each entity SHOULD supply all blocks where 1549 it has at least some of the information in the block. 1551 5.1. Transmitting Blocks using the Call-Info Header 1553 A URI to a block MAY be inserted in any SIP request or response 1554 method (most often INVITE or MESSAGE) with a Call-Info header field 1555 containing a purpose value starting with 'EmergencyCallData', a dot 1556 ("."), and the type of data available at the URI. The type of data 1557 is denoted by including the root of the MIME subtype (the 1558 'EmergencyCallData' prefix is not repeated), omitting any suffix such 1559 as '+xml'). For example, when referencing a block with MIME type 1560 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 1561 parameter is set to 'EmergencyCallData.ProviderInfo'. An example 1562 "Call-Info" header field for this would be: 1564 Call-Info: https://www.example.com/23sedde3; 1565 purpose="EmergencyCallData.ProviderInfo" 1567 A Call-info header with a purpose value starting with 1568 'EmergencyCallData' only has meaning in the context of an emergency 1569 call (as ascertained by the presence of an emergency service URN in a 1570 Request-URI header of a SIP message), test emergency calls (using an 1571 appropriate service URN), and some private-use calls where the 1572 endpoints have a preexisting relationship and privacy concerns do not 1573 apply because of the relationship; use in other contexts is undefined 1574 and is likely to unnecessarily expose confidential data. 1576 If the data is provided by reference, an HTTPS URI MUST be included 1577 and consequently Transport Layer Security (TLS) protection is applied 1578 for protecting the retrieval of the information. 1580 The data may also be supplied by value in any SIP request or response 1581 method that is permitted to contain a body (i.e., not a BYE request). 1582 In this case, Content Indirection (CID) [RFC2392] is used, with the 1583 CID URL referencing the MIME body part containing the data. Note 1584 that [RFC3261] forbids proxies from altering message bodies, so 1585 entities in the call path that add blocks by value need to do so 1586 using an appropriate SIP entity (e.g., a back-to-back user agent). 1588 Transmitting data by value is especially useful in certain cases, 1589 such as when the data exists in or is generated by the originating 1590 device, but is not intended for very large data blocks. Additional 1591 security and privacy considerations apply to data transmitted by 1592 value, as discussed in Section 8 and Section 9. 1594 More than one Call-Info header with a purpose value starting with 1595 'EmergencyCallData' can be expected, but at least one MUST be 1596 provided. The device MUST provide one if it knows no service 1597 provider is in the path of the call. The device MAY insert one if it 1598 uses a service provider. Any service provider in the path of the 1599 call MUST insert its own. For example, a device, a telematics 1600 service provider in the call path, as well as the mobile carrier 1601 handling the call will each provide one. There may be circumstances 1602 where there is a service provider who is unaware that the call is an 1603 emergency call and cannot reasonably be expected to determine that it 1604 is an emergency call. In that case, that service provider is not 1605 expected to provide EmergencyCallData. 1607 5.2. Transmitting Blocks by Reference using the Element 1609 The element is used to transmit an 1610 additional data block by reference within a element of 1611 a PIDF-LO. The element has two 1612 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1613 type of data block referenced. The value of 'ref' is an HTTPS URL 1614 that resolves to a data structure with information about the call. 1615 The value of 'purpose' is the same as used in a 'Call-Info' header 1616 field (as specified in Section 5.1). 1618 For example, to reference a block with MIME type 'application/ 1619 EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set 1620 to 'EmergencyCallData.ProviderInfo'. An example 1621 element for this would be: 1623 1626 The element transmits one data block; 1627 multiple data blocks may be transmitted by using multiple 1628 elements. Multiple 1629 elements MAY be included as child 1630 elements inside the element. 1632 The following is a simplified example: 1634 1639 1643 1646 1648 Example by Reference 1650 For an example in context, Figure 18 shows a PIDF-LO example with an 1651 element pointing to an 1652 EmergencyCallData.ServiceInfo data block with the URL in the 'ref' 1653 attribute and the purpose attribute set to 1654 "EmergencyCallData.ServiceInfo". 1656 5.3. Transmitting Blocks by Value using the Element 1658 It is RECOMMENDED that access networks supply the data specified in 1659 this document by reference, but they MAY provide the data by value. 1661 The element is used to transmit one or more 1662 additional data blocks by value within a element of a 1663 PIDF-LO. Each block being transmitted is placed (as a child element) 1664 inside the element. (The same XML structure 1665 as would be contained in the corresponding MIME type body part is 1666 placed inside the element.) Multiple 1667 elements MAY be included as child elements 1668 in the element. 1670 The following is a simplified example: 1672 1676 1679 flurbit735@es.example.com 1680 1681 Access Network Examples, Inc 1682 1683 urn:nena:companyid:Test 1684 NENA 1685 Access Network Provider 1686 1687 tel:+1-555-555-0897 1688 en 1689 1691 1694 flurbit735@es.example.com 1695 1696 This is an example text. 1697 1698 1700 1702 1704 Example by Value 1706 For an example in context, Figure 18 shows a PIDF-LO example that 1707 contains a element with the 1708 and the 1709 elements as child elements of an element. 1711 5.4. The Content-Disposition Parameter 1713 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1714 It updates and clarifies handling originally defined in RFC 3261 1715 [RFC3261] based on implementation experience. While RFC 3261 did not 1716 mandate support for 'multipart' message bodies, 'multipart/mixed' 1717 MIME bodies are used by many extensions (including this document) 1718 today. For example, adding a PIDF-LO, SDP, and additional data in 1719 body of a SIP message requires a 'multipart' message body. 1721 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1722 parameter for the Content-Disposition header field. These RFCs 1723 describe how a UAS reacts if it receives a message body whose content 1724 type or disposition type it does not understand. If the 'handling' 1725 parameter has the value "optional", the UAS ignores the message body. 1726 If the 'handling' parameter has the value "required", the UAS returns 1727 a 415 (Unsupported Media Type) response. The 'by-reference' 1728 disposition type allows a SIP message to contain a reference to the 1729 body part, and the SIP UA processes the body part according to the 1730 reference. This is the case for the Call-info header containing a 1731 Content Indirection (CID) URL. 1733 As an example, a SIP message indicates the Content-Disposition 1734 parameter in the body of the SIP message as shown in Figure 14. 1736 Content-Type: application/sdp 1738 ...Omit Content-Disposition here; defaults are ok 1739 ...SDP goes in here 1741 --boundary1 1743 Content-Type: application/pidf+xml 1744 Content-ID: 1745 Content-Disposition: by-reference;handling=optional 1747 ...PIDF-LO goes in here 1749 --boundary1-- 1751 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1752 Content-ID: <1234567890@atlanta.example.com> 1753 Content-Disposition: by-reference; handling=optional 1755 ...Data provider information data goes in here 1757 --boundary1-- 1759 Figure 14: Example for use of the Content-Disposition Parameter in 1760 SIP 1762 6. Examples 1764 This section illustrates a longer and more complex example, as shown 1765 in Figure 15. In this example additional data is added by the end 1766 device, included by the VoIP provider, and provided by the access 1767 network provider (via the PIDF-LO). 1769 O +----+ [============] [=============] 1770 /|\ | UA | [ Access ] [ VoIP ] 1771 | +----+ [ Network ] [ Provider ] 1772 / \ [ Provider ] [ example.org ] 1773 [ ] [ ] 1774 (1) [ ] (2) [ ] 1775 Emergency Call [ ] Emergency Call [ ] 1776 ------------------------------------------------------> ] 1777 +Device Info [ ] +Device Info [ ] 1778 +Data Prov. Info [ ^ ] +Data Provider Info [ | ] 1779 +Location URI [=======.====] +Location URI [====|========] 1780 . | 1781 . | 1782 +Location . [==============] | 1783 +Owner/Subscriber Info . [ ] (3) | 1784 +Device Info . (4) [ <------------+ 1785 +Data Provider Info #3 ..........> ] Emergency Call 1786 [ ] +Device Info 1787 [ PSAP ] +Data Prov. Info #2 1788 [ ] +Location URI 1789 [==============] 1791 Legend: 1793 --- Emergency Call Setup Procedure 1794 ... Location Retrieval/Response 1796 Figure 15: Additional Data Example Flow 1798 The example scenario starts with the end device itself adding device 1799 information, owner/subscriber information, a location URI, and data 1800 provider information to the outgoing emergency call setup message 1801 (see step #1 in Figure 15). The SIP INVITE example is shown in 1802 Figure 16. 1804 INVITE urn:service:sos SIP/2.0 1805 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1806 Max-Forwards: 70 1807 To: 1808 From: Hannes Tschofenig ;tag=9fxced76sl 1809 Call-ID: 3848276298220188511@example.com 1810 Call-Info: 1811 ;purpose=icon, 1812 ;purpose=info, 1813 1814 ;purpose=EmergencyCallData.ProviderInfo, 1815 1816 ;purpose=EmergencyCallData.DeviceInfo 1817 Geolocation: 1818 Geolocation-Routing: yes 1819 Accept: application/sdp, application/pidf+xml, 1820 application/EmergencyCallData.ProviderInfo+xml 1821 CSeq: 31862 INVITE 1822 Contact: 1823 Content-Type: multipart/mixed; boundary=boundary1 1825 Content-Length: ... 1827 --boundary1 1829 Content-Type: application/sdp 1831 ...SDP goes here 1833 --boundary1-- 1835 Content-Type: application/EmergencyCallData.DeviceInfo+xml 1836 Content-ID: <0123456789@atlanta.example.com> 1837 Content-Disposition: by-reference;handling=optional 1838 1840 1842 d4b3072df09876543@[93.184.216.119] 1843 1844 laptop 1845 00-0d-4b-30-72-df 1847 1849 --boundary1-- 1851 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1852 Content-ID: <1234567890@atlanta.example.com> 1853 Content-Disposition: by-reference;handling=optional 1854 1855 1857 d4b3072df09876543@[93.184.216.119] 1858 1859 Hannes Tschofenig 1860 1861 Client 1862 tel:+1-555-555-0123 1863 en 1864 1866 1867 Hannes Tschofenig 1868 1869 Hannes 1870 Tschofenig 1871 1872 1873 Dipl. Ing. 1874 1875 --0203 1876 1877 20090808T1430-0500 1878 1879 M 1880 1881 1 1882 1883 de 1884 1885 1886 2 1887 1888 en 1889 1890 1891 1892 work 1893 1897 1898 1899 1900 Linnoitustie 6 1901 Espoo 1902 Uusimaa 1903 02600 1904 Finland 1905 1906 1907 1908 home 1909 1914 1915 1916 1917 42 W 11th St 1918 Wilmington 1919 DE 1920 19801 1921 USA 1922 1923 1924 1925 1926 work 1927 voice 1928 1929 1930 tel:+358 50 4871445 1931 1932 1933 1934 1935 home 1936 voice 1937 1938 1939 tel:+1 555 555 0123 1940 1941 1942 work 1943 1944 hannes.tschofenig@nsn.com 1945 1946 1947 work 1948 1949 geo:60.210796,24.812924 1950 1951 1952 home 1953 1954 geo:39.746537,-75.548027 1955 1956 1957 1958 home 1959 1960 https://www.example.com/key.asc 1961 1962 1963 Finland/Helsinki 1964 1965 home 1966 1967 http://example.com/hannes.tschofenig 1968 1969 1970 1971 1972 1973 --boundary1-- 1975 Figure 16: End Device sending SIP INVITE with Additional Data 1977 In this example, information available to the access network provider 1978 is included in the call setup message only indirectly via the use of 1979 the location reference. The PSAP has to retrieve it via a separate 1980 look-up step. Since the access network provider and the VoIP service 1981 provider are two independent entities in this scenario, the access 1982 network provider is not involved in application layer exchanges; the 1983 SIP INVITE transits the access network transparently, as illustrated 1984 in steps #1 and #2 (the access network does not alter the SIP 1985 INVITE). 1987 The VoIP service provider receives the message and determines, based 1988 on the Service URN, that the incoming request is an emergency call. 1989 It performs typical emergency services related tasks (such as 1990 location-based routing), and adds additional data, namely service and 1991 subscriber information as well as data provider information #2, to 1992 the outgoing message. For the example we assume a VoIP service 1993 provider that deploys a back-to-back user agent allowing additional 1994 data to be included in the body of the SIP message (rather than by 1995 reference), which allows us to illustrate the use of multiple data 1996 provider info blocks. The resulting message is shown in Figure 17. 1997 The SIP INVITE is sent to the PSAP in step #3. 1999 INVITE sips:psap@example.org SIP/2.0 2000 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 2001 Max-Forwards: 70 2002 To: 2003 From: Hannes Tschofenig ;tag=9fxced76sl 2004 Call-ID: 3848276298220188511@example.com 2005 Call-Info: 2006 ;purpose=icon, 2007 ;purpose=info, 2008 2009 ;purpose=EmergencyCallData.ProviderInfo 2010 2011 ;purpose=EmergencyCallData.DeviceInfo 2012 Call-Info: 2013 ;purpose=EmergencyCallData.ServiceInfo 2014 Call-Info: 2015 ;purpose=EmergencyCallData.ProviderInfo 2016 Geolocation: 2017 Geolocation-Routing: yes 2018 Accept: application/sdp, application/pidf+xml, 2019 application/EmergencyCallData.ProviderInfo+xml 2020 CSeq: 31862 INVITE 2021 Contact: 2022 Content-Type: multipart/mixed; boundary=boundary1 2024 Content-Length: ... 2026 --boundary1 2028 Content-Type: application/sdp 2030 ...SDP goes here 2032 --boundary1-- 2034 Content-Type: application/EmergencyCallData.DeviceInfo+xml 2035 Content-ID: <0123456789@atlanta.example.com> 2036 Content-Disposition: by-reference;handling=optional 2037 2039 2041 d4b3072df09876543@[93.184.216.119] 2042 2043 laptop 2044 00-0d-4b-30-72-df 2046 2048 --boundary1-- 2050 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2051 Content-ID: <1234567890@atlanta.example.com> 2052 Content-Disposition: by-reference;handling=optional 2053 2054 2056 d4b3072df09876543@[93.184.216.119] 2057 2058 Hannes Tschofenig 2059 2060 Client 2061 tel:+1-555-555-0123 2062 en 2063 2065 2066 Hannes Tschofenig 2067 2068 Hannes 2069 Tschofenig 2070 2071 2072 Dipl. Ing. 2073 2074 --0203 2075 2076 20090808T1430-0500 2077 2078 M 2079 2080 1 2081 2082 de 2083 2084 2085 2 2086 2087 en 2088 2089 2090 2091 work 2092 2096 2097 2098 2099 Linnoitustie 6 2100 Espoo 2101 Uusimaa 2102 02600 2103 Finland 2104 2105 2106 2107 home 2108 2113 2114 2115 2116 42 W 11th St 2117 Wilmington 2118 DE 2119 19801 2120 USA 2121 2122 2123 2124 2125 work 2126 voice 2127 2128 2129 tel:+358 50 4871445 2130 2131 2132 2133 2134 home 2135 voice 2136 2137 2138 tel:+1 555 555 0123 2139 2140 2141 work 2142 2143 hannes.tschofenig@nsn.com 2144 2145 2146 work 2147 2148 geo:60.210796,24.812924 2149 2150 2151 home 2152 2153 geo:39.746537,-75.548027 2154 2155 2156 2157 home 2158 2159 https://www.example.com/key.asc 2160 2161 2162 Finland/Helsinki 2163 2164 home 2165 2166 http://example.com/hannes.tschofenig 2167 2168 2169 2170 2171 2173 --boundary1-- 2175 Content-Type: application/EmergencyCallData.ServiceInfo+xml 2176 Content-ID: 2177 Content-Disposition: by-reference;handling=optional 2178 2179 2181 string0987654321@example.org 2182 2183 Residence 2184 VOIP 2185 Unknown 2187 2189 --boundary1-- 2191 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2192 Content-ID: 2193 Content-Disposition: by-reference;handling=optional 2194 2195 2197 string0987654321@example.org 2198 2199 Exemplar VoIP Provider 2200 2201 urn:nena:companyid:ID123 2202 NENA 2203 Service Provider 2204 sip:voip-provider@example.com 2205 en 2206 2208 2209 John Doe 2210 2211 John 2212 Doe 2213 2214 2215 2216 2217 --0203 2218 2219 20090808T1430-0500 2220 2221 M 2222 2223 1 2224 2225 en 2226 2227 2228 work 2229 2230 Exemplar VoIP Provider 2231 2232 2233 2234 work 2235 2238 2239 2240 2241 123 Middle Street 2242 the Sticks 2243 IA 2244 50055 2245 USA 2246 2247 2248 2249 2250 work 2251 voice 2252 2253 2254 sips:john.doe@example.com 2255 2256 2257 work 2258 2259 john.doe@example.com 2260 2261 2262 work 2263 2264 geo:41.761838,-92.963268 2265 2266 America/Chicago 2267 2268 home 2269 2270 http://www.example.com/john.doe 2271 2272 2273 2274 2276 Figure 17: VoIP Provider sending SIP INVITE with Additional Data 2278 Finally, the PSAP requests location information from the access 2279 network provider. The response is shown in Figure 18. Along with 2280 the location information, additional data is provided in the 2281 element of the PIDF-LO. This request and response is 2282 step #4. 2284 2285 2290 2291 2292 2293 2295 US 2296 DE 2297 Wilmington 2298 W 2299 11th 2300 Street 2301 42 2302 The Hotel DuPont 2303 19801 2304 2305 2306 2307 true 2308 2309 2013-12-10T20:00:00Z 2310 2311 2312 802.11 2314 2317 2321 2322 2325 88QV4FpfZ976T@example.com 2326 2327 Diamond State Exemplar 2328 2329 urn:nena:companyid:diamond 2330 NENA 2331 Access Network Provider 2332 tel:+1-302-555-0000 2333 en 2334 2336 2338 88QV4FpfZ976T@example.com 2339 2340 This is an example text. 2341 2343 2344 2345 2346 mac:00-0d-4b-30-72-df 2347 2013-07-09T20:57:29Z 2348 2349 2351 Figure 18: Access Network Provider returning PIDF-LO with Additional 2352 Data 2354 7. XML Schemas 2356 This section defines the XML schemas of the five data blocks. 2357 Additionally, the provided-by schema is specified. 2359 7.1. EmergencyCallData.ProviderInfo XML Schema 2361 2362 2372 2375 2378 2382 2383 2384 2385 2386 2387 2389 2390 2391 2394 2397 2400 2403 2406 2409 2410 2411 2412 2418 2419 2420 2422 2425 2426 2427 2429 2430 2431 2433 2436 2440 2442 2443 2445 2447 Figure 19: EmergencyCallData.ProviderInfo XML Schema. 2449 7.2. EmergencyCallData.ServiceInfo XML Schema 2450 2451 2460 2463 2466 2467 2468 2471 2474 2478 2481 2483 2484 2486 2488 Figure 20: EmergencyCallData.ServiceInfo XML Schema. 2490 7.3. EmergencyCallData.DeviceInfo XML Schema 2492 2493 2502 2505 2508 2509 2510 2513 2516 2519 2522 2524 2525 2526 2527 2530 2531 2532 2533 2535 2538 2541 2543 2544 2546 2548 Figure 21: EmergencyCallData.DeviceInfo XML Schema. 2550 7.4. EmergencyCallData.SubscriberInfo XML Schema 2552 2553 2564 2567 2570 2573 2574 2575 2576 2577 2580 2581 2582 2583 2585 2586 2587 2589 2591 2592 2594 2595 2596 2598 2600 Figure 22: EmergencyCallData.SubscriberInfo XML Schema. 2602 7.5. EmergencyCallData.Comment XML Schema 2603 2604 2613 2616 2619 2620 2621 2624 2628 2630 2631 2633 2634 2635 2636 2637 2638 2639 2641 2643 Figure 23: EmergencyCallData.Comment XML Schema. 2645 7.6. provided-by XML Schema 2647 This section defines the provided-by schema. 2649 2650 2665 2668 2671 2674 2677 2681 2684 2687 2689 2690 2691 2692 2693 2695 2696 2699 2701 2702 2703 2705 2707 2708 2709 2712 2715 2718 2721 2725 2728 2729 2731 2733 Figure 24: provided-by XML Schema 2735 8. Security Considerations 2737 The data structures described in this document contain information 2738 usually considered private. When information is provided by value, 2739 entities that are a party to the SIP signaling (such as proxy servers 2740 and back-to-back user agents) will have access to it and need to 2741 protect it against inappropriate disclosure. An entity that is able 2742 to eavesdrop on the SIP signaling will also have access. Some access 2743 types (such as in-the-clear Wi-Fi) are more vulnerable than others 2744 (such as 3G or 4G cellular data traffic) to eavesdropping. 2745 Mechanisms that protect against eavesdropping (such as Transport 2746 Layer Security (TLS)) SHOULD be preferentially used whenever 2747 feasible. (This requirement is not a "MUST" because there is an 2748 existing deployed base of clear-text SIP, and also because, as an 2749 emergency call, it is more important for the call to go through than 2750 for it to be protected; e.g., the call MUST proceed even if the TLS 2751 negotiation or certificate verification fails for whatever reason.) 2752 When information is provided by reference, HTTPS is REQUIRED for 2753 dereferencing, and the provider of the information is REQUIRED to 2754 validate the credentials of the requester. While the creation of a 2755 public key infrastructure (PKI) that has global scope may be 2756 difficult, the alternatives to creating devices and services that can 2757 provide critical information securely are more daunting. The 2758 provider of the information MAY enforce any policy it wishes to use, 2759 but PSAPs and responder agencies SHOULD deploy a PKI so that 2760 providers of additional data can check the certificate of the client 2761 (the requester) and decide the appropriate policy to enforce based on 2762 that certificate. 2764 Ideally, the PSAP and emergency responders will be given credentials 2765 signed by an authority trusted by the data provider. In most 2766 circumstances, nationally recognized credentials are sufficient; the 2767 emergency services community within a country can arrange a PKI, data 2768 providers can be provisioned with the root CA public key for the 2769 country. Some nations are developing a PKI for this, and related, 2770 purposes. Since calls could be made from devices where the device 2771 and/or the service provider(s) are not local to the emergency 2772 services authorities, globally recognized credentials are useful. 2773 This might be accomplished by extending the notion of the "forest 2774 guide" described in [RFC5582] to allow the forest guide to provide 2775 the credential of the PKI root for areas for which it has coverage 2776 information, but standards for such a mechanism are not yet 2777 available. In its absence, the data provider needs to obtain by out 2778 of band means the root CA credentials for any areas to which it is 2779 willing to provide additional data. With the credential of the root 2780 CA for a national emergency services PKI, the data provider server 2781 can validate the credentials of an entity requesting additional data 2782 by reference. 2784 The data provider also needs a credential that can be verified by the 2785 emergency services to know that it is receiving data from an 2786 authorized server. The emergency services authorities could provide 2787 credentials, distinguishable from credentials provided to emergency 2788 responders and PSAPs, which could be used to validate data providers. 2789 Such credentials would have to be acceptable to any PSAP or responder 2790 that could receive a call with additional data supplied by that 2791 provider. This would be extensible to global credential validation 2792 using the forest guide as mentioned above. In the absence of such 2793 credentials, the emergency services authorities could maintain a list 2794 of local data providers' credentials as provided to them out of band. 2796 At a minimum, the emergency services authorities could obtain a 2797 credential from the DNS entry of the domain in the Additional Data 2798 URI to at least validate that the server is known to the domain 2799 providing the URI. 2801 Data provided by devices by reference have similar credential 2802 validation issues as for service providers, and while the solutions 2803 are the same, the challenges of doing so for every device are 2804 obviously more difficult, especially when considering root 2805 certificate updates, revocation lists, etc. However, in general, 2806 devices are not expected to provide data directly by reference, but 2807 rather, to either provide data by value, or upload the data to a 2808 server which can more reliably make it available and more easily 2809 enforce security policy. Devices which do provide data directly by 2810 reference, which might include fixed-location sensors, will need to 2811 be capable of handling this. 2813 Much of the information supplied by service providers and devices is 2814 private and confidential; service providers and devices generally go 2815 to lengths to protect this information; disclosing it in the context 2816 of an emergency call is a trade-off to protect the greater interest 2817 of the customer in an emergency. 2819 Neither service providers nor devices will supply private information 2820 unless the call is recognized as an emergency call. In cellular 2821 telephony systems (such as those using 3GPP IMS), there are different 2822 procedures for an originating device to place an emergency versus a 2823 normal call. If a call that is really an emergency call is initiated 2824 as a normal call and the cellular service provider recognizes this, 2825 3GPP IMS permits the service provider to either accept the call 2826 anyway or reject it with a specific code that instructs the device to 2827 retry the call as an emergency call. Service providers ought to 2828 choose the latter, because otherwise the device will not have 2829 included the information specified in this document (since the device 2830 didn't recognize the call as being an emergency call). 2832 9. Privacy Considerations 2834 This document enables functionality for conveying additional 2835 information about the caller and the caller's device and service to 2836 the callee. Some of this information is personal data and therefore 2837 privacy concerns arise. An explicit privacy indicator for 2838 information directly relating to the caller's identity is defined and 2839 use is mandatory. However, observance of this request for privacy 2840 and which information it relates to is determined by the destination 2841 jurisdiction (which replicates functionality provided in some legacy 2842 emergency services systems). 2844 There are a number of privacy concerns with non-emergency real-time 2845 communication services that are also applicable to emergency calling. 2846 Data protection regulation world-wide has, however, decided to create 2847 exceptions for emergency services since the drawbacks of disclosing 2848 personal data are outweighed by the benefit for the emergency caller. 2849 Hence, the data protection rights of individuals are commonly waived 2850 for emergency situations. There are, however, still various 2851 countries that offer some degree of anonymity for the caller towards 2852 PSAP call takers. 2854 The functionality defined in this document far exceeds the amount of 2855 information sharing available in the legacy POTS system. For this 2856 reason there are additional privacy threats to consider, which are 2857 described in more detail in [RFC6973]. 2859 Stored Data Compromise: There is an increased risk of stored data 2860 compromise since additional data is collected and stored in 2861 databases. Without adequate measures to secure stored data from 2862 unauthorized or inappropriate access at access network providers, 2863 service providers, end devices, as well as PSAPs, individuals are 2864 exposed to potential financial, reputational, or physical harm. 2866 Misattribution: If the personal data collected and conveyed is 2867 incorrect or inaccurate then this may lead to misattribution. 2868 Misattribution occurs when data or communications related to one 2869 individual are attributed to another. 2871 Identification: By the nature of the additional data and its 2872 capability to provide much richer information about the caller, 2873 the call, and the location, the calling party is identified in a 2874 much better way. Some users may feel uncomfortable with this 2875 degree of information sharing even in emergency services 2876 situations. 2878 Secondary Use: There is a risk of secondary use, which is the use of 2879 collected information about an individual without the individual's 2880 consent for a purpose different from that for which the 2881 information was collected. The stated purpose of the additional 2882 data is for emergency services purposes but theoretically the same 2883 information could be used for any other call as well. 2884 Additionally, parties involved in the emergency call may retain 2885 the obtained information and may re-use it for other, non- 2886 emergency services purposes. 2888 Disclosure: When the data defined in this document is not properly 2889 protected (while in transit with traditional communication 2890 security techniques, and while stored using access control 2891 mechanisms) there is the risk of disclosure, which is the 2892 revelation of private information about an individual. 2894 To mitigate these privacy risks the following countermeasures can be 2895 taken: 2897 In regions where callers can elect to suppress certain personally 2898 identifying information, network or PSAP functionality can inspect 2899 privacy flags within the SIP headers to determine what information 2900 may be passed, stored, or displayed to comply with local policy or 2901 law. RFC 3325 [RFC3325] defines the "id" priv-value token. The 2902 presence of this privacy type in a Privacy header field indicates 2903 that the user would like the network asserted identity to be kept 2904 private with respect to SIP entities outside the trust domain with 2905 which the user authenticated, including the PSAP. 2907 This document defines various data structures that contain privacy- 2908 sensitive data. For example, identifiers for the device (e.g., 2909 serial number, MAC address) or account/SIM (e.g., IMSI), contact 2910 information for the user, location of the caller. Local regulations 2911 may govern which data is provided in emergency calls, but in general, 2912 the emergency call system is aided by the information described in 2913 this document. There is a tradeoff between the privacy 2914 considerations and the utility of the data. For protection, this 2915 specification requires all retrieval of data passed by reference to 2916 be protected against eavesdropping and alteration via communication 2917 security techniques (namely TLS). Furthermore, security safeguards 2918 are required to prevent unauthorized access to stored data. Various 2919 security incidents over at least the past few decades have shown that 2920 data breaches are not uncommon and are often caused by lack of proper 2921 access control frameworks, software bugs (such as buffer overflows), 2922 or missing input parsing (such as SQL injection attacks). The risks 2923 of data breaches is increased with the obligation for emergency 2924 services to retain emergency call related data for extended periods 2925 (e.g., several years are the norm). 2927 Finally, it is also worth highlighting the nature of the SIP 2928 communication architecture, which introduces additional complications 2929 for privacy. Some forms of data can be sent by value in the SIP 2930 signaling or by reference (a URL in the SIP signaling). When data is 2931 sent by value, all intermediaries have access to the data. As such, 2932 these intermediaries may also introduce additional privacy risk. 2933 Therefore, in situations where the conveyed information is privacy- 2934 sensitive and intermediaries are involved, transmitting by reference 2935 might be appropriate, assuming the source of the data can operate a 2936 sufficient dereferencing infrastructure and that proper access 2937 control policies are available for distinguishing the different 2938 entities dereferencing the reference. Without access control 2939 policies any party in possession of the reference is able to resolve 2940 the reference and to obtain the data, including intermediaries. 2942 10. IANA Considerations 2944 10.1. Registry creation 2946 This document creates a new registry called 'Emergency Call 2947 Additional Data'. The following sub-registries are created for this 2948 registry. 2950 10.1.1. Provider ID Series Registry 2952 This document creates a new sub-registry called "Additional Call Data 2953 Provider ID Series". As defined in [RFC5226], this registry operates 2954 under "Expert Review" rules. The expert should determine that the 2955 entity requesting a new value is a legitimate issuer of service 2956 provider IDs suitable for use in Additional Call Data. 2958 Private entities issuing or using internally-generated IDs are 2959 encouraged to register here and to ensure that all IDs they issue or 2960 use are unique. This guarantees that IDs issued or used by the 2961 entity are globally unique and distinguishable from other IDs issued 2962 or used by the same or a different entity. (Some organizations, such 2963 as NENA, issue IDs that are unique among all IDs they issue, so an 2964 entity using a combination of its NENA ID and the fact that it is 2965 from NENA is globally unique. Other entities might not have an ID 2966 issued by an organization such as NENA, so they are permitted to use 2967 their domain name, but if so, it needs to be unique.) 2969 The content of this registry includes: 2971 Name: An identifier to be used in the 'ProviderIDSeries' element. 2973 Source: The full name of the organization issuing the identifiers. 2975 URL: A URL to the organization for further information. 2977 The initial set of values is listed in Figure 1. 2979 10.1.2. Service Environment Registry 2981 This document creates a new sub-registry called 'Additional Call 2982 Service Environment'. As defined in [RFC5226], this registry 2983 operates under "Expert Review" rules. The expert should determine 2984 that the entity requesting a new value is relevant for this service 2985 element, and that the new value is distinct from existing values, and 2986 its use is unambiguous. 2988 The content of this registry includes: 2990 Token: The value to be used in the element. 2992 Description: A short description of the value. 2994 The initial set of values is listed in Figure 4. 2996 10.1.3. Service Type Registry 2998 This document creates a new sub-registry called 'Additional Call 2999 Service Type'. As defined in [RFC5226], this registry operates under 3000 "Expert Review" rules. The expert should determine that the entity 3001 requesting a new value is relevant for this service element and that 3002 the requested value is clearly distinct from other values so that 3003 there is no ambiguity as to when the value is to be used or which 3004 value is to be used. 3006 The content of this registry includes: 3008 Name: The value to be used in the element. 3010 Description: A short description of the value. 3012 The initial set of values is listed in Figure 5. 3014 10.1.4. Service Mobility Registry 3016 This document creates a new sub-registry called 'Additional Call 3017 Service Mobility'. As defined in [RFC5226], this registry operates 3018 under "Expert Review" rules. The expert should determine that the 3019 entity requesting a new value is relevant for this service element 3020 and that the requested value is clearly distinct from other values so 3021 that there is no ambiguity as to when the value is to be used or 3022 which value is to be used. 3024 The content of this registry includes: 3026 Token: The value used in the element. 3028 Description: A short description of the value. 3030 The initial set of values is listed in Figure 6. 3032 10.1.5. Service Provider Type Registry 3034 This document creates a new sub-registry called 'Service Provider 3035 Type'. As defined in [RFC5226], this registry operates under "Expert 3036 Review". The expert should determine that the proposed new value is 3037 distinct from existing values and appropriate for use in the 3038 element 3040 The content of this registry includes: 3042 Token: The value used in the element. 3044 Description: A short description of the type of service provider. 3046 The initial set of values is defined in Figure 2. 3048 10.1.6. Device Classification Registry 3050 This document creates a new sub-registry called 'Device 3051 Classification'. As defined in [RFC5226], this registry operates 3052 under "Expert Review" rules. The expert should consider whether the 3053 proposed class is unique from existing classes and the definition of 3054 the class will be clear to implementors and PSAPs/responders. 3056 The content of this registry includes: 3058 Token: Value used in the element. 3060 Description: Short description identifying the device type. 3062 The initial set of values are defined in Figure 8. 3064 10.1.7. Device ID Type Type Registry 3066 This document creates a new sub-registry called 'Additional Call Data 3067 Device ID Type'. As defined in [RFC5226], this registry operates 3068 under "Expert Review" rules. The expert should ascertain that the 3069 proposed type is well understood, and provides information which 3070 PSAPs and responders are able to use to uniquely identify a device. 3071 (For example, a biometric fingerprint used to authenticate a device 3072 would not normally be useful by a PSAP or responder to identify a 3073 device.) 3075 The content of this registry includes: 3077 Token: The value to be placed in the element. 3079 Description: Short description identifying the type of the device 3080 ID. 3082 The initial set of values are defined in Figure 9. 3084 10.1.8. Device/Service Data Type Registry 3086 This document creates a new sub-registry called 'Device/Service Data 3087 Type Registry'. As defined in [RFC5226], this registry operates 3088 under "Specification Required" rules, which include an explicit 3089 expert review. The designated expert should ascertain that the 3090 proposed type is well understood, and provides information useful to 3091 PSAPs and responders. The specification must contain a complete 3092 description of the data, and a precise format specification suitable 3093 to allow interoperable implementations. 3095 The content of this registry includes: 3097 Token: The value to be placed in the element. 3099 Description: Short description identifying the data. 3101 Specification: Citation for the specification of the data. 3103 The initial set of values are listed in Figure 10. 3105 10.1.9. Emergency Call Data Types Registry 3107 This document creates a new sub-registry called 'Emergency Call Data 3108 Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. 3109 As defined in [RFC5226], this registry operates under "Specification 3110 Required" rules, which include an explicit expert review. The expert 3111 is responsible for verifying that the document contains a complete 3112 and clear specification and the proposed functionality does not 3113 obviously duplicate existing functionality. The expert is also 3114 responsible for verifying that the block is correctly categorized per 3115 the description of the categories in Section 1. 3117 The registry contains an entry for every data block that can be sent 3118 with an emergency call using the mechanisms as specified in this 3119 document. Each data block is identified by the "root" of its MIME 3120 subtype (which is the part after 'EmergencyCallData.'). If the MIME 3121 subtype does not start with 'EmergencyCallData.', then it cannot be 3122 registered here nor used in a Call-Info header as specified in this 3123 document. The subtype MAY exist under any MIME media type (although 3124 most commonly these are under 'Application/' this is NOT REQUIRED), 3125 however, to be added to the registry the "root" needs to be unique 3126 regardless of the MIME media type. 3128 The content of this registry includes: 3130 Token: The root of the data's MIME subtype (not including the 3131 'EmergencyCallData' prefix and any suffix such as '+xml') 3133 Data About: A hint as to if the block is considered descriptive of 3134 the call, the caller, or the location (or is applicable to more 3135 than one), which may help PSAPs and other entities determine if 3136 they wish to process the block. Note that this is only a hint; 3137 entities need to consider the block's contents, not just this 3138 field, when determining if they wish to process the block (which 3139 is why the field only exists in the registry, and is not contained 3140 within the block). The value MUST be either "The Call", "The 3141 Caller", "The Location", or "Multiple". New values are created by 3142 extending this registry in a subsequent RFC. 3144 Reference: The document that describes the data object 3146 Note that the tokens in this registry are part of the 3147 'EmergencyCallData' compound value; when used as a value of the 3148 'purpose' parameter of the Call-Info header, the values listed in 3149 this registry are prefixed by 'EmergencyCallData.' per the 3150 'EmergencyCallData' registation Section 10.2. 3152 The initial set of values are listed in Figure 25. 3154 +----------------+--------------+------------+ 3155 | Token | Data About | Reference | 3156 +----------------+--------------+------------+ 3157 | ProviderInfo | The Call | [This RFC] | 3158 | ServiceInfo | The Call | [This RFC] | 3159 | DeviceInfo | The Call | [This RFC] | 3160 | SubscriberInfo | The Call | [This RFC] | 3161 | Comment | The Call | [This RFC] | 3162 +----------------+--------------+------------+ 3164 Figure 25: Additional Data Blocks Registry 3166 10.2. 'EmergencyCallData' Purpose Parameter Value 3168 This document defines the 'EmergencyCallData' value for the "purpose" 3169 parameter of the Call-Info header field. The Call-Info header and 3170 the corresponding registry for the 'purpose' parameter was 3171 established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData' 3172 is a compound value; when used as a value of the 'purpose' parameter 3173 of the Call-Info header, 'EmergencyCallData' is immediately followed 3174 by a dot ('.') and a value from the 'Emergency Call Data Types' 3175 registry Section 10.1.9. 3177 Header Parameter New 3178 Field Name Value Reference 3179 ---------- --------- ----------------- --------- 3180 Call-Info purpose EmergencyCallData [This RFC] 3182 10.3. URN Sub-Namespace Registration for Registry Entry 3184 This section registers the namespace specified in Section 10.5.1 in 3185 the provided-by registry established by RFC 4119, for usage within 3186 the element of a PIDF-LO. 3188 The schema for the element used by this document is 3189 specified in Section 7.6. 3191 10.4. MIME Registrations 3193 10.4.1. MIME Content-type Registration for 'application/ 3194 EmergencyCallData.ProviderInfo+xml' 3196 This specification requests the registration of a new MIME type 3197 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3198 RFC 7303 [RFC7303]. 3200 MIME media type name: application 3202 MIME subtype name: EmergencyCallData.ProviderInfo+xml 3204 Mandatory parameters: none 3206 Optional parameters: charset (indicates the character encoding of 3207 the contents) 3209 Encoding considerations: Uses XML, which can contain 8-bit 3210 characters, depending on the character encoding. See Section 3.2 3211 of RFC 7303 [RFC7303]. 3213 Security considerations: This content type is designed to carry 3214 the data provider information, which is a sub-category of 3215 additional data about an emergency call. Since this data may 3216 contain personal information, appropriate precautions might be 3217 needed to limit unauthorized access, inappropriate disclosure, and 3218 eavesdropping of personal information. Please refer to Section 8 3219 and Section 9 for more information. 3221 Interoperability considerations: None 3222 Published specification: [TBD: This specification] 3224 Applications which use this media type: Emergency Services 3226 Additional information: 3228 Magic Number: None 3230 File Extension: .xml 3232 Macintosh file type code: 'TEXT' 3234 Person and email address for further information: Hannes 3235 Tschofenig, Hannes.Tschofenig@gmx.net 3237 Intended usage: LIMITED USE 3239 Author: This specification is a work item of the IETF ECRIT 3240 working group, with mailing list address . 3242 Change controller: The IESG 3244 10.4.2. MIME Content-type Registration for 'application/ 3245 EmergencyCallData.ServiceInfo+xml' 3247 This specification requests the registration of a new MIME type 3248 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3249 RFC 7303 [RFC7303]. 3251 MIME media type name: application 3253 MIME subtype name: EmergencyCallData.ServiceInfo+xml 3255 Mandatory parameters: none 3257 Optional parameters: charset (indicates the character encoding of 3258 the contents) 3260 Encoding considerations: Uses XML, which can contain 8-bit 3261 characters, depending on the character encoding. See Section 3.2 3262 of RFC 7303 [RFC7303]. 3264 Security considerations: This content type is designed to carry 3265 the service information, which is a sub-category of additional 3266 data about an emergency call. Since this data may contain 3267 personal information, appropriate precautions may be needed to 3268 limit unauthorized access, inappropriate disclosure, and 3269 eavesdropping of personal information. Please refer to Section 8 3270 and Section 9 for more information. 3272 Interoperability considerations: None 3274 Published specification: [TBD: This specification] 3276 Applications which use this media type: Emergency Services 3278 Additional information: 3280 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 10.4.3. MIME Content-type Registration for 'application/ 3297 EmergencyCallData.DeviceInfo+xml' 3299 This specification requests the registration of a new MIME 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 subtype name: EmergencyCallData.DeviceInfo+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 device information, which is a sub-category of additional data 3318 about an emergency call. Since this data contains personal 3319 information, appropriate precautions need to be taken to limit 3320 unauthorized access, inappropriate disclosure to third parties, 3321 and eavesdropping of this information. Please refer to Section 8 3322 and Section 9 for more information. 3324 Interoperability considerations: None 3326 Published specification: [TBD: This specification] 3328 Applications which use this media type: Emergency Services 3330 Additional information: 3332 Magic Number: None 3334 File Extension: .xml 3336 Macintosh file type code: 'TEXT' 3338 Person and email address for further information: Hannes 3339 Tschofenig, Hannes.Tschofenig@gmx.net 3341 Intended usage: LIMITED USE 3343 Author: This specification is a work item of the IETF ECRIT 3344 working group, with mailing list address . 3346 Change controller: The IESG 3348 10.4.4. MIME Content-type Registration for 'application/ 3349 EmergencyCallData.SubscriberInfo+xml' 3351 This specification requests the registration of a new MIME type 3352 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3353 RFC 7303 [RFC7303]. 3355 MIME media type name: application 3357 MIME subtype name: EmergencyCallData.SubscriberInfo+xml 3359 Mandatory parameters: none 3361 Optional parameters: charset (indicates the character encoding of 3362 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 owner/subscriber information, which is a sub-category of 3369 additional data about an emergency call. Since this data contains 3370 personal information, appropriate precautions need to be taken to 3371 limit unauthorized access, inappropriate disclosure to third 3372 parties, and eavesdropping of this information. Please refer to 3373 Section 8 and Section 9 for more information. 3375 Interoperability considerations: None 3377 Published specification: [TBD: This specification] 3379 Applications which use this media type: Emergency Services 3381 Additional information: 3383 Magic Number: None 3385 File Extension: .xml 3387 Macintosh file type code: 'TEXT' 3389 Person and email address for further information: Hannes 3390 Tschofenig, Hannes.Tschofenig@gmx.net 3392 Intended usage: LIMITED USE 3394 Author: This specification is a work item of the IETF ECRIT 3395 working group, with mailing list address . 3397 Change controller: The IESG 3399 10.4.5. MIME Content-type Registration for 'application/ 3400 EmergencyCallData.Comment+xml' 3402 This specification requests the registration of a new MIME type 3403 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3404 RFC 7303 [RFC7303]. 3406 MIME media type name: application 3408 MIME subtype name: EmergencyCallData.Comment+xml 3410 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 a 3419 comment, which is a sub-category of additional data about an 3420 emergency call. This data may contain personal information. 3421 Appropriate precautions may be needed to limit unauthorized 3422 access, inappropriate disclosure to third parties, and 3423 eavesdropping of this information. Please refer to Section 8 and 3424 Section 9 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 10.5. URN Sub-Namespace Registration 3452 10.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 3454 This section registers a new XML namespace, as per the guidelines in 3455 RFC 3688 [RFC3688]. 3457 URI: urn:ietf:params:xml:ns:EmergencyCallData 3458 Registrant Contact: IETF, ECRIT working group, , as 3459 delegated by the IESG . 3461 XML: 3463 BEGIN 3464 3465 3467 3468 3469 3471 Namespace for Additional Emergency Call Data 3472 3473 3474

Namespace for Additional Data related to an Emergency Call 3475

3476

See [TBD: This document].

3477 3478 3479 END 3481 10.5.2. Registration for 3482 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3484 This section registers a new XML namespace, as per the guidelines in 3485 RFC 3688 [RFC3688]. 3487 URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3489 Registrant Contact: IETF, ECRIT working group, , as 3490 delegated by the IESG . 3492 XML: 3494 BEGIN 3495 3496 3498 3499 3500 3502 Namespace for Additional Emergency Call Data: 3503 Data Provider Information 3504 3505 3506

Namespace for Additional Data related to an Emergency Call 3507

3508

Data Provider Information

3509

See [TBD: This document].

3510 3511 3512 END 3514 10.5.3. Registration for 3515 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3517 This section registers a new XML namespace, as per the guidelines in 3518 RFC 3688 [RFC3688]. 3520 URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3522 Registrant Contact: IETF, ECRIT working group, , as 3523 delegated by the IESG . 3525 XML: 3527 BEGIN 3528 3529 3531 3532 3533 3535 Namespace for Additional Emergency Call Data: 3536 Service Information 3537 3538 3539

Namespace for Additional Data related to an Emergency Call 3540

3541

Service Information

3542

See [TBD: This document].

3543 3544 3545 END 3547 10.5.4. Registration for 3548 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3550 This section registers a new XML namespace, as per the guidelines in 3551 RFC 3688 [RFC3688]. 3553 URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3555 Registrant Contact: IETF, ECRIT working group, , as 3556 delegated by the IESG . 3558 XML: 3560 BEGIN 3561 3562 3564 3565 3566 3568 Namespace for Additional Emergency Call Data: 3569 Device Information 3570 3571 3572

Namespace for Additional Data related to an Emergency Call 3573

3574

Device Information

3575

See [TBD: This document].

3576 3577 3578 END 3580 10.5.5. Registration for 3581 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3583 This section registers a new XML namespace, as per the guidelines in 3584 RFC 3688 [RFC3688]. 3586 URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3588 Registrant Contact: IETF, ECRIT working group, , as 3589 delegated by the IESG . 3591 XML: 3593 BEGIN 3594 3595 3597 3598 3599 3601 Namespace for Additional Emergency Call Data: 3602 Owner/Subscriber Information 3603 3604 3605

Namespace for Additional Data related to an Emergency Call 3606

3607

Owner/Subscriber Information

3608

See [TBD: This document].

3609 3610 3611 END 3613 10.5.6. Registration for 3614 urn:ietf:params:xml:ns:EmergencyCallData:Comment 3616 This section registers a new XML namespace, as per the guidelines in 3617 RFC 3688 [RFC3688]. 3619 URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment 3621 Registrant Contact: IETF, ECRIT working group, , as 3622 delegated by the IESG . 3624 XML: 3626 BEGIN 3627 3628 3630 3631 3632 3634 Namespace for Additional Emergency Call Data:Comment 3635 3636 3637 3638

Namespace for Additional Data related to an Emergency Call 3639

3640

Comment

3641

See [TBD: This document].

3642 3643 3644 END 3646 10.6. Schema Registrations 3648 This specification registers five schemas, as per the guidelines in 3649 RFC 3688 [RFC3688]. 3651 URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo 3653 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3654 delegated by the IESG (iesg@ietf.org). 3656 XML: The XML schema can be found in Figure 19. 3658 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3660 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 3661 delegated by the IESG (iesg@ietf.org). 3663 XML: The XML schema can be found in Figure 20. 3665 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3667 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3668 delegated by the IESG (iesg@ietf.org). 3670 XML: The XML schema can be found in Figure 21. 3672 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3673 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3674 delegated by the IESG (iesg@ietf.org). 3676 XML: The XML schema can be found in Section 7.4. 3678 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3680 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3681 delegated by the IESG (iesg@ietf.org). 3683 XML: The XML schema can be found in Section 7.5. 3685 10.7. VCard Parameter Value Registration 3687 This document registers a new value in the vCARD Parameter Values 3688 registry as defined by [RFC6350] with the following template: 3690 Value: main 3692 Purpose: The main telephone number, typically of an enterprise, as 3693 opposed to a direct dial number of an individual employee 3695 Conformance: This value can be used with the "TYPE" parameter 3696 applied on the "TEL" property. 3698 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3699 00 3701 11. Acknowledgments 3703 This work was originally started in NENA and has benefitted from a 3704 large number of participants in NENA standardization efforts, 3705 originally in the Long Term Definition Working Group, the Data 3706 Technical Committee and most recently the Additional Data working 3707 group. The authors are grateful for the initial work and extended 3708 comments provided by many NENA participants, including Delaine 3709 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3710 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 3711 and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank 3712 Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback 3713 regarding the vCard/xCard use in this specification. 3715 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3716 Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris 3717 Santer, and Archie Cobbs for their review comments. Alissa Cooper 3718 and Guy Caron deserves special mention for their detailed and 3719 extensive review comments, which were very helpful and appreciated. 3721 12. References 3723 12.1. Normative References 3725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3726 Requirement Levels", BCP 14, RFC 2119, March 1997. 3728 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3729 Locators", RFC 2392, August 1998. 3731 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3732 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3733 and QSIG Objects", RFC 3204, December 2001. 3735 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3736 A., Peterson, J., Sparks, R., Handley, M., and E. 3737 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3738 June 2002. 3740 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3741 Extensions (MIME) Parameter", RFC 3459, January 2003. 3743 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3744 January 2004. 3746 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3747 3966, December 2004. 3749 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3750 Format", RFC 4119, December 2005. 3752 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3753 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3754 May 2008. 3756 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3757 October 2008. 3759 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3760 Initiation Protocol (SIP)", RFC 5621, September 2009. 3762 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3763 Languages", BCP 47, RFC 5646, September 2009. 3765 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3766 August 2011. 3768 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3769 6351, August 2011. 3771 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3772 Specifications and Registration Procedures", BCP 13, RFC 3773 6838, January 2013. 3775 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 3776 July 2014. 3778 12.2. Informational References 3780 [ECRIT-WG-wiki] 3781 IETF, "ECRIT WG Wiki"", July 2015, 3782 . 3785 [I-D.gellens-slim-negotiating-human-language] 3786 Gellens, R., "Negotiating Human Language in Real-Time 3787 Communications", draft-gellens-slim-negotiating-human- 3788 language-01 (work in progress), April 2015. 3790 [IANA-XML-Schemas] 3791 IANA, "IANA XML Schemas"", July 2015, 3792 . 3795 [LanguageTagRegistry] 3796 IANA, "Language Subtag Registry", Feb 2015, 3797 . 3800 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3801 Extensions to the Session Initiation Protocol (SIP) for 3802 Asserted Identity within Trusted Networks", RFC 3325, 3803 November 2002. 3805 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3806 "Indicating User Agent Capabilities in the Session 3807 Initiation Protocol (SIP)", RFC 3840, August 2004. 3809 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 3810 Emergency Context Resolution with Internet Technologies", 3811 RFC 5012, January 2008. 3813 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3814 Format for Presence Information Data Format Location 3815 Object (PIDF-LO)", RFC 5139, February 2008. 3817 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3818 Presence Information Data Format Location Object (PIDF-LO) 3819 Usage Clarification, Considerations, and Recommendations", 3820 RFC 5491, March 2009. 3822 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 3823 Framework", RFC 5582, September 2009. 3825 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3826 Thomson, "Dynamic Extensions to the Presence Information 3827 Data Format Location Object (PIDF-LO)", RFC 5962, 3828 September 2010. 3830 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3831 5985, September 2010. 3833 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3834 "Framework for Emergency Calling Using Internet 3835 Multimedia", RFC 6443, December 2011. 3837 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3838 R. George, "Specifying Civic Address Extensions in the 3839 Presence Information Data Format Location Object (PIDF- 3840 LO)", RFC 6848, January 2013. 3842 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3843 Communications Services in Support of Emergency Calling", 3844 BCP 181, RFC 6881, March 2013. 3846 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3847 Morris, J., Hansen, M., and R. Smith, "Privacy 3848 Considerations for Internet Protocols", RFC 6973, July 3849 2013. 3851 [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3852 Thomson, "Relative Location Representation", RFC 7035, 3853 October 2013. 3855 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3856 Patel, "Public Safety Answering Point (PSAP) Callback", 3857 RFC 7090, April 2014. 3859 12.3. URIs 3861 [1] http://www.nena.org/?page=cid2014 3863 [2] http://www.nena.org/?page=CompanyID 3865 Appendix A. XML Schema for vCard/xCard 3867 This section contains the vCard/xCard XML schema version of the Relax 3868 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3869 XML schemas defined in this document. The schema in RFC 6351 3870 [RFC6351] is the normative source and this section is informative 3871 only. 3873 3874 3878 3884 3885 3886 vCard Format Specification 3887 3888 3889 3890 3891 3892 3893 3894 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3909 3910 3911 3914 3915 3916 3917 3918 3920 3921 3922 3924 3925 3926 3927 3928 3930 3931 3932 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3976 3977 3978 3979 3983 3984 3985 Section 5: Parameters 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 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 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 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 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 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 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 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 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 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 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 4908 4909 4910 4911 4912 4913 4914 4916 4917 4918 4919 4920 4921 4922 4924 4925 4926 4928 4930 4931 4932 4934 4935 4936 4937 4939 Appendix B. XML Validation 4941 This document defines a number of XML schemas and contains various 4942 examples. Extracting the XML and validating the examples against the 4943 schemas can be challenging, especially due to the formatting 4944 limitations introduced by IETF RFCs. For those readers who copy the 4945 XML schemas and examples directly from this document, please consider 4946 that errors might be introduced due to line breaks and extra 4947 whitespaces in the regular expressions contained in the vcard schema 4948 in Appendix A. To validate the PIDF-LO from Figure 18 it is also 4949 necessary to consult the referenced RFCs and copy the schemas 4950 necessary for successful validation. 4952 The XML schemas found in this document include a 'SchemaLocation' 4953 attribute. Depending on the location of the downloaded schema files 4954 you may need to adjust this schema location or configure your XML 4955 editor to point to the location. 4957 For convenience of readers, the schemas are available at http://ip- 4958 emergency.net/additional-data.zip and the XML examples are available 4959 at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki]. 4961 Note to RFC Editor: After IANA has published the schemas, the above 4962 link to the schemas should be replaced with [IANA-XML-Schemas]. 4964 Authors' Addresses 4965 Randall Gellens 4966 Qualcomm Technologies, Inc. 4967 5775 Morehouse Drive 4968 San Diego, CA 92121 4969 US 4971 Email: rg+ietf@qti.qualcomm.com 4973 Brian Rosen 4974 NeuStar 4975 470 Conrad Dr. 4976 Mars, PA 16046 4977 US 4979 Phone: +1 724 382 1051 4980 Email: br@brianrosen.net 4982 Hannes Tschofenig 4983 Hall in Tirol 6060 4984 Austria 4986 Email: Hannes.tschofenig@gmx.net 4987 URI: http://www.tschofenig.priv.at 4989 Roger Marshall 4990 TeleCommunication Systems, Inc. 4991 2401 Elliott Avenue 4992 Seattle, WA 98121 4993 US 4995 Phone: +1 206 792 2424 4996 Email: rmarshall@telecomsys.com 4997 URI: http://www.telecomsys.com 4999 James Winterbottom 5000 AU 5002 Email: a.james.winterbottom@gmail.com