idnits 2.17.00 (12 Aug 2021) /tmp/idnits37174/draft-ietf-ecrit-additional-data-09.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 16 instances of too long lines in the document, the longest one being 11 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 1893 has weird spacing: '...ll-Info pur...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 28, 2013) is 3279 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 1893, but not defined == Unused Reference: 'I-D.iab-privacy-considerations' is defined on line 2562, but no explicit reference was found in the text == Unused Reference: 'RFC5985' is defined on line 2576, but no explicit reference was found in the text == Unused Reference: 'RFC6443' is defined on line 2579, but no explicit reference was found in the text == Unused Reference: 'RFC6881' is defined on line 2583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B.R. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Tschofenig 5 Expires: November 29, 2013 Nokia Siemens Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 May 28, 2013 12 Additional Data related to an Emergency Call 13 draft-ietf-ecrit-additional-data-09.txt 15 Abstract 17 When an emergency call is sent to a Public Safety Answering Point 18 (PSAP), the device that sends it, as well as any application service 19 provider in the path of the call, or access network provider through 20 which the call originated may have information about the call or the 21 caller which the PSAP may be able to use. This document describes 22 data structures and a mechanism to convey such data to the PSAP. The 23 mechanism uses a Uniform Resource Identifier (URI), which may point 24 to either an external resource or an object in the body of the SIP 25 message. The mechanism thus allows the data to be passed by 26 reference (when the URI points to an external resource) or by value 27 (when it points into the body of the message). This follows the 28 tradition of prior emergency services standardization work where data 29 can be conveyed by value within the call signaling (i.e., in body of 30 the SIP message) and also by reference. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 29, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 70 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7 71 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 7 72 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 73 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 8 74 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9 75 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10 76 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10 77 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11 78 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12 79 3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12 80 3.2. Service Information . . . . . . . . . . . . . . . . . . . 14 81 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14 82 3.2.2. Service Delivered by Provider to End User . . . . . . 15 83 3.2.3. Service Mobility Environment . . . . . . . . . . . . 16 84 3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17 85 3.3. Device Information . . . . . . . . . . . . . . . . . . . 17 86 3.3.1. Device Classification . . . . . . . . . . . . . . . . 18 87 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19 88 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20 89 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20 90 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 21 91 3.3.6. Device/Service Specific Additional Data Structure . . 21 92 3.3.7. Device/Service Specific Additional Data Structure 93 Type . . . . . . . . . . . . . . . . . . . . . . . . 22 94 3.3.8. Choosing between defining a new type of block or new 95 type of device/service specific additional data . . . 23 96 3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 23 98 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24 99 3.4.1. xCard for Subscriber's Data . . . . . . . . . . . . . 24 100 3.4.2. emergencyCall.SubInfo Example . . . . . . . . . . . . 24 101 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27 103 3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27 104 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 4.1. Transmitting Blocks using the Call-Info Header . . . . . 29 106 4.2. Transmitting Blocks by Reference using the Provided-By 107 Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 4.3. Transmitting Blocks by Value using the Provided-By 109 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 33 112 6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 33 113 6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 34 114 6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 35 115 6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 36 116 6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 37 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 118 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 120 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 39 121 9.1.1. Additional Call Data Provider ID Series Registry . . 39 122 9.1.2. Additional Call Data Service Provider Type Registry . 40 123 9.1.3. Additional Call Data Service Delivered Registry . . . 40 124 9.1.4. Additional Call Data Device Classification Registry . 40 125 9.1.5. Additional Call Data Device ID Type Type Registry . . 41 126 9.1.6. Device/Service Specific Additional Data Type Registry 41 127 9.1.7. Additional Call Data Blocks Registry . . . . . . . . 42 128 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 42 129 9.3. URN Sub-Namespace Registration for provided-by Registry 130 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 43 131 9.3.1. Provided-By XML Schema . . . . . . . . . . . . . . . 43 132 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 44 133 9.4.1. MIME Content-type Registration for 134 'application/emergencyCall.ProviderInfo+xml' . . . . 45 135 9.4.2. MIME Content-type Registration for 136 'application/emergencyCall.SvcInfo+xml' . . . . . . . 46 137 9.4.3. MIME Content-type Registration for 138 'application/emergencyCall.DevInfo+xml' . . . . . . . 47 139 9.4.4. MIME Content-type Registration for 140 'application/emergencyCall.SubInfo+xml' . . . . . . . 48 141 9.4.5. MIME Content-type Registration for 142 'application/emergencyCall.Comment+xml' . . . . . . . 50 143 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 51 144 9.5.1. Registration for 145 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 51 147 9.5.2. Registration for 148 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 51 149 9.5.3. Registration for 150 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 52 151 9.5.4. Registration for 152 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 53 153 9.5.5. Registration for 154 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 54 155 9.5.6. Registration for 156 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 54 157 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 55 158 9.7. VCard Parameter Value Registration . . . . . . . . . . . 56 159 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 160 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 161 11.1. Normative References . . . . . . . . . . . . . . . . . . 57 162 11.2. Informational References . . . . . . . . . . . . . . . . 57 163 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 58 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 166 1. Introduction 168 When an IP-based emergency call is initiated a rich set of data from 169 multiple data sources is conveyed to the Public Safety Answering 170 Point (PSAP). This data includes information about the calling party 171 identity, the multimedia capabilities of the device, the emergency 172 service number, location information, and meta-data about the 173 sources. The device, the access network provider, and any service 174 provider in the call path may have even more information that may be 175 useful for a PSAP call taker. This document extends the basic set of 176 data communicated with an IP-based emergency call providing call 177 takers and the PSAP organization valuable insight and increased 178 situational awareness. 180 In general, there are three categories of data communicated in an 181 emergency call: 183 Data Associated with a Location: Location data is conveyed in the 184 Presence Information Data Format Location Object (PIDF-LO) data 185 structure originally defined in RFC 4119 [RFC4119]. There may be 186 data that is specific to the location not available in the 187 location data structure itself, such as floor plans, tenant and 188 building owner contact data, heating, ventilation and air 189 conditioning (HVAC) status, etc. 191 Data Associated with a Call: While information is carried in the 192 call setup procedure itself (as part of the SIP headers as well as 193 in the body of the SIP message), there is additional data known by 194 the device making the call, or a service provider in the path of 195 the call. This information may include the service provider 196 contact information, subscriber identity and contact information, 197 the type of service the service provider and access network 198 provider offer, what kind of device is being used, etc. Some data 199 is device or service dependent data. For example, a car 200 telematics system may have crash information. A medical 201 monitoring device may have sensor data. 203 Data Associated with a Caller: This is personal data about a caller, 204 such as medical information and emergency contact data. 206 This document only defines data structures relevant to data 207 associated with the call. Other forms of additional data may use 208 this mechanism to carry data, but those blocks are not defined in 209 this document. 211 For interoperability, there needs to be a common way for the 212 information conveyed to a PSAP to be encoded and identified. 213 Identification allows emergency services authorities to know during 214 call processing which types of data are present and to determine if 215 they wish to access it. A common encoding allows the data to be 216 accessed. This document defines the data structures and a way to 217 communicate the information in several ways. Although current 218 standization efforts around IP-based emergency services are focused 219 on the Session Initiation Protocol (SIP) and HTTP the data structures 220 in XML format described in this document are usable for other 221 communication systems as well. In Section 3 the data structures are 222 defined and the SIP/HTTP transport components are defined in 223 Section 4 to offer a clear separation between the two. 225 More technically, the data structure described in this document is 226 represented as one or more "blocks" of information. Each of the 227 blocks is an XML structure with an associated Multipurpose Internet 228 Mail Extensions (MIME) type for encapsulation, and an extensible set 229 of these types constitute the data set. A registry is defined to 230 list the block types that may be included. 232 2. Terminology 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in RFC 2119 [RFC2119]. 238 This document also uses terminology from [RFC5012]. We use the term 239 service provider to refer to an Application Service Provider (ASP) or 240 to Voice Service Provider (VSP), which is a specific type of ASP. 241 With the term "Access Network Provider" we refer to the Internet 242 Access Provider (IAP) and the Internet Service Provider (ISP) without 243 further distinguishing these two entities, since the difference 244 between the two is not relevant for this document. Note that the 245 roles of ASP and access network provider may be provided by a single 246 company. 248 In the data block definitions, see Section 3, the values for the 249 "Use:" label are specified as one of: 251 'Required': means they must be present in the data structure. 253 'Conditional': means they must be present unless the specified 254 condition is met, in which case the they may be present. 256 'Optional': means they may be present. 258 3. Data Structures 260 This section defines the following five data structures, each as a 261 data block. For each block we define the MIME type, and the XML data 262 structure 264 'Data Provider': This block supplies name and contact information 265 for the entity that created the data. Section 3.1 provides the 266 details. 268 'Service Information': This block supplies information about the 269 service. The description can be found in Section 3.2. 271 'Device Information': This block supplies information about the 272 device placing the call. Device information can be found in 273 Section 3.3. 275 'Owner/Subscriber': This block supplies information about the owner 276 of the device or about the subscriber. Details can be found in 277 Section 3.4. 279 'Comment': This block provides a way to supply free form human 280 readable text to the PSAP or emergency responders. This simple 281 structure is defined in Section 3.5. 283 Note that the xCard format is re-used in some of the data structures 284 to provide contact information. In a xCard there is no way to 285 specify a "main" telephone number. These numbers are useful to 286 emergency responders who are called to a large enterprise. This 287 document adds a new property value to the "tel" property of the TYPE 288 parameter called "main". It can be used in any xCard in additional 289 data. 291 3.1. Data Provider Information 293 This block is intended to be provided by any service provider in the 294 path of the call or the access network provider. It includes 295 identification and contact information. This block SHOULD be 296 provided by every service provider in the call path, and by the 297 access network provider. Devices MAY use this block to provide 298 identifying information. The MIME subtype is "application/ 299 emergencyCall.ProviderInfo+xml". 301 3.1.1. Data Provider String 303 Data Element: Data Provider String 305 Use: Required 307 XML Element: 309 Description: This is a plain language string suitable for displaying 310 the name of the service provider that created the additional data 311 structure. If the device created the structure the value is 312 identical to the contact header in the SIP INVITE. 314 Reason for Need: Inform the call taker of the identity of the entity 315 providing the additional call data structure. 317 How Used by Call Taker: Allows the call taker to interpret the data 318 in this structure. The source of the information often influences 319 how the information is used, believed or verified. 321 3.1.2. Data Provider ID 323 Data Element: Data Provider ID 325 Use: Conditional. Must be provided if the service provider is 326 located in a jurisdiction that maintains such ids. Devices are 327 not required to provide it. 329 XML Element: 330 Description: A jurisdiction specific code for the provider shown in 331 the element that created the structure of the 332 call. This data SHOULD be provided if the local jurisdiction 333 maintains such an ID list. For example, in North America, this 334 would be a "NENA Company ID". Devices SHOULD NOT use this 335 element. 337 Reason for Need: Inform the call taker of the identity of the entity 338 providing the additional call data structure. 340 How Used by Call Taker: Where jurisdictions have lists of providers 341 the Data Provider ID can be useful. 343 3.1.3. Data Provider ID Series 345 Data Element: Data Provider ID Series 347 Use: Conditional. If Data Provider ID is provided, Data Provider ID 348 Series is required. 350 XML Element: 352 Description: Identifies the issuer of the the ProviderId. A 353 registry will reflect the following valid entries: 355 * NENA 357 * EENA 359 Reason for Need: Identifies how to interpret the Data Provider ID. 361 How Used by Call Taker: Determines which provider ID registry to 362 consult for more information 364 3.1.4. Type of Data Provider 366 Data Element: Type of Data Provider ID 368 Use: Conditional. If Data Provider ID is provided, Type of Data 369 Provider ID is required. 371 XML Element: 373 Description: Identifies the type of data provider id being supplied 374 in the ProviderId data element. A registry with an initial set of 375 values is shown in the table below. 377 +------------------------------+------------------------------------+ 378 | Token | Description | 379 +------------------------------+------------------------------------+ 380 |Access Network Provider | Access network service provider | 381 |Service Provider | Calling or Origination telecom SP | 382 |Service Provider Subcontractor| A contractor to another kind of SP | 383 |Telematics Provider | A sensor based SP, especially | 384 | | vehicle based | 385 |Language Translation Provider | A spoken language translation SP | 386 |Expert Advice Provider | An SP giving expert advice | 387 |Emergency Modality Translation| An emergency call specific | 388 | | modality translation service | 389 | | e.g. for sign language | 390 |Relay Provider | A interpretation SP, for example, | 391 | | video relay for sign language | 392 | | interpreting | 393 |Other | Any other type of service provider | 394 +------------------------------+------------------------------------+ 396 Figure 1: Type of Data Provider ID Registry 398 Reason for Need: Identifies what kind of data provider this is. 400 How Used by Call Taker: To decide who to contact when further 401 information is needed 403 3.1.5. Data Provider Contact URI 405 Data Element: Data Provider Contact URI 407 Use: Required 409 XML Element: 411 Description: For a service provider the contact SHOULD be a contact 412 URI. This MUST be a SIP URI. If a telephone number is the 413 contact address it should be provided in the form of 414 sip:telephonenumber@serviceprovider:user=phone. If the call is 415 from a device, this would reflect the contact information of the 416 owner of the device. When provided by a service provider, this 417 would be a URI to a 24/7 support organization tasked to provide 418 PSAP support for this emergency call. 420 Reason for Need: Additional data providers may need to be contacted 421 for error or other unusual circumstances. 423 How Used by Call Taker: To contact the supplier of the additional 424 data for assistance in handling the call. 426 3.1.6. Data Provider Languages(s) Supported 428 Data Element: Data Provider Language(s) supported 430 Use: Conditional 432 XML Element: 434 Description: The language used by the entity at the Data Provider 435 Contact URI as an alpha 2-character code as defined in ISO 436 639-1:2002 Codes for the representation of names of languages -- 437 Part 1: Alpha-2 code Multiple instances of this element may occur. 438 Order is significant; preferred language should appear first. 439 This data is required if a Data Provider Contact URI is provided. 440 The content must reflect the languages supported at the contact 441 URI. 443 Reason for Need: Information needed to determine if emergency 444 service authority can communicate with the service provider or if 445 an interpreter will be needed. 447 How Used by Call Taker: If call taker cannot speak language(s) 448 supported by the service provider, a translation service will need 449 to be added to the conversation. 451 3.1.7. xCard of Data Provider 453 Data Element: xCard of Data Provider 454 Use: Optional 456 XML Element: 458 Description: There are many fields in the xCARD and the creator of 459 the data structure is encouraged to provide as much information as 460 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 461 minimum. N should contain name of support group or device owner 462 as appropriate. If more than one TEL property is provided, a 463 parameter from the vCard Property Value registry MUST be specified 464 on each TEL. For encoding of the xCard this specification uses 465 the XML-based encoding specified in [RFC6351]. 467 and is hereinafter referred to as "xCard" 469 Reason for Need: Information needed to determine additional contact 470 information. 472 How Used by Call Taker: Assists call taker by providing additional 473 contact information that may not be included in the SIP invite or 474 the PIDF-LO. 476 3.1.8. Subcontractor Principal 478 Data Element: Subcontractor Principal 480 XML Element: 482 Description: If the data provider is a subcontractor to another 483 provider such as an access infrastructure provider or telematics 484 provider, this element contains the DataProviderString of the 485 service provider to indicate which provider the subcontractor is 486 working for. This data is required if the Data Provider type is 487 subcontractor. 489 Reason for Need: Identify the entity the subcontractor works for. 491 How Used by Call Taker: Allows the call taker to understand what the 492 relationship between data providers and the service providers in 493 the path of the call are. 495 3.1.9. Subcontractor Priority 497 Data Element: Subcontractor Priority 499 Use: Required 501 XML Element: 503 Description: If the subcontractor should be contacted first, this 504 element should have a "sub" value. If the access or origination 505 service provider should be contacted first, this element should 506 have a "main" value. This data is required if the Data Provider 507 type is "subcontractor". 509 Reason for Need: Inform the call taker whether the network operator 510 or the subcontractor should be contacted first if support is 511 needed. 513 How Used by Call Taker: To decide which entity to contact first if 514 assistance is needed. 516 3.1.10. emergencyCall.ProviderInfo Example 518 519 522 Example VoIP Provider 523 524 ID123 525 NENA 526 Service Provider 527 sip:voip-provider@example.com 528 EN 529 531 532 Hannes Tschofenig 533 534 Hannes 535 Tschofenig 536 537 538 Dipl. Ing. 539 540 --0203 541 542 20090808T1430-0500 543 544 M 545 546 1 547 548 de 549 550 551 2 552 553 en 554 555 556 work 557 558 Example VoIP Provider 559 560 561 562 work 563 567 568 569 570 Linnoitustie 6 571 Espoo 572 Uusimaa 573 02600 574 Finland 575 576 577 578 579 work 580 voice 581 582 583 tel:+358 50 4871445 584 585 586 work 587 588 hannes.tschofenig@nsn.com 589 590 591 work 592 593 geo:60.210796,24.812924 594 595 596 home 597 598 599 http://www.tschofenig.priv.at/key.asc 600 601 602 Finland/Helsinki 603 604 home 605 606 http://www.tschofenig.priv.at 607 608 609 610 612 Figure 2: emergencyCall.ProviderInfo Example 614 3.2. Service Information 616 This block describes the service that the service provider provides 617 to the caller. It SHOULD be included by all SPs in the path of the 618 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 620 3.2.1. Service Environment 622 Data Element: Service Environment 624 Use: Required 626 XML Element: 628 Description: This element defines whether a call is from a business 629 or residence caller. Currently, the only valid entries are 630 'Business' or 'Residence'. 632 Reason for Need: To assist in determining equipment and manpower 633 requirements. 635 How Used by Call Taker: Information may be used to assist in 636 determining equipment and manpower requirements for emergency 637 responders. As the information is not always available, and the 638 registry is not all encompassing, this is at best advisory 639 information, but since it mimics a similar capability in some 640 current emergency calling systems, it is known to be valuable. 641 The service provider uses its best information (such as a rate 642 plan, facilities used to deliver service or service description) 643 to determine the information and is not responsible for 644 determining the actual characteristics of the location where the 645 call originates from. 647 3.2.2. Service Delivered by Provider to End User 649 Data Element: Service Delivered by Provider to End User 651 Use: Required 653 XML Element: 655 Description: This defines the type of service the end user has 656 subscribed to. The implied mobility of this service can not be 657 relied upon. A registry with a initial set of values is defined 658 in the table below. 660 +--------+----------------------------------------+ 661 | Name | Description | 662 +--------+----------------------------------------+ 663 | Wrless | Wireless Telephone Service: Includes | 664 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 665 | | LTE (Long Term Evolution) | 666 | Coin | Fixed Public Pay/Coin telephones: Any | 667 | | coin or credit card operated device | 668 | 1way | One way outbound service | 669 | Prison | Inmate call/service | 670 | Temp | Soft dialtone/quick service/warm | 671 | | disconnect/suspended | 672 | MLTS | Multi-line telephone system: Includes | 673 | | all PBX, Centrex, key systems, | 674 | | Shared Tenant Service | 675 | SenseU | Sensor, unattended: Includes devices | 676 | | that generate DATA ONLY. This is | 677 | | one-way information exchange and | 678 | | there will be no other form of | 679 | | communication | 680 | SenseA | Sensor, attended: Includes devices | 681 | | that are supported by a monitoring | 682 | | service provider or automatically | 683 | | open a two-way communication path | 684 | POTS | Wireline: Plain Old Telephone Service | 685 | VOIP | VoIP Telephone Service: A type of | 686 | | service that offers communication | 687 | | over internet protocol, such as Fixed| 688 | | Nomadic, Mobile, ... | 689 | Remote | Off premise extension | 690 | Relay | Relay Service: a type of service where | 691 | | there is a human 3rd party agent who | 692 | | provides some kind of additional | 693 | | assistance to the caller. Includes | 694 | | sign language relay and telematics | 695 | | services which provide a service | 696 | | assistant on the call. | 697 +--------+----------------------------------------+ 699 Figure 3: Service Delivered by Provider to End User Registry 701 More than one value MAY be returned. For example, a VoIP inmate 702 telephone service is a reasonable combination. 704 Reason for Need: Knowing the type of service may assist the PSAP 705 with the handling of the call. 707 How Used by Call Taker: Call takers often use this information to 708 determine what kinds of questions to ask callers, and how much to 709 rely on supportive information. An emergency call from a prison 710 is treated differently that a call from a sensor device. As the 711 information is not always available, and the registry is not all 712 encompassing, this is at best advisory information, but since it 713 mimics a similar capability in some current emergency calling 714 systems, it is known to be valuable. 716 3.2.3. Service Mobility Environment 718 Data Element: Service Mobility Environment 720 Use: Required 721 XML Element: 723 Description: This provides the service providers view of the 724 mobility of the caller. As the service provider may not know the 725 characteristics of the actual access network used, the value not 726 be relied upon. A registry will reflect the following initial 727 valid entries: 729 * Mobile: the device should be able to move at any time 731 * Fixed: the device is not expected to move unless the service is 732 relocated 734 * Nomadic: the device is not expected to change its point of 735 attachment while on a call 737 * Unknown: no information is known about the service mobility 738 environment for the device 740 Reason for Need: Knowing the service provider's belief of mobility 741 may assist the PSAP with the handling of the call. 743 How Used by Call Taker: To determine whether to assume the location 744 of the caller might change. 746 3.2.4. emergencyCall.SvcInfo Example 748 749 752 Business 753 MLTS 754 Fixed 755 757 Figure 4: emergencyCall.SvcInfo Example 759 3.3. Device Information 761 This block provides information about the device used to place the 762 call. It should be provided by any service provider that knows what 763 device is being used, and by the device itself. The mime subtype is 764 "application/emergencyCall.DevInfo+xml". 766 3.3.1. Device Classification 768 Data Element: Device Classification 770 Use: Optional 772 XML Element: 774 Description: This data element defines the kind of device making the 775 emergency call. If the device provides the data structure, the 776 device information SHOULD be provided. If the service provider 777 provides the structure and it knows what the device is, the 778 service provider SHOULD provide the device information. Often the 779 carrier does not know what the device is. It is possible to 780 receive two Additional Data Associated with a Call data 781 structures, one created by the device and one created by the 782 service provider. This information describes the device, not how 783 it is being used. This data element defines the kind of device 784 making the emergency call. The registry with the initial set of 785 values is shown below. 787 +--------+----------------------------------------+ 788 | Token | Description | 789 +--------+----------------------------------------+ 790 |Cordless| Cordless handset | 791 | Fixed | Fixed phone | 792 | Mobile | Mobile handset | 793 | ATA | analog terminal adapter | 794 |Satphone| Satellite phone | 795 | FSense | Stationary computing device (alarm | 796 | | system, data sensor) | 797 | Guard | Guardian devices | 798 | Desktop| Desktop PC | 799 | Laptop | Laptop computing device | 800 | Tablet | Tablet computing device | 801 | Alarm | Alarm system | 802 | MSense | Mobile Data sensor | 803 | Beacon | Personal beacons (spot) | 804 | Auto | Auto telematics | 805 | Truck | Truck telematics | 806 | Farm | Farm equipment telematics | 807 | Marine | Marine telematics | 808 | PDA | Personal digital assistant | 809 | PND | Personal navigation device) | 810 | SmrtPhn| Smart phone | 811 | Itab | Internet tablet | 812 | Game | Gaming console | 813 | Video | Video phone | 814 | Text | Other text device | 815 | NA | Not Available | 816 +--------+----------------------------------------+ 818 Figure 5: Device Classification Registry 820 Reason for Need: The device classification implies the capability of 821 the calling device and assists in identifying the meaning of the 822 emergency call location information that is being presented. For 823 example, does the device require human intervention to initiate a 824 call or is this call the result of programmed instructions? Does 825 the calling device have the ability to update location or 826 condition changes? Is this device interactive or a one-way 827 reporting device? 829 How Used by Call Taker: May assist with location of caller. For 830 example, a cordless handset may be outside or next door. May 831 provide calltaker some context about the caller, the capabilities 832 of the device used for the call or the environment the device is 833 being used in. 835 3.3.2. Device Manufacturer 837 Data Element: Device Manufacturer 839 Use: Optional 841 XML Element: 843 Description: The plain language name of the manufacturer of the 844 device. 846 Reason for Need: Used by PSAP management for post-mortem 847 investigation/resolution. 849 How Used by Call Taker: Probably not used by calltaker, but by PSAP 850 management. 852 3.3.3. Device Model Number 854 Data Element: Device Model Number 856 Use: Optional 858 XML Element: 860 Description: Model number of the device. 862 Reason for Need: Used by PSAP management for after action 863 investigation/resolution. 865 How Used by Call Taker: Probably not used by calltaker, but by PSAP 866 management. 868 3.3.4. Unique Device Identifier 870 Data Element: Unique Device Identifier 872 Use: Optional 874 XML Element: 876 Description: String that identifies the specific device making the 877 call or creating an event. 879 Reason for Need: Uniquely identifies the device as opposed to any 880 signaling identifiers encountered in the call signaling stream. 882 How Used by Call Taker: Probably not used by calltaker they would 883 need to refer to management for investigation. 885 3.3.5. Type of Device Identifier 887 Data Element: Type of Device Identifier 889 Use: Conditional: must be provided if DeviceID is provided 891 XML Element: 893 Description: Identifies the type of device identifier being 894 generated in the unique device identifier data element. A 895 registry with an initial set of values can be seen below: 897 +--------+----------------------------------------+ 898 | Token | Description | 899 +--------+----------------------------------------+ 900 | MEID | Mobile Equipment Identifier (CDMA) | 901 | ESN | Electronic Serial Number(GSM) | 902 | MAC | Media Access Control Address (IEEE) | 903 | WiMAX | Device Certificate Unique ID | 904 | IMEI | International Mobile Equipment ID (GSM)| 905 | UDI | Unique Device Identifier | 906 | RFID | Radio Frequency Identification | 907 | SN | Manufacturer Serial Number | 908 +--------+----------------------------------------+ 910 Figure 6: Registry with Device Identifier Types 912 Reason for Need: Identifies how to interpret the Unique Device 913 Identifier. 915 How Used by Call Taker: Additional information that may be used to 916 assist with call handling. 918 3.3.6. Device/Service Specific Additional Data Structure 920 Data Element: Device/service specific additional data structure 922 Use: Optional 924 XML Element: 925 Description: A URI representing additional data whose schema is 926 specific to the device or service which created it. An example is 927 the VEDs structure for a vehicle telematics device. The URI, when 928 dereferenced, MUST yield a data structure defined by the Device/ 929 service specific additional data type value. Different data may 930 be created by each classification; e.g., telematics creates VEDS 931 data set. 933 Reason for Need: Provides device/service specific data that may be 934 used by the call taker and/or responders. 936 How Used by Call Taker: Provide information to guide call takers to 937 select appropriate responders, give appropriate pre-arrival 938 instructions to callers, and advise responders of what to be 939 prepared for. May be used by responders to guide assistance 940 provided. 942 3.3.7. Device/Service Specific Additional Data Structure Type 944 Data Element: Type of Device/service specific additional data 945 structure 947 Use: Conditional. MUST be provided when Device/service specific 948 additional URI is provided 950 XML Element: 952 Description: Value from a registry defined by this document to 953 describe the type of data that can be retrieved from the Device/ 954 service specific additional data structure. Initial values are: 956 * IEEE 1512 - USDOT Model for traffic incidents 958 * VEDS 960 Reason for Need: This data element allows identification of 961 externally defined schemas, which may have additional data that 962 may assist in emergency response. 964 How Used by Call Taker: This data element allows the end user 965 (calltaker or first responder) to know what type of additional 966 data may be available to aid in providing the needed emergency 967 services. 969 Note: Information which is specific to a location or a caller 970 (person) should not be placed in this section. 972 3.3.8. Choosing between defining a new type of block or new type of 973 device/service specific additional data 975 For devices that have device or service specific data, there are two 976 choices to carry it. A new block can be defined, or the device/ 977 service specific additional data URL the the DevInfo block can be 978 used and a new type for it defined . The data passed would likely be 979 the same in both cases. Considerations for choosing which mechanism 980 to register under include: 982 Applicability: Information which will be carried by many kinds of 983 devices or services are more appropriately defined as separate 984 blocks. 986 Privacy: Information which may contain private data may be better 987 sent in the DevInfo block, rather than a new block so that 988 implementations are not tempted to send the data by value, and 989 thus having more exposure to the data than forcing the data to be 990 retrieved via the URL in DevInfo. 992 Size: Information which may be very may be better sent in the 993 DevInfo block, rather than a new block so that implementations are 994 not tempted to send the data by value. Conversely, data which is 995 small may best be sent in a separate block so that it can be sent 996 by value 998 Availability of a server: Providing the data via the device block 999 requires a server be made available to retrieve the data. 1000 Providing the data via new block allows it to be sent by value 1001 (CID). 1003 3.3.9. emergencyCall.DevInfo Example 1005 1006 1009 Fixed phone 1010 Nokia 1011 Lumia 800 1012 35788104 1013 IMEI 1014 1016 Figure 7: emergencyCallDevInfo Example 1018 3.4. Owner/Subscriber Information 1020 This block describes the owner of the device (if provided by the 1021 device) or the subscriber information, if provided by a service 1022 provider. The contact location is not necessarily the location of 1023 the caller or incident, but is rather the nominal contact address. 1024 The mime subtype is "application/emergencyCall.Subscriber+xml". 1026 3.4.1. xCard for Subscriber's Data 1028 Data Element: xCARD for Subscriber's Data 1030 Use: Conditional: Some services (e.g., prepaid phones, initialized 1031 phones, etc.) may not have this information. 1033 XML Element: 1035 Description: Information known by the service provider or device 1036 about the subscriber; e.g., Name, Address, Individual Telephone 1037 Number, Main Telephone Number and any other data. N, ORG (if 1038 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1039 than one TEL property is provided, a parameter from the vCard 1040 Property Value registry MUST be specified on each TEL. 1042 Reason for Need: When the caller is unable to provide information, 1043 this data may be used to obtain it 1045 How Used by Call Taker: Obtaining critical information about the 1046 caller and possibly the location when it is not able to be 1047 obtained otherwise. 1049 3.4.2. emergencyCall.SubInfo Example 1051 1052 1055 1056 1057 1058 Simon Perreault 1059 1060 Perreault 1061 Simon 1062 1063 1064 ing. jr 1065 M.Sc. 1066 1067 --0203 1068 1069 20090808T1430-0500 1070 1071 M 1072 1073 1 1074 1075 fr 1076 1077 1078 2 1079 1080 en 1081 1082 1083 work 1084 1085 Viagenie 1086 1087 1088 1089 work 1090 1094 1095 1096 1097 2875 boul. Laurier, suite D2-630 1098 Quebec 1099 QC 1100 G1V 2M2 1101 Canada 1103 1104 1105 1106 1107 work 1108 voice 1109 1110 1111 tel:+1-418-656-9254;ext=102 1112 1113 1114 1115 1116 work 1117 text 1118 voice 1119 cell 1120 video 1121 1122 1123 tel:+1-418-262-6501 1124 1125 1126 work 1127 1128 simon.perreault@viagenie.ca 1129 1130 1131 work 1132 1133 geo:46.766336,-71.28955 1134 1135 1136 work 1137 1138 1139 http://www.viagenie.ca/simon.perreault/simon.asc 1140 1141 1142 America/Montreal 1143 1144 home 1145 1146 http://nomis80.org 1147 1148 1149 1150 1152 1154 Figure 8: emergencyCall.SubInfo Example 1156 3.5. Comment 1158 This block provides a mechanism for the data provider to supply 1159 extra, human readable information to the PSAP. It is not intended 1160 for a general purpose extension mechanism. The mime subtype is 1161 "application/emergencyCall.Comment+xml" 1163 3.5.1. Comment 1165 Data Element: EmergencyCall.Comment 1167 Use: Optional 1169 XML Element: 1171 Description: Human readable text providing additional information to 1172 the PSAP staff. 1174 Reason for Need: Explanatory information for values in the data 1175 structure 1177 How Used by Call Taker: To interpret the data provided 1179 3.5.2. emergencyCall.Comment Example 1181 1182 1185 This is an example text. 1186 1188 Figure 9: EmergencyCall.Comment Example 1190 4. Transport 1192 This section defines how to convey additional data to an emergency 1193 service provider. Two different means are specified: the first uses 1194 the call signaling; the second uses the element of a 1195 PIDF-LO [RFC4119]. 1197 1. First, the ability to embed a Uniform Resource Identifier (URI) 1198 in an existing SIP header field, the Call-Info header, is 1199 defined. The URI points to the additional data structure. The 1200 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1201 document adds a new token with the value 'emergencyCallData' for 1202 the Call-Info "purpose" parameter. If the "purpose" parameter is 1203 set to 'emergencyCallData' then the Call-Info header contains 1204 either an HTTPS URL pointing to an external resource or a CID 1205 (content indirection) URI that allows the data structure to be 1206 placed in the body of the SIP message. The "purpose" parameter 1207 also contains an indication of what kind of data is available at 1208 the URI. 1210 As the data is conveyed using a URI in the SIP signaling, the 1211 data itself may reside on an external resource, or may be 1212 contained within the body of the SIP message. When the URI 1213 refers to data at an external resource, the data is said to be 1214 passed by reference. When the URI refers to data contained 1215 within the body of the SIP message, the data is said to be passed 1216 by value. A PSAP or emergency responder is able to examine the 1217 type of data provided and selectively inspect the data it is 1218 interested in, while forwarding all of it (the values or 1219 references) to downstream entities. 1221 To be conveyed in a SIP body additional data about a call is 1222 defined as a series of MIME objects, each with an XML data 1223 structure contained inside. As usual, whenever more than one 1224 MIME part is included in the body of a message, MIME-multipart 1225 (i.e., 'multipart/mixed') encloses them all. This document 1226 defines the XML schemas and MIME types used for each block. When 1227 additional data is passed by value in the SIP signaling, each CID 1228 URL points to one block in the body. Multiple URIs are used 1229 within a Call-Info header field (or multiple Call-Info header 1230 fields) to point to multiple blocks. When additional data is 1231 provided by reference (in SIP signaling or Provided-By), each 1232 HTTPS URL references one block; the data is retrieved with an 1233 HTTPS GET operation, which returns one of the blocks as an XML 1234 object. 1236 2. Second, the ability to embed additional data structures in the 1237 element of a PIDF-LO [RFC4119] is defined. Besides 1238 a service provider in the call path, the access network provider 1239 may also have similar information that may be valuable to the 1240 PSAP. The access network provider may provide location in the 1241 form of a PIDF-LO from a location server via a location 1242 configuration protocol. The data structures described in this 1243 document are not specific to the location itsef, but rather 1244 provides descriptive information having to do with the immediate 1245 circumstances about the provision of the location (who the access 1246 network is, how to contact that entity, what kind of service the 1247 access network provides, subscriber information, etc.). This 1248 data is similar in nearly every respect to the data known by 1249 service providers in the path of the call. When the access 1250 network provider and service provider are separate entities, the 1251 access network does not participate in the application layer 1252 signaling (and hence cannot add a Call-Info header field to the 1253 SIP message), but may provide location information to assist in 1254 locating the caller's device. The element of the 1255 PIDF-LO is a mechanism for the access network provider to supply 1256 the information about the entity or organization that supplied 1257 this location information. For this reason, this document 1258 describes a namespace per RFC 4119 for inclusion in the 1259 element of a PIDF-LO for adding information known 1260 to the access network provider. 1262 One or more blocks of data registered in the Emergency Call 1263 Additional Data registry, as defined in Section 9.1, may be included 1264 or referenced in the SIP signaling (using the Call-Info header field) 1265 or in the element of a PIDF-LO. Every block must be 1266 one of the types in the registry. Since the data of an emergency 1267 call may come from multiple sources, the data itself needs 1268 information describing the source. Consequently, each entity adding 1269 additional data MUST supply the "Data Provider" block. All other 1270 blocks are optional, but each entity SHOULD supply any blocks where 1271 it has at least some of the information in the block. 1273 4.1. Transmitting Blocks using the Call-Info Header 1275 A URI to a block MAY be inserted in a SIP request or response method 1276 (most often INVITE or MESSAGE) with a Call-Info header field 1277 containing a purpose of "emergencyCallData" together with the type of 1278 data available at the URI. The type of data is denoted by including 1279 the root of the MIME type (not including the emergencyCall prefix and 1280 the +xml suffix) with a "." separator. For example, when 1281 referencing a block with MIME type 'application/ 1282 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1283 'emergencyCallData.ProviderInfo'. An example "Call-Info" header 1284 field for this would be: 1286 Call-Info: https://www.example.com/23sedde3; 1287 purpose="emergencyCallData.ProviderInfo" 1289 The Call-info header with purpose='emergencyCallData' MUST only be 1290 sent on an emergency call, which can be ascertained by the presence 1291 of an emergency service urn in a Route header of a SIP message. 1293 If the data is provided by reference, an HTTPS URI MUST be included 1294 and consequently Transport Layer Security (TLS) protection is applied 1295 for protecting the retrieval of the information. 1297 The data may also be supplied by value in a SIP message. In this 1298 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1299 referencing the MIME body part. 1301 More than one Call-Info header with an emergencyCallData purpose can 1302 be expected, but at least one MUST be provided. The device MUST 1303 provide one if it knows no service provider is in the path of the 1304 call. The device MAY insert one if it uses a service provider. Any 1305 service provider in the path of the call MUST insert its own. For 1306 example, a device, a telematics service provider in the call path, as 1307 well as the mobile carrier handling the call will each provide one. 1308 There may be circumstances where there is a service provider who is 1309 unaware that the call is an emergency call and cannot reasonably be 1310 expected to determine that it is an emergency call. In that case, 1311 that service provider is not expected to provide emergencyCallData. 1313 4.2. Transmitting Blocks by Reference using the Provided-By Element 1315 The 'emergencyCallDataReference' element is used to transmit an 1316 additional data block by reference within a 'Provided-By' element of 1317 a PIDF-LO. The 'emergencyCallDataReference' element has two 1318 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1319 type of data block referenced. The value of 'ref' is an HTTPS URL 1320 that resolves to a data structure with information about the call. 1321 The value of 'purpose' is the same as used in a 'Call-Info' header 1322 field (as specified in Section 4.1). 1324 For example, to reference a block with MIME type 'application/ 1325 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1326 'emergencyCallData.ProviderInfo'. An example 1327 'emergencyCallDataReference' element for this would be: 1329 1332 4.3. Transmitting Blocks by Value using the Provided-By Element 1334 It is RECOMMENDED that access networks supply the data specified in 1335 this document by reference, but they MAY provide the data by value. 1337 The 'emergencyCallDataValue' element is used to transmit an 1338 additional data block by value within a 'Provided-By' element of a 1339 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1340 'purpose' to indicate the type of data block contained. The value of 1341 'purpose' is the same as used in a 'Call-Info' header field (as 1342 specified in Section 4.1, and in Section 4.1). The same XML 1343 structure as would be wrapped in the corresponding MIME type is 1344 placed inside the emergencyCallDataValue element. 1346 For example: 1348 1349 1350 Test 1351 NENA 1352 Access Infrastructure Provider 1353 1354 sip:15555550987@burf.example.com;user=phone 1355 1356 1357 1359 Example Provided-By by Value. 1361 5. Examples 1363 This section provides three examples of communicating additional 1364 data. In Figure 10 additional data is communicated in a SIP INVITE 1365 per value. In Figure 11 we illustrate how additional data is added 1366 by a SIP proxy per reference. Finally, an example of conveying 1367 additional data in the is illustrated. 1369 INVITE sips:bob@biloxi.example.com SIP/2.0 1370 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1371 Max-Forwards: 70 1372 To: Bob 1373 From: Alice ;tag=9fxced76sl 1374 Call-ID: 3848276298220188511@atlanta.example.com 1375 Call-Info: ;purpose=icon, 1376 ;purpose=info, 1377 1378 ;purpose=emergencyCallData.ProviderInfo 1379 Geolocation: 1380 Geolocation-Routing: no 1381 Accept: application/sdp, application/pidf+xml, 1382 application/emergencyCallProviderinfo+xml 1383 CSeq: 31862 INVITE 1384 Contact: 1385 Content-Type: multipart/mixed; boundary=boundary1 1387 Content-Length: ... 1389 --boundary1 1391 Content-Type: application/sdp 1393 ...SDP goes here 1395 --boundary1 1397 Content-Type: application/pidf+xml 1398 Content-ID: 1400 \0x2026PIDF-LO goes here 1402 --boundary1-- 1404 Content-Type: application/emergencyCall.ProviderInfo+xml 1405 Content-ID: <1234567890@atlanta.example.com> 1407 ...Additional Data goes here 1409 --boundary1-- 1411 Figure 10: Example: Attaching Additional Data via CID to a SIP 1412 INVITE. 1414 INVITE sips:bob@biloxi.example.com SIP/2.0 1415 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1416 Max-Forwards: 70 1417 To: Bob 1418 From: Alice ;tag=9fxced76sl 1419 Call-ID: 3848276298220188511@atlanta.example.com 1420 Call-Info: ;purpose=icon, 1421 ;purpose=info, 1422 1423 ;purpose=emergencyCallData.ProviderInfo 1424 Geolocation: 1425 Geolocation-Routing: no 1426 Accept: application/sdp, application/pidf+xml, 1427 application/emergencyCallProviderinfo+xml 1428 CSeq: 31862 INVITE 1429 Contact: 1430 Content-Type: multipart/mixed; boundary=boundary1 1432 Content-Length: ... 1434 --boundary1 1436 Content-Type: application/sdp 1438 ...SDP goes here 1440 --boundary1 1442 Content-Type: application/pidf+xml 1443 Content-ID: 1445 PIDF-LO goes here 1447 --boundary1-- 1449 Figure 11: Example: Attaching Additional Data per Reference in a SIP 1450 INVITE. 1452 TBD. 1454 Figure 12: Example: Attaching Additional Data to Provided-By Element. 1456 6. XML Schemas 1458 This section defines the XML schemas of the five data blocks. 1460 6.1. emergencyCall.ProviderInfo XML Schema 1462 1463 1472 1475 1476 1477 1478 1479 1481 1482 1483 1484 1486 1488 1490 1492 1494 1496 1500 1502 1503 1504 1505 1507 Figure 13: emergencyCall.ProviderInfo XML Schema 1509 6.2. emergencyCall.SvcInfo XML Schema 1511 1512 1520 1523 1524 1525 1526 1528 1530 1532 1534 1536 1537 1538 1539 1541 Figure 14: emergencyCall.SvcInfo XML Schema 1543 6.3. emergencyCall.DevInfo XML Schema 1545 1546 1554 1557 1558 1559 1560 1562 1564 1566 1568 1570 1572 1574 1576 1577 1578 1579 1581 Figure 15: emergencyCallDevInfo XML Schema 1583 6.4. emergencyCall.SubInfo XML Schema 1585 1586 1594 1597 1598 1599 1600 1604 1607 1608 1609 1610 1612 Figure 16: emergencyCall.SubInfo XML Schema 1614 6.5. emergencyCall.Comment XML Schema 1616 1617 1624 1627 1628 1629 1630 1632 1634 1635 1636 1638 1639 1640 1641 1642 1643 1644 1646 1648 Figure 17: EmergencyCall.Comment XML Schema 1650 7. Security Considerations 1651 The information in this data structure will usually be considered 1652 private. HTTPS is specified to require the provider of the 1653 information to validate the credentials of the requester. While the 1654 creation of a PKI that has global scope may be difficult, the 1655 alternatives to creating devices and services that can provide 1656 critical information securely are more daunting. The provider may 1657 enforce any policy it wishes to use, but PSAPs and responder agencies 1658 should deploy a PKI so that providers of additional data can check 1659 the certificate of the client and decide the appropriate policy to 1660 enforce based on that certificate. 1662 Ideally, the PSAP and emergency responders will be given credentials 1663 signed by an authority trusted by the data provider. In most 1664 circumstances, nationally recognized credentials would be sufficient, 1665 and if the emergency services arranges a PKI, data providers could be 1666 provisioned with the root CA public key for a given nation. Some 1667 nations are developing a PKI for this, and related, purposes. Since 1668 calls could be made from devices where the device and/or the service 1669 provider(s) are not local to the emergency authorities, globally 1670 recognized credentials are useful. This might be accomplished by 1671 extending the notion of the "forest guide" described in [RFC5222] to 1672 allow the forest guide to provide the credential of the PKI root for 1673 areas that it has coverage information for, but standards for such a 1674 mechanism are not yet available. In its absence, the data provider 1675 will need to obtain the root CA credentials for any areas it is 1676 willing to provide additional data by out of band means. With the 1677 credential of the root CA for a national emergency services PKI, the 1678 data provider server can validate the credentials of an entity 1679 requesting additional data by reference. 1681 The data provider also needs a credential that can be verified by the 1682 emergency services to know that it is receiving data from the right 1683 server. The emergency authorities could provide credentials, 1684 distinguishable from credentials it provides to emergency responders 1685 and PSAPs, which could be used to validate data providers. Such 1686 credentials would have to be acceptable to any PSAP or responder that 1687 could receive a call with additional data supplied by that provider. 1688 This would be extensible to global credential validation using the 1689 forest guide as above. In the absence of such credentials, the 1690 emergency authorities could maintain a list of local data providers' 1691 credentials provided to it out of band. At a minimum, the emergency 1692 authorities could obtain a credential from the DNS entry of the 1693 domain in the Addional Data URI to at least validate that the server 1694 is known to the domain providing the URI. 1696 Data provided by devices by reference have similar credential 1697 validation issues to service providers, and the solutions are the 1698 same. 1700 8. Privacy Considerations 1702 [Editor's Note: Text to be re-written.] 1704 In regions where callers can elect to suppress certain personally 1705 identifying information, the network or PSAP functionality can 1706 inspect privacy flags within the SIP headers to determine what 1707 information may be passed, stored, or displayed to comply with local 1708 policy or law. 1710 There is much private data in this information. Local regulations 1711 may govern what data must be provided in emergency calls, but in 1712 general, the emergency call system is often aided by the kinds of 1713 information described in this document. There is a tradeoff between 1714 the privacy considerations and the utility of the data. Certainly, 1715 if the data cannot be protected, due to failure to establish (by TLS) 1716 a secure connection to the data provider, data SHOULD NOT be sent 1717 unless specifically required by regulation. 1719 Some forms of data can be sent by value in the SIP signaling or by 1720 value (URL in SIP signaling). When data is sent by value, all 1721 intermediaries have access to the data. If the data is private, 1722 sending by reference is more appropriate. 1724 9. IANA Considerations 1726 9.1. Registry creation 1728 This document creates a new registry called 'Emergency Call 1729 Additional Data'. The following subregistries are created in 1730 Emergency Call Additional Data: 1732 9.1.1. Additional Call Data Provider ID Series Registry 1734 This document creates a new subregistry called 'Additional Call Data 1735 Provider ID Series'. As defined in [RFC5226], this registry operates 1736 under "Expert Review" rules. The expert should determine that the 1737 entity requesting a new value is a legitimate issuer of service 1738 provider IDs suitable for use in Additional Call Data. 1740 The content of this registry includes: 1742 Name: The identifier which will be used in the ProviderIDSeries 1743 element 1745 Source: The full name of the organization issuing the identifiers 1747 URL: A URL to the organization for further information 1748 The initial set of values is listed in the table below. 1750 +-----------+-----------+--------------+----------------------+ 1751 | Name | Source | URL | 1752 +-----------+--------------------------+----------------------+ 1753 | NENA | North American Emergency | http://www.nena.org | 1754 | | Number Association | | 1755 | EENA | European Emergency | http://www.eena.org | 1756 | | Number Association | | 1757 +-----------+--------------------------+----------------------+ 1759 9.1.2. Additional Call Data Service Provider Type Registry 1761 This document creates a new subregistry called 'Service Provider 1762 Type'. As defined in [RFC5226], this registry operates under "Expert 1763 Review". The expert should determine that the proposed new value is 1764 distinct from existing values and appropriate for use in the 1765 TypeOfServicerProvider element 1767 The content of this registry includes: 1769 Name: Value to be used in TypeOfServiceProvider. 1771 Description: A short description of the type of service provider 1773 The initial set of values is defined in Figure 1. 1775 9.1.3. Additional Call Data Service Delivered Registry 1777 This document creates a new registry called 'Additional Call Data 1778 Service Delivered'. As defined in [RFC5226], this registry operates 1779 under "Expert Review" rules. The expert should consider whether the 1780 proposed service is unique from existing services and the definition 1781 of the service will be clear to implementors and PSAPS/responders. 1783 The content of this registry includes: 1785 Name: enumeration token of the service. 1787 Description: Short description identifying the service. 1789 The initial set of values are defined in Figure 3. 1791 9.1.4. Additional Call Data Device Classification Registry 1793 This document creates a new registry called 'Additional Call Data 1794 Device Classification'. As defined in [RFC5226], this registry 1795 operates under "Expert Review" rules. The expert should consider 1796 whether the proposed class is unique from existing classes and the 1797 definition of the class will be clear to implementors and PSAPS/ 1798 responders. 1800 The content of this registry includes: 1802 Name: enumeration token of the device classification. 1804 Description: Short description identifying the device type. 1806 The initial set of values are defined in Figure 5. 1808 9.1.5. Additional Call Data Device ID Type Type Registry 1810 This document creates a new registry called 'Additional Call Data 1811 Device ID Type'. As defined in [RFC5226], this registry operates 1812 under "Expert Review" rules. The expert should ascertain that the 1813 proposed type is well understood, and provides the information useful 1814 to PSAPs and responders to uniquely identify a device. 1816 The content of this registry includes: 1818 Name: enumeration token of the device id type. 1820 Description: Short description identifying type of device id. 1822 The initial set of values are defined in Figure 6. 1824 9.1.6. Device/Service Specific Additional Data Type Registry 1826 This document creates a new registry called 'Device/Service Specific 1827 Additional Data Type Registry'. As defined in [RFC5226], this 1828 registry operates under "Expert Review" and "Specification Required" 1829 rules. The expert should ascertain that the proposed type is well 1830 understood, and provides information useful to PSAPs and responders. 1831 The specification must contain a complete description of the data, 1832 and a precise format specification suitable to allow interoperable 1833 implementations. 1835 The content of this registry includes: 1837 Name: enumeration token of the data type. 1839 Description: Short description identifying the the data. 1841 Specification: Citation for the specification of the data. 1843 The initial set of values are listed below: 1845 +---------+----------------------------------------+----------------+ 1846 | Token | Description | Specification | 1847 +---------+----------------------------------------+----------------+ 1848 | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | 1849 +---------+----------------------------------------+----------------+ 1850 | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | 1851 +---------+----------------------------------------+----------------+ 1853 9.1.7. Additional Call Data Blocks Registry 1855 This document creates a new subregistry called 'Additional Call Data 1856 Blocks' in the purpose registry established by RFC 261. As defined 1857 in [RFC5226], this registry operates under "Expert Review" and 1858 "Specification Required" rules. The expert is responsible for 1859 verifying that the document contains a complete and clear 1860 specification of the block and the block does not obviously duplicate 1861 existing blocks. 1863 The content of this registry includes: 1865 Name: Element Name of enclosing block. 1867 Reference: The document that describes the block 1869 This document defines the following set of values: 1871 +--------------+-----------+ 1872 | Token | Reference | 1873 +--------------+-----------+ 1874 | ProviderInfo | RFCXXXX | 1875 | SvcInfo | RFCXXXX | 1876 | DevInfo | RFCXXXX | 1877 | Subscriber | RFCXXXX | 1878 | Comment | RFCXXXX | 1879 +--------------+-----------+ 1880 RFC Editor Note: 1881 replace XXXX in the table above with this documents RFC number 1883 9.2. 'emergencyCallData' Purpose Parameter Value 1885 This document defines the 'emergencyCall' value for the "purpose" 1886 parameter of the Call-Info header field. The Call-Info header and 1887 the corresponding registry for the 'purpose' parameter was 1888 established with RFC 3261 [RFC3261]. 1890 Header Parameter New 1891 Field Name Value Reference 1892 ---------- --------- ----------------- --------- 1893 Call-Info purpose emergencyCall [This RFC] 1895 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 1897 This section registers the namespace specified in Section 9.5.1 in 1898 the provided-by registry established by RFC 4119, for usage within 1899 the 'provided-by' element of a PIDF-LO. 1901 9.3.1. Provided-By XML Schema 1903 1904 1916 1918 1919 1920 1921 1923 1925 1927 1929 1931 1934 1937 1938 1939 1941 1943 1944 1945 1946 1949 1952 1955 1958 1961 1963 1964 1965 1967 1970 1972 Figure 18: Provided-By XML Schema 1974 9.4. MIME Registrations 1975 9.4.1. MIME Content-type Registration for 'application/ 1976 emergencyCall.ProviderInfo+xml' 1978 This specification requests the registration of a new MIME type 1979 according to the procedures of RFC 4288 [RFC4288] and guidelines in 1980 RFC 3023 [RFC3023]. 1982 MIME media type name: application 1984 MIME subtype name: emergencyCall.ProviderInfo+xml 1986 Mandatory parameters: none 1988 Optional parameters: charset 1990 Indicates the character encoding of enclosed XML. 1992 Encoding considerations: 1994 Uses XML, which can employ 8-bit characters, depending on the 1995 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 1997 Security considerations: 1999 This content type is designed to carry the data provider 2000 information, which is a sub-category of additional data about an 2001 emergency call. 2003 Since this data contains personal information appropriate 2004 precautions have to be taken to limit unauthorized access, 2005 inappropriate disclosure to third parties, and eavesdropping of 2006 this information. Please refer to Section 7 and Section 8 for 2007 more information. 2009 Interoperability considerations: None 2011 Published specification: [TBD: This specification] 2013 Applications which use this media type: Emergency Services 2015 Additional information: 2017 Magic Number: None 2019 File Extension: .xml 2021 Macintosh file type code: 'TEXT' 2022 Person and email address for further information: Hannes 2023 Tschofenig, Hannes.Tschofenig@gmx.net 2025 Intended usage: LIMITED USE 2027 Author: This specification is a work item of the IETF ECRIT 2028 working group, with mailing list address . 2030 Change controller: The IESG 2032 9.4.2. MIME Content-type Registration for 'application/ 2033 emergencyCall.SvcInfo+xml' 2035 This specification requests the registration of a new MIME type 2036 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2037 RFC 3023 [RFC3023]. 2039 MIME media type name: application 2041 MIME subtype name: emergencyCall.SvcInfo+xml 2043 Mandatory parameters: none 2045 Optional parameters: charset 2047 Indicates the character encoding of enclosed XML. 2049 Encoding considerations: 2051 Uses XML, which can employ 8-bit characters, depending on the 2052 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 2054 Security considerations: 2056 This content type is designed to carry the service information, 2057 which is a sub-category of additional data about an emergency 2058 call. 2060 Since this data contains personal information appropriate 2061 precautions have to be taken to limit unauthorized access, 2062 inappropriate disclosure to third parties, and eavesdropping of 2063 this information. Please refer to Section 7 and Section 8 for 2064 more information. 2066 Interoperability considerations: None 2068 Published specification: [TBD: This specification] 2069 Applications which use this media type: Emergency Services 2071 Additional information: 2073 Magic Number: None 2075 File Extension: .xml 2077 Macintosh file type code: 'TEXT' 2079 Person and email address for further information: Hannes 2080 Tschofenig, Hannes.Tschofenig@gmx.net 2082 Intended usage: LIMITED USE 2084 Author: This specification is a work item of the IETF ECRIT 2085 working group, with mailing list address . 2087 Change controller: The IESG 2089 9.4.3. MIME Content-type Registration for 'application/ 2090 emergencyCall.DevInfo+xml' 2092 This specification requests the registration of a new MIME type 2093 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2094 RFC 3023 [RFC3023]. 2096 MIME media type name: application 2098 MIME subtype name: emergencyCall.DevInfo+xml 2100 Mandatory parameters: none 2102 Optional parameters: charset 2104 Indicates the character encoding of enclosed XML. 2106 Encoding considerations: 2108 Uses XML, which can employ 8-bit characters, depending on the 2109 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 2111 Security considerations: 2113 This content type is designed to carry the device information 2114 information, which is a sub-category of additional data about an 2115 emergency call. 2117 Since this data contains personal information appropriate 2118 precautions have to be taken to limit unauthorized access, 2119 inappropriate disclosure to third parties, and eavesdropping of 2120 this information. Please refer to Section 7 and Section 8 for 2121 more information. 2123 Interoperability considerations: None 2125 Published specification: [TBD: This specification] 2127 Applications which use this media type: Emergency Services 2129 Additional information: 2131 Magic Number: None 2133 File Extension: .xml 2135 Macintosh file type code: 'TEXT' 2137 Person and email address for further information: Hannes 2138 Tschofenig, Hannes.Tschofenig@gmx.net 2140 Intended usage: LIMITED USE 2142 Author: This specification is a work item of the IETF ECRIT 2143 working group, with mailing list address . 2145 Change controller: The IESG 2147 9.4.4. MIME Content-type Registration for 'application/ 2148 emergencyCall.SubInfo+xml' 2150 This specification requests the registration of a new MIME type 2151 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2152 RFC 3023 [RFC3023]. 2154 MIME media type name: application 2156 MIME subtype name: emergencyCall.SubInfo+xml 2158 Mandatory parameters: none 2160 Optional parameters: charset 2162 Indicates the character encoding of enclosed XML. 2164 Encoding considerations: 2166 Uses XML, which can employ 8-bit characters, depending on the 2167 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 2169 Security considerations: 2171 This content type is designed to carry owner/subscriber 2172 information, which is a sub-category of additional data about an 2173 emergency call. 2175 Since this data contains personal information appropriate 2176 precautions have to be taken to limit unauthorized access, 2177 inappropriate disclosure to third parties, and eavesdropping of 2178 this information. Please refer to Section 7 and Section 8 for 2179 more information. 2181 Interoperability considerations: None 2183 Published specification: [TBD: This specification] 2185 Applications which use this media type: Emergency Services 2187 Additional information: 2189 Magic Number: None 2191 File Extension: .xml 2193 Macintosh file type code: 'TEXT' 2195 Person and email address for further information: Hannes 2196 Tschofenig, Hannes.Tschofenig@gmx.net 2198 Intended usage: LIMITED USE 2200 Author: This specification is a work item of the IETF ECRIT 2201 working group, with mailing list address . 2203 Change controller: The IESG 2205 9.4.5. MIME Content-type Registration for 'application/ 2206 emergencyCall.Comment+xml' 2208 This specification requests the registration of a new MIME type 2209 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2210 RFC 3023 [RFC3023]. 2212 MIME media type name: application 2214 MIME subtype name: emergencyCall.Comment+xml 2216 Mandatory parameters: none 2218 Optional parameters: charset 2220 Indicates the character encoding of enclosed XML. 2222 Encoding considerations: 2224 Uses XML, which can employ 8-bit characters, depending on the 2225 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 2227 Security considerations: 2229 This content type is designed to carry a comment, which is a sub- 2230 category of additional data about an emergency call. 2232 This data may contain personal information. Appropriate 2233 precautions may have to be taken to limit unauthorized access, 2234 inappropriate disclosure to third parties, and eavesdropping of 2235 this information. Please refer to Section 7 and Section 8 for 2236 more information. 2238 Interoperability considerations: None 2240 Published specification: [TBD: This specification] 2242 Applications which use this media type: Emergency Services 2244 Additional information: 2246 Magic Number: None 2248 File Extension: .xml 2250 Macintosh file type code: 'TEXT' 2251 Person and email address for further information: Hannes 2252 Tschofenig, Hannes.Tschofenig@gmx.net 2254 Intended usage: LIMITED USE 2256 Author: This specification is a work item of the IETF ECRIT 2257 working group, with mailing list address . 2259 Change controller: The IESG 2261 9.5. URN Sub-Namespace Registration 2263 9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 2265 This section registers a new XML namespace, as per the guidelines in 2266 RFC 3688 [RFC3688]. 2268 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 2270 Registrant Contact: IETF, ECRIT working group, , as 2271 delegated by the IESG . 2273 XML: 2275 BEGIN 2276 2277 2279 2280 2281 2283 Namespace for Additional Emergency Call Data 2284 2285 2286

Namespace for Additional Data related to an Emergency Call

2287

See [TBD: This document].

2288 2289 2290 END 2292 9.5.2. Registration for 2293 urn:ietf:params:xml:ns:emergencyCallProviderInfo 2295 This section registers a new XML namespace, as per the guidelines in 2296 RFC 3688 [RFC3688]. 2298 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 2300 Registrant Contact: IETF, ECRIT working group, , as 2301 delegated by the IESG . 2303 XML: 2305 BEGIN 2306 2307 2309 2310 2311 2313 Namespace for Additional Emergency Call Data: 2314 Data Provider Information 2315 2316 2317

Namespace for Additional Data related to an Emergency Call

2318

Data Provider Information

2319

See [TBD: This document].

2320 2321 2322 END 2324 9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2326 This section registers a new XML namespace, as per the guidelines in 2327 RFC 3688 [RFC3688]. 2329 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2331 Registrant Contact: IETF, ECRIT working group, , as 2332 delegated by the IESG . 2334 XML: 2336 BEGIN 2337 2338 2340 2341 2342 2344 Namespace for Additional Emergency Call Data: 2345 Service Information 2346 2347 2348

Namespace for Additional Data related to an Emergency Call

2349

Service Information

2350

See [TBD: This document].

2351 2352 2353 END 2355 9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 2357 This section registers a new XML namespace, as per the guidelines in 2358 RFC 3688 [RFC3688]. 2360 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 2362 Registrant Contact: IETF, ECRIT working group, , as 2363 delegated by the IESG . 2365 XML: 2367 BEGIN 2368 2369 2371 2372 2373 2375 Namespace for Additional Emergency Call Data: 2376 Device Information 2377 2378 2379

Namespace for Additional Data related to an Emergency Call

2380

Device Information

2381

See [TBD: This document].

2382 2383 2384 END 2386 9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 2388 This section registers a new XML namespace, as per the guidelines in 2389 RFC 3688 [RFC3688]. 2391 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 2393 Registrant Contact: IETF, ECRIT working group, , as 2394 delegated by the IESG . 2396 XML: 2398 BEGIN 2399 2400 2402 2403 2404 2406 Namespace for Additional Emergency Call Data: 2407 Owner/Subscriber Information 2408 2409 2410

Namespace for Additional Data related to an Emergency Call

2411

Owner/Subscriber Information

2412

See [TBD: This document].

2413 2414 2415 END 2417 9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 2419 This section registers a new XML namespace, as per the guidelines in 2420 RFC 3688 [RFC3688]. 2422 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 2424 Registrant Contact: IETF, ECRIT working group, , as 2425 delegated by the IESG . 2427 XML: 2429 BEGIN 2430 2431 2433 2434 2435 2437 Namespace for Additional Emergency Call Data:Comment 2438 2439 2440

Namespace for Additional Data related to an Emergency Call

2441

Comment

2442

See [TBD: This document].

2443 2444 2445 END 2447 9.6. Schema Registrations 2449 This specification registers five schemas, as per the guidelines in 2450 RFC 3688 [RFC3688]. 2452 URI: urn:ietf:params:xml:schema:additional- 2453 data:emergencyCallProviderInfo 2455 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2456 delegated by the IESG (iesg@ietf.org). 2458 XML: The XML schema can be found in Figure 13. 2460 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2462 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2463 delegated by the IESG (iesg@ietf.org). 2465 XML: The XML schema can be found in Figure 14. 2467 URI: urn:ietf:params:xml:schema:additional- 2468 data:emergencyCallDevInfo 2470 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2471 delegated by the IESG (iesg@ietf.org). 2473 XML: The XML schema can be found in Figure 15. 2475 URI: urn:ietf:params:xml:schema:additional- 2476 data:emergencyCall.SubInfo 2478 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2479 delegated by the IESG (iesg@ietf.org). 2481 XML: The XML schema can be found in Section 6.4. 2483 URI: urn:ietf:params:xml:schema:additional- 2484 data:emergencyCall.Comment 2486 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2487 delegated by the IESG (iesg@ietf.org). 2489 XML: The XML schema can be found in Section 6.5. 2491 9.7. VCard Parameter Value Registration 2493 This document registers a new value in the vCARD Parameter Values 2494 registry as defined by [RFC6350] with the following template: 2496 Value: main 2498 Purpose: The main telephone number, typically of an enterprise, as 2499 opposed to a direct dial number of an individual employee 2501 Conformance: This value can be used with the "TYPE" parameter 2502 applied on the "TEL" property. 2504 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 2505 00 2507 10. Acknowledgments 2509 This work was originally started in NENA and has benefitted from a 2510 large number of participants in NENA standardization efforts, 2511 originally in the Long Term Definition Working Group, the Data 2512 Technical Committee and most recently the Additional Data working 2513 group. The authors are grateful for the initial work and extended 2514 comments provided by many NENA participants, including Delaine 2515 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 2516 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 2517 and Robert (Bob) Sherry. 2519 We would also like to thank James Winterbottom, Paul Kyzivat, Gunnar 2520 Hellstrom, Martin Thomson, Keith Drage, and Laura Liess for their 2521 review comments. 2523 11. References 2525 11.1. Normative References 2527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2528 Requirement Levels", BCP 14, RFC 2119, March 1997. 2530 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2531 Locators", RFC 2392, August 1998. 2533 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2534 Types", RFC 3023, January 2001. 2536 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2537 A., Peterson, J., Sparks, R., Handley, M., and E. 2538 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2539 June 2002. 2541 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2542 January 2004. 2544 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2545 Format", RFC 4119, December 2005. 2547 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2548 Registration Procedures", RFC 4288, December 2005. 2550 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2551 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2552 May 2008. 2554 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2555 August 2011. 2557 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2558 6351, August 2011. 2560 11.2. Informational References 2562 [I-D.iab-privacy-considerations] 2563 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2564 Morris, J., Hansen, M., and R. Smith, "Privacy 2565 Considerations for Internet Protocols", draft-iab-privacy- 2566 considerations-03 (work in progress), July 2012. 2568 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 2569 Emergency Context Resolution with Internet Technologies", 2570 RFC 5012, January 2008. 2572 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 2573 Tschofenig, "LoST: A Location-to-Service Translation 2574 Protocol", RFC 5222, August 2008. 2576 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 2577 5985, September 2010. 2579 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2580 "Framework for Emergency Calling Using Internet 2581 Multimedia", RFC 6443, December 2011. 2583 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 2584 Communications Services in Support of Emergency Calling", 2585 BCP 181, RFC 6881, March 2013. 2587 Appendix A. XML Schema for vCard/xCard 2589 This section contains the vCard/xCard XML schema version of the Relax 2590 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 2591 XML schemas defined in this document. The schema in RFC 6351 2592 [RFC6351] is the normative source and this section is informative 2593 only. 2595 2596 2600 2606 2607 2608 vCard Format Specification 2609 2610 2611 2612 2613 2614 2616 2617 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2632 2633 2634 2636 2637 2638 2639 2640 2642 2643 2644 2646 2647 2648 2649 2650 2652 2653 2654 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2699 2700 2701 2702 2706 2707 2708 Section 5: Parameters 2709 2710 2711 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3631 3632 3633 3634 3635 3636 3637 3639 3640 3641 3642 3643 3644 3645 3647 3648 3649 3651 3653 3654 3655 3657 3658 3659 3660 3662 Authors' Addresses 3664 Brian Rosen 3665 NeuStar 3666 470 Conrad Dr. 3667 Mars, PA 16046 3668 US 3670 Phone: +1 724 382 1051 3671 Email: br@brianrosen.net 3672 Hannes Tschofenig 3673 Nokia Siemens Networks 3674 Linnoitustie 6 3675 Espoo 02600 3676 Finland 3678 Phone: +358 (50) 4871445 3679 Email: Hannes.Tschofenig@gmx.net 3680 URI: http://www.tschofenig.priv.at 3682 Roger Marshall 3683 TeleCommunication Systems, Inc. 3684 2401 Elliott Avenue 3685 Seattle, WA 98121 3686 US 3688 Phone: +1 206 792 2424 3689 Email: rmarshall@telecomsys.com 3690 URI: http://www.telecomsys.com 3692 Randall Gellens 3693 Qualcomm Technologies, Inc. 3694 5775 Morehouse Drive 3695 San Diego, CA 92121 3696 US 3698 Email: rg+ietf@qti.qualcomm.com