idnits 2.17.1 draft-ietf-ecrit-additional-data-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 39 instances of too long lines in the document, the longest one being 18 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 2270 has weird spacing: '...element name=...' == Line 2771 has weird spacing: '...ll-Info pur...' -- The document date (January 22, 2014) is 3740 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 2771, but not defined == Unused Reference: 'RFC5985' is defined on line 3372, 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) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: July 26, 2014 Nokia Solutions and Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 J. Winterbottom 12 January 22, 2014 14 Additional Data related to an Emergency Call 15 draft-ietf-ecrit-additional-data-17.txt 17 Abstract 19 When an emergency call is sent to a Public Safety Answering Point 20 (PSAP), the device that sends it, as well as any application service 21 provider in the path of the call, or access network provider through 22 which the call originated may have information about the call, the 23 caller or the location which the PSAP may be able to use. This 24 document describes data structures and a mechanism to convey such 25 data to the PSAP. The mechanism uses a Uniform Resource Identifier 26 (URI), which may point to either an external resource or an object in 27 the body of the SIP message. The mechanism thus allows the data to 28 be passed by reference (when the URI points to an external resource) 29 or by value (when it points into the body of the message). This 30 follows the tradition of prior emergency services standardization 31 work where data can be conveyed by value within the call signaling 32 (i.e., in body of the SIP message) and also by reference. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 26, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 71 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 8 72 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 73 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 74 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 75 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10 76 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10 77 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11 78 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11 79 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12 80 3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 12 81 3.2. Service Information . . . . . . . . . . . . . . . . . . . 14 82 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15 83 3.2.2. Service Delivered by Provider to End User . . . . . . 15 84 3.2.3. Service Mobility Environment . . . . . . . . . . . . 17 85 3.2.4. emergencyCallData.ServiceInfo Example . . . . . . . . 17 86 3.3. Device Information . . . . . . . . . . . . . . . . . . . 17 87 3.3.1. Device Classification . . . . . . . . . . . . . . . . 18 88 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19 89 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19 90 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20 91 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 20 92 3.3.6. Device/Service Specific Additional Data Structure . . 21 93 3.3.7. Device/Service Specific Additional Data Structure 94 Type . . . . . . . . . . . . . . . . . . . . . . . . 21 95 3.3.8. Issues with getting new types of data into use . . . 22 96 3.3.9. Choosing between defining a new type of block or new 97 type of device/service specific additional data . . . 23 98 3.3.10. emergencyCallData.DeviceInfo Example . . . . . . . . 23 99 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24 100 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 24 101 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25 102 3.4.3. emergencyCallData.SubscriberInfo Example . . . . . . 25 103 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27 105 3.5.2. emergencyCallData.Comment Example . . . . . . . . . . 28 106 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 4.1. Transmitting Blocks using the Call-Info Header . . . . . 30 108 4.2. Transmitting Blocks by Reference using the Provided-By 109 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 4.3. Transmitting Blocks by Value using the Provided-By 111 Element . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 33 113 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 114 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45 115 6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 45 116 6.2. emergencyCallData.ServiceInfo XML Schema . . . . . . . . 46 117 6.3. emergencyCallData.DeviceInfo XML Schema . . . . . . . . . 47 118 6.4. emergencyCallData.SubscriberInfo XML Schema . . . . . . . 48 119 6.5. emergencyCallData.Comment XML Schema . . . . . . . . . . 49 120 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 50 121 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 122 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 53 123 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 124 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 55 125 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 55 126 9.1.2. Service Environment Registry . . . . . . . . . . . . 56 127 9.1.3. Service Provider Type Registry . . . . . . . . . . . 57 128 9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57 129 9.1.5. Device Classification Registry . . . . . . . . . . . 57 130 9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58 131 9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58 132 9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 59 133 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 59 134 9.3. URN Sub-Namespace Registration for provided-by Registry 135 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 60 136 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 60 137 9.4.1. MIME Content-type Registration for 138 'application/emergencyCallData.ProviderInfo+xml' . . 60 139 9.4.2. MIME Content-type Registration for 140 'application/emergencyCallData.ServiceInfo+xml' . . . 61 141 9.4.3. MIME Content-type Registration for 142 'application/emergencyCallData.DeviceInfo+xml' . . . 62 143 9.4.4. MIME Content-type Registration for 144 'application/emergencyCallData.SubscriberInfo+xml' . 63 145 9.4.5. MIME Content-type Registration for 146 'application/emergencyCallData.Comment+xml' . . . . . 64 147 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65 148 9.5.1. Registration for 149 urn:ietf:params:xml:ns:emergencycalldata . . . . . . 65 150 9.5.2. Registration for 151 urn:ietf:params:xml:ns:emergencycalldata:providerinfo 65 152 9.5.3. Registration for 153 urn:ietf:params:xml:ns:emergencycalldata:ServiceInfo 66 154 9.5.4. Registration for 155 urn:ietf:params:xml:ns:emergencycalldata:DeviceInfo . 67 156 9.5.5. Registration for 157 urn:ietf:params:xml:ns:emergencycalldata:SubscriberIn 158 fo . . . . . . . . . . . . . . . . . . . . . . . . . 68 159 9.5.6. Registration for 160 urn:ietf:params:xml:ns:emergencycalldata:comment . . 68 161 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 69 162 9.7. VCard Parameter Value Registration . . . . . . . . . . . 70 163 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 164 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 165 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 166 11.2. Informational References . . . . . . . . . . . . . . . . 72 167 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 73 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 170 1. Introduction 172 When an IP-based emergency call is initiated a rich set of data from 173 multiple data sources is conveyed to the Public Safety Answering 174 Point (PSAP). This data includes information about the calling party 175 identity, the multimedia capabilities of the device, the emergency 176 service number, location information, and meta-data about the sources 177 of the data. The device, the access network provider, and any 178 service provider in the call path may have even more information 179 useful for a PSAP. This document extends the basic set of data 180 communicated with an IP-based emergency call, as described in 181 [RFC6443] and [RFC6881], in order to carry additional data which may 182 be useful to an entity or call taker handling the call. This data is 183 "additional" to the basic information found in the emergency call 184 signaling used. 186 In general, there are three categories of data communicated in an 187 emergency call: 189 Data Associated with a Location: Location data is conveyed in the 190 Presence Information Data Format Location Object (PIDF-LO) data 191 structure originally defined in RFC 4119 [RFC4119] and extended by 192 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 193 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 194 geodetic location information), and 195 [I-D.ietf-geopriv-relative-location] (for relative location). 196 There may be data that is specific to the location not available 197 in the location data structure itself, such as floor plans, tenant 198 and building owner contact data, heating, ventilation and air 199 conditioning (HVAC) status, etc. 201 Data Associated with a Call: While information is carried in the 202 call setup procedure itself (as part of the SIP headers as well as 203 in the body of the SIP message), there is additional data known by 204 the device making the call, and the service provider along the 205 path of the call. This information may include the service 206 provider contact information, subscriber identity and contact 207 information, the type of service the service provider and the 208 access network provider offer, what kind of device is being used, 209 etc. Some data is device or service dependent data. For example, 210 a car telematics system may have crash information. A medical 211 monitoring device may have sensor data. 213 Data Associated with a Caller: This is personal data about a caller, 214 such as medical information and emergency contact data. 216 This document only defines data structures relevant to data 217 associated with the call but defines extension points for other data 218 to be added via other specifications. 220 For interoperability, there needs to be a common way for the 221 information conveyed to a PSAP to be encoded and identified. 222 Identification allows emergency services authorities to know during 223 call processing which types of data are present and to determine if 224 they wish to access it. A common encoding allows the data to be 225 accessed. 227 This document defines the data structures and a way to communicate 228 the information in several ways. Although current standardization 229 efforts around IP-based emergency services are focused on the Session 230 Initiation Protocol (SIP) and HTTP the data structures in XML format 231 described in this document are usable for other communication systems 232 as well. In Section 3 the data structures are defined and the SIP/ 233 HTTP transport components are defined in Section 4 to offer a clear 234 separation between the two. 236 More technically, the data structure described in this document is 237 represented as one or more "blocks" of information. Each of the 238 blocks is an XML structure with an associated Multipurpose Internet 239 Mail Extensions (MIME) type for encapsulation, and an extensible set 240 of these types constitute the data set. A registry is defined to 241 list the block types that may be included. 243 2. Terminology 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [RFC2119]. 249 This document also uses terminology from [RFC5012]. We use the term 250 service provider to refer to an Application Service Provider (ASP). 251 A Voice Service Provider (VSP) is a special type of ASP. With the 252 term "Access Network Provider" we refer to the Internet Access 253 Provider (IAP) and the Internet Service Provider (ISP) without 254 further distinguishing these two entities, since the difference 255 between the two is not relevant for this document. Note that the 256 roles of ASP and access network provider may be provided by a single 257 company. 259 In the data block definitions, see Section 3, the values for the 260 "Use:" label are specified as one of: 262 'Required': means they MUST be present in the data structure. 264 'Conditional': means they MUST be present if the specified 265 condition(s) is met. They MAY be present if the condition(s) is 266 not met. 268 'Optional': means they MAY be present. 270 vCard is a data format for representing and exchanging a variety of 271 information about individuals and other entities. For applications 272 that use XML the format defined in vCard is not immediately 273 applicable. For this purpose an XML-based encoding of the 274 information elements defined in the vCard specification has been 275 defined and the name of that specification is xCard. Since the term 276 vCard is more familiar to most readers we use the term xCard and 277 vCard interchangeable but it would be accurate to use the term vCard 278 only. 280 3. Data Structures 282 This section defines the following five data structures, each as a 283 data block. For each block we define the MIME type, and the XML data 284 structure. The five data structures are: 286 'Data Provider': This block supplies name and contact information 287 for the entity that created the data. Section 3.1 provides the 288 details. 290 'Service Information': This block supplies information about the 291 service. The description can be found in Section 3.2. 293 'Device Information': This block supplies information about the 294 device placing the call. Device information can be found in 295 Section 3.3. 297 'Owner/Subscriber': This block supplies information about the owner 298 of the device or about the subscriber. Details can be found in 299 Section 3.4. 301 'Comment': This block provides a way to supply free form human 302 readable text to the PSAP or emergency responders. This simple 303 structure is defined in Section 3.5. 305 Each block contains a mandatory element. The purpose of this 306 element is to associate the data added by a data provider to the 307 data provider block. Consequently, when a data provider adds 308 additional data to an emergency call (such as device information) it 309 MUST add information about itself (via the data provider block) and 310 the two blocks contain the same value in the element, whereby 311 the chosen value for the element MUST be different to any other 312 elements already added by other data providers. 314 Note that the xCard format is re-used in some of the data structures 315 to provide contact information. In an xCard there is no way to 316 specify a "main" telephone number. These numbers are useful to 317 emergency responders who are called to a large enterprise. This 318 document adds a new property value to the "tel" property of the TYPE 319 parameter called "main". It can be used in any xCard in additional 320 data. 322 3.1. Data Provider Information 324 This block is intended to be provided by any service provider in the 325 path of the call or the access network provider. It includes 326 identification and contact information. This block SHOULD be 327 provided by every service provider in the call path, and by the 328 access network provider. Devices MAY use this block to provide 329 identifying information. The MIME subtype is "application/ 330 emergencyCall.ProviderInfo+xml". An access network provider SHOULD 331 provide this block either by value or by reference in the Provided-By 332 section of a PIDF-LO 334 3.1.1. Data Provider String 336 Data Element: Data Provider String 338 Use: Required 340 XML Element: 342 Description: This is a plain language string suitable for displaying 343 the name of the service provider that created the additional data 344 structure. If the device created the structure the value is 345 identical to the contact header in the SIP INVITE. 347 Reason for Need: Inform the call taker of the identity of the entity 348 providing the additional call data structure. 350 How Used by Call Taker: Allows the call taker to interpret the data 351 in this structure. The source of the information often influences 352 how the information is used, believed or verified. 354 3.1.2. Data Provider ID 356 Data Element: Data Provider ID 358 Use: Conditional. This data SHOULD be provided if the service 359 provider or access provider is located in a jurisdiction that 360 maintains such ids. For example, in North America, this would be 361 a "NENA Company ID". 363 XML Element: 365 Description: A jurisdiction specific code for the access provider or 366 service provider shown in the element that 367 created the structure of the call. NOTE: In the US, the NENA 368 Company ID must appear here. Additional information can be found 369 at http://www.nena.org/nena-company-id. The NENA Company ID MUST 370 be in the form of a URI in the following format: 371 urn:nena:companyid: 373 Reason for Need: Inform the call taker of the identity of the entity 374 providing the additional call data structure. 376 How Used by Call Taker: Where jurisdictions have lists of providers 377 the Data Provider ID provides useful information about the data 378 source. 380 3.1.3. Data Provider ID Series 381 Data Element: Data Provider ID Series 383 Use: Conditional. If Data Provider ID is provided, Data Provider ID 384 Series is required. 386 XML Element: 388 Description: Identifies the issuer of the ProviderId. A registry 389 will reflect the following valid entries: 391 * NENA 393 * EENA 395 Reason for Need: Identifies how to interpret the Data Provider ID. 397 How Used by Call Taker: Determines which provider ID registry to 398 consult for more information 400 3.1.4. Type of Data Provider 402 Data Element: Type of Data Provider ID 404 Use: Conditional. If Data Provider ID is provided, Type of Data 405 Provider ID is required. 407 XML Element: 409 Description: Identifies the type of data provider id being supplied 410 in the ProviderId data element. A registry with an initial set of 411 values is shown in Figure 1. 413 +------------------------------+------------------------------------+ 414 | Token | Description | 415 +------------------------------+------------------------------------+ 416 |Access Network Provider | Access network service provider | 417 |Service Provider | Calling or Origination telecom SP | 418 |Subcontractor | A contractor to another SP | 419 |Telematics Provider | A sensor based SP, especially | 420 | | vehicle based | 421 |Language Translation Provider | A spoken language translation SP | 422 |Emergency Service Provider | An emergency service provider | 423 | | conveying information to another | 424 | | emergency service provider. | 425 |Emergency Modality Translation| An emergency call specific | 426 | | modality translation service | 427 | | e.g., for sign language | 428 |Relay Provider | A interpretation SP, for example, | 429 | | video relay for sign language | 430 | | interpreting | 431 |Other | Any other type of service provider | 432 +------------------------------+------------------------------------+ 434 Figure 1: Type of Data Provider ID Registry. 436 Reason for Need: Identifies what kind of data provider this is. 438 How Used by Call Taker: To decide who to contact when further 439 information is needed 441 3.1.5. Data Provider Contact URI 443 Data Element: Data Provider Contact URI 445 Use: Required 447 XML Element: 449 Description: When provided by a service provider or an access 450 provider, this information MUST be a URI to a 24/7 support 451 organization tasked to provide PSAP support for this emergency 452 call. If the call is from a device, this would reflect the 453 contact information of the owner of the device. If a telephone 454 number is the contact address then it MUST be tel URI. If it is 455 provided as a SIP URI then it MUST be in the form of 456 sip:telephonenumber@serviceprovider:user=phone. Note that this 457 contact information is not used by PSAPs for callbacks using a SIP 458 Priority header field with the value set to "psap- callback", as 459 described in [I-D.ietf-ecrit-psap-callback]. 461 Reason for Need: Additional data providers may need to be contacted 462 for error or other unusual circumstances. 464 How Used by Call Taker: To contact the supplier of the additional 465 data for assistance in handling the call. 467 3.1.6. Data Provider Languages(s) Supported 469 Data Element: Data Provider Language(s) supported 471 Use: Required. 473 XML Element: 475 Description: The language used by the entity at the Data Provider 476 Contact URI as an alpha 2-character code as defined in ISO 477 639-1:2002 Codes for the representation of names of languages -- 478 Part 1: Alpha-2 code Multiple instances of this element may occur. 479 Order is significant; preferred language should appear first. The 480 content MUST reflect the languages supported at the contact URI. 482 Note that the 'language' media feature tag, defined in RFC 3840 483 [RFC3840] and the more extensive language negotiation mechanism 484 proposed with [I-D.gellens-negotiating-human-language] are 485 independent of this data provider language indication. 487 Reason for Need: Information needed to determine if emergency 488 service authority can communicate with the service provider or if 489 an interpreter will be needed. 491 How Used by Call Taker: If call taker cannot speak language(s) 492 supported by the service provider, a translation service will need 493 to be added to the conversation. Alternatively, other persons at 494 the PSAP, besides the call taker, might be consulted for help 495 (depending on the urgency and the type of interaction). 497 3.1.7. xCard of Data Provider 499 Data Element: xCard of Data Provider 501 Use: Optional 503 XML Element: 505 Description: There are many fields in the xCard and the creator of 506 the data structure is encouraged to provide as much information as 507 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 508 minimum. N should contain name of support group or device owner 509 as appropriate. If more than one TEL property is provided, a 510 parameter from the vCard Property Value registry MUST be specified 511 on each TEL. For encoding of the xCard this specification uses 512 the XML-based encoding specified in [RFC6351]. and is hereinafter 513 referred to as "xCard" 515 Reason for Need: Information needed to determine additional contact 516 information. 518 How Used by Call Taker: Assists call taker by providing additional 519 contact information that may not be included in the SIP invite or 520 the PIDF-LO. 522 3.1.8. Subcontractor Principal 524 Data Element: Subcontractor Principal 525 Use: Conditional. This data is required if the Data Provider type 526 is subcontractor. 528 XML Element: 530 Description: Some providers outsource their obligations to handle 531 aspects of emergency services to specialized providers. If the 532 data provider is a subcontractor to another provider this element 533 contains the DataProviderString of the service provider to 534 indicate which provider the subcontractor is working for. 536 Reason for Need: Identify the entity the subcontractor works for. 538 How Used by Call Taker: Allows the call taker to understand what the 539 relationship between data providers and the service providers in 540 the path of the call are. 542 3.1.9. Subcontractor Priority 544 Data Element: Subcontractor Priority 546 Use: Conditional. This element is required if the Data Provider 547 type is set to "Subcontractor". 549 XML Element: 551 Description: If the subcontractor has to be contacted first then 552 this element MUST have the value "sub". If the provider the 553 subcontractor is working for has to be contacted first then this 554 element MUST have the value "main". 556 Reason for Need: Inform the call taker whom to contact first, if 557 support is needed. 559 How Used by Call Taker: To decide which entity to contact first if 560 assistance is needed. 562 3.1.10. ProviderInfo Example 564 565 568 12345 569 Example VoIP Provider 570 571 urn:nena:companyid:ID123 572 NENA 573 Service Provider 574 sip:voip-provider@example.com 575 EN 576 578 579 Hannes Tschofenig 580 581 Hannes 582 Tschofenig 583 584 585 Dipl. Ing. 586 587 --0203 588 589 20090808T1430-0500 590 591 M 592 593 1 594 595 de 596 597 598 2 599 600 en 601 602 603 work 604 605 Example VoIP Provider 606 607 608 609 work 610 614 615 616 617 Linnoitustie 6 618 Espoo 619 Uusimaa 620 02600 621 Finland 622 623 624 625 626 work 627 voice 628 629 630 tel:+358 50 4871445 631 632 633 work 634 635 hannes.tschofenig@nsn.com 636 637 638 work 639 640 geo:60.210796,24.812924 641 642 643 home 644 645 646 http://www.tschofenig.priv.at/key.asc 647 648 649 Finland/Helsinki 650 651 home 652 653 http://www.tschofenig.priv.at 654 655 656 657 659 Figure 2: emergencyCall.ProviderInfo Example. 661 3.2. Service Information 663 This block describes the service that the service provider provides 664 to the caller. It SHOULD be included by all SPs in the path of the 665 call. The mime subtype is "application/ 666 emergencyCall.ServiceInfo+xml". 668 3.2.1. Service Environment 670 Data Element: Service Environment 672 Use: Required 674 XML Element: 676 Description: This element defines whether a call is from a business 677 or residence caller. Currently, the only valid entries are 678 'Business' or 'Residence'. New values can be defined via the 679 registry created in Figure 22. 681 Reason for Need: To assist in determining equipment and manpower 682 requirements. 684 How Used by Call Taker: Information may be used to assist in 685 determining equipment and manpower requirements for emergency 686 responders. As the information is not always available, and the 687 registry is not all encompassing, this is at best advisory 688 information, but since it mimics a similar capability in some 689 current emergency calling systems, it is known to be valuable. 690 The service provider uses its best information (such as a rate 691 plan, facilities used to deliver service or service description) 692 to determine the information and is not responsible for 693 determining the actual characteristics of the location where the 694 call originates from. 696 3.2.2. Service Delivered by Provider to End User 698 Data Element: Service Delivered by Provider to End User 700 Use: Required 702 XML Element: 704 Description: This defines the type of service the end user has 705 subscribed to. The implied mobility of this service cannot be 706 relied upon. A registry with an initial set of values is defined 707 in Figure 3. 709 +--------+----------------------------------------+ 710 | Name | Description | 711 +--------+----------------------------------------+ 712 | Wrless | Wireless Telephone Service: Includes | 713 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 714 | | LTE (Long Term Evolution) | 715 | Coin | Fixed Public Pay/Coin telephones: Any | 716 | | coin or credit card operated device | 717 | 1way | One way outbound service | 718 | Prison | Inmate call/service | 719 | Temp | Soft dialtone/quick service/warm | 720 | | disconnect/suspended | 721 | MLTS | Multi-line telephone system: Includes | 722 | | all PBX, Centrex, key systems, | 723 | | Shared Tenant Service | 724 | SenseU | Sensor, unattended: Includes devices | 725 | | that generate DATA ONLY. This is | 726 | | one-way information exchange and | 727 | | there will be no other form of | 728 | | communication | 729 | SenseA | Sensor, attended: Includes devices | 730 | | that are supported by a monitoring | 731 | | service provider or automatically | 732 | | open a two-way communication path | 733 | POTS | Wireline: Plain Old Telephone Service | 734 | VOIP | VoIP Telephone Service: A type of | 735 | | service that offers communication | 736 | | over internet protocol, such as Fixed| 737 | | Nomadic, Mobile, ... | 738 | Remote | Off premise extension | 739 | Relay | Relay Service: a type of service where | 740 | | there is a human 3rd party agent who | 741 | | provides some kind of additional | 742 | | assistance to the caller. Includes | 743 | | sign language relay and telematics | 744 | | services which provide a service | 745 | | assistant on the call. | 746 +--------+----------------------------------------+ 748 Figure 3: Service Delivered by Provider to End User Registry. 750 More than one value MAY be returned. For example, a VoIP inmate 751 telephone service is a reasonable combination. 753 Reason for Need: Knowing the type of service may assist the PSAP 754 with the handling of the call. 756 How Used by Call Taker: Call takers often use this information to 757 determine what kinds of questions to ask callers, and how much to 758 rely on supportive information. An emergency call from a prison 759 is treated differently that a call from a sensor device. As the 760 information is not always available, and the registry is not all 761 encompassing, this is at best advisory information, but since it 762 mimics a similar capability in some current emergency calling 763 systems, it is known to be valuable. 765 3.2.3. Service Mobility Environment 767 Data Element: Service Mobility Environment 769 Use: Required 771 XML Element: 773 Description: This provides the service providers view of the 774 mobility of the caller. As the service provider may not know the 775 characteristics of the actual access network used, the value not 776 be relied upon. A registry will reflect the following initial 777 valid entries: 779 * Mobile: the device should be able to move at any time 781 * Fixed: the device is not expected to move unless the service is 782 relocated 784 * Nomadic: the device is not expected to change its point of 785 attachment while on a call 787 * Unknown: no information is known about the service mobility 788 environment for the device 790 Reason for Need: Knowing the service provider's belief of mobility 791 may assist the PSAP with the handling of the call. 793 How Used by Call Taker: To determine whether to assume the location 794 of the caller might change. 796 3.2.4. emergencyCallData.ServiceInfo Example 798 799 802 12345 803 Business 804 MLTS 805 Fixed 806 808 Figure 4: emergencyCallData.ServiceInfo Example. 810 3.3. Device Information 811 This block provides information about the device used to place the 812 call. It should be provided by any service provider that knows what 813 device is being used, and by the device itself. The mime subtype is 814 "application/emergencyCall.DeviceInfo+xml". 816 3.3.1. Device Classification 818 Data Element: Device Classification 820 Use: Optional 822 XML Element: 824 Description: This data element defines the kind of device making the 825 emergency call. If the device provides the data structure, the 826 device information SHOULD be provided. If the service provider 827 provides the structure and it knows what the device is, the 828 service provider SHOULD provide the device information. Often the 829 carrier does not know what the device is. It is possible to 830 receive two Additional Data Associated with a Call data 831 structures, one created by the device and one created by the 832 service provider. This information describes the device, not how 833 it is being used. This data element defines the kind of device 834 making the emergency call. The registry with the initial set of 835 values is shown in Figure 5. 837 +--------+----------------------------------------+ 838 | Token | Description | 839 +--------+----------------------------------------+ 840 |Cordless| Cordless handset | 841 | Fixed | Fixed phone | 842 | Mobile | Mobile handset | 843 | ATA | analog terminal adapter | 844 |Satphone| Satellite phone | 845 | FSense | Stationary computing device (alarm | 846 | | system, data sensor) | 847 | Guard | Guardian devices | 848 | Desktop| Desktop PC | 849 | Laptop | Laptop computing device | 850 | Tablet | Tablet computing device | 851 | Alarm | Alarm system | 852 | MSense | Mobile Data sensor | 853 | Beacon | Personal beacons (spot) | 854 | Auto | Auto telematics | 855 | Truck | Truck telematics | 856 | Farm | Farm equipment telematics | 857 | Marine | Marine telematics | 858 | PDA | Personal digital assistant | 859 | PND | Personal navigation device) | 860 | SmrtPhn| Smart phone | 861 | Itab | Internet tablet | 862 | Game | Gaming console | 863 | Video | Video phone | 864 | Text | Other text device | 865 |SoftPhn | Soft phone or soft client software | 866 | NA | Not Available | 867 +--------+----------------------------------------+ 869 Figure 5: Device Classification Registry. 871 Reason for Need: The device classification implies the capability of 872 the calling device and assists in identifying the meaning of the 873 emergency call location information that is being presented. For 874 example, does the device require human intervention to initiate a 875 call or is this call the result of programmed instructions? Does 876 the calling device have the ability to update location or 877 condition changes? Is this device interactive or a one-way 878 reporting device? 880 How Used by Call Taker: May assist with location of caller. For 881 example, a cordless handset may be outside or next door. May 882 provide the calltaker some context about the caller, the 883 capabilities of the device used for the call or the environment 884 the device is being used in. 886 3.3.2. Device Manufacturer 888 Data Element: Device Manufacturer 890 Use: Optional 892 XML Element: 894 Description: The plain language name of the manufacturer of the 895 device. 897 Reason for Need: Used by PSAP management for post-mortem 898 investigation/resolution. 900 How Used by Call Taker: Probably not used by the calltaker, but by 901 PSAP management. 903 3.3.3. Device Model Number 905 Data Element: Device Model Number 906 Use: Optional 908 XML Element: 910 Description: Model number of the device. 912 Reason for Need: Used by PSAP management for after action 913 investigation/resolution. 915 How Used by Call Taker: Probably not used by the calltaker, but by 916 PSAP management. 918 3.3.4. Unique Device Identifier 920 Data Element: Unique Device Identifier 922 Use: Optional 924 XML Element: 926 Description: String that identifies the specific device making the 927 call or creating an event. 929 Reason for Need: Uniquely identifies the device as opposed to any 930 signaling identifiers encountered in the call signaling stream. 932 How Used by Call Taker: Probably not used by the calltaker; they 933 would need to refer to management for investigation. 935 3.3.5. Type of Device Identifier 937 Data Element: Type of Device Identifier 939 Use: Conditional: must be provided if the DeviceID is provided 941 XML Element: 943 Description: Identifies the type of device identifier being 944 generated in the unique device identifier data element. A 945 registry with an initial set of values can be seen in Figure 6. 947 +--------+----------------------------------------+ 948 | Token | Description | 949 +--------+----------------------------------------+ 950 | MEID | Mobile Equipment Identifier (CDMA) | 951 | ESN | Electronic Serial Number(GSM) | 952 | MAC | Media Access Control Address (IEEE) | 953 | WiMAX | Device Certificate Unique ID | 954 | IMEI | International Mobile Equipment ID (GSM)| 955 | UDI | Unique Device Identifier | 956 | RFID | Radio Frequency Identification | 957 | SN | Manufacturer Serial Number | 958 +--------+----------------------------------------+ 960 Figure 6: Registry with Device Identifier Types. 962 Reason for Need: Identifies how to interpret the Unique Device 963 Identifier. 965 How Used by Call Taker: Additional information that may be used to 966 assist with call handling. 968 3.3.6. Device/Service Specific Additional Data Structure 970 Data Element: Device/service specific additional data structure 972 Use: Optional 974 XML Element: 976 Description: A URI representing additional data whose schema is 977 specific to the device or service which created it. An example is 978 the Vehicular Emergency Data Set (VEDS) structure for a vehicle 979 telematics device. The URI, when dereferenced, MUST yield a data 980 structure defined by the Device/service specific additional data 981 type value. Different data may be created by each classification; 982 e.g., a telematics created VEDS data set. 984 Reason for Need: Provides device/service specific data that may be 985 used by the call taker and/or responders. 987 How Used by Call Taker: Provide information to guide call takers to 988 select appropriate responders, give appropriate pre-arrival 989 instructions to callers, and advise responders of what to be 990 prepared for. May be used by responders to guide assistance 991 provided. 993 3.3.7. Device/Service Specific Additional Data Structure Type 995 Data Element: Type of device/service specific additional data 996 structure 998 Use: Conditional. MUST be provided when device/service specific 999 additional URI is provided 1001 XML Element: 1002 Description: Value from a registry defined by this document to 1003 describe the type of data that can be retrieved from the device/ 1004 service specific additional data structure. Initial values are: 1006 * IEEE 1512 1008 * VEDS 1010 IEEE 1512 is the USDoT model for traffic incidents and VEDS 1011 provides data elements needed for an efficient emergency response 1012 to vehicular emergency incidents. 1014 Reason for Need: This data element allows identification of 1015 externally defined schemas, which may have additional data that 1016 may assist in emergency response. 1018 How Used by Call Taker: This data element allows the end user 1019 (calltaker or first responder) to know what type of additional 1020 data may be available to aid in providing the needed emergency 1021 services. 1023 Note: Information which is specific to a location or a caller 1024 (person) should not be placed in this section. 1026 3.3.8. Issues with getting new types of data into use 1028 This document describes two mechanisms which allow extension of the 1029 kind of data provided with an emergency call: define a new block or 1030 define a new service specific additional data URL for the DeviceInfo 1031 block. While defining new data types and getting a new device or 1032 application to send the new data may be easy, getting PSAPs and 1033 responders to actually retrieve the data and use it will be 1034 difficult. New mechanism providers should understand that acquiring 1035 and using new forms of data usually require software upgrades at the 1036 PSAP and/or responders, as well as training of call takers and 1037 responders in how to interpret and use the information. Legal and 1038 operational review may also be needed. Overwhelming a call taker or 1039 responder with too much information is highly discouraged. Thus, the 1040 barrier to supporting new data is quite high. 1042 The mechanisms this document describes are meant to encourage 1043 development of widely supported, common data formats for classes of 1044 devices. If all manufacturers of a class of device use the same 1045 format, and the data can be shown to improve outcomes, then PSAPs and 1046 responders may be encouraged to upgrade their systems and train their 1047 staff to use the data. Variations, however well intentioned, are 1048 unlikely to be supported. 1050 Implementers should consider that data from sensor-based devices in 1051 some cases may not be useful to call takers or PSAPs (and privacy or 1052 other considerations may preclude the PSAP from touching the data), 1053 but may be of use to responders. Some standards being developed by 1054 other organizations to carry data from the PSAP to responders are 1055 designed to carry all additional data supplied in the call that 1056 conform to this document, even if the PSAP does not fetch or 1057 interpret the data. This allows responders to get the data even if 1058 the PSAP does not. 1060 3.3.9. Choosing between defining a new type of block or new type of 1061 device/service specific additional data 1063 For devices that have device or service specific data, there are two 1064 choices to carry it. A new block can be defined, or the device/ 1065 service specific additional data URL the DeviceInfo block can be used 1066 and a new type for it defined . The data passed would likely be the 1067 same in both cases. Considerations for choosing which mechanism to 1068 register under include: 1070 Applicability: Information which will be carried by many kinds of 1071 devices or services are more appropriately defined as separate 1072 blocks. 1074 Privacy: Information which may contain private data may be better 1075 sent in the DeviceInfo block, rather than a new block so that 1076 implementations are not tempted to send the data by value, and 1077 thus having more exposure to the data than forcing the data to be 1078 retrieved via the URL in DeviceInfo. 1080 Size: Information which may be very may be better sent in the 1081 DeviceInfo block, rather than a new block so that implementations 1082 are not tempted to send the data by value. Conversely, data which 1083 is small may best be sent in a separate block so that it can be 1084 sent by value 1086 Availability of a server: Providing the data via the device block 1087 requires a server be made available to retrieve the data. 1088 Providing the data via new block allows it to be sent by value 1089 (CID). 1091 3.3.10. emergencyCallData.DeviceInfo Example 1093 1094 1098 12345 1099 Fixed phone 1100 Nokia 1101 Lumia 800 1102 35788104 1103 IMEI 1104 1106 Figure 7: emergencyCallData.DeviceInfo Example. 1108 3.4. Owner/Subscriber Information 1110 This block describes the owner of the device (if provided by the 1111 device) or the subscriber information, if provided by a service 1112 provider. The contact location is not necessarily the location of 1113 the caller or incident, but is rather the nominal contact address. 1114 The mime subtype is "application/emergencyCall.Subscriber+xml". 1116 In some jurisdictions some or all parts of the subscriber-specific 1117 information are subject to privacy constraints. These constraints 1118 vary but dictate what information and be displayed and logged. A 1119 general privacy indicator expressing a desire for privacy is 1120 provided. The interpretation of how this is applied is left to the 1121 receiving jurisdiction as the custodians of the local regulatory 1122 requirements. 1124 3.4.1. Subscriber Data Privacy Indicator 1126 Attribute: privacyRequested, boolean. 1128 Use: Conditional. This attribute MUST be provided if the owner/ 1129 subscriber information block is not empty. 1131 Description: The subscriber data privacy indicator specifically 1132 expresses the subscriber's desire for privacy. In some 1133 jurisdictions subscriber services can have a specific "Type of 1134 Service" which prohibits information, such as the name of the 1135 subscriber, from being displayed. This attribute should be used 1136 to explicitly indicate whether the subscriber service includes 1137 such constraints. 1139 Reason for Need: Some jurisdictions require subscriber privacy to be 1140 observed. 1142 How Used by Call Taker: Where privacy is indicated the call taker 1143 may not have access to some aspects of the subscriber information. 1145 3.4.2. xCard for Subscriber's Data 1147 Data Element: xCARD for Subscriber's Data 1149 Use: Conditional. Subscriber data is provided unless it is not 1150 available. Some services, for example prepaid phones, non- 1151 initialized phones, etc., do not have information about the 1152 subscriber. 1154 XML Element: 1156 Description: Information known by the service provider or device 1157 about the subscriber; e.g., Name, Address, Individual Telephone 1158 Number, Main Telephone Number and any other data. N, ORG (if 1159 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1160 than one TEL property is provided, a parameter from the vCard 1161 Property Value registry MUST be specified on each TEL. 1163 Reason for Need: When the caller is unable to provide information, 1164 this data may be used to obtain it 1166 How Used by Call Taker: Obtaining critical information about the 1167 caller and possibly the location when it is not able to be 1168 obtained otherwise. 1170 3.4.3. emergencyCallData.SubscriberInfo Example 1172 1173 1177 12345 1178 1179 1180 1181 Simon Perreault 1182 1183 Perreault 1184 Simon 1185 1186 1187 ing. jr 1188 M.Sc. 1189 1190 --0203 1191 1192 20090808T1430-0500 1193 1194 M 1195 1196 1 1197 1198 fr 1199 1200 1201 2 1202 1203 en 1204 1205 1206 work 1207 1208 Viagenie 1209 1210 1211 1212 work 1213 1217 1218 1219 1220 2875 boul. Laurier, suite D2-630 1221 Quebec 1222 QC 1223 G1V 2M2 1224 Canada 1225 1226 1227 1228 1229 work 1230 voice 1231 1232 1233 tel:+1-418-656-9254;ext=102 1234 1235 1236 1237 1238 work 1239 text 1240 voice 1241 cell 1242 video 1243 1244 1245 tel:+1-418-262-6501 1246 1247 1248 work 1249 1250 simon.perreault@viagenie.ca 1251 1252 1253 work 1254 1255 geo:46.766336,-71.28955 1256 1257 1258 work 1259 1260 1261 http://www.viagenie.ca/simon.perreault/simon.asc 1262 1263 1264 America/Montreal 1265 1266 home 1267 1268 http://nomis80.org 1269 1270 1271 1272 1273 1275 Figure 8: emergencyCallData.SubscriberInfo Example. 1277 3.5. Comment 1279 This block provides a mechanism for the data provider to supply 1280 extra, human readable information to the PSAP. It is not intended 1281 for a general purpose extension mechanism nor does it aim to provide 1282 machine-reable content. The mime subtype is "application/ 1283 emergencyCall.Comment+xml" 1285 3.5.1. Comment 1287 Data Element: EmergencyCall.Comment 1288 Use: Optional 1290 XML Element: 1292 Description: Human readable text providing additional information to 1293 the PSAP staff. 1295 Reason for Need: Explanatory information for values in the data 1296 structure 1298 How Used by Call Taker: To interpret the data provided 1300 3.5.2. emergencyCallData.Comment Example 1302 1303 1306 12345 1307 This is an example text. 1308 1310 Figure 9: EmergencyCallData.Comment Example. 1312 4. Transport 1314 This section defines how to convey additional data to an emergency 1315 service provider. Two different means are specified: the first uses 1316 the call signaling; the second uses the element of a 1317 PIDF-LO [RFC4119]. 1319 1. First, the ability to embed a Uniform Resource Identifier (URI) 1320 in an existing SIP header field, the Call-Info header, is 1321 defined. The URI points to the additional data structure. The 1322 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1323 document adds a new compound token starting with the value 1324 'emergencyCallData' for the Call-Info "purpose" parameter. If 1325 the "purpose" parameter is set to a value starting with 1326 'emergencyCallData', then the Call-Info header contains either an 1327 HTTPS URL pointing to an external resource or a CID (content 1328 indirection) URI that allows the data structure to be placed in 1329 the body of the SIP message. The "purpose" parameter also 1330 indicates the kind of data (by its MIME type) that is available 1331 at the URI. As the data is conveyed using a URI in the SIP 1332 signaling, the data itself may reside on an external resource, or 1333 may be contained within the body of the SIP message. When the 1334 URI refers to data at an external resource, the data is said to 1335 be passed by reference. When the URI refers to data contained 1336 within the body of the SIP message, the data is said to be passed 1337 by value. A PSAP or emergency responder is able to examine the 1338 type of data provided and selectively inspect the data it is 1339 interested in, while forwarding all of it (the values or 1340 references) to downstream entities. To be conveyed in a SIP 1341 body, additional data about a call is defined as a series of MIME 1342 objects. Each block defined in this document is an XML data 1343 structure identified by its MIME type. (Blocks defined by others 1344 may be encoded in XML or not, as identified by their MIME 1345 registration.) As usual, whenever more than one MIME part is 1346 included in the body of a message, MIME-multipart (i.e., 1347 'multipart/mixed') encloses them all. This document defines a 1348 set of XML schemas and MIME types used for each block defined 1349 here. When additional data is passed by value in the SIP 1350 signaling, each CID URL points to one block in the body. 1351 Multiple URIs are used within a Call-Info header field (or 1352 multiple Call-Info header fields) to point to multiple blocks. 1353 When additional data is provided by reference (in SIP signaling 1354 or Provided-By), each HTTPS URL references one block; the data is 1355 retrieved with an HTTPS GET operation, which returns one of the 1356 blocks as an object (the blocks defined here are returned as XML 1357 objects). 1359 2. Second, the ability to embed additional data structures in the 1360 element of a PIDF-LO [RFC4119] is defined. Besides 1361 a service provider in the call path, the access network provider 1362 may also have similar information that may be valuable to the 1363 PSAP. The access network provider may provide location in the 1364 form of a PIDF-LO from a location server via a location 1365 configuration protocol. The data structures described in this 1366 document are not specific to the location itself, but rather 1367 provides descriptive information having to do with the immediate 1368 circumstances about the provision of the location (who the access 1369 network is, how to contact that entity, what kind of service the 1370 access network provides, subscriber information, etc.). This 1371 data is similar in nearly every respect to the data known by 1372 service providers in the path of the call. When the access 1373 network provider and service provider are separate entities, the 1374 access network does not participate in the application layer 1375 signaling (and hence cannot add a Call-Info header field to the 1376 SIP message), but may provide location information to assist in 1377 locating the caller's device. The element of the 1378 PIDF-LO is a mechanism for the access network provider to supply 1379 the information about the entity or organization that supplied 1380 this location information. For this reason, this document 1381 describes a namespace per RFC 4119 for inclusion in the 1382 element of a PIDF-LO for adding information known 1383 to the access network provider. 1385 One or more blocks of data registered in the Emergency Call 1386 Additional Data registry, as defined in Section 9.1, may be included 1387 or referenced in the SIP signaling (using the Call-Info header field) 1388 or in the element of a PIDF-LO. Every block must be 1389 one of the types in the registry. Since the data of an emergency 1390 call may come from multiple sources, the data itself needs 1391 information describing the source. Consequently, each entity adding 1392 additional data MUST supply the "Data Provider" block. All other 1393 blocks are optional, but each entity SHOULD supply any blocks where 1394 it has at least some of the information in the block. 1396 4.1. Transmitting Blocks using the Call-Info Header 1397 A URI to a block MAY be inserted in a SIP request or response method 1398 (most often INVITE or MESSAGE) with a Call-Info header field 1399 containing a purpose value starting with 'emergencyCallData' and the 1400 type of data available at the URI. The type of data is denoted by 1401 including the root of the MIME type (not including the 1402 'emergencyCall' prefix and any suffix such as '+xml') with a '.' 1403 separator. For example, when referencing a block with MIME type 1404 'application/emergencyCall.ProviderInfo+xml', the 'purpose' parameter 1405 is set to 'emergencyCallData.ProviderInfo'. An example "Call-Info" 1406 header field for this would be: 1408 Call-Info: https://www.example.com/23sedde3; 1409 purpose="emergencyCallData.ProviderInfo" 1411 A Call-info header with a purpose value starting with 1412 'emergencyCallData' MUST only be sent on an emergency call, which can 1413 be ascertained by the presence of an emergency service urn in a Route 1414 header of a SIP message. 1416 If the data is provided by reference, an HTTPS URI MUST be included 1417 and consequently Transport Layer Security (TLS) protection is applied 1418 for protecting the retrieval of the information. 1420 The data may also be supplied by value in a SIP message. In this 1421 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1422 referencing the MIME body part. 1424 More than one Call-Info header with a purpose value starting with 1425 'emergencyCallData' can be expected, but at least one MUST be 1426 provided. The device MUST provide one if it knows no service 1427 provider is in the path of the call. The device MAY insert one if it 1428 uses a service provider. Any service provider in the path of the 1429 call MUST insert its own. For example, a device, a telematics 1430 service provider in the call path, as well as the mobile carrier 1431 handling the call will each provide one. There may be circumstances 1432 where there is a service provider who is unaware that the call is an 1433 emergency call and cannot reasonably be expected to determine that it 1434 is an emergency call. In that case, that service provider is not 1435 expected to provide emergencyCallData. 1437 4.2. Transmitting Blocks by Reference using the Provided-By Element 1439 The 'emergencyCallDataReference' element is used to transmit an 1440 additional data block by reference within a 'Provided-By' element of 1441 a PIDF-LO. The 'emergencyCallDataReference' element has two 1442 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1443 type of data block referenced. The value of 'ref' is an HTTPS URL 1444 that resolves to a data structure with information about the call. 1446 The value of 'purpose' is the same as used in a 'Call-Info' header 1447 field (as specified in Section 4.1). 1449 For example, to reference a block with MIME type 'application/ 1450 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1451 'emergencyCallData.ProviderInfo'. An example 1452 'emergencyCallDataReference' element for this would be: 1454 1457 4.3. Transmitting Blocks by Value using the Provided-By Element 1459 It is RECOMMENDED that access networks supply the data specified in 1460 this document by reference, but they MAY provide the data by value. 1462 The 'emergencyCallDataValue' element is used to transmit an 1463 additional data block by value within a 'Provided-By' element of a 1464 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1465 'purpose' to indicate the type of data block contained. The value of 1466 'purpose' is the same as used in a 'Call-Info' header field (as 1467 specified in Section 4.1, and in Section 4.1). The same XML 1468 structure as would be contained in the corresponding MIME type body 1469 part is placed inside the 'emergencyCallDataValue' element. 1471 For example: 1473 1475 1476 1478 1480 This is an example text. 1481 1482 1483 1484 1486 Test 1487 NENA 1488 Access Infrastructure Provider 1489 1490 sip:15555550987@burf.example.com;user=phone 1491 1492 1494 1496 Example Provided-By by Value. 1498 4.4. The Content-Disposition Parameter 1500 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1501 It updates and clarifies handling originally defined in RFC 3261 1502 [RFC3261] based on implementation experience. While RFC 3261 did not 1503 mandate support for 'multipart' message bodies, 'multipart/mixed' 1504 MIME bodies are used by many extensions (including this document) 1505 today. For example, adding a PIDF-LO, SDP, and additional data in 1506 body of a SIP message requires a 'multipart' message body. 1508 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1509 parameter for the Content-Disposition header field. These RFCs 1510 describe how a UAS reacts if it receives a message body whose content 1511 type or disposition type it does not understand. If the 'handling' 1512 parameter has the value "optional", the UAS ignores the message body. 1513 If the 'handling' parameter has the value "required", the UAS returns 1514 a 415 (Unsupported Media Type) response. The 'by-reference' 1515 disposition type allows a SIP message to contain a reference to the 1516 body part, and the SIP UA processes the body part according to the 1517 reference. This is the case for the Call-info header containing a 1518 Content Indirection (CID) URL. 1520 As an example, a SIP message indicates the Content-Disposition 1521 parameter in the body of the SIP message as shown in Figure 10. 1523 Content-Type: application/sdp 1525 ...Omit Content-Disposition here; defaults are ok 1526 ...SDP goes in here 1528 --boundary1 1530 Content-Type: application/pidf+xml 1531 Content-ID: 1532 Content-Disposition: by-reference;handling=optional 1534 ...PIDF-LO goes in here 1536 --boundary1-- 1538 Content-Type: application/emergencyCall.ProviderInfo+xml 1539 Content-ID: <1234567890@atlanta.example.com> 1540 Content-Disposition: by-reference; handling=optional 1542 ...Data provider information data goes in here 1544 --boundary1-- 1546 Figure 10: Example for use of the Content-Disposition Parameter in 1547 SIP. 1549 5. Examples 1551 This section illustrates a longer and more complex example, as shown 1552 in Figure 11. In this example additional data is added by the end 1553 device, included by the VoIP provider (via the PIDF-LO), and provided 1554 by the access network provider. 1556 [================] (1) [================] 1557 [ O +----+ ] Emergency Call [ ] 1558 [ /|\ | UA |-------------------------------> ] 1559 [ | +----+ ] +Device Info [ ] 1560 [ / \ ] +Data Provider Info [ ] 1561 [ ] +Location URI [ ] 1562 [ Access Network ] [ ] 1563 [ Provider ] [ VoIP Provider ] 1564 [ ] [ example.org ] 1565 [ ^ ] [ ] 1566 [=======.========] [============|===] 1567 . | 1568 . | 1569 . [================] | 1570 . [ ] (2) | 1571 . (3) [ <--------------+ 1572 ....................> PSAP ] Emergency Call 1573 Location [ ] +Device Info 1574 +Owner/Subscriber Info [ ] +Data Provider Info #2 1575 +Device Info [ ] +Location URI 1576 +Data Provider Info #3 [================] 1578 Legend: 1580 --- Emergency Call Setup Procedure 1581 ... Location Retrieval/Response 1583 Figure 11: Additional Data Example Flow 1585 The example scenario starts with the end device itself adding device 1586 information, owner/subscriber information, a location URI, and data 1587 provider information to the outgoing emergency call setup message 1588 (see step #1 in Figure 11). The SIP INVITE example is shown in 1589 Figure 12. 1591 INVITE urn:service:sos SIP/2.0 1592 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1593 Max-Forwards: 70 1594 To: 1595 From: Hannes Tschofenig ;tag=9fxced76sl 1596 Call-ID: 3848276298220188511@example.com 1597 Call-Info: ;purpose=icon, 1598 ;purpose=info, 1599 1600 ;purpose=emergencyCallData.ProviderInfo, 1601 1602 ;purpose=emergencyCallData.DeviceInfo 1603 Geolocation: 1604 Geolocation-Routing: yes 1605 Accept: application/sdp, application/pidf+xml, 1606 application/emergencyCallProviderinfo+xml 1607 CSeq: 31862 INVITE 1608 Contact: 1609 Content-Type: multipart/mixed; boundary=boundary1 1611 Content-Length: ... 1613 --boundary1 1615 Content-Type: application/sdp 1617 ...SDP goes here 1619 --boundary1-- 1621 Content-Type: application/emergencyCallData.DeviceInfo+xml 1622 Content-ID: <0123456789@atlanta.example.com> 1623 Content-Disposition: by-reference;handling=optional 1624 1626 1629 12345 1630 SoftPhn 1631 00-0d-4b-30-72-df 1632 MAC 1633 1635 --boundary1-- 1637 Content-Type: application/emergencyCallData.ProviderInfo+xml 1638 Content-ID: <1234567890@atlanta.example.com> 1639 Content-Disposition: by-reference;handling=optional 1640 1641 1644 12345 1645 Hannes Tschofenig 1646 1647 Other 1648 sip:hannes@example.com 1649 EN 1650 1652 1653 Hannes Tschofenig 1654 1655 Hannes 1656 Tschofenig 1657 1658 1659 Dipl. Ing. 1660 1661 --0203 1662 1663 20090808T1430-0500 1664 1665 M 1666 1667 1 1668 1669 de 1670 1671 1672 2 1673 1674 en 1675 1676 1677 1678 work 1679 1683 1684 1685 1686 Linnoitustie 6 1687 Espoo 1688 Uusimaa 1689 02600 1690 Finland 1691 1692 1693 1694 1695 work 1696 voice 1697 1698 1699 tel:+358 50 4871445 1700 1701 1702 work 1703 1704 hannes.tschofenig@nsn.com 1705 1706 1707 work 1708 1709 geo:60.210796,24.812924 1710 1711 1712 1713 home 1714 1715 https://www.example.com/key.asc 1716 1717 1718 Finland/Helsinki 1719 1720 home 1721 1722 http://example.com/hannes.tschofenig 1723 1724 1725 1726 1727 --boundary1-- 1729 Figure 12: End Device sending SIP INVITE with Additional Data. 1731 In this example, information available to the access network operator 1732 is included in the call setup message only indirectly via the use of 1733 the location reference. The PSAP has to retrieve it via a separate 1734 look-up step. Since the access network provider and the VoIP service 1735 provider are two independent entities in this scenario the access 1736 network operator is not involved in the processing of application 1737 layer exchanges and forwards the SIP INVITE transparently, as 1738 illustrated in step #1. No change to the SIP INVITE is applied. 1740 When the VoIP service provider receives the message and determines 1741 based on the Service URN that the incoming request is an emergency 1742 call. It performs the typical emergency services related tasks, 1743 including location-based routing, and adds additional data, namely 1744 service and subscriber information, to the outgoing message. For the 1745 example we assume a VoIP service provider that deploys a back-to-back 1746 user agent allowing additional data to be included in the body of the 1747 SIP message (rather than per reference in the header), which allows 1748 us to illustrate the use of multiple data provider info blocks. The 1749 resulting message is shown in Figure 13. 1751 INVITE sips:psap@example.org SIP/2.0 1752 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1753 Max-Forwards: 70 1754 To: 1755 From: Hannes Tschofenig ;tag=9fxced76sl 1756 Call-ID: 3848276298220188511@example.com 1757 Call-Info: ;purpose=icon, 1758 ;purpose=info, 1759 1760 ;purpose=emergencyCallData.ProviderInfo 1761 1762 ;purpose=emergencyCallData.DeviceInfo 1763 Call-Info: 1764 ;purpose=emergencyCallData.ServiceInfo 1765 Call-Info: 1766 ;purpose=emergencyCallData.ProviderInfo 1767 Geolocation: 1768 Geolocation-Routing: yes 1769 Accept: application/sdp, application/pidf+xml, 1770 application/emergencyCallData.ProviderInfo+xml 1771 CSeq: 31862 INVITE 1772 Contact: 1773 Content-Type: multipart/mixed; boundary=boundary1 1774 Content-Length: ... 1776 --boundary1 1778 Content-Type: application/sdp 1780 ...SDP goes here 1782 --boundary1-- 1784 Content-Type: application/emergencyCallData.DeviceInfo+xml 1785 Content-ID: <0123456789@atlanta.example.com> 1786 Content-Disposition: by-reference;handling=optional 1787 1789 1792 12345 1793 SoftPhn 1794 00-0d-4b-30-72-df 1795 MAC 1796 1798 --boundary1-- 1800 Content-Type: application/emergencyCallData.ProviderInfo+xml 1801 Content-ID: <1234567890@atlanta.example.com> 1802 Content-Disposition: by-reference;handling=optional 1803 1804 1807 12345 1808 Hannes Tschofenig 1809 1810 Other 1811 sip:hannes@example.com 1812 EN 1813 1815 1816 Hannes Tschofenig 1817 1818 Hannes 1819 Tschofenig 1820 1821 1822 Dipl. Ing. 1823 1824 --0203 1825 1826 20090808T1430-0500 1827 1828 M 1829 1830 1 1831 1832 de 1833 1834 1835 2 1836 1837 en 1838 1839 1840 1841 work 1842 1846 1847 1848 1849 Linnoitustie 6 1850 Espoo 1851 Uusimaa 1852 02600 1853 Finland 1854 1855 1856 1857 1858 work 1859 voice 1860 1861 1862 tel:+358 50 4871445 1863 1864 1865 work 1866 1867 hannes.tschofenig@nsn.com 1868 1869 1870 work 1871 1872 geo:60.210796,24.812924 1873 1874 1875 1876 home 1877 1878 https://www.example.com/key.asc 1879 1880 1881 Finland/Helsinki 1882 1883 home 1884 1885 http://example.com/hannes.tschofenig 1886 1887 1888 1889 1891 --boundary1-- 1893 Content-Type: application/emergencyCall.ServiceInfo+xml 1894 Content-ID: 1895 Content-Disposition: by-reference;handling=optional 1896 1897 1900 abc123 1901 Residence 1902 VOIP 1903 Unknown 1904 1906 --boundary1-- 1908 Content-Type: application/emergencyCallData.ProviderInfo+xml 1909 Content-ID: 1910 Content-Disposition: by-reference;handling=optional 1911 1912 1915 abc123 1916 Example VoIP Provider 1917 1919 urn:nena:companyid:ID123 1920 NENA 1921 Service Provider 1922 sip:voip-provider@example.com 1923 EN 1924 1926 1927 John Doe 1928 1929 John 1930 Doe 1931 1932 1933 1934 1935 --0203 1936 1937 20090808T1430-0500 1938 1939 M 1940 1941 1 1942 1943 en 1944 1945 1946 work 1947 1948 Example VoIP Provider 1949 1950 1951 1952 work 1953 1956 1957 1958 1959 Downing Street 10 1960 London 1961 1962 SW1A 2AA 1963 UK 1964 1965 1966 1967 1968 work 1969 voice 1970 1971 1972 sips:john.doe@example.com 1973 1974 1975 work 1976 1977 john.doe@example.com 1978 1979 1980 work 1981 1982 geo:51.503396, 0.127640 1983 1984 Europe/London 1985 1986 home 1987 1988 http://www.example.com/john.doe 1989 1990 1991 1992 1994 Figure 13: VoIP Provider sending SIP INVITE with Additional Data. 1996 Finally, the PSAP requests location information from the access 1997 network operator. The response is shown in Figure 14. Along with 1998 the location information additional data is provided in the 1999 element of the PIDF-LO. 2001 2002 2007 2008 2009 2010 2012 AU 2013 NSW 2014 Wollongong 2015 North Wollongong 2016 Flinders 2017 Street 2018 Campbell Street 2019 Gilligan's Island 2020 Corner 2021 Video Rental Store 2022 2500 2023 Westerns and Classics 2024 store 2025 Private Box 15 2026 2027 2028 2029 true 2030 2031 2013-12-10T20:00:00Z 2032 2033 2034 802.11 2036 2039 2042 2043 2045 University of California, Irvine 2046 2047 urn:nena:companyid:uci 2048 NENA 2049 Other 2050 tel:+1 9498245222 2051 EN 2052 2054 2056 This is an example text. 2057 2059 2060 2061 2062 mac:00-0d-4b-30-72-df 2063 2013-07-09T20:57:29Z 2064 2065 2067 Figure 14: Access Network Provider returning PIDF-LO with Additional 2068 Data. 2070 6. XML Schemas 2072 This section defines the XML schemas of the five data blocks. 2073 Additionally, the Provided-By schema is specified. 2075 6.1. emergencyCallData.ProviderInfo XML Schema 2077 2078 2088 2091 2093 2094 2095 2096 2097 2099 2103 2104 2105 2106 2107 2109 2111 2112 2113 2116 2119 2122 2125 2128 2131 2134 2138 2141 2144 2146 2147 2149 2151 Figure 15: emergencyCallData.ProviderInfo XML Schema. 2153 6.2. emergencyCallData.ServiceInfo XML Schema 2155 2156 2164 2167 2169 2170 2171 2174 2177 2180 2183 2186 2188 2189 2191 2193 Figure 16: emergencyCallData.ServiceInfo XML Schema. 2195 6.3. emergencyCallData.DeviceInfo XML Schema 2197 2198 2205 2208 2210 2211 2212 2215 2218 2221 2224 2227 2230 2233 2236 2238 2239 2241 2243 Figure 17: emergencyCallData.DeviceInfo XML Schema. 2245 6.4. emergencyCallData.SubscriberInfo XML Schema 2247 2248 2257 2260 2262 2264 2265 2266 2267 2270 2273 2275 2276 2277 2278 2280 2282 Figure 18: emergencyCallData.SubscriberInfo XML Schema. 2284 6.5. emergencyCallData.Comment XML Schema 2286 2287 2295 2298 2300 2301 2302 2305 2309 2311 2312 2314 2315 2316 2317 2318 2319 2320 2322 2324 Figure 19: EmergencyCallData.Comment XML Schema. 2326 6.6. Provided-By XML Schema 2328 This section defines the Provided-By schema. 2330 2331 2344 2345 2346 2347 2348 2350 2352 2353 2354 2357 2361 2365 2368 2370 2372 2374 2375 2376 2377 2378 2380 2381 2383 2385 2386 2387 2389 2391 2392 2393 2396 2399 2402 2405 2409 2412 2413 2415 2417 Figure 20: Provided-By XML Schema. 2419 7. Security Considerations 2421 The information in this data structure will usually be considered 2422 private. HTTPS is specified to require the provider of the 2423 information to validate the credentials of the requester. While the 2424 creation of a public key infrastructure (PKI) that has global scope 2425 may be difficult, the alternatives to creating devices and services 2426 that can provide critical information securely are more daunting. 2427 The provider may enforce any policy it wishes to use, but PSAPs and 2428 responder agencies should deploy a PKI so that providers of 2429 additional data can check the certificate of the client and decide 2430 the appropriate policy to enforce based on that certificate. 2432 Ideally, the PSAP and emergency responders will be given credentials 2433 signed by an authority trusted by the data provider. In most 2434 circumstances, nationally recognized credentials would be sufficient, 2435 and if the emergency services arranges a PKI, data providers could be 2436 provisioned with the root CA public key for a given nation. Some 2437 nations are developing a PKI for this, and related, purposes. Since 2438 calls could be made from devices where the device and/or the service 2439 provider(s) are not local to the emergency authorities, globally 2440 recognized credentials are useful. This might be accomplished by 2441 extending the notion of the "forest guide" described in [RFC5222] to 2442 allow the forest guide to provide the credential of the PKI root for 2443 areas that it has coverage information for, but standards for such a 2444 mechanism are not yet available. In its absence, the data provider 2445 will need to obtain the root CA credentials for any areas it is 2446 willing to provide additional data by out of band means. With the 2447 credential of the root CA for a national emergency services PKI, the 2448 data provider server can validate the credentials of an entity 2449 requesting additional data by reference. 2451 The data provider also needs a credential that can be verified by the 2452 emergency services to know that it is receiving data from the right 2453 server. The emergency authorities could provide credentials, 2454 distinguishable from credentials it provides to emergency responders 2455 and PSAPs, which could be used to validate data providers. Such 2456 credentials would have to be acceptable to any PSAP or responder that 2457 could receive a call with additional data supplied by that provider. 2458 This would be extensible to global credential validation using the 2459 forest guide as above. In the absence of such credentials, the 2460 emergency authorities could maintain a list of local data providers' 2461 credentials provided to it out of band. At a minimum, the emergency 2462 authorities could obtain a credential from the DNS entry of the 2463 domain in the Additional Data URI to at least validate that the 2464 server is known to the domain providing the URI. 2466 Data provided by devices by reference have similar credential 2467 validation issues to service providers, and the solutions are the 2468 same. 2470 8. Privacy Considerations 2472 This document enables functionality for conveying additional 2473 information about the caller to the callee. Some of this information 2474 is personal data and therefore privacy concerns arise. An explicit 2475 privacy indicator for information directly relating to the callers 2476 identity is defined and use is mandatory. However, observance of 2477 this request for privacy and what information it relates to is 2478 controlled by the destination jurisdiction. 2480 There are a number of privacy concerns with regular real-time 2481 communication services that are also applicable to emergency calling. 2482 Data protection regulation world-wide has, however, decided to create 2483 exceptions for emergency services since the drawbacks of disclosing 2484 personal data in comparison to the benefit for the emergency caller 2485 are often towards the latter. Hence, the data protection rights of 2486 individuals are often waived for emergency situations. There are, 2487 however, still various countries that offer some degree of anonymity 2488 for the caller towards PSAP call takers. 2490 The functionality defined in this document, however, far exceeds the 2491 amount of information sharing found in the Plain old telephone system 2492 (POTS). For this reason there are additional privacy threats to 2493 consider, which are described in more detail in [RFC6973]. 2495 Stored Data Compromise: First, there is an increased risk of stored 2496 data compromise since additional data is collected and stored in 2497 databases. Without adequate measures to secure stored data from 2498 unauthorized or inappropriate access at access network operators, 2499 service providers, end devices, as well as PSAPs individuals are 2500 exposed to potential financial, reputational, or physical harm. 2502 Misattribution: If the personal data collected and conveyed is 2503 incorrect or inaccurate then this may lead to misattribution. 2504 Misattribution occurs when data or communications related to one 2505 individual are attributed to another. 2507 Identification: By the nature of the additional data and its 2508 capability to provide much richer information about the caller, 2509 the call, and the location the calling party is identified in a 2510 much better way. Some users may feel uncomfortable with this 2511 degree of information sharing even in emergency services 2512 situations. 2514 Secondary Use: Furthermore, there is the risk of secondary use. 2515 Secondary use is the use of collected information about an 2516 individual without the individual's consent for a purpose 2517 different from that for which the information was collected. The 2518 stated purpose of the additional data is for emergency services 2519 purposes but theoretically the same information could be used for 2520 any other call as well. Additionally, parties involved in the 2521 emergency call may retain the obtained information and may re-use 2522 it for other, non-emergency services purposes. 2524 Disclosure: When the data defined in this document is not properly 2525 security (while in transit with traditional communication security 2526 techniques, and while at rest using access control mechanisms) 2527 there is the risk of disclosure, which is the revelation of 2528 information about an individual that affects the way others judge 2529 the individual. 2531 To mitigate these privacy risks the following countermeasures can be 2532 taken. 2534 In regions where callers can elect to suppress certain personally 2535 identifying information, the network or PSAP functionality can 2536 inspect privacy flags within the SIP headers to determine what 2537 information may be passed, stored, or displayed to comply with local 2538 policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token. 2539 The presence of this privacy type in a Privacy header field indicates 2540 that the user would like the network asserted identity to be kept 2541 private with respect to SIP entities outside the trust domain with 2542 which the user authenticated, including the PSAP. 2544 This document defines various data structures that constitutes 2545 personal data. Local regulations may govern what data must be 2546 provided in emergency calls, but in general, the emergency call 2547 system is often aided by the kinds of information described in this 2548 document. There is a tradeoff between the privacy considerations and 2549 the utility of the data. For adequate protection this specification 2550 requires all data exchanges to be secured via communication security 2551 techniques (namely TLS) against eavesdropping and inception. 2552 Furthermore, security safeguards are required to prevent unauthorized 2553 access to data at rest. Various security incidents over the last 10 2554 years have shown data breaches are not not uncommon and are often 2555 caused by lack of proper access control frameworks, software bugs 2556 (buffer overflows), or missing input parsing (SQL injection attacks). 2557 The risks of data breaches is increased with the obligation for 2558 emergency services to retain emergency call related data for extended 2559 periods, e.g., several years are the norm. 2561 Finally, it is also worth to highlight the nature of the SIP 2562 communication architecture, which introduces additional complications 2563 for privacy. Some forms of data can be sent by value in the SIP 2564 signaling or by value (URL in SIP signaling). When data is sent by 2565 value, all intermediaries have access to the data. As such, these 2566 intermediaries may also introduce additional privacy risk. 2567 Therefore, in situations where the conveyed information raises 2568 privacy concerns and intermediaries are involved transmitting a 2569 reference is more appropriate (assuming proper access control 2570 policies are available for distinguishing the different entities 2571 dereferencing the reference). Without access control policies any 2572 party in possession of the reference is able to resolve the reference 2573 and to obtain the data, including intermediaries. 2575 9. IANA Considerations 2577 9.1. Registry creation 2579 This document creates a new registry called 'Emergency Call 2580 Additional Data'. The following sub-registries are created for this 2581 registry. 2583 9.1.1. Provider ID Series Registry 2584 This document creates a new sub-registry called 'Additional Call Data 2585 Provider ID Series'. As defined in [RFC5226], this registry operates 2586 under "Expert Review" rules. The expert should determine that the 2587 entity requesting a new value is a legitimate issuer of service 2588 provider IDs suitable for use in Additional Call Data. 2590 The content of this registry includes: 2592 Name: The identifier which will be used in the ProviderIDSeries 2593 element 2595 Source: The full name of the organization issuing the identifiers 2597 URL: A URL to the organization for further information 2599 The initial set of values is listed in Figure 21. 2601 +-----------+--------------------------+----------------------+ 2602 | Name | Source | URL | 2603 +-----------+--------------------------+----------------------+ 2604 | NENA | National Emergency | http://www.nena.org | 2605 | | Number Association | | 2606 | EENA | European Emergency | http://www.eena.org | 2607 | | Number Association | | 2608 +-----------+--------------------------+----------------------+ 2610 Figure 21: Provider ID Series Registry. 2612 9.1.2. Service Environment Registry 2614 This document creates a new sub-registry called 'Additional Call 2615 Service Environment'. As defined in [RFC5226], this registry 2616 operates under "Expert Review" rules. The expert should determine 2617 that the entity requesting a new value is relevant for this service 2618 element. 2620 The content of this registry includes: 2622 Token: The value to be used in element. 2624 Description: A short description of the token. 2626 The initial set of values is listed in Figure 22. 2628 +-----------+--------------------------+ 2629 | Token | Description | 2630 +-----------+--------------------------+ 2631 | Business | [[This RFC]] | 2632 | Residence | [[This RFC]] | 2633 +-----------+--------------------------+ 2635 Figure 22: Service Environment Registry. 2637 9.1.3. Service Provider Type Registry 2639 This document creates a new sub-registry called 'Service Provider 2640 Type'. As defined in [RFC5226], this registry operates under "Expert 2641 Review". The expert should determine that the proposed new value is 2642 distinct from existing values and appropriate for use in the 2643 TypeOfServicerProvider element 2645 The content of this registry includes: 2647 Name: The value to be used in TypeOfServiceProvider. 2649 Description: A short description of the type of service provider 2651 The initial set of values is defined in Figure 1. 2653 9.1.4. Service Delivered Registry 2655 This document creates a new sub-registry called 'Service Delivered'. 2656 As defined in [RFC5226], this registry operates under "Expert Review" 2657 rules. The expert should consider whether the proposed service is 2658 unique from existing services and the definition of the service will 2659 be clear to implementors and PSAPS/responders. 2661 The content of this registry includes: 2663 Name: Enumeration token of the service. 2665 Description: Short description identifying the service. 2667 The initial set of values are defined in Figure 3. 2669 9.1.5. Device Classification Registry 2671 This document creates a new sub-registry called 'Device 2672 Classification'. As defined in [RFC5226], this registry operates 2673 under "Expert Review" rules. The expert should consider whether the 2674 proposed class is unique from existing classes and the definition of 2675 the class will be clear to implementors and PSAPS/responders. 2677 The content of this registry includes: 2679 Name: Enumeration token of the device classification. 2681 Description: Short description identifying the device type. 2683 The initial set of values are defined in Figure 5. 2685 9.1.6. Device ID Type Type Registry 2687 This document creates a new sub-registry called 'Additional Call Data 2688 Device ID Type'. As defined in [RFC5226], this registry operates 2689 under "Expert Review" rules. The expert should ascertain that the 2690 proposed type is well understood, and provides the information useful 2691 to PSAPs and responders to uniquely identify a device. 2693 The content of this registry includes: 2695 Name: Enumeration token of the device id type. 2697 Description: Short description identifying type of device id. 2699 The initial set of values are defined in Figure 6. 2701 9.1.7. Device/Service Data Type Registry 2703 This document creates a new sub-registry called 'Device/Service Data 2704 Type Registry'. As defined in [RFC5226], this registry operates 2705 under "Expert Review" and "Specification Required" rules. The expert 2706 should ascertain that the proposed type is well understood, and 2707 provides information useful to PSAPs and responders. The 2708 specification must contain a complete description of the data, and a 2709 precise format specification suitable to allow interoperable 2710 implementations. 2712 The content of this registry includes: 2714 Name: Enumeration token of the data type. 2716 Description: Short description identifying the the data. 2718 Specification: Citation for the specification of the data. 2720 The initial set of values are listed in Figure 23. 2722 +---------+----------------------------------------+----------------+ 2723 | Token | Description | Specification | 2724 +---------+----------------------------------------+----------------+ 2725 | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | 2726 +---------+----------------------------------------+----------------+ 2727 | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | 2728 +---------+----------------------------------------+----------------+ 2729 Figure 23: Device/Service Data Type Registry. 2731 9.1.8. Additional Data Blocks Registry 2733 This document creates a new sub-registry called 'Additional Data 2734 Blocks' in the purpose registry established by RFC 3261 [RFC3261]. 2735 As defined in [RFC5226], this registry operates under "Expert Review" 2736 and "Specification Required" rules. The expert is responsible for 2737 verifying that the document contains a complete and clear 2738 specification and the proposed functionality does not obviously 2739 duplicate existing functionality. 2741 The content of this registry includes: 2743 Name: Element Name of enclosing block. 2745 Reference: The document that describes the block 2747 The initial set of values are listed in Figure 24. 2749 +--------------+------------+ 2750 | Token | Reference | 2751 +--------------+------------+ 2752 | ProviderInfo | [This RFC] | 2753 | ServiceInfo | [This RFC] | 2754 | DeviceInfo | [This RFC] | 2755 | Subscriber | [This RFC] | 2756 | Comment | [This RFC] | 2757 +--------------+------------+ 2759 Figure 24: Additional Data Blocks Registry. 2761 9.2. 'emergencyCallData' Purpose Parameter Value 2763 This document defines the 'emergencyCallData' value for the "purpose" 2764 parameter of the Call-Info header field. The Call-Info header and 2765 the corresponding registry for the 'purpose' parameter was 2766 established with RFC 3261 [RFC3261]. 2768 Header Parameter New 2769 Field Name Value Reference 2770 ---------- --------- ----------------- --------- 2771 Call-Info purpose emergencyCallData [This RFC] 2773 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 2775 This section registers the namespace specified in Section 9.5.1 in 2776 the provided-by registry established by RFC 4119, for usage within 2777 the element of a PIDF-LO. 2779 The schema for the provided-by schema used by this document is 2780 specified in Section 6.6. 2782 9.4. MIME Registrations 2784 9.4.1. MIME Content-type Registration for 'application/ 2785 emergencyCallData.ProviderInfo+xml' 2787 This specification requests the registration of a new MIME type 2788 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2789 RFC 3023 [RFC3023]. 2791 MIME media type name: application 2793 MIME subtype name: emergencyCallData.ProviderInfo+xml 2795 Mandatory parameters: none 2797 Optional parameters: charset Indicates the character encoding of 2798 enclosed XML. 2800 Encoding considerations: Uses XML, which can employ 8-bit 2801 characters, depending on the character encoding used. See 2802 Section 3.2 of RFC 3023 [RFC3023]. 2804 Security considerations: This content type is designed to carry 2805 the data provider information, which is a sub-category of 2806 additional data about an emergency call. Since this data contains 2807 personal information appropriate precautions have to be taken to 2808 limit unauthorized access, inappropriate disclosure to third 2809 parties, and eavesdropping of this information. Please refer to 2810 Section 7 and Section 8 for more information. 2812 Interoperability considerations: None 2814 Published specification: [TBD: This specification] 2816 Applications which use this media type: Emergency Services 2818 Additional information: Magic Number: None File Extension: .xml 2819 Macintosh file type code: 'TEXT' 2820 Person and email address for further information: Hannes 2821 Tschofenig, Hannes.Tschofenig@gmx.net 2823 Intended usage: LIMITED USE 2825 Author: This specification is a work item of the IETF ECRIT 2826 working group, with mailing list address . 2828 Change controller: The IESG 2830 9.4.2. MIME Content-type Registration for 'application/ 2831 emergencyCallData.ServiceInfo+xml' 2833 This specification requests the registration of a new MIME type 2834 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2835 RFC 3023 [RFC3023]. 2837 MIME media type name: application 2839 MIME subtype name: emergencyCallData.ServiceInfo+xml 2841 Mandatory parameters: none 2843 Optional parameters: charset Indicates the character encoding of 2844 enclosed XML. 2846 Encoding considerations: Uses XML, which can employ 8-bit 2847 characters, depending on the character encoding used. See 2848 Section 3.2 of RFC 3023 [RFC3023]. 2850 Security considerations: This content type is designed to carry 2851 the service information, which is a sub-category of additional 2852 data about an emergency call. Since this data contains personal 2853 information appropriate precautions have to be taken to limit 2854 unauthorized access, inappropriate disclosure to third parties, 2855 and eavesdropping of this information. Please refer to Section 7 2856 and Section 8 for more information. 2858 Interoperability considerations: None 2860 Published specification: [TBD: This specification] 2862 Applications which use this media type: Emergency Services 2864 Additional information: Magic Number: None File Extension: .xml 2865 Macintosh file type code: 'TEXT' 2866 Person and email address for further information: Hannes 2867 Tschofenig, Hannes.Tschofenig@gmx.net 2869 Intended usage: LIMITED USE 2871 Author: This specification is a work item of the IETF ECRIT 2872 working group, with mailing list address . 2874 Change controller: The IESG 2876 9.4.3. MIME Content-type Registration for 'application/ 2877 emergencyCallData.DeviceInfo+xml' 2879 This specification requests the registration of a new MIME type 2880 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2881 RFC 3023 [RFC3023]. 2883 MIME media type name: application 2885 MIME subtype name: emergencyCallData.DeviceInfo+xml 2887 Mandatory parameters: none 2889 Optional parameters: charset Indicates the character encoding of 2890 enclosed XML. 2892 Encoding considerations: Uses XML, which can employ 8-bit 2893 characters, depending on the character encoding used. See 2894 Section 3.2 of RFC 3023 [RFC3023]. 2896 Security considerations: This content type is designed to carry 2897 the device information information, which is a sub-category of 2898 additional data about an emergency call. Since this data contains 2899 personal information appropriate precautions have to be taken to 2900 limit unauthorized access, inappropriate disclosure to third 2901 parties, and eavesdropping of this information. Please refer to 2902 Section 7 and Section 8 for more information. 2904 Interoperability considerations: None 2906 Published specification: [TBD: This specification] 2908 Applications which use this media type: Emergency Services 2910 Additional information: Magic Number: None File Extension: .xml 2911 Macintosh file type code: 'TEXT' 2912 Person and email address for further information: Hannes 2913 Tschofenig, Hannes.Tschofenig@gmx.net 2915 Intended usage: LIMITED USE 2917 Author: This specification is a work item of the IETF ECRIT 2918 working group, with mailing list address . 2920 Change controller: The IESG 2922 9.4.4. MIME Content-type Registration for 'application/ 2923 emergencyCallData.SubscriberInfo+xml' 2925 This specification requests the registration of a new MIME type 2926 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2927 RFC 3023 [RFC3023]. 2929 MIME media type name: application 2931 MIME subtype name: emergencyCallData.SubscriberInfo+xml 2933 Mandatory parameters: none 2935 Optional parameters: charset Indicates the character encoding of 2936 enclosed XML. 2938 Encoding considerations: Uses XML, which can employ 8-bit 2939 characters, depending on the character encoding used. See 2940 Section 3.2 of RFC 3023 [RFC3023]. 2942 Security considerations: This content type is designed to carry 2943 owner/subscriber information, which is a sub-category of 2944 additional data about an emergency call. Since this data contains 2945 personal information appropriate precautions have to be taken to 2946 limit unauthorized access, inappropriate disclosure to third 2947 parties, and eavesdropping of this information. Please refer to 2948 Section 7 and Section 8 for more information. 2950 Interoperability considerations: None 2952 Published specification: [TBD: This specification] 2954 Applications which use this media type: Emergency Services 2956 Additional information: Magic Number: None File Extension: .xml 2957 Macintosh file type code: 'TEXT' 2958 Person and email address for further information: Hannes 2959 Tschofenig, Hannes.Tschofenig@gmx.net 2961 Intended usage: LIMITED USE 2963 Author: This specification is a work item of the IETF ECRIT 2964 working group, with mailing list address . 2966 Change controller: The IESG 2968 9.4.5. MIME Content-type Registration for 'application/ 2969 emergencyCallData.Comment+xml' 2971 This specification requests the registration of a new MIME type 2972 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2973 RFC 3023 [RFC3023]. 2975 MIME media type name: application 2977 MIME subtype name: emergencyCallData.Comment+xml 2979 Mandatory parameters: none 2981 Optional parameters: charset Indicates the character encoding of 2982 enclosed XML. 2984 Encoding considerations: Uses XML, which can employ 8-bit 2985 characters, depending on the character encoding used. See 2986 Section 3.2 of RFC 3023 [RFC3023]. 2988 Security considerations: This content type is designed to carry a 2989 comment, which is a sub-category of additional data about an 2990 emergency call. This data may contain personal information. 2991 Appropriate precautions may have to be taken to limit unauthorized 2992 access, inappropriate disclosure to third parties, and 2993 eavesdropping of this information. Please refer to Section 7 and 2994 Section 8 for more information. 2996 Interoperability considerations: None 2998 Published specification: [TBD: This specification] 3000 Applications which use this media type: Emergency Services 3002 Additional information: Magic Number: None File Extension: .xml 3003 Macintosh file type code: 'TEXT' 3004 Person and email address for further information: Hannes 3005 Tschofenig, Hannes.Tschofenig@gmx.net 3007 Intended usage: LIMITED USE 3009 Author: This specification is a work item of the IETF ECRIT 3010 working group, with mailing list address . 3012 Change controller: The IESG 3014 9.5. URN Sub-Namespace Registration 3016 9.5.1. Registration for urn:ietf:params:xml:ns:emergencycalldata 3018 This section registers a new XML namespace, as per the guidelines in 3019 RFC 3688 [RFC3688]. 3021 URI: urn:ietf:params:xml:ns:emergencycalldata 3023 Registrant Contact: IETF, ECRIT working group, , as 3024 delegated by the IESG . 3026 XML: 3028 BEGIN 3029 3030 3032 3033 3034 3036 Namespace for Additional Emergency Call Data 3037 3038 3039

Namespace for Additional Data related to an Emergency Call

3040

See [TBD: This document].

3041 3042 3043 END 3045 9.5.2. Registration for 3046 urn:ietf:params:xml:ns:emergencycalldata:providerinfo 3048 This section registers a new XML namespace, as per the guidelines in 3049 RFC 3688 [RFC3688]. 3051 URI: urn:ietf:params:xml:ns:emergencycalldata:providerinfo 3053 Registrant Contact: IETF, ECRIT working group, , as 3054 delegated by the IESG . 3056 XML: 3058 BEGIN 3059 3060 3062 3063 3064 3066 Namespace for Additional Emergency Call Data: 3067 Data Provider Information 3068 3069 3070

Namespace for Additional Data related to an Emergency Call

3071

Data Provider Information

3072

See [TBD: This document].

3073 3074 3075 END 3077 9.5.3. Registration for 3078 urn:ietf:params:xml:ns:emergencycalldata:ServiceInfo 3080 This section registers a new XML namespace, as per the guidelines in 3081 RFC 3688 [RFC3688]. 3083 URI: urn:ietf:params:xml:ns:emergencycalldata:ServiceInfo 3085 Registrant Contact: IETF, ECRIT working group, , as 3086 delegated by the IESG . 3088 XML: 3090 BEGIN 3091 3092 3094 3095 3096 3098 Namespace for Additional Emergency Call Data: 3099 Service Information 3100 3101 3102

Namespace for Additional Data related to an Emergency Call

3103

Service Information

3104

See [TBD: This document].

3105 3106 3107 END 3109 9.5.4. Registration for 3110 urn:ietf:params:xml:ns:emergencycalldata:DeviceInfo 3112 This section registers a new XML namespace, as per the guidelines in 3113 RFC 3688 [RFC3688]. 3115 URI: urn:ietf:params:xml:ns:emergencycalldata:DeviceInfo 3117 Registrant Contact: IETF, ECRIT working group, , as 3118 delegated by the IESG . 3120 XML: 3122 BEGIN 3123 3124 3126 3127 3128 3130 Namespace for Additional Emergency Call Data: 3131 Device Information 3132 3133 3134

Namespace for Additional Data related to an Emergency Call

3135

Device Information

3136

See [TBD: This document].

3137 3138 3139 END 3141 9.5.5. Registration for 3142 urn:ietf:params:xml:ns:emergencycalldata:SubscriberInfo 3144 This section registers a new XML namespace, as per the guidelines in 3145 RFC 3688 [RFC3688]. 3147 URI: urn:ietf:params:xml:ns:emergencycalldata:SubscriberInfo 3149 Registrant Contact: IETF, ECRIT working group, , as 3150 delegated by the IESG . 3152 XML: 3154 BEGIN 3155 3156 3158 3159 3160 3162 Namespace for Additional Emergency Call Data: 3163 Owner/Subscriber Information 3164 3165 3166

Namespace for Additional Data related to an Emergency Call

3167

Owner/Subscriber Information

3168

See [TBD: This document].

3169 3170 3171 END 3173 9.5.6. Registration for 3174 urn:ietf:params:xml:ns:emergencycalldata:comment 3176 This section registers a new XML namespace, as per the guidelines in 3177 RFC 3688 [RFC3688]. 3179 URI: urn:ietf:params:xml:ns:emergencycalldata:comment 3181 Registrant Contact: IETF, ECRIT working group, , as 3182 delegated by the IESG . 3184 XML: 3186 BEGIN 3187 3188 3190 3191 3192 3194 Namespace for Additional Emergency Call Data:Comment 3195 3196 3197

Namespace for Additional Data related to an Emergency Call

3198

Comment

3199

See [TBD: This document].

3200 3201 3202 END 3204 9.6. Schema Registrations 3206 This specification registers five schemas, as per the guidelines in 3207 RFC 3688 [RFC3688]. 3209 URI: urn:ietf:params:xml:schema:emergencycalldata:providerinfo 3211 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3212 delegated by the IESG (iesg@ietf.org). 3214 XML: The XML schema can be found in Figure 15. 3216 URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo 3218 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 3219 delegated by the IESG (iesg@ietf.org). 3221 XML: The XML schema can be found in Figure 16. 3223 URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo 3225 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3226 delegated by the IESG (iesg@ietf.org). 3228 XML: The XML schema can be found in Figure 17. 3230 URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo 3231 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3232 delegated by the IESG (iesg@ietf.org). 3234 XML: The XML schema can be found in Section 6.4. 3236 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3238 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3239 delegated by the IESG (iesg@ietf.org). 3241 XML: The XML schema can be found in Section 6.5. 3243 9.7. VCard Parameter Value Registration 3245 This document registers a new value in the vCARD Parameter Values 3246 registry as defined by [RFC6350] with the following template: 3248 Value: main 3250 Purpose: The main telephone number, typically of an enterprise, as 3251 opposed to a direct dial number of an individual employee 3253 Conformance: This value can be used with the "TYPE" parameter 3254 applied on the "TEL" property. 3256 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3257 00 3259 10. Acknowledgments 3261 This work was originally started in NENA and has benefitted from a 3262 large number of participants in NENA standardization efforts, 3263 originally in the Long Term Definition Working Group, the Data 3264 Technical Committee and most recently the Additional Data working 3265 group. The authors are grateful for the initial work and extended 3266 comments provided by many NENA participants, including Delaine 3267 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3268 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 3269 and Robert (Bob) Sherry. 3271 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3272 Thomson, Keith Drage, Laura Liess, and Barbara Stark for their review 3273 comments. 3275 11. References 3277 11.1. Normative References 3279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3280 Requirement Levels", BCP 14, RFC 2119, March 1997. 3282 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3283 Locators", RFC 2392, August 1998. 3285 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 3286 Types", RFC 3023, January 2001. 3288 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3289 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3290 and QSIG Objects", RFC 3204, December 2001. 3292 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3293 A., Peterson, J., Sparks, R., Handley, M., and E. 3294 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3295 June 2002. 3297 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3298 Extensions to the Session Initiation Protocol (SIP) for 3299 Asserted Identity within Trusted Networks", RFC 3325, 3300 November 2002. 3302 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3303 Extensions (MIME) Parameter", RFC 3459, January 2003. 3305 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3306 January 2004. 3308 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3309 Format", RFC 4119, December 2005. 3311 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 3312 Registration Procedures", RFC 4288, December 2005. 3314 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3315 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3316 May 2008. 3318 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3319 Initiation Protocol (SIP)", RFC 5621, September 2009. 3321 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3322 August 2011. 3324 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3325 6351, August 2011. 3327 11.2. Informational References 3329 [I-D.gellens-negotiating-human-language] 3330 Randy, R., "Negotiating Human Language Using SDP", draft- 3331 gellens-negotiating-human-language-02 (work in progress), 3332 February 2013. 3334 [I-D.ietf-ecrit-psap-callback] 3335 Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3336 Patel, "Public Safety Answering Point (PSAP) Callback", 3337 draft-ietf-ecrit-psap-callback-13 (work in progress), 3338 October 2013. 3340 [I-D.ietf-geopriv-relative-location] 3341 Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3342 Thomson, "Relative Location Representation", draft-ietf- 3343 geopriv-relative-location-08 (work in progress), September 3344 2013. 3346 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3347 "Indicating User Agent Capabilities in the Session 3348 Initiation Protocol (SIP)", RFC 3840, August 2004. 3350 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 3351 Emergency Context Resolution with Internet Technologies", 3352 RFC 5012, January 2008. 3354 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3355 Format for Presence Information Data Format Location 3356 Object (PIDF-LO)", RFC 5139, February 2008. 3358 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 3359 Tschofenig, "LoST: A Location-to-Service Translation 3360 Protocol", RFC 5222, August 2008. 3362 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3363 Presence Information Data Format Location Object (PIDF-LO) 3364 Usage Clarification, Considerations, and Recommendations", 3365 RFC 5491, March 2009. 3367 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3368 Thomson, "Dynamic Extensions to the Presence Information 3369 Data Format Location Object (PIDF-LO)", RFC 5962, 3370 September 2010. 3372 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3373 5985, September 2010. 3375 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3376 "Framework for Emergency Calling Using Internet 3377 Multimedia", RFC 6443, December 2011. 3379 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3380 R. George, "Specifying Civic Address Extensions in the 3381 Presence Information Data Format Location Object (PIDF- 3382 LO)", RFC 6848, January 2013. 3384 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3385 Communications Services in Support of Emergency Calling", 3386 BCP 181, RFC 6881, March 2013. 3388 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3389 Morris, J., Hansen, M., and R. Smith, "Privacy 3390 Considerations for Internet Protocols", RFC 6973, July 3391 2013. 3393 Appendix A. XML Schema for vCard/xCard 3395 This section contains the vCard/xCard XML schema version of the Relax 3396 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3397 XML schemas defined in this document. The schema in RFC 6351 3398 [RFC6351] is the normative source and this section is informative 3399 only. 3401 3402 3406 3412 3413 3414 vCard Format Specification 3415 3416 3417 3418 3419 3420 3421 3422 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3437 3438 3439 3441 3442 3443 3444 3445 3447 3448 3449 3451 3452 3453 3454 3455 3457 3458 3459 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 3504 3505 3506 3507 3511 3512 3513 Section 5: Parameters 3514 3515 3516 3517 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 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 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 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 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4437 4438 4440 4441 4442 4443 4444 4445 4446 4448 4449 4450 4451 4452 4453 4454 4456 4457 4458 4460 4462 4463 4464 4466 4467 4468 4469 4471 Authors' Addresses 4473 Brian Rosen 4474 NeuStar 4475 470 Conrad Dr. 4476 Mars, PA 16046 4477 US 4479 Phone: +1 724 382 1051 4480 Email: br@brianrosen.net 4481 Hannes Tschofenig 4482 Nokia Solutions and Networks 4483 Linnoitustie 6 4484 Espoo 02600 4485 Finland 4487 Phone: +358 (50) 4871445 4488 Email: Hannes.Tschofenig@gmx.net 4489 URI: http://www.tschofenig.priv.at 4491 Roger Marshall 4492 TeleCommunication Systems, Inc. 4493 2401 Elliott Avenue 4494 Seattle, WA 98121 4495 US 4497 Phone: +1 206 792 2424 4498 Email: rmarshall@telecomsys.com 4499 URI: http://www.telecomsys.com 4501 Randall Gellens 4502 Qualcomm Technologies, Inc. 4503 5775 Morehouse Drive 4504 San Diego, CA 92121 4505 US 4507 Email: rg+ietf@qti.qualcomm.com 4509 James Winterbottom 4510 AU 4512 Email: a.james.winterbottom@gmail.com