idnits 2.17.00 (12 Aug 2021) /tmp/idnits13310/draft-ietf-ecrit-additional-data-10.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 25 instances of too long lines in the document, the longest one being 9 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 1740 has weird spacing: '...element name=...' == Line 2206 has weird spacing: '...ll-Info pur...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 15, 2013) is 3231 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) == Missing Reference: 'This RFC' is mentioned on line 2206, but not defined == Unused Reference: 'RFC5985' is defined on line 2798, but no explicit reference was found in the text == Unused Reference: 'RFC6443' is defined on line 2801, but no explicit reference was found in the text == Unused Reference: 'RFC6881' is defined on line 2810, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 == Outdated reference: draft-ietf-geopriv-relative-location has been published as RFC 7035 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 16, 2014 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 J. Winterbottom 12 July 15, 2013 14 Additional Data related to an Emergency Call 15 draft-ietf-ecrit-additional-data-10.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 may have information about the call, the 23 caller or the location which the PSAP may be able to use. This 24 document describes data structures and a mechanism to convey such 25 data to the PSAP. The mechanism uses a Uniform Resource Identifier 26 (URI), which may point to either an external resource or an object in 27 the body of the SIP message. The mechanism thus allows the data to 28 be passed by reference (when the URI points to an external resource) 29 or by value (when it points into the body of the message). This 30 follows the tradition of prior emergency services standardization 31 work where data can be conveyed by value within the call signaling 32 (i.e., in body of the SIP message) and also by reference. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 16, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 71 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7 72 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 73 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 74 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 75 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9 76 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10 77 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10 78 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11 79 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 11 80 3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12 81 3.2. Service Information . . . . . . . . . . . . . . . . . . . 14 82 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14 83 3.2.2. Service Delivered by Provider to End User . . . . . . 15 84 3.2.3. Service Mobility Environment . . . . . . . . . . . . 16 85 3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17 86 3.3. Device Information . . . . . . . . . . . . . . . . . . . 17 87 3.3.1. Device Classification . . . . . . . . . . . . . . . . 17 88 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 18 89 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19 90 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 19 91 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 19 92 3.3.6. Device/Service Specific Additional Data Structure . . 20 93 3.3.7. Device/Service Specific Additional Data Structure 94 Type . . . . . . . . . . . . . . . . . . . . . . . . 21 95 3.3.8. Choosing between defining a new type of block or new 96 type of device/service specific additional data . . . 21 97 3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22 98 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 22 99 3.4.1. xCard for Subscriber's Data . . . . . . . . . . . . . 22 100 3.4.2. emergencyCall.SubInfo Example . . . . . . . . . . . . 23 101 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 25 103 3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 26 104 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 4.1. Transmitting Blocks using the Call-Info Header . . . . . 28 106 4.2. Transmitting Blocks by Reference using the Provided-By 107 Element . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 4.3. Transmitting Blocks by Value using the Provided-By 109 Element . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 30 111 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 34 114 6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 36 115 6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 36 116 6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 37 117 6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 38 118 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 39 119 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 120 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 122 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 44 123 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 44 124 9.1.2. Service Provider Type Registry . . . . . . . . . . . 45 125 9.1.3. Service Delivered Registry . . . . . . . . . . . . . 45 126 9.1.4. Device Classification Registry . . . . . . . . . . . 45 127 9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 46 128 9.1.6. Device/Service Data Type Registry . . . . . . . . . . 46 129 9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 47 130 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 47 131 9.3. URN Sub-Namespace Registration for provided-by Registry 132 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 48 133 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 48 134 9.4.1. MIME Content-type Registration for 135 'application/emergencyCall.ProviderInfo+xml' . . . . 48 136 9.4.2. MIME Content-type Registration for 137 'application/emergencyCall.SvcInfo+xml' . . . . . . . 49 138 9.4.3. MIME Content-type Registration for 139 'application/emergencyCall.DevInfo+xml' . . . . . . . 50 140 9.4.4. MIME Content-type Registration for 141 'application/emergencyCall.SubInfo+xml' . . . . . . . 51 142 9.4.5. MIME Content-type Registration for 143 'application/emergencyCall.Comment+xml' . . . . . . . 52 145 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 53 146 9.5.1. Registration for 147 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 53 148 9.5.2. Registration for 149 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 53 150 9.5.3. Registration for 151 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 54 152 9.5.4. Registration for 153 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 55 154 9.5.5. Registration for 155 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 56 156 9.5.6. Registration for 157 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 56 158 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 57 159 9.7. VCard Parameter Value Registration . . . . . . . . . . . 58 160 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 161 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 162 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 163 11.2. Informational References . . . . . . . . . . . . . . . . 60 164 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 61 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 167 1. Introduction 169 When an IP-based emergency call is initiated a rich set of data from 170 multiple data sources is conveyed to the Public Safety Answering 171 Point (PSAP). This data includes information about the calling party 172 identity, the multimedia capabilities of the device, the emergency 173 service number, location information, and meta-data about the sources 174 of the data. The device, the access network provider, and any 175 service provider in the call path have even more information useful 176 for a PSAP call taker. This document extends the basic set of data 177 communicated with an IP-based emergency call providing call takers 178 and the PSAP organization valuable insight and increased situational 179 awareness. 181 In general, there are three categories of data communicated in an 182 emergency call: 184 Data Associated with a Location: Location data is conveyed in the 185 Presence Information Data Format Location Object (PIDF-LO) data 186 structure originally defined in RFC 4119 [RFC4119] and extended by 187 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 188 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 189 geodetic location information), and 190 [I-D.ietf-geopriv-relative-location] (for relative location). 191 There may be data that is specific to the location not available 192 in the location data structure itself, such as floor plans, tenant 193 and building owner contact data, heating, ventilation and air 194 conditioning (HVAC) status, etc. 196 Data Associated with a Call: While information is carried in the 197 call setup procedure itself (as part of the SIP headers as well as 198 in the body of the SIP message), there is additional data known by 199 the device making the call, and the service provider along the 200 path of the call. This information may include the service 201 provider contact information, subscriber identity and contact 202 information, the type of service the service provider and the 203 access network provider offer, what kind of device is being used, 204 etc. Some data is device or service dependent data. For example, 205 a car telematics system may have crash information. A medical 206 monitoring device may have sensor data. 208 Data Associated with a Caller: This is personal data about a caller, 209 such as medical information and emergency contact data. 211 This document only defines data structures relevant to data 212 associated with the call but defines extension points for other data 213 to be added via other specifications. 215 For interoperability, there needs to be a common way for the 216 information conveyed to a PSAP to be encoded and identified. 217 Identification allows emergency services authorities to know during 218 call processing which types of data are present and to determine if 219 they wish to access it. A common encoding allows the data to be 220 accessed. 222 This document defines the data structures and a way to communicate 223 the information in several ways. Although current standardization 224 efforts around IP-based emergency services are focused on the Session 225 Initiation Protocol (SIP) and HTTP the data structures in XML format 226 described in this document are usable for other communication systems 227 as well. In Section 3 the data structures are defined and the SIP/ 228 HTTP transport components are defined in Section 4 to offer a clear 229 separation between the two. 231 More technically, the data structure described in this document is 232 represented as one or more "blocks" of information. Each of the 233 blocks is an XML structure with an associated Multipurpose Internet 234 Mail Extensions (MIME) type for encapsulation, and an extensible set 235 of these types constitute the data set. A registry is defined to 236 list the block types that may be included. 238 2. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in RFC 2119 [RFC2119]. 243 This document also uses terminology from [RFC5012]. We use the term 244 service provider to refer to an Application Service Provider (ASP). 245 A Voice Service Provider (VSP) is a special type of ASP. With the 246 term "Access Network Provider" we refer to the Internet Access 247 Provider (IAP) and the Internet Service Provider (ISP) without 248 further distinguishing these two entities, since the difference 249 between the two is not relevant for this document. Note that the 250 roles of ASP and access network provider may be provided by a single 251 company. 253 In the data block definitions, see Section 3, the values for the 254 "Use:" label are specified as one of: 256 'Required': means they must be present in the data structure. 258 'Conditional': means they must be present unless the specified 259 condition is met, in which case the they may be present. 261 'Optional': means they may be present. 263 vCard is a data format for representing and exchanging a variety of 264 information about individuals and other entities. For applications 265 that use XML the format defined in vCard is not immediately 266 applicable. For this purpose an XML-based encoding of the 267 information elements defined in the vCard specification has been 268 defined and the name of that specification is xCard. Since the term 269 vCard is more familiar to most readers we use the term xCard and 270 vCard interchangeable but it would be accurate to use the term vCard 271 only. 273 3. Data Structures 275 This section defines the following five data structures, each as a 276 data block. For each block we define the MIME type, and the XML data 277 structure. The five data structures are: 279 'Data Provider': This block supplies name and contact information 280 for the entity that created the data. Section 3.1 provides the 281 details. 283 'Service Information': This block supplies information about the 284 service. The description can be found in Section 3.2. 286 'Device Information': This block supplies information about the 287 device placing the call. Device information can be found in 288 Section 3.3. 290 'Owner/Subscriber': This block supplies information about the owner 291 of the device or about the subscriber. Details can be found in 292 Section 3.4. 294 'Comment': This block provides a way to supply free form human 295 readable text to the PSAP or emergency responders. This simple 296 structure is defined in Section 3.5. 298 Note that the xCard format is re-used in some of the data structures 299 to provide contact information. In an xCard there is no way to 300 specify a "main" telephone number. These numbers are useful to 301 emergency responders who are called to a large enterprise. This 302 document adds a new property value to the "tel" property of the TYPE 303 parameter called "main". It can be used in any xCard in additional 304 data. 306 3.1. Data Provider Information 308 This block is intended to be provided by any service provider in the 309 path of the call or the access network provider. It includes 310 identification and contact information. This block SHOULD be 311 provided by every service provider in the call path, and by the 312 access network provider. Devices MAY use this block to provide 313 identifying information. The MIME subtype is "application/ 314 emergencyCall.ProviderInfo+xml". 316 3.1.1. Data Provider String 318 Data Element: Data Provider String 320 Use: Required 322 XML Element: 324 Description: This is a plain language string suitable for displaying 325 the name of the service provider that created the additional data 326 structure. If the device created the structure the value is 327 identical to the contact header in the SIP INVITE. 329 Reason for Need: Inform the call taker of the identity of the entity 330 providing the additional call data structure. 332 How Used by Call Taker: Allows the call taker to interpret the data 333 in this structure. The source of the information often influences 334 how the information is used, believed or verified. 336 3.1.2. Data Provider ID 338 Data Element: Data Provider ID 340 Use: Conditional. Must be provided if the service provider is 341 located in a jurisdiction that maintains such ids. Devices are 342 not required to provide it. 344 XML Element: 346 Description: A jurisdiction specific code for the provider shown in 347 the element that created the structure of the 348 call. This data SHOULD be provided if the local jurisdiction 349 maintains such an ID list. For example, in North America, this 350 would be a "NENA Company ID". Devices SHOULD NOT use this 351 element. 353 Reason for Need: Inform the call taker of the identity of the entity 354 providing the additional call data structure. 356 How Used by Call Taker: Where jurisdictions have lists of providers 357 the Data Provider ID can be useful. 359 3.1.3. Data Provider ID Series 361 Data Element: Data Provider ID Series 363 Use: Conditional. If Data Provider ID is provided, Data Provider ID 364 Series is required. 366 XML Element: 368 Description: Identifies the issuer of the ProviderId. A registry 369 will reflect the following valid entries: 371 * NENA 373 * EENA 375 Reason for Need: Identifies how to interpret the Data Provider ID. 377 How Used by Call Taker: Determines which provider ID registry to 378 consult for more information 380 3.1.4. Type of Data Provider 382 Data Element: Type of Data Provider ID 384 Use: Conditional. If Data Provider ID is provided, Type of Data 385 Provider ID is required. 387 XML Element: 389 Description: Identifies the type of data provider id being supplied 390 in the ProviderId data element. A registry with an initial set of 391 values is shown in Figure 1. 393 +------------------------------+------------------------------------+ 394 | Token | Description | 395 +------------------------------+------------------------------------+ 396 |Access Network Provider | Access network service provider | 397 |Service Provider | Calling or Origination telecom SP | 398 |Service Provider Subcontractor| A contractor to another kind of SP | 399 |Telematics Provider | A sensor based SP, especially | 400 | | vehicle based | 401 |Language Translation Provider | A spoken language translation SP | 402 |Expert Advice Provider | An SP giving expert advice | 403 |Emergency Modality Translation| An emergency call specific | 404 | | modality translation service | 405 | | e.g. for sign language | 406 |Relay Provider | A interpretation SP, for example, | 407 | | video relay for sign language | 408 | | interpreting | 409 |Other | Any other type of service provider | 410 +------------------------------+------------------------------------+ 412 Figure 1: Type of Data Provider ID Registry 414 Reason for Need: Identifies what kind of data provider this is. 416 How Used by Call Taker: To decide who to contact when further 417 information is needed 419 3.1.5. Data Provider Contact URI 421 Data Element: Data Provider Contact URI 423 Use: Required 425 XML Element: 426 Description: For a service provider the contact SHOULD be a contact 427 URI. This MUST be a SIP URI. If a telephone number is the 428 contact address it should be provided in the form of 429 sip:telephonenumber@serviceprovider:user=phone. If the call is 430 from a device, this would reflect the contact information of the 431 owner of the device. When provided by a service provider, this 432 would be a URI to a 24/7 support organization tasked to provide 433 PSAP support for this emergency call. 435 Reason for Need: Additional data providers may need to be contacted 436 for error or other unusual circumstances. 438 How Used by Call Taker: To contact the supplier of the additional 439 data for assistance in handling the call. 441 3.1.6. Data Provider Languages(s) Supported 443 Data Element: Data Provider Language(s) supported 445 Use: Conditional 447 XML Element: 449 Description: The language used by the entity at the Data Provider 450 Contact URI as an alpha 2-character code as defined in ISO 451 639-1:2002 Codes for the representation of names of languages -- 452 Part 1: Alpha-2 code Multiple instances of this element may occur. 453 Order is significant; preferred language should appear first. 454 This data is required if a Data Provider Contact URI is provided. 455 The content must reflect the languages supported at the contact 456 URI. 458 Reason for Need: Information needed to determine if emergency 459 service authority can communicate with the service provider or if 460 an interpreter will be needed. 462 How Used by Call Taker: If call taker cannot speak language(s) 463 supported by the service provider, a translation service will need 464 to be added to the conversation. 466 3.1.7. xCard of Data Provider 468 Data Element: xCard of Data Provider 470 Use: Optional 472 XML Element: 473 Description: There are many fields in the xCard and the creator of 474 the data structure is encouraged to provide as much information as 475 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 476 minimum. N should contain name of support group or device owner 477 as appropriate. If more than one TEL property is provided, a 478 parameter from the vCard Property Value registry MUST be specified 479 on each TEL. For encoding of the xCard this specification uses 480 the XML-based encoding specified in [RFC6351]. and is hereinafter 481 referred to as "xCard" 483 Reason for Need: Information needed to determine additional contact 484 information. 486 How Used by Call Taker: Assists call taker by providing additional 487 contact information that may not be included in the SIP invite or 488 the PIDF-LO. 490 3.1.8. Subcontractor Principal 492 Data Element: Subcontractor Principal 494 XML Element: 496 Description: If the data provider is a subcontractor to another 497 provider such as an access infrastructure provider or telematics 498 provider, this element contains the DataProviderString of the 499 service provider to indicate which provider the subcontractor is 500 working for. This data is required if the Data Provider type is 501 subcontractor. 503 Reason for Need: Identify the entity the subcontractor works for. 505 How Used by Call Taker: Allows the call taker to understand what the 506 relationship between data providers and the service providers in 507 the path of the call are. 509 3.1.9. Subcontractor Priority 511 Data Element: Subcontractor Priority 513 Use: Required 515 XML Element: 516 Description: If the subcontractor should be contacted first, this 517 element should have a "sub" value. If the access or origination 518 service provider should be contacted first, this element should 519 have a "main" value. This data is required if the Data Provider 520 type is "subcontractor". 522 Reason for Need: Inform the call taker whether the network operator 523 or the subcontractor should be contacted first if support is 524 needed. 526 How Used by Call Taker: To decide which entity to contact first if 527 assistance is needed. 529 3.1.10. emergencyCall.ProviderInfo Example 531 532 535 Example VoIP Provider 536 537 urn:nena:companyid:ID123 538 NENA 539 Service Provider 540 sip:voip-provider@example.com 541 EN 542 544 545 Hannes Tschofenig 546 547 Hannes 548 Tschofenig 549 550 551 Dipl. Ing. 552 553 --0203 554 555 20090808T1430-0500 556 557 M 558 559 1 560 561 de 562 563 564 2 565 566 en 567 568 569 work 570 571 Example VoIP Provider 572 573 574 575 work 576 580 581 582 583 Linnoitustie 6 584 Espoo 585 Uusimaa 586 02600 587 Finland 588 589 590 591 592 work 593 voice 594 595 596 tel:+358 50 4871445 597 598 599 work 600 601 hannes.tschofenig@nsn.com 602 603 604 work 605 606 geo:60.210796,24.812924 607 608 609 home 610 611 612 http://www.tschofenig.priv.at/key.asc 613 614 615 Finland/Helsinki 616 617 home 618 619 http://www.tschofenig.priv.at 620 621 622 623 625 Figure 2: emergencyCall.ProviderInfo Example 627 3.2. Service Information 629 This block describes the service that the service provider provides 630 to the caller. It SHOULD be included by all SPs in the path of the 631 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 633 3.2.1. Service Environment 635 Data Element: Service Environment 637 Use: Required 639 XML Element: 641 Description: This element defines whether a call is from a business 642 or residence caller. Currently, the only valid entries are 643 'Business' or 'Residence'. 645 Reason for Need: To assist in determining equipment and manpower 646 requirements. 648 How Used by Call Taker: Information may be used to assist in 649 determining equipment and manpower requirements for emergency 650 responders. As the information is not always available, and the 651 registry is not all encompassing, this is at best advisory 652 information, but since it mimics a similar capability in some 653 current emergency calling systems, it is known to be valuable. 654 The service provider uses its best information (such as a rate 655 plan, facilities used to deliver service or service description) 656 to determine the information and is not responsible for 657 determining the actual characteristics of the location where the 658 call originates from. 660 3.2.2. Service Delivered by Provider to End User 662 Data Element: Service Delivered by Provider to End User 664 Use: Required 666 XML Element: 668 Description: This defines the type of service the end user has 669 subscribed to. The implied mobility of this service cannot be 670 relied upon. A registry with an initial set of values is defined 671 in Figure 3. 673 +--------+----------------------------------------+ 674 | Name | Description | 675 +--------+----------------------------------------+ 676 | Wrless | Wireless Telephone Service: Includes | 677 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 678 | | LTE (Long Term Evolution) | 679 | Coin | Fixed Public Pay/Coin telephones: Any | 680 | | coin or credit card operated device | 681 | 1way | One way outbound service | 682 | Prison | Inmate call/service | 683 | Temp | Soft dialtone/quick service/warm | 684 | | disconnect/suspended | 685 | MLTS | Multi-line telephone system: Includes | 686 | | all PBX, Centrex, key systems, | 687 | | Shared Tenant Service | 688 | SenseU | Sensor, unattended: Includes devices | 689 | | that generate DATA ONLY. This is | 690 | | one-way information exchange and | 691 | | there will be no other form of | 692 | | communication | 693 | SenseA | Sensor, attended: Includes devices | 694 | | that are supported by a monitoring | 695 | | service provider or automatically | 696 | | open a two-way communication path | 697 | POTS | Wireline: Plain Old Telephone Service | 698 | VOIP | VoIP Telephone Service: A type of | 699 | | service that offers communication | 700 | | over internet protocol, such as Fixed| 701 | | Nomadic, Mobile, ... | 702 | Remote | Off premise extension | 703 | Relay | Relay Service: a type of service where | 704 | | there is a human 3rd party agent who | 705 | | provides some kind of additional | 706 | | assistance to the caller. Includes | 707 | | sign language relay and telematics | 708 | | services which provide a service | 709 | | assistant on the call. | 710 +--------+----------------------------------------+ 712 Figure 3: Service Delivered by Provider to End User Registry 714 More than one value MAY be returned. For example, a VoIP inmate 715 telephone service is a reasonable combination. 717 Reason for Need: Knowing the type of service may assist the PSAP 718 with the handling of the call. 720 How Used by Call Taker: Call takers often use this information to 721 determine what kinds of questions to ask callers, and how much to 722 rely on supportive information. An emergency call from a prison 723 is treated differently that a call from a sensor device. As the 724 information is not always available, and the registry is not all 725 encompassing, this is at best advisory information, but since it 726 mimics a similar capability in some current emergency calling 727 systems, it is known to be valuable. 729 3.2.3. Service Mobility Environment 731 Data Element: Service Mobility Environment 733 Use: Required 735 XML Element: 737 Description: This provides the service providers view of the 738 mobility of the caller. As the service provider may not know the 739 characteristics of the actual access network used, the value not 740 be relied upon. A registry will reflect the following initial 741 valid entries: 743 * Mobile: the device should be able to move at any time 745 * Fixed: the device is not expected to move unless the service is 746 relocated 748 * Nomadic: the device is not expected to change its point of 749 attachment while on a call 751 * Unknown: no information is known about the service mobility 752 environment for the device 754 Reason for Need: Knowing the service provider's belief of mobility 755 may assist the PSAP with the handling of the call. 757 How Used by Call Taker: To determine whether to assume the location 758 of the caller might change. 760 3.2.4. emergencyCall.SvcInfo Example 762 763 766 Business 767 MLTS 768 Fixed 769 771 Figure 4: emergencyCall.SvcInfo Example 773 3.3. Device Information 775 This block provides information about the device used to place the 776 call. It should be provided by any service provider that knows what 777 device is being used, and by the device itself. The mime subtype is 778 "application/emergencyCall.DevInfo+xml". 780 3.3.1. Device Classification 782 Data Element: Device Classification 784 Use: Optional 786 XML Element: 788 Description: This data element defines the kind of device making the 789 emergency call. If the device provides the data structure, the 790 device information SHOULD be provided. If the service provider 791 provides the structure and it knows what the device is, the 792 service provider SHOULD provide the device information. Often the 793 carrier does not know what the device is. It is possible to 794 receive two Additional Data Associated with a Call data 795 structures, one created by the device and one created by the 796 service provider. This information describes the device, not how 797 it is being used. This data element defines the kind of device 798 making the emergency call. The registry with the initial set of 799 values is shown in Figure 5. 801 +--------+----------------------------------------+ 802 | Token | Description | 803 +--------+----------------------------------------+ 804 |Cordless| Cordless handset | 805 | Fixed | Fixed phone | 806 | Mobile | Mobile handset | 807 | ATA | analog terminal adapter | 808 |Satphone| Satellite phone | 809 | FSense | Stationary computing device (alarm | 810 | | system, data sensor) | 811 | Guard | Guardian devices | 812 | Desktop| Desktop PC | 813 | Laptop | Laptop computing device | 814 | Tablet | Tablet computing device | 815 | Alarm | Alarm system | 816 | MSense | Mobile Data sensor | 817 | Beacon | Personal beacons (spot) | 818 | Auto | Auto telematics | 819 | Truck | Truck telematics | 820 | Farm | Farm equipment telematics | 821 | Marine | Marine telematics | 822 | PDA | Personal digital assistant | 823 | PND | Personal navigation device) | 824 | SmrtPhn| Smart phone | 825 | Itab | Internet tablet | 826 | Game | Gaming console | 827 | Video | Video phone | 828 | Text | Other text device | 829 | NA | Not Available | 830 +--------+----------------------------------------+ 832 Figure 5: Device Classification Registry 834 Reason for Need: The device classification implies the capability of 835 the calling device and assists in identifying the meaning of the 836 emergency call location information that is being presented. For 837 example, does the device require human intervention to initiate a 838 call or is this call the result of programmed instructions? Does 839 the calling device have the ability to update location or 840 condition changes? Is this device interactive or a one-way 841 reporting device? 843 How Used by Call Taker: May assist with location of caller. For 844 example, a cordless handset may be outside or next door. May 845 provide the calltaker some context about the caller, the 846 capabilities of the device used for the call or the environment 847 the device is being used in. 849 3.3.2. Device Manufacturer 851 Data Element: Device Manufacturer 852 Use: Optional 854 XML Element: 856 Description: The plain language name of the manufacturer of the 857 device. 859 Reason for Need: Used by PSAP management for post-mortem 860 investigation/resolution. 862 How Used by Call Taker: Probably not used by the calltaker, but by 863 PSAP management. 865 3.3.3. Device Model Number 867 Data Element: Device Model Number 869 Use: Optional 871 XML Element: 873 Description: Model number of the device. 875 Reason for Need: Used by PSAP management for after action 876 investigation/resolution. 878 How Used by Call Taker: Probably not used by the calltaker, but by 879 PSAP management. 881 3.3.4. Unique Device Identifier 883 Data Element: Unique Device Identifier 885 Use: Optional 887 XML Element: 889 Description: String that identifies the specific device making the 890 call or creating an event. 892 Reason for Need: Uniquely identifies the device as opposed to any 893 signaling identifiers encountered in the call signaling stream. 895 How Used by Call Taker: Probably not used by the calltaker they 896 would need to refer to management for investigation. 898 3.3.5. Type of Device Identifier 899 Data Element: Type of Device Identifier 901 Use: Conditional: must be provided if the DeviceID is provided 903 XML Element: 905 Description: Identifies the type of device identifier being 906 generated in the unique device identifier data element. A 907 registry with an initial set of values can be seen in Figure 6. 909 +--------+----------------------------------------+ 910 | Token | Description | 911 +--------+----------------------------------------+ 912 | MEID | Mobile Equipment Identifier (CDMA) | 913 | ESN | Electronic Serial Number(GSM) | 914 | MAC | Media Access Control Address (IEEE) | 915 | WiMAX | Device Certificate Unique ID | 916 | IMEI | International Mobile Equipment ID (GSM)| 917 | UDI | Unique Device Identifier | 918 | RFID | Radio Frequency Identification | 919 | SN | Manufacturer Serial Number | 920 +--------+----------------------------------------+ 922 Figure 6: Registry with Device Identifier Types 924 Reason for Need: Identifies how to interpret the Unique Device 925 Identifier. 927 How Used by Call Taker: Additional information that may be used to 928 assist with call handling. 930 3.3.6. Device/Service Specific Additional Data Structure 932 Data Element: Device/service specific additional data structure 934 Use: Optional 936 XML Element: 938 Description: A URI representing additional data whose schema is 939 specific to the device or service which created it. An example is 940 the VEDs structure for a vehicle telematics device. The URI, when 941 dereferenced, MUST yield a data structure defined by the Device/ 942 service specific additional data type value. Different data may 943 be created by each classification; e.g., telematics creates VEDS 944 data set. 946 Reason for Need: Provides device/service specific data that may be 947 used by the call taker and/or responders. 949 How Used by Call Taker: Provide information to guide call takers to 950 select appropriate responders, give appropriate pre-arrival 951 instructions to callers, and advise responders of what to be 952 prepared for. May be used by responders to guide assistance 953 provided. 955 3.3.7. Device/Service Specific Additional Data Structure Type 957 Data Element: Type of Device/service specific additional data 958 structure 960 Use: Conditional. MUST be provided when Device/service specific 961 additional URI is provided 963 XML Element: 965 Description: Value from a registry defined by this document to 966 describe the type of data that can be retrieved from the Device/ 967 service specific additional data structure. Initial values are: 969 * IEEE 1512 - USDOT Model for traffic incidents 971 * VEDS 973 Reason for Need: This data element allows identification of 974 externally defined schemas, which may have additional data that 975 may assist in emergency response. 977 How Used by Call Taker: This data element allows the end user 978 (calltaker or first responder) to know what type of additional 979 data may be available to aid in providing the needed emergency 980 services. 982 Note: Information which is specific to a location or a caller 983 (person) should not be placed in this section. 985 3.3.8. Choosing between defining a new type of block or new type of 986 device/service specific additional data 988 For devices that have device or service specific data, there are two 989 choices to carry it. A new block can be defined, or the device/ 990 service specific additional data URL the DevInfo block can be used 991 and a new type for it defined . The data passed would likely be the 992 same in both cases. Considerations for choosing which mechanism to 993 register under include: 995 Applicability: Information which will be carried by many kinds of 996 devices or services are more appropriately defined as separate 997 blocks. 999 Privacy: Information which may contain private data may be better 1000 sent in the DevInfo block, rather than a new block so that 1001 implementations are not tempted to send the data by value, and 1002 thus having more exposure to the data than forcing the data to be 1003 retrieved via the URL in DevInfo. 1005 Size: Information which may be very may be better sent in the 1006 DevInfo block, rather than a new block so that implementations are 1007 not tempted to send the data by value. Conversely, data which is 1008 small may best be sent in a separate block so that it can be sent 1009 by value 1011 Availability of a server: Providing the data via the device block 1012 requires a server be made available to retrieve the data. 1013 Providing the data via new block allows it to be sent by value 1014 (CID). 1016 3.3.9. emergencyCall.DevInfo Example 1018 1019 1022 Fixed phone 1023 Nokia 1024 Lumia 800 1025 35788104 1026 IMEI 1027 1029 Figure 7: emergencyCallDevInfo Example 1031 3.4. Owner/Subscriber Information 1033 This block describes the owner of the device (if provided by the 1034 device) or the subscriber information, if provided by a service 1035 provider. The contact location is not necessarily the location of 1036 the caller or incident, but is rather the nominal contact address. 1037 The mime subtype is "application/emergencyCall.Subscriber+xml". 1039 3.4.1. xCard for Subscriber's Data 1041 Data Element: xCARD for Subscriber's Data 1042 Use: Conditional: Some services (e.g., prepaid phones, initialized 1043 phones, etc.) may not have this information. 1045 XML Element: 1047 Description: Information known by the service provider or device 1048 about the subscriber; e.g., Name, Address, Individual Telephone 1049 Number, Main Telephone Number and any other data. N, ORG (if 1050 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1051 than one TEL property is provided, a parameter from the vCard 1052 Property Value registry MUST be specified on each TEL. 1054 Reason for Need: When the caller is unable to provide information, 1055 this data may be used to obtain it 1057 How Used by Call Taker: Obtaining critical information about the 1058 caller and possibly the location when it is not able to be 1059 obtained otherwise. 1061 3.4.2. emergencyCall.SubInfo Example 1063 1064 1067 1068 1069 1070 Simon Perreault 1071 1072 Perreault 1073 Simon 1074 1075 1076 ing. jr 1077 M.Sc. 1078 1079 --0203 1080 1081 20090808T1430-0500 1082 1083 M 1084 1085 1 1086 1087 fr 1088 1089 1090 2 1091 1092 en 1093 1094 1095 work 1096 1097 Viagenie 1098 1099 1100 1101 work 1102 1106 1107 1108 1109 2875 boul. Laurier, suite D2-630 1110 Quebec 1111 QC 1112 G1V 2M2 1113 Canada 1114 1115 1116 1117 1118 work 1119 voice 1120 1121 1122 tel:+1-418-656-9254;ext=102 1123 1124 1125 1126 1127 work 1128 text 1129 voice 1130 cell 1131 video 1132 1133 1134 tel:+1-418-262-6501 1135 1136 1137 work 1138 1139 simon.perreault@viagenie.ca 1140 1141 1142 work 1143 1144 geo:46.766336,-71.28955 1145 1146 1147 work 1148 1149 1150 http://www.viagenie.ca/simon.perreault/simon.asc 1151 1152 1153 America/Montreal 1154 1155 home 1156 1157 http://nomis80.org 1158 1159 1160 1161 1162 1164 Figure 8: emergencyCall.SubInfo Example 1166 3.5. Comment 1168 This block provides a mechanism for the data provider to supply 1169 extra, human readable information to the PSAP. It is not intended 1170 for a general purpose extension mechanism. The mime subtype is 1171 "application/emergencyCall.Comment+xml" 1173 3.5.1. Comment 1175 Data Element: EmergencyCall.Comment 1177 Use: Optional 1179 XML Element: 1181 Description: Human readable text providing additional information to 1182 the PSAP staff. 1184 Reason for Need: Explanatory information for values in the data 1185 structure 1187 How Used by Call Taker: To interpret the data provided 1189 3.5.2. emergencyCall.Comment Example 1191 1192 1195 This is an example text. 1196 1198 Figure 9: EmergencyCall.Comment Example 1200 4. Transport 1202 This section defines how to convey additional data to an emergency 1203 service provider. Two different means are specified: the first uses 1204 the call signaling; the second uses the element of a 1205 PIDF-LO [RFC4119]. 1207 1. First, the ability to embed a Uniform Resource Identifier (URI) 1208 in an existing SIP header field, the Call-Info header, is 1209 defined. The URI points to the additional data structure. The 1210 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1211 document adds a new token with the value 'emergencyCallData' for 1212 the Call-Info "purpose" parameter. If the "purpose" parameter is 1213 set to 'emergencyCallData' then the Call-Info header contains 1214 either an HTTPS URL pointing to an external resource or a CID 1215 (content indirection) URI that allows the data structure to be 1216 placed in the body of the SIP message. The "purpose" parameter 1217 also contains an indication of what kind of data is available at 1218 the URI. As the data is conveyed using a URI in the SIP 1219 signaling, the data itself may reside on an external resource, or 1220 may be contained within the body of the SIP message. When the 1221 URI refers to data at an external resource, the data is said to 1222 be passed by reference. When the URI refers to data contained 1223 within the body of the SIP message, the data is said to be passed 1224 by value. A PSAP or emergency responder is able to examine the 1225 type of data provided and selectively inspect the data it is 1226 interested in, while forwarding all of it (the values or 1227 references) to downstream entities. To be conveyed in a SIP body 1228 additional data about a call is defined as a series of MIME 1229 objects, each with an XML data structure contained inside. As 1230 usual, whenever more than one MIME part is included in the body 1231 of a message, MIME-multipart (i.e., 'multipart/mixed') encloses 1232 them all. This document defines the XML schemas and MIME types 1233 used for each block. When additional data is passed by value in 1234 the SIP signaling, each CID URL points to one block in the body. 1235 Multiple URIs are used within a Call-Info header field (or 1236 multiple Call-Info header fields) to point to multiple blocks. 1237 When additional data is provided by reference (in SIP signaling 1238 or Provided-By), each HTTPS URL references one block; the data is 1239 retrieved with an HTTPS GET operation, which returns one of the 1240 blocks as an XML object. 1242 2. Second, the ability to embed additional data structures in the 1243 element of a PIDF-LO [RFC4119] is defined. Besides 1244 a service provider in the call path, the access network provider 1245 may also have similar information that may be valuable to the 1246 PSAP. The access network provider may provide location in the 1247 form of a PIDF-LO from a location server via a location 1248 configuration protocol. The data structures described in this 1249 document are not specific to the location itself, but rather 1250 provides descriptive information having to do with the immediate 1251 circumstances about the provision of the location (who the access 1252 network is, how to contact that entity, what kind of service the 1253 access network provides, subscriber information, etc.). This 1254 data is similar in nearly every respect to the data known by 1255 service providers in the path of the call. When the access 1256 network provider and service provider are separate entities, the 1257 access network does not participate in the application layer 1258 signaling (and hence cannot add a Call-Info header field to the 1259 SIP message), but may provide location information to assist in 1260 locating the caller's device. The element of the 1261 PIDF-LO is a mechanism for the access network provider to supply 1262 the information about the entity or organization that supplied 1263 this location information. For this reason, this document 1264 describes a namespace per RFC 4119 for inclusion in the 1265 element of a PIDF-LO for adding information known 1266 to the access network provider. 1268 One or more blocks of data registered in the Emergency Call 1269 Additional Data registry, as defined in Section 9.1, may be included 1270 or referenced in the SIP signaling (using the Call-Info header field) 1271 or in the element of a PIDF-LO. Every block must be 1272 one of the types in the registry. Since the data of an emergency 1273 call may come from multiple sources, the data itself needs 1274 information describing the source. Consequently, each entity adding 1275 additional data MUST supply the "Data Provider" block. All other 1276 blocks are optional, but each entity SHOULD supply any blocks where 1277 it has at least some of the information in the block. 1279 4.1. Transmitting Blocks using the Call-Info Header 1281 A URI to a block MAY be inserted in a SIP request or response method 1282 (most often INVITE or MESSAGE) with a Call-Info header field 1283 containing a purpose of "emergencyCallData" together with the type of 1284 data available at the URI. The type of data is denoted by including 1285 the root of the MIME type (not including the emergencyCall prefix and 1286 the +xml suffix) with a "." separator. For example, when referencing 1287 a block with MIME type 'application/emergencyCall.ProviderInfo+xml', 1288 the 'purpose' parameter is set to 'emergencyCallData.ProviderInfo'. 1289 An example "Call-Info" header field for this would be: 1291 Call-Info: https://www.example.com/23sedde3; 1292 purpose="emergencyCallData.ProviderInfo" 1294 The Call-info header with purpose='emergencyCallData' MUST only be 1295 sent on an emergency call, which can be ascertained by the presence 1296 of an emergency service urn in a Route header of a SIP message. 1298 If the data is provided by reference, an HTTPS URI MUST be included 1299 and consequently Transport Layer Security (TLS) protection is applied 1300 for protecting the retrieval of the information. 1302 The data may also be supplied by value in a SIP message. In this 1303 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1304 referencing the MIME body part. 1306 More than one Call-Info header with an emergencyCallData purpose can 1307 be expected, but at least one MUST be provided. The device MUST 1308 provide one if it knows no service provider is in the path of the 1309 call. The device MAY insert one if it uses a service provider. Any 1310 service provider in the path of the call MUST insert its own. For 1311 example, a device, a telematics service provider in the call path, as 1312 well as the mobile carrier handling the call will each provide one. 1313 There may be circumstances where there is a service provider who is 1314 unaware that the call is an emergency call and cannot reasonably be 1315 expected to determine that it is an emergency call. In that case, 1316 that service provider is not expected to provide emergencyCallData. 1318 4.2. Transmitting Blocks by Reference using the Provided-By Element 1319 The 'emergencyCallDataReference' element is used to transmit an 1320 additional data block by reference within a 'Provided-By' element of 1321 a PIDF-LO. The 'emergencyCallDataReference' element has two 1322 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1323 type of data block referenced. The value of 'ref' is an HTTPS URL 1324 that resolves to a data structure with information about the call. 1325 The value of 'purpose' is the same as used in a 'Call-Info' header 1326 field (as specified in Section 4.1). 1328 For example, to reference a block with MIME type 'application/ 1329 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1330 'emergencyCallData.ProviderInfo'. An example 1331 'emergencyCallDataReference' element for this would be: 1333 1336 4.3. Transmitting Blocks by Value using the Provided-By Element 1338 It is RECOMMENDED that access networks supply the data specified in 1339 this document by reference, but they MAY provide the data by value. 1341 The 'emergencyCallDataValue' element is used to transmit an 1342 additional data block by value within a 'Provided-By' element of a 1343 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1344 'purpose' to indicate the type of data block contained. The value of 1345 'purpose' is the same as used in a 'Call-Info' header field (as 1346 specified in Section 4.1, and in Section 4.1). The same XML 1347 structure as would be wrapped in the corresponding MIME type is 1348 placed inside the emergencyCallDataValue element. 1350 For example: 1352 1354 1355 1357 1359 This is an example text. 1360 1361 1362 1363 1365 Test 1366 NENA 1367 Access Infrastructure Provider 1368 1369 sip:15555550987@burf.example.com;user=phone 1370 1371 1372 1374 Example Provided-By by Value. 1376 4.4. The Content-Disposition Parameter 1378 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1379 It updates and clarifies handling originally defined in RFC 3261 1380 [RFC3261] based on implementation experience. While RFC 3261 did not 1381 mandate support for 'multipart' message bodies 'multipart/mixed' MIME 1382 bodies are, however, used by many extensions (including additional 1383 data) today. For example, adding a PIDF-LO, SDP, and additional data 1384 in body of a SIP message requires a 'multipart' message body. 1386 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1387 parameter for the Content-Disposition header field. These RFCs 1388 describe how a UAS reacts if it receives a message body whose content 1389 type or disposition type it does not understand. If the 'handling' 1390 parameter has the value "optional", the UAS ignores the message body. 1391 If the 'handling' parameter has the value "required", the UAS returns 1392 a 415 (Unsupported Media Type) response. The 'by-reference' 1393 disposition type allows a SIP message to contain a reference to the 1394 body part, and the SIP UA processes the body part according to the 1395 reference. This is the case for the Call-info header containing a 1396 Content Indirection (CID) URL. 1398 As an example, a SIP message indicates the Content-Disposition 1399 parameter in the body of the SIP message as shown in Figure 10. 1401 Content-Type: application/sdp 1403 ...Omit Content-Disposition here; defaults are ok 1404 ...SDP goes here 1406 --boundary1 1408 Content-Type: application/pidf+xml 1409 Content-ID: 1410 Content-Disposition: by-reference;handling=optional 1411 ...PIDF-LO goes here 1413 --boundary1-- 1415 Content-Type: application/emergencyCall.ProviderInfo+xml 1416 Content-ID: <1234567890@atlanta.example.com> 1417 Content-Disposition: by-reference;handling=optional 1419 ...Additional data goes here 1421 --boundary1-- 1423 Figure 10: Example for use of the Content-Disposition Parameter in 1424 SIP. 1426 5. Examples 1428 This section provides three examples of communicating additional 1429 data. In Figure 11 additional data is communicated in a SIP INVITE 1430 per value. In Figure 12 we illustrate how additional data is added 1431 by a SIP proxy per reference. Finally, an example for including 1432 additional data in the element of a PIDF-LO is 1433 illustrated. 1435 INVITE sips:bob@biloxi.example.com SIP/2.0 1436 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1437 Max-Forwards: 70 1438 To: Bob 1439 From: Alice ;tag=9fxced76sl 1440 Call-ID: 3848276298220188511@atlanta.example.com 1441 Call-Info: ;purpose=icon, 1442 ;purpose=info, 1443 1444 ;purpose=emergencyCallData.ProviderInfo 1445 Geolocation: 1446 Geolocation-Routing: no 1447 Accept: application/sdp, application/pidf+xml, 1448 application/emergencyCallProviderinfo+xml 1449 CSeq: 31862 INVITE 1450 Contact: 1451 Content-Type: multipart/mixed; boundary=boundary1 1453 Content-Length: ... 1455 --boundary1 1456 Content-Type: application/sdp 1458 ...SDP goes here 1460 --boundary1 1462 Content-Type: application/pidf+xml 1463 Content-ID: 1464 Content-Disposition: by-reference;handling=optional 1466 ...PIDF-LO goes here 1468 --boundary1-- 1470 Content-Type: application/emergencyCall.ProviderInfo+xml 1471 Content-ID: <1234567890@atlanta.example.com> 1472 Content-Disposition: by-reference;handling=optional 1474 ...Additional data goes here 1476 --boundary1-- 1478 Figure 11: Example: Attaching Additional Data via CID to a SIP 1479 INVITE. 1481 INVITE sips:bob@biloxi.example.com SIP/2.0 1482 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1483 Max-Forwards: 70 1484 To: Bob 1485 From: Alice ;tag=9fxced76sl 1486 Call-ID: 3848276298220188511@atlanta.example.com 1487 Call-Info: ;purpose=icon, 1488 ;purpose=info, 1489 1490 ;purpose=emergencyCallData.ProviderInfo 1491 Geolocation: 1492 Geolocation-Routing: no 1493 Accept: application/sdp, application/pidf+xml, 1494 application/emergencyCallProviderinfo+xml 1495 CSeq: 31862 INVITE 1496 Contact: 1497 Content-Type: multipart/mixed; boundary=boundary1 1499 Content-Length: ... 1501 --boundary1 1502 Content-Type: application/sdp 1504 ...SDP goes here 1506 --boundary1 1508 Content-Type: application/pidf+xml 1509 Content-ID: 1510 Content-Disposition: by-reference;handling=optional 1512 ...PIDF-LO goes here 1514 --boundary1-- 1516 Figure 12: Example: Attaching Additional Data per Reference in a SIP 1517 INVITE. 1519 1520 1525 1526 1527 1528 1530 AU 1531 NSW 1532 Wollongong 1533 North Wollongong 1534 Flinders 1535 Street 1536 Campbell Street 1537 Gilligan's Island 1538 Corner 1539 Video Rental Store 1540 2500 1541 Westerns and Classics 1542 store 1543 Private Box 15 1544 1545 1546 1547 true 1548 1549 2013-07-10T20:00:00Z 1550 1551 1552 802.11 1553 1556 1559 1560 1562 University of California, Irvine 1563 1564 urn:nena:companyid:uci 1565 NENA 1566 Other 1567 tel:+1 9498245222 1568 EN 1569 1571 1573 This is an example text. 1574 1576 1577 1578 1579 mac:1234567890ab 1580 2013-07-09T20:57:29Z 1581 1582 1584 Figure 13: Example: Including Additional Data via the Provided-By 1585 Element in a PIDF-LO. 1587 6. XML Schemas 1589 This section defines the XML schemas of the five data blocks. 1590 Additionally, the Provided-By schema is specified. 1592 6.1. emergencyCall.ProviderInfo XML Schema 1594 1595 1604 1607 1609 1610 1611 1612 1613 1615 1619 1620 1621 1623 1625 1627 1629 1631 1633 1637 1639 1640 1642 1643 Figure 14: emergencyCall.ProviderInfo XML Schema 1645 6.2. emergencyCall.SvcInfo XML Schema 1647 1648 1655 1658 1660 1661 1662 1664 1666 1668 1671 1673 1674 1676 1678 Figure 15: emergencyCall.SvcInfo XML Schema 1680 6.3. emergencyCall.DevInfo XML Schema 1682 1683 1689 1692 1694 1695 1696 1698 1700 1702 1704 1706 1708 1711 1713 1714 1716 1718 Figure 16: emergencyCall.DevInfo XML Schema 1720 6.4. emergencyCall.SubInfo XML Schema 1722 1723 1731 1734 1736 1738 1739 1740 1743 1745 1746 1748 1750 Figure 17: emergencyCall.SubInfo XML Schema 1752 6.5. emergencyCall.Comment XML Schema 1754 1755 1762 1765 1767 1768 1769 1772 1774 1775 1777 1778 1779 1780 1781 1782 1784 1786 1788 Figure 18: EmergencyCall.Comment XML Schema 1790 6.6. Provided-By XML Schema 1792 This section defines the Provided-By schema. 1794 1795 1808 1809 1810 1811 1812 1814 1816 1817 1819 1823 1827 1830 1832 1834 1836 1837 1838 1839 1840 1842 1843 1845 1847 1848 1849 1851 1853 1854 1855 1858 1861 1864 1867 1871 1874 1875 1877 1879 Figure 19: Provided-By XML Schema 1881 7. Security Considerations 1883 The information in this data structure will usually be considered 1884 private. HTTPS is specified to require the provider of the 1885 information to validate the credentials of the requester. While the 1886 creation of a PKI that has global scope may be difficult, the 1887 alternatives to creating devices and services that can provide 1888 critical information securely are more daunting. The provider may 1889 enforce any policy it wishes to use, but PSAPs and responder agencies 1890 should deploy a PKI so that providers of additional data can check 1891 the certificate of the client and decide the appropriate policy to 1892 enforce based on that certificate. 1894 Ideally, the PSAP and emergency responders will be given credentials 1895 signed by an authority trusted by the data provider. In most 1896 circumstances, nationally recognized credentials would be sufficient, 1897 and if the emergency services arranges a PKI, data providers could be 1898 provisioned with the root CA public key for a given nation. Some 1899 nations are developing a PKI for this, and related, purposes. Since 1900 calls could be made from devices where the device and/or the service 1901 provider(s) are not local to the emergency authorities, globally 1902 recognized credentials are useful. This might be accomplished by 1903 extending the notion of the "forest guide" described in [RFC5222] to 1904 allow the forest guide to provide the credential of the PKI root for 1905 areas that it has coverage information for, but standards for such a 1906 mechanism are not yet available. In its absence, the data provider 1907 will need to obtain the root CA credentials for any areas it is 1908 willing to provide additional data by out of band means. With the 1909 credential of the root CA for a national emergency services PKI, the 1910 data provider server can validate the credentials of an entity 1911 requesting additional data by reference. 1913 The data provider also needs a credential that can be verified by the 1914 emergency services to know that it is receiving data from the right 1915 server. The emergency authorities could provide credentials, 1916 distinguishable from credentials it provides to emergency responders 1917 and PSAPs, which could be used to validate data providers. Such 1918 credentials would have to be acceptable to any PSAP or responder that 1919 could receive a call with additional data supplied by that provider. 1920 This would be extensible to global credential validation using the 1921 forest guide as above. In the absence of such credentials, the 1922 emergency authorities could maintain a list of local data providers' 1923 credentials provided to it out of band. At a minimum, the emergency 1924 authorities could obtain a credential from the DNS entry of the 1925 domain in the Additional Data URI to at least validate that the 1926 server is known to the domain providing the URI. 1928 Data provided by devices by reference have similar credential 1929 validation issues to service providers, and the solutions are the 1930 same. 1932 8. Privacy Considerations 1934 This document enables functionality for conveying additional 1935 information about the caller to the callee. Some of this information 1936 is personal data and therefore privacy concerns arise. There are a 1937 number of privacy concerns with regular real-time communication 1938 services that are also applicable to emergency calling. Data 1939 protection regulation world-wide has, however, decided to create 1940 exceptions for emergency services since the drawbacks of disclosing 1941 personal data in comparison to the benefit for the emergency caller 1942 are often towards the latter. Hence, the data protection rights of 1943 individuals are often waived for emergency situations. There are, 1944 however, still various countries that offer some degree of anonymity 1945 for the caller towards PSAP call takers. 1947 The functionality defined in this document, however, far exceeds the 1948 amount of information sharing found in the Plain old telephone system 1949 (POTS). For this reason there are additional privacy threats to 1950 consider, which are described in more detail in 1951 [I-D.iab-privacy-considerations]. 1953 Stored Data Compromise: First, there is an increased risk of stored 1954 data compromise since additional data is collected and stored in 1955 databases. Without adequate measures to secure stored data from 1956 unauthorized or inappropriate access at access network operators, 1957 service providers, end devices, as well as PSAPs individuals are 1958 exposed to potential financial, reputational, or physical harm. 1960 Misattribution: If the personal data collected and conveyed is 1961 incorrect or inaccurate then this may lead to misattribution. 1962 Misattribution occurs when data or communications related to one 1963 individual are attributed to another. 1965 Identification: By the nature of the additional data and its 1966 capability to provide much richer information about the caller, 1967 the call, and the location the calling party is identified in a 1968 much better way. Some users may feel uncomfortable with this 1969 degree of information sharing even in emergency services 1970 situations. 1972 Secondary Use: Furthermore, there is the risk of secondary use. 1973 Secondary use is the use of collected information about an 1974 individual without the individual's consent for a purpose 1975 different from that for which the information was collected. The 1976 stated purpose of the additional data is for emergency services 1977 purposes but theoretically the same information could be used for 1978 any other call as well. Additionally, parties involved in the 1979 emergency call may retain the obtained information and may re-use 1980 it for other, non-emergency services purposes. 1982 Disclosure: When the data defined in this document is not properly 1983 security (while in transit with traditional communication security 1984 techniques, and while at rest using access control mechanisms) 1985 there is the risk of disclosure, which is the revelation of 1986 information about an individual that affects the way others judge 1987 the individual. 1989 To mitigate these privacy risks the following countermeasures can be 1990 taken. 1992 In regions where callers can elect to suppress certain personally 1993 identifying information, the network or PSAP functionality can 1994 inspect privacy flags within the SIP headers to determine what 1995 information may be passed, stored, or displayed to comply with local 1996 policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token. 1997 The presence of this privacy type in a Privacy header field indicates 1998 that the user would like the network asserted identity to be kept 1999 private with respect to SIP entities outside the trust domain with 2000 which the user authenticated, including the PSAP. 2002 This document defines various data structures that constitutes 2003 personal data. Local regulations may govern what data must be 2004 provided in emergency calls, but in general, the emergency call 2005 system is often aided by the kinds of information described in this 2006 document. There is a tradeoff between the privacy considerations and 2007 the utility of the data. For adequate protection this specification 2008 requires all data exchanges to be secured via communication security 2009 techniques (namely TLS) against eavesdropping and inception. 2010 Furthermore, security safeguards are required to prevent unauthorized 2011 access to data at rest. Various security incidents over the last 10 2012 years have shown data breaches are not not uncommon and are often 2013 caused by lack of proper access control frameworks, software bugs 2014 (buffer overflows), or missing input parsing (SQL injection attacks). 2015 The risks of data breaches is increased with the obligation for 2016 emergency services to retain emergency call related data for extended 2017 periods, e.g., several years are the norm. 2019 Finally, it is also worth to highlight the nature of the SIP 2020 communication architecture, which introduces additional complications 2021 for privacy. Some forms of data can be sent by value in the SIP 2022 signaling or by value (URL in SIP signaling). When data is sent by 2023 value, all intermediaries have access to the data. As such, these 2024 intermediaries may also introduce additional privacy risk. 2025 Therefore, in situations where the conveyed information raises 2026 privacy concerns and intermediaries are involved transmitting a 2027 reference is more appropriate (assuming proper access control 2028 policies are available for distinguishing the different entities 2029 dereferencing the reference). Without access control policies any 2030 party in possession of the reference is able to resolve the reference 2031 and to obtain the data, including intermediaries. 2033 9. IANA Considerations 2035 9.1. Registry creation 2037 This document creates a new registry called 'Emergency Call 2038 Additional Data'. The following sub-registries are created in 2039 Emergency Call Additional Data: 2041 9.1.1. Provider ID Series Registry 2043 This document creates a new sub-registry called 'Additional Call Data 2044 Provider ID Series'. As defined in [RFC5226], this registry operates 2045 under "Expert Review" rules. The expert should determine that the 2046 entity requesting a new value is a legitimate issuer of service 2047 provider IDs suitable for use in Additional Call Data. 2049 The content of this registry includes: 2051 Name: The identifier which will be used in the ProviderIDSeries 2052 element 2054 Source: The full name of the organization issuing the identifiers 2056 URL: A URL to the organization for further information 2058 The initial set of values is listed in Figure 20. 2060 +-----------+--------------------------+----------------------+ 2061 | Name | Source | URL | 2062 +-----------+--------------------------+----------------------+ 2063 | NENA | National Emergency | http://www.nena.org | 2064 | | Number Association | | 2065 | EENA | European Emergency | http://www.eena.org | 2066 | | Number Association | | 2067 +-----------+--------------------------+----------------------+ 2069 Figure 20: Provider ID Series Registry 2071 9.1.2. Service Provider Type Registry 2073 This document creates a new sub-registry called 'Service Provider 2074 Type'. As defined in [RFC5226], this registry operates under "Expert 2075 Review". The expert should determine that the proposed new value is 2076 distinct from existing values and appropriate for use in the 2077 TypeOfServicerProvider element 2079 The content of this registry includes: 2081 Name: Value to be used in TypeOfServiceProvider. 2083 Description: A short description of the type of service provider 2085 The initial set of values is defined in Figure 1. 2087 9.1.3. Service Delivered Registry 2089 This document creates a new sub-registry called 'Service Delivered'. 2090 As defined in [RFC5226], this registry operates under "Expert Review" 2091 rules. The expert should consider whether the proposed service is 2092 unique from existing services and the definition of the service will 2093 be clear to implementors and PSAPS/responders. 2095 The content of this registry includes: 2097 Name: Enumeration token of the service. 2099 Description: Short description identifying the service. 2101 The initial set of values are defined in Figure 3. 2103 9.1.4. Device Classification Registry 2105 This document creates a new sub-registry called 'Device 2106 Classification'. As defined in [RFC5226], this registry operates 2107 under "Expert Review" rules. The expert should consider whether the 2108 proposed class is unique from existing classes and the definition of 2109 the class will be clear to implementors and PSAPS/responders. 2111 The content of this registry includes: 2113 Name: Enumeration token of the device classification. 2115 Description: Short description identifying the device type. 2117 The initial set of values are defined in Figure 5. 2119 9.1.5. Device ID Type Type Registry 2121 This document creates a new sub-registry called 'Additional Call Data 2122 Device ID Type'. As defined in [RFC5226], this registry operates 2123 under "Expert Review" rules. The expert should ascertain that the 2124 proposed type is well understood, and provides the information useful 2125 to PSAPs and responders to uniquely identify a device. 2127 The content of this registry includes: 2129 Name: Enumeration token of the device id type. 2131 Description: Short description identifying type of device id. 2133 The initial set of values are defined in Figure 6. 2135 9.1.6. Device/Service Data Type Registry 2137 This document creates a new sub-registry called 'Device/Service Data 2138 Type Registry'. As defined in [RFC5226], this registry operates 2139 under "Expert Review" and "Specification Required" rules. The expert 2140 should ascertain that the proposed type is well understood, and 2141 provides information useful to PSAPs and responders. The 2142 specification must contain a complete description of the data, and a 2143 precise format specification suitable to allow interoperable 2144 implementations. 2146 The content of this registry includes: 2148 Name: Enumeration token of the data type. 2150 Description: Short description identifying the the data. 2152 Specification: Citation for the specification of the data. 2154 The initial set of values are listed in Figure 21. 2156 +---------+----------------------------------------+----------------+ 2157 | Token | Description | Specification | 2158 +---------+----------------------------------------+----------------+ 2159 | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | 2160 +---------+----------------------------------------+----------------+ 2161 | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | 2162 +---------+----------------------------------------+----------------+ 2164 Figure 21: Device/Service Data Type Registry 2166 9.1.7. Additional Data Blocks Registry 2168 This document creates a new sub-registry called 'Additional Data 2169 Blocks' in the purpose registry established by RFC 3261 [RFC3261]. 2170 As defined in [RFC5226], this registry operates under "Expert Review" 2171 and "Specification Required" rules. The expert is responsible for 2172 verifying that the document contains a complete and clear 2173 specification and the proposed functionality does not obviously 2174 duplicate existing functionality. 2176 The content of this registry includes: 2178 Name: Element Name of enclosing block. 2180 Reference: The document that describes the block 2182 The initial set of values are listed in Figure 22. 2184 +--------------+------------+ 2185 | Token | Reference | 2186 +--------------+------------+ 2187 | ProviderInfo | [This RFC] | 2188 | SvcInfo | [This RFC] | 2189 | DevInfo | [This RFC] | 2190 | Subscriber | [This RFC] | 2191 | Comment | [This RFC] | 2192 +--------------+------------+ 2194 Figure 22: Additional Data Blocks Registry 2196 9.2. 'emergencyCallData' Purpose Parameter Value 2198 This document defines the 'emergencyCall' value for the "purpose" 2199 parameter of the Call-Info header field. The Call-Info header and 2200 the corresponding registry for the 'purpose' parameter was 2201 established with RFC 3261 [RFC3261]. 2203 Header Parameter New 2204 Field Name Value Reference 2205 ---------- --------- ----------------- --------- 2206 Call-Info purpose emergencyCall [This RFC] 2208 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 2210 This section registers the namespace specified in Section 9.5.1 in 2211 the provided-by registry established by RFC 4119, for usage within 2212 the element of a PIDF-LO. 2214 The schema for the provided-by schema used by this document is 2215 specified in Section 6.6. 2217 9.4. MIME Registrations 2219 9.4.1. MIME Content-type Registration for 'application/ 2220 emergencyCall.ProviderInfo+xml' 2222 This specification requests the registration of a new MIME type 2223 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2224 RFC 3023 [RFC3023]. 2226 MIME media type name: application 2228 MIME subtype name: emergencyCall.ProviderInfo+xml 2230 Mandatory parameters: none 2232 Optional parameters: charset Indicates the character encoding of 2233 enclosed XML. 2235 Encoding considerations: Uses XML, which can employ 8-bit 2236 characters, depending on the character encoding used. See 2237 Section 3.2 of RFC 3023 [RFC3023]. 2239 Security considerations: This content type is designed to carry 2240 the data provider information, which is a sub-category of 2241 additional data about an emergency call. Since this data contains 2242 personal information appropriate precautions have to be taken to 2243 limit unauthorized access, inappropriate disclosure to third 2244 parties, and eavesdropping of this information. Please refer to 2245 Section 7 and Section 8 for more information. 2247 Interoperability considerations: None 2249 Published specification: [TBD: This specification] 2251 Applications which use this media type: Emergency Services 2253 Additional information: Magic Number: None File Extension: .xml 2254 Macintosh file type code: 'TEXT' 2255 Person and email address for further information: Hannes 2256 Tschofenig, Hannes.Tschofenig@gmx.net 2258 Intended usage: LIMITED USE 2260 Author: This specification is a work item of the IETF ECRIT 2261 working group, with mailing list address . 2263 Change controller: The IESG 2265 9.4.2. MIME Content-type Registration for 'application/ 2266 emergencyCall.SvcInfo+xml' 2268 This specification requests the registration of a new MIME type 2269 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2270 RFC 3023 [RFC3023]. 2272 MIME media type name: application 2274 MIME subtype name: emergencyCall.SvcInfo+xml 2276 Mandatory parameters: none 2278 Optional parameters: charset Indicates the character encoding of 2279 enclosed XML. 2281 Encoding considerations: Uses XML, which can employ 8-bit 2282 characters, depending on the character encoding used. See 2283 Section 3.2 of RFC 3023 [RFC3023]. 2285 Security considerations: This content type is designed to carry 2286 the service information, which is a sub-category of additional 2287 data about an emergency call. Since this data contains personal 2288 information appropriate precautions have to be taken to limit 2289 unauthorized access, inappropriate disclosure to third parties, 2290 and eavesdropping of this information. Please refer to Section 7 2291 and Section 8 for more information. 2293 Interoperability considerations: None 2295 Published specification: [TBD: This specification] 2297 Applications which use this media type: Emergency Services 2299 Additional information: Magic Number: None File Extension: .xml 2300 Macintosh file type code: 'TEXT' 2301 Person and email address for further information: Hannes 2302 Tschofenig, Hannes.Tschofenig@gmx.net 2304 Intended usage: LIMITED USE 2306 Author: This specification is a work item of the IETF ECRIT 2307 working group, with mailing list address . 2309 Change controller: The IESG 2311 9.4.3. MIME Content-type Registration for 'application/ 2312 emergencyCall.DevInfo+xml' 2314 This specification requests the registration of a new MIME type 2315 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2316 RFC 3023 [RFC3023]. 2318 MIME media type name: application 2320 MIME subtype name: emergencyCall.DevInfo+xml 2322 Mandatory parameters: none 2324 Optional parameters: charset Indicates the character encoding of 2325 enclosed XML. 2327 Encoding considerations: Uses XML, which can employ 8-bit 2328 characters, depending on the character encoding used. See 2329 Section 3.2 of RFC 3023 [RFC3023]. 2331 Security considerations: This content type is designed to carry 2332 the device information information, which is a sub-category of 2333 additional data about an emergency call. Since this data contains 2334 personal information appropriate precautions have to be taken to 2335 limit unauthorized access, inappropriate disclosure to third 2336 parties, and eavesdropping of this information. Please refer to 2337 Section 7 and Section 8 for more information. 2339 Interoperability considerations: None 2341 Published specification: [TBD: This specification] 2343 Applications which use this media type: Emergency Services 2345 Additional information: Magic Number: None File Extension: .xml 2346 Macintosh file type code: 'TEXT' 2347 Person and email address for further information: Hannes 2348 Tschofenig, Hannes.Tschofenig@gmx.net 2350 Intended usage: LIMITED USE 2352 Author: This specification is a work item of the IETF ECRIT 2353 working group, with mailing list address . 2355 Change controller: The IESG 2357 9.4.4. MIME Content-type Registration for 'application/ 2358 emergencyCall.SubInfo+xml' 2360 This specification requests the registration of a new MIME type 2361 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2362 RFC 3023 [RFC3023]. 2364 MIME media type name: application 2366 MIME subtype name: emergencyCall.SubInfo+xml 2368 Mandatory parameters: none 2370 Optional parameters: charset Indicates the character encoding of 2371 enclosed XML. 2373 Encoding considerations: Uses XML, which can employ 8-bit 2374 characters, depending on the character encoding used. See 2375 Section 3.2 of RFC 3023 [RFC3023]. 2377 Security considerations: This content type is designed to carry 2378 owner/subscriber information, which is a sub-category of 2379 additional data about an emergency call. Since this data contains 2380 personal information appropriate precautions have to be taken to 2381 limit unauthorized access, inappropriate disclosure to third 2382 parties, and eavesdropping of this information. Please refer to 2383 Section 7 and Section 8 for more information. 2385 Interoperability considerations: None 2387 Published specification: [TBD: This specification] 2389 Applications which use this media type: Emergency Services 2391 Additional information: Magic Number: None File Extension: .xml 2392 Macintosh file type code: 'TEXT' 2393 Person and email address for further information: Hannes 2394 Tschofenig, Hannes.Tschofenig@gmx.net 2396 Intended usage: LIMITED USE 2398 Author: This specification is a work item of the IETF ECRIT 2399 working group, with mailing list address . 2401 Change controller: The IESG 2403 9.4.5. MIME Content-type Registration for 'application/ 2404 emergencyCall.Comment+xml' 2406 This specification requests the registration of a new MIME type 2407 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2408 RFC 3023 [RFC3023]. 2410 MIME media type name: application 2412 MIME subtype name: emergencyCall.Comment+xml 2414 Mandatory parameters: none 2416 Optional parameters: charset Indicates the character encoding of 2417 enclosed XML. 2419 Encoding considerations: Uses XML, which can employ 8-bit 2420 characters, depending on the character encoding used. See 2421 Section 3.2 of RFC 3023 [RFC3023]. 2423 Security considerations: This content type is designed to carry a 2424 comment, which is a sub-category of additional data about an 2425 emergency call. This data may contain personal information. 2426 Appropriate precautions may have to be taken to limit unauthorized 2427 access, inappropriate disclosure to third parties, and 2428 eavesdropping of this information. Please refer to Section 7 and 2429 Section 8 for more information. 2431 Interoperability considerations: None 2433 Published specification: [TBD: This specification] 2435 Applications which use this media type: Emergency Services 2437 Additional information: Magic Number: None File Extension: .xml 2438 Macintosh file type code: 'TEXT' 2439 Person and email address for further information: Hannes 2440 Tschofenig, Hannes.Tschofenig@gmx.net 2442 Intended usage: LIMITED USE 2444 Author: This specification is a work item of the IETF ECRIT 2445 working group, with mailing list address . 2447 Change controller: The IESG 2449 9.5. URN Sub-Namespace Registration 2451 9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 2453 This section registers a new XML namespace, as per the guidelines in 2454 RFC 3688 [RFC3688]. 2456 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 2458 Registrant Contact: IETF, ECRIT working group, , as 2459 delegated by the IESG . 2461 XML: 2463 BEGIN 2464 2465 2467 2468 2469 2471 Namespace for Additional Emergency Call Data 2472 2473 2474

Namespace for Additional Data related to an Emergency Call

2475

See [TBD: This document].

2476 2477 2478 END 2480 9.5.2. Registration for 2481 urn:ietf:params:xml:ns:emergencyCallProviderInfo 2483 This section registers a new XML namespace, as per the guidelines in 2484 RFC 3688 [RFC3688]. 2486 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 2488 Registrant Contact: IETF, ECRIT working group, , as 2489 delegated by the IESG . 2491 XML: 2493 BEGIN 2494 2495 2497 2498 2499 2501 Namespace for Additional Emergency Call Data: 2502 Data Provider Information 2503 2504 2505

Namespace for Additional Data related to an Emergency Call

2506

Data Provider Information

2507

See [TBD: This document].

2508 2509 2510 END 2512 9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2514 This section registers a new XML namespace, as per the guidelines in 2515 RFC 3688 [RFC3688]. 2517 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2519 Registrant Contact: IETF, ECRIT working group, , as 2520 delegated by the IESG . 2522 XML: 2524 BEGIN 2525 2526 2528 2529 2530 2532 Namespace for Additional Emergency Call Data: 2533 Service Information 2534 2535 2536

Namespace for Additional Data related to an Emergency Call

2537

Service Information

2538

See [TBD: This document].

2539 2540 2541 END 2543 9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 2545 This section registers a new XML namespace, as per the guidelines in 2546 RFC 3688 [RFC3688]. 2548 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 2550 Registrant Contact: IETF, ECRIT working group, , as 2551 delegated by the IESG . 2553 XML: 2555 BEGIN 2556 2557 2559 2560 2561 2563 Namespace for Additional Emergency Call Data: 2564 Device Information 2565 2566 2567

Namespace for Additional Data related to an Emergency Call

2568

Device Information

2569

See [TBD: This document].

2570 2571 2572 END 2574 9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 2576 This section registers a new XML namespace, as per the guidelines in 2577 RFC 3688 [RFC3688]. 2579 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 2581 Registrant Contact: IETF, ECRIT working group, , as 2582 delegated by the IESG . 2584 XML: 2586 BEGIN 2587 2588 2590 2591 2592 2594 Namespace for Additional Emergency Call Data: 2595 Owner/Subscriber Information 2596 2597 2598

Namespace for Additional Data related to an Emergency Call

2599

Owner/Subscriber Information

2600

See [TBD: This document].

2601 2602 2603 END 2605 9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 2607 This section registers a new XML namespace, as per the guidelines in 2608 RFC 3688 [RFC3688]. 2610 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 2612 Registrant Contact: IETF, ECRIT working group, , as 2613 delegated by the IESG . 2615 XML: 2617 BEGIN 2618 2619 2621 2622 2623 2625 Namespace for Additional Emergency Call Data:Comment 2626 2627 2628

Namespace for Additional Data related to an Emergency Call

2629

Comment

2630

See [TBD: This document].

2631 2632 2633 END 2635 9.6. Schema Registrations 2637 This specification registers five schemas, as per the guidelines in 2638 RFC 3688 [RFC3688]. 2640 URI: urn:ietf:params:xml:schema:additional- 2641 data:emergencyCallProviderInfo 2643 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2644 delegated by the IESG (iesg@ietf.org). 2646 XML: The XML schema can be found in Figure 14. 2648 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2650 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2651 delegated by the IESG (iesg@ietf.org). 2653 XML: The XML schema can be found in Figure 15. 2655 URI: urn:ietf:params:xml:schema:additional- 2656 data:emergencyCallDevInfo 2658 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2659 delegated by the IESG (iesg@ietf.org). 2661 XML: The XML schema can be found in Figure 16. 2663 URI: urn:ietf:params:xml:schema:additional- 2664 data:emergencyCall.SubInfo 2666 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2667 delegated by the IESG (iesg@ietf.org). 2669 XML: The XML schema can be found in Section 6.4. 2671 URI: urn:ietf:params:xml:schema:additional- 2672 data:emergencyCall.Comment 2674 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2675 delegated by the IESG (iesg@ietf.org). 2677 XML: The XML schema can be found in Section 6.5. 2679 9.7. VCard Parameter Value Registration 2681 This document registers a new value in the vCARD Parameter Values 2682 registry as defined by [RFC6350] with the following template: 2684 Value: main 2686 Purpose: The main telephone number, typically of an enterprise, as 2687 opposed to a direct dial number of an individual employee 2689 Conformance: This value can be used with the "TYPE" parameter 2690 applied on the "TEL" property. 2692 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 2693 00 2695 10. Acknowledgments 2697 This work was originally started in NENA and has benefitted from a 2698 large number of participants in NENA standardization efforts, 2699 originally in the Long Term Definition Working Group, the Data 2700 Technical Committee and most recently the Additional Data working 2701 group. The authors are grateful for the initial work and extended 2702 comments provided by many NENA participants, including Delaine 2703 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 2704 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 2705 and Robert (Bob) Sherry. 2707 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 2708 Thomson, Keith Drage, and Laura Liess for their review comments. 2710 11. References 2712 11.1. Normative References 2714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2715 Requirement Levels", BCP 14, RFC 2119, March 1997. 2717 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2718 Locators", RFC 2392, August 1998. 2720 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2721 Types", RFC 3023, January 2001. 2723 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 2724 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 2725 and QSIG Objects", RFC 3204, December 2001. 2727 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2728 A., Peterson, J., Sparks, R., Handley, M., and E. 2729 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2730 June 2002. 2732 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 2733 Extensions to the Session Initiation Protocol (SIP) for 2734 Asserted Identity within Trusted Networks", RFC 3325, 2735 November 2002. 2737 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 2738 Extensions (MIME) Parameter", RFC 3459, January 2003. 2740 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2741 January 2004. 2743 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2744 Format", RFC 4119, December 2005. 2746 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2747 Registration Procedures", RFC 4288, December 2005. 2749 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2750 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2751 May 2008. 2753 [RFC5621] Camarillo, G., "Message Body Handling in the Session 2754 Initiation Protocol (SIP)", RFC 5621, September 2009. 2756 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2757 August 2011. 2759 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2760 6351, August 2011. 2762 11.2. Informational References 2764 [I-D.iab-privacy-considerations] 2765 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2766 Morris, J., Hansen, M., and R. Smith, "Privacy 2767 Considerations for Internet Protocols", draft-iab-privacy- 2768 considerations-03 (work in progress), July 2012. 2770 [I-D.ietf-geopriv-relative-location] 2771 Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 2772 Thomson, "Relative Location Representation", draft-ietf- 2773 geopriv-relative-location-05 (work in progress), June 2774 2013. 2776 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 2777 Emergency Context Resolution with Internet Technologies", 2778 RFC 5012, January 2008. 2780 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 2781 Format for Presence Information Data Format Location 2782 Object (PIDF-LO)", RFC 5139, February 2008. 2784 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 2785 Tschofenig, "LoST: A Location-to-Service Translation 2786 Protocol", RFC 5222, August 2008. 2788 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2789 Presence Information Data Format Location Object (PIDF-LO) 2790 Usage Clarification, Considerations, and Recommendations", 2791 RFC 5491, March 2009. 2793 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 2794 Thomson, "Dynamic Extensions to the Presence Information 2795 Data Format Location Object (PIDF-LO)", RFC 5962, 2796 September 2010. 2798 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 2799 5985, September 2010. 2801 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2802 "Framework for Emergency Calling Using Internet 2803 Multimedia", RFC 6443, December 2011. 2805 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 2806 R. George, "Specifying Civic Address Extensions in the 2807 Presence Information Data Format Location Object (PIDF- 2808 LO)", RFC 6848, January 2013. 2810 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 2811 Communications Services in Support of Emergency Calling", 2812 BCP 181, RFC 6881, March 2013. 2814 Appendix A. XML Schema for vCard/xCard 2816 This section contains the vCard/xCard XML schema version of the Relax 2817 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 2818 XML schemas defined in this document. The schema in RFC 6351 2819 [RFC6351] is the normative source and this section is informative 2820 only. 2822 2823 2827 2833 2834 2835 vCard Format Specification 2836 2837 2838 2839 2840 2841 2842 2843 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2858 2859 2860 2862 2863 2864 2865 2866 2868 2869 2870 2872 2873 2874 2875 2876 2878 2879 2880 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2925 2926 2927 2928 2932 2933 2934 Section 5: Parameters 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3875 3876 3877 3879 3881 3882 3883 3885 3886 3887 3888 3890 Authors' Addresses 3892 Brian Rosen 3893 NeuStar 3894 470 Conrad Dr. 3895 Mars, PA 16046 3896 US 3898 Phone: +1 724 382 1051 3899 Email: br@brianrosen.net 3901 Hannes Tschofenig 3902 Nokia Siemens Networks 3903 Linnoitustie 6 3904 Espoo 02600 3905 Finland 3907 Phone: +358 (50) 4871445 3908 Email: Hannes.Tschofenig@gmx.net 3909 URI: http://www.tschofenig.priv.at 3910 Roger Marshall 3911 TeleCommunication Systems, Inc. 3912 2401 Elliott Avenue 3913 Seattle, WA 98121 3914 US 3916 Phone: +1 206 792 2424 3917 Email: rmarshall@telecomsys.com 3918 URI: http://www.telecomsys.com 3920 Randall Gellens 3921 Qualcomm Technologies, Inc. 3922 5775 Morehouse Drive 3923 San Diego, CA 92121 3924 US 3926 Email: rg+ietf@qti.qualcomm.com 3928 James Winterbottom 3929 AU 3931 Email: a.james.winterbottom@gmail.com