idnits 2.17.00 (12 Aug 2021) /tmp/idnits29214/draft-ietf-ecrit-additional-data-30.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 3142 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 (June 30, 2015) is 2516 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 3812 -- Looks like a reference, but probably isn't: '2' on line 3814 == Missing Reference: 'This RFC' is mentioned on line 3142, 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-00 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 1, 2016 NeuStar 6 H. Tschofenig 8 R. Marshall 9 TeleCommunication Systems, Inc. 10 J. Winterbottom 12 June 30, 2015 14 Additional Data Related to an Emergency Call 15 draft-ietf-ecrit-additional-data-30.txt 17 Abstract 19 When an emergency call is sent to a Public Safety Answering Point 20 (PSAP), the device that sends it, as well as any application service 21 provider in the path of the call, or access network provider through 22 which the call originated has information about the call, the caller 23 or the location which might be helpful for the PSAP to have in 24 handling the emergency. This document describes data structures and 25 a mechanism to convey such data to the PSAP. The intent is that 26 every emergency call carry the information described here using the 27 mechanisms described here. 29 The mechanism uses a Uniform Resource Identifier (URI), which may 30 point to either an external resource or an object in the body of the 31 SIP message. The mechanism thus allows the data to be passed by 32 reference (when the URI points to an external resource) or by value 33 (when it points into the body of the message). This follows the 34 tradition of prior emergency services standardization work where data 35 can be conveyed by value within the call signaling (i.e., in body of 36 the SIP message) and also by reference. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 1, 2016. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Data Provider Information . . . . . . . . . . . . . . . . 8 77 4.1.1. Data Provider String . . . . . . . . . . . . . . . . 9 78 4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9 79 4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 10 80 4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 11 81 4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 11 82 4.1.6. Data Provider Languages(s) Supported . . . . . . . . 12 83 4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 13 84 4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 13 85 4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 14 86 4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 14 87 4.2. Service Information . . . . . . . . . . . . . . . . . . . 16 88 4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17 89 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18 90 4.2.3. Service Mobility Environment . . . . . . . . . . . . 19 91 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 20 92 4.3. Device Information . . . . . . . . . . . . . . . . . . . 21 93 4.3.1. Device Classification . . . . . . . . . . . . . . . . 21 94 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 22 95 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 23 96 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 23 97 4.3.5. Device/Service-Specific Additional Data Structure . . 24 98 4.3.6. Device/Service Specific Additional Data Structure 99 Type . . . . . . . . . . . . . . . . . . . . . . . . 24 100 4.3.7. Issues with getting new types of data into use . . . 25 101 4.3.8. Choosing between defining a new type of block or new 102 type of device/service specific additional data . . . 26 103 4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 27 104 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 27 105 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 27 106 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 28 107 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 28 108 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 31 110 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 31 111 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 31 112 5.1. Transmitting Blocks using the Call-Info Header . . . . . 33 113 5.2. Transmitting Blocks by Reference using the 114 Element . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 5.3. Transmitting Blocks by Value using the 116 Element . . . . . . . . . . . . . . . . . . . . . . . . . 35 117 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 37 118 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 51 120 7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 51 121 7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 53 122 7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 54 123 7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 56 124 7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 57 125 7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 58 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 60 127 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 62 128 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 129 10.1. Registry creation . . . . . . . . . . . . . . . . . . . 65 130 10.1.1. Provider ID Series Registry . . . . . . . . . . . . 65 131 10.1.2. Service Environment Registry . . . . . . . . . . . . 65 132 10.1.3. Service Type Registry . . . . . . . . . . . . . . . 66 133 10.1.4. Service Mobility Registry . . . . . . . . . . . . . 66 134 10.1.5. Service Provider Type Registry . . . . . . . . . . . 67 135 10.1.6. Device Classification Registry . . . . . . . . . . . 67 136 10.1.7. Device ID Type Type Registry . . . . . . . . . . . . 67 137 10.1.8. Device/Service Data Type Registry . . . . . . . . . 68 138 10.1.9. Emergency Call Data Types Registry . . . . . . . . . 68 139 10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 69 140 10.3. URN Sub-Namespace Registration for 141 Registry Entry . . . . . . . . . . . . . . . . . . . . . 70 142 10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 70 143 10.4.1. MIME Content-type Registration for 144 'application/EmergencyCallData.ProviderInfo+xml' . . 70 145 10.4.2. MIME Content-type Registration for 146 'application/EmergencyCallData.ServiceInfo+xml' . . 71 147 10.4.3. MIME Content-type Registration for 148 'application/EmergencyCallData.DeviceInfo+xml' . . . 72 149 10.4.4. MIME Content-type Registration for 150 'application/EmergencyCallData.SubscriberInfo+xml' . 73 151 10.4.5. MIME Content-type Registration for 152 'application/EmergencyCallData.Comment+xml' . . . . 74 153 10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 75 154 10.5.1. Registration for 155 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 75 156 10.5.2. Registration for 157 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf 158 o . . . . . . . . . . . . . . . . . . . . . . . . . 76 159 10.5.3. Registration for 160 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 77 161 10.5.4. Registration for 162 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 78 163 10.5.5. Registration for 164 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI 165 nfo . . . . . . . . . . . . . . . . . . . . . . . . 79 166 10.5.6. Registration for 167 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 80 168 10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 81 169 10.7. VCard Parameter Value Registration . . . . . . . . . . . 82 170 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 171 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 172 12.1. Normative References . . . . . . . . . . . . . . . . . . 83 173 12.2. Informational References . . . . . . . . . . . . . . . . 84 174 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 85 175 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 85 176 Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 108 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 179 1. Introduction 181 When an IP-based emergency call is initiated, a rich set of data from 182 multiple data sources is conveyed to the Public Safety Answering 183 Point (PSAP). This data includes information about the calling party 184 identity, the multimedia capabilities of the device, the request for 185 emergency services, location information, and meta-data about the 186 sources of the data. In addition, the device, the access network 187 provider, and any service provider in the call path has even more 188 information that is useful for a PSAP when handling an emergency. 189 This document extends the basic set of data communicated with an IP- 190 based emergency call, as described in [RFC6443] and [RFC6881], in 191 order to carry additional data which is useful to an entity or call 192 taker handling the call. This data is "additional" to the basic 193 information found in the emergency call signaling used. The intent 194 is that every emergency call carry the information described here 195 using the mechanisms described here. 197 In general, there are three categories of this additional data that 198 may be transmitted with an emergency call: 200 Data Associated with a Location: Primary location data is conveyed 201 in the Presence Information Data Format Location Object (PIDF-LO) 202 data structure as defined in RFC 4119 [RFC4119] and extended by 203 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 204 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 205 geodetic location information), and [RFC7035] (for relative 206 location). This primary location data identifies the location or 207 estimated location of the caller. However, there may exist 208 additional, secondary data which is specific to the location, such 209 as floor plans, tenant and building owner contact data, heating, 210 ventilation and air conditioning (HVAC) status, etc. Such 211 secondary location data is not included in the location data 212 structure but can be transmitted using the mechanisms defined in 213 this document. Although this document does not define any 214 structures for such data, future documents may do so following the 215 procedures defined here. 217 Data Associated with a Call: While some information is carried in 218 the call setup procedure itself (as part of the SIP headers as 219 well as in the body of the SIP message), there is additional data 220 known by the device making the call and/or a service provider 221 along the path of the call. This information may include the 222 service provider contact information, subscriber identity and 223 contact information, the type of service the service provider and 224 the access network provider offer, what type of device is being 225 used, etc. Some data is broadly applicable, while other data is 226 dependent on the type of device or service. For example, a 227 medical monitoring device may have sensor data. The data 228 structures defined in this document (Data Provider Information, 229 Device Information, and Owner/Subscriber Information) all fall 230 into the category of "Data Associated with a Call". 232 Data Associated with a Caller: This is personal data about a caller, 233 such as medical information and emergency contact data. Although 234 this document does not define any structures within this category, 235 future documents may do so following the procedures defined here. 237 While this document defines data structures only within the category 238 of Data Associated with a Call, by establishing the overall framework 239 of Additional Data, along with general mechanisms for transport of 240 such data, extension points and procedures for future extensions, it 241 minimizes the work needed to carry data in the other categories. 242 Other specifications may make use of the facilities provided here. 244 For interoperability, there needs to be a common way for the 245 information conveyed to a PSAP to be encoded and identified. 246 Identification allows emergency services authorities to know during 247 call processing which types of data are present and to determine if 248 they wish to access it. A common encoding allows the data to be 249 successfully accessed. 251 This document defines an extensible set of data structures, and 252 mechanisms to transmit this data either by value or by reference, 253 either in the Session Initiation Protocol (SIP) call signaling or in 254 the Presence Information Data Format Location Object (PIDF-LO). The 255 data structures are usable by other communication systems and 256 transports as well. The data structures are defined in Section 4, 257 and the transport mechanisms (using SIP and HTTPS) are defined in 258 Section 5. 260 Each data structure described in this document is encoded as a 261 "block" of information. Each block is an XML structure with an 262 associated Multipurpose Internet Mail Extensions (MIME) type for 263 identification within transport such as SIP and HTTPS. The set of 264 blocks is extensible. Registries are defined to identify the block 265 types that may be used and to allow blocks to be included in 266 emergency call signaling. 268 Much of the information supplied by service providers and devices is 269 private and confidential; service providers and devices generally go 270 to lengths to protect this information; disclosing it in the context 271 of an emergency call is a trade-off to protect the greater interest 272 of the customer in an emergency. 274 2. Terminology 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 278 document are to be interpreted as described in RFC 2119 [RFC2119]. 280 This document also uses terminology from [RFC5012]. We use the term 281 service provider to refer to an Application Service Provider (ASP). 282 A Voice Service Provider (VSP) is a special type of ASP. With the 283 term "Access Network Provider" we refer to the Internet Access 284 Provider (IAP) and the Internet Service Provider (ISP) without 285 further distinguishing these two entities, since the difference 286 between the two is not relevant for this document. Note that the 287 roles of ASP and access network provider may be provided by a single 288 company. An Emergency Services Provider is an entity directly 289 involved in providing emergency services. This includes PSAPs, 290 dispatch, police, fire, emergency medical, other responders, and 291 other similar agencies. 293 Within each data block definition (see Section 4), the values for the 294 "Use:" label are specified as one of the following: 296 'Required': means it MUST be present in the data structure. 298 'Conditional': means it MUST be present if the specified 299 condition(s) is met. It MAY be present if the condition(s) is not 300 met. 302 'Optional': means it MAY be present. 304 vCard [RFC6350] is a data format for representing and exchanging a 305 variety of information about individuals and other entities. For 306 applications that use XML, the format defined in vCard is not 307 immediately applicable. For this reason, an XML-based encoding of 308 the information elements defined in the vCard specification has been 309 defined and the name of that specification is xCard [RFC6351]. Since 310 the term vCard is more familiar to most readers, we use the terms 311 xCard and vCard interchangeably. 313 3. Document Scope 315 The scope of this document is explicitly limited to emergency calls. 316 The data structures defined here are not appropriate to be conveyed 317 with non-emergency calls because they carry sensitive and private 318 data. However, in certain private-use situations where the endpoints 319 have a preexisting relationship and privacy concerns do not apply 320 because of the relationship, the mechanisms and data structures 321 defined here MAY be used. 323 4. Data Structures 325 This section defines the following five data structures, each as a 326 data block. For each block we define the MIME type, and the XML 327 encoding. The five data structures are: 329 'Data Provider': This block supplies name and contact information 330 for the entity that created the data. Section 4.1 provides the 331 details. 333 'Service Information': This block supplies information about the 334 service. The description can be found in Section 4.2. 336 'Device Information': This block supplies information about the 337 device placing the call. Device information can be found in 338 Section 4.3. 340 'Owner/Subscriber': This block supplies information about the owner 341 of the device or about the subscriber. Details can be found in 342 Section 4.4. 344 'Comment': This block provides a way to supply free form human 345 readable text to the PSAP or emergency responders. This simple 346 structure is defined in Section 4.5. 348 Each block contains a mandatory element. The 349 purpose of the element is to associate all 350 blocks added by the same data provider as a unit. The 351 element associates the data provider block to 352 each of the other blocks added as a unit. Consequently, when a data 353 provider adds additional data to an emergency call (such as device 354 information) it MUST add information about itself (via the data 355 provider block) and the blocks added contain the same value in the 356 element. All blocks added by a single entity 357 at the same time MUST have the same value. 358 The value of the element has the same syntax 359 and properties (specifically, world-uniqueness) as the value of the 360 "Message-ID" message body header field specified in RFC 5322 361 [RFC5322] except that the element is not 362 enclosed in brackets (the "<" and ">" symbols are omitted). In other 363 words, the value of a element is 364 syntactically a msg-id as specified in RFC 5322 [RFC5322]. 366 Note that the xCard format is re-used in some of the data structures 367 to provide contact information. In an xCard there is no way to 368 specify a "main" telephone number. These numbers are useful to 369 emergency responders who are called to a large enterprise. This 370 document adds a new property value to the "tel" property of the TYPE 371 parameter called "main". It can be used in any xCard in additional 372 data. 374 4.1. Data Provider Information 376 This block is intended to be supplied by any service provider in the 377 path of the call, or the access network provider, or the device. It 378 includes identification and contact information. This block SHOULD 379 be supplied by every service provider in the call path, and by the 380 access network provider. Devices MAY use this block to provide 381 identifying information. The MIME subtype is "application/ 382 EmergencyCallData.ProviderInfo+xml". An access network provider 383 SHOULD provide this block either by value or by reference in the 384 element of a PIDF-LO 386 4.1.1. Data Provider String 388 Data Element: Data Provider String 390 Use: Required 392 XML Element: 394 Description: This is a plain text string suitable for displaying the 395 name of the service provider that supplied the data structure. If 396 the device creates the structure, it SHOULD use the value of the 397 contact header in the SIP INVITE. 399 Reason for Need: Inform the call taker of the identity of the entity 400 providing the data. 402 How Used by Call Taker: Allows the call taker to interpret the data 403 in this structure. The source of the information often influences 404 how the information is used, believed or verified. 406 4.1.2. Data Provider ID 408 Data Element: Data Provider ID 410 Use: Conditional. Optional for blocks supplied by the originating 411 device, mandatory otherwise. This data MUST be provided by all 412 entities other than the originating device in order to uniquely 413 identify the service provider or access provider. 415 XML Element: 417 Description: A jurisdiction-specific code for, or the fully- 418 qualified domain name of, the access network provider or service 419 provider shown in the element that created the 420 structure. NOTE: The value SHOULD be assigned by an organization 421 appropriate for the jurisdiction. In the U.S., if the provider is 422 registered with NENA, the provider's NENA Company ID MUST appear 423 here. Additional information can be found at NENA Company 424 Identifier Program [1] or NENA Company ID [2]. The NENA Company 425 ID MUST be in the form of a URI in the following format: 426 urn:nena:companyid:. If the organization does 427 not have an identifier registered with a jurisdiction-specific 428 emergency services registrar (such as NENA), then the value MAY be 429 the fully-qualified domain name of the service provider or access 430 provider. The device MAY use its IP address or fully-qualified 431 domain name (and set the "Data Provider ID Series" element to 432 "domain"). 434 Reason for Need: Inform the call taker of the identity of the entity 435 providing the data. 437 How Used by Call Taker: Where jurisdictions have lists of providers 438 the Data Provider ID provides useful information about the data 439 source. The Data Provider ID uniquely identifies the source of 440 the data, which might be needed especially during unusual 441 circumstances and for routine logging. 443 4.1.3. Data Provider ID Series 445 Data Element: Data Provider ID Series 447 Use: Conditional. Optional for blocks supplied by the originating 448 device, mandatory otherwise. 450 XML Element: 452 Description: Identifies the issuer of the . The 453 Provider ID Series Registry created in Section 10.1.1 initially 454 contains the entries shown in Figure 1. 456 Reason for Need: Identifies how to interpret the Data Provider ID. 457 The combination of ProviderIDSeries and ProviderID MUST be 458 globally unique. 460 How Used by Call Taker: Determines which provider ID registry to 461 consult for more information 463 +-----------+--------------------------+----------------------+ 464 | Name | Source | URL | 465 +-----------+--------------------------+----------------------+ 466 | NENA | National Emergency | http://www.nena.org | 467 | | Number Association | | 468 | EENA | European Emergency | http://www.eena.org | 469 | | Number Association | | 470 | domain | (The ID is a fully- | (not applicable) | 471 | | qualified domain name) | | 472 +-----------+--------------------------+----------------------+ 474 Figure 1: Provider ID Series Registry 476 4.1.4. Type of Data Provider 478 Data Element: Type of Data Provider 480 Use: Required. 482 XML Element: 484 Description: Identifies the type of data provider supplying the 485 data. The registry containing all valid values is created in 486 Section 10.1.5 and the initial set of values is shown in Figure 2. 488 Reason for Need: Identifies the category of data provider. 490 How Used by Call Taker: This information may be helpful when 491 deciding whom to contact when further information is needed. 493 +------------------------------+------------------------------------+ 494 | Token | Description | 495 +------------------------------+------------------------------------+ 496 |Client | Originating client/device | 497 |Access Network Provider | Access network service provider | 498 |Telecom Provider | Telecom service provider (including| 499 | | over-the-top VoIP services) | 500 |Telematics Provider | A sensor-based service provider, | 501 | | especially vehicle-based | 502 |Language Translation Provider | A spoken language translation | 503 | | service | 504 |Emergency Service Provider | An emergency service provider | 505 | | conveying information to another| 506 | | emergency service provider. | 507 |Emergency Modality Translation| An emergency-call-specific | 508 | | modality translation service | 509 | | e.g., for sign language | 510 |Relay Provider | A interpretation service, e.g., | 511 | | video relay for sign language | 512 | | interpreting | 513 |Other | Any other type of service provider | 514 +------------------------------+------------------------------------+ 516 Figure 2: Type of Data Provider Registry 518 4.1.5. Data Provider Contact URI 520 Data Element: Data Provider Contact URI 522 Use: Required 523 XML Element: 525 Description: When provided by a service provider or an access 526 network provider, this information MUST be a URI to a 24/7 support 527 organization tasked to provide PSAP support for this emergency 528 call. When provided by a device, this MUST be the contact 529 information of the user or owner of the device. (Ideally, this is 530 the contact information of the device user, but when the owner and 531 user are separate (e.g., the device owner is an organization), 532 this MAY be the contact information of the owner.) The Data 533 Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format 534 fully specified with country code. If a TEL URI is not available, 535 it MAY be a generic SIP URI. Note that this contact information 536 is not used by PSAPs for callbacks (a call from a PSAP directly 537 related to a recently terminated emergency call, placed by the 538 PSAP using a SIP Priority header field set to "psap-callback", as 539 described in [RFC7090]). 541 Reason for Need: Additional data providers may need to be contacted 542 in error cases or other unusual circumstances. 544 How Used by Call Taker: To contact the supplier of the additional 545 data for assistance in handling the call. 547 4.1.6. Data Provider Languages(s) Supported 549 Data Element: Data Provider Language(s) supported 551 Use: Required. 553 XML Element: 555 Description: This field encodes the language used by the entity at 556 the Data Provider Contact URI. The content of this field consists 557 of a single token from the language tags registry, which can be 558 found at [LanguageTagRegistry], and is defined in [RFC5646]. 559 Multiple instances of this element may occur but the order is 560 significant and the preferred language should appear first. The 561 content MUST reflect the languages supported at the contact URI. 563 (Note that this field informs the PSAP of the language(s) used by 564 the data provider. If the PSAP needs to contact the data 565 provider, it can be helpful to know in advance the language(s) 566 used by the data provider. If the PSAP uses a communication 567 protocol to reach the data provider, that protocol may have 568 language facilities of its own (such as the 'language' media 569 feature tag, defined in RFC 3840 [RFC3840] and the more extensive 570 language negotiation mechanism proposed with 572 [I-D.gellens-slim-negotiating-human-language]), and if so, those 573 are independent of this field.) 575 Reason for Need: This information indicates if the emergency service 576 authority can directly communicate with the service provider or if 577 an interpreter will be needed. 579 How Used by Call Taker: If the call taker cannot speak any language 580 supported by the service provider, a translation service will need 581 to be added to the conversation. Alternatively, other persons at 582 the PSAP, besides the call taker, might be consulted for help 583 (depending on the urgency and the type of interaction). 585 4.1.7. xCard of Data Provider 587 Data Element: xCard of Data Provider 589 Use: Optional 591 XML Element: 593 Description: Per [RFC6351] the xCard structure is represented within 594 a element. Although multiple elements may be 595 contained in a structure only one element SHOULD be 596 provided. If more than one appears, the first SHOULD be used. 597 There are many fields in the xCard and the creator of the data 598 structure is encouraged to provide all available information. N, 599 ORG, ADR, TEL, EMAIL are suggested at a minimum. N SHOULD contain 600 the name of the support group or device owner as appropriate. If 601 more than one TEL property is provided, a parameter from the vCard 602 Property Value registry MUST be specified for each TEL. For 603 encoding of the vCard this specification uses the XML-based 604 encoding specified in [RFC6351], referred to in this document as 605 "xCard". 607 Reason for Need: Information needed to determine additional contact 608 information. 610 How Used by Call Taker: Assists the call taker by providing 611 additional contact information aside from what may be included in 612 the SIP INVITE or the PIDF-LO. 614 4.1.8. Subcontractor Principal 616 When the entity providing the data is a subcontractor, the Data 617 Provider Type is set to that of the primary service provider and this 618 entry is supplied to provide information regarding the subcontracting 619 entity. 621 Data Element: Subcontractor Principal 623 Use: Conditional. This data is required if the entity providing the 624 data is a subcontractor. 626 XML Element: 628 Description: Some providers outsource their obligations to handle 629 aspects of emergency services to specialized providers. If the 630 data provider is a subcontractor to another provider this element 631 contains the DataProviderString of the service provider to 632 indicate which provider the subcontractor is working for. 634 Reason for Need: Identify the entity the subcontractor works for. 636 How Used by Call Taker: Allows the call taker to understand what the 637 relationship between data providers and the service providers in 638 the path of the call are. 640 4.1.9. Subcontractor Priority 642 Data Element: Subcontractor Priority 644 Use: Conditional. This data is required if the entity providing the 645 data is a subcontractor. 647 XML Element: 649 Description: If the subcontractor is supposed to be contacted first 650 then this element MUST have the value "sub". If the provider the 651 subcontractor is working for is supposed to be contacted first 652 then this element MUST have the value "main". 654 Reason for Need: Inform the call taker whom to contact first, if 655 support is needed. 657 How Used by Call Taker: To decide which entity to contact first if 658 assistance is needed. 660 4.1.10. ProviderInfo Example 662 663 665 string0987654321@example.org 666 667 Example VoIP Provider 668 669 urn:nena:companyid:ID123 670 NENA 671 Telecom Provider 672 tel:+1-201-555-0123 673 en 674 676 677 Hannes Tschofenig 678 679 Hannes 680 Tschofenig 681 682 683 Dipl. Ing. 684 685 --0203 686 687 20090808T1430-0500 688 689 M 690 691 1 692 693 de 694 695 696 2 697 698 en 699 700 701 work 702 703 Example VoIP Provider 704 705 706 707 work 708 712 713 714 715 Linnoitustie 6 716 Espoo 717 Uusimaa 718 02600 719 Finland 720 721 722 723 724 work 725 voice 726 727 728 tel:+358 50 4871445 729 730 731 work 732 733 hannes.tschofenig@nsn.com 734 735 736 work 737 738 geo:60.210796,24.812924 739 740 741 home 742 743 744 http://www.tschofenig.priv.at/key.asc 745 746 747 Finland/Helsinki 748 749 home 750 751 http://www.tschofenig.priv.at 752 753 754 755 757 Figure 3: EmergencyCallData.ProviderInfo Example. 759 4.2. Service Information 761 This block describes the service that the service provider provides 762 to the caller. It SHOULD be included by all SPs in the path of the 763 call. The mime subtype is "application/ 764 EmergencyCallData.ServiceInfo+xml". 766 4.2.1. Service Environment 768 Data Element: Service Environment 770 Use: Conditional: Required unless the 'ServiceType' value is 771 'wireless'. 773 XML Element: 775 Description: This element indicates whether a call is from a 776 business or residence. Currently, the only valid entries are 777 'Business', 'Residence', and 'unknown', as shown in Figure 4. New 778 values can be defined via the registry created in Section 10.1.2. 780 Reason for Need: To provide context and a hint when determining 781 equipment and manpower requirements. 783 How Used by Call Taker: Information may be used to provide context 784 and a hint to assist in determining equipment and manpower 785 requirements for emergency responders. Because there are 786 situations where the service provider does not know (such as 787 anonymous pre-paid service), and because the type of service does 788 not neccessarily reflect the nature of the premises (for example, 789 a business line installed in a residence, or wireless service), 790 and the registry is not all-encompassing, this is at best advisory 791 information, but since it mimics a similar capability in some 792 current emergency calling systems (e.g., a field in the Automatic 793 Location Information (ALI) information used with legacy North 794 American wireline systems), it is known to be valuable. The 795 service provider uses its best information (such as a rate plan, 796 facilities used to deliver service or service description) to 797 determine the information and is not responsible for determining 798 the actual characteristics of the location from which the call 799 originated. Because the usefulness is unknown (and less clear) 800 for wireless, this element is OPTIONAL for wireless and REQUIRED 801 otherwise. 803 +-----------+--------------------------+ 804 | Token | Description | 805 +-----------+--------------------------+ 806 | Business | Business service | 807 | Residence | Residential service | 808 | unknown | Type of service unknown | 809 | | (e.g., anonymous pre- | 810 | | paid service) | 811 +-----------+--------------------------+ 813 Figure 4: Service Environment Registry 815 4.2.2. Service Type 817 Data Element: Service Delivered by Provider to End User 819 Use: Required 821 XML Element: 823 Description: This defines the type of service over which the call is 824 placed (similar to the Class of Service delivered with legacy 825 emergency calls in some some regions). The implied mobility of 826 this service cannot be relied upon. A registry is created in 827 Section 10.1.3. The initial set of values is shown in Figure 5. 828 More than one value MAY be returned. For example, a VoIP inmate 829 telephone service is a reasonable combination. 831 Reason for Need: Knowing the type of service may assist the PSAP in 832 handling of the call. 834 How Used by Call Taker: Call takers often use this information to 835 determine what kinds of questions to ask callers, and how much to 836 rely on supportive information. An emergency call from a prison 837 is treated differently than a call from a sensor device. As the 838 information is not always available, and the registry is not all- 839 encompassing, this is at best advisory information, but since it 840 mimics a similar capability in some legacy emergency calling 841 systems, it is known to be valuable. 843 +--------------+----------------------------------------+ 844 | Name | Description | 845 +--------------+----------------------------------------+ 846 | wireless | Wireless Telephone Service: Includes | 847 | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but | 848 | | not satellite) | 849 | coin | Fixed public pay/coin telephones: Any | 850 | | coin or credit card operated device | 851 | one-way | One way outbound service | 852 | prison | Inmate call/service | 853 | temp | Soft dial tone/quick service/warm | 854 | | disconnect/suspended | 855 | MLTS-hosted | Hosted multi-line telephone system | 856 | | such as Centrex | 857 | MLTS-local | Local multi-line telephone system, | 858 | | includes all PBX, key systems, | 859 | | Shared Tenant Service | 860 | sensor- | These are devices that generate DATA | 861 | unattended | ONLY. This is a one-way information | 862 | | transmit without interactive media | 863 | sensor- | Devices that are supported by a | 864 | attended | monitoring service provider or that | 865 | | are capable of supporting interactive| 866 | | media | 867 | POTS | Wireline: Plain Old Telephone Service | 868 | VOIP | An over-the-top service that provides | 869 | | communication over arbitrary Internet| 870 | | access (fixed, nomadic, mobile) | 871 | remote | Off-premise extension | 872 | relay | A service where a human third-party | 873 | | agent provides additional assistance | 874 | | This includes sign language relay/ | 875 | | interpretation, telematics services | 876 | | that provide a human on the call, | 877 | | and similar services. | 878 +--------------+----------------------------------------+ 880 Figure 5: Service Delivered by Provider to End User Registry 882 4.2.3. Service Mobility Environment 884 Data Element: Service Mobility Environment 886 Use: Required 888 XML Element: 889 Description: This provides the service provider's view of the 890 mobility of the caller's device. As the service provider might 891 not know the characteristics of the actual device or access 892 network used, the value should be treated as advisory and not be 893 relied upon. A registry is created in Section 10.1.4 with the 894 initial valid entries shown in Figure 6. 896 Reason for Need: Knowing the service provider's belief of mobility 897 may assist the PSAP with the handling of the call. 899 How Used by Call Taker: To determine whether to assume the location 900 of the caller might change. 902 +-----------+----------------------------+ 903 | Token | Description | 904 +-----------+----------------------------+ 905 | Mobile | The device is able to move | 906 | | at any time | 907 | Fixed | The device is not expected | 908 | | to move unless the | 909 | | service is relocated | 910 | Nomadic | The device is not expected | 911 | | to change its point of | 912 | | attachment while on a | 913 | | call | 914 | Unknown | No information is known | 915 | | about the service | 916 | | mobility environment for | 917 | | the device | 918 +-----------+----------------------------+ 920 Figure 6: Service Environment Registry 922 4.2.4. EmergencyCallData.ServiceInfo Example 924 925 927 2468.IBOC.MLTS.1359@example.org 928 929 Business 930 MLTS-hosted 931 Fixed 932 934 Figure 7: EmergencyCallData.ServiceInfo Example. 936 4.3. Device Information 938 This block provides information about the device used to place the 939 call. It should be provided by any service provider that knows what 940 device is being used, and by the device itself. The mime subtype is 941 "application/EmergencyCallData.DeviceInfo+xml". 943 4.3.1. Device Classification 945 Data Element: Device Classification 947 Use: Optional 949 XML Element: 951 Description: This data element defines the kind of device making the 952 emergency call. If the device provides the data structure, the 953 device information SHOULD be provided. If the service provider 954 provides the structure and it knows what the device is, the 955 service provider SHOULD provide the device information. Often the 956 carrier does not know what the device is. It is possible to 957 receive two Additional Data Associated with a Call data 958 structures, one created by the device and one created by the 959 service provider. This information describes the device, not how 960 it is being used. This data element defines the kind of device 961 making the emergency call. A registry is created in 962 Section 10.1.6 with the initial set of values as shown in 963 Figure 8. 965 Reason for Need: The device classification implies the capability of 966 the calling device and assists in identifying the meaning of the 967 emergency call location information that is being presented. For 968 example, does the device require human intervention to initiate a 969 call or is this call the result of programmed instructions? Does 970 the calling device have the ability to update location or 971 condition changes? Is this device interactive or a one-way 972 reporting device? 974 How Used by Call Taker: May provide the call taker context regarding 975 the caller, the capabilities of the calling device or the 976 environment in which the device is being used, and may assist in 977 understanding the location information and capabilities of the 978 calling device. For example, a cordless handset may be outside or 979 next door. 981 +---------------+----------------------------------------+ 982 | Token | Description | 983 +---------------+----------------------------------------+ 984 |cordless | Cordless handset | 985 |fixed | Fixed phone | 986 |satellite | Satellite phone | 987 |sensor-fixed | Fixed (non mobile) sensor/alarm device | 988 |desktop | Soft client on desktop PC | 989 |laptop | Soft client on laptop type device | 990 |tablet | Soft client on tablet type device | 991 |alarm-monitored| Alarm system | 992 |sensor-mobile | Mobile sensor device | 993 |aircraft | Aircraft telematics device | 994 |automobile | Automobile/cycle/off-road telematics | 995 |truck | Truck/construction telematics | 996 |farm | Farm equipment telematics | 997 |marine | Marine telematics | 998 |personal | Personal telematics device | 999 |feature-phone | Feature- (not smart-) cellular phone | 1000 |smart-phone | Smart-phone cellular phone (native) | 1001 |smart-phone-app| Soft client app on smart-phone | 1002 |unknown-device | Soft client on unknown device type | 1003 |game | Gaming console | 1004 |text-only | Other text device | 1005 |NA | Not Available | 1006 +---------------+----------------------------------------+ 1008 Figure 8: Device Classification Registry Initial Values 1010 4.3.2. Device Manufacturer 1012 Data Element: Device Manufacturer 1014 Use: Optional 1016 XML Element: 1018 Description: The plain language name of the manufacturer of the 1019 device. 1021 Reason for Need: Used by PSAP management for post-mortem 1022 investigation/resolution. 1024 How Used by Call Taker: Probably not used by the calltaker, but by 1025 PSAP management. 1027 4.3.3. Device Model Number 1029 Data Element: Device Model Number 1031 Use: Optional 1033 XML Element: 1035 Description: Model number of the device. 1037 Reason for Need: Used by PSAP management for after-action 1038 investigation/resolution. 1040 How Used by Call Taker: Probably not used by the calltaker, but by 1041 PSAP management. 1043 4.3.4. Unique Device Identifier 1045 Data Element: Unique Device Identifier 1047 Use: Optional 1049 XML Element: 1051 XML Attribute: 1053 Description: A string that identifies the specific device (or the 1054 device's current SIM) making the call or creating an event. Note 1055 that more than one may be present, to supply more 1056 than one of the identifying values. 1058 The attribute identifies the type of device 1059 identifier. A registry is created in Section 10.1.7 with an 1060 initial set of values shown in Figure 9. 1062 Reason for Need: Uniquely identifies the device (or, in the case of 1063 IMSI, a SIM), independent of any signaling identifiers present in 1064 the call signaling stream. 1066 How Used by Call Taker: Probably not used by the call taker; may be 1067 used by PSAP management during an investigation. 1069 Example: 12345 1070 +--------+------------------------------------------+ 1071 | Token | Description | 1072 +--------+------------------------------------------+ 1073 | MEID | Mobile Equipment Identifier (CDMA) | 1074 | ESN | Electronic Serial Number (GSM) | 1075 | MAC | Media Access Control Address (IEEE) | 1076 | WiMAX | Device Certificate Unique ID | 1077 | IMEI | International Mobile Equipment ID (GSM) | 1078 | IMSI | International Mobile Subscriber ID (GSM) | 1079 | UDI | Unique Device Identifier | 1080 | RFID | Radio Frequency Identification | 1081 | SN | Manufacturer Serial Number | 1082 +--------+------------------------------------------+ 1084 Figure 9: Registry of Device Identifier Types 1086 4.3.5. Device/Service-Specific Additional Data Structure 1088 Data Element: Device/service-specific additional data structure 1090 Use: Optional 1092 XML Element: 1094 Description: A URI representing additional data whose schema is 1095 specific to the device or service which created it. (For example, 1096 a medical device or medical device monitoring service may have a 1097 defined set of medical data). The URI, when dereferenced, MUST 1098 yield a data structure defined by the Device/service specific 1099 additional data type value. Different data may be created by each 1100 classification; e.g., a medical device created data set. 1102 Reason for Need: Provides device/service specific data that may be 1103 used by the call taker and/or responders. 1105 How Used by Call Taker: Provide information to guide call takers to 1106 select appropriate responders, give appropriate pre-arrival 1107 instructions to callers, and advise responders of what to be 1108 prepared for. May be used by responders to guide assistance 1109 provided. 1111 4.3.6. Device/Service Specific Additional Data Structure Type 1113 Data Element: Type of device/service-specific additional data 1114 structure 1116 Use: Conditional. MUST be provided when device/service specific- 1117 additional URI is provided 1119 XML Element: 1121 Description: A value from the registry defined in Section 10.1.8 to 1122 describe the type of data located at the device/service-specific 1123 additional data structure. The initial values shown in Figure 10 1124 currently only include IEEE 1512, which is the USDoT model for 1125 traffic incidents. 1127 Reason for Need: This data element allows identification of 1128 externally defined schemas, which may have additional data that 1129 may assist in emergency response. 1131 How Used by Call Taker: This data element allows the end user (call 1132 taker or first responder) to know what type of additional data may 1133 be available to aid in providing the needed emergency services. 1135 Note: Information which is specific to a location or a caller 1136 (person) should not be placed in this section. 1138 +----------+----------------------------+--------------------------------+ 1139 | Token | Description | Specification | 1140 +----------+----------------------------+--------------------------------+ 1141 | IEEE1512 | Common Incident Management |IEEE 1512-2006 | 1142 | | Message Set (USDoT model |https://standards.ieee.org/ | 1143 | | for traffic incidents) |findstds/standard/1512-2006.html| 1144 +----------+----------------------------+--------------------------------+ 1146 Figure 10: Device/Service Data Type Registry 1148 4.3.7. Issues with getting new types of data into use 1150 This document describes two mechanisms that allow extension of the 1151 kind of data provided with an emergency call: define a new block or 1152 define a new service specific additional data URL for the DeviceInfo 1153 block. While defining new data types and getting a new device or 1154 application to send the new data may be easy, getting PSAPs and 1155 responders to actually retrieve the data and use it will be 1156 difficult. New mechanism providers should understand that acquiring 1157 and using new forms of data usually require software upgrades at the 1158 PSAP and/or responders, as well as training of call takers and 1159 responders in how to interpret and use the information. Legal and 1160 operational review may also be needed. Overwhelming a call taker or 1161 responder with too much information is highly discouraged. Thus, the 1162 barrier to supporting new data is quite high. 1164 The mechanisms this document describes are meant to encourage 1165 development of widely supported, common data formats for classes of 1166 devices. If all manufacturers of a class of device use the same 1167 format, and the data can be shown to improve outcomes, then PSAPs and 1168 responders may be encouraged to upgrade their systems and train their 1169 staff to use the data. Variations, however well intentioned, are 1170 unlikely to be supported. 1172 Implementers should consider that data from sensor-based devices in 1173 some cases may not be useful to call takers or PSAPs (and privacy or 1174 other considerations may preclude the PSAP from touching the data), 1175 but may be of use to responders. Each data item provided with the 1176 call in conformance with this document can be accessed by responders 1177 or other entities in the emergency services, whether or not the data 1178 is accessed by the PSAP. 1180 4.3.8. Choosing between defining a new type of block or new type of 1181 device/service specific additional data 1183 For devices that have device or service specific data, there are two 1184 choices to carry it. A new block can be defined, or the device/ 1185 service specific additional data URL the DeviceInfo block can be used 1186 and a new type for it defined . The data passed would likely be the 1187 same in both cases. Considerations for choosing which mechanism to 1188 register under include: 1190 Applicability: Information which will be carried by many kinds of 1191 devices or services are more appropriately defined as separate 1192 blocks. 1194 Privacy: Information which may contain private data may be better 1195 sent in the DeviceInfo block, rather than a new block so that 1196 implementations are not tempted to send the data by value, and 1197 thus having more exposure to the data than forcing the data to be 1198 retrieved via the URL in DeviceInfo. 1200 Size: Information which may be very large may be better sent in the 1201 DeviceInfo block, rather than a new block so that implementations 1202 are not tempted to send the data by value. Conversely, data which 1203 is small may best be sent in a separate block so that it can be 1204 sent by value 1206 Availability of a server: Providing the data via the device block 1207 requires a server be made available to retrieve the data. 1208 Providing the data via new block allows it to be sent by value 1209 (CID). 1211 4.3.9. EmergencyCallData.DeviceInfo Example 1213 1214 1216 d4b3072df.201409182208075@example.org 1217 1218 fixed 1219 Nokia 1220 Lumia 800 1221 35788104 1222 1223 1225 Figure 11: EmergencyCallData.DeviceInfo Example. 1227 4.4. Owner/Subscriber Information 1229 This block describes the owner of the device (if provided by the 1230 device) or the subscriber information (if provided by a service 1231 provider). The contact location is not necessarily the location of 1232 the caller or incident, but is rather the nominal contact address. 1233 The MIME type is "application/EmergencyCallData.SubscriberInfo+xml". 1235 In some jurisdictions some or all parts of the subscriber-specific 1236 information are subject to privacy constraints. These constraints 1237 vary but dictate what information can be displayed and logged. A 1238 general privacy indicator expressing a desire for privacy by the 1239 subscriber is provided. The interpretation of how this is applied is 1240 left to the receiving jurisdiction as the custodians of the local 1241 regulatory requirements. This matches an equivalent privacy flag 1242 provided in some legacy emergency call systems. 1244 4.4.1. Subscriber Data Privacy Indicator 1246 Attribute: 'privacyRequested', Boolean. 1248 Use: Conditional. This attribute MUST be provided if the owner/ 1249 subscriber information block is not empty. 1251 Description: The subscriber data privacy indicator specifically 1252 expresses the subscriber's desire for privacy. In some 1253 jurisdictions subscriber services can have a specific "Type of 1254 Service" which prohibits information, such as the name of the 1255 subscriber, from being displayed. This attribute is provided to 1256 explicitly indicate whether the subscriber service includes such 1257 constraints. The interpretation of this indicator is left to each 1258 jurisdiction (in keeping with the semantics of the privacy 1259 indicator provided in some legacy emergency call systems). 1261 Reason for Need: Some jurisdictions require subscriber privacy to be 1262 observed when processing emergency calls. 1264 How Used by Call Taker: Where privacy is indicated the call taker 1265 may not have access to some aspects of the subscriber information. 1267 4.4.2. xCard for Subscriber's Data 1269 Data Element: xCARD for Subscriber's Data 1271 Use: Conditional. Subscriber data MUST be provided unless it is not 1272 available. Some services, such as prepaid phones, non-initialized 1273 phones, etc., do not have information about the subscriber. 1275 XML Element: 1277 Description: Information known by the service provider or device 1278 about the subscriber; e.g., Name, Address, Individual Telephone 1279 Number, Main Telephone Number and any other data. , (if 1280 appropriate), , , are suggested at a minimum. 1281 If more than one property is provided, a parameter from the 1282 vCard Property Value registry MUST be specified on each . 1283 While some data (such as ) might not seem obviously 1284 relevant for emergency services, any data is potentially useful in 1285 some emergency circumstances. 1287 Reason for Need: When the caller is unable to provide information, 1288 this data may be used to obtain it 1290 How Used by Call Taker: Obtaining critical information about the 1291 caller and possibly the location when it is not able to be 1292 obtained otherwise. While the location here is not necessarily 1293 that of caller, in some circumstances it can be helpful in 1294 locating the caller when other means have failed. 1296 4.4.3. EmergencyCallData.SubscriberInfo Example 1298 1299 1303 FEABFECD901@example.org 1304 1305 1306 1307 Simon Perreault 1308 1309 Perreault 1310 Simon 1311 1312 1313 ing. jr 1314 M.Sc. 1315 1316 --0203 1317 1318 20090808T1430-0500 1319 1320 M 1321 1322 1 1323 1324 fr 1325 1326 1327 2 1328 1329 en 1330 1331 1332 work 1333 1334 Viagenie 1335 1336 1337 1338 work 1339 1343 1344 1345 1346 2875 boul. Laurier, suite D2-630 1347 Quebec 1348 QC 1349 G1V 2M2 1350 Canada 1351 1352 1353 1354 1355 work 1356 voice 1357 1358 1359 tel:+1-418-656-9254;ext=102 1360 1361 1362 1363 1364 work 1365 text 1366 voice 1367 cell 1368 video 1369 1370 1371 tel:+1-418-262-6501 1372 1373 1374 work 1375 1376 simon.perreault@viagenie.ca 1377 1378 1379 work 1380 1381 geo:46.766336,-71.28955 1382 1383 1384 work 1385 1386 1387 http://www.viagenie.ca/simon.perreault/simon.asc 1388 1389 1390 America/Montreal 1391 1392 home 1393 1394 http://nomis80.org 1395 1396 1397 1398 1400 Figure 12: EmergencyCallData.SubscriberInfo Example. 1402 4.5. Comment 1404 This block provides a mechanism for the data provider to supply 1405 extra, human readable information to the PSAP. It is not intended 1406 for a general purpose extension mechanism nor does it aim to provide 1407 machine-readable content. The mime subtype is "application/ 1408 EmergencyCallData.Comment+xml" 1410 4.5.1. Comment 1412 Data Element: EmergencyCallData.Comment 1414 Use: Optional 1416 XML Element: 1418 Description: Human readable text providing additional information to 1419 the PSAP staff. 1421 Reason for Need: Explanatory information for values in the data 1422 structure. 1424 How Used by Call Taker: To interpret the data provided. 1426 4.5.2. EmergencyCallData.Comment Example 1428 1429 1431 string0987654321@example.org 1432 1433 This is an example text. 1434 1436 Figure 13: EmergencyCallData.Comment Example. 1438 5. Data Transport Mechanisms 1440 This section defines how to convey additional data to an emergency 1441 service provider. Two different means are specified: the first uses 1442 the call signaling; the second uses the element of a 1443 PIDF-LO [RFC4119]. 1445 1. First, the ability to embed a Uniform Resource Identifier (URI) 1446 in an existing SIP header field, the Call-Info header, is 1447 defined. The URI points to the additional data structure. The 1448 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1449 document adds a new compound token starting with the value 1450 'EmergencyCallData' for the Call-Info "purpose" parameter. If 1451 the "purpose" parameter is set to a value starting with 1452 'EmergencyCallData', then the Call-Info header contains either an 1453 HTTPS URL pointing to an external resource or a CID (content 1454 indirection) URI that allows the data structure to be placed in 1455 the body of the SIP message. The "purpose" parameter also 1456 indicates the kind of data (by its MIME type) that is available 1457 at the URI. As the data is conveyed using a URI in the SIP 1458 signaling, the data itself may reside on an external resource, or 1459 may be contained within the body of the SIP message. When the 1460 URI refers to data at an external resource, the data is said to 1461 be passed by reference. When the URI refers to data contained 1462 within the body of the SIP message, the data is said to be passed 1463 by value. A PSAP or emergency responder is able to examine the 1464 type of data provided and selectively inspect the data it is 1465 interested in, while forwarding all of it (the values or 1466 references) to downstream entities. To be conveyed in a SIP 1467 body, additional data about a call is defined as a series of MIME 1468 objects. Each block defined in this document is an XML data 1469 structure identified by its MIME type. (Blocks defined by others 1470 may be encoded in XML or not, as identified by their MIME 1471 registration.) As usual, whenever more than one MIME part is 1472 included in the body of a message, MIME multipart (i.e., 1473 'multipart/mixed') encloses them all. This document defines a 1474 set of XML schemas and MIME types used for each block defined 1475 here. When additional data is passed by value in the SIP 1476 signaling, each CID URL points to one block in the body. 1477 Multiple URIs are used within a Call-Info header field (or 1478 multiple Call-Info header fields) to point to multiple blocks. 1479 When additional data is provided by reference (in SIP signaling 1480 or the element of a PIDF-LO), each HTTPS URL 1481 references one block; the data is retrieved with an HTTPS GET 1482 operation, which returns the block as an object (the blocks 1483 defined here are returned as XML objects). 1485 2. Second, the ability to embed additional data structures in the 1486 element of a PIDF-LO [RFC4119] is defined. In 1487 addition to service providers in the call path, the access 1488 network provider may also have similar information that can be 1489 valuable to the PSAP. When the access network provider supplies 1490 location information in the form of a PIDF-LO from a location 1491 server via a location configuration protocol, it has the ability 1492 to add the data structures defined in this document within the 1493 PIDF-LO. The data in these data structures is not specific to 1494 the location itself, but rather provides descriptive information 1495 having to do with the immediate circumstances about the provision 1496 of the location (e.g., the identity of the access network 1497 provider, how to contact that entity, what kind of service the 1498 access network provides, subscriber information, etc.). This 1499 data is similar in nearly every respect to the data known by 1500 service providers in the path of the call. When the access 1501 network provider and service provider are separate entities, the 1502 access network does not participate in the application layer 1503 signaling (and hence cannot add a Call-Info header field to the 1504 SIP message), but can provide location information in a PIDF-LO. 1505 The element of the PIDF-LO is a mechanism for the 1506 access network provider to supply the information. For this 1507 reason, this document describes a namespace per [RFC4119] for 1508 inclusion in the element of a PIDF-LO for adding 1509 information known to the access network provider. The access 1510 network provider SHOULD provide additional data within a 1511 element of a PDIF-LO it returns for emergency use 1512 (e.g., if requested with a HELD "responseTime" attribute of 1513 "emergencyRouting" or "emergencyDispatch" [RFC5985]). 1515 One or more blocks of data registered in the Emergency Call 1516 Additional Data registry, as defined in Section 10.1.9, can be 1517 included or referenced in the SIP signaling (using the Call-Info 1518 header field) or in the element of a PIDF-LO. For 1519 interoperability, only blocks in the registry are permitted to be 1520 sent using the mechanisms specified in this document. Since multiple 1521 entities are expected to provide sets of data, the data itself needs 1522 information describing the source. Consequently, each entity adding 1523 additional data MUST supply a "Data Provider" block. All other 1524 blocks are optional, but each entity SHOULD supply all blocks where 1525 it has at least some of the information in the block. 1527 5.1. Transmitting Blocks using the Call-Info Header 1529 A URI to a block MAY be inserted in any SIP request or response 1530 method (most often INVITE or MESSAGE) with a Call-Info header field 1531 containing a purpose value starting with 'EmergencyCallData' and the 1532 type of data available at the URI. The type of data is denoted by 1533 including the root of the MIME type (not including the 1534 'EmergencyCallData' prefix and any suffix such as '+xml') with a '.' 1535 separator. For example, when referencing a block with MIME type 1536 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 1537 parameter is set to 'EmergencyCallData.ProviderInfo'. An example 1538 "Call-Info" header field for this would be: 1540 Call-Info: https://www.example.com/23sedde3; 1541 purpose="EmergencyCallData.ProviderInfo" 1543 A Call-info header with a purpose value starting with 1544 'EmergencyCallData' only has meaning in the context of an emergency 1545 call (as ascertained by the presence of an emergency service URN in a 1546 Request-URI header of a SIP message), test emergency calls (using an 1547 appropriate service URN), and some private-use calls where the 1548 endpoints have a preexisting relationship and privacy concerns do not 1549 apply because of the relationship; use in other contexts is undefined 1550 and is likely to unnecessarily expose confidential data. 1552 If the data is provided by reference, an HTTPS URI MUST be included 1553 and consequently Transport Layer Security (TLS) protection is applied 1554 for protecting the retrieval of the information. 1556 The data may also be supplied by value in any SIP request or response 1557 method that is permitted to contain a body (i.e., not a BYE request). 1558 In this case, Content Indirection (CID) [RFC2392] is used, with the 1559 CID URL referencing the MIME body part containing the data. Note 1560 that [RFC3261] forbids proxies from altering message bodies, so 1561 entities in the call path that add blocks by value need to do so 1562 using an appropriate SIP entity (e.g., a back-to-back user agent). 1564 Transmitting data by value is especially useful in certain cases, 1565 such as when the data exists in or is generated by the originating 1566 device, but is not intended for very large data blocks. Additional 1567 security and privacy considerations apply to data transmitted by 1568 value, as discussed in Section 8 and Section 9. 1570 More than one Call-Info header with a purpose value starting with 1571 'EmergencyCallData' can be expected, but at least one MUST be 1572 provided. The device MUST provide one if it knows no service 1573 provider is in the path of the call. The device MAY insert one if it 1574 uses a service provider. Any service provider in the path of the 1575 call MUST insert its own. For example, a device, a telematics 1576 service provider in the call path, as well as the mobile carrier 1577 handling the call will each provide one. There may be circumstances 1578 where there is a service provider who is unaware that the call is an 1579 emergency call and cannot reasonably be expected to determine that it 1580 is an emergency call. In that case, that service provider is not 1581 expected to provide EmergencyCallData. 1583 5.2. Transmitting Blocks by Reference using the Element 1585 The element is used to transmit an 1586 additional data block by reference within a element of 1587 a PIDF-LO. The element has two 1588 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1589 type of data block referenced. The value of 'ref' is an HTTPS URL 1590 that resolves to a data structure with information about the call. 1591 The value of 'purpose' is the same as used in a 'Call-Info' header 1592 field (as specified in Section 5.1). 1594 For example, to reference a block with MIME type 'application/ 1595 EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set 1596 to 'EmergencyCallData.ProviderInfo'. An example 1597 element for this would be: 1599 1602 The element transmits one data block; 1603 multiple data blocks may be transmitted by using multiple 1604 elements. Multiple 1605 elements MAY be included as child 1606 elements inside the element. 1608 The following is a simplified example: 1610 1615 1619 1622 1624 Example by Reference 1626 For an example in context, Figure 18 shows a PIDF-LO example with an 1627 element pointing to an 1628 EmergencyCallData.ServiceInfo data block with the URL in the 'ref' 1629 attribute and the purpose attribute set to 1630 "EmergencyCallData.ServiceInfo". 1632 5.3. Transmitting Blocks by Value using the Element 1634 It is RECOMMENDED that access networks supply the data specified in 1635 this document by reference, but they MAY provide the data by value. 1637 The element is used to transmit one or more 1638 additional data blocks by value within a element of a 1639 PIDF-LO. Each block being transmitted is placed (as a child element) 1640 inside the element. (The same XML structure 1641 as would be contained in the corresponding MIME type body part is 1642 placed inside the element.) Multiple 1643 elements MAY be included as child elements 1644 in the element. 1646 The following is a simplified example: 1648 1652 1655 flurbit735@es.example.com 1656 1657 Access Network Examples, Inc 1658 1659 urn:nena:companyid:Test 1660 NENA 1661 Access Network Provider 1662 1663 tel:+1-555-555-0897 1664 en 1665 1667 1670 flurbit735@es.example.com 1671 1672 This is an example text. 1673 1674 1676 1678 1680 Example by Value 1682 For an example in context, Figure 18 shows a PIDF-LO example that 1683 contains a element with the 1684 and the 1685 elements as child elements of an element. 1687 5.4. The Content-Disposition Parameter 1689 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1690 It updates and clarifies handling originally defined in RFC 3261 1691 [RFC3261] based on implementation experience. While RFC 3261 did not 1692 mandate support for 'multipart' message bodies, 'multipart/mixed' 1693 MIME bodies are used by many extensions (including this document) 1694 today. For example, adding a PIDF-LO, SDP, and additional data in 1695 body of a SIP message requires a 'multipart' message body. 1697 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1698 parameter for the Content-Disposition header field. These RFCs 1699 describe how a UAS reacts if it receives a message body whose content 1700 type or disposition type it does not understand. If the 'handling' 1701 parameter has the value "optional", the UAS ignores the message body. 1702 If the 'handling' parameter has the value "required", the UAS returns 1703 a 415 (Unsupported Media Type) response. The 'by-reference' 1704 disposition type allows a SIP message to contain a reference to the 1705 body part, and the SIP UA processes the body part according to the 1706 reference. This is the case for the Call-info header containing a 1707 Content Indirection (CID) URL. 1709 As an example, a SIP message indicates the Content-Disposition 1710 parameter in the body of the SIP message as shown in Figure 14. 1712 Content-Type: application/sdp 1714 ...Omit Content-Disposition here; defaults are ok 1715 ...SDP goes in here 1717 --boundary1 1719 Content-Type: application/pidf+xml 1720 Content-ID: 1721 Content-Disposition: by-reference;handling=optional 1723 ...PIDF-LO goes in here 1725 --boundary1-- 1727 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1728 Content-ID: <1234567890@atlanta.example.com> 1729 Content-Disposition: by-reference; handling=optional 1731 ...Data provider information data goes in here 1733 --boundary1-- 1735 Figure 14: Example for use of the Content-Disposition Parameter in 1736 SIP 1738 6. Examples 1740 This section illustrates a longer and more complex example, as shown 1741 in Figure 15. In this example additional data is added by the end 1742 device, included by the VoIP provider, and provided by the access 1743 network provider (via the PIDF-LO). 1745 O +----+ [============] [=============] 1746 /|\ | UA | [ Access ] [ VoIP ] 1747 | +----+ [ Network ] [ Provider ] 1748 / \ [ Provider ] [ example.org ] 1749 [ ] [ ] 1750 (1) [ ] (2) [ ] 1751 Emergency Call [ ] Emergency Call [ ] 1752 ------------------------------------------------------> ] 1753 +Device Info [ ] +Device Info [ ] 1754 +Data Prov. Info [ ^ ] +Data Provider Info [ | ] 1755 +Location URI [=======.====] +Location URI [====|========] 1756 . | 1757 . | 1758 +Location . [==============] | 1759 +Owner/Subscriber Info . [ ] (3) | 1760 +Device Info . (4) [ <------------+ 1761 +Data Provider Info #3 ..........> ] Emergency Call 1762 [ ] +Device Info 1763 [ PSAP ] +Data Prov. Info #2 1764 [ ] +Location URI 1765 [==============] 1767 Legend: 1769 --- Emergency Call Setup Procedure 1770 ... Location Retrieval/Response 1772 Figure 15: Additional Data Example Flow 1774 The example scenario starts with the end device itself adding device 1775 information, owner/subscriber information, a location URI, and data 1776 provider information to the outgoing emergency call setup message 1777 (see step #1 in Figure 15). The SIP INVITE example is shown in 1778 Figure 16. 1780 INVITE urn:service:sos SIP/2.0 1781 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1782 Max-Forwards: 70 1783 To: 1784 From: Hannes Tschofenig ;tag=9fxced76sl 1785 Call-ID: 3848276298220188511@example.com 1786 Call-Info: 1787 ;purpose=icon, 1788 ;purpose=info, 1789 1790 ;purpose=EmergencyCallData.ProviderInfo, 1792 1793 ;purpose=EmergencyCallData.DeviceInfo 1794 Geolocation: 1795 Geolocation-Routing: yes 1796 Accept: application/sdp, application/pidf+xml, 1797 application/EmergencyCallData.ProviderInfo+xml 1798 CSeq: 31862 INVITE 1799 Contact: 1800 Content-Type: multipart/mixed; boundary=boundary1 1802 Content-Length: ... 1804 --boundary1 1806 Content-Type: application/sdp 1808 ...SDP goes here 1810 --boundary1-- 1812 Content-Type: application/EmergencyCallData.DeviceInfo+xml 1813 Content-ID: <0123456789@atlanta.example.com> 1814 Content-Disposition: by-reference;handling=optional 1815 1817 1819 d4b3072df09876543@[93.184.216.119] 1820 1821 laptop 1822 00-0d-4b-30-72-df 1824 1826 --boundary1-- 1828 Content-Type: application/EmergencyCallData.ProviderInfo+xml 1829 Content-ID: <1234567890@atlanta.example.com> 1830 Content-Disposition: by-reference;handling=optional 1831 1832 1834 d4b3072df09876543@[93.184.216.119] 1835 1836 Hannes Tschofenig 1837 1838 Client 1839 tel:+1-555-555-0123 1840 en 1841 1843 1844 Hannes Tschofenig 1845 1846 Hannes 1847 Tschofenig 1848 1849 1850 Dipl. Ing. 1851 1852 --0203 1853 1854 20090808T1430-0500 1855 1856 M 1857 1858 1 1859 1860 de 1861 1862 1863 2 1864 1865 en 1866 1867 1868 1869 work 1870 1874 1875 1876 1877 Linnoitustie 6 1878 Espoo 1879 Uusimaa 1880 02600 1881 Finland 1882 1883 1884 1885 home 1886 1891 1892 1893 1894 42 W 11th St 1895 Wilmington 1896 DE 1897 19801 1898 USA 1899 1900 1901 1902 1903 work 1904 voice 1905 1906 1907 tel:+358 50 4871445 1908 1909 1910 1911 1912 home 1913 voice 1914 1915 1916 tel:+1 555 555 0123 1917 1918 1919 work 1920 1921 hannes.tschofenig@nsn.com 1922 1923 1924 work 1925 1926 geo:60.210796,24.812924 1927 1928 1929 home 1930 1931 geo:39.746537,-75.548027 1932 1933 1934 1935 home 1936 1937 https://www.example.com/key.asc 1938 1939 1940 Finland/Helsinki 1941 1942 home 1943 1944 http://example.com/hannes.tschofenig 1945 1946 1947 1948 1949 1950 --boundary1-- 1952 Figure 16: End Device sending SIP INVITE with Additional Data 1954 In this example, information available to the access network provider 1955 is included in the call setup message only indirectly via the use of 1956 the location reference. The PSAP has to retrieve it via a separate 1957 look-up step. Since the access network provider and the VoIP service 1958 provider are two independent entities in this scenario, the access 1959 network provider is not involved in application layer exchanges; the 1960 SIP INVITE transits the access network transparently, as illustrated 1961 in steps #1 and #2 (the access network does not alter the SIP 1962 INVITE). 1964 The VoIP service provider receives the message and determines, based 1965 on the Service URN, that the incoming request is an emergency call. 1966 It performs typical emergency services related tasks (such as 1967 location-based routing), and adds additional data, namely service and 1968 subscriber information as well as data provider information #2, to 1969 the outgoing message. For the example we assume a VoIP service 1970 provider that deploys a back-to-back user agent allowing additional 1971 data to be included in the body of the SIP message (rather than by 1972 reference), which allows us to illustrate the use of multiple data 1973 provider info blocks. The resulting message is shown in Figure 17. 1974 The SIP INVITE is sent to the PSAP in step #3. 1976 INVITE sips:psap@example.org SIP/2.0 1977 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1978 Max-Forwards: 70 1979 To: 1980 From: Hannes Tschofenig ;tag=9fxced76sl 1981 Call-ID: 3848276298220188511@example.com 1982 Call-Info: 1983 ;purpose=icon, 1984 ;purpose=info, 1985 1986 ;purpose=EmergencyCallData.ProviderInfo 1987 1988 ;purpose=EmergencyCallData.DeviceInfo 1989 Call-Info: 1990 ;purpose=EmergencyCallData.ServiceInfo 1991 Call-Info: 1992 ;purpose=EmergencyCallData.ProviderInfo 1993 Geolocation: 1994 Geolocation-Routing: yes 1995 Accept: application/sdp, application/pidf+xml, 1996 application/EmergencyCallData.ProviderInfo+xml 1997 CSeq: 31862 INVITE 1998 Contact: 1999 Content-Type: multipart/mixed; boundary=boundary1 2001 Content-Length: ... 2003 --boundary1 2005 Content-Type: application/sdp 2007 ...SDP goes here 2009 --boundary1-- 2011 Content-Type: application/EmergencyCallData.DeviceInfo+xml 2012 Content-ID: <0123456789@atlanta.example.com> 2013 Content-Disposition: by-reference;handling=optional 2014 2016 2018 d4b3072df09876543@[93.184.216.119] 2019 2020 laptop 2021 00-0d-4b-30-72-df 2023 2025 --boundary1-- 2027 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2028 Content-ID: <1234567890@atlanta.example.com> 2029 Content-Disposition: by-reference;handling=optional 2030 2031 2033 d4b3072df09876543@[93.184.216.119] 2034 2035 Hannes Tschofenig 2036 2037 Client 2038 tel:+1-555-555-0123 2039 en 2040 2042 2043 Hannes Tschofenig 2044 2045 Hannes 2046 Tschofenig 2047 2048 2049 Dipl. Ing. 2050 2051 --0203 2052 2053 20090808T1430-0500 2054 2055 M 2056 2057 1 2058 2059 de 2060 2061 2062 2 2063 2064 en 2065 2066 2067 2068 work 2069 2073 2074 2075 2076 Linnoitustie 6 2077 Espoo 2078 Uusimaa 2079 02600 2080 Finland 2081 2082 2083 2084 home 2085 2090 2091 2092 2093 42 W 11th St 2094 Wilmington 2095 DE 2096 19801 2097 USA 2098 2099 2100 2101 2102 work 2103 voice 2104 2105 2106 tel:+358 50 4871445 2107 2108 2109 2110 2111 home 2112 voice 2113 2114 2115 tel:+1 555 555 0123 2116 2117 2118 work 2119 2120 hannes.tschofenig@nsn.com 2121 2122 2123 work 2124 2125 geo:60.210796,24.812924 2126 2127 2128 home 2129 2130 geo:39.746537,-75.548027 2131 2132 2133 2134 home 2135 2136 https://www.example.com/key.asc 2137 2138 2139 Finland/Helsinki 2140 2141 home 2142 2143 http://example.com/hannes.tschofenig 2144 2145 2146 2147 2148 2150 --boundary1-- 2152 Content-Type: application/EmergencyCallData.ServiceInfo+xml 2153 Content-ID: 2154 Content-Disposition: by-reference;handling=optional 2155 2156 2158 string0987654321@example.org 2159 2160 Residence 2161 VOIP 2162 Unknown 2163 2165 --boundary1-- 2167 Content-Type: application/EmergencyCallData.ProviderInfo+xml 2168 Content-ID: 2169 Content-Disposition: by-reference;handling=optional 2170 2171 2173 string0987654321@example.org 2174 2175 Exemplar VoIP Provider 2176 2177 urn:nena:companyid:ID123 2178 NENA 2179 Service Provider 2180 sip:voip-provider@example.com 2181 en 2182 2184 2185 John Doe 2186 2187 John 2188 Doe 2189 2190 2191 2192 2193 --0203 2194 2195 20090808T1430-0500 2196 2197 M 2198 2199 1 2200 2201 en 2202 2203 2204 work 2205 2206 Exemplar VoIP Provider 2207 2208 2209 2210 work 2211 2214 2215 2216 2217 123 Middle Street 2218 the Sticks 2219 IA 2220 50055 2221 USA 2222 2223 2224 2225 2226 work 2227 voice 2228 2229 2230 sips:john.doe@example.com 2231 2232 2233 work 2234 2235 john.doe@example.com 2236 2237 2238 work 2239 2240 geo:41.761838,-92.963268 2241 2242 America/Chicago 2243 2244 home 2245 2246 http://www.example.com/john.doe 2247 2248 2249 2250 2252 Figure 17: VoIP Provider sending SIP INVITE with Additional Data 2254 Finally, the PSAP requests location information from the access 2255 network provider. The response is shown in Figure 18. Along with 2256 the location information, additional data is provided in the 2257 element of the PIDF-LO. This request and response is 2258 step #4. 2260 2261 2266 2267 2268 2269 2271 US 2272 DE 2273 Wilmington 2274 W 2275 11th 2276 Street 2277 42 2278 The Hotel DuPont 2279 19801 2280 2281 2282 2283 true 2284 2285 2013-12-10T20:00:00Z 2286 2287 2288 802.11 2290 2293 2297 2298 2301 88QV4FpfZ976T@example.com 2302 2303 Diamond State Exemplar 2304 2305 urn:nena:companyid:diamond 2306 NENA 2307 Access Network Provider 2308 tel:+1-302-555-0000 2309 en 2310 2312 2314 88QV4FpfZ976T@example.com 2315 2316 This is an example text. 2317 2319 2320 2321 2322 mac:00-0d-4b-30-72-df 2323 2013-07-09T20:57:29Z 2324 2325 2327 Figure 18: Access Network Provider returning PIDF-LO with Additional 2328 Data 2330 7. XML Schemas 2332 This section defines the XML schemas of the five data blocks. 2333 Additionally, the provided-by schema is specified. 2335 7.1. EmergencyCallData.ProviderInfo XML Schema 2337 2338 2348 2351 2354 2358 2359 2360 2361 2363 2364 2366 2367 2368 2371 2374 2377 2380 2383 2386 2387 2388 2389 2395 2396 2397 2399 2401 2402 2403 2405 2406 2407 2408 2411 2415 2417 2418 2420 2422 Figure 19: EmergencyCallData.ProviderInfo XML Schema. 2424 7.2. EmergencyCallData.ServiceInfo XML Schema 2425 2426 2435 2438 2441 2442 2443 2446 2449 2453 2456 2458 2459 2461 2463 Figure 20: EmergencyCallData.ServiceInfo XML Schema. 2465 7.3. EmergencyCallData.DeviceInfo XML Schema 2467 2468 2477 2480 2483 2484 2485 2488 2491 2494 2497 2499 2500 2501 2502 2505 2506 2507 2508 2510 2513 2516 2518 2519 2521 2523 Figure 21: EmergencyCallData.DeviceInfo XML Schema. 2525 7.4. EmergencyCallData.SubscriberInfo XML Schema 2527 2528 2539 2542 2545 2548 2549 2550 2551 2552 2555 2556 2557 2558 2560 2561 2562 2564 2566 2567 2569 2570 2571 2573 2575 Figure 22: EmergencyCallData.SubscriberInfo XML Schema. 2577 7.5. EmergencyCallData.Comment XML Schema 2578 2579 2588 2591 2594 2595 2596 2599 2603 2605 2606 2608 2609 2610 2611 2612 2613 2614 2616 2618 Figure 23: EmergencyCallData.Comment XML Schema. 2620 7.6. provided-by XML Schema 2622 This section defines the provided-by schema. 2624 2625 2640 2643 2646 2649 2652 2656 2659 2662 2664 2665 2666 2667 2668 2670 2671 2674 2676 2677 2678 2680 2682 2683 2684 2687 2690 2693 2696 2700 2703 2704 2706 2708 Figure 24: provided-by XML Schema 2710 8. Security Considerations 2712 The data structures described in this document contain information 2713 usually considered private. When information is provided by value, 2714 entities that are a party to the SIP signaling (such as proxy servers 2715 and back-to-back user agents) will have access to it and need to 2716 protect it against inappropriate disclosure. An entity that is able 2717 to eavesdrop on the SIP signaling will also have access. Some access 2718 types (such as in-the-clear Wi-Fi) are more vulnerable than others 2719 (such as 3G or 4G cellular data traffic) to eavesdropping. 2720 Mechanisms that protect against eavesdropping (such as Transport 2721 Layer Security (TLS)) SHOULD be preferentially used whenever 2722 feasible. (This requirement is not a "MUST" because there is an 2723 existing deployed base of clear-text SIP, and also because, as an 2724 emergency call, it is more important for the call to go through than 2725 for it to be protected; e.g., the call MUST proceed even if the TLS 2726 negotiation or certificate verification fails for whatever reason.) 2727 When information is provided by reference, HTTPS is REQUIRED for 2728 dereferencing, and the provider of the information is REQUIRED to 2729 validate the credentials of the requester. While the creation of a 2730 public key infrastructure (PKI) that has global scope may be 2731 difficult, the alternatives to creating devices and services that can 2732 provide critical information securely are more daunting. The 2733 provider of the information MAY enforce any policy it wishes to use, 2734 but PSAPs and responder agencies SHOULD deploy a PKI so that 2735 providers of additional data can check the certificate of the client 2736 (the requester) and decide the appropriate policy to enforce based on 2737 that certificate. 2739 Ideally, the PSAP and emergency responders will be given credentials 2740 signed by an authority trusted by the data provider. In most 2741 circumstances, nationally recognized credentials are sufficient; the 2742 emergency services community within a country can arrange a PKI, data 2743 providers can be provisioned with the root CA public key for the 2744 country. Some nations are developing a PKI for this, and related, 2745 purposes. Since calls could be made from devices where the device 2746 and/or the service provider(s) are not local to the emergency 2747 services authorities, globally recognized credentials are useful. 2748 This might be accomplished by extending the notion of the "forest 2749 guide" described in [RFC5582] to allow the forest guide to provide 2750 the credential of the PKI root for areas for which it has coverage 2751 information, but standards for such a mechanism are not yet 2752 available. In its absence, the data provider needs to obtain by out 2753 of band means the root CA credentials for any areas to which it is 2754 willing to provide additional data. With the credential of the root 2755 CA for a national emergency services PKI, the data provider server 2756 can validate the credentials of an entity requesting additional data 2757 by reference. 2759 The data provider also needs a credential that can be verified by the 2760 emergency services to know that it is receiving data from an 2761 authorized server. The emergency services authorities could provide 2762 credentials, distinguishable from credentials provided to emergency 2763 responders and PSAPs, which could be used to validate data providers. 2764 Such credentials would have to be acceptable to any PSAP or responder 2765 that could receive a call with additional data supplied by that 2766 provider. This would be extensible to global credential validation 2767 using the forest guide as mentioned above. In the absence of such 2768 credentials, the emergency services authorities could maintain a list 2769 of local data providers' credentials as provided to them out of band. 2771 At a minimum, the emergency services authorities could obtain a 2772 credential from the DNS entry of the domain in the Additional Data 2773 URI to at least validate that the server is known to the domain 2774 providing the URI. 2776 Data provided by devices by reference have similar credential 2777 validation issues as for service providers, and while the solutions 2778 are the same, the challenges of doing so for every device are 2779 obviously more difficult, especially when considering root 2780 certificate updates, revocation lists, etc. However, in general, 2781 devices are not expected to provide data directly by reference, but 2782 rather, to either provide data by value, or upload the data to a 2783 server which can more reliably make it available and more easily 2784 enforce security policy. Devices which do provide data directly by 2785 reference, which might include fixed-location sensors, will need to 2786 be capable of handling this. 2788 Much of the information supplied by service providers and devices is 2789 private and confidential; service providers and devices generally go 2790 to lengths to protect this information; disclosing it in the context 2791 of an emergency call is a trade-off to protect the greater interest 2792 of the customer in an emergency. 2794 Neither service providers nor devices will supply private information 2795 unless the call is recognized as an emergency call. In cellular 2796 telephony systems (such as those using 3GPP IMS), there are different 2797 procedures for an originating device to place an emergency versus a 2798 normal call. If a call that is really an emergency call is initiated 2799 as a normal call and the cellular service provider recognizes this, 2800 3GPP IMS permits the service provider to either accept the call 2801 anyway or reject it with a specific code that instructs the device to 2802 retry the call as an emergency call. Service providers ought to 2803 choose the latter, because otherwise the device will not have 2804 included the information specified in this document (since the device 2805 didn't recognize the call as being an emergency call). 2807 9. Privacy Considerations 2809 This document enables functionality for conveying additional 2810 information about the caller and the caller's device and service to 2811 the callee. Some of this information is personal data and therefore 2812 privacy concerns arise. An explicit privacy indicator for 2813 information directly relating to the caller's identity is defined and 2814 use is mandatory. However, observance of this request for privacy 2815 and which information it relates to is determined by the destination 2816 jurisdiction (which replicates functionality provided in some legacy 2817 emergency services systems). 2819 There are a number of privacy concerns with non-emergency real-time 2820 communication services that are also applicable to emergency calling. 2821 Data protection regulation world-wide has, however, decided to create 2822 exceptions for emergency services since the drawbacks of disclosing 2823 personal data are outweighed by the benefit for the emergency caller. 2824 Hence, the data protection rights of individuals are commonly waived 2825 for emergency situations. There are, however, still various 2826 countries that offer some degree of anonymity for the caller towards 2827 PSAP call takers. 2829 The functionality defined in this document far exceeds the amount of 2830 information sharing available in the legacy POTS system. For this 2831 reason there are additional privacy threats to consider, which are 2832 described in more detail in [RFC6973]. 2834 Stored Data Compromise: There is an increased risk of stored data 2835 compromise since additional data is collected and stored in 2836 databases. Without adequate measures to secure stored data from 2837 unauthorized or inappropriate access at access network providers, 2838 service providers, end devices, as well as PSAPs, individuals are 2839 exposed to potential financial, reputational, or physical harm. 2841 Misattribution: If the personal data collected and conveyed is 2842 incorrect or inaccurate then this may lead to misattribution. 2843 Misattribution occurs when data or communications related to one 2844 individual are attributed to another. 2846 Identification: By the nature of the additional data and its 2847 capability to provide much richer information about the caller, 2848 the call, and the location, the calling party is identified in a 2849 much better way. Some users may feel uncomfortable with this 2850 degree of information sharing even in emergency services 2851 situations. 2853 Secondary Use: There is a risk of secondary use, which is the use of 2854 collected information about an individual without the individual's 2855 consent for a purpose different from that for which the 2856 information was collected. The stated purpose of the additional 2857 data is for emergency services purposes but theoretically the same 2858 information could be used for any other call as well. 2859 Additionally, parties involved in the emergency call may retain 2860 the obtained information and may re-use it for other, non- 2861 emergency services purposes. 2863 Disclosure: When the data defined in this document is not properly 2864 protected (while in transit with traditional communication 2865 security techniques, and while stored using access control 2866 mechanisms) there is the risk of disclosure, which is the 2867 revelation of private information about an individual. 2869 To mitigate these privacy risks the following countermeasures can be 2870 taken: 2872 In regions where callers can elect to suppress certain personally 2873 identifying information, network or PSAP functionality can inspect 2874 privacy flags within the SIP headers to determine what information 2875 may be passed, stored, or displayed to comply with local policy or 2876 law. RFC 3325 [RFC3325] defines the "id" priv-value token. The 2877 presence of this privacy type in a Privacy header field indicates 2878 that the user would like the network asserted identity to be kept 2879 private with respect to SIP entities outside the trust domain with 2880 which the user authenticated, including the PSAP. 2882 This document defines various data structures that contain privacy- 2883 sensitive data. For example, identifiers for the device (e.g., 2884 serial number, MAC address) or account/SIM (e.g., IMSI), contact 2885 information for the user, location of the caller. Local regulations 2886 may govern which data is provided in emergency calls, but in general, 2887 the emergency call system is aided by the information described in 2888 this document. There is a tradeoff between the privacy 2889 considerations and the utility of the data. For protection, this 2890 specification requires all retrieval of data passed by reference to 2891 be protected against eavesdropping and alteration via communication 2892 security techniques (namely TLS). Furthermore, security safeguards 2893 are required to prevent unauthorized access to stored data. Various 2894 security incidents over at least the past few decades have shown that 2895 data breaches are not uncommon and are often caused by lack of proper 2896 access control frameworks, software bugs (such as buffer overflows), 2897 or missing input parsing (such as SQL injection attacks). The risks 2898 of data breaches is increased with the obligation for emergency 2899 services to retain emergency call related data for extended periods 2900 (e.g., several years are the norm). 2902 Finally, it is also worth highlighting the nature of the SIP 2903 communication architecture, which introduces additional complications 2904 for privacy. Some forms of data can be sent by value in the SIP 2905 signaling or by reference (a URL in the SIP signaling). When data is 2906 sent by value, all intermediaries have access to the data. As such, 2907 these intermediaries may also introduce additional privacy risk. 2908 Therefore, in situations where the conveyed information is privacy- 2909 sensitive and intermediaries are involved, transmitting by reference 2910 might be appropriate, assuming the source of the data can operate a 2911 sufficient dereferencing infrastructure and that proper access 2912 control policies are available for distinguishing the different 2913 entities dereferencing the reference. Without access control 2914 policies any party in possession of the reference is able to resolve 2915 the reference and to obtain the data, including intermediaries. 2917 10. IANA Considerations 2919 10.1. Registry creation 2921 This document creates a new registry called 'Emergency Call 2922 Additional Data'. The following sub-registries are created for this 2923 registry. 2925 10.1.1. Provider ID Series Registry 2927 This document creates a new sub-registry called "Additional Call Data 2928 Provider ID Series". As defined in [RFC5226], this registry operates 2929 under "Expert Review" rules. The expert should determine that the 2930 entity requesting a new value is a legitimate issuer of service 2931 provider IDs suitable for use in Additional Call Data. 2933 Private entities issuing or using internally-generated IDs are 2934 encouraged to register here and to ensure that all IDs they issue or 2935 use are unique. This guarantees that IDs issued or used by the 2936 entity are globally unique and distinguishable from other IDs issued 2937 or used by the same or a different entity. (Some organizations, such 2938 as NENA, issue IDs that are unique among all IDs they issue, so an 2939 entity using a combination of its NENA ID and the fact that it is 2940 from NENA is globally unique. Other entities might not have an ID 2941 issued by an organization such as NENA, so they are permitted to use 2942 their domain name, but if so, it needs to be unique.) 2944 The content of this registry includes: 2946 Name: An identifier to be used in the 'ProviderIDSeries' element. 2948 Source: The full name of the organization issuing the identifiers. 2950 URL: A URL to the organization for further information. 2952 The initial set of values is listed in Figure 1. 2954 10.1.2. Service Environment Registry 2956 This document creates a new sub-registry called 'Additional Call 2957 Service Environment'. As defined in [RFC5226], this registry 2958 operates under "Expert Review" rules. The expert should determine 2959 that the entity requesting a new value is relevant for this service 2960 element, and that the new value is distinct from existing values, and 2961 its use is unambiguous. 2963 The content of this registry includes: 2965 Token: The value to be used in the element. 2967 Description: A short description of the value. 2969 The initial set of values is listed in Figure 4. 2971 10.1.3. Service Type Registry 2973 This document creates a new sub-registry called 'Additional Call 2974 Service Type'. As defined in [RFC5226], this registry operates under 2975 "Expert Review" rules. The expert should determine that the entity 2976 requesting a new value is relevant for this service element and that 2977 the requested value is clearly distinct from other values so that 2978 there is no ambiguity as to when the value is to be used or which 2979 value is to be used. 2981 The content of this registry includes: 2983 Name: The value to be used in the element. 2985 Description: A short description of the value. 2987 The initial set of values is listed in Figure 5. 2989 10.1.4. Service Mobility Registry 2991 This document creates a new sub-registry called 'Additional Call 2992 Service Mobility'. As defined in [RFC5226], this registry operates 2993 under "Expert Review" rules. The expert should determine that the 2994 entity requesting a new value is relevant for this service element 2995 and that the requested value is clearly distinct from other values so 2996 that there is no ambiguity as to when the value is to be used or 2997 which value is to be used. 2999 The content of this registry includes: 3001 Token: The value used in the element. 3003 Description: A short description of the value. 3005 The initial set of values is listed in Figure 6. 3007 10.1.5. Service Provider Type Registry 3009 This document creates a new sub-registry called 'Service Provider 3010 Type'. As defined in [RFC5226], this registry operates under "Expert 3011 Review". The expert should determine that the proposed new value is 3012 distinct from existing values and appropriate for use in the 3013 element 3015 The content of this registry includes: 3017 Token: The value used in the element. 3019 Description: A short description of the type of service provider. 3021 The initial set of values is defined in Figure 2. 3023 10.1.6. Device Classification Registry 3025 This document creates a new sub-registry called 'Device 3026 Classification'. As defined in [RFC5226], this registry operates 3027 under "Expert Review" rules. The expert should consider whether the 3028 proposed class is unique from existing classes and the definition of 3029 the class will be clear to implementors and PSAPs/responders. 3031 The content of this registry includes: 3033 Token: Value used in the element. 3035 Description: Short description identifying the device type. 3037 The initial set of values are defined in Figure 8. 3039 10.1.7. Device ID Type Type Registry 3041 This document creates a new sub-registry called 'Additional Call Data 3042 Device ID Type'. As defined in [RFC5226], this registry operates 3043 under "Expert Review" rules. The expert should ascertain that the 3044 proposed type is well understood, and provides information which 3045 PSAPs and responders are able to use to uniquely identify a device. 3046 (For example, a biometric fingerprint used to authenticate a device 3047 would not normally be useful by a PSAP or responder to identify a 3048 device.) 3050 The content of this registry includes: 3052 Token: The value to be placed in the element. 3054 Description: Short description identifying the type of the device 3055 ID. 3057 The initial set of values are defined in Figure 9. 3059 10.1.8. Device/Service Data Type Registry 3061 This document creates a new sub-registry called 'Device/Service Data 3062 Type Registry'. As defined in [RFC5226], this registry operates 3063 under "Specification Required" rules, which include an explicit 3064 expert review. The designated expert should ascertain that the 3065 proposed type is well understood, and provides information useful to 3066 PSAPs and responders. The specification must contain a complete 3067 description of the data, and a precise format specification suitable 3068 to allow interoperable implementations. 3070 The content of this registry includes: 3072 Token: The value to be placed in the element. 3074 Description: Short description identifying the the data. 3076 Specification: Citation for the specification of the data. 3078 The initial set of values are listed in Figure 10. 3080 10.1.9. Emergency Call Data Types Registry 3082 This document creates a new sub-registry called 'Emergency Call Data 3083 Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. 3084 As defined in [RFC5226], this registry operates under "Specification 3085 Required" rules, which include an explicit expert review. The expert 3086 is responsible for verifying that the document contains a complete 3087 and clear specification and the proposed functionality does not 3088 obviously duplicate existing functionality. 3090 The registry contains an entry for every data block that can be sent 3091 with an emergency call using the mechanisms as specified in this 3092 document. Each data block is identified by the "root" of its MIME 3093 subtype (which is the part after 'EmergencyCallData.'). If the MIME 3094 subtype does not start with 'EmergencyCallData.', then it cannot be 3095 registered here nor used in a Call-Info header as specified in this 3096 document. The subtype MAY exist under any MIME type (although most 3097 commonly these are under 'Application/' this is NOT REQUIRED), 3098 however, to be added to the registry the "root" needs to be unique 3099 regardless of the MIME type. 3101 The content of this registry includes: 3103 Token: The root of the data's MIME subtype (not including the 3104 'EmergencyCallData' prefix and any suffix such as '+xml') 3106 Reference: The document that describes the data object 3108 Note that the values from this registry are part of the 3109 'EmergencyCallData' compound value; when used as a value of the 3110 'purpose' parameter of the Call-Info header, the values listed in 3111 this registry are prefixed by 'EmergencyCallData.' per the the 3112 'EmergencyCallData' registation Section 10.2. 3114 The initial set of values are listed in Figure 25. 3116 +----------------+------------+ 3117 | Token | Reference | 3118 +----------------+------------+ 3119 | ProviderInfo | [This RFC] | 3120 | ServiceInfo | [This RFC] | 3121 | DeviceInfo | [This RFC] | 3122 | SubscriberInfo | [This RFC] | 3123 | Comment | [This RFC] | 3124 +----------------+------------+ 3126 Figure 25: Additional Data Blocks Registry 3128 10.2. 'EmergencyCallData' Purpose Parameter Value 3130 This document defines the 'EmergencyCallData' value for the "purpose" 3131 parameter of the Call-Info header field. The Call-Info header and 3132 the corresponding registry for the 'purpose' parameter was 3133 established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData' 3134 is a compound value; when used as a value of the 'purpose' parameter 3135 of the Call-Info header, 'EmergencyCallData' is immediately followed 3136 by a dot ('.') and a value from the 'Emergency Call Data Types' 3137 registry Section 10.1.9. 3139 Header Parameter New 3140 Field Name Value Reference 3141 ---------- --------- ----------------- --------- 3142 Call-Info purpose EmergencyCallData [This RFC] 3144 10.3. URN Sub-Namespace Registration for Registry Entry 3146 This section registers the namespace specified in Section 10.5.1 in 3147 the provided-by registry established by RFC 4119, for usage within 3148 the element of a PIDF-LO. 3150 The schema for the element used by this document is 3151 specified in Section 7.6. 3153 10.4. MIME Registrations 3155 10.4.1. MIME Content-type Registration for 'application/ 3156 EmergencyCallData.ProviderInfo+xml' 3158 This specification requests the registration of a new MIME type 3159 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3160 RFC 7303 [RFC7303]. 3162 MIME media type name: application 3164 MIME subtype name: EmergencyCallData.ProviderInfo+xml 3166 Mandatory parameters: none 3168 Optional parameters: charset (indicates the character encoding of 3169 the contents) 3171 Encoding considerations: Uses XML, which can contain 8-bit 3172 characters, depending on the character encoding. See Section 3.2 3173 of RFC 7303 [RFC7303]. 3175 Security considerations: This content type is designed to carry 3176 the data provider information, which is a sub-category of 3177 additional data about an emergency call. Since this data may 3178 contain personal information, appropriate precautions might be 3179 needed to limit unauthorized access, inappropriate disclosure, and 3180 eavesdropping of personal information. Please refer to Section 8 3181 and Section 9 for more information. 3183 Interoperability considerations: None 3185 Published specification: [TBD: This specification] 3187 Applications which use this media type: Emergency Services 3189 Additional information: 3191 Magic Number: None 3192 File Extension: .xml 3194 Macintosh file type code: 'TEXT' 3196 Person and email address for further information: Hannes 3197 Tschofenig, Hannes.Tschofenig@gmx.net 3199 Intended usage: LIMITED USE 3201 Author: This specification is a work item of the IETF ECRIT 3202 working group, with mailing list address . 3204 Change controller: The IESG 3206 10.4.2. MIME Content-type Registration for 'application/ 3207 EmergencyCallData.ServiceInfo+xml' 3209 This specification requests the registration of a new MIME type 3210 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3211 RFC 7303 [RFC7303]. 3213 MIME media type name: application 3215 MIME subtype name: EmergencyCallData.ServiceInfo+xml 3217 Mandatory parameters: none 3219 Optional parameters: charset (indicates the character encoding of 3220 the contents) 3222 Encoding considerations: Uses XML, which can contain 8-bit 3223 characters, depending on the character encoding. See Section 3.2 3224 of RFC 7303 [RFC7303]. 3226 Security considerations: This content type is designed to carry 3227 the service information, which is a sub-category of additional 3228 data about an emergency call. Since this data may contain 3229 personal information, appropriate precautions may be needed to 3230 limit unauthorized access, inappropriate disclosure, and 3231 eavesdropping of personal information. Please refer to Section 8 3232 and Section 9 for more information. 3234 Interoperability considerations: None 3236 Published specification: [TBD: This specification] 3238 Applications which use this media type: Emergency Services 3239 Additional information: 3241 Magic Number: None 3243 File Extension: .xml 3245 Macintosh file type code: 'TEXT' 3247 Person and email address for further information: Hannes 3248 Tschofenig, Hannes.Tschofenig@gmx.net 3250 Intended usage: LIMITED USE 3252 Author: This specification is a work item of the IETF ECRIT 3253 working group, with mailing list address . 3255 Change controller: The IESG 3257 10.4.3. MIME Content-type Registration for 'application/ 3258 EmergencyCallData.DeviceInfo+xml' 3260 This specification requests the registration of a new MIME type 3261 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3262 RFC 7303 [RFC7303]. 3264 MIME media type name: application 3266 MIME subtype name: EmergencyCallData.DeviceInfo+xml 3268 Mandatory parameters: none 3270 Optional parameters: charset (indicates the character encoding of 3271 the contents) 3273 Encoding considerations: Uses XML, which can contain 8-bit 3274 characters, depending on the character encoding. See Section 3.2 3275 of RFC 7303 [RFC7303]. 3277 Security considerations: This content type is designed to carry 3278 device information, which is a sub-category of additional data 3279 about an emergency call. Since this data contains personal 3280 information, appropriate precautions need to be taken to limit 3281 unauthorized access, inappropriate disclosure to third parties, 3282 and eavesdropping of this information. Please refer to Section 8 3283 and Section 9 for more information. 3285 Interoperability considerations: None 3286 Published specification: [TBD: This specification] 3288 Applications which use this media type: Emergency Services 3290 Additional information: 3292 Magic Number: None 3294 File Extension: .xml 3296 Macintosh file type code: 'TEXT' 3298 Person and email address for further information: Hannes 3299 Tschofenig, Hannes.Tschofenig@gmx.net 3301 Intended usage: LIMITED USE 3303 Author: This specification is a work item of the IETF ECRIT 3304 working group, with mailing list address . 3306 Change controller: The IESG 3308 10.4.4. MIME Content-type Registration for 'application/ 3309 EmergencyCallData.SubscriberInfo+xml' 3311 This specification requests the registration of a new MIME type 3312 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3313 RFC 7303 [RFC7303]. 3315 MIME media type name: application 3317 MIME subtype name: EmergencyCallData.SubscriberInfo+xml 3319 Mandatory parameters: none 3321 Optional parameters: charset (indicates the character encoding of 3322 the contents) 3324 Encoding considerations: Uses XML, which can contain 8-bit 3325 characters, depending on the character encoding. See Section 3.2 3326 of RFC 7303 [RFC7303]. 3328 Security considerations: This content type is designed to carry 3329 owner/subscriber information, which is a sub-category of 3330 additional data about an emergency call. Since this data contains 3331 personal information, appropriate precautions need to be taken to 3332 limit unauthorized access, inappropriate disclosure to third 3333 parties, and eavesdropping of this information. Please refer to 3334 Section 8 and Section 9 for more information. 3336 Interoperability considerations: None 3338 Published specification: [TBD: This specification] 3340 Applications which use this media type: Emergency Services 3342 Additional information: 3344 Magic Number: None 3346 File Extension: .xml 3348 Macintosh file type code: 'TEXT' 3350 Person and email address for further information: Hannes 3351 Tschofenig, Hannes.Tschofenig@gmx.net 3353 Intended usage: LIMITED USE 3355 Author: This specification is a work item of the IETF ECRIT 3356 working group, with mailing list address . 3358 Change controller: The IESG 3360 10.4.5. MIME Content-type Registration for 'application/ 3361 EmergencyCallData.Comment+xml' 3363 This specification requests the registration of a new MIME type 3364 according to the procedures of RFC 6838 [RFC6838] and guidelines in 3365 RFC 7303 [RFC7303]. 3367 MIME media type name: application 3369 MIME subtype name: EmergencyCallData.Comment+xml 3371 Mandatory parameters: none 3373 Optional parameters: charset (indicates the character encoding of 3374 the contents) 3376 Encoding considerations: Uses XML, which can contain 8-bit 3377 characters, depending on the character encoding. See Section 3.2 3378 of RFC 7303 [RFC7303]. 3380 Security considerations: This content type is designed to carry a 3381 comment, which is a sub-category of additional data about an 3382 emergency call. This data may contain personal information. 3383 Appropriate precautions may be needed to limit unauthorized 3384 access, inappropriate disclosure to third parties, and 3385 eavesdropping of this information. Please refer to Section 8 and 3386 Section 9 for more information. 3388 Interoperability considerations: None 3390 Published specification: [TBD: This specification] 3392 Applications which use this media type: Emergency Services 3394 Additional information: 3396 Magic Number: None 3398 File Extension: .xml 3400 Macintosh file type code: 'TEXT' 3402 Person and email address for further information: Hannes 3403 Tschofenig, Hannes.Tschofenig@gmx.net 3405 Intended usage: LIMITED USE 3407 Author: This specification is a work item of the IETF ECRIT 3408 working group, with mailing list address . 3410 Change controller: The IESG 3412 10.5. URN Sub-Namespace Registration 3414 10.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 3416 This section registers a new XML namespace, as per the guidelines in 3417 RFC 3688 [RFC3688]. 3419 URI: urn:ietf:params:xml:ns:EmergencyCallData 3421 Registrant Contact: IETF, ECRIT working group, , as 3422 delegated by the IESG . 3424 XML: 3426 BEGIN 3427 3428 3430 3431 3432 3434 Namespace for Additional Emergency Call Data 3435 3436 3437

Namespace for Additional Data related to an Emergency Call 3438

3439

See [TBD: This document].

3440 3441 3442 END 3444 10.5.2. Registration for 3445 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3447 This section registers a new XML namespace, as per the guidelines in 3448 RFC 3688 [RFC3688]. 3450 URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 3452 Registrant Contact: IETF, ECRIT working group, , as 3453 delegated by the IESG . 3455 XML: 3457 BEGIN 3458 3459 3461 3462 3463 3465 Namespace for Additional Emergency Call Data: 3466 Data Provider Information 3467 3468 3469

Namespace for Additional Data related to an Emergency Call 3470

3471

Data Provider Information

3472

See [TBD: This document].

3473 3474 3475 END 3477 10.5.3. Registration for 3478 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3480 This section registers a new XML namespace, as per the guidelines in 3481 RFC 3688 [RFC3688]. 3483 URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 3485 Registrant Contact: IETF, ECRIT working group, , as 3486 delegated by the IESG . 3488 XML: 3490 BEGIN 3491 3492 3494 3495 3496 3498 Namespace for Additional Emergency Call Data: 3499 Service Information 3500 3501 3502

Namespace for Additional Data related to an Emergency Call 3503

3504

Service Information

3505

See [TBD: This document].

3506 3507 3508 END 3510 10.5.4. Registration for 3511 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3513 This section registers a new XML namespace, as per the guidelines in 3514 RFC 3688 [RFC3688]. 3516 URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 3518 Registrant Contact: IETF, ECRIT working group, , as 3519 delegated by the IESG . 3521 XML: 3523 BEGIN 3524 3525 3527 3528 3529 3531 Namespace for Additional Emergency Call Data: 3532 Device Information 3533 3534 3535

Namespace for Additional Data related to an Emergency Call 3536

3537

Device Information

3538

See [TBD: This document].

3539 3540 3541 END 3543 10.5.5. Registration for 3544 urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3546 This section registers a new XML namespace, as per the guidelines in 3547 RFC 3688 [RFC3688]. 3549 URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 3551 Registrant Contact: IETF, ECRIT working group, , as 3552 delegated by the IESG . 3554 XML: 3556 BEGIN 3557 3558 3560 3561 3562 3564 Namespace for Additional Emergency Call Data: 3565 Owner/Subscriber Information 3566 3567 3568

Namespace for Additional Data related to an Emergency Call 3569

3570

Owner/Subscriber Information

3571

See [TBD: This document].

3572 3573 3574 END 3576 10.5.6. Registration for 3577 urn:ietf:params:xml:ns:EmergencyCallData:Comment 3579 This section registers a new XML namespace, as per the guidelines in 3580 RFC 3688 [RFC3688]. 3582 URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment 3584 Registrant Contact: IETF, ECRIT working group, , as 3585 delegated by the IESG . 3587 XML: 3589 BEGIN 3590 3591 3593 3594 3595 3597 Namespace for Additional Emergency Call Data:Comment 3598 3599 3600 3601

Namespace for Additional Data related to an Emergency Call 3602

3603

Comment

3604

See [TBD: This document].

3605 3606 3607 END 3609 10.6. Schema Registrations 3611 This specification registers five schemas, as per the guidelines in 3612 RFC 3688 [RFC3688]. 3614 URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo 3616 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3617 delegated by the IESG (iesg@ietf.org). 3619 XML: The XML schema can be found in Figure 19. 3621 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3623 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 3624 delegated by the IESG (iesg@ietf.org). 3626 XML: The XML schema can be found in Figure 20. 3628 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3630 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3631 delegated by the IESG (iesg@ietf.org). 3633 XML: The XML schema can be found in Figure 21. 3635 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3636 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3637 delegated by the IESG (iesg@ietf.org). 3639 XML: The XML schema can be found in Section 7.4. 3641 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3643 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3644 delegated by the IESG (iesg@ietf.org). 3646 XML: The XML schema can be found in Section 7.5. 3648 10.7. VCard Parameter Value Registration 3650 This document registers a new value in the vCARD Parameter Values 3651 registry as defined by [RFC6350] with the following template: 3653 Value: main 3655 Purpose: The main telephone number, typically of an enterprise, as 3656 opposed to a direct dial number of an individual employee 3658 Conformance: This value can be used with the "TYPE" parameter 3659 applied on the "TEL" property. 3661 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3662 00 3664 11. Acknowledgments 3666 This work was originally started in NENA and has benefitted from a 3667 large number of participants in NENA standardization efforts, 3668 originally in the Long Term Definition Working Group, the Data 3669 Technical Committee and most recently the Additional Data working 3670 group. The authors are grateful for the initial work and extended 3671 comments provided by many NENA participants, including Delaine 3672 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3673 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 3674 and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank 3675 Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback 3676 regarding the vCard/xCard use in this specification. 3678 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3679 Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris 3680 Santer, and Archie Cobbs for their review comments. Alissa Cooper 3681 and Guy Caron deserves special mention for their detailed and 3682 extensive review comments, which were very helpful and appreciated. 3684 12. References 3686 12.1. Normative References 3688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3689 Requirement Levels", BCP 14, RFC 2119, March 1997. 3691 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3692 Locators", RFC 2392, August 1998. 3694 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3695 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3696 and QSIG Objects", RFC 3204, December 2001. 3698 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3699 A., Peterson, J., Sparks, R., Handley, M., and E. 3700 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3701 June 2002. 3703 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3704 Extensions (MIME) Parameter", RFC 3459, January 2003. 3706 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3707 January 2004. 3709 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3710 3966, December 2004. 3712 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3713 Format", RFC 4119, December 2005. 3715 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3716 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3717 May 2008. 3719 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3720 October 2008. 3722 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3723 Initiation Protocol (SIP)", RFC 5621, September 2009. 3725 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3726 Languages", BCP 47, RFC 5646, September 2009. 3728 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3729 August 2011. 3731 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3732 6351, August 2011. 3734 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3735 Specifications and Registration Procedures", BCP 13, RFC 3736 6838, January 2013. 3738 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 3739 July 2014. 3741 12.2. Informational References 3743 [I-D.gellens-slim-negotiating-human-language] 3744 Randy, R., "Negotiating Human Language in Real-Time 3745 Communications", draft-gellens-slim-negotiating-human- 3746 language-00 (work in progress), October 2014. 3748 [LanguageTagRegistry] 3749 IANA, "Language Subtag Registry", Feb 2015. 3751 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3752 Extensions to the Session Initiation Protocol (SIP) for 3753 Asserted Identity within Trusted Networks", RFC 3325, 3754 November 2002. 3756 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3757 "Indicating User Agent Capabilities in the Session 3758 Initiation Protocol (SIP)", RFC 3840, August 2004. 3760 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 3761 Emergency Context Resolution with Internet Technologies", 3762 RFC 5012, January 2008. 3764 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3765 Format for Presence Information Data Format Location 3766 Object (PIDF-LO)", RFC 5139, February 2008. 3768 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3769 Presence Information Data Format Location Object (PIDF-LO) 3770 Usage Clarification, Considerations, and Recommendations", 3771 RFC 5491, March 2009. 3773 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 3774 Framework", RFC 5582, September 2009. 3776 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3777 Thomson, "Dynamic Extensions to the Presence Information 3778 Data Format Location Object (PIDF-LO)", RFC 5962, 3779 September 2010. 3781 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3782 5985, September 2010. 3784 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3785 "Framework for Emergency Calling Using Internet 3786 Multimedia", RFC 6443, December 2011. 3788 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3789 R. George, "Specifying Civic Address Extensions in the 3790 Presence Information Data Format Location Object (PIDF- 3791 LO)", RFC 6848, January 2013. 3793 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3794 Communications Services in Support of Emergency Calling", 3795 BCP 181, RFC 6881, March 2013. 3797 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3798 Morris, J., Hansen, M., and R. Smith, "Privacy 3799 Considerations for Internet Protocols", RFC 6973, July 3800 2013. 3802 [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3803 Thomson, "Relative Location Representation", RFC 7035, 3804 October 2013. 3806 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3807 Patel, "Public Safety Answering Point (PSAP) Callback", 3808 RFC 7090, April 2014. 3810 12.3. URIs 3812 [1] http://www.nena.org/?page=cid2014 3814 [2] http://www.nena.org/?page=CompanyID 3816 Appendix A. XML Schema for vCard/xCard 3818 This section contains the vCard/xCard XML schema version of the Relax 3819 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3820 XML schemas defined in this document. The schema in RFC 6351 3821 [RFC6351] is the normative source and this section is informative 3822 only. 3824 3825 3829 3835 3836 3837 vCard Format Specification 3838 3839 3840 3841 3842 3843 3844 3845 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3860 3861 3862 3864 3865 3866 3867 3868 3870 3871 3872 3874 3875 3876 3877 3878 3880 3881 3882 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3926 3927 3928 3929 3933 3934 3935 Section 5: Parameters 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 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 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 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 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 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 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 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 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4859 4860 4861 4862 4863 4864 4865 4867 4868 4869 4870 4871 4872 4873 4875 4876 4877 4879 4881 4882 4883 4885 4886 4887 4888 4890 Appendix B. XML Validation 4892 This document defines a number of XML schemas and contains various 4893 examples. Extracting the XML and validating the examples against the 4894 schemas can be challenging, especially due to the formatting 4895 limitations introduced by IETF RFCs. For those readers who copy the 4896 XML schemas and examples directly from this document, please consider 4897 that errors might be introduced due to line breaks and extra 4898 whitespaces in the regular expressions contained in the vcard schema 4899 in Appendix A. To validate the PIDF-LO from Figure 18 it is also 4900 necessary to consult the referenced RFCs and copy the schemas 4901 necessary for successful validation. 4903 The XML schemas found in this document include a 'SchemaLocation' 4904 attribute. Depending on the location of the downloaded schema files 4905 you may need to adjust this schema location or configure your XML 4906 editor to point to the location. 4908 For convience of readers we have put all schemas and XML examples at 4909 http://ip-emergency.net/additional-data.zip 4911 Authors' Addresses 4913 Randall Gellens 4914 Qualcomm Technologies, Inc. 4915 5775 Morehouse Drive 4916 San Diego, CA 92121 4917 US 4919 Email: rg+ietf@qti.qualcomm.com 4921 Brian Rosen 4922 NeuStar 4923 470 Conrad Dr. 4924 Mars, PA 16046 4925 US 4927 Phone: +1 724 382 1051 4928 Email: br@brianrosen.net 4929 Hannes Tschofenig 4930 Hall in Tirol 6060 4931 Austria 4933 Email: Hannes.tschofenig@gmx.net 4934 URI: http://www.tschofenig.priv.at 4936 Roger Marshall 4937 TeleCommunication Systems, Inc. 4938 2401 Elliott Avenue 4939 Seattle, WA 98121 4940 US 4942 Phone: +1 206 792 2424 4943 Email: rmarshall@telecomsys.com 4944 URI: http://www.telecomsys.com 4946 James Winterbottom 4947 AU 4949 Email: a.james.winterbottom@gmail.com