idnits 2.17.1 draft-ietf-ecrit-additional-data-11.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 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 1703 has weird spacing: '...element name=...' == Line 1912 has weird spacing: '...s PSAPs indiv...' == Line 2154 has weird spacing: '...ll-Info pur...' -- The document date (July 31, 2013) is 3920 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 2154, but not defined == Unused Reference: 'I-D.iab-privacy-considerations' is defined on line 2714, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-relative-location' is defined on line 2720, but no explicit reference was found in the text == Unused Reference: 'RFC5985' is defined on line 2747, 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: A later version (-09) exists of draft-iab-privacy-considerations-03 == Outdated reference: A later version (-08) exists of draft-ietf-geopriv-relative-location-06 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B.R. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 30, 2014 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 J. Winterbottom 11 July 31, 2013 13 Additional Data related to an Emergency Call 14 draft-ietf-ecrit-additional-data-11.txt 16 Abstract 18 When an emergency call is sent to a Public Safety Answering Point 19 (PSAP), the device that sends it, as well as any application service 20 provider in the path of the call, or access network provider through 21 which the call originated may have information about the call, the 22 caller or the location which the PSAP may be able to use. This 23 document describes data structures and a mechanism to convey such 24 data to the PSAP. The mechanism uses a Uniform Resource Identifier 25 (URI), which may point to either an external resource or an object in 26 the body of the SIP message. The mechanism thus allows the data to 27 be passed by reference (when the URI points to an external resource) 28 or by value (when it points into the body of the message). This 29 follows the tradition of prior emergency services standardization 30 work where data can be conveyed by value within the call signaling 31 (i.e., in body of the SIP message) and also by reference. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 30, 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 (http://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Data Provider Information . . . . . . . . . . . . . . . . 6 70 3.1.1. Data Provider String . . . . . . . . . . . . . . . . . 7 71 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . . 7 72 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 7 73 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 8 74 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 8 75 3.1.6. Data Provider Languages(s) Supported . . . . . . . . . 9 76 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . . 9 77 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 10 78 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . . 10 79 3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . . 11 80 3.2. Service Information . . . . . . . . . . . . . . . . . . . 13 81 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 13 82 3.2.2. Service Delivered by Provider to End User . . . . . . 14 83 3.2.3. Service Mobility Environment . . . . . . . . . . . . . 16 84 3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 16 85 3.3. Device Information . . . . . . . . . . . . . . . . . . . . 16 86 3.3.1. Device Classification . . . . . . . . . . . . . . . . 17 87 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 18 88 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19 89 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . . 19 90 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 19 91 3.3.6. Device/Service Specific Additional Data Structure . . 20 92 3.3.7. Device/Service Specific Additional Data Structure Type 21 93 3.3.8. Choosing between defining a new type of block or new type 94 of device/service specific additional data . . . . . . 21 95 3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22 96 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . . 22 97 3.4.1. xCard for Subscriber's Data . . . . . . . . . . . . . 22 98 3.4.2. emergencyCall.SubInfo Example . . . . . . . . . . . . 23 99 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 26 101 3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 26 102 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 4.1. Transmitting Blocks using the Call-Info Header . . . . . . 28 104 4.2. Transmitting Blocks by Reference using the Provided-By 105 Element . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 4.3. Transmitting Blocks by Value using the Provided-By Element 29 107 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 30 109 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 35 111 6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 35 112 6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . . 36 113 6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . . 37 114 6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . . 38 115 6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . . 39 116 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . . 40 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 118 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 43 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 120 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 45 121 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 45 122 9.1.2. Service Provider Type Registry . . . . . . . . . . . . 46 123 9.1.3. Service Delivered Registry . . . . . . . . . . . . . . 46 124 9.1.4. Device Classification Registry . . . . . . . . . . . . 47 125 9.1.5. Device ID Type Type Registry . . . . . . . . . . . . . 47 126 9.1.6. Device/Service Data Type Registry . . . . . . . . . . 47 127 9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48 128 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 48 129 9.3. URN Sub-Namespace Registration for provided-by Registry Entr 49 130 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 49 131 9.4.1. MIME Content-type Registration for 132 'application/emergencyCall.ProviderInfo+xml' . . . . . 49 133 9.4.2. MIME Content-type Registration for 134 'application/emergencyCall.SvcInfo+xml' . . . . . . . 50 135 9.4.3. MIME Content-type Registration for 136 'application/emergencyCall.DevInfo+xml' . . . . . . . 51 137 9.4.4. MIME Content-type Registration for 138 'application/emergencyCall.SubInfo+xml' . . . . . . . 52 139 9.4.5. MIME Content-type Registration for 140 'application/emergencyCall.Comment+xml' . . . . . . . 52 141 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 53 142 9.5.1. Registration for 143 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . . 53 144 9.5.2. Registration for 145 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . . 54 146 9.5.3. Registration for 147 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . . 55 148 9.5.4. Registration for 149 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . . 55 150 9.5.5. Registration for 151 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . . 56 152 9.5.6. Registration for 153 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . . 57 154 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 57 155 9.7. VCard Parameter Value Registration . . . . . . . . . . . . 58 156 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 157 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 158 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 159 11.2. Informational References . . . . . . . . . . . . . . . . 60 160 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . . 60 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81 163 1. Introduction 164 When an IP-based emergency call is initiated a rich set of data from 165 multiple data sources is conveyed to the Public Safety Answering 166 Point (PSAP). This data includes information about the calling party 167 identity, the multimedia capabilities of the device, the emergency 168 service number, location information, and meta-data about the sources 169 of the data. The device, the access network provider, and any 170 service provider in the call path may have even more information 171 useful for a PSAP. This document extends the basic set of data 172 communicated with an IP-based emergency call, as described in 173 [RFC6443] and [RFC6881], in order to carry additional data which may 174 be useful to an entity or call taker handling the call. This data is 175 "additional" to the basic information found in the emergency call 176 signaling used. 178 In general, there are three categories of data communicated in an 179 emergency call: 181 Data Associated with a Location: Location data is conveyed in the 182 Presence Information Data Format Location Object (PIDF-LO) data 183 structure originally defined in RFC 4119 [RFC4119] and extended by 184 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 185 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 186 geodetic location information), and [I-D.ietf-geopriv-relative- 187 location] (for relative location). There may be data that is 188 specific to the location not available in the location data 189 structure itself, such as floor plans, tenant and building owner 190 contact data, heating, ventilation and air conditioning (HVAC) 191 status, etc. 193 Data Associated with a Call: While information is carried in the call 194 setup procedure itself (as part of the SIP headers as well as in 195 the body of the SIP message), there is additional data known by 196 the device making the call, and the service provider along the 197 path of the call. This information may include the service 198 provider contact information, subscriber identity and contact 199 information, the type of service the service provider and the 200 access network provider offer, what kind of device is being used, 201 etc. Some data is device or service dependent data. For example, 202 a car telematics system may have crash information. A medical 203 monitoring device may have sensor data. 205 Data Associated with a Caller: This is personal data about a caller, 206 such as medical information and emergency contact data. 208 This document only defines data structures relevant to data 209 associated with the call but defines extension points for other data 210 to be added via other specifications. 212 For interoperability, there needs to be a common way for the 213 information conveyed to a PSAP to be encoded and identified. 214 Identification allows emergency services authorities to know during 215 call processing which types of data are present and to determine if 216 they wish to access it. A common encoding allows the data to be 217 accessed. 219 This document defines the data structures and a way to communicate 220 the information in several ways. Although current standardization 221 efforts around IP-based emergency services are focused on the Session 222 Initiation Protocol (SIP) and HTTP the data structures in XML format 223 described in this document are usable for other communication systems 224 as well. In Section 3 the data structures are defined and the SIP/ 225 HTTP transport components are defined in Section 4 to offer a clear 226 separation between the two. 228 More technically, the data structure described in this document is 229 represented as one or more "blocks" of information. Each of the 230 blocks is an XML structure with an associated Multipurpose Internet 231 Mail Extensions (MIME) type for encapsulation, and an extensible set 232 of these types constitute the data set. A registry is defined to 233 list the block types that may be included. 235 2. Terminology 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 239 document are to be interpreted as described in RFC 2119 [RFC2119]. 241 This document also uses terminology from [RFC5012]. We use the term 242 service provider to refer to an Application Service Provider (ASP). A 243 Voice Service Provider (VSP) is a special type of ASP. With the term 244 "Access Network Provider" we refer to the Internet Access Provider 245 (IAP) and the Internet Service Provider (ISP) without further 246 distinguishing these two entities, since the difference between the 247 two is not relevant for this document. Note that the roles of ASP 248 and access network provider may be provided by a single company. 250 In the data block definitions, see Section 3, the values for the 251 "Use:" label are specified as one of: 253 'Required': means they must be present in the data structure. 255 'Conditional': means they must be present unless the specified 256 condition is met, in which case the they may be present. 258 'Optional': means they may be present. 260 vCard is a data format for representing and exchanging a variety of 261 information about individuals and other entities. For applications 262 that use XML the format defined in vCard is not immediately 263 applicable. For this purpose an XML-based encoding of the 264 information elements defined in the vCard specification has been 265 defined and the name of that specification is xCard. Since the term 266 vCard is more familiar to most readers we use the term xCard and 267 vCard interchangeable but it would be accurate to use the term vCard 268 only. 270 3. Data Structures 272 This section defines the following five data structures, each as a 273 data block. For each block we define the MIME type, and the XML data 274 structure. The five data structures are: 276 'Data Provider': This block supplies name and contact information for 277 the entity that created the data. Section 3.1 provides the 278 details. 280 'Service Information': This block supplies information about the 281 service. The description can be found in Section 3.2. 283 'Device Information': This block supplies information about the 284 device placing the call. Device information can be found in 285 Section 3.3. 287 'Owner/Subscriber': This block supplies information about the owner 288 of the device or about the subscriber. Details can be found in 289 Section 3.4. 291 'Comment': This block provides a way to supply free form human 292 readable text to the PSAP or emergency responders. This simple 293 structure is defined in Section 3.5. 295 Note that the xCard format is re-used in some of the data structures 296 to provide contact information. In an xCard there is no way to 297 specify a "main" telephone number. These numbers are useful to 298 emergency responders who are called to a large enterprise. This 299 document adds a new property value to the "tel" property of the TYPE 300 parameter called "main". It can be used in any xCard in additional 301 data. 303 3.1. Data Provider Information 305 This block is intended to be provided by any service provider in the 306 path of the call or the access network provider. It includes 307 identification and contact information. This block SHOULD be 308 provided by every service provider in the call path, and by the 309 access network provider. Devices MAY use this block to provide 310 identifying information. The MIME subtype is "application/ 311 emergencyCall.ProviderInfo+xml". 313 3.1.1. Data Provider String 315 Data Element: Data Provider String 317 Use: Required 319 XML Element: 321 Description: This is a plain language string suitable for displaying 322 the name of the service provider that created the additional data 323 structure. If the device created the structure the value is 324 identical to the contact header in the SIP INVITE. 326 Reason for Need: Inform the call taker of the identity of the entity 327 providing the additional call data structure. 329 How Used by Call Taker: Allows the call taker to interpret the data 330 in this structure. The source of the information often influences 331 how the information is used, believed or verified. 333 3.1.2. Data Provider ID 335 Data Element: Data Provider ID 337 Use: Conditional. Must be provided if the service provider is 338 located in a jurisdiction that maintains such ids. Devices are 339 not required to provide it. 341 XML Element: 343 Description: A jurisdiction specific code for the provider shown in 344 the element that created the structure of the 345 call. This data SHOULD be provided if the local jurisdiction 346 maintains such an ID list. For example, in North America, this 347 would be a "NENA Company ID". Devices SHOULD NOT use this 348 element. 350 Reason for Need: Inform the call taker of the identity of the entity 351 providing the additional call data structure. 353 How Used by Call Taker: Where jurisdictions have lists of providers 354 the Data Provider ID can be useful. 356 3.1.3. Data Provider ID Series 358 Data Element: Data Provider ID Series 360 Use: Conditional. If Data Provider ID is provided, Data Provider ID 361 Series is required. 363 XML Element: 364 Description: Identifies the issuer of the ProviderId. A registry 365 will reflect the following valid entries: 367 * NENA 369 * EENA 371 Reason for Need: Identifies how to interpret the Data Provider ID. 373 How Used by Call Taker: Determines which provider ID registry to 374 consult for more information 376 3.1.4. Type of Data Provider 378 Data Element: Type of Data Provider ID 380 Use: Conditional. If Data Provider ID is provided, Type of Data 381 Provider ID is required. 383 XML Element: 385 Description: Identifies the type of data provider id being supplied 386 in the ProviderId data element. A registry with an initial set of 387 values is shown in Figure 1. 389 +------------------------------+------------------------------------+ 390 | Token | Description | 391 +------------------------------+------------------------------------+ 392 |Access Network Provider | Access network service provider | 393 |Service Provider | Calling or Origination telecom SP | 394 |Service Provider Subcontractor| A contractor to another kind of SP | 395 |Telematics Provider | A sensor based SP, especially | 396 | | vehicle based | 397 |Language Translation Provider | A spoken language translation SP | 398 |Expert Advice Provider | An SP giving expert advice | 399 |Emergency Modality Translation| An emergency call specific | 400 | | modality translation service | 401 | | e.g. for sign language | 402 |Relay Provider | A interpretation SP, for example, | 403 | | video relay for sign language | 404 | | interpreting | 405 |Other | Any other type of service provider | 406 +------------------------------+------------------------------------+ 408 Reason for Need: Identifies what kind of data provider this is. 410 How Used by Call Taker: To decide who to contact when further 411 information is needed 413 3.1.5. Data Provider Contact URI 415 Data Element: Data Provider Contact URI 416 Use: Required 418 XML Element: 420 Description: For a service provider the contact SHOULD be a contact 421 URI. This MUST be a SIP URI. If a telephone number is the contact 422 address it should be provided in the form of 423 sip:telephonenumber@serviceprovider:user=phone. If the call is 424 from a device, this would reflect the contact information of the 425 owner of the device. When provided by a service provider, this 426 would be a URI to a 24/7 support organization tasked to provide 427 PSAP support for this emergency call. 429 Reason for Need: Additional data providers may need to be contacted 430 for error or other unusual circumstances. 432 How Used by Call Taker: To contact the supplier of the additional 433 data for assistance in handling the call. 435 3.1.6. Data Provider Languages(s) Supported 437 Data Element: Data Provider Language(s) supported 439 Use: Conditional 441 XML Element: 443 Description: The language used by the entity at the Data Provider 444 Contact URI as an alpha 2-character code as defined in ISO 445 639-1:2002 Codes for the representation of names of languages -- 446 Part 1: Alpha-2 code Multiple instances of this element may occur. 447 Order is significant; preferred language should appear first. 448 This data is required if a Data Provider Contact URI is provided. 449 The content must reflect the languages supported at the contact 450 URI. 452 Reason for Need: Information needed to determine if emergency service 453 authority can communicate with the service provider or if an 454 interpreter will be needed. 456 How Used by Call Taker: If call taker cannot speak language(s) 457 supported by the service provider, a translation service will need 458 to be added to the conversation. 460 3.1.7. xCard of Data Provider 462 Data Element: xCard of Data Provider 464 Use: Optional 466 XML Element: 467 Description: There are many fields in the xCard and the creator of 468 the data structure is encouraged to provide as much information as 469 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 470 minimum. N should contain name of support group or device owner 471 as appropriate. If more than one TEL property is provided, a 472 parameter from the vCard Property Value registry MUST be specified 473 on each TEL. For encoding of the xCard this specification uses 474 the XML-based encoding specified in [RFC6351]. and is hereinafter 475 referred to as "xCard" 477 Reason for Need: Information needed to determine additional contact 478 information. 480 How Used by Call Taker: Assists call taker by providing additional 481 contact information that may not be included in the SIP invite or 482 the PIDF-LO. 484 3.1.8. Subcontractor Principal 486 Data Element: Subcontractor Principal 488 XML Element: 490 Description: If the data provider is a subcontractor to another 491 provider such as an access infrastructure provider or telematics 492 provider, this element contains the DataProviderString of the 493 service provider to indicate which provider the subcontractor is 494 working for. This data is required if the Data Provider type is 495 subcontractor. 497 Reason for Need: Identify the entity the subcontractor works for. 499 How Used by Call Taker: Allows the call taker to understand what the 500 relationship between data providers and the service providers in 501 the path of the call are. 503 3.1.9. Subcontractor Priority 505 Data Element: Subcontractor Priority 507 Use: Required 508 XML Element: 510 Description: If the subcontractor should be contacted first, this 511 element should have a "sub" value. If the access or origination 512 service provider should be contacted first, this element should 513 have a "main" value. This data is required if the Data Provider 514 type is "subcontractor". 516 Reason for Need: Inform the call taker whether the network operator 517 or the subcontractor should be contacted first if support is 518 needed. 520 How Used by Call Taker: To decide which entity to contact first if 521 assistance is needed. 523 3.1.10. emergencyCall.ProviderInfo Example 524 525 528 Example VoIP Provider 529 530 urn:nena:companyid:ID123 531 NENA 532 Service Provider 533 sip:voip-provider@example.com 534 EN 535 537 538 Hannes Tschofenig 539 540 Hannes 541 Tschofenig 542 543 544 Dipl. Ing. 545 546 --0203 547 548 20090808T1430-0500 549 550 M 551 552 1 553 554 de 555 556 557 2 558 559 en 560 561 562 work 563 564 Example VoIP Provider 565 566 567 568 work 569 573 574 575 576 Linnoitustie 6 577 Espoo 578 Uusimaa 579 02600 580 Finland 581 582 583 584 585 work 586 voice 587 588 589 tel:+358 50 4871445 590 591 592 work 593 594 hannes.tschofenig@nsn.com 595 596 597 work 598 599 geo:60.210796,24.812924 600 601 602 home 603 604 605 http://www.tschofenig.priv.at/key.asc 606 607 608 Finland/Helsinki 609 610 home 611 612 http://www.tschofenig.priv.at 613 614 615 616 618 3.2. Service Information 620 This block describes the service that the service provider provides 621 to the caller. It SHOULD be included by all SPs in the path of the 622 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 624 3.2.1. Service Environment 626 Data Element: Service Environment 628 Use: Required 629 XML Element: 631 Description: This element defines whether a call is from a business 632 or residence caller. Currently, the only valid entries are 633 'Business' or 'Residence'. 635 Reason for Need: To assist in determining equipment and manpower 636 requirements. 638 How Used by Call Taker: Information may be used to assist in 639 determining equipment and manpower requirements for emergency 640 responders. As the information is not always available, and the 641 registry is not all encompassing, this is at best advisory 642 information, but since it mimics a similar capability in some 643 current emergency calling systems, it is known to be valuable. 644 The service provider uses its best information (such as a rate 645 plan, facilities used to deliver service or service description) 646 to determine the information and is not responsible for 647 determining the actual characteristics of the location where the 648 call originates from. 650 3.2.2. Service Delivered by Provider to End User 652 Data Element: Service Delivered by Provider to End User 654 Use: Required 656 XML Element: 658 Description: This defines the type of service the end user has 659 subscribed to. The implied mobility of this service cannot be 660 relied upon. A registry with an initial set of values is defined 661 in Figure 3. 663 +--------+----------------------------------------+ 664 | Name | Description | 665 +--------+----------------------------------------+ 666 | Wrless | Wireless Telephone Service: Includes | 667 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 668 | | LTE (Long Term Evolution) | 669 | Coin | Fixed Public Pay/Coin telephones: Any | 670 | | coin or credit card operated device | 671 | 1way | One way outbound service | 672 | Prison | Inmate call/service | 673 | Temp | Soft dialtone/quick service/warm | 674 | | disconnect/suspended | 675 | MLTS | Multi-line telephone system: Includes | 676 | | all PBX, Centrex, key systems, | 677 | | Shared Tenant Service | 678 | SenseU | Sensor, unattended: Includes devices | 679 | | that generate DATA ONLY. This is | 680 | | one-way information exchange and | 681 | | there will be no other form of | 682 | | communication | 683 | SenseA | Sensor, attended: Includes devices | 684 | | that are supported by a monitoring | 685 | | service provider or automatically | 686 | | open a two-way communication path | 687 | POTS | Wireline: Plain Old Telephone Service | 688 | VOIP | VoIP Telephone Service: A type of | 689 | | service that offers communication | 690 | | over internet protocol, such as Fixed| 691 | | Nomadic, Mobile, ... | 692 | Remote | Off premise extension | 693 | Relay | Relay Service: a type of service where | 694 | | there is a human 3rd party agent who | 695 | | provides some kind of additional | 696 | | assistance to the caller. Includes | 697 | | sign language relay and telematics | 698 | | services which provide a service | 699 | | assistant on the call. | 700 +--------+----------------------------------------+ 702 More than one value MAY be returned. For example, a VoIP inmate 703 telephone service is a reasonable combination. 705 Reason for Need: Knowing the type of service may assist the PSAP with 706 the handling of the call. 708 How Used by Call Taker: Call takers often use this information to 709 determine what kinds of questions to ask callers, and how much to 710 rely on supportive information. An emergency call from a prison 711 is treated differently that a call from a sensor device. As the 712 information is not always available, and the registry is not all 713 encompassing, this is at best advisory information, but since it 714 mimics a similar capability in some current emergency calling 715 systems, it is known to be valuable. 717 3.2.3. Service Mobility Environment 719 Data Element: Service Mobility Environment 721 Use: Required 723 XML Element: 725 Description: This provides the service providers view of the mobility 726 of the caller. As the service provider may not know the 727 characteristics of the actual access network used, the value not 728 be relied upon. A registry will reflect the following initial 729 valid entries: 731 * Mobile: the device should be able to move at any time 733 * Fixed: the device is not expected to move unless the service is 734 relocated 736 * Nomadic: the device is not expected to change its point of 737 attachment while on a call 739 * Unknown: no information is known about the service mobility 740 environment for the device 742 Reason for Need: Knowing the service provider's belief of mobility 743 may assist the PSAP with the handling of the call. 745 How Used by Call Taker: To determine whether to assume the location 746 of the caller might change. 748 3.2.4. emergencyCall.SvcInfo Example 750 751 754 Business 755 MLTS 756 Fixed 757 759 3.3. Device Information 761 This block provides information about the device used to place the 762 call. It should be provided by any service provider that knows what 763 device is being used, and by the device itself. The mime subtype is 764 "application/emergencyCall.DevInfo+xml". 766 3.3.1. Device Classification 768 Data Element: Device Classification 770 Use: Optional 772 XML Element: 774 Description: This data element defines the kind of device making the 775 emergency call. If the device provides the data structure, the 776 device information SHOULD be provided. If the service provider 777 provides the structure and it knows what the device is, the 778 service provider SHOULD provide the device information. Often the 779 carrier does not know what the device is. It is possible to 780 receive two Additional Data Associated with a Call data 781 structures, one created by the device and one created by the 782 service provider. This information describes the device, not how 783 it is being used. This data element defines the kind of device 784 making the emergency call. The registry with the initial set of 785 values is shown in Figure 5. 787 +--------+----------------------------------------+ 788 | Token | Description | 789 +--------+----------------------------------------+ 790 |Cordless| Cordless handset | 791 | Fixed | Fixed phone | 792 | Mobile | Mobile handset | 793 | ATA | analog terminal adapter | 794 |Satphone| Satellite phone | 795 | FSense | Stationary computing device (alarm | 796 | | system, data sensor) | 797 | Guard | Guardian devices | 798 | Desktop| Desktop PC | 799 | Laptop | Laptop computing device | 800 | Tablet | Tablet computing device | 801 | Alarm | Alarm system | 802 | MSense | Mobile Data sensor | 803 | Beacon | Personal beacons (spot) | 804 | Auto | Auto telematics | 805 | Truck | Truck telematics | 806 | Farm | Farm equipment telematics | 807 | Marine | Marine telematics | 808 | PDA | Personal digital assistant | 809 | PND | Personal navigation device) | 810 | SmrtPhn| Smart phone | 811 | Itab | Internet tablet | 812 | Game | Gaming console | 813 | Video | Video phone | 814 | Text | Other text device | 815 | NA | Not Available | 816 +--------+----------------------------------------+ 818 Reason for Need: The device classification implies the capability of 819 the calling device and assists in identifying the meaning of the 820 emergency call location information that is being presented. For 821 example, does the device require human intervention to initiate a 822 call or is this call the result of programmed instructions? Does 823 the calling device have the ability to update location or 824 condition changes? Is this device interactive or a one-way 825 reporting device? 827 How Used by Call Taker: May assist with location of caller. For 828 example, a cordless handset may be outside or next door. May 829 provide the calltaker some context about the caller, the 830 capabilities of the device used for the call or the environment 831 the device is being used in. 833 3.3.2. Device Manufacturer 835 Data Element: Device Manufacturer 837 Use: Optional 838 XML Element: 840 Description: The plain language name of the manufacturer of the 841 device. 843 Reason for Need: Used by PSAP management for post-mortem 844 investigation/resolution. 846 How Used by Call Taker: Probably not used by the calltaker, but by 847 PSAP management. 849 3.3.3. Device Model Number 851 Data Element: Device Model Number 853 Use: Optional 855 XML Element: 857 Description: Model number of the device. 859 Reason for Need: Used by PSAP management for after action 860 investigation/resolution. 862 How Used by Call Taker: Probably not used by the calltaker, but by 863 PSAP management. 865 3.3.4. Unique Device Identifier 867 Data Element: Unique Device Identifier 869 Use: Optional 871 XML Element: 873 Description: String that identifies the specific device making the 874 call or creating an event. 876 Reason for Need: Uniquely identifies the device as opposed to any 877 signaling identifiers encountered in the call signaling stream. 879 How Used by Call Taker: Probably not used by the calltaker they would 880 need to refer to management for investigation. 882 3.3.5. Type of Device Identifier 884 Data Element: Type of Device Identifier 886 Use: Conditional: must be provided if the DeviceID is provided 888 XML Element: 889 Description: Identifies the type of device identifier being generated 890 in the unique device identifier data element. A registry with an 891 initial set of values can be seen in Figure 6. 893 +--------+----------------------------------------+ 894 | Token | Description | 895 +--------+----------------------------------------+ 896 | MEID | Mobile Equipment Identifier (CDMA) | 897 | ESN | Electronic Serial Number(GSM) | 898 | MAC | Media Access Control Address (IEEE) | 899 | WiMAX | Device Certificate Unique ID | 900 | IMEI | International Mobile Equipment ID (GSM)| 901 | UDI | Unique Device Identifier | 902 | RFID | Radio Frequency Identification | 903 | SN | Manufacturer Serial Number | 904 +--------+----------------------------------------+ 906 Reason for Need: Identifies how to interpret the Unique Device 907 Identifier. 909 How Used by Call Taker: Additional information that may be used to 910 assist with call handling. 912 3.3.6. Device/Service Specific Additional Data Structure 914 Data Element: Device/service specific additional data structure 916 Use: Optional 918 XML Element: 920 Description: A URI representing additional data whose schema is 921 specific to the device or service which created it. An example is 922 the VEDs structure for a vehicle telematics device. The URI, when 923 dereferenced, MUST yield a data structure defined by the Device/ 924 service specific additional data type value. Different data may 925 be created by each classification; e.g., telematics creates VEDS 926 data set. 928 Reason for Need: Provides device/service specific data that may be 929 used by the call taker and/or responders. 931 How Used by Call Taker: Provide information to guide call takers to 932 select appropriate responders, give appropriate pre-arrival 933 instructions to callers, and advise responders of what to be 934 prepared for. May be used by responders to guide assistance 935 provided. 937 3.3.7. Device/Service Specific Additional Data Structure Type 939 Data Element: Type of Device/service specific additional data 940 structure 942 Use: Conditional. MUST be provided when Device/service specific 943 additional URI is provided 945 XML Element: 947 Description: Value from a registry defined by this document to 948 describe the type of data that can be retrieved from the Device/ 949 service specific additional data structure. Initial values are: 951 * IEEE 1512 - USDOT Model for traffic incidents 953 * VEDS 955 Reason for Need: This data element allows identification of 956 externally defined schemas, which may have additional data that 957 may assist in emergency response. 959 How Used by Call Taker: This data element allows the end user 960 (calltaker or first responder) to know what type of additional 961 data may be available to aid in providing the needed emergency 962 services. 964 Note: Information which is specific to a location or a caller 965 (person) should not be placed in this section. 967 3.3.8. Choosing between defining a new type of block or new type of 968 device/service specific additional data 970 For devices that have device or service specific data, there are two 971 choices to carry it. A new block can be defined, or the device/ 972 service specific additional data URL the DevInfo block can be used 973 and a new type for it defined . The data passed would likely be the 974 same in both cases. Considerations for choosing which mechanism to 975 register under include: 977 Applicability: Information which will be carried by many kinds of 978 devices or services are more appropriately defined as separate 979 blocks. 981 Privacy: Information which may contain private data may be better 982 sent in the DevInfo block, rather than a new block so that 983 implementations are not tempted to send the data by value, and 984 thus having more exposure to the data than forcing the data to be 985 retrieved via the URL in DevInfo. 987 Size: Information which may be very may be better sent in the DevInfo 988 block, rather than a new block so that implementations are not 989 tempted to send the data by value. Conversely, data which is 990 small may best be sent in a separate block so that it can be sent 991 by value 993 Availability of a server: Providing the data via the device block 994 requires a server be made available to retrieve the data. 995 Providing the data via new block allows it to be sent by value 996 (CID). 998 3.3.9. emergencyCall.DevInfo Example 1000 1001 1004 Fixed phone 1005 Nokia 1006 Lumia 800 1007 35788104 1008 IMEI 1009 1011 3.4. Owner/Subscriber Information 1013 This block describes the owner of the device (if provided by the 1014 device) or the subscriber information, if provided by a service 1015 provider. The contact location is not necessarily the location of 1016 the caller or incident, but is rather the nominal contact address. 1017 The mime subtype is "application/emergencyCall.Subscriber+xml". 1019 3.4.1. xCard for Subscriber's Data 1021 Data Element: xCARD for Subscriber's Data 1023 Use: Conditional: Some services (e.g., prepaid phones, initialized 1024 phones, etc.) may not have this information. 1026 XML Element: 1028 Description: Information known by the service provider or device 1029 about the subscriber; e.g., Name, Address, Individual Telephone 1030 Number, Main Telephone Number and any other data. N, ORG (if 1031 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1032 than one TEL property is provided, a parameter from the vCard 1033 Property Value registry MUST be specified on each TEL. 1035 Reason for Need: When the caller is unable to provide information, 1036 this data may be used to obtain it 1038 How Used by Call Taker: Obtaining critical information about the 1039 caller and possibly the location when it is not able to be 1040 obtained otherwise. 1042 3.4.2. emergencyCall.SubInfo Example 1043 1044 1047 1048 1049 1050 Simon Perreault 1051 1052 Perreault 1053 Simon 1054 1055 1056 ing. jr 1057 M.Sc. 1058 1059 --0203 1060 1061 20090808T1430-0500 1062 1063 M 1064 1065 1 1066 1067 fr 1068 1069 1070 2 1071 1072 en 1073 1074 1075 work 1076 1077 Viagenie 1078 1079 1080 1081 work 1082 1086 1087 1088 1089 2875 boul. Laurier, suite D2-630 1090 Quebec 1091 QC 1092 G1V 2M2 1093 Canada 1095 1096 1097 1098 1099 work 1100 voice 1101 1102 1103 tel:+1-418-656-9254;ext=102 1104 1105 1106 1107 1108 work 1109 text 1110 voice 1111 cell 1112 video 1113 1114 1115 tel:+1-418-262-6501 1116 1117 1118 work 1119 1120 simon.perreault@viagenie.ca 1121 1122 1123 work 1124 1125 geo:46.766336,-71.28955 1126 1127 1128 work 1129 1130 1131 http://www.viagenie.ca/simon.perreault/simon.asc 1132 1133 1134 America/Montreal 1135 1136 home 1137 1138 http://nomis80.org 1139 1140 1141 1142 1143 1145 3.5. Comment 1146 This block provides a mechanism for the data provider to supply 1147 extra, human readable information to the PSAP. It is not intended for 1148 a general purpose extension mechanism. The mime subtype is 1149 "application/emergencyCall.Comment+xml" 1151 3.5.1. Comment 1153 Data Element: EmergencyCall.Comment 1155 Use: Optional 1157 XML Element: 1159 Description: Human readable text providing additional information to 1160 the PSAP staff. 1162 Reason for Need: Explanatory information for values in the data 1163 structure 1165 How Used by Call Taker: To interpret the data provided 1167 3.5.2. emergencyCall.Comment Example 1169 1170 1173 This is an example text. 1174 1176 4. Transport 1178 This section defines how to convey additional data to an emergency 1179 service provider. Two different means are specified: the first uses 1180 the call signaling; the second uses the element of a 1181 PIDF-LO [RFC4119]. 1183 1. First, the ability to embed a Uniform Resource Identifier (URI) 1184 in an existing SIP header field, the Call-Info header, is 1185 defined. The URI points to the additional data structure. The 1186 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1187 document adds a new compound token starting with the value 1188 'emergencyCallData' for the Call-Info "purpose" parameter. If 1189 the "purpose" parameter is set to a value starting with 1190 'emergencyCallData', then the Call-Info header contains either an 1191 HTTPS URL pointing to an external resource or a CID (content 1192 indirection) URI that allows the data structure to be placed in 1193 the body of the SIP message. The "purpose" parameter also 1194 indicates the kind of data (by its MIME type) that is available 1195 at the URI. As the data is conveyed using a URI in the SIP 1196 signaling, the data itself may reside on an external resource, or 1197 may be contained within the body of the SIP message. When the 1198 URI refers to data at an external resource, the data is said to 1199 be passed by reference. When the URI refers to data contained 1200 within the body of the SIP message, the data is said to be passed 1201 by value. A PSAP or emergency responder is able to examine the 1202 type of data provided and selectively inspect the data it is 1203 interested in, while forwarding all of it (the values or 1204 references) to downstream entities. To be conveyed in a SIP 1205 body, additional data about a call is defined as a series of MIME 1206 objects. Each block defined in this document is an XML data 1207 structure identified by its MIME type. (Blocks defined by others 1208 may be encoded in XML or not, as identified by their MIME 1209 registration.) As usual, whenever more than one MIME part is 1210 included in the body of a message, MIME-multipart (i.e., 1211 'multipart/mixed') encloses them all. This document defines a 1212 set of XML schemas and MIME types used for each block defined 1213 here. When additional data is passed by value in the SIP 1214 signaling, each CID URL points to one block in the body. 1215 Multiple URIs are used within a Call-Info header field (or 1216 multiple Call-Info header fields) to point to multiple blocks. 1217 When additional data is provided by reference (in SIP signaling 1218 or Provided-By), each HTTPS URL references one block; the data is 1219 retrieved with an HTTPS GET operation, which returns one of the 1220 blocks as an object (the blocks defined here are returned as XML 1221 objects). 1223 2. Second, the ability to embed additional data structures in the 1224 element of a PIDF-LO [RFC4119] is defined. Besides 1225 a service provider in the call path, the access network provider 1226 may also have similar information that may be valuable to the 1227 PSAP. The access network provider may provide location in the 1228 form of a PIDF-LO from a location server via a location 1229 configuration protocol. The data structures described in this 1230 document are not specific to the location itself, but rather 1231 provides descriptive information having to do with the immediate 1232 circumstances about the provision of the location (who the access 1233 network is, how to contact that entity, what kind of service the 1234 access network provides, subscriber information, etc.). This 1235 data is similar in nearly every respect to the data known by 1236 service providers in the path of the call. When the access 1237 network provider and service provider are separate entities, the 1238 access network does not participate in the application layer 1239 signaling (and hence cannot add a Call-Info header field to the 1240 SIP message), but may provide location information to assist in 1241 locating the caller's device. The element of the 1242 PIDF-LO is a mechanism for the access network provider to supply 1243 the information about the entity or organization that supplied 1244 this location information. For this reason, this document 1245 describes a namespace per RFC 4119 for inclusion in the 1246 element of a PIDF-LO for adding information known 1247 to the access network provider. 1249 One or more blocks of data registered in the Emergency Call 1250 Additional Data registry, as defined in Section 9.1, may be included 1251 or referenced in the SIP signaling (using the Call-Info header field) 1252 or in the element of a PIDF-LO. Every block must be one 1253 of the types in the registry. Since the data of an emergency call 1254 may come from multiple sources, the data itself needs information 1255 describing the source. Consequently, each entity adding additional 1256 data MUST supply the "Data Provider" block. All other blocks are 1257 optional, but each entity SHOULD supply any blocks where it has at 1258 least some of the information in the block. 1260 4.1. Transmitting Blocks using the Call-Info Header 1262 A URI to a block MAY be inserted in a SIP request or response method 1263 (most often INVITE or MESSAGE) with a Call-Info header field 1264 containing a purpose value starting with 'emergencyCallData' and the 1265 type of data available at the URI. The type of data is denoted by 1266 including the root of the MIME type (not including the 1267 'emergencyCall' prefix and any suffix such as '+xml') with a '.' 1268 separator. For example, when referencing a block with MIME type 1269 'application/emergencyCall.ProviderInfo+xml', the 'purpose' parameter 1270 is set to 'emergencyCallData.ProviderInfo'. An example "Call-Info" 1271 header field for this would be: 1273 Call-Info: https://www.example.com/23sedde3; 1274 purpose="emergencyCallData.ProviderInfo" 1276 A Call-info header with a purpose value starting with 1277 'emergencyCallData' MUST only be sent on an emergency call, which can 1278 be ascertained by the presence of an emergency service urn in a Route 1279 header of a SIP message. 1281 If the data is provided by reference, an HTTPS URI MUST be included 1282 and consequently Transport Layer Security (TLS) protection is applied 1283 for protecting the retrieval of the information. 1285 The data may also be supplied by value in a SIP message. In this 1286 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1287 referencing the MIME body part. 1289 More than one Call-Info header with a purpose value starting with 1290 'emergencyCallData' can be expected, but at least one MUST be 1291 provided. The device MUST provide one if it knows no service 1292 provider is in the path of the call. The device MAY insert one if it 1293 uses a service provider. Any service provider in the path of the 1294 call MUST insert its own. For example, a device, a telematics 1295 service provider in the call path, as well as the mobile carrier 1296 handling the call will each provide one. There may be circumstances 1297 where there is a service provider who is unaware that the call is an 1298 emergency call and cannot reasonably be expected to determine that it 1299 is an emergency call. In that case, that service provider is not 1300 expected to provide emergencyCallData. 1302 4.2. Transmitting Blocks by Reference using the Provided-By Element 1304 The 'emergencyCallDataReference' element is used to transmit an 1305 additional data block by reference within a 'Provided-By' element of 1306 a PIDF-LO. The 'emergencyCallDataReference' element has two 1307 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1308 type of data block referenced. The value of 'ref' is an HTTPS URL 1309 that resolves to a data structure with information about the call. 1310 The value of 'purpose' is the same as used in a 'Call-Info' header 1311 field (as specified in Section 4.1). 1313 For example, to reference a block with MIME type 'application/ 1314 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1315 'emergencyCallData.ProviderInfo'. An example 1316 'emergencyCallDataReference' element for this would be: 1318 1321 4.3. Transmitting Blocks by Value using the Provided-By Element 1322 It is RECOMMENDED that access networks supply the data specified in 1323 this document by reference, but they MAY provide the data by value. 1325 The 'emergencyCallDataValue' element is used to transmit an 1326 additional data block by value within a 'Provided-By' element of a 1327 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1328 'purpose' to indicate the type of data block contained. The value of 1329 'purpose' is the same as used in a 'Call-Info' header field (as 1330 specified in Section 4.1, and in Section 4.1). The same XML 1331 structure as would be contained in the corresponding MIME type body 1332 part is placed inside the 'emergencyCallDataValue' element. 1334 For example: 1336 1338 1339 1341 1343 This is an example text. 1344 1345 1346 1347 1349 Test 1350 NENA 1351 Access Infrastructure Provider 1352 1353 sip:15555550987@burf.example.com;user=phone 1354 1355 1356 1358 4.4. The Content-Disposition Parameter 1360 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1361 It updates and clarifies handling originally defined in RFC 3261 1362 [RFC3261] based on implementation experience. While RFC 3261 did not 1363 mandate support for 'multipart' message bodies 'multipart/mixed' MIME 1364 bodies are, however, used by many extensions (including additional 1365 data) today. For example, adding a PIDF-LO, SDP, and additional data 1366 in body of a SIP message requires a 'multipart' message body. 1368 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1369 parameter for the Content-Disposition header field. These RFCs 1370 describe how a UAS reacts if it receives a message body whose content 1371 type or disposition type it does not understand. If the 'handling' 1372 parameter has the value "optional", the UAS ignores the message body. 1373 If the 'handling' parameter has the value "required", the UAS returns 1374 a 415 (Unsupported Media Type) response. The 'by-reference' 1375 disposition type allows a SIP message to contain a reference to the 1376 body part, and the SIP UA processes the body part according to the 1377 reference. This is the case for the Call-info header containing a 1378 Content Indirection (CID) URL. 1380 As an example, a SIP message indicates the Content-Disposition 1381 parameter in the body of the SIP message as shown in Figure 11. 1383 Content-Type: application/sdp 1385 ...Omit Content-Disposition here; defaults are ok 1386 ...SDP goes here 1388 --boundary1 1390 Content-Type: application/pidf+xml 1391 Content-ID: 1392 Content-Disposition: by-reference;handling=optional 1394 ...PIDF-LO goes here 1396 --boundary1-- 1398 Content-Type: application/emergencyCall.ProviderInfo+xml 1399 Content-ID: <1234567890@atlanta.example.com> 1400 Content-Disposition: by-reference;handling=optional 1402 ...Additional data goes here 1404 --boundary1-- 1406 5. Examples 1408 This section provides three examples of communicating additional 1409 data. In Figure 12 additional data is communicated in a SIP INVITE 1410 per value. In Figure 13 we illustrate how additional data is added 1411 by a SIP proxy per reference. Finally, an example for including 1412 additional data in the element of a PIDF-LO is 1413 illustrated. 1415 INVITE sips:bob@biloxi.example.com SIP/2.0 1416 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1417 Max-Forwards: 70 1418 To: Bob 1419 From: Alice ;tag=9fxced76sl 1420 Call-ID: 3848276298220188511@atlanta.example.com 1421 Call-Info: ;purpose=icon, 1422 ;purpose=info, 1423 1424 ;purpose=emergencyCallData.ProviderInfo 1425 Geolocation: 1426 Geolocation-Routing: no 1427 Accept: application/sdp, application/pidf+xml, 1428 application/emergencyCallProviderinfo+xml 1429 CSeq: 31862 INVITE 1430 Contact: 1431 Content-Type: multipart/mixed; boundary=boundary1 1433 Content-Length: ... 1435 --boundary1 1437 Content-Type: application/sdp 1439 ...SDP goes here 1441 --boundary1 1443 Content-Type: application/pidf+xml 1444 Content-ID: 1445 Content-Disposition: by-reference;handling=optional 1447 ...PIDF-LO goes here 1449 --boundary1-- 1451 Content-Type: application/emergencyCall.ProviderInfo+xml 1452 Content-ID: <1234567890@atlanta.example.com> 1453 Content-Disposition: by-reference;handling=optional 1455 ...Additional data goes here 1457 --boundary1-- 1458 INVITE sips:bob@biloxi.example.com SIP/2.0 1459 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1460 Max-Forwards: 70 1461 To: Bob 1462 From: Alice ;tag=9fxced76sl 1463 Call-ID: 3848276298220188511@atlanta.example.com 1464 Call-Info: ;purpose=icon, 1465 ;purpose=info, 1466 1467 ;purpose=emergencyCallData.ProviderInfo 1468 Geolocation: 1469 Geolocation-Routing: no 1470 Accept: application/sdp, application/pidf+xml, 1471 application/emergencyCallProviderinfo+xml 1472 CSeq: 31862 INVITE 1473 Contact: 1474 Content-Type: multipart/mixed; boundary=boundary1 1476 Content-Length: ... 1478 --boundary1 1480 Content-Type: application/sdp 1482 ...SDP goes here 1484 --boundary1 1486 Content-Type: application/pidf+xml 1487 Content-ID: 1488 Content-Disposition: by-reference;handling=optional 1490 ...PIDF-LO goes here 1492 --boundary1-- 1494 1495 1500 1501 1502 1503 1505 AU 1506 NSW 1507 Wollongong 1508 North Wollongong 1509 Flinders 1510 Street 1511 Campbell Street 1512 Gilligan's Island 1513 Corner 1514 Video Rental Store 1515 2500 1516 Westerns and Classics 1517 store 1518 Private Box 15 1519 1520 1521 1522 true 1523 1524 2013-07-10T20:00:00Z 1525 1526 1527 802.11 1528 1531 1534 1535 1537 University of California, Irvine 1538 1539 urn:nena:companyid:uci 1540 NENA 1541 Other 1542 tel:+1 9498245222 1543 EN 1544 1545 1547 This is an example text. 1548 1550 1551 1552 1553 mac:1234567890ab 1554 2013-07-09T20:57:29Z 1555 1556 1558 6. XML Schemas 1560 This section defines the XML schemas of the five data blocks. 1561 Additionally, the Provided-By schema is specified. 1563 6.1. emergencyCall.ProviderInfo XML Schema 1564 1565 1574 1577 1579 1580 1581 1582 1583 1585 1589 1590 1591 1593 1595 1597 1599 1601 1603 1607 1609 1610 1612 1614 6.2. emergencyCall.SvcInfo XML Schema 1615 1616 1623 1626 1628 1629 1630 1632 1634 1636 1639 1641 1642 1644 1646 6.3. emergencyCall.DevInfo XML Schema 1647 1648 1655 1658 1660 1661 1662 1664 1666 1668 1670 1672 1674 1677 1679 1680 1682 1684 6.4. emergencyCall.SubInfo XML Schema 1685 1686 1694 1697 1699 1701 1702 1703 1706 1708 1709 1711 1713 6.5. emergencyCall.Comment XML Schema 1714 1715 1722 1725 1727 1728 1729 1732 1734 1735 1737 1738 1739 1740 1741 1742 1743 1745 1747 6.6. Provided-By XML Schema 1749 This section defines the Provided-By schema. 1751 1752 1765 1766 1767 1768 1769 1771 1773 1774 1776 1780 1784 1787 1789 1791 1793 1794 1795 1796 1797 1799 1800 1802 1804 1805 1806 1808 1810 1811 1812 1815 1818 1821 1824 1828 1831 1832 1834 1836 7. Security Considerations 1838 The information in this data structure will usually be considered 1839 private. HTTPS is specified to require the provider of the 1840 information to validate the credentials of the requester. While the 1841 creation of a PKI that has global scope may be difficult, the 1842 alternatives to creating devices and services that can provide 1843 critical information securely are more daunting. The provider may 1844 enforce any policy it wishes to use, but PSAPs and responder agencies 1845 should deploy a PKI so that providers of additional data can check 1846 the certificate of the client and decide the appropriate policy to 1847 enforce based on that certificate. 1849 Ideally, the PSAP and emergency responders will be given credentials 1850 signed by an authority trusted by the data provider. In most 1851 circumstances, nationally recognized credentials would be sufficient, 1852 and if the emergency services arranges a PKI, data providers could be 1853 provisioned with the root CA public key for a given nation. Some 1854 nations are developing a PKI for this, and related, purposes. Since 1855 calls could be made from devices where the device and/or the service 1856 provider(s) are not local to the emergency authorities, globally 1857 recognized credentials are useful. This might be accomplished by 1858 extending the notion of the "forest guide" described in [RFC5222] to 1859 allow the forest guide to provide the credential of the PKI root for 1860 areas that it has coverage information for, but standards for such a 1861 mechanism are not yet available. In its absence, the data provider 1862 will need to obtain the root CA credentials for any areas it is 1863 willing to provide additional data by out of band means. With the 1864 credential of the root CA for a national emergency services PKI, the 1865 data provider server can validate the credentials of an entity 1866 requesting additional data by reference. 1868 The data provider also needs a credential that can be verified by the 1869 emergency services to know that it is receiving data from the right 1870 server. The emergency authorities could provide credentials, 1871 distinguishable from credentials it provides to emergency responders 1872 and PSAPs, which could be used to validate data providers. Such 1873 credentials would have to be acceptable to any PSAP or responder that 1874 could receive a call with additional data supplied by that provider. 1875 This would be extensible to global credential validation using the 1876 forest guide as above. In the absence of such credentials, the 1877 emergency authorities could maintain a list of local data providers' 1878 credentials provided to it out of band. At a minimum, the emergency 1879 authorities could obtain a credential from the DNS entry of the 1880 domain in the Additional Data URI to at least validate that the 1881 server is known to the domain providing the URI. 1883 Data provided by devices by reference have similar credential 1884 validation issues to service providers, and the solutions are the 1885 same. 1887 8. Privacy Considerations 1889 This document enables functionality for conveying additional 1890 information about the caller to the callee. Some of this information 1891 is personal data and therefore privacy concerns arise. There are a 1892 number of privacy concerns with regular real-time communication 1893 services that are also applicable to emergency calling. Data 1894 protection regulation world-wide has, however, decided to create 1895 exceptions for emergency services since the drawbacks of disclosing 1896 personal data in comparison to the benefit for the emergency caller 1897 are often towards the latter. Hence, the data protection rights of 1898 individuals are often waived for emergency situations. There are, 1899 however, still various countries that offer some degree of anonymity 1900 for the caller towards PSAP call takers. 1902 The functionality defined in this document, however, far exceeds the 1903 amount of information sharing found in the Plain old telephone system 1904 (POTS). For this reason there are additional privacy threats to 1905 consider, which are described in more detail in [I-D.iab-privacy- 1906 considerations]. 1908 Stored Data Compromise: First, there is an increased risk of stored 1909 data compromise since additional data is collected and stored in 1910 databases. Without adequate measures to secure stored data from 1911 unauthorized or inappropriate access at access network operators, 1912 service providers, end devices, as well as PSAPs individuals are 1913 exposed to potential financial, reputational, or physical harm. 1915 Misattribution: If the personal data collected and conveyed is 1916 incorrect or inaccurate then this may lead to misattribution. 1917 Misattribution occurs when data or communications related to one 1918 individual are attributed to another. 1920 Identification: By the nature of the additional data and its 1921 capability to provide much richer information about the caller, 1922 the call, and the location the calling party is identified in a 1923 much better way. Some users may feel uncomfortable with this 1924 degree of information sharing even in emergency services 1925 situations. 1927 Secondary Use: Furthermore, there is the risk of secondary use. 1928 Secondary use is the use of collected information about an 1929 individual without the individual's consent for a purpose 1930 different from that for which the information was collected. The 1931 stated purpose of the additional data is for emergency services 1932 purposes but theoretically the same information could be used for 1933 any other call as well. Additionally, parties involved in the 1934 emergency call may retain the obtained information and may re-use 1935 it for other, non-emergency services purposes. 1937 Disclosure: When the data defined in this document is not properly 1938 security (while in transit with traditional communication security 1939 techniques, and while at rest using access control mechanisms) 1940 there is the risk of disclosure, which is the revelation of 1941 information about an individual that affects the way others judge 1942 the individual. 1944 To mitigate these privacy risks the following countermeasures can be 1945 taken. 1947 In regions where callers can elect to suppress certain personally 1948 identifying information, the network or PSAP functionality can 1949 inspect privacy flags within the SIP headers to determine what 1950 information may be passed, stored, or displayed to comply with local 1951 policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token. 1952 The presence of this privacy type in a Privacy header field indicates 1953 that the user would like the network asserted identity to be kept 1954 private with respect to SIP entities outside the trust domain with 1955 which the user authenticated, including the PSAP. 1957 This document defines various data structures that constitutes 1958 personal data. Local regulations may govern what data must be 1959 provided in emergency calls, but in general, the emergency call 1960 system is often aided by the kinds of information described in this 1961 document. There is a tradeoff between the privacy considerations and 1962 the utility of the data. For adequate protection this specification 1963 requires all data exchanges to be secured via communication security 1964 techniques (namely TLS) against eavesdropping and inception. 1965 Furthermore, security safeguards are required to prevent unauthorized 1966 access to data at rest. Various security incidents over the last 10 1967 years have shown data breaches are not not uncommon and are often 1968 caused by lack of proper access control frameworks, software bugs 1969 (buffer overflows), or missing input parsing (SQL injection attacks). 1970 The risks of data breaches is increased with the obligation for 1971 emergency services to retain emergency call related data for extended 1972 periods, e.g., several years are the norm. 1974 Finally, it is also worth to highlight the nature of the SIP 1975 communication architecture, which introduces additional complications 1976 for privacy. Some forms of data can be sent by value in the SIP 1977 signaling or by value (URL in SIP signaling). When data is sent by 1978 value, all intermediaries have access to the data. As such, these 1979 intermediaries may also introduce additional privacy risk. 1980 Therefore, in situations where the conveyed information raises 1981 privacy concerns and intermediaries are involved transmitting a 1982 reference is more appropriate (assuming proper access control 1983 policies are available for distinguishing the different entities 1984 dereferencing the reference). Without access control policies any 1985 party in possession of the reference is able to resolve the reference 1986 and to obtain the data, including intermediaries. 1988 9. IANA Considerations 1990 9.1. Registry creation 1992 This document creates a new registry called 'Emergency Call 1993 Additional Data'. The following sub-registries are created in 1994 Emergency Call Additional Data: 1996 9.1.1. Provider ID Series Registry 1997 This document creates a new sub-registry called 'Additional Call Data 1998 Provider ID Series'. As defined in [RFC5226], this registry operates 1999 under "Expert Review" rules. The expert should determine that the 2000 entity requesting a new value is a legitimate issuer of service 2001 provider IDs suitable for use in Additional Call Data. 2003 The content of this registry includes: 2005 Name: The identifier which will be used in the ProviderIDSeries 2006 element 2008 Source: The full name of the organization issuing the identifiers 2010 URL: A URL to the organization for further information 2012 The initial set of values is listed in Figure 21. 2014 +-----------+--------------------------+----------------------+ 2015 | Name | Source | URL | 2016 +-----------+--------------------------+----------------------+ 2017 | NENA | National Emergency | http://www.nena.org | 2018 | | Number Association | | 2019 | EENA | European Emergency | http://www.eena.org | 2020 | | Number Association | | 2021 +-----------+--------------------------+----------------------+ 2023 9.1.2. Service Provider Type Registry 2025 This document creates a new sub-registry called 'Service Provider 2026 Type'. As defined in [RFC5226], this registry operates under "Expert 2027 Review". The expert should determine that the proposed new value is 2028 distinct from existing values and appropriate for use in the 2029 TypeOfServicerProvider element 2031 The content of this registry includes: 2033 Name: Value to be used in TypeOfServiceProvider. 2035 Description: A short description of the type of service provider 2037 The initial set of values is defined in Figure 1. 2039 9.1.3. Service Delivered Registry 2041 This document creates a new sub-registry called 'Service Delivered'. 2042 As defined in [RFC5226], this registry operates under "Expert Review" 2043 rules. The expert should consider whether the proposed service is 2044 unique from existing services and the definition of the service will 2045 be clear to implementors and PSAPS/responders. 2047 The content of this registry includes: 2049 Name: Enumeration token of the service. 2051 Description: Short description identifying the service. 2053 The initial set of values are defined in Figure 3. 2055 9.1.4. Device Classification Registry 2057 This document creates a new sub-registry called 'Device 2058 Classification'. As defined in [RFC5226], this registry operates 2059 under "Expert Review" rules. The expert should consider whether the 2060 proposed class is unique from existing classes and the definition of 2061 the class will be clear to implementors and PSAPS/responders. 2063 The content of this registry includes: 2065 Name: Enumeration token of the device classification. 2067 Description: Short description identifying the device type. 2069 The initial set of values are defined in Figure 5. 2071 9.1.5. Device ID Type Type Registry 2073 This document creates a new sub-registry called 'Additional Call Data 2074 Device ID Type'. As defined in [RFC5226], this registry operates 2075 under "Expert Review" rules. The expert should ascertain that the 2076 proposed type is well understood, and provides the information useful 2077 to PSAPs and responders to uniquely identify a device. 2079 The content of this registry includes: 2081 Name: Enumeration token of the device id type. 2083 Description: Short description identifying type of device id. 2085 The initial set of values are defined in Figure 6. 2087 9.1.6. Device/Service Data Type Registry 2089 This document creates a new sub-registry called 'Device/Service Data 2090 Type Registry'. As defined in [RFC5226], this registry operates 2091 under "Expert Review" and "Specification Required" rules. The expert 2092 should ascertain that the proposed type is well understood, and 2093 provides information useful to PSAPs and responders. The 2094 specification must contain a complete description of the data, and a 2095 precise format specification suitable to allow interoperable 2096 implementations. 2098 The content of this registry includes: 2100 Name: Enumeration token of the data type. 2102 Description: Short description identifying the the data. 2104 Specification: Citation for the specification of the data. 2106 The initial set of values are listed in Figure 22. 2108 +---------+----------------------------------------+----------------+ 2109 | Token | Description | Specification | 2110 +---------+----------------------------------------+----------------+ 2111 | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | 2112 +---------+----------------------------------------+----------------+ 2113 | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | 2114 +---------+----------------------------------------+----------------+ 2116 9.1.7. Additional Data Blocks Registry 2118 This document creates a new sub-registry called 'Additional Data 2119 Blocks' in the purpose registry established by RFC 3261 [RFC3261]. 2120 As defined in [RFC5226], this registry operates under "Expert Review" 2121 and "Specification Required" rules. The expert is responsible for 2122 verifying that the document contains a complete and clear 2123 specification and the proposed functionality does not obviously 2124 duplicate existing functionality. 2126 The content of this registry includes: 2128 Name: Element Name of enclosing block. 2130 Reference: The document that describes the block 2132 The initial set of values are listed in Figure 23. 2134 +--------------+------------+ 2135 | Token | Reference | 2136 +--------------+------------+ 2137 | ProviderInfo | [This RFC] | 2138 | SvcInfo | [This RFC] | 2139 | DevInfo | [This RFC] | 2140 | Subscriber | [This RFC] | 2141 | Comment | [This RFC] | 2142 +--------------+------------+ 2144 9.2. 'emergencyCallData' Purpose Parameter Value 2146 This document defines the 'emergencyCall' value for the "purpose" 2147 parameter of the Call-Info header field. The Call-Info header and 2148 the corresponding registry for the 'purpose' parameter was 2149 established with RFC 3261 [RFC3261]. 2151 Header Parameter New 2152 Field Name Value Reference 2153 ---------- --------- ----------------- --------- 2154 Call-Info purpose emergencyCall [This RFC] 2156 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 2158 This section registers the namespace specified in Section 9.5.1 in 2159 the provided-by registry established by RFC 4119, for usage within 2160 the element of a PIDF-LO. 2162 The schema for the provided-by schema used by this document is 2163 specified in Section 6.6. 2165 9.4. MIME Registrations 2167 9.4.1. MIME Content-type Registration for 'application/ 2168 emergencyCall.ProviderInfo+xml' 2170 This specification requests the registration of a new MIME type 2171 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2172 RFC 3023 [RFC3023]. 2174 MIME media type name: application 2176 MIME subtype name: emergencyCall.ProviderInfo+xml 2178 Mandatory parameters: none 2180 Optional parameters: charset Indicates the character encoding of 2181 enclosed XML. 2183 Encoding considerations: Uses XML, which can employ 8-bit 2184 characters, depending on the character encoding used. See Section 2185 3.2 of RFC 3023 [RFC3023]. 2187 Security considerations: This content type is designed to carry 2188 the data provider information, which is a sub-category of 2189 additional data about an emergency call. Since this data contains 2190 personal information appropriate precautions have to be taken to 2191 limit unauthorized access, inappropriate disclosure to third 2192 parties, and eavesdropping of this information. Please refer to 2193 Section 7 and Section 8 for more information. 2195 Interoperability considerations: None 2197 Published specification: [TBD: This specification] 2199 Applications which use this media type: Emergency Services 2200 Additional information: Magic Number: None File Extension: .xml 2201 Macintosh file type code: 'TEXT' 2203 Person and email address for further information: Hannes 2204 Tschofenig, Hannes.Tschofenig@gmx.net 2206 Intended usage: LIMITED USE 2208 Author: This specification is a work item of the IETF ECRIT 2209 working group, with mailing list address . 2211 Change controller: The IESG 2213 9.4.2. MIME Content-type Registration for 'application/ 2214 emergencyCall.SvcInfo+xml' 2216 This specification requests the registration of a new MIME type 2217 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2218 RFC 3023 [RFC3023]. 2220 MIME media type name: application 2222 MIME subtype name: emergencyCall.SvcInfo+xml 2224 Mandatory parameters: none 2226 Optional parameters: charset Indicates the character encoding of 2227 enclosed XML. 2229 Encoding considerations: Uses XML, which can employ 8-bit 2230 characters, depending on the character encoding used. See Section 2231 3.2 of RFC 3023 [RFC3023]. 2233 Security considerations: This content type is designed to carry 2234 the service information, which is a sub-category of additional 2235 data about an emergency call. Since this data contains personal 2236 information appropriate precautions have to be taken to limit 2237 unauthorized access, inappropriate disclosure to third parties, 2238 and eavesdropping of this information. Please refer to Section 7 2239 and Section 8 for more information. 2241 Interoperability considerations: None 2243 Published specification: [TBD: This specification] 2245 Applications which use this media type: Emergency Services 2247 Additional information: Magic Number: None File Extension: .xml 2248 Macintosh file type code: 'TEXT' 2250 Person and email address for further information: Hannes 2251 Tschofenig, Hannes.Tschofenig@gmx.net 2252 Intended usage: LIMITED USE 2254 Author: This specification is a work item of the IETF ECRIT 2255 working group, with mailing list address . 2257 Change controller: The IESG 2259 9.4.3. MIME Content-type Registration for 'application/ 2260 emergencyCall.DevInfo+xml' 2262 This specification requests the registration of a new MIME type 2263 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2264 RFC 3023 [RFC3023]. 2266 MIME media type name: application 2268 MIME subtype name: emergencyCall.DevInfo+xml 2270 Mandatory parameters: none 2272 Optional parameters: charset Indicates the character encoding of 2273 enclosed XML. 2275 Encoding considerations: Uses XML, which can employ 8-bit 2276 characters, depending on the character encoding used. See Section 2277 3.2 of RFC 3023 [RFC3023]. 2279 Security considerations: This content type is designed to carry 2280 the device information information, which is a sub-category of 2281 additional data about an emergency call. Since this data contains 2282 personal information appropriate precautions have to be taken to 2283 limit unauthorized access, inappropriate disclosure to third 2284 parties, and eavesdropping of this information. Please refer to 2285 Section 7 and Section 8 for more information. 2287 Interoperability considerations: None 2289 Published specification: [TBD: This specification] 2291 Applications which use this media type: Emergency Services 2293 Additional information: Magic Number: None File Extension: .xml 2294 Macintosh file type code: 'TEXT' 2296 Person and email address for further information: Hannes 2297 Tschofenig, Hannes.Tschofenig@gmx.net 2299 Intended usage: LIMITED USE 2301 Author: This specification is a work item of the IETF ECRIT 2302 working group, with mailing list address . 2304 Change controller: The IESG 2306 9.4.4. MIME Content-type Registration for 'application/ 2307 emergencyCall.SubInfo+xml' 2309 This specification requests the registration of a new MIME type 2310 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2311 RFC 3023 [RFC3023]. 2313 MIME media type name: application 2315 MIME subtype name: emergencyCall.SubInfo+xml 2317 Mandatory parameters: none 2319 Optional parameters: charset Indicates the character encoding of 2320 enclosed XML. 2322 Encoding considerations: Uses XML, which can employ 8-bit 2323 characters, depending on the character encoding used. See Section 2324 3.2 of RFC 3023 [RFC3023]. 2326 Security considerations: This content type is designed to carry 2327 owner/subscriber information, which is a sub-category of 2328 additional data about an emergency call. Since this data contains 2329 personal information appropriate precautions have to be taken to 2330 limit unauthorized access, inappropriate disclosure to third 2331 parties, and eavesdropping of this information. Please refer to 2332 Section 7 and Section 8 for more information. 2334 Interoperability considerations: None 2336 Published specification: [TBD: This specification] 2338 Applications which use this media type: Emergency Services 2340 Additional information: Magic Number: None File Extension: .xml 2341 Macintosh file type code: 'TEXT' 2343 Person and email address for further information: Hannes 2344 Tschofenig, Hannes.Tschofenig@gmx.net 2346 Intended usage: LIMITED USE 2348 Author: This specification is a work item of the IETF ECRIT 2349 working group, with mailing list address . 2351 Change controller: The IESG 2353 9.4.5. MIME Content-type Registration for 'application/ 2354 emergencyCall.Comment+xml' 2356 This specification requests the registration of a new MIME type 2357 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2358 RFC 3023 [RFC3023]. 2360 MIME media type name: application 2362 MIME subtype name: emergencyCall.Comment+xml 2364 Mandatory parameters: none 2366 Optional parameters: charset Indicates the character encoding of 2367 enclosed XML. 2369 Encoding considerations: Uses XML, which can employ 8-bit 2370 characters, depending on the character encoding used. See Section 2371 3.2 of RFC 3023 [RFC3023]. 2373 Security considerations: This content type is designed to carry a 2374 comment, which is a sub-category of additional data about an 2375 emergency call. This data may contain personal information. 2376 Appropriate precautions may have to be taken to limit unauthorized 2377 access, inappropriate disclosure to third parties, and 2378 eavesdropping of this information. Please refer to Section 7 and 2379 Section 8 for more information. 2381 Interoperability considerations: None 2383 Published specification: [TBD: This specification] 2385 Applications which use this media type: Emergency Services 2387 Additional information: Magic Number: None File Extension: .xml 2388 Macintosh file type code: 'TEXT' 2390 Person and email address for further information: Hannes 2391 Tschofenig, Hannes.Tschofenig@gmx.net 2393 Intended usage: LIMITED USE 2395 Author: This specification is a work item of the IETF ECRIT 2396 working group, with mailing list address . 2398 Change controller: The IESG 2400 9.5. URN Sub-Namespace Registration 2402 9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 2404 This section registers a new XML namespace, as per the guidelines in 2405 RFC 3688 [RFC3688]. 2407 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 2409 Registrant Contact: IETF, ECRIT working group, , as 2410 delegated by the IESG . 2412 XML: 2414 BEGIN 2415 2416 2418 2419 2420 2422 Namespace for Additional Emergency Call Data 2423 2424 2425

Namespace for Additional Data related to an Emergency Call

2426

See [TBD: This document].

2427 2428 2429 END 2431 9.5.2. Registration for 2432 urn:ietf:params:xml:ns:emergencyCallProviderInfo 2434 This section registers a new XML namespace, as per the guidelines in 2435 RFC 3688 [RFC3688]. 2437 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 2439 Registrant Contact: IETF, ECRIT working group, , as 2440 delegated by the IESG . 2442 XML: 2444 BEGIN 2445 2446 2448 2449 2450 2452 Namespace for Additional Emergency Call Data: 2453 Data Provider Information 2454 2455 2456

Namespace for Additional Data related to an Emergency Call

2457

Data Provider Information

2458

See [TBD: This document].

2459 2460 2461 END 2463 9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2465 This section registers a new XML namespace, as per the guidelines in 2466 RFC 3688 [RFC3688]. 2468 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2470 Registrant Contact: IETF, ECRIT working group, , as 2471 delegated by the IESG . 2473 XML: 2475 BEGIN 2476 2477 2479 2480 2481 2483 Namespace for Additional Emergency Call Data: 2484 Service Information 2485 2486 2487

Namespace for Additional Data related to an Emergency Call

2488

Service Information

2489

See [TBD: This document].

2490 2491 2492 END 2494 9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 2496 This section registers a new XML namespace, as per the guidelines in 2497 RFC 3688 [RFC3688]. 2499 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 2501 Registrant Contact: IETF, ECRIT working group, , as 2502 delegated by the IESG . 2504 XML: 2506 BEGIN 2507 2508 2510 2511 2512 2514 Namespace for Additional Emergency Call Data: 2515 Device Information 2516 2517 2518

Namespace for Additional Data related to an Emergency Call

2519

Device Information

2520

See [TBD: This document].

2521 2522 2523 END 2525 9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 2527 This section registers a new XML namespace, as per the guidelines in 2528 RFC 3688 [RFC3688]. 2530 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 2532 Registrant Contact: IETF, ECRIT working group, , as 2533 delegated by the IESG . 2535 XML: 2537 BEGIN 2538 2539 2541 2542 2543 2545 Namespace for Additional Emergency Call Data: 2546 Owner/Subscriber Information 2547 2548 2549

Namespace for Additional Data related to an Emergency Call

2550

Owner/Subscriber Information

2551

See [TBD: This document].

2552 2553 2554 END 2556 9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 2558 This section registers a new XML namespace, as per the guidelines in 2559 RFC 3688 [RFC3688]. 2561 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 2563 Registrant Contact: IETF, ECRIT working group, , as 2564 delegated by the IESG . 2566 XML: 2568 BEGIN 2569 2570 2572 2573 2574 2576 Namespace for Additional Emergency Call Data:Comment 2577 2578 2579

Namespace for Additional Data related to an Emergency Call

2580

Comment

2581

See [TBD: This document].

2582 2583 2584 END 2586 9.6. Schema Registrations 2588 This specification registers five schemas, as per the guidelines in 2589 RFC 3688 [RFC3688]. 2591 URI: urn:ietf:params:xml:schema:additional- 2592 data:emergencyCallProviderInfo 2594 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2595 delegated by the IESG (iesg@ietf.org). 2597 XML: The XML schema can be found in Figure 15. 2599 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2601 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2602 delegated by the IESG (iesg@ietf.org). 2604 XML: The XML schema can be found in Figure 16. 2606 URI: urn:ietf:params:xml:schema:additional- 2607 data:emergencyCallDevInfo 2609 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2610 delegated by the IESG (iesg@ietf.org). 2612 XML: The XML schema can be found in Figure 17. 2614 URI: urn:ietf:params:xml:schema:additional- 2615 data:emergencyCall.SubInfo 2617 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2618 delegated by the IESG (iesg@ietf.org). 2620 XML: The XML schema can be found in Section 6.4. 2622 URI: urn:ietf:params:xml:schema:additional- 2623 data:emergencyCall.Comment 2625 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2626 delegated by the IESG (iesg@ietf.org). 2628 XML: The XML schema can be found in Section 6.5. 2630 9.7. VCard Parameter Value Registration 2632 This document registers a new value in the vCARD Parameter Values 2633 registry as defined by [RFC6350] with the following template: 2635 Value: main 2637 Purpose: The main telephone number, typically of an enterprise, as 2638 opposed to a direct dial number of an individual employee 2640 Conformance: This value can be used with the "TYPE" parameter applied 2641 on the "TEL" property. 2643 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-900 2644 0 2646 10. Acknowledgments 2648 This work was originally started in NENA and has benefitted from a 2649 large number of participants in NENA standardization efforts, 2650 originally in the Long Term Definition Working Group, the Data 2651 Technical Committee and most recently the Additional Data working 2652 group. The authors are grateful for the initial work and extended 2653 comments provided by many NENA participants, including Delaine 2654 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 2655 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 2656 and Robert (Bob) Sherry. 2658 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 2659 Thomson, Keith Drage, and Laura Liess for their review comments. 2661 11. References 2663 11.1. Normative References 2665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2666 Requirement Levels", BCP 14, RFC 2119, March 1997. 2668 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2669 Locators", RFC 2392, August 1998. 2671 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 2672 Types", RFC 3023, January 2001. 2674 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 2675 F., Watson, M. and M. Zonoun, "MIME media types for ISUP 2676 and QSIG Objects", RFC 3204, December 2001. 2678 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2679 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 2680 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 2682 [RFC3325] Jennings, C., Peterson, J. and M. Watson, "Private 2683 Extensions to the Session Initiation Protocol (SIP) for 2684 Asserted Identity within Trusted Networks", RFC 3325, 2685 November 2002. 2687 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 2688 Extensions (MIME) Parameter", RFC 3459, January 2003. 2690 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2691 January 2004. 2693 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2694 Format", RFC 4119, December 2005. 2696 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2697 Registration Procedures", RFC 4288, December 2005. 2699 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2700 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2701 May 2008. 2703 [RFC5621] Camarillo, G., "Message Body Handling in the Session 2704 Initiation Protocol (SIP)", RFC 5621, September 2009. 2706 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2707 August 2011. 2709 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2710 6351, August 2011. 2712 11.2. Informational References 2714 [I-D.iab-privacy-considerations] 2715 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2716 Morris, J., Hansen, M. and R. Smith, "Privacy 2717 Considerations for Internet Protocols", Internet-Draft 2718 draft-iab-privacy-considerations-03, July 2012. 2720 [I-D.ietf-geopriv-relative-location] 2721 Thomson, M., Rosen, B., Stanley, D., Bajko, G. and A. 2722 Thomson, "Relative Location Representation", Internet- 2723 Draft draft-ietf-geopriv-relative-location-06, July 2013. 2725 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 2726 Emergency Context Resolution with Internet Technologies", 2727 RFC 5012, January 2008. 2729 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 2730 Format for Presence Information Data Format Location 2731 Object (PIDF-LO)", RFC 5139, February 2008. 2733 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, 2734 "LoST: A Location-to-Service Translation Protocol", RFC 2735 5222, August 2008. 2737 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 2738 Presence Information Data Format Location Object (PIDF-LO) 2739 Usage Clarification, Considerations, and Recommendations", 2740 RFC 5491, March 2009. 2742 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H. and M. Thomson, 2743 "Dynamic Extensions to the Presence Information Data 2744 Format Location Object (PIDF-LO)", RFC 5962, September 2745 2010. 2747 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 2748 5985, September 2010. 2750 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J. and A. Newton, 2751 "Framework for Emergency Calling Using Internet 2752 Multimedia", RFC 6443, December 2011. 2754 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B. and 2755 R. George, "Specifying Civic Address Extensions in the 2756 Presence Information Data Format Location Object (PIDF- 2757 LO)", RFC 6848, January 2013. 2759 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 2760 Communications Services in Support of Emergency Calling", 2761 BCP 181, RFC 6881, March 2013. 2763 Appendix A. XML Schema for vCard/xCard 2764 This section contains the vCard/xCard XML schema version of the Relax 2765 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 2766 XML schemas defined in this document. The schema in RFC 6351 2767 [RFC6351] is the normative source and this section is informative 2768 only. 2770 2771 2775 2781 2782 2783 vCard Format Specification 2784 2785 2786 2787 2788 2789 2790 2791 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2806 2807 2808 2810 2811 2812 2813 2814 2816 2817 2818 2820 2821 2823 2824 2825 2827 2828 2829 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2874 2875 2876 2877 2881 2882 2883 Section 5: Parameters 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 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 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 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 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 3042 3043 3044 3045 3046 3047 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 3092 3093 3094 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 3144 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 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 3481 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 3578 3579 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 3627 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 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 3806 3807 3808 3809 3810 3811 3812 3814 3815 3816 3817 3818 3819 3820 3822 3823 3824 3826 3828 3829 3830 3832 3833 3834 3835 3837 Authors' Addresses 3839 Brian Rosen 3840 NeuStar 3841 470 Conrad Dr. 3842 Mars, PA 16046 3843 US 3845 Phone: +1 724 382 1051 3846 Email: br@brianrosen.net 3847 Hannes Tschofenig 3848 Nokia Siemens Networks 3849 Linnoitustie 6 3850 Espoo, 02600 3851 Finland 3853 Phone: +358 (50) 4871445 3854 Email: Hannes.Tschofenig@gmx.net 3855 URI: http://www.tschofenig.priv.at 3857 Roger Marshall 3858 TeleCommunication Systems, Inc. 3859 2401 Elliott Avenue 3860 Seattle, WA 98121 3861 US 3863 Phone: +1 206 792 2424 3864 Email: rmarshall@telecomsys.com 3865 URI: http://www.telecomsys.com 3867 Randall Gellens 3868 Qualcomm Technologies, Inc. 3869 5775 Morehouse Drive 3870 San Diego, CA 92121 3871 US 3873 Email: rg+ietf@qti.qualcomm.com 3875 James Winterbottom 3876 AU 3878 Email: a.james.winterbottom@gmail.com