idnits 2.17.1 draft-ietf-ecrit-additional-data-16.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 36 instances of too long lines in the document, the longest one being 16 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 2268 has weird spacing: '...element name=...' == Line 2772 has weird spacing: '...ll-Info pur...' -- The document date (January 16, 2014) is 3724 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 2772, but not defined == Unused Reference: 'RFC5985' is defined on line 3377, 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 20, 2014 Nokia Solutions and Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 J. Winterbottom 12 January 16, 2014 14 Additional Data related to an Emergency Call 15 draft-ietf-ecrit-additional-data-16.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 20, 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 . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . 12 79 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12 80 3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 12 81 3.2. Service Information . . . . . . . . . . . . . . . . . . . 15 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.SvcInfo Example . . . . . . . . . . 17 86 3.3. Device Information . . . . . . . . . . . . . . . . . . . 18 87 3.3.1. Device Classification . . . . . . . . . . . . . . . . 18 88 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19 89 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 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.DevInfo Example . . . . . . . . . . 24 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.SubInfo Example . . . . . . . . . . 25 103 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 32 113 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 44 115 6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 44 116 6.2. emergencyCallData.SvcInfo XML Schema . . . . . . . . . . 46 117 6.3. emergencyCallData.DevInfo XML Schema . . . . . . . . . . 47 118 6.4. emergencyCallData.SubInfo 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 . . . . . . . . . . . 56 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 . . . . . . . . . . . . 57 131 9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58 132 9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 58 133 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 59 134 9.3. URN Sub-Namespace Registration for provided-by Registry 135 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 59 136 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 59 137 9.4.1. MIME Content-type Registration for 138 'application/emergencyCallData.ProviderInfo+xml' . . 59 139 9.4.2. MIME Content-type Registration for 140 'application/emergencyCallData.SvcInfo+xml' . . . . . 60 141 9.4.3. MIME Content-type Registration for 142 'application/emergencyCallData.DevInfo+xml' . . . . . 61 143 9.4.4. MIME Content-type Registration for 144 'application/emergencyCallData.SubInfo+xml' . . . . . 62 145 9.4.5. MIME Content-type Registration for 146 'application/emergencyCallData.Comment+xml' . . . . . 63 147 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 64 148 9.5.1. Registration for 149 urn:ietf:params:xml:ns:emergencycalldata . . . . . . 64 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:svcinfo . . 66 154 9.5.4. Registration for 155 urn:ietf:params:xml:ns:emergencycalldata:devinfo . . 67 156 9.5.5. Registration for 157 urn:ietf:params:xml:ns:emergencycalldata:subinfo . . 67 158 9.5.6. Registration for 159 urn:ietf:params:xml:ns:emergencycalldata:comment . . 68 160 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 69 161 9.7. VCard Parameter Value Registration . . . . . . . . . . . 69 162 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 163 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 164 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 165 11.2. Informational References . . . . . . . . . . . . . . . . 71 166 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 73 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 169 1. Introduction 171 When an IP-based emergency call is initiated a rich set of data from 172 multiple data sources is conveyed to the Public Safety Answering 173 Point (PSAP). This data includes information about the calling party 174 identity, the multimedia capabilities of the device, the emergency 175 service number, location information, and meta-data about the sources 176 of the data. The device, the access network provider, and any 177 service provider in the call path may have even more information 178 useful for a PSAP. This document extends the basic set of data 179 communicated with an IP-based emergency call, as described in 180 [RFC6443] and [RFC6881], in order to carry additional data which may 181 be useful to an entity or call taker handling the call. This data is 182 "additional" to the basic information found in the emergency call 183 signaling used. 185 In general, there are three categories of data communicated in an 186 emergency call: 188 Data Associated with a Location: Location data is conveyed in the 189 Presence Information Data Format Location Object (PIDF-LO) data 190 structure originally defined in RFC 4119 [RFC4119] and extended by 191 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 192 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 193 geodetic location information), and 194 [I-D.ietf-geopriv-relative-location] (for relative location). 195 There may be data that is specific to the location not available 196 in the location data structure itself, such as floor plans, tenant 197 and building owner contact data, heating, ventilation and air 198 conditioning (HVAC) status, etc. 200 Data Associated with a Call: While information is carried in the 201 call setup procedure itself (as part of the SIP headers as well as 202 in the body of the SIP message), there is additional data known by 203 the device making the call, and the service provider along the 204 path of the call. This information may include the service 205 provider contact information, subscriber identity and contact 206 information, the type of service the service provider and the 207 access network provider offer, what kind of device is being used, 208 etc. Some data is device or service dependent data. For example, 209 a car telematics system may have crash information. A medical 210 monitoring device may have sensor data. 212 Data Associated with a Caller: This is personal data about a caller, 213 such as medical information and emergency contact data. 215 This document only defines data structures relevant to data 216 associated with the call but defines extension points for other data 217 to be added via other specifications. 219 For interoperability, there needs to be a common way for the 220 information conveyed to a PSAP to be encoded and identified. 221 Identification allows emergency services authorities to know during 222 call processing which types of data are present and to determine if 223 they wish to access it. A common encoding allows the data to be 224 accessed. 226 This document defines the data structures and a way to communicate 227 the information in several ways. Although current standardization 228 efforts around IP-based emergency services are focused on the Session 229 Initiation Protocol (SIP) and HTTP the data structures in XML format 230 described in this document are usable for other communication systems 231 as well. In Section 3 the data structures are defined and the SIP/ 232 HTTP transport components are defined in Section 4 to offer a clear 233 separation between the two. 235 More technically, the data structure described in this document is 236 represented as one or more "blocks" of information. Each of the 237 blocks is an XML structure with an associated Multipurpose Internet 238 Mail Extensions (MIME) type for encapsulation, and an extensible set 239 of these types constitute the data set. A registry is defined to 240 list the block types that may be included. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in RFC 2119 [RFC2119]. 248 This document also uses terminology from [RFC5012]. We use the term 249 service provider to refer to an Application Service Provider (ASP). 250 A Voice Service Provider (VSP) is a special type of ASP. With the 251 term "Access Network Provider" we refer to the Internet Access 252 Provider (IAP) and the Internet Service Provider (ISP) without 253 further distinguishing these two entities, since the difference 254 between the two is not relevant for this document. Note that the 255 roles of ASP and access network provider may be provided by a single 256 company. 258 In the data block definitions, see Section 3, the values for the 259 "Use:" label are specified as one of: 261 'Required': means they MUST be present in the data structure. 263 'Conditional': means they MUST be present if the specified 264 condition(s) is met. They MAY be present if the condition(s) is 265 not met. 267 'Optional': means they MAY be present. 269 vCard is a data format for representing and exchanging a variety of 270 information about individuals and other entities. For applications 271 that use XML the format defined in vCard is not immediately 272 applicable. For this purpose an XML-based encoding of the 273 information elements defined in the vCard specification has been 274 defined and the name of that specification is xCard. Since the term 275 vCard is more familiar to most readers we use the term xCard and 276 vCard interchangeable but it would be accurate to use the term vCard 277 only. 279 3. Data Structures 280 This section defines the following five data structures, each as a 281 data block. For each block we define the MIME type, and the XML data 282 structure. The five data structures are: 284 'Data Provider': This block supplies name and contact information 285 for the entity that created the data. Section 3.1 provides the 286 details. 288 'Service Information': This block supplies information about the 289 service. The description can be found in Section 3.2. 291 'Device Information': This block supplies information about the 292 device placing the call. Device information can be found in 293 Section 3.3. 295 'Owner/Subscriber': This block supplies information about the owner 296 of the device or about the subscriber. Details can be found in 297 Section 3.4. 299 'Comment': This block provides a way to supply free form human 300 readable text to the PSAP or emergency responders. This simple 301 structure is defined in Section 3.5. 303 Each block contains a mandatory element. The purpose of this 304 element is to associate the data added by a data provider to the 305 data provider block. Consequently, when a data provider adds 306 additional data to an emergency call (such as device information) it 307 MUST add information about itself (via the data provider block) and 308 the two blocks contain the same value in the element, whereby 309 the chosen value for the element MUST be different to any other 310 elements already added by other data providers. 312 Note that the xCard format is re-used in some of the data structures 313 to provide contact information. In an xCard there is no way to 314 specify a "main" telephone number. These numbers are useful to 315 emergency responders who are called to a large enterprise. This 316 document adds a new property value to the "tel" property of the TYPE 317 parameter called "main". It can be used in any xCard in additional 318 data. 320 3.1. Data Provider Information 322 This block is intended to be provided by any service provider in the 323 path of the call or the access network provider. It includes 324 identification and contact information. This block SHOULD be 325 provided by every service provider in the call path, and by the 326 access network provider. Devices MAY use this block to provide 327 identifying information. The MIME subtype is "application/ 328 emergencyCall.ProviderInfo+xml". An access network provider SHOULD 329 provide this block either by value or by reference in the Provided-By 330 section of a PIDF-LO 332 3.1.1. Data Provider String 334 Data Element: Data Provider String 336 Use: Required 338 XML Element: 340 Description: This is a plain language string suitable for displaying 341 the name of the service provider that created the additional data 342 structure. If the device created the structure the value is 343 identical to the contact header in the SIP INVITE. 345 Reason for Need: Inform the call taker of the identity of the entity 346 providing the additional call data structure. 348 How Used by Call Taker: Allows the call taker to interpret the data 349 in this structure. The source of the information often influences 350 how the information is used, believed or verified. 352 3.1.2. Data Provider ID 354 Data Element: Data Provider ID 356 Use: Conditional. This data SHOULD be provided if the service 357 provider or access provider is located in a jurisdiction that 358 maintains such ids. For example, in North America, this would be 359 a "NENA Company ID". 361 XML Element: 363 Description: A jurisdiction specific code for the access provider or 364 service provider shown in the element that 365 created the structure of the call. NOTE: In the US, the NENA 366 Company ID must appear here. Additional information can be found 367 at http://www.nena.org/nena-company-id. The NENA Company ID MUST 368 be in the form of a URI in the following format: 369 urn:nena:companyid: 371 Reason for Need: Inform the call taker of the identity of the entity 372 providing the additional call data structure. 374 How Used by Call Taker: Where jurisdictions have lists of providers 375 the Data Provider ID provides useful information about the data 376 source. 378 3.1.3. Data Provider ID Series 380 Data Element: Data Provider ID Series 382 Use: Conditional. If Data Provider ID is provided, Data Provider ID 383 Series is required. 385 XML Element: 387 Description: Identifies the issuer of the ProviderId. A registry 388 will reflect the following valid entries: 390 * NENA 392 * EENA 394 Reason for Need: Identifies how to interpret the Data Provider ID. 396 How Used by Call Taker: Determines which provider ID registry to 397 consult for more information 399 3.1.4. Type of Data Provider 401 Data Element: Type of Data Provider ID 403 Use: Conditional. If Data Provider ID is provided, Type of Data 404 Provider ID is required. 406 XML Element: 408 Description: Identifies the type of data provider id being supplied 409 in the ProviderId data element. A registry with an initial set of 410 values is shown in Figure 1. 412 +------------------------------+------------------------------------+ 413 | Token | Description | 414 +------------------------------+------------------------------------+ 415 |Access Network Provider | Access network service provider | 416 |Service Provider | Calling or Origination telecom SP | 417 |Subcontractor | A contractor to another SP | 418 |Telematics Provider | A sensor based SP, especially | 419 | | vehicle based | 420 |Language Translation Provider | A spoken language translation SP | 421 |Emergency Service Provider | An emergency service provider | 422 | | conveying information to another | 423 | | emergency service provider. | 424 |Emergency Modality Translation| An emergency call specific | 425 | | modality translation service | 426 | | e.g., for sign language | 427 |Relay Provider | A interpretation SP, for example, | 428 | | video relay for sign language | 429 | | interpreting | 430 |Other | Any other type of service provider | 431 +------------------------------+------------------------------------+ 433 Figure 1: Type of Data Provider ID Registry. 435 Reason for Need: Identifies what kind of data provider this is. 437 How Used by Call Taker: To decide who to contact when further 438 information is needed 440 3.1.5. Data Provider Contact URI 442 Data Element: Data Provider Contact URI 444 Use: Required 446 XML Element: 448 Description: When provided by a service provider or an access 449 provider, this information MUST be a URI to a 24/7 support 450 organization tasked to provide PSAP support for this emergency 451 call. If the call is from a device, this would reflect the 452 contact information of the owner of the device. If a telephone 453 number is the contact address then it MUST be tel URI. If it is 454 provided as a SIP URI then it MUST be in the form of 455 sip:telephonenumber@serviceprovider:user=phone. Note that this 456 contact information is not used by PSAPs for callbacks using a SIP 457 Priority header field with the value set to "psap- callback", as 458 described in [I-D.ietf-ecrit-psap-callback]. 460 Reason for Need: Additional data providers may need to be contacted 461 for error or other unusual circumstances. 463 How Used by Call Taker: To contact the supplier of the additional 464 data for assistance in handling the call. 466 3.1.6. Data Provider Languages(s) Supported 468 Data Element: Data Provider Language(s) supported 469 Use: Required. 471 XML Element: 473 Description: The language used by the entity at the Data Provider 474 Contact URI as an alpha 2-character code as defined in ISO 475 639-1:2002 Codes for the representation of names of languages -- 476 Part 1: Alpha-2 code Multiple instances of this element may occur. 477 Order is significant; preferred language should appear first. The 478 content MUST reflect the languages supported at the contact URI. 480 Note that the 'language' media feature tag, defined in RFC 3840 481 [RFC3840] and the more extensive language negotiation mechanism 482 proposed with [I-D.gellens-negotiating-human-language] are 483 independent of this data provider language indication. 485 Reason for Need: Information needed to determine if emergency 486 service authority can communicate with the service provider or if 487 an interpreter will be needed. 489 How Used by Call Taker: If call taker cannot speak language(s) 490 supported by the service provider, a translation service will need 491 to be added to the conversation. Alternatively, other persons at 492 the PSAP, besides the call taker, might be consulted for help 493 (depending on the urgency and the type of interaction). 495 3.1.7. xCard of Data Provider 497 Data Element: xCard of Data Provider 499 Use: Optional 501 XML Element: 503 Description: There are many fields in the xCard and the creator of 504 the data structure is encouraged to provide as much information as 505 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 506 minimum. N should contain name of support group or device owner 507 as appropriate. If more than one TEL property is provided, a 508 parameter from the vCard Property Value registry MUST be specified 509 on each TEL. For encoding of the xCard this specification uses 510 the XML-based encoding specified in [RFC6351]. and is hereinafter 511 referred to as "xCard" 513 Reason for Need: Information needed to determine additional contact 514 information. 516 How Used by Call Taker: Assists call taker by providing additional 517 contact information that may not be included in the SIP invite or 518 the PIDF-LO. 520 3.1.8. Subcontractor Principal 522 Data Element: Subcontractor Principal 524 Use: Conditional. This data is required if the Data Provider type 525 is subcontractor. 527 XML Element: 529 Description: Some providers outsource their obligations to handle 530 aspects of emergency services to specialized providers. If the 531 data provider is a subcontractor to another provider this element 532 contains the DataProviderString of the service provider to 533 indicate which provider the subcontractor is working for. 535 Reason for Need: Identify the entity the subcontractor works for. 537 How Used by Call Taker: Allows the call taker to understand what the 538 relationship between data providers and the service providers in 539 the path of the call are. 541 3.1.9. Subcontractor Priority 543 Data Element: Subcontractor Priority 545 Use: Conditional. This element is required if the Data Provider 546 type is set to "Subcontractor". 548 XML Element: 550 Description: If the subcontractor has to be contacted first then 551 this element MUST have the value "sub". If the provider the 552 subcontractor is working for has to be contacted first then this 553 element MUST have the value "main". 555 Reason for Need: Inform the call taker whom to contact first, if 556 support is needed. 558 How Used by Call Taker: To decide which entity to contact first if 559 assistance is needed. 561 3.1.10. ProviderInfo Example 562 563 566 12345 567 Example VoIP Provider 568 569 urn:nena:companyid:ID123 570 NENA 571 Service Provider 572 sip:voip-provider@example.com 573 EN 574 576 577 Hannes Tschofenig 578 579 Hannes 580 Tschofenig 581 582 583 Dipl. Ing. 584 585 --0203 586 587 20090808T1430-0500 588 589 M 590 591 1 592 593 de 594 595 596 2 597 598 en 599 600 601 work 602 603 Example VoIP Provider 604 605 606 607 work 608 612 613 614 615 Linnoitustie 6 616 Espoo 617 Uusimaa 618 02600 619 Finland 620 621 622 623 624 work 625 voice 626 627 628 tel:+358 50 4871445 629 630 631 work 632 633 hannes.tschofenig@nsn.com 634 635 636 work 637 638 geo:60.210796,24.812924 639 640 641 home 642 643 644 http://www.tschofenig.priv.at/key.asc 645 646 647 Finland/Helsinki 648 649 home 650 651 http://www.tschofenig.priv.at 652 653 654 655 657 Figure 2: emergencyCall.ProviderInfo Example. 659 3.2. Service Information 661 This block describes the service that the service provider provides 662 to the caller. It SHOULD be included by all SPs in the path of the 663 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 665 3.2.1. Service Environment 667 Data Element: Service Environment 669 Use: Required 671 XML Element: 673 Description: This element defines whether a call is from a business 674 or residence caller. Currently, the only valid entries are 675 'Business' or 'Residence'. New values can be defined via the 676 registry created in Figure 22. 678 Reason for Need: To assist in determining equipment and manpower 679 requirements. 681 How Used by Call Taker: Information may be used to assist in 682 determining equipment and manpower requirements for emergency 683 responders. As the information is not always available, and the 684 registry is not all encompassing, this is at best advisory 685 information, but since it mimics a similar capability in some 686 current emergency calling systems, it is known to be valuable. 687 The service provider uses its best information (such as a rate 688 plan, facilities used to deliver service or service description) 689 to determine the information and is not responsible for 690 determining the actual characteristics of the location where the 691 call originates from. 693 3.2.2. Service Delivered by Provider to End User 695 Data Element: Service Delivered by Provider to End User 697 Use: Required 699 XML Element: 701 Description: This defines the type of service the end user has 702 subscribed to. The implied mobility of this service cannot be 703 relied upon. A registry with an initial set of values is defined 704 in Figure 3. 706 +--------+----------------------------------------+ 707 | Name | Description | 708 +--------+----------------------------------------+ 709 | Wrless | Wireless Telephone Service: Includes | 710 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 711 | | LTE (Long Term Evolution) | 712 | Coin | Fixed Public Pay/Coin telephones: Any | 713 | | coin or credit card operated device | 714 | 1way | One way outbound service | 715 | Prison | Inmate call/service | 716 | Temp | Soft dialtone/quick service/warm | 717 | | disconnect/suspended | 718 | MLTS | Multi-line telephone system: Includes | 719 | | all PBX, Centrex, key systems, | 720 | | Shared Tenant Service | 721 | SenseU | Sensor, unattended: Includes devices | 722 | | that generate DATA ONLY. This is | 723 | | one-way information exchange and | 724 | | there will be no other form of | 725 | | communication | 726 | SenseA | Sensor, attended: Includes devices | 727 | | that are supported by a monitoring | 728 | | service provider or automatically | 729 | | open a two-way communication path | 730 | POTS | Wireline: Plain Old Telephone Service | 731 | VOIP | VoIP Telephone Service: A type of | 732 | | service that offers communication | 733 | | over internet protocol, such as Fixed| 734 | | Nomadic, Mobile, ... | 735 | Remote | Off premise extension | 736 | Relay | Relay Service: a type of service where | 737 | | there is a human 3rd party agent who | 738 | | provides some kind of additional | 739 | | assistance to the caller. Includes | 740 | | sign language relay and telematics | 741 | | services which provide a service | 742 | | assistant on the call. | 743 +--------+----------------------------------------+ 745 Figure 3: Service Delivered by Provider to End User Registry. 747 More than one value MAY be returned. For example, a VoIP inmate 748 telephone service is a reasonable combination. 750 Reason for Need: Knowing the type of service may assist the PSAP 751 with the handling of the call. 753 How Used by Call Taker: Call takers often use this information to 754 determine what kinds of questions to ask callers, and how much to 755 rely on supportive information. An emergency call from a prison 756 is treated differently that a call from a sensor device. As the 757 information is not always available, and the registry is not all 758 encompassing, this is at best advisory information, but since it 759 mimics a similar capability in some current emergency calling 760 systems, it is known to be valuable. 762 3.2.3. Service Mobility Environment 764 Data Element: Service Mobility Environment 766 Use: Required 768 XML Element: 770 Description: This provides the service providers view of the 771 mobility of the caller. As the service provider may not know the 772 characteristics of the actual access network used, the value not 773 be relied upon. A registry will reflect the following initial 774 valid entries: 776 * Mobile: the device should be able to move at any time 778 * Fixed: the device is not expected to move unless the service is 779 relocated 781 * Nomadic: the device is not expected to change its point of 782 attachment while on a call 784 * Unknown: no information is known about the service mobility 785 environment for the device 787 Reason for Need: Knowing the service provider's belief of mobility 788 may assist the PSAP with the handling of the call. 790 How Used by Call Taker: To determine whether to assume the location 791 of the caller might change. 793 3.2.4. emergencyCallData.SvcInfo Example 795 796 799 12345 800 Business 801 MLTS 802 Fixed 803 805 Figure 4: emergencyCallData.SvcInfo Example. 807 3.3. Device Information 809 This block provides information about the device used to place the 810 call. It should be provided by any service provider that knows what 811 device is being used, and by the device itself. The mime subtype is 812 "application/emergencyCall.DevInfo+xml". 814 3.3.1. Device Classification 816 Data Element: Device Classification 818 Use: Optional 820 XML Element: 822 Description: This data element defines the kind of device making the 823 emergency call. If the device provides the data structure, the 824 device information SHOULD be provided. If the service provider 825 provides the structure and it knows what the device is, the 826 service provider SHOULD provide the device information. Often the 827 carrier does not know what the device is. It is possible to 828 receive two Additional Data Associated with a Call data 829 structures, one created by the device and one created by the 830 service provider. This information describes the device, not how 831 it is being used. This data element defines the kind of device 832 making the emergency call. The registry with the initial set of 833 values is shown in Figure 5. 835 +--------+----------------------------------------+ 836 | Token | Description | 837 +--------+----------------------------------------+ 838 |Cordless| Cordless handset | 839 | Fixed | Fixed phone | 840 | Mobile | Mobile handset | 841 | ATA | analog terminal adapter | 842 |Satphone| Satellite phone | 843 | FSense | Stationary computing device (alarm | 844 | | system, data sensor) | 845 | Guard | Guardian devices | 846 | Desktop| Desktop PC | 847 | Laptop | Laptop computing device | 848 | Tablet | Tablet computing device | 849 | Alarm | Alarm system | 850 | MSense | Mobile Data sensor | 851 | Beacon | Personal beacons (spot) | 852 | Auto | Auto telematics | 853 | Truck | Truck telematics | 854 | Farm | Farm equipment telematics | 855 | Marine | Marine telematics | 856 | PDA | Personal digital assistant | 857 | PND | Personal navigation device) | 858 | SmrtPhn| Smart phone | 859 | Itab | Internet tablet | 860 | Game | Gaming console | 861 | Video | Video phone | 862 | Text | Other text device | 863 |SoftPhn | Soft phone or soft client software | 864 | NA | Not Available | 865 +--------+----------------------------------------+ 867 Figure 5: Device Classification Registry. 869 Reason for Need: The device classification implies the capability of 870 the calling device and assists in identifying the meaning of the 871 emergency call location information that is being presented. For 872 example, does the device require human intervention to initiate a 873 call or is this call the result of programmed instructions? Does 874 the calling device have the ability to update location or 875 condition changes? Is this device interactive or a one-way 876 reporting device? 878 How Used by Call Taker: May assist with location of caller. For 879 example, a cordless handset may be outside or next door. May 880 provide the calltaker some context about the caller, the 881 capabilities of the device used for the call or the environment 882 the device is being used in. 884 3.3.2. Device Manufacturer 886 Data Element: Device Manufacturer 888 Use: Optional 890 XML Element: 892 Description: The plain language name of the manufacturer of the 893 device. 895 Reason for Need: Used by PSAP management for post-mortem 896 investigation/resolution. 898 How Used by Call Taker: Probably not used by the calltaker, but by 899 PSAP management. 901 3.3.3. Device Model Number 903 Data Element: Device Model Number 905 Use: Optional 907 XML Element: 909 Description: Model number of the device. 911 Reason for Need: Used by PSAP management for after action 912 investigation/resolution. 914 How Used by Call Taker: Probably not used by the calltaker, but by 915 PSAP management. 917 3.3.4. Unique Device Identifier 919 Data Element: Unique Device Identifier 921 Use: Optional 923 XML Element: 925 Description: String that identifies the specific device making the 926 call or creating an event. 928 Reason for Need: Uniquely identifies the device as opposed to any 929 signaling identifiers encountered in the call signaling stream. 931 How Used by Call Taker: Probably not used by the calltaker; they 932 would need to refer to management for investigation. 934 3.3.5. Type of Device Identifier 936 Data Element: Type of Device Identifier 938 Use: Conditional: must be provided if the DeviceID is provided 940 XML Element: 941 Description: Identifies the type of device identifier being 942 generated in the unique device identifier data element. A 943 registry with an initial set of values can be seen in Figure 6. 945 +--------+----------------------------------------+ 946 | Token | Description | 947 +--------+----------------------------------------+ 948 | MEID | Mobile Equipment Identifier (CDMA) | 949 | ESN | Electronic Serial Number(GSM) | 950 | MAC | Media Access Control Address (IEEE) | 951 | WiMAX | Device Certificate Unique ID | 952 | IMEI | International Mobile Equipment ID (GSM)| 953 | UDI | Unique Device Identifier | 954 | RFID | Radio Frequency Identification | 955 | SN | Manufacturer Serial Number | 956 +--------+----------------------------------------+ 958 Figure 6: Registry with Device Identifier Types. 960 Reason for Need: Identifies how to interpret the Unique Device 961 Identifier. 963 How Used by Call Taker: Additional information that may be used to 964 assist with call handling. 966 3.3.6. Device/Service Specific Additional Data Structure 968 Data Element: Device/service specific additional data structure 970 Use: Optional 972 XML Element: 974 Description: A URI representing additional data whose schema is 975 specific to the device or service which created it. An example is 976 the Vehicular Emergency Data Set (VEDS) structure for a vehicle 977 telematics device. The URI, when dereferenced, MUST yield a data 978 structure defined by the Device/service specific additional data 979 type value. Different data may be created by each classification; 980 e.g., a telematics created VEDS data set. 982 Reason for Need: Provides device/service specific data that may be 983 used by the call taker and/or responders. 985 How Used by Call Taker: Provide information to guide call takers to 986 select appropriate responders, give appropriate pre-arrival 987 instructions to callers, and advise responders of what to be 988 prepared for. May be used by responders to guide assistance 989 provided. 991 3.3.7. Device/Service Specific Additional Data Structure Type 993 Data Element: Type of device/service specific additional data 994 structure 996 Use: Conditional. MUST be provided when device/service specific 997 additional URI is provided 999 XML Element: 1001 Description: Value from a registry defined by this document to 1002 describe the type of data that can be retrieved from the device/ 1003 service specific additional data structure. Initial values are: 1005 * IEEE 1512 1007 * VEDS 1009 IEEE 1512 is the USDoT model for traffic incidents and VEDS 1010 provides data elements needed for an efficient emergency response 1011 to vehicular emergency incidents. 1013 Reason for Need: This data element allows identification of 1014 externally defined schemas, which may have additional data that 1015 may assist in emergency response. 1017 How Used by Call Taker: This data element allows the end user 1018 (calltaker or first responder) to know what type of additional 1019 data may be available to aid in providing the needed emergency 1020 services. 1022 Note: Information which is specific to a location or a caller 1023 (person) should not be placed in this section. 1025 3.3.8. Issues with getting new types of data into use 1027 This document describes two mechanisms which allow extension of the 1028 kind of data provided with an emergency call: define a new block or 1029 define a new service specific additional data URL for the DevInfo 1030 block. While defining new data types and getting a new device or 1031 application to send the new data may be easy, getting PSAPs and 1032 responders to actually retrieve the data and use it will be 1033 difficult. New mechanism providers should understand that acquiring 1034 and using new forms of data usually require software upgrades at the 1035 PSAP and/or responders, as well as training of call takers and 1036 responders in how to interpret and use the information. Legal and 1037 operational review may also be needed. Overwhelming a call taker or 1038 responder with too much information is highly discouraged. Thus, the 1039 barrier to supporting new data is quite high. 1041 The mechanisms this document describes are meant to encourage 1042 development of widely supported, common data formats for classes of 1043 devices. If all manufacturers of a class of device use the same 1044 format, and the data can be shown to improve outcomes, then PSAPs and 1045 responders may be encouraged to upgrade their systems and train their 1046 staff to use the data. Variations, however well intentioned, are 1047 unlikely to be supported. 1049 Implementers should consider that data from sensor-based devices in 1050 some cases may not be useful to call takers or PSAPs (and privacy or 1051 other considerations may preclude the PSAP from touching the data), 1052 but may be of use to responders. Some standards being developed by 1053 other organizations to carry data from the PSAP to responders are 1054 designed to carry all additional data supplied in the call that 1055 conform to this document, even if the PSAP does not fetch or 1056 interpret the data. This allows responders to get the data even if 1057 the PSAP does not. 1059 3.3.9. Choosing between defining a new type of block or new type of 1060 device/service specific additional data 1062 For devices that have device or service specific data, there are two 1063 choices to carry it. A new block can be defined, or the device/ 1064 service specific additional data URL the DevInfo block can be used 1065 and a new type for it defined . The data passed would likely be the 1066 same in both cases. Considerations for choosing which mechanism to 1067 register under include: 1069 Applicability: Information which will be carried by many kinds of 1070 devices or services are more appropriately defined as separate 1071 blocks. 1073 Privacy: Information which may contain private data may be better 1074 sent in the DevInfo block, rather than a new block so that 1075 implementations are not tempted to send the data by value, and 1076 thus having more exposure to the data than forcing the data to be 1077 retrieved via the URL in DevInfo. 1079 Size: Information which may be very may be better sent in the 1080 DevInfo block, rather than a new block so that implementations are 1081 not tempted to send the data by value. Conversely, data which is 1082 small may best be sent in a separate block so that it can be sent 1083 by value 1085 Availability of a server: Providing the data via the device block 1086 requires a server be made available to retrieve the data. 1087 Providing the data via new block allows it to be sent by value 1088 (CID). 1090 3.3.10. emergencyCallData.DevInfo Example 1092 1093 1096 12345 1097 Fixed phone 1098 Nokia 1099 Lumia 800 1100 35788104 1101 IMEI 1102 1104 Figure 7: emergencyCallData.DevInfo Example. 1106 3.4. Owner/Subscriber Information 1108 This block describes the owner of the device (if provided by the 1109 device) or the subscriber information, if provided by a service 1110 provider. The contact location is not necessarily the location of 1111 the caller or incident, but is rather the nominal contact address. 1112 The mime subtype is "application/emergencyCall.Subscriber+xml". 1114 In some jurisdictions some or all parts of the subscriber-specific 1115 information are subject to privacy constraints. These constraints 1116 vary but dictate what information and be displayed and logged. A 1117 general privacy indicator expressing a desire for privacy is 1118 provided. The interpretation of how this is applied is left to the 1119 receiving jurisdiction as the custodians of the local regulatory 1120 requirements. 1122 3.4.1. Subscriber Data Privacy Indicator 1124 Attribute: privacyRequested, boolean. 1126 Use: Conditional. This attribute MUST be provided if the owner/ 1127 subscriber information block is not empty. 1129 Description: The subscriber data privacy indicator specifically 1130 expresses the subscriber's desire for privacy. In some 1131 jurisdictions subscriber services can have a specific "Type of 1132 Service" which prohibits information, such as the name of the 1133 subscriber, from being displayed. This attribute should be used 1134 to explicitly indicate whether the subscriber service includes 1135 such constraints. 1137 Reason for Need: Some jurisdictions require subscriber privacy to be 1138 observed. 1140 How Used by Call Taker: Where privacy is indicated the call taker 1141 may not have access to some aspects of the subscriber information. 1143 3.4.2. xCard for Subscriber's Data 1145 Data Element: xCARD for Subscriber's Data 1147 Use: Conditional. Subscriber data is provided unless it is not 1148 available. Some services, for example prepaid phones, non- 1149 initialized phones, etc., do not have information about the 1150 subscriber. 1152 XML Element: 1154 Description: Information known by the service provider or device 1155 about the subscriber; e.g., Name, Address, Individual Telephone 1156 Number, Main Telephone Number and any other data. N, ORG (if 1157 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1158 than one TEL property is provided, a parameter from the vCard 1159 Property Value registry MUST be specified on each TEL. 1161 Reason for Need: When the caller is unable to provide information, 1162 this data may be used to obtain it 1164 How Used by Call Taker: Obtaining critical information about the 1165 caller and possibly the location when it is not able to be 1166 obtained otherwise. 1168 3.4.3. emergencyCallData.SubInfo Example 1170 1171 1175 12345 1176 1177 1178 1179 Simon Perreault 1180 1181 Perreault 1182 Simon 1183 1184 1185 ing. jr 1186 M.Sc. 1187 1188 --0203 1189 1190 20090808T1430-0500 1191 1192 M 1193 1194 1 1195 1196 fr 1197 1198 1199 2 1200 1201 en 1202 1203 1204 work 1205 1206 Viagenie 1207 1208 1209 1210 work 1211 1215 1216 1217 1218 2875 boul. Laurier, suite D2-630 1219 Quebec 1220 QC 1221 G1V 2M2 1222 Canada 1223 1224 1225 1226 1227 work 1228 voice 1229 1230 1231 tel:+1-418-656-9254;ext=102 1232 1233 1234 1235 1236 work 1237 text 1238 voice 1239 cell 1240 video 1241 1242 1243 tel:+1-418-262-6501 1244 1245 1246 work 1247 1248 simon.perreault@viagenie.ca 1249 1250 1251 work 1252 1253 geo:46.766336,-71.28955 1254 1255 1256 work 1257 1258 1259 http://www.viagenie.ca/simon.perreault/simon.asc 1260 1261 1262 America/Montreal 1263 1264 home 1265 1266 http://nomis80.org 1267 1268 1269 1270 1271 1272 Figure 8: emergencyCallData.SubInfo Example. 1274 3.5. Comment 1276 This block provides a mechanism for the data provider to supply 1277 extra, human readable information to the PSAP. It is not intended 1278 for a general purpose extension mechanism nor does it aim to provide 1279 machine-reable content. The mime subtype is "application/ 1280 emergencyCall.Comment+xml" 1282 3.5.1. Comment 1284 Data Element: EmergencyCall.Comment 1286 Use: Optional 1288 XML Element: 1290 Description: Human readable text providing additional information to 1291 the PSAP staff. 1293 Reason for Need: Explanatory information for values in the data 1294 structure 1296 How Used by Call Taker: To interpret the data provided 1298 3.5.2. emergencyCallData.Comment Example 1300 1301 1304 12345 1305 This is an example text. 1306 1308 Figure 9: EmergencyCallData.Comment Example. 1310 4. Transport 1312 This section defines how to convey additional data to an emergency 1313 service provider. Two different means are specified: the first uses 1314 the call signaling; the second uses the element of a 1315 PIDF-LO [RFC4119]. 1317 1. First, the ability to embed a Uniform Resource Identifier (URI) 1318 in an existing SIP header field, the Call-Info header, is 1319 defined. The URI points to the additional data structure. The 1320 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1321 document adds a new compound token starting with the value 1322 'emergencyCallData' for the Call-Info "purpose" parameter. If 1323 the "purpose" parameter is set to a value starting with 1324 'emergencyCallData', then the Call-Info header contains either an 1325 HTTPS URL pointing to an external resource or a CID (content 1326 indirection) URI that allows the data structure to be placed in 1327 the body of the SIP message. The "purpose" parameter also 1328 indicates the kind of data (by its MIME type) that is available 1329 at the URI. As the data is conveyed using a URI in the SIP 1330 signaling, the data itself may reside on an external resource, or 1331 may be contained within the body of the SIP message. When the 1332 URI refers to data at an external resource, the data is said to 1333 be passed by reference. When the URI refers to data contained 1334 within the body of the SIP message, the data is said to be passed 1335 by value. A PSAP or emergency responder is able to examine the 1336 type of data provided and selectively inspect the data it is 1337 interested in, while forwarding all of it (the values or 1338 references) to downstream entities. To be conveyed in a SIP 1339 body, additional data about a call is defined as a series of MIME 1340 objects. Each block defined in this document is an XML data 1341 structure identified by its MIME type. (Blocks defined by others 1342 may be encoded in XML or not, as identified by their MIME 1343 registration.) As usual, whenever more than one MIME part is 1344 included in the body of a message, MIME-multipart (i.e., 1345 'multipart/mixed') encloses them all. This document defines a 1346 set of XML schemas and MIME types used for each block defined 1347 here. When additional data is passed by value in the SIP 1348 signaling, each CID URL points to one block in the body. 1349 Multiple URIs are used within a Call-Info header field (or 1350 multiple Call-Info header fields) to point to multiple blocks. 1351 When additional data is provided by reference (in SIP signaling 1352 or Provided-By), each HTTPS URL references one block; the data is 1353 retrieved with an HTTPS GET operation, which returns one of the 1354 blocks as an object (the blocks defined here are returned as XML 1355 objects). 1357 2. Second, the ability to embed additional data structures in the 1358 element of a PIDF-LO [RFC4119] is defined. Besides 1359 a service provider in the call path, the access network provider 1360 may also have similar information that may be valuable to the 1361 PSAP. The access network provider may provide location in the 1362 form of a PIDF-LO from a location server via a location 1363 configuration protocol. The data structures described in this 1364 document are not specific to the location itself, but rather 1365 provides descriptive information having to do with the immediate 1366 circumstances about the provision of the location (who the access 1367 network is, how to contact that entity, what kind of service the 1368 access network provides, subscriber information, etc.). This 1369 data is similar in nearly every respect to the data known by 1370 service providers in the path of the call. When the access 1371 network provider and service provider are separate entities, the 1372 access network does not participate in the application layer 1373 signaling (and hence cannot add a Call-Info header field to the 1374 SIP message), but may provide location information to assist in 1375 locating the caller's device. The element of the 1376 PIDF-LO is a mechanism for the access network provider to supply 1377 the information about the entity or organization that supplied 1378 this location information. For this reason, this document 1379 describes a namespace per RFC 4119 for inclusion in the 1380 element of a PIDF-LO for adding information known 1381 to the access network provider. 1383 One or more blocks of data registered in the Emergency Call 1384 Additional Data registry, as defined in Section 9.1, may be included 1385 or referenced in the SIP signaling (using the Call-Info header field) 1386 or in the element of a PIDF-LO. Every block must be 1387 one of the types in the registry. Since the data of an emergency 1388 call may come from multiple sources, the data itself needs 1389 information describing the source. Consequently, each entity adding 1390 additional data MUST supply the "Data Provider" block. All other 1391 blocks are optional, but each entity SHOULD supply any blocks where 1392 it has at least some of the information in the block. 1394 4.1. Transmitting Blocks using the Call-Info Header 1396 A URI to a block MAY be inserted in a SIP request or response method 1397 (most often INVITE or MESSAGE) with a Call-Info header field 1398 containing a purpose value starting with 'emergencyCallData' and the 1399 type of data available at the URI. The type of data is denoted by 1400 including the root of the MIME type (not including the 1401 'emergencyCall' prefix and any suffix such as '+xml') with a '.' 1402 separator. For example, when referencing a block with MIME type 1403 'application/emergencyCall.ProviderInfo+xml', the 'purpose' parameter 1404 is set to 'emergencyCallData.ProviderInfo'. An example "Call-Info" 1405 header field for this would be: 1407 Call-Info: https://www.example.com/23sedde3; 1408 purpose="emergencyCallData.ProviderInfo" 1410 A Call-info header with a purpose value starting with 1411 'emergencyCallData' MUST only be sent on an emergency call, which can 1412 be ascertained by the presence of an emergency service urn in a Route 1413 header of a SIP message. 1415 If the data is provided by reference, an HTTPS URI MUST be included 1416 and consequently Transport Layer Security (TLS) protection is applied 1417 for protecting the retrieval of the information. 1419 The data may also be supplied by value in a SIP message. In this 1420 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1421 referencing the MIME body part. 1423 More than one Call-Info header with a purpose value starting with 1424 'emergencyCallData' can be expected, but at least one MUST be 1425 provided. The device MUST provide one if it knows no service 1426 provider is in the path of the call. The device MAY insert one if it 1427 uses a service provider. Any service provider in the path of the 1428 call MUST insert its own. For example, a device, a telematics 1429 service provider in the call path, as well as the mobile carrier 1430 handling the call will each provide one. There may be circumstances 1431 where there is a service provider who is unaware that the call is an 1432 emergency call and cannot reasonably be expected to determine that it 1433 is an emergency call. In that case, that service provider is not 1434 expected to provide emergencyCallData. 1436 4.2. Transmitting Blocks by Reference using the Provided-By Element 1438 The 'emergencyCallDataReference' element is used to transmit an 1439 additional data block by reference within a 'Provided-By' element of 1440 a PIDF-LO. The 'emergencyCallDataReference' element has two 1441 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1442 type of data block referenced. The value of 'ref' is an HTTPS URL 1443 that resolves to a data structure with information about the call. 1444 The value of 'purpose' is the same as used in a 'Call-Info' header 1445 field (as specified in Section 4.1). 1447 For example, to reference a block with MIME type 'application/ 1448 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1449 'emergencyCallData.ProviderInfo'. An example 1450 'emergencyCallDataReference' element for this would be: 1452 1455 4.3. Transmitting Blocks by Value using the Provided-By Element 1457 It is RECOMMENDED that access networks supply the data specified in 1458 this document by reference, but they MAY provide the data by value. 1460 The 'emergencyCallDataValue' element is used to transmit an 1461 additional data block by value within a 'Provided-By' element of a 1462 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1464 'purpose' to indicate the type of data block contained. The value of 1465 'purpose' is the same as used in a 'Call-Info' header field (as 1466 specified in Section 4.1, and in Section 4.1). The same XML 1467 structure as would be contained in the corresponding MIME type body 1468 part is placed inside the 'emergencyCallDataValue' element. 1470 For example: 1472 1474 1475 1477 1479 This is an example text. 1480 1481 1482 1483 1485 Test 1486 NENA 1487 Access Infrastructure Provider 1488 1489 sip:15555550987@burf.example.com;user=phone 1490 1491 1492 1494 Example Provided-By by Value. 1496 4.4. The Content-Disposition Parameter 1498 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1499 It updates and clarifies handling originally defined in RFC 3261 1500 [RFC3261] based on implementation experience. While RFC 3261 did not 1501 mandate support for 'multipart' message bodies, 'multipart/mixed' 1502 MIME bodies are used by many extensions (including this document) 1503 today. For example, adding a PIDF-LO, SDP, and additional data in 1504 body of a SIP message requires a 'multipart' message body. 1506 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1507 parameter for the Content-Disposition header field. These RFCs 1508 describe how a UAS reacts if it receives a message body whose content 1509 type or disposition type it does not understand. If the 'handling' 1510 parameter has the value "optional", the UAS ignores the message body. 1511 If the 'handling' parameter has the value "required", the UAS returns 1512 a 415 (Unsupported Media Type) response. The 'by-reference' 1513 disposition type allows a SIP message to contain a reference to the 1514 body part, and the SIP UA processes the body part according to the 1515 reference. This is the case for the Call-info header containing a 1516 Content Indirection (CID) URL. 1518 As an example, a SIP message indicates the Content-Disposition 1519 parameter in the body of the SIP message as shown in Figure 10. 1521 Content-Type: application/sdp 1523 ...Omit Content-Disposition here; defaults are ok 1524 ...SDP goes in here 1526 --boundary1 1528 Content-Type: application/pidf+xml 1529 Content-ID: 1530 Content-Disposition: by-reference;handling=optional 1532 ...PIDF-LO goes in here 1534 --boundary1-- 1536 Content-Type: application/emergencyCall.ProviderInfo+xml 1537 Content-ID: <1234567890@atlanta.example.com> 1538 Content-Disposition: by-reference; handling=optional 1540 ...Data provider information data goes in here 1542 --boundary1-- 1544 Figure 10: Example for use of the Content-Disposition Parameter in 1545 SIP. 1547 5. Examples 1549 This section illustrates a longer and more complex example, as shown 1550 in Figure 11. In this example additional data is added by the end 1551 device, included by the VoIP provider (via the PIDF-LO), and provided 1552 by the access network provider. 1554 [================] (1) [================] 1555 [ O +----+ ] Emergency Call [ ] 1556 [ /|\ | UA |-------------------------------> ] 1557 [ | +----+ ] +Device Info [ ] 1558 [ / \ ] +Data Provider Info [ ] 1559 [ ] +Location URI [ ] 1560 [ Access Network ] [ ] 1561 [ Provider ] [ VoIP Provider ] 1562 [ ] [ example.org ] 1563 [ ^ ] [ ] 1564 [=======.========] [============|===] 1565 . | 1566 . | 1567 . [================] | 1568 . [ ] (2) | 1569 . (3) [ <--------------+ 1570 ....................> PSAP ] Emergency Call 1571 Location [ ] +Device Info 1572 +Owner/Subscriber Info [ ] +Data Provider Info #2 1573 +Device Info [ ] +Location URI 1574 +Data Provider Info #3 [================] 1576 Legend: 1578 --- Emergency Call Setup Procedure 1579 ... Location Retrieval/Response 1581 Figure 11: Additional Data Example Flow 1583 The example scenario starts with the end device itself adding device 1584 information, owner/subscriber information, a location URI, and data 1585 provider information to the outgoing emergency call setup message 1586 (see step #1 in Figure 11). The SIP INVITE example is shown in 1587 Figure 12. 1589 INVITE urn:service:sos SIP/2.0 1590 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1591 Max-Forwards: 70 1592 To: 1593 From: Hannes Tschofenig ;tag=9fxced76sl 1594 Call-ID: 3848276298220188511@example.com 1595 Call-Info: ;purpose=icon, 1596 ;purpose=info, 1597 1598 ;purpose=emergencyCallData.ProviderInfo, 1599 1600 ;purpose=emergencyCallData.DevInfo 1601 Geolocation: 1602 Geolocation-Routing: yes 1603 Accept: application/sdp, application/pidf+xml, 1604 application/emergencyCallProviderinfo+xml 1605 CSeq: 31862 INVITE 1606 Contact: 1607 Content-Type: multipart/mixed; boundary=boundary1 1609 Content-Length: ... 1611 --boundary1 1613 Content-Type: application/sdp 1615 ...SDP goes here 1617 --boundary1-- 1619 Content-Type: application/emergencyCallData.DevInfo+xml 1620 Content-ID: <0123456789@atlanta.example.com> 1621 Content-Disposition: by-reference;handling=optional 1622 1624 1627 12345 1628 SoftPhn 1629 00-0d-4b-30-72-df 1630 MAC 1631 1633 --boundary1-- 1635 Content-Type: application/emergencyCallData.ProviderInfo+xml 1636 Content-ID: <1234567890@atlanta.example.com> 1637 Content-Disposition: by-reference;handling=optional 1638 1639 1642 12345 1643 Hannes Tschofenig 1644 1645 Other 1646 sip:hannes@example.com 1647 EN 1648 1650 1651 Hannes Tschofenig 1652 1653 Hannes 1654 Tschofenig 1655 1656 1657 Dipl. Ing. 1658 1659 --0203 1660 1661 20090808T1430-0500 1662 1663 M 1664 1665 1 1666 1667 de 1668 1669 1670 2 1671 1672 en 1673 1674 1675 1676 work 1677 1681 1682 1683 1684 Linnoitustie 6 1685 Espoo 1686 Uusimaa 1687 02600 1688 Finland 1689 1690 1691 1692 1693 work 1694 voice 1696 1697 1698 tel:+358 50 4871445 1699 1700 1701 work 1702 1703 hannes.tschofenig@nsn.com 1704 1705 1706 work 1707 1708 geo:60.210796,24.812924 1709 1710 1711 1712 home 1713 1714 https://www.example.com/key.asc 1715 1716 1717 Finland/Helsinki 1718 1719 home 1720 1721 http://example.com/hannes.tschofenig 1722 1723 1724 1725 1726 --boundary1-- 1728 Figure 12: End Device sending SIP INVITE with Additional Data. 1730 In this example, information available to the access network operator 1731 is included in the call setup message only indirectly via the use of 1732 the location reference. The PSAP has to retrieve it via a separate 1733 look-up step. Since the access network provider and the VoIP service 1734 provider are two independent entities in this scenario the access 1735 network operator is not involved in the processing of application 1736 layer exchanges and forwards the SIP INVITE transparently, as 1737 illustrated in step #1. No change to the SIP INVITE is applied. 1739 When the VoIP service provider receives the message and determines 1740 based on the Service URN that the incoming request is an emergency 1741 call. It performs the typical emergency services related tasks, 1742 including location-based routing, and adds additional data, namely 1743 service and subscriber information, to the outgoing message. For the 1744 example we assume a VoIP service provider that deploys a back-to-back 1745 user agent allowing additional data to be included in the body of the 1746 SIP message (rather than per reference in the header), which allows 1747 us to illustrate the use of multiple data provider info blocks. The 1748 resulting message is shown in Figure 13. 1750 INVITE sips:psap@example.org SIP/2.0 1751 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 1752 Max-Forwards: 70 1753 To: 1754 From: Hannes Tschofenig ;tag=9fxced76sl 1755 Call-ID: 3848276298220188511@example.com 1756 Call-Info: ;purpose=icon, 1757 ;purpose=info, 1758 1759 ;purpose=emergencyCallData.ProviderInfo 1760 1761 ;purpose=emergencyCallData.DevInfo 1762 Call-Info: 1763 ;purpose=emergencyCallData.SrvcInfo 1764 Call-Info: 1765 ;purpose=emergencyCallData.ProviderInfo 1766 Geolocation: 1767 Geolocation-Routing: yes 1768 Accept: application/sdp, application/pidf+xml, 1769 application/emergencyCallData.ProviderInfo+xml 1770 CSeq: 31862 INVITE 1771 Contact: 1772 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.DevInfo+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 1888 1889 1890 1892 --boundary1-- 1894 Content-Type: application/emergencyCall.SvcInfo+xml 1895 Content-ID: 1896 Content-Disposition: by-reference;handling=optional 1897 1898 1901 abc123 1902 Residence 1903 VOIP 1904 Unknown 1905 1907 --boundary1-- 1909 Content-Type: application/emergencyCallData.ProviderInfo+xml 1910 Content-ID: 1911 Content-Disposition: by-reference;handling=optional 1912 1913 1916 abc123 1917 Example VoIP Provider 1918 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 2076 2077 2087 2090 2092 2093 2094 2095 2096 2098 2102 2103 2104 2105 2106 2107 2109 2110 2111 2114 2117 2120 2123 2126 2129 2132 2136 2139 2142 2144 2145 2147 2149 Figure 15: emergencyCallData.ProviderInfo XML Schema. 2151 6.2. emergencyCallData.SvcInfo XML Schema 2153 2154 2162 2165 2167 2168 2169 2172 2175 2178 2181 2184 2186 2187 2189 2191 Figure 16: emergencyCallData.SvcInfo XML Schema. 2193 6.3. emergencyCallData.DevInfo XML Schema 2195 2196 2203 2206 2208 2209 2210 2213 2216 2219 2222 2225 2228 2231 2234 2236 2237 2239 2241 Figure 17: emergencyCallData.DevInfo XML Schema. 2243 6.4. emergencyCallData.SubInfo XML Schema 2245 2246 2255 2258 2260 2262 2263 2264 2265 2268 2271 2273 2274 2275 2276 2278 2280 Figure 18: emergencyCallData.SubInfo XML Schema. 2282 6.5. emergencyCallData.Comment XML Schema 2284 2285 2293 2296 2298 2299 2300 2303 2307 2309 2310 2312 2313 2314 2315 2316 2317 2318 2320 2322 Figure 19: EmergencyCallData.Comment XML Schema. 2324 6.6. Provided-By XML Schema 2326 This section defines the Provided-By schema. 2328 2329 2342 2343 2344 2345 2346 2348 2350 2351 2352 2355 2359 2363 2366 2368 2370 2372 2373 2374 2375 2376 2378 2379 2381 2383 2384 2385 2387 2389 2390 2391 2394 2397 2400 2403 2407 2410 2411 2413 2415 Figure 20: Provided-By XML Schema. 2417 7. Security Considerations 2419 The information in this data structure will usually be considered 2420 private. HTTPS is specified to require the provider of the 2421 information to validate the credentials of the requester. While the 2422 creation of a public key infrastructure (PKI) that has global scope 2423 may be difficult, the alternatives to creating devices and services 2424 that can provide critical information securely are more daunting. 2425 The provider may enforce any policy it wishes to use, but PSAPs and 2426 responder agencies should deploy a PKI so that providers of 2427 additional data can check the certificate of the client and decide 2428 the appropriate policy to enforce based on that certificate. 2430 Ideally, the PSAP and emergency responders will be given credentials 2431 signed by an authority trusted by the data provider. In most 2432 circumstances, nationally recognized credentials would be sufficient, 2433 and if the emergency services arranges a PKI, data providers could be 2434 provisioned with the root CA public key for a given nation. Some 2435 nations are developing a PKI for this, and related, purposes. Since 2436 calls could be made from devices where the device and/or the service 2437 provider(s) are not local to the emergency authorities, globally 2438 recognized credentials are useful. This might be accomplished by 2439 extending the notion of the "forest guide" described in [RFC5222] to 2440 allow the forest guide to provide the credential of the PKI root for 2441 areas that it has coverage information for, but standards for such a 2442 mechanism are not yet available. In its absence, the data provider 2443 will need to obtain the root CA credentials for any areas it is 2444 willing to provide additional data by out of band means. With the 2445 credential of the root CA for a national emergency services PKI, the 2446 data provider server can validate the credentials of an entity 2447 requesting additional data by reference. 2449 The data provider also needs a credential that can be verified by the 2450 emergency services to know that it is receiving data from the right 2451 server. The emergency authorities could provide credentials, 2452 distinguishable from credentials it provides to emergency responders 2453 and PSAPs, which could be used to validate data providers. Such 2454 credentials would have to be acceptable to any PSAP or responder that 2455 could receive a call with additional data supplied by that provider. 2457 This would be extensible to global credential validation using the 2458 forest guide as above. In the absence of such credentials, the 2459 emergency authorities could maintain a list of local data providers' 2460 credentials provided to it out of band. At a minimum, the emergency 2461 authorities could obtain a credential from the DNS entry of the 2462 domain in the Additional Data URI to at least validate that the 2463 server is known to the domain providing the URI. 2465 Data provided by devices by reference have similar credential 2466 validation issues to service providers, and the solutions are the 2467 same. 2469 8. Privacy Considerations 2471 This document enables functionality for conveying additional 2472 information about the caller to the callee. Some of this information 2473 is personal data and therefore privacy concerns arise. An explicit 2474 privacy indicator for information directly relating to the callers 2475 identity is defined and use is mandatory. However, observance of 2476 this request for privacy and what information it relates to is 2477 controlled by the destination jurisdiction. 2479 There are a number of privacy concerns with regular real-time 2480 communication services that are also applicable to emergency calling. 2481 Data protection regulation world-wide has, however, decided to create 2482 exceptions for emergency services since the drawbacks of disclosing 2483 personal data in comparison to the benefit for the emergency caller 2484 are often towards the latter. Hence, the data protection rights of 2485 individuals are often waived for emergency situations. There are, 2486 however, still various countries that offer some degree of anonymity 2487 for the caller towards PSAP call takers. 2489 The functionality defined in this document, however, far exceeds the 2490 amount of information sharing found in the Plain old telephone system 2491 (POTS). For this reason there are additional privacy threats to 2492 consider, which are described in more detail in [RFC6973]. 2494 Stored Data Compromise: First, there is an increased risk of stored 2495 data compromise since additional data is collected and stored in 2496 databases. Without adequate measures to secure stored data from 2497 unauthorized or inappropriate access at access network operators, 2498 service providers, end devices, as well as PSAPs individuals are 2499 exposed to potential financial, reputational, or physical harm. 2501 Misattribution: If the personal data collected and conveyed is 2502 incorrect or inaccurate then this may lead to misattribution. 2503 Misattribution occurs when data or communications related to one 2504 individual are attributed to another. 2506 Identification: By the nature of the additional data and its 2507 capability to provide much richer information about the caller, 2508 the call, and the location the calling party is identified in a 2509 much better way. Some users may feel uncomfortable with this 2510 degree of information sharing even in emergency services 2511 situations. 2513 Secondary Use: Furthermore, there is the risk of secondary use. 2514 Secondary use is the use of collected information about an 2515 individual without the individual's consent for a purpose 2516 different from that for which the information was collected. The 2517 stated purpose of the additional data is for emergency services 2518 purposes but theoretically the same information could be used for 2519 any other call as well. Additionally, parties involved in the 2520 emergency call may retain the obtained information and may re-use 2521 it for other, non-emergency services purposes. 2523 Disclosure: When the data defined in this document is not properly 2524 security (while in transit with traditional communication security 2525 techniques, and while at rest using access control mechanisms) 2526 there is the risk of disclosure, which is the revelation of 2527 information about an individual that affects the way others judge 2528 the individual. 2530 To mitigate these privacy risks the following countermeasures can be 2531 taken. 2533 In regions where callers can elect to suppress certain personally 2534 identifying information, the network or PSAP functionality can 2535 inspect privacy flags within the SIP headers to determine what 2536 information may be passed, stored, or displayed to comply with local 2537 policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token. 2538 The presence of this privacy type in a Privacy header field indicates 2539 that the user would like the network asserted identity to be kept 2540 private with respect to SIP entities outside the trust domain with 2541 which the user authenticated, including the PSAP. 2543 This document defines various data structures that constitutes 2544 personal data. Local regulations may govern what data must be 2545 provided in emergency calls, but in general, the emergency call 2546 system is often aided by the kinds of information described in this 2547 document. There is a tradeoff between the privacy considerations and 2548 the utility of the data. For adequate protection this specification 2549 requires all data exchanges to be secured via communication security 2550 techniques (namely TLS) against eavesdropping and inception. 2551 Furthermore, security safeguards are required to prevent unauthorized 2552 access to data at rest. Various security incidents over the last 10 2553 years have shown data breaches are not not uncommon and are often 2554 caused by lack of proper access control frameworks, software bugs 2555 (buffer overflows), or missing input parsing (SQL injection attacks). 2556 The risks of data breaches is increased with the obligation for 2557 emergency services to retain emergency call related data for extended 2558 periods, e.g., several years are the norm. 2560 Finally, it is also worth to highlight the nature of the SIP 2561 communication architecture, which introduces additional complications 2562 for privacy. Some forms of data can be sent by value in the SIP 2563 signaling or by value (URL in SIP signaling). When data is sent by 2564 value, all intermediaries have access to the data. As such, these 2565 intermediaries may also introduce additional privacy risk. 2566 Therefore, in situations where the conveyed information raises 2567 privacy concerns and intermediaries are involved transmitting a 2568 reference is more appropriate (assuming proper access control 2569 policies are available for distinguishing the different entities 2570 dereferencing the reference). Without access control policies any 2571 party in possession of the reference is able to resolve the reference 2572 and to obtain the data, including intermediaries. 2574 9. IANA Considerations 2576 9.1. Registry creation 2578 This document creates a new registry called 'Emergency Call 2579 Additional Data'. The following sub-registries are created for this 2580 registry. 2582 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 +---------+----------------------------------------+----------------+ 2730 Figure 23: Device/Service Data Type Registry. 2732 9.1.8. Additional Data Blocks Registry 2734 This document creates a new sub-registry called 'Additional Data 2735 Blocks' in the purpose registry established by RFC 3261 [RFC3261]. 2736 As defined in [RFC5226], this registry operates under "Expert Review" 2737 and "Specification Required" rules. The expert is responsible for 2738 verifying that the document contains a complete and clear 2739 specification and the proposed functionality does not obviously 2740 duplicate existing functionality. 2742 The content of this registry includes: 2744 Name: Element Name of enclosing block. 2746 Reference: The document that describes the block 2748 The initial set of values are listed in Figure 24. 2750 +--------------+------------+ 2751 | Token | Reference | 2752 +--------------+------------+ 2753 | ProviderInfo | [This RFC] | 2754 | SvcInfo | [This RFC] | 2755 | DevInfo | [This RFC] | 2756 | Subscriber | [This RFC] | 2757 | Comment | [This RFC] | 2758 +--------------+------------+ 2760 Figure 24: Additional Data Blocks Registry. 2762 9.2. 'emergencyCallData' Purpose Parameter Value 2764 This document defines the 'emergencyCallData' value for the "purpose" 2765 parameter of the Call-Info header field. The Call-Info header and 2766 the corresponding registry for the 'purpose' parameter was 2767 established with RFC 3261 [RFC3261]. 2769 Header Parameter New 2770 Field Name Value Reference 2771 ---------- --------- ----------------- --------- 2772 Call-Info purpose emergencyCallData [This RFC] 2774 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 2776 This section registers the namespace specified in Section 9.5.1 in 2777 the provided-by registry established by RFC 4119, for usage within 2778 the element of a PIDF-LO. 2780 The schema for the provided-by schema used by this document is 2781 specified in Section 6.6. 2783 9.4. MIME Registrations 2785 9.4.1. MIME Content-type Registration for 'application/ 2786 emergencyCallData.ProviderInfo+xml' 2788 This specification requests the registration of a new MIME type 2789 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2790 RFC 3023 [RFC3023]. 2792 MIME media type name: application 2794 MIME subtype name: emergencyCallData.ProviderInfo+xml 2796 Mandatory parameters: none 2798 Optional parameters: charset Indicates the character encoding of 2799 enclosed XML. 2801 Encoding considerations: Uses XML, which can employ 8-bit 2802 characters, depending on the character encoding used. See 2803 Section 3.2 of RFC 3023 [RFC3023]. 2805 Security considerations: This content type is designed to carry 2806 the data provider information, which is a sub-category of 2807 additional data about an emergency call. Since this data contains 2808 personal information appropriate precautions have to be taken to 2809 limit unauthorized access, inappropriate disclosure to third 2810 parties, and eavesdropping of this information. Please refer to 2811 Section 7 and Section 8 for more information. 2813 Interoperability considerations: None 2815 Published specification: [TBD: This specification] 2817 Applications which use this media type: Emergency Services 2819 Additional information: Magic Number: None File Extension: .xml 2820 Macintosh file type code: 'TEXT' 2822 Person and email address for further information: Hannes 2823 Tschofenig, Hannes.Tschofenig@gmx.net 2825 Intended usage: LIMITED USE 2827 Author: This specification is a work item of the IETF ECRIT 2828 working group, with mailing list address . 2830 Change controller: The IESG 2832 9.4.2. MIME Content-type Registration for 'application/ 2833 emergencyCallData.SvcInfo+xml' 2835 This specification requests the registration of a new MIME type 2836 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2837 RFC 3023 [RFC3023]. 2839 MIME media type name: application 2841 MIME subtype name: emergencyCallData.SvcInfo+xml 2843 Mandatory parameters: none 2845 Optional parameters: charset Indicates the character encoding of 2846 enclosed XML. 2848 Encoding considerations: Uses XML, which can employ 8-bit 2849 characters, depending on the character encoding used. See 2850 Section 3.2 of RFC 3023 [RFC3023]. 2852 Security considerations: This content type is designed to carry 2853 the service information, which is a sub-category of additional 2854 data about an emergency call. Since this data contains personal 2855 information appropriate precautions have to be taken to limit 2856 unauthorized access, inappropriate disclosure to third parties, 2857 and eavesdropping of this information. Please refer to Section 7 2858 and Section 8 for more information. 2860 Interoperability considerations: None 2862 Published specification: [TBD: This specification] 2864 Applications which use this media type: Emergency Services 2866 Additional information: Magic Number: None File Extension: .xml 2867 Macintosh file type code: 'TEXT' 2869 Person and email address for further information: Hannes 2870 Tschofenig, Hannes.Tschofenig@gmx.net 2872 Intended usage: LIMITED USE 2874 Author: This specification is a work item of the IETF ECRIT 2875 working group, with mailing list address . 2877 Change controller: The IESG 2879 9.4.3. MIME Content-type Registration for 'application/ 2880 emergencyCallData.DevInfo+xml' 2882 This specification requests the registration of a new MIME type 2883 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2884 RFC 3023 [RFC3023]. 2886 MIME media type name: application 2888 MIME subtype name: emergencyCallData.DevInfo+xml 2890 Mandatory parameters: none 2892 Optional parameters: charset Indicates the character encoding of 2893 enclosed XML. 2895 Encoding considerations: Uses XML, which can employ 8-bit 2896 characters, depending on the character encoding used. See 2897 Section 3.2 of RFC 3023 [RFC3023]. 2899 Security considerations: This content type is designed to carry 2900 the device information information, which is a sub-category of 2901 additional data about an emergency call. Since this data contains 2902 personal information appropriate precautions have to be taken to 2903 limit unauthorized access, inappropriate disclosure to third 2904 parties, and eavesdropping of this information. Please refer to 2905 Section 7 and Section 8 for more information. 2907 Interoperability considerations: None 2909 Published specification: [TBD: This specification] 2911 Applications which use this media type: Emergency Services 2913 Additional information: Magic Number: None File Extension: .xml 2914 Macintosh file type code: 'TEXT' 2916 Person and email address for further information: Hannes 2917 Tschofenig, Hannes.Tschofenig@gmx.net 2919 Intended usage: LIMITED USE 2921 Author: This specification is a work item of the IETF ECRIT 2922 working group, with mailing list address . 2924 Change controller: The IESG 2926 9.4.4. MIME Content-type Registration for 'application/ 2927 emergencyCallData.SubInfo+xml' 2929 This specification requests the registration of a new MIME type 2930 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2931 RFC 3023 [RFC3023]. 2933 MIME media type name: application 2935 MIME subtype name: emergencyCallData.SubInfo+xml 2937 Mandatory parameters: none 2939 Optional parameters: charset Indicates the character encoding of 2940 enclosed XML. 2942 Encoding considerations: Uses XML, which can employ 8-bit 2943 characters, depending on the character encoding used. See 2944 Section 3.2 of RFC 3023 [RFC3023]. 2946 Security considerations: This content type is designed to carry 2947 owner/subscriber information, which is a sub-category of 2948 additional data about an emergency call. Since this data contains 2949 personal information appropriate precautions have to be taken to 2950 limit unauthorized access, inappropriate disclosure to third 2951 parties, and eavesdropping of this information. Please refer to 2952 Section 7 and Section 8 for more information. 2954 Interoperability considerations: None 2956 Published specification: [TBD: This specification] 2958 Applications which use this media type: Emergency Services 2960 Additional information: Magic Number: None File Extension: .xml 2961 Macintosh file type code: 'TEXT' 2963 Person and email address for further information: Hannes 2964 Tschofenig, Hannes.Tschofenig@gmx.net 2966 Intended usage: LIMITED USE 2968 Author: This specification is a work item of the IETF ECRIT 2969 working group, with mailing list address . 2971 Change controller: The IESG 2973 9.4.5. MIME Content-type Registration for 'application/ 2974 emergencyCallData.Comment+xml' 2976 This specification requests the registration of a new MIME type 2977 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2978 RFC 3023 [RFC3023]. 2980 MIME media type name: application 2982 MIME subtype name: emergencyCallData.Comment+xml 2984 Mandatory parameters: none 2986 Optional parameters: charset Indicates the character encoding of 2987 enclosed XML. 2989 Encoding considerations: Uses XML, which can employ 8-bit 2990 characters, depending on the character encoding used. See 2991 Section 3.2 of RFC 3023 [RFC3023]. 2993 Security considerations: This content type is designed to carry a 2994 comment, which is a sub-category of additional data about an 2995 emergency call. This data may contain personal information. 2996 Appropriate precautions may have to be taken to limit unauthorized 2997 access, inappropriate disclosure to third parties, and 2998 eavesdropping of this information. Please refer to Section 7 and 2999 Section 8 for more information. 3001 Interoperability considerations: None 3003 Published specification: [TBD: This specification] 3005 Applications which use this media type: Emergency Services 3007 Additional information: Magic Number: None File Extension: .xml 3008 Macintosh file type code: 'TEXT' 3010 Person and email address for further information: Hannes 3011 Tschofenig, Hannes.Tschofenig@gmx.net 3013 Intended usage: LIMITED USE 3015 Author: This specification is a work item of the IETF ECRIT 3016 working group, with mailing list address . 3018 Change controller: The IESG 3020 9.5. URN Sub-Namespace Registration 3022 9.5.1. Registration for urn:ietf:params:xml:ns:emergencycalldata 3023 This section registers a new XML namespace, as per the guidelines in 3024 RFC 3688 [RFC3688]. 3026 URI: urn:ietf:params:xml:ns:emergencycalldata 3028 Registrant Contact: IETF, ECRIT working group, , as 3029 delegated by the IESG . 3031 XML: 3033 BEGIN 3034 3035 3037 3038 3039 3041 Namespace for Additional Emergency Call Data 3042 3043 3044

Namespace for Additional Data related to an Emergency Call

3045

See [TBD: This document].

3046 3047 3048 END 3050 9.5.2. Registration for 3051 urn:ietf:params:xml:ns:emergencycalldata:providerinfo 3053 This section registers a new XML namespace, as per the guidelines in 3054 RFC 3688 [RFC3688]. 3056 URI: urn:ietf:params:xml:ns:emergencycalldata:providerinfo 3058 Registrant Contact: IETF, ECRIT working group, , as 3059 delegated by the IESG . 3061 XML: 3063 BEGIN 3064 3065 3067 3068 3069 3071 Namespace for Additional Emergency Call Data: 3072 Data Provider Information 3073 3074 3075

Namespace for Additional Data related to an Emergency Call

3076

Data Provider Information

3077

See [TBD: This document].

3078 3079 3080 END 3082 9.5.3. Registration for 3083 urn:ietf:params:xml:ns:emergencycalldata:svcinfo 3085 This section registers a new XML namespace, as per the guidelines in 3086 RFC 3688 [RFC3688]. 3088 URI: urn:ietf:params:xml:ns:emergencycalldata:svcinfo 3090 Registrant Contact: IETF, ECRIT working group, , as 3091 delegated by the IESG . 3093 XML: 3095 BEGIN 3096 3097 3099 3100 3101 3103 Namespace for Additional Emergency Call Data: 3104 Service Information 3105 3106 3107

Namespace for Additional Data related to an Emergency Call

3108

Service Information

3109

See [TBD: This document].

3110 3111 3112 END 3114 9.5.4. Registration for 3115 urn:ietf:params:xml:ns:emergencycalldata:devinfo 3117 This section registers a new XML namespace, as per the guidelines in 3118 RFC 3688 [RFC3688]. 3120 URI: urn:ietf:params:xml:ns:emergencycalldata:devinfo 3122 Registrant Contact: IETF, ECRIT working group, , as 3123 delegated by the IESG . 3125 XML: 3127 BEGIN 3128 3129 3131 3132 3133 3135 Namespace for Additional Emergency Call Data: 3136 Device Information 3137 3138 3139

Namespace for Additional Data related to an Emergency Call

3140

Device Information

3141

See [TBD: This document].

3142 3143 3144 END 3146 9.5.5. Registration for 3147 urn:ietf:params:xml:ns:emergencycalldata:subinfo 3149 This section registers a new XML namespace, as per the guidelines in 3150 RFC 3688 [RFC3688]. 3152 URI: urn:ietf:params:xml:ns:emergencycalldata:subinfo 3154 Registrant Contact: IETF, ECRIT working group, , as 3155 delegated by the IESG . 3157 XML: 3159 BEGIN 3160 3161 3163 3164 3165 3167 Namespace for Additional Emergency Call Data: 3168 Owner/Subscriber Information 3169 3170 3171

Namespace for Additional Data related to an Emergency Call

3172

Owner/Subscriber Information

3173

See [TBD: This document].

3174 3175 3176 END 3178 9.5.6. Registration for 3179 urn:ietf:params:xml:ns:emergencycalldata:comment 3181 This section registers a new XML namespace, as per the guidelines in 3182 RFC 3688 [RFC3688]. 3184 URI: urn:ietf:params:xml:ns:emergencycalldata:comment 3186 Registrant Contact: IETF, ECRIT working group, , as 3187 delegated by the IESG . 3189 XML: 3191 BEGIN 3192 3193 3195 3196 3197 3199 Namespace for Additional Emergency Call Data:Comment 3200 3201 3202

Namespace for Additional Data related to an Emergency Call

3203

Comment

3204

See [TBD: This document].

3205 3206 3207 END 3209 9.6. Schema Registrations 3211 This specification registers five schemas, as per the guidelines in 3212 RFC 3688 [RFC3688]. 3214 URI: urn:ietf:params:xml:schema:emergencycalldata:providerinfo 3216 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3217 delegated by the IESG (iesg@ietf.org). 3219 XML: The XML schema can be found in Figure 15. 3221 URI: urn:ietf:params:xml:schema:emergencycalldata:svcinfo 3223 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 3224 delegated by the IESG (iesg@ietf.org). 3226 XML: The XML schema can be found in Figure 16. 3228 URI: urn:ietf:params:xml:schema:emergencycalldata:devinfo 3230 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3231 delegated by the IESG (iesg@ietf.org). 3233 XML: The XML schema can be found in Figure 17. 3235 URI: urn:ietf:params:xml:schema:emergencycalldata:subinfo 3237 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3238 delegated by the IESG (iesg@ietf.org). 3240 XML: The XML schema can be found in Section 6.4. 3242 URI: urn:ietf:params:xml:schema:emergencycalldata:comment 3244 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 3245 delegated by the IESG (iesg@ietf.org). 3247 XML: The XML schema can be found in Section 6.5. 3249 9.7. VCard Parameter Value Registration 3250 This document registers a new value in the vCARD Parameter Values 3251 registry as defined by [RFC6350] with the following template: 3253 Value: main 3255 Purpose: The main telephone number, typically of an enterprise, as 3256 opposed to a direct dial number of an individual employee 3258 Conformance: This value can be used with the "TYPE" parameter 3259 applied on the "TEL" property. 3261 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 3262 00 3264 10. Acknowledgments 3266 This work was originally started in NENA and has benefitted from a 3267 large number of participants in NENA standardization efforts, 3268 originally in the Long Term Definition Working Group, the Data 3269 Technical Committee and most recently the Additional Data working 3270 group. The authors are grateful for the initial work and extended 3271 comments provided by many NENA participants, including Delaine 3272 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 3273 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 3274 and Robert (Bob) Sherry. 3276 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 3277 Thomson, Keith Drage, Laura Liess, and Barbara Stark for their review 3278 comments. 3280 11. References 3282 11.1. Normative References 3284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3285 Requirement Levels", BCP 14, RFC 2119, March 1997. 3287 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3288 Locators", RFC 2392, August 1998. 3290 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 3291 Types", RFC 3023, January 2001. 3293 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 3294 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 3295 and QSIG Objects", RFC 3204, December 2001. 3297 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3298 A., Peterson, J., Sparks, R., Handley, M., and E. 3299 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3300 June 2002. 3302 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 3303 Extensions to the Session Initiation Protocol (SIP) for 3304 Asserted Identity within Trusted Networks", RFC 3325, 3305 November 2002. 3307 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 3308 Extensions (MIME) Parameter", RFC 3459, January 2003. 3310 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3311 January 2004. 3313 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3314 Format", RFC 4119, December 2005. 3316 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 3317 Registration Procedures", RFC 4288, December 2005. 3319 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3320 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3321 May 2008. 3323 [RFC5621] Camarillo, G., "Message Body Handling in the Session 3324 Initiation Protocol (SIP)", RFC 5621, September 2009. 3326 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3327 August 2011. 3329 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 3330 6351, August 2011. 3332 11.2. Informational References 3334 [I-D.gellens-negotiating-human-language] 3335 Randy, R., "Negotiating Human Language Using SDP", draft- 3336 gellens-negotiating-human-language-02 (work in progress), 3337 February 2013. 3339 [I-D.ietf-ecrit-psap-callback] 3340 Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 3341 Patel, "Public Safety Answering Point (PSAP) Callback", 3342 draft-ietf-ecrit-psap-callback-13 (work in progress), 3343 October 2013. 3345 [I-D.ietf-geopriv-relative-location] 3346 Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 3347 Thomson, "Relative Location Representation", draft-ietf- 3348 geopriv-relative-location-08 (work in progress), September 3349 2013. 3351 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3352 "Indicating User Agent Capabilities in the Session 3353 Initiation Protocol (SIP)", RFC 3840, August 2004. 3355 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 3356 Emergency Context Resolution with Internet Technologies", 3357 RFC 5012, January 2008. 3359 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 3360 Format for Presence Information Data Format Location 3361 Object (PIDF-LO)", RFC 5139, February 2008. 3363 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 3364 Tschofenig, "LoST: A Location-to-Service Translation 3365 Protocol", RFC 5222, August 2008. 3367 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3368 Presence Information Data Format Location Object (PIDF-LO) 3369 Usage Clarification, Considerations, and Recommendations", 3370 RFC 5491, March 2009. 3372 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 3373 Thomson, "Dynamic Extensions to the Presence Information 3374 Data Format Location Object (PIDF-LO)", RFC 5962, 3375 September 2010. 3377 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3378 5985, September 2010. 3380 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 3381 "Framework for Emergency Calling Using Internet 3382 Multimedia", RFC 6443, December 2011. 3384 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 3385 R. George, "Specifying Civic Address Extensions in the 3386 Presence Information Data Format Location Object (PIDF- 3387 LO)", RFC 6848, January 2013. 3389 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 3390 Communications Services in Support of Emergency Calling", 3391 BCP 181, RFC 6881, March 2013. 3393 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 3394 Morris, J., Hansen, M., and R. Smith, "Privacy 3395 Considerations for Internet Protocols", RFC 6973, July 3396 2013. 3398 Appendix A. XML Schema for vCard/xCard 3400 This section contains the vCard/xCard XML schema version of the Relax 3401 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 3402 XML schemas defined in this document. The schema in RFC 6351 3403 [RFC6351] is the normative source and this section is informative 3404 only. 3406 3407 3411 3417 3418 3419 vCard Format Specification 3420 3421 3422 3423 3424 3425 3426 3427 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3442 3443 3444 3446 3447 3448 3449 3450 3452 3453 3454 3456 3457 3458 3459 3460 3462 3463 3464 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3509 3510 3511 3512 3516 3517 3518 Section 5: Parameters 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 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 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 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 3904 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 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 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 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 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 4482 Hannes Tschofenig 4483 Nokia Solutions and Networks 4484 Linnoitustie 6 4485 Espoo 02600 4486 Finland 4488 Phone: +358 (50) 4871445 4489 Email: Hannes.Tschofenig@gmx.net 4490 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