idnits 2.17.00 (12 Aug 2021) /tmp/idnits19702/draft-ietf-ecrit-additional-data-31.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 3159 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 3, 2015) is 2513 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 3840 -- Looks like a reference, but probably isn't: '2' on line 3842 == Missing Reference: 'This RFC' is mentioned on line 3159, 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 4, 2016 NeuStar 6 H. Tschofenig 8 R. Marshall 9 TeleCommunication Systems, Inc. 10 J. Winterbottom 12 July 3, 2015 14 Additional Data Related to an Emergency Call 15 draft-ietf-ecrit-additional-data-31.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 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . 29 104 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32 106 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32 107 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 32 108 5.1. Transmitting Blocks using the Call-Info Header . . . . . 34 109 5.2. Transmitting Blocks by Reference using the 110 Element . . . . . . . . . . . . . . . . . . . . . . . . . 35 111 5.3. Transmitting Blocks by Value using the 112 Element . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38 114 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 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 402 XML Element: 404 Description: This is a plain text string suitable for displaying the 405 name of the service provider that supplied the data structure. If 406 the device creates the structure, it SHOULD use the value of the 407 contact header in the SIP INVITE. 409 Reason for Need: Inform the call taker of the identity of the entity 410 providing the data. 412 How Used by Call Taker: Allows the call taker to interpret the data 413 in this structure. The source of the information often influences 414 how the information is used, believed or verified. 416 4.1.2. Data Provider ID 418 Data Element: Data Provider ID 420 Use: Conditional. Optional for blocks supplied by the originating 421 device, mandatory otherwise. This data MUST be provided by all 422 entities other than the originating device in order to uniquely 423 identify the service provider or access provider. 425 XML Element: 427 Description: A jurisdiction-specific code for, or the fully- 428 qualified domain name of, the access network provider or service 429 provider shown in the element that created the 430 structure. NOTE: The value SHOULD be assigned by an organization 431 appropriate for the jurisdiction. In the U.S., if the provider is 432 registered with NENA, the provider's NENA Company ID MUST appear 433 here. Additional information can be found at NENA Company 434 Identifier Program [1] or NENA Company ID [2]. The NENA Company 435 ID MUST be in the form of a URI in the following format: 436 urn:nena:companyid:. If the organization does 437 not have an identifier registered with a jurisdiction-specific 438 emergency services registrar (such as NENA), then the value MAY be 439 the fully-qualified domain name of the service provider or access 440 provider. The device MAY use its IP address or fully-qualified 441 domain name (and set the "Data Provider ID Series" element to 442 "domain"). 444 Reason for Need: Inform the call taker of the identity of the entity 445 providing the data. 447 How Used by Call Taker: Where jurisdictions have lists of providers 448 the Data Provider ID provides useful information about the data 449 source. The Data Provider ID uniquely identifies the source of 450 the data, which might be needed especially during unusual 451 circumstances and for routine logging. 453 4.1.3. Data Provider ID Series 455 Data Element: Data Provider ID Series 457 Use: Conditional. Optional for blocks supplied by the originating 458 device, mandatory otherwise. 460 XML Element: 462 Description: Identifies the issuer of the . The 463 Provider ID Series Registry created in Section 10.1.1 initially 464 contains the entries shown in Figure 1. 466 Reason for Need: Identifies how to interpret the Data Provider ID. 467 The combination of ProviderIDSeries and ProviderID MUST be 468 globally unique. 470 How Used by Call Taker: Determines which provider ID registry to 471 consult for more information 472 +-----------+--------------------------+----------------------+ 473 | Name | Source | URL | 474 +-----------+--------------------------+----------------------+ 475 | NENA | National Emergency | http://www.nena.org | 476 | | Number Association | | 477 | EENA | European Emergency | http://www.eena.org | 478 | | Number Association | | 479 | domain | (The ID is a fully- | (not applicable) | 480 | | qualified domain name) | | 481 +-----------+--------------------------+----------------------+ 483 Figure 1: Provider ID Series Registry 485 4.1.4. Type of Data Provider 487 Data Element: Type of Data Provider 489 Use: Required. 491 XML Element: 493 Description: Identifies the type of data provider supplying the 494 data. The registry containing all valid values is created in 495 Section 10.1.5 and the initial set of values is shown in Figure 2. 497 Reason for Need: Identifies the category of data provider. 499 How Used by Call Taker: This information may be helpful when 500 deciding whom to contact when further information is needed. 502 +------------------------------+------------------------------------+ 503 | Token | Description | 504 +------------------------------+------------------------------------+ 505 |Client | Originating client/device | 506 |Access Network Provider | Access network service provider | 507 |Telecom Provider | Telecom service provider (including| 508 | | over-the-top VoIP services) | 509 |Telematics Provider | A sensor-based service provider, | 510 | | especially vehicle-based | 511 |Language Translation Provider | A spoken language translation | 512 | | service | 513 |Emergency Service Provider | An emergency service provider | 514 | | conveying information to another| 515 | | emergency service provider. | 516 |Emergency Modality Translation| An emergency-call-specific | 517 | | modality translation service | 518 | | e.g., for sign language | 519 |Relay Provider | A interpretation service, e.g., | 520 | | video relay for sign language | 521 | | interpreting | 522 |Other | Any other type of service provider | 523 +------------------------------+------------------------------------+ 525 Figure 2: Type of Data Provider Registry 527 4.1.5. Data Provider Contact URI 529 Data Element: Data Provider Contact URI 531 Use: Required 533 XML Element: 535 Description: When provided by a service provider or an access 536 network provider, this information MUST be a URI to a 24/7 support 537 organization tasked to provide PSAP support for this emergency 538 call. When provided by a device, this MUST be the contact 539 information of the user or owner of the device. (Ideally, this is 540 the contact information of the device user, but when the owner and 541 user are separate (e.g., the device owner is an organization), 542 this MAY be the contact information of the owner.) The Data 543 Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format 544 fully specified with country code. If a TEL URI is not available, 545 it MAY be a generic SIP URI. Note that this contact information 546 is not used by PSAPs for callbacks (a call from a PSAP directly 547 related to a recently terminated emergency call, placed by the 548 PSAP using a SIP Priority header field set to "psap-callback", as 549 described in [RFC7090]). 551 Reason for Need: Additional data providers may need to be contacted 552 in error cases or other unusual circumstances. 554 How Used by Call Taker: To contact the supplier of the additional 555 data for assistance in handling the call. 557 4.1.6. Data Provider Languages(s) Supported 559 Data Element: Data Provider Language(s) supported 561 Use: Required. 563 XML Element: 565 Description: This field encodes the language used by the entity at 566 the Data Provider Contact URI. The content of this field consists 567 of a single token from the language tags registry, which can be 568 found at [LanguageTagRegistry], and is defined in [RFC5646]. 569 Multiple instances of this element may occur but the order is 570 significant and the preferred language should appear first. The 571 content MUST reflect the languages supported at the contact URI. 573 (Note that this field informs the PSAP of the language(s) used by 574 the data provider. If the PSAP needs to contact the data 575 provider, it can be helpful to know in advance the language(s) 576 used by the data provider. If the PSAP uses a communication 577 protocol to reach the data provider, that protocol may have 578 language facilities of its own (such as the 'language' media 579 feature tag, defined in RFC 3840 [RFC3840] and the more extensive 580 language negotiation mechanism proposed with 581 [I-D.gellens-slim-negotiating-human-language]), and if so, those 582 are independent of this field.) 584 Reason for Need: This information indicates if the emergency service 585 authority can directly communicate with the service provider or if 586 an interpreter will be needed. 588 How Used by Call Taker: If the call taker cannot speak any language 589 supported by the service provider, a translation service will need 590 to be added to the conversation. Alternatively, other persons at 591 the PSAP, besides the call taker, might be consulted for help 592 (depending on the urgency and the type of interaction). 594 4.1.7. xCard of Data Provider 596 Data Element: xCard of Data Provider 598 Use: Optional 599 XML Element: 601 Description: Per [RFC6351] the xCard structure is represented within 602 a element. Although multiple elements may be 603 contained in a structure only one element SHOULD be 604 provided. If more than one appears, the first SHOULD be used. 605 There are many fields in the xCard and the creator of the data 606 structure is encouraged to provide all available information. N, 607 ORG, ADR, TEL, EMAIL are suggested at a minimum. N SHOULD contain 608 the name of the support group or device owner as appropriate. If 609 more than one TEL property is provided, a parameter from the vCard 610 Property Value registry MUST be specified for each TEL. For 611 encoding of the vCard this specification uses the XML-based 612 encoding specified in [RFC6351], referred to in this document as 613 "xCard". 615 Reason for Need: Information needed to determine additional contact 616 information. 618 How Used by Call Taker: Assists the call taker by providing 619 additional contact information aside from what may be included in 620 the SIP INVITE or the PIDF-LO. 622 4.1.8. Subcontractor Principal 624 When the entity providing the data is a subcontractor, the Data 625 Provider Type is set to that of the primary service provider and this 626 entry is supplied to provide information regarding the subcontracting 627 entity. 629 Data Element: Subcontractor Principal 631 Use: Conditional. This data is required if the entity providing the 632 data is a subcontractor. 634 XML Element: 636 Description: Some providers outsource their obligations to handle 637 aspects of emergency services to specialized providers. If the 638 data provider is a subcontractor to another provider this element 639 contains the DataProviderString of the service provider to 640 indicate which provider the subcontractor is working for. 642 Reason for Need: Identify the entity the subcontractor works for. 644 How Used by Call Taker: Allows the call taker to understand what the 645 relationship between data providers and the service providers in 646 the path of the call are. 648 4.1.9. Subcontractor Priority 650 Data Element: Subcontractor Priority 652 Use: Conditional. This data is required if the entity providing the 653 data is a subcontractor. 655 XML Element: 657 Description: If the subcontractor is supposed to be contacted first 658 then this element MUST have the value "sub". If the provider the 659 subcontractor is working for is supposed to be contacted first 660 then this element MUST have the value "main". 662 Reason for Need: Inform the call taker whom to contact first, if 663 support is needed. 665 How Used by Call Taker: To decide which entity to contact first if 666 assistance is needed. 668 4.1.10. ProviderInfo Example 670 671 673 string0987654321@example.org 674 675 Example VoIP Provider 676 677 urn:nena:companyid:ID123 678 NENA 679 Telecom Provider 680 tel:+1-201-555-0123 681 en 682 684 685 Hannes Tschofenig 686 687 Hannes 688 Tschofenig 689 690 691 Dipl. Ing. 692 693 --0203 694 695 20090808T1430-0500 696 697 M 698 699 1 700 701 de 702 703 704 2 705 706 en 707 708 709 work 710 711 Example VoIP Provider 712 713 714 715 work 716 720 721 722 723 Linnoitustie 6 724 Espoo 725 Uusimaa 726 02600 727 Finland 728 729 730 731 732 work 733 voice 734 735 736 tel:+358 50 4871445 737 738 739 work 740 741 hannes.tschofenig@nsn.com 742 743 744 work 745 746 geo:60.210796,24.812924 747 748 749 home 750 751 752 http://www.tschofenig.priv.at/key.asc 753 754 755 Finland/Helsinki 756 757 home 758 759 http://www.tschofenig.priv.at 760 761 762 763 765 Figure 3: EmergencyCallData.ProviderInfo Example. 767 4.2. Service Information 769 This block describes the service that the service provider provides 770 to the caller. It SHOULD be included by all service providers in the 771 path of the call. The mime subtype is "application/ 772 EmergencyCallData.ServiceInfo+xml". 774 4.2.1. Service Environment 776 Data Element: Service Environment 778 Use: Conditional: Required unless the 'ServiceType' value is 779 'wireless'. 781 XML Element: 783 Description: This element indicates whether a call is from a 784 business or residence. Currently, the only valid entries are 785 'Business', 'Residence', and 'unknown', as shown in Figure 4. New 786 values can be defined via the registry created in Section 10.1.2. 788 Reason for Need: To provide context and a hint when determining 789 equipment and manpower requirements. 791 How Used by Call Taker: Information may be used to provide context 792 and a hint to assist in determining equipment and manpower 793 requirements for emergency responders. Because there are 794 situations where the service provider does not know (such as 795 anonymous pre-paid service), and because the type of service does 796 not neccessarily reflect the nature of the premises (for example, 797 a business line installed in a residence, or wireless service), 798 and the registry is not all-encompassing, this is at best advisory 799 information, but since it mimics a similar capability in some 800 current emergency calling systems (e.g., a field in the Automatic 801 Location Information (ALI) information used with legacy North 802 American wireline systems), it is known to be valuable. The 803 service provider uses its best information (such as a rate plan, 804 facilities used to deliver service or service description) to 805 determine the information and is not responsible for determining 806 the actual characteristics of the location from which the call 807 originated. Because the usefulness is unknown (and less clear) 808 for wireless, this element is OPTIONAL for wireless and REQUIRED 809 otherwise. 811 +-----------+--------------------------+ 812 | Token | Description | 813 +-----------+--------------------------+ 814 | Business | Business service | 815 | Residence | Residential service | 816 | unknown | Type of service unknown | 817 | | (e.g., anonymous pre- | 818 | | paid service) | 819 +-----------+--------------------------+ 821 Figure 4: Service Environment Registry 823 4.2.2. Service Type 825 Data Element: Service Delivered by Provider to End User 827 Use: Required 829 XML Element: 831 Description: This defines the type of service over which the call is 832 placed (similar to the Class of Service delivered with legacy 833 emergency calls in some some regions). The implied mobility of 834 this service cannot be relied upon. A registry is created in 835 Section 10.1.3. The initial set of values is shown in Figure 5. 836 More than one value MAY be returned. For example, a VoIP inmate 837 telephone service is a reasonable combination. 839 Reason for Need: Knowing the type of service may assist the PSAP in 840 handling of the call. 842 How Used by Call Taker: Call takers often use this information to 843 determine what kinds of questions to ask callers, and how much to 844 rely on supportive information. An emergency call from a prison 845 is treated differently than a call from a sensor device. As the 846 information is not always available, and the registry is not all- 847 encompassing, this is at best advisory information, but since it 848 mimics a similar capability in some legacy emergency calling 849 systems, it is known to be valuable. 851 +--------------+----------------------------------------+ 852 | Name | Description | 853 +--------------+----------------------------------------+ 854 | wireless | Wireless Telephone Service: Includes | 855 | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but | 856 | | not satellite) | 857 | coin | Fixed public pay/coin telephones: Any | 858 | | coin or credit card operated device | 859 | one-way | One way outbound service | 860 | prison | Inmate call/service | 861 | temp | Soft dial tone/quick service/warm | 862 | | disconnect/suspended | 863 | MLTS-hosted | Hosted multi-line telephone system | 864 | | such as Centrex | 865 | MLTS-local | Local multi-line telephone system, | 866 | | includes all PBX, key systems, | 867 | | Shared Tenant Service | 868 | sensor- | These are devices that generate DATA | 869 | unattended | ONLY. This is a one-way information | 870 | | transmit without interactive media | 871 | sensor- | Devices that are supported by a | 872 | attended | monitoring service provider or that | 873 | | are capable of supporting interactive| 874 | | media | 875 | POTS | Wireline: Plain Old Telephone Service | 876 | VOIP | An over-the-top service that provides | 877 | | communication over arbitrary Internet| 878 | | access (fixed, nomadic, mobile) | 879 | remote | Off-premise extension | 880 | relay | A service where a human third-party | 881 | | agent provides additional assistance | 882 | | This includes sign language relay/ | 883 | | interpretation, telematics services | 884 | | that provide a human on the call, | 885 | | and similar services. | 886 +--------------+----------------------------------------+ 888 Figure 5: Service Delivered by Provider to End User Registry 890 4.2.3. Service Mobility Environment 892 Data Element: Service Mobility Environment 894 Use: Required 896 XML Element: 897 Description: This provides the service provider's view of the 898 mobility of the caller's device. As the service provider might 899 not know the characteristics of the actual device or access 900 network used, the value should be treated as advisory and not be 901 relied upon. A registry is created in Section 10.1.4 with the 902 initial valid entries shown in Figure 6. 904 Reason for Need: Knowing the service provider's belief of mobility 905 may assist the PSAP with the handling of the call. 907 How Used by Call Taker: To determine whether to assume the location 908 of the caller might change. 910 +-----------+----------------------------+ 911 | Token | Description | 912 +-----------+----------------------------+ 913 | Mobile | The device is able to move | 914 | | at any time | 915 | Fixed | The device is not expected | 916 | | to move unless the | 917 | | service is relocated | 918 | Nomadic | The device is not expected | 919 | | to change its point of | 920 | | attachment while on a | 921 | | call | 922 | Unknown | No information is known | 923 | | about the service | 924 | | mobility environment for | 925 | | the device | 926 +-----------+----------------------------+ 928 Figure 6: Service Environment Registry 930 4.2.4. EmergencyCallData.ServiceInfo Example 932 933 935 2468.IBOC.MLTS.1359@example.org 936 937 Business 938 MLTS-hosted 939 Fixed 940 942 Figure 7: EmergencyCallData.ServiceInfo Example. 944 4.3. Device Information 946 This block provides information about the device used to place the 947 call. It should be provided by any service provider that knows what 948 device is being used, and by the device itself. The mime subtype is 949 "application/EmergencyCallData.DeviceInfo+xml". 951 4.3.1. Device Classification 953 Data Element: Device Classification 955 Use: Optional 957 XML Element: 959 Description: This data element defines the kind of device making the 960 emergency call. If the device provides the data structure, the 961 device information SHOULD be provided. If the service provider 962 provides the structure and it knows what the device is, the 963 service provider SHOULD provide the device information. Often the 964 carrier does not know what the device is. It is possible to 965 receive two Additional Data Associated with a Call data 966 structures, one created by the device and one created by the 967 service provider. This information describes the device, not how 968 it is being used. This data element defines the kind of device 969 making the emergency call. A registry is created in 970 Section 10.1.6 with the initial set of values as shown in 971 Figure 8. 973 Reason for Need: The device classification implies the capability of 974 the calling device and assists in identifying the meaning of the 975 emergency call location information that is being presented. For 976 example, does the device require human intervention to initiate a 977 call or is this call the result of programmed instructions? Does 978 the calling device have the ability to update location or 979 condition changes? Is this device interactive or a one-way 980 reporting device? 982 How Used by Call Taker: May provide the call taker context regarding 983 the caller, the capabilities of the calling device or the 984 environment in which the device is being used, and may assist in 985 understanding the location information and capabilities of the 986 calling device. For example, a cordless handset may be outside or 987 next door. 989 +---------------+----------------------------------------+ 990 | Token | Description | 991 +---------------+----------------------------------------+ 992 |cordless | Cordless handset | 993 |fixed | Fixed phone | 994 |satellite | Satellite phone | 995 |sensor-fixed | Fixed (non mobile) sensor/alarm device | 996 |desktop | Soft client on desktop PC | 997 |laptop | Soft client on laptop type device | 998 |tablet | Soft client on tablet type device | 999 |alarm-monitored| Alarm system | 1000 |sensor-mobile | Mobile sensor device | 1001 |aircraft | Aircraft telematics device | 1002 |automobile | Automobile/cycle/off-road telematics | 1003 |truck | Truck/construction telematics | 1004 |farm | Farm equipment telematics | 1005 |marine | Marine telematics | 1006 |personal | Personal telematics device | 1007 |feature-phone | Feature- (not smart-) cellular phone | 1008 |smart-phone | Smart-phone cellular phone (native) | 1009 |smart-phone-app| Soft client app on smart-phone | 1010 |unknown-device | Soft client on unknown device type | 1011 |game | Gaming console | 1012 |text-only | Other text device | 1013 |NA | Not Available | 1014 +---------------+----------------------------------------+ 1016 Figure 8: Device Classification Registry Initial Values 1018 4.3.2. Device Manufacturer 1020 Data Element: Device Manufacturer 1022 Use: Optional 1024 XML Element: 1026 Description: The plain language name of the manufacturer of the 1027 device. 1029 Reason for Need: Used by PSAP management for post-mortem 1030 investigation/resolution. 1032 How Used by Call Taker: Probably not used by the calltaker, but by 1033 PSAP management. 1035 4.3.3. Device Model Number 1037 Data Element: Device Model Number 1039 Use: Optional 1041 XML Element: 1043 Description: Model number of the device. 1045 Reason for Need: Used by PSAP management for after-action 1046 investigation/resolution. 1048 How Used by Call Taker: Probably not used by the calltaker, but by 1049 PSAP management. 1051 4.3.4. Unique Device Identifier 1053 Data Element: Unique Device Identifier 1055 Use: Optional 1057 XML Element: 1059 XML Attribute: 1061 Description: A string that identifies the specific device (or the 1062 device's current SIM) making the call or creating an event. Note 1063 that more than one may be present, to supply more 1064 than one of the identifying values. 1066 The attribute identifies the type of device 1067 identifier. A registry is created in Section 10.1.7 with an 1068 initial set of values shown in Figure 9. 1070 Reason for Need: Uniquely identifies the device (or, in the case of 1071 IMSI, a SIM), independent of any signaling identifiers present in 1072 the call signaling stream. 1074 How Used by Call Taker: Probably not used by the call taker; may be 1075 used by PSAP management during an investigation. 1077 Example: 12345 1078 +--------+------------------------------------------+ 1079 | Token | Description | 1080 +--------+------------------------------------------+ 1081 | MEID | Mobile Equipment Identifier (CDMA) | 1082 | ESN | Electronic Serial Number (GSM) | 1083 | MAC | Media Access Control Address (IEEE) | 1084 | WiMAX | Device Certificate Unique ID | 1085 | IMEI | International Mobile Equipment ID (GSM) | 1086 | IMSI | International Mobile Subscriber ID (GSM) | 1087 | UDI | Unique Device Identifier | 1088 | RFID | Radio Frequency Identification | 1089 | SN | Manufacturer Serial Number | 1090 +--------+------------------------------------------+ 1092 Figure 9: Registry of Device Identifier Types 1094 4.3.5. Device/Service-Specific Additional Data Structure 1096 Data Element: Device/service-specific additional data structure 1098 Use: Optional 1100 XML Element: 1102 Description: A URI representing additional data whose schema is 1103 specific to the device or service which created it. (For example, 1104 a medical device or medical device monitoring service may have a 1105 defined set of medical data). The URI, when dereferenced, MUST 1106 yield a data structure defined by the Device/service specific 1107 additional data type value. Different data may be created by each 1108 classification; e.g., a medical device created data set. 1110 Reason for Need: Provides device/service specific data that may be 1111 used by the call taker and/or responders. 1113 How Used by Call Taker: Provide information to guide call takers to 1114 select appropriate responders, give appropriate pre-arrival 1115 instructions to callers, and advise responders of what to be 1116 prepared for. May be used by responders to guide assistance 1117 provided. 1119 4.3.6. Device/Service Specific Additional Data Structure Type 1121 Data Element: Type of device/service-specific additional data 1122 structure 1124 Use: Conditional. MUST be provided when device/service specific- 1125 additional URI is provided 1127 XML Element: 1129 Description: A value from the registry defined in Section 10.1.8 to 1130 describe the type of data located at the device/service-specific 1131 additional data structure. The initial values shown in Figure 10 1132 currently only include IEEE 1512, which is the USDoT model for 1133 traffic incidents. 1135 Reason for Need: This data element allows identification of 1136 externally defined schemas, which may have additional data that 1137 may assist in emergency response. 1139 How Used by Call Taker: This data element allows the end user (call 1140 taker or first responder) to know what type of additional data may 1141 be available to aid in providing the needed emergency services. 1143 Note: Information which is specific to a location or a caller 1144 (person) should not be placed in this section. 1146 +----------+----------------------------+--------------------------------+ 1147 | Token | Description | Specification | 1148 +----------+----------------------------+--------------------------------+ 1149 | IEEE1512 | Common Incident Management |IEEE 1512-2006 | 1150 | | Message Set (USDoT model |https://standards.ieee.org/ | 1151 | | for traffic incidents) |findstds/standard/1512-2006.html| 1152 +----------+----------------------------+--------------------------------+ 1154 Figure 10: Device/Service Data Type Registry 1156 4.3.7. Issues with getting new types of data into use 1158 This document describes two mechanisms that allow extension of the 1159 kind of data provided with an emergency call: define a new block or 1160 define a new service specific additional data URL for the DeviceInfo 1161 block. While defining new data types and getting a new device or 1162 application to send the new data may be easy, getting PSAPs and 1163 responders to actually retrieve the data and use it will be 1164 difficult. New mechanism providers should understand that acquiring 1165 and using new forms of data usually require software upgrades at the 1166 PSAP and/or responders, as well as training of call takers and 1167 responders in how to interpret and use the information. Legal and 1168 operational review may also be needed. Overwhelming a call taker or 1169 responder with too much information is highly discouraged. Thus, the 1170 barrier to supporting new data is quite high. 1172 The mechanisms this document describes are meant to encourage 1173 development of widely supported, common data formats for classes of 1174 devices. If all manufacturers of a class of device use the same 1175 format, and the data can be shown to improve outcomes, then PSAPs and 1176 responders may be encouraged to upgrade their systems and train their 1177 staff to use the data. Variations, however well intentioned, are 1178 unlikely to be supported. 1180 Implementers should consider that data from sensor-based devices in 1181 some cases may not be useful to call takers or PSAPs (and privacy or 1182 other considerations may preclude the PSAP from touching the data), 1183 but may be of use to responders. Each data item provided with the 1184 call in conformance with this document can be accessed by responders 1185 or other entities in the emergency services, whether or not the data 1186 is accessed by the PSAP. 1188 4.3.8. Choosing between defining a new type of block or new type of 1189 device/service specific additional data 1191 For devices that have device or service specific data, there are two 1192 choices to carry it. A new block can be defined, or the device/ 1193 service specific additional data URL the DeviceInfo block can be used 1194 and a new type for it defined . The data passed would likely be the 1195 same in both cases. Considerations for choosing which mechanism to 1196 register under include: 1198 Applicability: Information which will be carried by many kinds of 1199 devices or services are more appropriately defined as separate 1200 blocks. 1202 Privacy: Information which may contain private data may be better 1203 sent in the DeviceInfo block, rather than a new block so that 1204 implementations are not tempted to send the data by value, and 1205 thus having more exposure to the data than forcing the data to be 1206 retrieved via the URL in DeviceInfo. 1208 Size: Information which may be very large may be better sent in the 1209 DeviceInfo block, rather than a new block so that implementations 1210 are not tempted to send the data by value. Conversely, data which 1211 is small may best be sent in a separate block so that it can be 1212 sent by value 1214 Availability of a server: Providing the data via the device block 1215 requires a server be made available to retrieve the data. 1216 Providing the data via new block allows it to be sent by value 1217 (CID). 1219 4.3.9. EmergencyCallData.DeviceInfo Example 1221 1222 1224 d4b3072df.201409182208075@example.org 1225 1226 fixed 1227 Nokia 1228 Lumia 800 1229 35788104 1230 1231 1233 Figure 11: EmergencyCallData.DeviceInfo Example. 1235 4.4. Owner/Subscriber Information 1237 This block describes the owner of the device (if provided by the 1238 device) or the subscriber information (if provided by a service 1239 provider). The contact location is not necessarily the location of 1240 the caller or incident, but is rather the nominal contact address. 1241 The MIME type is "application/EmergencyCallData.SubscriberInfo+xml". 1243 In some jurisdictions some or all parts of the subscriber-specific 1244 information are subject to privacy constraints. These constraints 1245 vary but dictate what information can be displayed and logged. A 1246 general privacy indicator expressing a desire for privacy by the 1247 subscriber is provided. The interpretation of how this is applied is 1248 left to the receiving jurisdiction as the custodians of the local 1249 regulatory requirements. This matches an equivalent privacy flag 1250 provided in some legacy emergency call systems. 1252 4.4.1. Subscriber Data Privacy Indicator 1254 Attribute: 'privacyRequested', Boolean. 1256 Use: Conditional. This attribute MUST be provided if the owner/ 1257 subscriber information block is not empty. 1259 Description: The subscriber data privacy indicator specifically 1260 expresses the subscriber's desire for privacy. In some 1261 jurisdictions subscriber services can have a specific "Type of 1262 Service" which prohibits information, such as the name of the 1263 subscriber, from being displayed. This attribute is provided to 1264 explicitly indicate whether the subscriber service includes such 1265 constraints. The interpretation of this indicator is left to each 1266 jurisdiction (in keeping with the semantics of the privacy 1267 indicator provided in some legacy emergency call systems). 1269 Reason for Need: Some jurisdictions require subscriber privacy to be 1270 observed when processing emergency calls. 1272 How Used by Call Taker: Where privacy is indicated the call taker 1273 may not have access to some aspects of the subscriber information. 1275 4.4.2. xCard for Subscriber's Data 1277 Data Element: xCARD for Subscriber's Data 1279 Use: Conditional. Subscriber data MUST be provided unless it is not 1280 available. Some services, such as prepaid phones, non-initialized 1281 phones, etc., do not have information about the subscriber. 1283 XML Element: 1285 Description: Information known by the service provider or device 1286 about the subscriber; e.g., Name, Address, Individual Telephone 1287 Number, Main Telephone Number and any other data. , (if 1288 appropriate), , , are suggested at a minimum. 1289 If more than one property is provided, a parameter from the 1290 vCard Property Value registry MUST be specified on each . 1291 While some data (such as ) might not seem obviously 1292 relevant for emergency services, any data is potentially useful in 1293 some emergency circumstances. 1295 Reason for Need: When the caller is unable to provide information, 1296 this data may be used to obtain it 1298 How Used by Call Taker: Obtaining critical information about the 1299 caller and possibly the location when it is not able to be 1300 obtained otherwise. While the location here is not necessarily 1301 that of caller, in some circumstances it can be helpful in 1302 locating the caller when other means have failed. 1304 4.4.3. EmergencyCallData.SubscriberInfo Example 1306 1307 1311 FEABFECD901@example.org 1312 1313 1314 1315 Simon Perreault 1316 1317 Perreault 1318 Simon 1319 1320 1321 ing. jr 1322 M.Sc. 1323 1324 --0203 1325 1326 20090808T1430-0500 1327 1328 M 1329 1330 1 1331 1332 fr 1333 1334 1335 2 1336 1337 en 1338 1339 1340 work 1341 1342 Viagenie 1343 1344 1345 1346 work 1347 1351 1352 1353 1354 2875 boul. Laurier, suite D2-630 1355 Quebec 1356 QC 1357 G1V 2M2 1358 Canada 1359 1360 1361 1362 1363 work 1364 voice 1365 1366 1367 tel:+1-418-656-9254;ext=102 1368 1369 1370 1371 1372 work 1373 text 1374 voice 1375 cell 1376 video 1377 1378 1379 tel:+1-418-262-6501 1380 1381 1382 work 1383 1384 simon.perreault@viagenie.ca 1385 1386 1387 work 1388 1389 geo:46.766336,-71.28955 1390 1391 1392 work 1393 1394 1395 http://www.viagenie.ca/simon.perreault/simon.asc 1396 1397 1398 America/Montreal 1399 1400 home 1401 1402 http://nomis80.org 1403 1404 1405 1406 1408 Figure 12: EmergencyCallData.SubscriberInfo Example. 1410 4.5. Comment 1412 This block provides a mechanism for the data provider to supply 1413 extra, human readable information to the PSAP. It is not intended 1414 for a general purpose extension mechanism nor does it aim to provide 1415 machine-readable content. The mime subtype is "application/ 1416 EmergencyCallData.Comment+xml" 1418 4.5.1. Comment 1420 Data Element: EmergencyCallData.Comment 1422 Use: Optional 1424 XML Element: 1426 Description: Human readable text providing additional information to 1427 the PSAP staff. 1429 Reason for Need: Explanatory information for values in the data 1430 structure. 1432 How Used by Call Taker: To interpret the data provided. 1434 4.5.2. EmergencyCallData.Comment Example 1436 1437 1439 string0987654321@example.org 1440 1441 This is an example text. 1442 1444 Figure 13: EmergencyCallData.Comment Example. 1446 5. Data Transport Mechanisms 1448 This section defines how to convey additional data to an emergency 1449 service provider. Two different means are specified: the first uses 1450 the call signaling; the second uses the element of a 1451 PIDF-LO [RFC4119]. 1453 1. First, the ability to embed a Uniform Resource Identifier (URI) 1454 in an existing SIP header field, the Call-Info header, is 1455 defined. The URI points to the additional data structure. The 1456 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1457 document adds a new compound token starting with the value 1458 'EmergencyCallData' for the Call-Info "purpose" parameter. If 1459 the "purpose" parameter is set to a value starting with 1460 'EmergencyCallData', then the Call-Info header contains either an 1461 HTTPS URL pointing to an external resource or a CID (content 1462 indirection) URI that allows the data structure to be placed in 1463 the body of the SIP message. The "purpose" parameter also 1464 indicates the kind of data (by its MIME type) that is available 1465 at the URI. As the data is conveyed using a URI in the SIP 1466 signaling, the data itself may reside on an external resource, or 1467 may be contained within the body of the SIP message. When the 1468 URI refers to data at an external resource, the data is said to 1469 be passed by reference. When the URI refers to data contained 1470 within the body of the SIP message, the data is said to be passed 1471 by value. A PSAP or emergency responder is able to examine the 1472 type of data provided and selectively inspect the data it is 1473 interested in, while forwarding all of it (the values or 1474 references) to downstream entities. To be conveyed in a SIP 1475 body, additional data about a call is defined as a series of MIME 1476 objects. Each block defined in this document is an XML data 1477 structure identified by its MIME type. (Blocks defined by others 1478 may be encoded in XML or not, as identified by their MIME 1479 registration.) As usual, whenever more than one MIME part is 1480 included in the body of a message, MIME multipart (i.e., 1481 'multipart/mixed') encloses them all. This document defines a 1482 set of XML schemas and MIME types used for each block defined 1483 here. When additional data is passed by value in the SIP 1484 signaling, each CID URL points to one block in the body. 1485 Multiple URIs are used within a Call-Info header field (or 1486 multiple Call-Info header fields) to point to multiple blocks. 1487 When additional data is provided by reference (in SIP signaling 1488 or the element of a PIDF-LO), each HTTPS URL 1489 references one block; the data is retrieved with an HTTPS GET 1490 operation, which returns the block as an object (the blocks 1491 defined here are returned as XML objects). 1493 2. Second, the ability to embed additional data structures in the 1494 element of a PIDF-LO [RFC4119] is defined. In 1495 addition to service providers in the call path, the access 1496 network provider may also have similar information that can be 1497 valuable to the PSAP. When the access network provider supplies 1498 location information in the form of a PIDF-LO from a location 1499 server via a location configuration protocol, it has the ability 1500 to add the data structures defined in this document within the 1501 PIDF-LO. The data in these data structures is not specific to 1502 the location itself, but rather provides descriptive information 1503 having to do with the immediate circumstances about the provision 1504 of the location (e.g., the identity of the access network 1505 provider, how to contact that entity, what kind of service the 1506 access network provides, subscriber information, etc.). This 1507 data is similar in nearly every respect to the data known by 1508 service providers in the path of the call. When the access 1509 network provider and service provider are separate entities, the 1510 access network does not participate in the application layer 1511 signaling (and hence cannot add a Call-Info header field to the 1512 SIP message), but can provide location information in a PIDF-LO. 1513 The element of the PIDF-LO is a mechanism for the 1514 access network provider to supply the information. For this 1515 reason, this document describes a namespace per [RFC4119] for 1516 inclusion in the element of a PIDF-LO for adding 1517 information known to the access network provider. The access 1518 network provider SHOULD provide additional data within a 1519 element of a PDIF-LO it returns for emergency use 1520 (e.g., if requested with a HELD "responseTime" attribute of 1521 "emergencyRouting" or "emergencyDispatch" [RFC5985]). 1523 One or more blocks of data registered in the Emergency Call 1524 Additional Data registry, as defined in Section 10.1.9, can be 1525 included or referenced in the SIP signaling (using the Call-Info 1526 header field) or in the element of a PIDF-LO. For 1527 interoperability, only blocks in the registry are permitted to be 1528 sent using the mechanisms specified in this document. Since multiple 1529 entities are expected to provide sets of data, the data itself needs 1530 information describing the source. Consequently, each entity adding 1531 additional data MUST supply a "Data Provider" block. All other 1532 blocks are optional, but each entity SHOULD supply all blocks where 1533 it has at least some of the information in the block. 1535 5.1. Transmitting Blocks using the Call-Info Header 1537 A URI to a block MAY be inserted in any SIP request or response 1538 method (most often INVITE or MESSAGE) with a Call-Info header field 1539 containing a purpose value starting with 'EmergencyCallData' and the 1540 type of data available at the URI. The type of data is denoted by 1541 including the root of the MIME type (not including the 1542 'EmergencyCallData' prefix and any suffix such as '+xml') with a '.' 1543 separator. For example, when referencing a block with MIME type 1544 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 1545 parameter is set to 'EmergencyCallData.ProviderInfo'. An example 1546 "Call-Info" header field for this would be: 1548 Call-Info: https://www.example.com/23sedde3; 1549 purpose="EmergencyCallData.ProviderInfo" 1551 A Call-info header with a purpose value starting with 1552 'EmergencyCallData' only has meaning in the context of an emergency 1553 call (as ascertained by the presence of an emergency service URN in a 1554 Request-URI header of a SIP message), test emergency calls (using an 1555 appropriate service URN), and some private-use calls where the 1556 endpoints have a preexisting relationship and privacy concerns do not 1557 apply because of the relationship; use in other contexts is undefined 1558 and is likely to unnecessarily expose confidential data. 1560 If the data is provided by reference, an HTTPS URI MUST be included 1561 and consequently Transport Layer Security (TLS) protection is applied 1562 for protecting the retrieval of the information. 1564 The data may also be supplied by value in any SIP request or response 1565 method that is permitted to contain a body (i.e., not a BYE request). 1566 In this case, Content Indirection (CID) [RFC2392] is used, with the 1567 CID URL referencing the MIME body part containing the data. Note 1568 that [RFC3261] forbids proxies from altering message bodies, so 1569 entities in the call path that add blocks by value need to do so 1570 using an appropriate SIP entity (e.g., a back-to-back user agent). 1572 Transmitting data by value is especially useful in certain cases, 1573 such as when the data exists in or is generated by the originating 1574 device, but is not intended for very large data blocks. Additional 1575 security and privacy considerations apply to data transmitted by 1576 value, as discussed in Section 8 and Section 9. 1578 More than one Call-Info header with a purpose value starting with 1579 'EmergencyCallData' can be expected, but at least one MUST be 1580 provided. The device MUST provide one if it knows no service 1581 provider is in the path of the call. The device MAY insert one if it 1582 uses a service provider. Any service provider in the path of the 1583 call MUST insert its own. For example, a device, a telematics 1584 service provider in the call path, as well as the mobile carrier 1585 handling the call will each provide one. There may be circumstances 1586 where there is a service provider who is unaware that the call is an 1587 emergency call and cannot reasonably be expected to determine that it 1588 is an emergency call. In that case, that service provider is not 1589 expected to provide EmergencyCallData. 1591 5.2. Transmitting Blocks by Reference using the Element 1593 The element is used to transmit an 1594 additional data block by reference within a element of 1595 a PIDF-LO. The element has two 1596 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1597 type of data block referenced. The value of 'ref' is an HTTPS URL 1598 that resolves to a data structure with information about the call. 1599 The value of 'purpose' is the same as used in a 'Call-Info' header 1600 field (as specified in Section 5.1). 1602 For example, to reference a block with MIME type 'application/ 1603 EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set 1604 to 'EmergencyCallData.ProviderInfo'. An example 1605 element for this would be: 1607 1610 The element transmits one data block; 1611 multiple data blocks may be transmitted by using multiple 1612 elements. Multiple 1613 elements MAY be included as child 1614 elements inside the element. 1616 The following is a simplified example: 1618 1623 1627 1630 1632 Example by Reference 1634 For an example in context, Figure 18 shows a PIDF-LO example with an 1635 element pointing to an 1636 EmergencyCallData.ServiceInfo data block with the URL in the 'ref' 1637 attribute and the purpose attribute set to 1638 "EmergencyCallData.ServiceInfo". 1640 5.3. Transmitting Blocks by Value using the Element 1642 It is RECOMMENDED that access networks supply the data specified in 1643 this document by reference, but they MAY provide the data by value. 1645 The element is used to transmit one or more 1646 additional data blocks by value within a element of a 1647 PIDF-LO. Each block being transmitted is placed (as a child element) 1648 inside the element. (The same XML structure 1649 as would be contained in the corresponding MIME type body part is 1650 placed inside the element.) Multiple 1651 elements MAY be included as child elements 1652 in the element. 1654 The following is a simplified example: 1656 1660 1663 flurbit735@es.example.com 1664 1665 Access Network Examples, Inc 1666 1667 urn:nena:companyid:Test 1668 NENA 1669 Access Network Provider 1670 1671 tel:+1-555-555-0897 1672 en 1673 1675 1678 flurbit735@es.example.com 1679 1680 This is an example text. 1681 1682 1684 1686 1688 Example by Value 1690 For an example in context, Figure 18 shows a PIDF-LO example that 1691 contains a element with the 1692 and the 1693 elements as child elements of an element. 1695 5.4. The Content-Disposition Parameter 1697 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1698 It updates and clarifies handling originally defined in RFC 3261 1699 [RFC3261] based on implementation experience. While RFC 3261 did not 1700 mandate support for 'multipart' message bodies, 'multipart/mixed' 1701 MIME bodies are used by many extensions (including this document) 1702 today. For example, adding a PIDF-LO, SDP, and additional data in 1703 body of a SIP message requires a 'multipart' message body. 1705 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1706 parameter for the Content-Disposition header field. These RFCs 1707 describe how a UAS reacts if it receives a message body whose content 1708 type or disposition type it does not understand. If the 'handling' 1709 parameter has the value "optional", the UAS ignores the message body. 1710 If the 'handling' parameter has the value "required", the UAS returns 1711 a 415 (Unsupported Media Type) response. The 'by-reference' 1712 disposition type allows a SIP message to contain a reference to the 1713 body part, and the SIP UA processes the body part according to the 1714 reference. This is the case for the Call-info header containing a 1715 Content Indirection (CID) URL. 1717 As an example, a SIP message indicates the Content-Disposition 1718 parameter in the body of the SIP message as shown in Figure 14. 1720 Content-Type: application/sdp 1722 ...Omit Content-Disposition here; defaults are ok 1723 ...SDP goes in here 1725 --boundary1 1727 Content-Type: application/pidf+xml 1728 Content-ID: 1729 Content-Disposition: by-reference;handling=optional 1731 ...PIDF-LO goes in here 1733 --boundary1-- 1735 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1736 Content-ID: <1234567890@atlanta.example.com> 1737 Content-Disposition: by-reference; handling=optional 1739 ...Data provider information data goes in here 1741 --boundary1-- 1743 Figure 14: Example for use of the Content-Disposition Parameter in 1744 SIP 1746 6. Examples 1748 This section illustrates a longer and more complex example, as shown 1749 in Figure 15. In this example additional data is added by the end 1750 device, included by the VoIP provider, and provided by the access 1751 network provider (via the PIDF-LO). 1753 O +----+ [============] [=============] 1754 /|\ | UA | [ Access ] [ VoIP ] 1755 | +----+ [ Network ] [ Provider ] 1756 / \ [ Provider ] [ example.org ] 1757 [ ] [ ] 1758 (1) [ ] (2) [ ] 1759 Emergency Call [ ] Emergency Call [ ] 1760 ------------------------------------------------------> ] 1761 +Device Info [ ] +Device Info [ ] 1762 +Data Prov. Info [ ^ ] +Data Provider Info [ | ] 1763 +Location URI [=======.====] +Location URI [====|========] 1764 . | 1765 . | 1766 +Location . [==============] | 1767 +Owner/Subscriber Info . [ ] (3) | 1768 +Device Info . (4) [ <------------+ 1769 +Data Provider Info #3 ..........> ] Emergency Call 1770 [ ] +Device Info 1771 [ PSAP ] +Data Prov. Info #2 1772 [ ] +Location URI 1773 [==============] 1775 Legend: 1777 --- Emergency Call Setup Procedure 1778 ... Location Retrieval/Response 1780 Figure 15: Additional Data Example Flow 1782 The example scenario starts with the end device itself adding device 1783 information, owner/subscriber information, a location URI, and data 1784 provider information to the outgoing emergency call setup message 1785 (see step #1 in Figure 15). The SIP INVITE example is shown in 1786 Figure 16. 1788 INVITE urn:service:sos SIP/2.0 1789 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1790 Max-Forwards: 70 1791 To: 1792 From: Hannes Tschofenig ;tag=9fxced76sl 1793 Call-ID: 3848276298220188511@example.com 1794 Call-Info: 1795 ;purpose=icon, 1796 ;purpose=info, 1797 1798 ;purpose=EmergencyCallData.ProviderInfo, 1800 1801 ;purpose=EmergencyCallData.DeviceInfo 1802 Geolocation: 1803 Geolocation-Routing: yes 1804 Accept: application/sdp, application/pidf+xml, 1805 application/EmergencyCallData.ProviderInfo+xml 1806 CSeq: 31862 INVITE 1807 Contact: 1808 Content-Type: multipart/mixed; boundary=boundary1 1810 Content-Length: ... 1812 --boundary1 1814 Content-Type: application/sdp 1816 ...SDP goes here 1818 --boundary1-- 1820 Content-Type: application/EmergencyCallData.DeviceInfo+xml 1821 Content-ID: <0123456789@atlanta.example.com> 1822 Content-Disposition: by-reference;handling=optional 1823 1825 1827 d4b3072df09876543@[93.184.216.119] 1828 1829 laptop 1830 00-0d-4b-30-72-df 1832 1834 --boundary1-- 1836 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1837 Content-ID: <1234567890@atlanta.example.com> 1838 Content-Disposition: by-reference;handling=optional 1839 1840 1842 d4b3072df09876543@[93.184.216.119] 1843 1844 Hannes Tschofenig 1845 1846 Client 1847 tel:+1-555-555-0123 1848 en 1849 1851 1852 Hannes Tschofenig 1853 1854 Hannes 1855 Tschofenig 1856 1857 1858 Dipl. Ing. 1859 1860 --0203 1861 1862 20090808T1430-0500 1863 1864 M 1865 1866 1 1867 1868 de 1869 1870 1871 2 1872 1873 en 1874 1875 1876 1877 work 1878 1882 1883 1884 1885 Linnoitustie 6 1886 Espoo 1887 Uusimaa 1888 02600 1889 Finland 1890 1891 1892 1893 home 1894 1899 1900 1901 1902 42 W 11th St 1903 Wilmington 1904 DE 1905 19801 1906 USA 1907 1908 1909 1910 1911 work 1912 voice 1913 1914 1915 tel:+358 50 4871445 1916 1917 1918 1919 1920 home 1921 voice 1922 1923 1924 tel:+1 555 555 0123 1925 1926 1927 work 1928 1929 hannes.tschofenig@nsn.com 1930 1931 1932 work 1933 1934 geo:60.210796,24.812924 1935 1936 1937 home 1938 1939 geo:39.746537,-75.548027 1940 1941 1942 1943 home 1944 1945 https://www.example.com/key.asc 1946 1947 1948 Finland/Helsinki 1949 1950 home 1951 1952 http://example.com/hannes.tschofenig 1953 1954 1955 1956 1957 1958 --boundary1-- 1960 Figure 16: End Device sending SIP INVITE with Additional Data 1962 In this example, information available to the access network provider 1963 is included in the call setup message only indirectly via the use of 1964 the location reference. The PSAP has to retrieve it via a separate 1965 look-up step. Since the access network provider and the VoIP service 1966 provider are two independent entities in this scenario, the access 1967 network provider is not involved in application layer exchanges; the 1968 SIP INVITE transits the access network transparently, as illustrated 1969 in steps #1 and #2 (the access network does not alter the SIP 1970 INVITE). 1972 The VoIP service provider receives the message and determines, based 1973 on the Service URN, that the incoming request is an emergency call. 1974 It performs typical emergency services related tasks (such as 1975 location-based routing), and adds additional data, namely service and 1976 subscriber information as well as data provider information #2, to 1977 the outgoing message. For the example we assume a VoIP service 1978 provider that deploys a back-to-back user agent allowing additional 1979 data to be included in the body of the SIP message (rather than by 1980 reference), which allows us to illustrate the use of multiple data 1981 provider info blocks. The resulting message is shown in Figure 17. 1982 The SIP INVITE is sent to the PSAP in step #3. 1984 INVITE sips:psap@example.org SIP/2.0 1985 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1986 Max-Forwards: 70 1987 To: 1988 From: Hannes Tschofenig ;tag=9fxced76sl 1989 Call-ID: 3848276298220188511@example.com 1990 Call-Info: 1991 ;purpose=icon, 1992 ;purpose=info, 1993 1994 ;purpose=EmergencyCallData.ProviderInfo 1995 1996 ;purpose=EmergencyCallData.DeviceInfo 1997 Call-Info: 1998 ;purpose=EmergencyCallData.ServiceInfo 1999 Call-Info: 2000 ;purpose=EmergencyCallData.ProviderInfo 2001 Geolocation: 2002 Geolocation-Routing: yes 2003 Accept: application/sdp, application/pidf+xml, 2004 application/EmergencyCallData.ProviderInfo+xml 2005 CSeq: 31862 INVITE 2006 Contact: 2007 Content-Type: multipart/mixed; boundary=boundary1 2009 Content-Length: ... 2011 --boundary1 2013 Content-Type: application/sdp 2015 ...SDP goes here 2017 --boundary1-- 2019 Content-Type: application/EmergencyCallData.DeviceInfo+xml 2020 Content-ID: <0123456789@atlanta.example.com> 2021 Content-Disposition: by-reference;handling=optional 2022 2024 2026 d4b3072df09876543@[93.184.216.119] 2027 2028 laptop 2029 00-0d-4b-30-72-df 2031 2033 --boundary1-- 2035 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2036 Content-ID: <1234567890@atlanta.example.com> 2037 Content-Disposition: by-reference;handling=optional 2038 2039 2041 d4b3072df09876543@[93.184.216.119] 2042 2043 Hannes Tschofenig 2044 2045 Client 2046 tel:+1-555-555-0123 2047 en 2048 2050 2051 Hannes Tschofenig 2052 2053 Hannes 2054 Tschofenig 2055 2056 2057 Dipl. Ing. 2058 2059 --0203 2060 2061 20090808T1430-0500 2062 2063 M 2064 2065 1 2066 2067 de 2068 2069 2070 2 2071 2072 en 2073 2074 2075 2076 work 2077 2081 2082 2083 2084 Linnoitustie 6 2085 Espoo 2086 Uusimaa 2087 02600 2088 Finland 2089 2090 2091 2092 home 2093 2098 2099 2100 2101 42 W 11th St 2102 Wilmington 2103 DE 2104 19801 2105 USA 2106 2107 2108 2109 2110 work 2111 voice 2112 2113 2114 tel:+358 50 4871445 2115 2116 2117 2118 2119 home 2120 voice 2121 2122 2123 tel:+1 555 555 0123 2124 2125 2126 work 2127 2128 hannes.tschofenig@nsn.com 2129 2130 2131 work 2132 2133 geo:60.210796,24.812924 2134 2135 2136 home 2137 2138 geo:39.746537,-75.548027 2139 2140 2141 2142 home 2143 2144 https://www.example.com/key.asc 2145 2146 2147 Finland/Helsinki 2148 2149 home 2150 2151 http://example.com/hannes.tschofenig 2152 2153 2154 2155 2156 2158 --boundary1-- 2160 Content-Type: application/EmergencyCallData.ServiceInfo+xml 2161 Content-ID: 2162 Content-Disposition: by-reference;handling=optional 2163 2164 2166 string0987654321@example.org 2167 2168 Residence 2169 VOIP 2170 Unknown 2171 2173 --boundary1-- 2175 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2176 Content-ID: 2177 Content-Disposition: by-reference;handling=optional 2178 2179 2181 string0987654321@example.org 2182 2183 Exemplar VoIP Provider 2184 2185 urn:nena:companyid:ID123 2186 NENA 2187 Service Provider 2188 sip:voip-provider@example.com 2189 en 2190 2192 2193 John Doe 2194 2195 John 2196 Doe 2197 2198 2199 2200 2201 --0203 2202 2203 20090808T1430-0500 2204 2205 M 2206 2207 1 2208 2209 en 2210 2211 2212 work 2213 2214 Exemplar VoIP Provider 2215 2216 2217 2218 work 2219 2222 2223 2224 2225 123 Middle Street 2226 the Sticks 2227 IA 2228 50055 2229 USA 2230 2231 2232 2233 2234 work 2235 voice 2236 2237 2238 sips:john.doe@example.com 2239 2240 2241 work 2242 2243 john.doe@example.com 2244 2245 2246 work 2247 2248 geo:41.761838,-92.963268 2249 2250 America/Chicago 2251 2252 home 2253 2254 http://www.example.com/john.doe 2255 2256 2257 2258 2260 Figure 17: VoIP Provider sending SIP INVITE with Additional Data 2262 Finally, the PSAP requests location information from the access 2263 network provider. The response is shown in Figure 18. Along with 2264 the location information, additional data is provided in the 2265 element of the PIDF-LO. This request and response is 2266 step #4. 2268 2269 2274 2275 2276 2277 2279 US 2280 DE 2281 Wilmington 2282 W 2283 11th 2284 Street 2285 42 2286 The Hotel DuPont 2287 19801 2288 2289 2290 2291 true 2292 2293 2013-12-10T20:00:00Z 2294 2295 2296 802.11 2298 2301 2305 2306 2309 88QV4FpfZ976T@example.com 2310 2311 Diamond State Exemplar 2312 2313 urn:nena:companyid:diamond 2314 NENA 2315 Access Network Provider 2316 tel:+1-302-555-0000 2317 en 2318 2320 2322 88QV4FpfZ976T@example.com 2323 2324 This is an example text. 2325 2327 2328 2329 2330 mac:00-0d-4b-30-72-df 2331 2013-07-09T20:57:29Z 2332 2333 2335 Figure 18: Access Network Provider returning PIDF-LO with Additional 2336 Data 2338 7. XML Schemas 2340 This section defines the XML schemas of the five data blocks. 2341 Additionally, the provided-by schema is specified. 2343 7.1. EmergencyCallData.ProviderInfo XML Schema 2345 2346 2356 2359 2362 2366 2367 2368 2369 2371 2372 2374 2375 2376 2379 2382 2385 2388 2391 2394 2395 2396 2397 2403 2404 2405 2407 2409 2410 2411 2413 2414 2415 2416 2419 2423 2425 2426 2428 2430 Figure 19: EmergencyCallData.ProviderInfo XML Schema. 2432 7.2. EmergencyCallData.ServiceInfo XML Schema 2433 2434 2443 2446 2449 2450 2451 2454 2457 2461 2464 2466 2467 2469 2471 Figure 20: EmergencyCallData.ServiceInfo XML Schema. 2473 7.3. EmergencyCallData.DeviceInfo XML Schema 2475 2476 2485 2488 2491 2492 2493 2496 2499 2502 2505 2507 2508 2509 2510 2513 2514 2515 2516 2518 2521 2524 2526 2527 2529 2531 Figure 21: EmergencyCallData.DeviceInfo XML Schema. 2533 7.4. EmergencyCallData.SubscriberInfo XML Schema 2535 2536 2547 2550 2553 2556 2557 2558 2559 2560 2563 2564 2565 2566 2568 2569 2570 2572 2574 2575 2577 2578 2579 2581 2583 Figure 22: EmergencyCallData.SubscriberInfo XML Schema. 2585 7.5. EmergencyCallData.Comment XML Schema 2586 2587 2596 2599 2602 2603 2604 2607 2611 2613 2614 2616 2617 2618 2619 2620 2621 2622 2624 2626 Figure 23: EmergencyCallData.Comment XML Schema. 2628 7.6. provided-by XML Schema 2630 This section defines the provided-by schema. 2632 2633 2648 2651 2654 2657 2660 2664 2667 2670 2672 2673 2674 2675 2676 2678 2679 2682 2684 2685 2686 2688 2690 2691 2692 2695 2698 2701 2704 2708 2711 2712 2714 2716 Figure 24: provided-by XML Schema 2718 8. Security Considerations 2720 The data structures described in this document contain information 2721 usually considered private. When information is provided by value, 2722 entities that are a party to the SIP signaling (such as proxy servers 2723 and back-to-back user agents) will have access to it and need to 2724 protect it against inappropriate disclosure. An entity that is able 2725 to eavesdrop on the SIP signaling will also have access. Some access 2726 types (such as in-the-clear Wi-Fi) are more vulnerable than others 2727 (such as 3G or 4G cellular data traffic) to eavesdropping. 2728 Mechanisms that protect against eavesdropping (such as Transport 2729 Layer Security (TLS)) SHOULD be preferentially used whenever 2730 feasible. (This requirement is not a "MUST" because there is an 2731 existing deployed base of clear-text SIP, and also because, as an 2732 emergency call, it is more important for the call to go through than 2733 for it to be protected; e.g., the call MUST proceed even if the TLS 2734 negotiation or certificate verification fails for whatever reason.) 2735 When information is provided by reference, HTTPS is REQUIRED for 2736 dereferencing, and the provider of the information is REQUIRED to 2737 validate the credentials of the requester. While the creation of a 2738 public key infrastructure (PKI) that has global scope may be 2739 difficult, the alternatives to creating devices and services that can 2740 provide critical information securely are more daunting. The 2741 provider of the information MAY enforce any policy it wishes to use, 2742 but PSAPs and responder agencies SHOULD deploy a PKI so that 2743 providers of additional data can check the certificate of the client 2744 (the requester) and decide the appropriate policy to enforce based on 2745 that certificate. 2747 Ideally, the PSAP and emergency responders will be given credentials 2748 signed by an authority trusted by the data provider. In most 2749 circumstances, nationally recognized credentials are sufficient; the 2750 emergency services community within a country can arrange a PKI, data 2751 providers can be provisioned with the root CA public key for the 2752 country. Some nations are developing a PKI for this, and related, 2753 purposes. Since calls could be made from devices where the device 2754 and/or the service provider(s) are not local to the emergency 2755 services authorities, globally recognized credentials are useful. 2756 This might be accomplished by extending the notion of the "forest 2757 guide" described in [RFC5582] to allow the forest guide to provide 2758 the credential of the PKI root for areas for which it has coverage 2759 information, but standards for such a mechanism are not yet 2760 available. In its absence, the data provider needs to obtain by out 2761 of band means the root CA credentials for any areas to which it is 2762 willing to provide additional data. With the credential of the root 2763 CA for a national emergency services PKI, the data provider server 2764 can validate the credentials of an entity requesting additional data 2765 by reference. 2767 The data provider also needs a credential that can be verified by the 2768 emergency services to know that it is receiving data from an 2769 authorized server. The emergency services authorities could provide 2770 credentials, distinguishable from credentials provided to emergency 2771 responders and PSAPs, which could be used to validate data providers. 2772 Such credentials would have to be acceptable to any PSAP or responder 2773 that could receive a call with additional data supplied by that 2774 provider. This would be extensible to global credential validation 2775 using the forest guide as mentioned above. In the absence of such 2776 credentials, the emergency services authorities could maintain a list 2777 of local data providers' credentials as provided to them out of band. 2779 At a minimum, the emergency services authorities could obtain a 2780 credential from the DNS entry of the domain in the Additional Data 2781 URI to at least validate that the server is known to the domain 2782 providing the URI. 2784 Data provided by devices by reference have similar credential 2785 validation issues as for service providers, and while the solutions 2786 are the same, the challenges of doing so for every device are 2787 obviously more difficult, especially when considering root 2788 certificate updates, revocation lists, etc. However, in general, 2789 devices are not expected to provide data directly by reference, but 2790 rather, to either provide data by value, or upload the data to a 2791 server which can more reliably make it available and more easily 2792 enforce security policy. Devices which do provide data directly by 2793 reference, which might include fixed-location sensors, will need to 2794 be capable of handling this. 2796 Much of the information supplied by service providers and devices is 2797 private and confidential; service providers and devices generally go 2798 to lengths to protect this information; disclosing it in the context 2799 of an emergency call is a trade-off to protect the greater interest 2800 of the customer in an emergency. 2802 Neither service providers nor devices will supply private information 2803 unless the call is recognized as an emergency call. In cellular 2804 telephony systems (such as those using 3GPP IMS), there are different 2805 procedures for an originating device to place an emergency versus a 2806 normal call. If a call that is really an emergency call is initiated 2807 as a normal call and the cellular service provider recognizes this, 2808 3GPP IMS permits the service provider to either accept the call 2809 anyway or reject it with a specific code that instructs the device to 2810 retry the call as an emergency call. Service providers ought to 2811 choose the latter, because otherwise the device will not have 2812 included the information specified in this document (since the device 2813 didn't recognize the call as being an emergency call). 2815 9. Privacy Considerations 2817 This document enables functionality for conveying additional 2818 information about the caller and the caller's device and service to 2819 the callee. Some of this information is personal data and therefore 2820 privacy concerns arise. An explicit privacy indicator for 2821 information directly relating to the caller's identity is defined and 2822 use is mandatory. However, observance of this request for privacy 2823 and which information it relates to is determined by the destination 2824 jurisdiction (which replicates functionality provided in some legacy 2825 emergency services systems). 2827 There are a number of privacy concerns with non-emergency real-time 2828 communication services that are also applicable to emergency calling. 2829 Data protection regulation world-wide has, however, decided to create 2830 exceptions for emergency services since the drawbacks of disclosing 2831 personal data are outweighed by the benefit for the emergency caller. 2832 Hence, the data protection rights of individuals are commonly waived 2833 for emergency situations. There are, however, still various 2834 countries that offer some degree of anonymity for the caller towards 2835 PSAP call takers. 2837 The functionality defined in this document far exceeds the amount of 2838 information sharing available in the legacy POTS system. For this 2839 reason there are additional privacy threats to consider, which are 2840 described in more detail in [RFC6973]. 2842 Stored Data Compromise: There is an increased risk of stored data 2843 compromise since additional data is collected and stored in 2844 databases. Without adequate measures to secure stored data from 2845 unauthorized or inappropriate access at access network providers, 2846 service providers, end devices, as well as PSAPs, individuals are 2847 exposed to potential financial, reputational, or physical harm. 2849 Misattribution: If the personal data collected and conveyed is 2850 incorrect or inaccurate then this may lead to misattribution. 2851 Misattribution occurs when data or communications related to one 2852 individual are attributed to another. 2854 Identification: By the nature of the additional data and its 2855 capability to provide much richer information about the caller, 2856 the call, and the location, the calling party is identified in a 2857 much better way. Some users may feel uncomfortable with this 2858 degree of information sharing even in emergency services 2859 situations. 2861 Secondary Use: There is a risk of secondary use, which is the use of 2862 collected information about an individual without the individual's 2863 consent for a purpose different from that for which the 2864 information was collected. The stated purpose of the additional 2865 data is for emergency services purposes but theoretically the same 2866 information could be used for any other call as well. 2867 Additionally, parties involved in the emergency call may retain 2868 the obtained information and may re-use it for other, non- 2869 emergency services purposes. 2871 Disclosure: When the data defined in this document is not properly 2872 protected (while in transit with traditional communication 2873 security techniques, and while stored using access control 2874 mechanisms) there is the risk of disclosure, which is the 2875 revelation of private information about an individual. 2877 To mitigate these privacy risks the following countermeasures can be 2878 taken: 2880 In regions where callers can elect to suppress certain personally 2881 identifying information, network or PSAP functionality can inspect 2882 privacy flags within the SIP headers to determine what information 2883 may be passed, stored, or displayed to comply with local policy or 2884 law. RFC 3325 [RFC3325] defines the "id" priv-value token. The 2885 presence of this privacy type in a Privacy header field indicates 2886 that the user would like the network asserted identity to be kept 2887 private with respect to SIP entities outside the trust domain with 2888 which the user authenticated, including the PSAP. 2890 This document defines various data structures that contain privacy- 2891 sensitive data. For example, identifiers for the device (e.g., 2892 serial number, MAC address) or account/SIM (e.g., IMSI), contact 2893 information for the user, location of the caller. Local regulations 2894 may govern which data is provided in emergency calls, but in general, 2895 the emergency call system is aided by the information described in 2896 this document. There is a tradeoff between the privacy 2897 considerations and the utility of the data. For protection, this 2898 specification requires all retrieval of data passed by reference to 2899 be protected against eavesdropping and alteration via communication 2900 security techniques (namely TLS). Furthermore, security safeguards 2901 are required to prevent unauthorized access to stored data. Various 2902 security incidents over at least the past few decades have shown that 2903 data breaches are not uncommon and are often caused by lack of proper 2904 access control frameworks, software bugs (such as buffer overflows), 2905 or missing input parsing (such as SQL injection attacks). The risks 2906 of data breaches is increased with the obligation for emergency 2907 services to retain emergency call related data for extended periods 2908 (e.g., several years are the norm). 2910 Finally, it is also worth highlighting the nature of the SIP 2911 communication architecture, which introduces additional complications 2912 for privacy. Some forms of data can be sent by value in the SIP 2913 signaling or by reference (a URL in the SIP signaling). When data is 2914 sent by value, all intermediaries have access to the data. As such, 2915 these intermediaries may also introduce additional privacy risk. 2916 Therefore, in situations where the conveyed information is privacy- 2917 sensitive and intermediaries are involved, transmitting by reference 2918 might be appropriate, assuming the source of the data can operate a 2919 sufficient dereferencing infrastructure and that proper access 2920 control policies are available for distinguishing the different 2921 entities dereferencing the reference. Without access control 2922 policies any party in possession of the reference is able to resolve 2923 the reference and to obtain the data, including intermediaries. 2925 10. IANA Considerations 2927 10.1. Registry creation 2929 This document creates a new registry called 'Emergency Call 2930 Additional Data'. The following sub-registries are created for this 2931 registry. 2933 10.1.1. Provider ID Series Registry 2935 This document creates a new sub-registry called "Additional Call Data 2936 Provider ID Series". As defined in [RFC5226], this registry operates 2937 under "Expert Review" rules. The expert should determine that the 2938 entity requesting a new value is a legitimate issuer of service 2939 provider IDs suitable for use in Additional Call Data. 2941 Private entities issuing or using internally-generated IDs are 2942 encouraged to register here and to ensure that all IDs they issue or 2943 use are unique. This guarantees that IDs issued or used by the 2944 entity are globally unique and distinguishable from other IDs issued 2945 or used by the same or a different entity. (Some organizations, such 2946 as NENA, issue IDs that are unique among all IDs they issue, so an 2947 entity using a combination of its NENA ID and the fact that it is 2948 from NENA is globally unique. Other entities might not have an ID 2949 issued by an organization such as NENA, so they are permitted to use 2950 their domain name, but if so, it needs to be unique.) 2952 The content of this registry includes: 2954 Name: An identifier to be used in the 'ProviderIDSeries' element. 2956 Source: The full name of the organization issuing the identifiers. 2958 URL: A URL to the organization for further information. 2960 The initial set of values is listed in Figure 1. 2962 10.1.2. Service Environment Registry 2964 This document creates a new sub-registry called 'Additional Call 2965 Service Environment'. As defined in [RFC5226], this registry 2966 operates under "Expert Review" rules. The expert should determine 2967 that the entity requesting a new value is relevant for this service 2968 element, and that the new value is distinct from existing values, and 2969 its use is unambiguous. 2971 The content of this registry includes: 2973 Token: The value to be used in the element. 2975 Description: A short description of the value. 2977 The initial set of values is listed in Figure 4. 2979 10.1.3. Service Type Registry 2981 This document creates a new sub-registry called 'Additional Call 2982 Service Type'. As defined in [RFC5226], this registry operates under 2983 "Expert Review" rules. The expert should determine that the entity 2984 requesting a new value is relevant for this service element and that 2985 the requested value is clearly distinct from other values so that 2986 there is no ambiguity as to when the value is to be used or which 2987 value is to be used. 2989 The content of this registry includes: 2991 Name: The value to be used in the element. 2993 Description: A short description of the value. 2995 The initial set of values is listed in Figure 5. 2997 10.1.4. Service Mobility Registry 2999 This document creates a new sub-registry called 'Additional Call 3000 Service Mobility'. As defined in [RFC5226], this registry operates 3001 under "Expert Review" rules. The expert should determine that the 3002 entity requesting a new value is relevant for this service element 3003 and that the requested value is clearly distinct from other values so 3004 that there is no ambiguity as to when the value is to be used or 3005 which value is to be used. 3007 The content of this registry includes: 3009 Token: The value used in the element. 3011 Description: A short description of the value. 3013 The initial set of values is listed in Figure 6. 3015 10.1.5. Service Provider Type Registry 3017 This document creates a new sub-registry called 'Service Provider 3018 Type'. As defined in [RFC5226], this registry operates under "Expert 3019 Review". The expert should determine that the proposed new value is 3020 distinct from existing values and appropriate for use in the 3021 element 3023 The content of this registry includes: 3025 Token: The value used in the element. 3027 Description: A short description of the type of service provider. 3029 The initial set of values is defined in Figure 2. 3031 10.1.6. Device Classification Registry 3033 This document creates a new sub-registry called 'Device 3034 Classification'. As defined in [RFC5226], this registry operates 3035 under "Expert Review" rules. The expert should consider whether the 3036 proposed class is unique from existing classes and the definition of 3037 the class will be clear to implementors and PSAPs/responders. 3039 The content of this registry includes: 3041 Token: Value used in the element. 3043 Description: Short description identifying the device type. 3045 The initial set of values are defined in Figure 8. 3047 10.1.7. Device ID Type Type Registry 3049 This document creates a new sub-registry called 'Additional Call Data 3050 Device ID Type'. As defined in [RFC5226], this registry operates 3051 under "Expert Review" rules. The expert should ascertain that the 3052 proposed type is well understood, and provides information which 3053 PSAPs and responders are able to use to uniquely identify a device. 3054 (For example, a biometric fingerprint used to authenticate a device 3055 would not normally be useful by a PSAP or responder to identify a 3056 device.) 3058 The content of this registry includes: 3060 Token: The value to be placed in the element. 3062 Description: Short description identifying the type of the device 3063 ID. 3065 The initial set of values are defined in Figure 9. 3067 10.1.8. Device/Service Data Type Registry 3069 This document creates a new sub-registry called 'Device/Service Data 3070 Type Registry'. As defined in [RFC5226], this registry operates 3071 under "Specification Required" rules, which include an explicit 3072 expert review. The designated expert should ascertain that the 3073 proposed type is well understood, and provides information useful to 3074 PSAPs and responders. The specification must contain a complete 3075 description of the data, and a precise format specification suitable 3076 to allow interoperable implementations. 3078 The content of this registry includes: 3080 Token: The value to be placed in the element. 3082 Description: Short description identifying the the data. 3084 Specification: Citation for the specification of the data. 3086 The initial set of values are listed in Figure 10. 3088 10.1.9. Emergency Call Data Types Registry 3090 This document creates a new sub-registry called 'Emergency Call Data 3091 Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. 3092 As defined in [RFC5226], this registry operates under "Specification 3093 Required" rules, which include an explicit expert review. The expert 3094 is responsible for verifying that the document contains a complete 3095 and clear specification and the proposed functionality does not 3096 obviously duplicate existing functionality. The expert is also 3097 responsible for verifying that the block is correctly categorized per 3098 the description of the categories in Section 1. 3100 The registry contains an entry for every data block that can be sent 3101 with an emergency call using the mechanisms as specified in this 3102 document. Each data block is identified by the "root" of its MIME 3103 subtype (which is the part after 'EmergencyCallData.'). If the MIME 3104 subtype does not start with 'EmergencyCallData.', then it cannot be 3105 registered here nor used in a Call-Info header as specified in this 3106 document. The subtype MAY exist under any MIME type (although most 3107 commonly these are under 'Application/' this is NOT REQUIRED), 3108 however, to be added to the registry the "root" needs to be unique 3109 regardless of the MIME type. 3111 The content of this registry includes: 3113 Token: The root of the data's MIME subtype (not including the 3114 'EmergencyCallData' prefix and any suffix such as '+xml') 3116 Data About: Indicates if the data describes the call, the caller, or 3117 the location (or is applicable to all), which helps PSAPs and 3118 other entities determine if they wish to process the block. The 3119 value MUST be either "The Call", "The Caller", "The Location", or 3120 "All". New values are created by extending this registry in a 3121 subsequent RFC. 3123 Reference: The document that describes the data object 3125 Note that the values from this registry are part of the 3126 'EmergencyCallData' compound value; when used as a value of the 3127 'purpose' parameter of the Call-Info header, the values listed in 3128 this registry are prefixed by 'EmergencyCallData.' per the the 3129 'EmergencyCallData' registation Section 10.2. 3131 The initial set of values are listed in Figure 25. 3133 +----------------+--------------+------------+ 3134 | Token | Data About | Reference | 3135 +----------------+--------------+------------+ 3136 | ProviderInfo | The Call | [This RFC] | 3137 | ServiceInfo | The Call | [This RFC] | 3138 | DeviceInfo | The Call | [This RFC] | 3139 | SubscriberInfo | The Call | [This RFC] | 3140 | Comment | The Call | [This RFC] | 3141 +----------------+--------------+------------+ 3143 Figure 25: Additional Data Blocks Registry 3145 10.2. 'EmergencyCallData' Purpose Parameter Value 3147 This document defines the 'EmergencyCallData' value for the "purpose" 3148 parameter of the Call-Info header field. The Call-Info header and 3149 the corresponding registry for the 'purpose' parameter was 3150 established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData' 3151 is a compound value; when used as a value of the 'purpose' parameter 3152 of the Call-Info header, 'EmergencyCallData' is immediately followed 3153 by a dot ('.') and a value from the 'Emergency Call Data Types' 3154 registry Section 10.1.9. 3156 Header Parameter New 3157 Field Name Value Reference 3158 ---------- --------- ----------------- --------- 3159 Call-Info purpose EmergencyCallData [This RFC] 3161 10.3. URN Sub-Namespace Registration for Registry Entry 3163 This section registers the namespace specified in Section 10.5.1 in 3164 the provided-by registry established by RFC 4119, for usage within 3165 the element of a PIDF-LO. 3167 The schema for the element used by this document is 3168 specified in Section 7.6. 3170 10.4. MIME Registrations 3172 10.4.1. MIME Content-type Registration for 'application/ 3173 EmergencyCallData.ProviderInfo+xml' 3175 This specification requests the registration of a new MIME type 3176 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3177 RFC 7303 [RFC7303]. 3179 MIME media type name: application 3181 MIME subtype name: EmergencyCallData.ProviderInfo+xml 3183 Mandatory parameters: none 3185 Optional parameters: charset (indicates the character encoding of 3186 the contents) 3188 Encoding considerations: Uses XML, which can contain 8-bit 3189 characters, depending on the character encoding. See Section 3.2 3190 of RFC 7303 [RFC7303]. 3192 Security considerations: This content type is designed to carry 3193 the data provider information, which is a sub-category of 3194 additional data about an emergency call. Since this data may 3195 contain personal information, appropriate precautions might be 3196 needed to limit unauthorized access, inappropriate disclosure, and 3197 eavesdropping of personal information. Please refer to Section 8 3198 and Section 9 for more information. 3200 Interoperability considerations: None 3201 Published specification: [TBD: This specification] 3203 Applications which use this media type: Emergency Services 3205 Additional information: 3207 Magic Number: None 3209 File Extension: .xml 3211 Macintosh file type code: 'TEXT' 3213 Person and email address for further information: Hannes 3214 Tschofenig, Hannes.Tschofenig@gmx.net 3216 Intended usage: LIMITED USE 3218 Author: This specification is a work item of the IETF ECRIT 3219 working group, with mailing list address . 3221 Change controller: The IESG 3223 10.4.2. MIME Content-type Registration for 'application/ 3224 EmergencyCallData.ServiceInfo+xml' 3226 This specification requests the registration of a new MIME type 3227 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3228 RFC 7303 [RFC7303]. 3230 MIME media type name: application 3232 MIME subtype name: EmergencyCallData.ServiceInfo+xml 3234 Mandatory parameters: none 3236 Optional parameters: charset (indicates the character encoding of 3237 the contents) 3239 Encoding considerations: Uses XML, which can contain 8-bit 3240 characters, depending on the character encoding. See Section 3.2 3241 of RFC 7303 [RFC7303]. 3243 Security considerations: This content type is designed to carry 3244 the service information, which is a sub-category of additional 3245 data about an emergency call. Since this data may contain 3246 personal information, appropriate precautions may be needed to 3247 limit unauthorized access, inappropriate disclosure, and 3248 eavesdropping of personal information. Please refer to Section 8 3249 and Section 9 for more information. 3251 Interoperability considerations: None 3253 Published specification: [TBD: This specification] 3255 Applications which use this media type: Emergency Services 3257 Additional information: 3259 Magic Number: None 3261 File Extension: .xml 3263 Macintosh file type code: 'TEXT' 3265 Person and email address for further information: Hannes 3266 Tschofenig, Hannes.Tschofenig@gmx.net 3268 Intended usage: LIMITED USE 3270 Author: This specification is a work item of the IETF ECRIT 3271 working group, with mailing list address . 3273 Change controller: The IESG 3275 10.4.3. MIME Content-type Registration for 'application/ 3276 EmergencyCallData.DeviceInfo+xml' 3278 This specification requests the registration of a new MIME type 3279 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3280 RFC 7303 [RFC7303]. 3282 MIME media type name: application 3284 MIME subtype name: EmergencyCallData.DeviceInfo+xml 3286 Mandatory parameters: none 3288 Optional parameters: charset (indicates the character encoding of 3289 the contents) 3291 Encoding considerations: Uses XML, which can contain 8-bit 3292 characters, depending on the character encoding. See Section 3.2 3293 of RFC 7303 [RFC7303]. 3295 Security considerations: This content type is designed to carry 3296 device information, which is a sub-category of additional data 3297 about an emergency call. Since this data contains personal 3298 information, appropriate precautions need to be taken to limit 3299 unauthorized access, inappropriate disclosure to third parties, 3300 and eavesdropping of this information. Please refer to Section 8 3301 and Section 9 for more information. 3303 Interoperability considerations: None 3305 Published specification: [TBD: This specification] 3307 Applications which use this media type: Emergency Services 3309 Additional information: 3311 Magic Number: None 3313 File Extension: .xml 3315 Macintosh file type code: 'TEXT' 3317 Person and email address for further information: Hannes 3318 Tschofenig, Hannes.Tschofenig@gmx.net 3320 Intended usage: LIMITED USE 3322 Author: This specification is a work item of the IETF ECRIT 3323 working group, with mailing list address . 3325 Change controller: The IESG 3327 10.4.4. MIME Content-type Registration for 'application/ 3328 EmergencyCallData.SubscriberInfo+xml' 3330 This specification requests the registration of a new MIME type 3331 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3332 RFC 7303 [RFC7303]. 3334 MIME media type name: application 3336 MIME subtype name: EmergencyCallData.SubscriberInfo+xml 3338 Mandatory parameters: none 3340 Optional parameters: charset (indicates the character encoding of 3341 the contents) 3342 Encoding considerations: Uses XML, which can contain 8-bit 3343 characters, depending on the character encoding. See Section 3.2 3344 of RFC 7303 [RFC7303]. 3346 Security considerations: This content type is designed to carry 3347 owner/subscriber information, which is a sub-category of 3348 additional data about an emergency call. Since this data contains 3349 personal information, appropriate precautions need to be taken to 3350 limit unauthorized access, inappropriate disclosure to third 3351 parties, and eavesdropping of this information. Please refer to 3352 Section 8 and Section 9 for more information. 3354 Interoperability considerations: None 3356 Published specification: [TBD: This specification] 3358 Applications which use this media type: Emergency Services 3360 Additional information: 3362 Magic Number: None 3364 File Extension: .xml 3366 Macintosh file type code: 'TEXT' 3368 Person and email address for further information: Hannes 3369 Tschofenig, Hannes.Tschofenig@gmx.net 3371 Intended usage: LIMITED USE 3373 Author: This specification is a work item of the IETF ECRIT 3374 working group, with mailing list address . 3376 Change controller: The IESG 3378 10.4.5. MIME Content-type Registration for 'application/ 3379 EmergencyCallData.Comment+xml' 3381 This specification requests the registration of a new MIME type 3382 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3383 RFC 7303 [RFC7303]. 3385 MIME media type name: application 3387 MIME subtype name: EmergencyCallData.Comment+xml 3389 Mandatory parameters: none 3390 Optional parameters: charset (indicates the character encoding of 3391 the contents) 3393 Encoding considerations: Uses XML, which can contain 8-bit 3394 characters, depending on the character encoding. See Section 3.2 3395 of RFC 7303 [RFC7303]. 3397 Security considerations: This content type is designed to carry a 3398 comment, which is a sub-category of additional data about an 3399 emergency call. This data may contain personal information. 3400 Appropriate precautions may be needed to limit unauthorized 3401 access, inappropriate disclosure to third parties, and 3402 eavesdropping of this information. Please refer to Section 8 and 3403 Section 9 for more information. 3405 Interoperability considerations: None 3407 Published specification: [TBD: This specification] 3409 Applications which use this media type: Emergency Services 3411 Additional information: 3413 Magic Number: None 3415 File Extension: .xml 3417 Macintosh file type code: 'TEXT' 3419 Person and email address for further information: Hannes 3420 Tschofenig, Hannes.Tschofenig@gmx.net 3422 Intended usage: LIMITED USE 3424 Author: This specification is a work item of the IETF ECRIT 3425 working group, with mailing list address . 3427 Change controller: The IESG 3429 10.5. URN Sub-Namespace Registration 3431 10.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 3433 This section registers a new XML namespace, as per the guidelines in 3434 RFC 3688 [RFC3688]. 3436 URI: urn:ietf:params:xml:ns:EmergencyCallData 3437 Registrant Contact: IETF, ECRIT working group, , as 3438 delegated by the IESG . 3440 XML: 3442 BEGIN 3443 3444 3446 3447 3448 3450 Namespace for Additional Emergency Call Data 3451 3452 3453

Namespace for Additional Data related to an Emergency Call 3454

3455

See [TBD: This document].

3456 3457 3458 END 3460 10.5.2. Registration for 3461 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3463 This section registers a new XML namespace, as per the guidelines in 3464 RFC 3688 [RFC3688]. 3466 URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3468 Registrant Contact: IETF, ECRIT working group, , as 3469 delegated by the IESG . 3471 XML: 3473 BEGIN 3474 3475 3477 3478 3479 3481 Namespace for Additional Emergency Call Data: 3482 Data Provider Information 3483 3484 3485

Namespace for Additional Data related to an Emergency Call 3486

3487

Data Provider Information

3488

See [TBD: This document].

3489 3490 3491 END 3493 10.5.3. Registration for 3494 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3496 This section registers a new XML namespace, as per the guidelines in 3497 RFC 3688 [RFC3688]. 3499 URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3501 Registrant Contact: IETF, ECRIT working group, , as 3502 delegated by the IESG . 3504 XML: 3506 BEGIN 3507 3508 3510 3511 3512 3514 Namespace for Additional Emergency Call Data: 3515 Service Information 3516 3517 3518

Namespace for Additional Data related to an Emergency Call 3519

3520

Service Information

3521

See [TBD: This document].

3522 3523 3524 END 3526 10.5.4. Registration for 3527 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3529 This section registers a new XML namespace, as per the guidelines in 3530 RFC 3688 [RFC3688]. 3532 URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3534 Registrant Contact: IETF, ECRIT working group, , as 3535 delegated by the IESG . 3537 XML: 3539 BEGIN 3540 3541 3543 3544 3545 3547 Namespace for Additional Emergency Call Data: 3548 Device Information 3549 3550 3551

Namespace for Additional Data related to an Emergency Call 3552

3553

Device Information

3554

See [TBD: This document].

3555 3556 3557 END 3559 10.5.5. Registration for 3560 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3562 This section registers a new XML namespace, as per the guidelines in 3563 RFC 3688 [RFC3688]. 3565 URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3567 Registrant Contact: IETF, ECRIT working group, , as 3568 delegated by the IESG . 3570 XML: 3572 BEGIN 3573 3574 3576 3577 3578 3580 Namespace for Additional Emergency Call Data: 3581 Owner/Subscriber Information 3582 3583 3584

Namespace for Additional Data related to an Emergency Call 3585

3586

Owner/Subscriber Information

3587

See [TBD: This document].

3588 3589 3590 END 3592 10.5.6. Registration for 3593 urn:ietf:params:xml:ns:EmergencyCallData:Comment 3595 This section registers a new XML namespace, as per the guidelines in 3596 RFC 3688 [RFC3688]. 3598 URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment 3600 Registrant Contact: IETF, ECRIT working group, , as 3601 delegated by the IESG . 3603 XML: 3605 BEGIN 3606 3607 3609 3610 3611 3613 Namespace for Additional Emergency Call Data:Comment 3614 3615 3616 3617

Namespace for Additional Data related to an Emergency Call 3618

3619

Comment

3620

See [TBD: This document].

3621 3622 3623 END 3625 10.6. Schema Registrations 3627 This specification registers five schemas, as per the guidelines in 3628 RFC 3688 [RFC3688]. 3630 URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo 3632 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3633 delegated by the IESG (iesg@ietf.org). 3635 XML: The XML schema can be found in Figure 19. 3637 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3639 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 3640 delegated by the IESG (iesg@ietf.org). 3642 XML: The XML schema can be found in Figure 20. 3644 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3646 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3647 delegated by the IESG (iesg@ietf.org). 3649 XML: The XML schema can be found in Figure 21. 3651 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3652 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3653 delegated by the IESG (iesg@ietf.org). 3655 XML: The XML schema can be found in Section 7.4. 3657 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3659 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3660 delegated by the IESG (iesg@ietf.org). 3662 XML: The XML schema can be found in Section 7.5. 3664 10.7. VCard Parameter Value Registration 3666 This document registers a new value in the vCARD Parameter Values 3667 registry as defined by [RFC6350] with the following template: 3669 Value: main 3671 Purpose: The main telephone number, typically of an enterprise, as 3672 opposed to a direct dial number of an individual employee 3674 Conformance: This value can be used with the "TYPE" parameter 3675 applied on the "TEL" property. 3677 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3678 00 3680 11. Acknowledgments 3682 This work was originally started in NENA and has benefitted from a 3683 large number of participants in NENA standardization efforts, 3684 originally in the Long Term Definition Working Group, the Data 3685 Technical Committee and most recently the Additional Data working 3686 group. The authors are grateful for the initial work and extended 3687 comments provided by many NENA participants, including Delaine 3688 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3689 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 3690 and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank 3691 Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback 3692 regarding the vCard/xCard use in this specification. 3694 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3695 Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris 3696 Santer, and Archie Cobbs for their review comments. Alissa Cooper 3697 and Guy Caron deserves special mention for their detailed and 3698 extensive review comments, which were very helpful and appreciated. 3700 12. References 3702 12.1. Normative References 3704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3705 Requirement Levels", BCP 14, RFC 2119, March 1997. 3707 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3708 Locators", RFC 2392, August 1998. 3710 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3711 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3712 and QSIG Objects", RFC 3204, December 2001. 3714 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3715 A., Peterson, J., Sparks, R., Handley, M., and E. 3716 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3717 June 2002. 3719 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3720 Extensions (MIME) Parameter", RFC 3459, January 2003. 3722 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3723 January 2004. 3725 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3726 3966, December 2004. 3728 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3729 Format", RFC 4119, December 2005. 3731 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3732 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3733 May 2008. 3735 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3736 October 2008. 3738 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3739 Initiation Protocol (SIP)", RFC 5621, September 2009. 3741 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3742 Languages", BCP 47, RFC 5646, September 2009. 3744 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3745 August 2011. 3747 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3748 6351, August 2011. 3750 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3751 Specifications and Registration Procedures", BCP 13, RFC 3752 6838, January 2013. 3754 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 3755 July 2014. 3757 12.2. Informational References 3759 [ECRIT-WG-wiki] 3760 IETF, "ECRIT WG Wiki"", July 2015, 3761 . 3764 [I-D.gellens-slim-negotiating-human-language] 3765 Gellens, R., "Negotiating Human Language in Real-Time 3766 Communications", draft-gellens-slim-negotiating-human- 3767 language-01 (work in progress), April 2015. 3769 [IANA-XML-Schemas] 3770 IANA, "IANA XML Schemas"", July 2015, 3771 . 3774 [LanguageTagRegistry] 3775 IANA, "Language Subtag Registry", Feb 2015, 3776 . 3779 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3780 Extensions to the Session Initiation Protocol (SIP) for 3781 Asserted Identity within Trusted Networks", RFC 3325, 3782 November 2002. 3784 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3785 "Indicating User Agent Capabilities in the Session 3786 Initiation Protocol (SIP)", RFC 3840, August 2004. 3788 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 3789 Emergency Context Resolution with Internet Technologies", 3790 RFC 5012, January 2008. 3792 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3793 Format for Presence Information Data Format Location 3794 Object (PIDF-LO)", RFC 5139, February 2008. 3796 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3797 Presence Information Data Format Location Object (PIDF-LO) 3798 Usage Clarification, Considerations, and Recommendations", 3799 RFC 5491, March 2009. 3801 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 3802 Framework", RFC 5582, September 2009. 3804 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3805 Thomson, "Dynamic Extensions to the Presence Information 3806 Data Format Location Object (PIDF-LO)", RFC 5962, 3807 September 2010. 3809 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3810 5985, September 2010. 3812 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3813 "Framework for Emergency Calling Using Internet 3814 Multimedia", RFC 6443, December 2011. 3816 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3817 R. George, "Specifying Civic Address Extensions in the 3818 Presence Information Data Format Location Object (PIDF- 3819 LO)", RFC 6848, January 2013. 3821 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3822 Communications Services in Support of Emergency Calling", 3823 BCP 181, RFC 6881, March 2013. 3825 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3826 Morris, J., Hansen, M., and R. Smith, "Privacy 3827 Considerations for Internet Protocols", RFC 6973, July 3828 2013. 3830 [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3831 Thomson, "Relative Location Representation", RFC 7035, 3832 October 2013. 3834 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3835 Patel, "Public Safety Answering Point (PSAP) Callback", 3836 RFC 7090, April 2014. 3838 12.3. URIs 3840 [1] http://www.nena.org/?page=cid2014 3842 [2] http://www.nena.org/?page=CompanyID 3844 Appendix A. XML Schema for vCard/xCard 3846 This section contains the vCard/xCard XML schema version of the Relax 3847 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3848 XML schemas defined in this document. The schema in RFC 6351 3849 [RFC6351] is the normative source and this section is informative 3850 only. 3852 3853 3857 3863 3864 3865 vCard Format Specification 3866 3867 3868 3869 3870 3871 3872 3873 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3888 3889 3890 3893 3894 3895 3896 3897 3899 3900 3901 3903 3904 3905 3906 3907 3909 3910 3911 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3955 3956 3957 3958 3962 3963 3964 Section 5: Parameters 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 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 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 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 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 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 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4887 4888 4889 4890 4891 4892 4893 4895 4896 4897 4898 4899 4900 4901 4903 4904 4905 4907 4909 4910 4911 4913 4914 4915 4916 4918 Appendix B. XML Validation 4920 This document defines a number of XML schemas and contains various 4921 examples. Extracting the XML and validating the examples against the 4922 schemas can be challenging, especially due to the formatting 4923 limitations introduced by IETF RFCs. For those readers who copy the 4924 XML schemas and examples directly from this document, please consider 4925 that errors might be introduced due to line breaks and extra 4926 whitespaces in the regular expressions contained in the vcard schema 4927 in Appendix A. To validate the PIDF-LO from Figure 18 it is also 4928 necessary to consult the referenced RFCs and copy the schemas 4929 necessary for successful validation. 4931 The XML schemas found in this document include a 'SchemaLocation' 4932 attribute. Depending on the location of the downloaded schema files 4933 you may need to adjust this schema location or configure your XML 4934 editor to point to the location. 4936 For convenience of readers, the schemas are available at http://ip- 4937 emergency.net/additional-data.zip and the XML examples are available 4938 at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki]. 4940 Note to RFC Editor: After IANA has published the schemas, the above 4941 link to the schemas should be replaced with [IANA-XML-Schemas]. 4943 Authors' Addresses 4944 Randall Gellens 4945 Qualcomm Technologies, Inc. 4946 5775 Morehouse Drive 4947 San Diego, CA 92121 4948 US 4950 Email: rg+ietf@qti.qualcomm.com 4952 Brian Rosen 4953 NeuStar 4954 470 Conrad Dr. 4955 Mars, PA 16046 4956 US 4958 Phone: +1 724 382 1051 4959 Email: br@brianrosen.net 4961 Hannes Tschofenig 4962 Hall in Tirol 6060 4963 Austria 4965 Email: Hannes.tschofenig@gmx.net 4966 URI: http://www.tschofenig.priv.at 4968 Roger Marshall 4969 TeleCommunication Systems, Inc. 4970 2401 Elliott Avenue 4971 Seattle, WA 98121 4972 US 4974 Phone: +1 206 792 2424 4975 Email: rmarshall@telecomsys.com 4976 URI: http://www.telecomsys.com 4978 James Winterbottom 4979 AU 4981 Email: a.james.winterbottom@gmail.com