idnits 2.17.00 (12 Aug 2021) /tmp/idnits3520/draft-ietf-ecrit-additional-data-14.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 27 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 1818 has weird spacing: '...element name=...' == Line 2287 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 (October 16, 2013) is 3138 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 2287, but not defined == Unused Reference: 'RFC5985' is defined on line 2879, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-geopriv-relative-location has been published as RFC 7035 Summary: 5 errors (**), 0 flaws (~~), 7 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: April 19, 2014 Nokia Solutions and Networks 6 R. Marshall 7 TeleCommunication Systems, Inc. 8 R. Gellens 9 Qualcomm Technologies, Inc. 10 J. Winterbottom 12 October 16, 2013 14 Additional Data related to an Emergency Call 15 draft-ietf-ecrit-additional-data-14.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 April 19, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 71 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7 72 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 73 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 74 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 75 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9 76 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10 77 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10 78 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11 79 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 11 80 3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12 81 3.2. Service Information . . . . . . . . . . . . . . . . . . . 14 82 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14 83 3.2.2. Service Delivered by Provider to End User . . . . . . 15 84 3.2.3. Service Mobility Environment . . . . . . . . . . . . 16 85 3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17 86 3.3. Device Information . . . . . . . . . . . . . . . . . . . 17 87 3.3.1. Device Classification . . . . . . . . . . . . . . . . 17 88 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19 89 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19 90 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 19 91 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 20 92 3.3.6. Device/Service Specific Additional Data Structure . . 20 93 3.3.7. Device/Service Specific Additional Data Structure 94 Type . . . . . . . . . . . . . . . . . . . . . . . . 21 95 3.3.8. Choosing between defining a new type of block or new 96 type of device/service specific additional data . . . 22 97 3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22 98 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 23 99 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 23 100 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 24 101 3.4.3. emergencyCall.SubInfo Example . . . . . . . . . . . . 24 102 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27 104 3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27 105 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 4.1. Transmitting Blocks using the Call-Info Header . . . . . 29 107 4.2. Transmitting Blocks by Reference using the Provided-By 108 Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 4.3. Transmitting Blocks by Value using the Provided-By 110 Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 31 112 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 36 114 6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 36 115 6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 37 116 6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 38 117 6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 39 118 6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 39 119 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 40 120 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 121 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 123 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 46 124 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 46 125 9.1.2. Service Provider Type Registry . . . . . . . . . . . 46 126 9.1.3. Service Delivered Registry . . . . . . . . . . . . . 47 127 9.1.4. Device Classification Registry . . . . . . . . . . . 47 128 9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 47 129 9.1.6. Device/Service Data Type Registry . . . . . . . . . . 48 130 9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48 131 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 49 132 9.3. URN Sub-Namespace Registration for provided-by Registry 133 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 49 134 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 49 135 9.4.1. MIME Content-type Registration for 136 'application/emergencyCall.ProviderInfo+xml' . . . . 49 137 9.4.2. MIME Content-type Registration for 138 'application/emergencyCall.SvcInfo+xml' . . . . . . . 50 139 9.4.3. MIME Content-type Registration for 140 'application/emergencyCall.DevInfo+xml' . . . . . . . 51 141 9.4.4. MIME Content-type Registration for 142 'application/emergencyCall.SubInfo+xml' . . . . . . . 52 143 9.4.5. MIME Content-type Registration for 144 'application/emergencyCall.Comment+xml' . . . . . . . 53 145 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 54 146 9.5.1. Registration for 147 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 54 148 9.5.2. Registration for 149 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 55 150 9.5.3. Registration for 151 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 56 152 9.5.4. Registration for 153 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 57 154 9.5.5. Registration for 155 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 57 156 9.5.6. Registration for 157 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 58 158 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 59 159 9.7. VCard Parameter Value Registration . . . . . . . . . . . 60 160 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 161 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 162 11.1. Normative References . . . . . . . . . . . . . . . . . . 60 163 11.2. Informational References . . . . . . . . . . . . . . . . 61 164 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 62 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 167 1. Introduction 169 When an IP-based emergency call is initiated a rich set of data from 170 multiple data sources is conveyed to the Public Safety Answering 171 Point (PSAP). This data includes information about the calling party 172 identity, the multimedia capabilities of the device, the emergency 173 service number, location information, and meta-data about the sources 174 of the data. The device, the access network provider, and any 175 service provider in the call path may have even more information 176 useful for a PSAP. This document extends the basic set of data 177 communicated with an IP-based emergency call, as described in 178 [RFC6443] and [RFC6881], in order to carry additional data which may 179 be useful to an entity or call taker handling the call. This data is 180 "additional" to the basic information found in the emergency call 181 signaling used. 183 In general, there are three categories of data communicated in an 184 emergency call: 186 Data Associated with a Location: Location data is conveyed in the 187 Presence Information Data Format Location Object (PIDF-LO) data 188 structure originally defined in RFC 4119 [RFC4119] and extended by 189 RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location 190 information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for 191 geodetic location information), and 193 [I-D.ietf-geopriv-relative-location] (for relative location). 194 There may be data that is specific to the location not available 195 in the location data structure itself, such as floor plans, tenant 196 and building owner contact data, heating, ventilation and air 197 conditioning (HVAC) status, etc. 199 Data Associated with a Call: While information is carried in the 200 call setup procedure itself (as part of the SIP headers as well as 201 in the body of the SIP message), there is additional data known by 202 the device making the call, and the service provider along the 203 path of the call. This information may include the service 204 provider contact information, subscriber identity and contact 205 information, the type of service the service provider and the 206 access network provider offer, what kind of device is being used, 207 etc. Some data is device or service dependent data. For example, 208 a car telematics system may have crash information. A medical 209 monitoring device may have sensor data. 211 Data Associated with a Caller: This is personal data about a caller, 212 such as medical information and emergency contact data. 214 This document only defines data structures relevant to data 215 associated with the call but defines extension points for other data 216 to be added via other specifications. 218 For interoperability, there needs to be a common way for the 219 information conveyed to a PSAP to be encoded and identified. 220 Identification allows emergency services authorities to know during 221 call processing which types of data are present and to determine if 222 they wish to access it. A common encoding allows the data to be 223 accessed. 225 This document defines the data structures and a way to communicate 226 the information in several ways. Although current standardization 227 efforts around IP-based emergency services are focused on the Session 228 Initiation Protocol (SIP) and HTTP the data structures in XML format 229 described in this document are usable for other communication systems 230 as well. In Section 3 the data structures are defined and the SIP/ 231 HTTP transport components are defined in Section 4 to offer a clear 232 separation between the two. 234 More technically, the data structure described in this document is 235 represented as one or more "blocks" of information. Each of the 236 blocks is an XML structure with an associated Multipurpose Internet 237 Mail Extensions (MIME) type for encapsulation, and an extensible set 238 of these types constitute the data set. A registry is defined to 239 list the block types that may be included. 241 2. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in RFC 2119 [RFC2119]. 247 This document also uses terminology from [RFC5012]. We use the term 248 service provider to refer to an Application Service Provider (ASP). 249 A Voice Service Provider (VSP) is a special type of ASP. With the 250 term "Access Network Provider" we refer to the Internet Access 251 Provider (IAP) and the Internet Service Provider (ISP) without 252 further distinguishing these two entities, since the difference 253 between the two is not relevant for this document. Note that the 254 roles of ASP and access network provider may be provided by a single 255 company. 257 In the data block definitions, see Section 3, the values for the 258 "Use:" label are specified as one of: 260 'Required': means they MUST be present in the data structure. 262 'Conditional': means they MUST be present if the specified 263 condition(s) is met. They MAY be present if the condition(s) is 264 not met. 266 'Optional': means they MAY be present. 268 vCard is a data format for representing and exchanging a variety of 269 information about individuals and other entities. For applications 270 that use XML the format defined in vCard is not immediately 271 applicable. For this purpose an XML-based encoding of the 272 information elements defined in the vCard specification has been 273 defined and the name of that specification is xCard. Since the term 274 vCard is more familiar to most readers we use the term xCard and 275 vCard interchangeable but it would be accurate to use the term vCard 276 only. 278 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 Note that the xCard format is re-used in some of the data structures 304 to provide contact information. In an xCard there is no way to 305 specify a "main" telephone number. These numbers are useful to 306 emergency responders who are called to a large enterprise. This 307 document adds a new property value to the "tel" property of the TYPE 308 parameter called "main". It can be used in any xCard in additional 309 data. 311 3.1. Data Provider Information 313 This block is intended to be provided by any service provider in the 314 path of the call or the access network provider. It includes 315 identification and contact information. This block SHOULD be 316 provided by every service provider in the call path, and by the 317 access network provider. Devices MAY use this block to provide 318 identifying information. The MIME subtype is "application/ 319 emergencyCall.ProviderInfo+xml". An access network provider SHOULD 320 provide this block either by value or by reference in the Provided-By 321 section of a PIDF-LO 323 3.1.1. Data Provider String 325 Data Element: Data Provider String 327 Use: Required 329 XML Element: 331 Description: This is a plain language string suitable for displaying 332 the name of the service provider that created the additional data 333 structure. If the device created the structure the value is 334 identical to the contact header in the SIP INVITE. 336 Reason for Need: Inform the call taker of the identity of the entity 337 providing the additional call data structure. 339 How Used by Call Taker: Allows the call taker to interpret the data 340 in this structure. The source of the information often influences 341 how the information is used, believed or verified. 343 3.1.2. Data Provider ID 345 Data Element: Data Provider ID 347 Use: Conditional. This data SHOULD be provided if the service 348 provider or access provider is located in a jurisdiction that 349 maintains such ids. For example, in North America, this would be 350 a "NENA Company ID". 352 XML Element: 354 Description: A jurisdiction specific code for the access provider or 355 service provider shown in the element that 356 created the structure of the call. NOTE: In the US, the NENA 357 Company ID must appear here. Additional information can be found 358 at http://www.nena.org/nena-company-id. The NENA Company ID MUST 359 be in the form of a URI in the following format: 360 urn:nena:companyid: 362 Reason for Need: Inform the call taker of the identity of the entity 363 providing the additional call data structure. 365 How Used by Call Taker: Where jurisdictions have lists of providers 366 the Data Provider ID provides useful information about the data 367 source. 369 3.1.3. Data Provider ID Series 371 Data Element: Data Provider ID Series 373 Use: Conditional. If Data Provider ID is provided, Data Provider ID 374 Series is required. 376 XML Element: 378 Description: Identifies the issuer of the ProviderId. A registry 379 will reflect the following valid entries: 381 * NENA 383 * EENA 385 Reason for Need: Identifies how to interpret the Data Provider ID. 387 How Used by Call Taker: Determines which provider ID registry to 388 consult for more information 390 3.1.4. Type of Data Provider 392 Data Element: Type of Data Provider ID 394 Use: Conditional. If Data Provider ID is provided, Type of Data 395 Provider ID is required. 397 XML Element: 399 Description: Identifies the type of data provider id being supplied 400 in the ProviderId data element. A registry with an initial set of 401 values is shown in Figure 1. 403 +------------------------------+------------------------------------+ 404 | Token | Description | 405 +------------------------------+------------------------------------+ 406 |Access Network Provider | Access network service provider | 407 |Service Provider | Calling or Origination telecom SP | 408 |Service Provider Subcontractor| A contractor to another kind of SP | 409 |Telematics Provider | A sensor based SP, especially | 410 | | vehicle based | 411 |Language Translation Provider | A spoken language translation SP | 412 |Emergency Service Provider | An emergency service provider | 413 | | conveying information to another | 414 | | emergency service provider. | 415 |Emergency Modality Translation| An emergency call specific | 416 | | modality translation service | 417 | | e.g., for sign language | 418 |Relay Provider | A interpretation SP, for example, | 419 | | video relay for sign language | 420 | | interpreting | 421 |Other | Any other type of service provider | 422 +------------------------------+------------------------------------+ 424 Figure 1: Type of Data Provider ID Registry. 426 Reason for Need: Identifies what kind of data provider this is. 428 How Used by Call Taker: To decide who to contact when further 429 information is needed 431 3.1.5. Data Provider Contact URI 432 Data Element: Data Provider Contact URI 434 Use: Required 436 XML Element: 438 Description: When provided by a service provider or an access 439 provider, this information MUST be a URI to a 24/7 support 440 organization tasked to provide PSAP support for this emergency 441 call. If the call is from a device, this would reflect the 442 contact information of the owner of the device. If a telephone 443 number is the contact address then it MUST be tel URI. If it is 444 provided as a SIP URI then it MUST be in the form of 445 sip:telephonenumber@serviceprovider:user=phone. 447 Reason for Need: Additional data providers may need to be contacted 448 for error or other unusual circumstances. 450 How Used by Call Taker: To contact the supplier of the additional 451 data for assistance in handling the call. 453 3.1.6. Data Provider Languages(s) Supported 455 Data Element: Data Provider Language(s) supported 457 Use: Required. 459 XML Element: 461 Description: The language used by the entity at the Data Provider 462 Contact URI as an alpha 2-character code as defined in ISO 463 639-1:2002 Codes for the representation of names of languages -- 464 Part 1: Alpha-2 code Multiple instances of this element may occur. 465 Order is significant; preferred language should appear first. The 466 content MUST reflect the languages supported at the contact URI. 468 Reason for Need: Information needed to determine if emergency 469 service authority can communicate with the service provider or if 470 an interpreter will be needed. 472 How Used by Call Taker: If call taker cannot speak language(s) 473 supported by the service provider, a translation service will need 474 to be added to the conversation. Alternatively, other persons at 475 the PSAP, besides the call taker, might be consulted for help 476 (depending on the urgency and the type of interaction). 478 3.1.7. xCard of Data Provider 479 Data Element: xCard of Data Provider 481 Use: Optional 483 XML Element: 485 Description: There are many fields in the xCard and the creator of 486 the data structure is encouraged to provide as much information as 487 they have available. N, ORG, ADR, TEL, EMAIL are suggested at a 488 minimum. N should contain name of support group or device owner 489 as appropriate. If more than one TEL property is provided, a 490 parameter from the vCard Property Value registry MUST be specified 491 on each TEL. For encoding of the xCard this specification uses 492 the XML-based encoding specified in [RFC6351]. and is hereinafter 493 referred to as "xCard" 495 Reason for Need: Information needed to determine additional contact 496 information. 498 How Used by Call Taker: Assists call taker by providing additional 499 contact information that may not be included in the SIP invite or 500 the PIDF-LO. 502 3.1.8. Subcontractor Principal 504 Data Element: Subcontractor Principal 506 Use: Conditional. This data is required if the Data Provider type 507 is subcontractor. 509 XML Element: 511 Description: If the data provider is a subcontractor to another 512 provider, such as an access infrastructure provider or telematics 513 provider, this element contains the DataProviderString of the 514 service provider to indicate which provider the subcontractor is 515 working for. 517 Reason for Need: Identify the entity the subcontractor works for. 519 How Used by Call Taker: Allows the call taker to understand what the 520 relationship between data providers and the service providers in 521 the path of the call are. 523 3.1.9. Subcontractor Priority 525 Data Element: Subcontractor Priority 526 Use: Conditional. This data is required if the Data Provider type 527 is "subcontractor". 529 XML Element: 531 Description: If the subcontractor has to be contacted first then 532 this element MUST have the value "sub". If the access or service 533 provider has to be contacted first then this element MUST have the 534 value "main". 536 Reason for Need: Inform the call taker whom to contact first, if 537 support is needed. 539 How Used by Call Taker: To decide which entity to contact first if 540 assistance is needed. 542 3.1.10. emergencyCall.ProviderInfo Example 544 545 548 Example VoIP Provider 549 550 urn:nena:companyid:ID123 551 NENA 552 Service Provider 553 sip:voip-provider@example.com 554 EN 555 557 558 Hannes Tschofenig 559 560 Hannes 561 Tschofenig 562 563 564 Dipl. Ing. 565 566 --0203 567 568 20090808T1430-0500 569 570 M 571 572 1 573 574 de 575 576 577 2 578 579 en 580 581 582 work 583 584 Example VoIP Provider 585 586 587 588 work 589 593 594 595 596 Linnoitustie 6 597 Espoo 598 Uusimaa 599 02600 600 Finland 601 602 603 604 605 work 606 voice 607 608 609 tel:+358 50 4871445 610 611 612 work 613 614 hannes.tschofenig@nsn.com 615 616 617 work 618 619 geo:60.210796,24.812924 620 621 622 home 623 624 625 http://www.tschofenig.priv.at/key.asc 626 627 628 Finland/Helsinki 629 630 home 631 632 http://www.tschofenig.priv.at 633 634 635 636 638 Figure 2: emergencyCall.ProviderInfo Example. 640 3.2. Service Information 642 This block describes the service that the service provider provides 643 to the caller. It SHOULD be included by all SPs in the path of the 644 call. The mime subtype is "application/emergencyCall.SvcInfo+xml". 646 3.2.1. Service Environment 648 Data Element: Service Environment 650 Use: Required 652 XML Element: 654 Description: This element defines whether a call is from a business 655 or residence caller. Currently, the only valid entries are 656 'Business' or 'Residence'. 658 Reason for Need: To assist in determining equipment and manpower 659 requirements. 661 How Used by Call Taker: Information may be used to assist in 662 determining equipment and manpower requirements for emergency 663 responders. As the information is not always available, and the 664 registry is not all encompassing, this is at best advisory 665 information, but since it mimics a similar capability in some 666 current emergency calling systems, it is known to be valuable. 667 The service provider uses its best information (such as a rate 668 plan, facilities used to deliver service or service description) 669 to determine the information and is not responsible for 670 determining the actual characteristics of the location where the 671 call originates from. 673 3.2.2. Service Delivered by Provider to End User 675 Data Element: Service Delivered by Provider to End User 677 Use: Required 679 XML Element: 681 Description: This defines the type of service the end user has 682 subscribed to. The implied mobility of this service cannot be 683 relied upon. A registry with an initial set of values is defined 684 in Figure 3. 686 +--------+----------------------------------------+ 687 | Name | Description | 688 +--------+----------------------------------------+ 689 | Wrless | Wireless Telephone Service: Includes | 690 | | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | 691 | | LTE (Long Term Evolution) | 692 | Coin | Fixed Public Pay/Coin telephones: Any | 693 | | coin or credit card operated device | 694 | 1way | One way outbound service | 695 | Prison | Inmate call/service | 696 | Temp | Soft dialtone/quick service/warm | 697 | | disconnect/suspended | 698 | MLTS | Multi-line telephone system: Includes | 699 | | all PBX, Centrex, key systems, | 700 | | Shared Tenant Service | 701 | SenseU | Sensor, unattended: Includes devices | 702 | | that generate DATA ONLY. This is | 703 | | one-way information exchange and | 704 | | there will be no other form of | 705 | | communication | 706 | SenseA | Sensor, attended: Includes devices | 707 | | that are supported by a monitoring | 708 | | service provider or automatically | 709 | | open a two-way communication path | 710 | POTS | Wireline: Plain Old Telephone Service | 711 | VOIP | VoIP Telephone Service: A type of | 712 | | service that offers communication | 713 | | over internet protocol, such as Fixed| 714 | | Nomadic, Mobile, ... | 715 | Remote | Off premise extension | 716 | Relay | Relay Service: a type of service where | 717 | | there is a human 3rd party agent who | 718 | | provides some kind of additional | 719 | | assistance to the caller. Includes | 720 | | sign language relay and telematics | 721 | | services which provide a service | 722 | | assistant on the call. | 723 +--------+----------------------------------------+ 725 Figure 3: Service Delivered by Provider to End User Registry. 727 More than one value MAY be returned. For example, a VoIP inmate 728 telephone service is a reasonable combination. 730 Reason for Need: Knowing the type of service may assist the PSAP 731 with the handling of the call. 733 How Used by Call Taker: Call takers often use this information to 734 determine what kinds of questions to ask callers, and how much to 735 rely on supportive information. An emergency call from a prison 736 is treated differently that a call from a sensor device. As the 737 information is not always available, and the registry is not all 738 encompassing, this is at best advisory information, but since it 739 mimics a similar capability in some current emergency calling 740 systems, it is known to be valuable. 742 3.2.3. Service Mobility Environment 744 Data Element: Service Mobility Environment 746 Use: Required 748 XML Element: 750 Description: This provides the service providers view of the 751 mobility of the caller. As the service provider may not know the 752 characteristics of the actual access network used, the value not 753 be relied upon. A registry will reflect the following initial 754 valid entries: 756 * Mobile: the device should be able to move at any time 758 * Fixed: the device is not expected to move unless the service is 759 relocated 761 * Nomadic: the device is not expected to change its point of 762 attachment while on a call 764 * Unknown: no information is known about the service mobility 765 environment for the device 767 Reason for Need: Knowing the service provider's belief of mobility 768 may assist the PSAP with the handling of the call. 770 How Used by Call Taker: To determine whether to assume the location 771 of the caller might change. 773 3.2.4. emergencyCall.SvcInfo Example 775 776 779 Business 780 MLTS 781 Fixed 782 784 Figure 4: emergencyCall.SvcInfo Example. 786 3.3. Device Information 788 This block provides information about the device used to place the 789 call. It should be provided by any service provider that knows what 790 device is being used, and by the device itself. The mime subtype is 791 "application/emergencyCall.DevInfo+xml". 793 3.3.1. Device Classification 795 Data Element: Device Classification 797 Use: Optional 799 XML Element: 801 Description: This data element defines the kind of device making the 802 emergency call. If the device provides the data structure, the 803 device information SHOULD be provided. If the service provider 804 provides the structure and it knows what the device is, the 805 service provider SHOULD provide the device information. Often the 806 carrier does not know what the device is. It is possible to 807 receive two Additional Data Associated with a Call data 808 structures, one created by the device and one created by the 809 service provider. This information describes the device, not how 810 it is being used. This data element defines the kind of device 811 making the emergency call. The registry with the initial set of 812 values is shown in Figure 5. 814 +--------+----------------------------------------+ 815 | Token | Description | 816 +--------+----------------------------------------+ 817 |Cordless| Cordless handset | 818 | Fixed | Fixed phone | 819 | Mobile | Mobile handset | 820 | ATA | analog terminal adapter | 821 |Satphone| Satellite phone | 822 | FSense | Stationary computing device (alarm | 823 | | system, data sensor) | 824 | Guard | Guardian devices | 825 | Desktop| Desktop PC | 826 | Laptop | Laptop computing device | 827 | Tablet | Tablet computing device | 828 | Alarm | Alarm system | 829 | MSense | Mobile Data sensor | 830 | Beacon | Personal beacons (spot) | 831 | Auto | Auto telematics | 832 | Truck | Truck telematics | 833 | Farm | Farm equipment telematics | 834 | Marine | Marine telematics | 835 | PDA | Personal digital assistant | 836 | PND | Personal navigation device) | 837 | SmrtPhn| Smart phone | 838 | Itab | Internet tablet | 839 | Game | Gaming console | 840 | Video | Video phone | 841 | Text | Other text device | 842 |SoftPhn | Soft phone or soft client software | 843 | NA | Not Available | 844 +--------+----------------------------------------+ 846 Figure 5: Device Classification Registry. 848 Reason for Need: The device classification implies the capability of 849 the calling device and assists in identifying the meaning of the 850 emergency call location information that is being presented. For 851 example, does the device require human intervention to initiate a 852 call or is this call the result of programmed instructions? Does 853 the calling device have the ability to update location or 854 condition changes? Is this device interactive or a one-way 855 reporting device? 857 How Used by Call Taker: May assist with location of caller. For 858 example, a cordless handset may be outside or next door. May 859 provide the calltaker some context about the caller, the 860 capabilities of the device used for the call or the environment 861 the device is being used in. 863 3.3.2. Device Manufacturer 865 Data Element: Device Manufacturer 867 Use: Optional 869 XML Element: 871 Description: The plain language name of the manufacturer of the 872 device. 874 Reason for Need: Used by PSAP management for post-mortem 875 investigation/resolution. 877 How Used by Call Taker: Probably not used by the calltaker, but by 878 PSAP management. 880 3.3.3. Device Model Number 882 Data Element: Device Model Number 884 Use: Optional 886 XML Element: 888 Description: Model number of the device. 890 Reason for Need: Used by PSAP management for after action 891 investigation/resolution. 893 How Used by Call Taker: Probably not used by the calltaker, but by 894 PSAP management. 896 3.3.4. Unique Device Identifier 898 Data Element: Unique Device Identifier 900 Use: Optional 902 XML Element: 904 Description: String that identifies the specific device making the 905 call or creating an event. 907 Reason for Need: Uniquely identifies the device as opposed to any 908 signaling identifiers encountered in the call signaling stream. 910 How Used by Call Taker: Probably not used by the calltaker; they 911 would need to refer to management for investigation. 913 3.3.5. Type of Device Identifier 915 Data Element: Type of Device Identifier 917 Use: Conditional: must be provided if the DeviceID is provided 919 XML Element: 921 Description: Identifies the type of device identifier being 922 generated in the unique device identifier data element. A 923 registry with an initial set of values can be seen in Figure 6. 925 +--------+----------------------------------------+ 926 | Token | Description | 927 +--------+----------------------------------------+ 928 | MEID | Mobile Equipment Identifier (CDMA) | 929 | ESN | Electronic Serial Number(GSM) | 930 | MAC | Media Access Control Address (IEEE) | 931 | WiMAX | Device Certificate Unique ID | 932 | IMEI | International Mobile Equipment ID (GSM)| 933 | UDI | Unique Device Identifier | 934 | RFID | Radio Frequency Identification | 935 | SN | Manufacturer Serial Number | 936 +--------+----------------------------------------+ 938 Figure 6: Registry with Device Identifier Types. 940 Reason for Need: Identifies how to interpret the Unique Device 941 Identifier. 943 How Used by Call Taker: Additional information that may be used to 944 assist with call handling. 946 3.3.6. Device/Service Specific Additional Data Structure 948 Data Element: Device/service specific additional data structure 950 Use: Optional 952 XML Element: 953 Description: A URI representing additional data whose schema is 954 specific to the device or service which created it. An example is 955 the Vehicular Emergency Data Set (VEDS) structure for a vehicle 956 telematics device. The URI, when dereferenced, MUST yield a data 957 structure defined by the Device/service specific additional data 958 type value. Different data may be created by each classification; 959 e.g., a telematics created VEDS data set. 961 Reason for Need: Provides device/service specific data that may be 962 used by the call taker and/or responders. 964 How Used by Call Taker: Provide information to guide call takers to 965 select appropriate responders, give appropriate pre-arrival 966 instructions to callers, and advise responders of what to be 967 prepared for. May be used by responders to guide assistance 968 provided. 970 3.3.7. Device/Service Specific Additional Data Structure Type 972 Data Element: Type of device/service specific additional data 973 structure 975 Use: Conditional. MUST be provided when device/service specific 976 additional URI is provided 978 XML Element: 980 Description: Value from a registry defined by this document to 981 describe the type of data that can be retrieved from the device/ 982 service specific additional data structure. Initial values are: 984 * IEEE 1512 986 * VEDS 988 IEEE 1512 is the USDoT model for traffic incidents and VEDS 989 provides data elements needed for an efficient emergency response 990 to vehicular emergency incidents. 992 Reason for Need: This data element allows identification of 993 externally defined schemas, which may have additional data that 994 may assist in emergency response. 996 How Used by Call Taker: This data element allows the end user 997 (calltaker or first responder) to know what type of additional 998 data may be available to aid in providing the needed emergency 999 services. 1001 Note: Information which is specific to a location or a caller 1002 (person) should not be placed in this section. 1004 3.3.8. Choosing between defining a new type of block or new type of 1005 device/service specific additional data 1007 For devices that have device or service specific data, there are two 1008 choices to carry it. A new block can be defined, or the device/ 1009 service specific additional data URL the DevInfo block can be used 1010 and a new type for it defined . The data passed would likely be the 1011 same in both cases. Considerations for choosing which mechanism to 1012 register under include: 1014 Applicability: Information which will be carried by many kinds of 1015 devices or services are more appropriately defined as separate 1016 blocks. 1018 Privacy: Information which may contain private data may be better 1019 sent in the DevInfo block, rather than a new block so that 1020 implementations are not tempted to send the data by value, and 1021 thus having more exposure to the data than forcing the data to be 1022 retrieved via the URL in DevInfo. 1024 Size: Information which may be very may be better sent in the 1025 DevInfo block, rather than a new block so that implementations are 1026 not tempted to send the data by value. Conversely, data which is 1027 small may best be sent in a separate block so that it can be sent 1028 by value 1030 Availability of a server: Providing the data via the device block 1031 requires a server be made available to retrieve the data. 1032 Providing the data via new block allows it to be sent by value 1033 (CID). 1035 3.3.9. emergencyCall.DevInfo Example 1036 1037 1040 Fixed phone 1041 Nokia 1042 Lumia 800 1043 35788104 1044 IMEI 1045 1047 Figure 7: emergencyCallDevInfo Example. 1049 3.4. Owner/Subscriber Information 1051 This block describes the owner of the device (if provided by the 1052 device) or the subscriber information, if provided by a service 1053 provider. The contact location is not necessarily the location of 1054 the caller or incident, but is rather the nominal contact address. 1055 The mime subtype is "application/emergencyCall.Subscriber+xml". 1057 In some jurisdictions some or all parts of the subscriber-specific 1058 information are subject to privacy constraints. These constraints 1059 vary but dictate what information and be displayed and logged. A 1060 general privacy indicator expressing a desire for privacy is 1061 provided. The interpretation of how this is applied is left to the 1062 receiving jurisdiction as the custodians of the local regulatory 1063 requirements. 1065 3.4.1. Subscriber Data Privacy Indicator 1067 Attribute: privacyRequested, boolean. 1069 Use: Conditional. This attribute MUST be provided if the owner/ 1070 subscriber information block is not empty. 1072 Description: The subscriber data privacy indicator specifically 1073 expresses the subscriber's desire for privacy. In some 1074 jurisdictions subscriber services can have a specific "Type of 1075 Service" which prohibits information, such as the name of the 1076 subscriber, from being displayed. This attribute should be used 1077 to explicitly indicate whether the subscriber service includes 1078 such constraints. 1080 Reason for Need: Some jurisdictions require subscriber privacy to be 1081 observed. 1083 How Used by Call Taker: Where privacy is indicated the call taker 1084 may not have access to some aspects of the subscriber information. 1086 3.4.2. xCard for Subscriber's Data 1088 Data Element: xCARD for Subscriber's Data 1090 Use: Conditional. Subscriber data is provided unless it is not 1091 available. Some services, for example prepaid phones, non- 1092 initialized phones, etc., do not have information about the 1093 subscriber. 1095 XML Element: 1097 Description: Information known by the service provider or device 1098 about the subscriber; e.g., Name, Address, Individual Telephone 1099 Number, Main Telephone Number and any other data. N, ORG (if 1100 appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more 1101 than one TEL property is provided, a parameter from the vCard 1102 Property Value registry MUST be specified on each TEL. 1104 Reason for Need: When the caller is unable to provide information, 1105 this data may be used to obtain it 1107 How Used by Call Taker: Obtaining critical information about the 1108 caller and possibly the location when it is not able to be 1109 obtained otherwise. 1111 3.4.3. emergencyCall.SubInfo Example 1113 1114 1118 1119 1120 1121 Simon Perreault 1122 1123 Perreault 1124 Simon 1125 1126 1127 ing. jr 1128 M.Sc. 1129 1130 --0203 1131 1132 20090808T1430-0500 1133 1134 M 1135 1136 1 1137 1138 fr 1139 1140 1141 2 1142 1143 en 1144 1145 1146 work 1147 1148 Viagenie 1149 1150 1151 1152 work 1153 1157 1158 1159 1160 2875 boul. Laurier, suite D2-630 1161 Quebec 1162 QC 1163 G1V 2M2 1164 Canada 1165 1166 1167 1168 1169 work 1170 voice 1171 1172 1173 tel:+1-418-656-9254;ext=102 1174 1175 1176 1177 1178 work 1179 text 1180 voice 1181 cell 1182 video 1183 1184 1185 tel:+1-418-262-6501 1186 1187 1188 work 1189 1190 simon.perreault@viagenie.ca 1191 1192 1193 work 1194 1195 geo:46.766336,-71.28955 1196 1197 1198 work 1199 1200 1201 http://www.viagenie.ca/simon.perreault/simon.asc 1202 1203 1204 America/Montreal 1205 1206 home 1207 1208 http://nomis80.org 1209 1210 1211 1212 1213 1215 Figure 8: emergencyCall.SubInfo Example. 1217 3.5. Comment 1219 This block provides a mechanism for the data provider to supply 1220 extra, human readable information to the PSAP. It is not intended 1221 for a general purpose extension mechanism nor does it aim to provide 1222 machine-reable content. The mime subtype is "application/ 1223 emergencyCall.Comment+xml" 1225 3.5.1. Comment 1227 Data Element: EmergencyCall.Comment 1229 Use: Optional 1231 XML Element: 1233 Description: Human readable text providing additional information to 1234 the PSAP staff. 1236 Reason for Need: Explanatory information for values in the data 1237 structure 1239 How Used by Call Taker: To interpret the data provided 1241 3.5.2. emergencyCall.Comment Example 1243 1244 1247 This is an example text. 1248 1250 Figure 9: EmergencyCall.Comment Example. 1252 4. Transport 1254 This section defines how to convey additional data to an emergency 1255 service provider. Two different means are specified: the first uses 1256 the call signaling; the second uses the element of a 1257 PIDF-LO [RFC4119]. 1259 1. First, the ability to embed a Uniform Resource Identifier (URI) 1260 in an existing SIP header field, the Call-Info header, is 1261 defined. The URI points to the additional data structure. The 1262 Call-Info header is specified in Section 20.9 of [RFC3261]. This 1263 document adds a new compound token starting with the value 1264 'emergencyCallData' for the Call-Info "purpose" parameter. If 1265 the "purpose" parameter is set to a value starting with 1266 'emergencyCallData', then the Call-Info header contains either an 1267 HTTPS URL pointing to an external resource or a CID (content 1268 indirection) URI that allows the data structure to be placed in 1269 the body of the SIP message. The "purpose" parameter also 1270 indicates the kind of data (by its MIME type) that is available 1271 at the URI. As the data is conveyed using a URI in the SIP 1272 signaling, the data itself may reside on an external resource, or 1273 may be contained within the body of the SIP message. When the 1274 URI refers to data at an external resource, the data is said to 1275 be passed by reference. When the URI refers to data contained 1276 within the body of the SIP message, the data is said to be passed 1277 by value. A PSAP or emergency responder is able to examine the 1278 type of data provided and selectively inspect the data it is 1279 interested in, while forwarding all of it (the values or 1280 references) to downstream entities. To be conveyed in a SIP 1281 body, additional data about a call is defined as a series of MIME 1282 objects. Each block defined in this document is an XML data 1283 structure identified by its MIME type. (Blocks defined by others 1284 may be encoded in XML or not, as identified by their MIME 1285 registration.) As usual, whenever more than one MIME part is 1286 included in the body of a message, MIME-multipart (i.e., 1287 'multipart/mixed') encloses them all. This document defines a 1288 set of XML schemas and MIME types used for each block defined 1289 here. When additional data is passed by value in the SIP 1290 signaling, each CID URL points to one block in the body. 1291 Multiple URIs are used within a Call-Info header field (or 1292 multiple Call-Info header fields) to point to multiple blocks. 1293 When additional data is provided by reference (in SIP signaling 1294 or Provided-By), each HTTPS URL references one block; the data is 1295 retrieved with an HTTPS GET operation, which returns one of the 1296 blocks as an object (the blocks defined here are returned as XML 1297 objects). 1299 2. Second, the ability to embed additional data structures in the 1300 element of a PIDF-LO [RFC4119] is defined. Besides 1301 a service provider in the call path, the access network provider 1302 may also have similar information that may be valuable to the 1303 PSAP. The access network provider may provide location in the 1304 form of a PIDF-LO from a location server via a location 1305 configuration protocol. The data structures described in this 1306 document are not specific to the location itself, but rather 1307 provides descriptive information having to do with the immediate 1308 circumstances about the provision of the location (who the access 1309 network is, how to contact that entity, what kind of service the 1310 access network provides, subscriber information, etc.). This 1311 data is similar in nearly every respect to the data known by 1312 service providers in the path of the call. When the access 1313 network provider and service provider are separate entities, the 1314 access network does not participate in the application layer 1315 signaling (and hence cannot add a Call-Info header field to the 1316 SIP message), but may provide location information to assist in 1317 locating the caller's device. The element of the 1318 PIDF-LO is a mechanism for the access network provider to supply 1319 the information about the entity or organization that supplied 1320 this location information. For this reason, this document 1321 describes a namespace per RFC 4119 for inclusion in the 1322 element of a PIDF-LO for adding information known 1323 to the access network provider. 1325 One or more blocks of data registered in the Emergency Call 1326 Additional Data registry, as defined in Section 9.1, may be included 1327 or referenced in the SIP signaling (using the Call-Info header field) 1328 or in the element of a PIDF-LO. Every block must be 1329 one of the types in the registry. Since the data of an emergency 1330 call may come from multiple sources, the data itself needs 1331 information describing the source. Consequently, each entity adding 1332 additional data MUST supply the "Data Provider" block. All other 1333 blocks are optional, but each entity SHOULD supply any blocks where 1334 it has at least some of the information in the block. 1336 4.1. Transmitting Blocks using the Call-Info Header 1338 A URI to a block MAY be inserted in a SIP request or response method 1339 (most often INVITE or MESSAGE) with a Call-Info header field 1340 containing a purpose value starting with 'emergencyCallData' and the 1341 type of data available at the URI. The type of data is denoted by 1342 including the root of the MIME type (not including the 1343 'emergencyCall' prefix and any suffix such as '+xml') with a '.' 1344 separator. For example, when referencing a block with MIME type 1345 'application/emergencyCall.ProviderInfo+xml', the 'purpose' parameter 1346 is set to 'emergencyCallData.ProviderInfo'. An example "Call-Info" 1347 header field for this would be: 1349 Call-Info: https://www.example.com/23sedde3; 1350 purpose="emergencyCallData.ProviderInfo" 1352 A Call-info header with a purpose value starting with 1353 'emergencyCallData' MUST only be sent on an emergency call, which can 1354 be ascertained by the presence of an emergency service urn in a Route 1355 header of a SIP message. 1357 If the data is provided by reference, an HTTPS URI MUST be included 1358 and consequently Transport Layer Security (TLS) protection is applied 1359 for protecting the retrieval of the information. 1361 The data may also be supplied by value in a SIP message. In this 1362 case, Content Indirection (CID) [RFC2392] is used, with the CID URL 1363 referencing the MIME body part. 1365 More than one Call-Info header with a purpose value starting with 1366 'emergencyCallData' can be expected, but at least one MUST be 1367 provided. The device MUST provide one if it knows no service 1368 provider is in the path of the call. The device MAY insert one if it 1369 uses a service provider. Any service provider in the path of the 1370 call MUST insert its own. For example, a device, a telematics 1371 service provider in the call path, as well as the mobile carrier 1372 handling the call will each provide one. There may be circumstances 1373 where there is a service provider who is unaware that the call is an 1374 emergency call and cannot reasonably be expected to determine that it 1375 is an emergency call. In that case, that service provider is not 1376 expected to provide emergencyCallData. 1378 4.2. Transmitting Blocks by Reference using the Provided-By Element 1380 The 'emergencyCallDataReference' element is used to transmit an 1381 additional data block by reference within a 'Provided-By' element of 1382 a PIDF-LO. The 'emergencyCallDataReference' element has two 1383 attributes: 'ref' to specify the URL, and 'purpose' to indicate the 1384 type of data block referenced. The value of 'ref' is an HTTPS URL 1385 that resolves to a data structure with information about the call. 1386 The value of 'purpose' is the same as used in a 'Call-Info' header 1387 field (as specified in Section 4.1). 1389 For example, to reference a block with MIME type 'application/ 1390 emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to 1391 'emergencyCallData.ProviderInfo'. An example 1392 'emergencyCallDataReference' element for this would be: 1394 1397 4.3. Transmitting Blocks by Value using the Provided-By Element 1399 It is RECOMMENDED that access networks supply the data specified in 1400 this document by reference, but they MAY provide the data by value. 1402 The 'emergencyCallDataValue' element is used to transmit an 1403 additional data block by value within a 'Provided-By' element of a 1404 PIDF-LO. The 'emergencyCallDataValue' element has one attribute: 1405 'purpose' to indicate the type of data block contained. The value of 1406 'purpose' is the same as used in a 'Call-Info' header field (as 1407 specified in Section 4.1, and in Section 4.1). The same XML 1408 structure as would be contained in the corresponding MIME type body 1409 part is placed inside the 'emergencyCallDataValue' element. 1411 For example: 1413 1415 1416 1418 1420 This is an example text. 1421 1422 1423 1424 1426 Test 1427 NENA 1428 Access Infrastructure Provider 1429 1430 sip:15555550987@burf.example.com;user=phone 1431 1432 1433 1435 Example Provided-By by Value. 1437 4.4. The Content-Disposition Parameter 1439 RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. 1440 It updates and clarifies handling originally defined in RFC 3261 1441 [RFC3261] based on implementation experience. While RFC 3261 did not 1442 mandate support for 'multipart' message bodies 'multipart/mixed' MIME 1443 bodies are, however, used by many extensions (including additional 1444 data) today. For example, adding a PIDF-LO, SDP, and additional data 1445 in body of a SIP message requires a 'multipart' message body. 1447 RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' 1448 parameter for the Content-Disposition header field. These RFCs 1449 describe how a UAS reacts if it receives a message body whose content 1450 type or disposition type it does not understand. If the 'handling' 1451 parameter has the value "optional", the UAS ignores the message body. 1452 If the 'handling' parameter has the value "required", the UAS returns 1453 a 415 (Unsupported Media Type) response. The 'by-reference' 1454 disposition type allows a SIP message to contain a reference to the 1455 body part, and the SIP UA processes the body part according to the 1456 reference. This is the case for the Call-info header containing a 1457 Content Indirection (CID) URL. 1459 As an example, a SIP message indicates the Content-Disposition 1460 parameter in the body of the SIP message as shown in Figure 10. 1462 Content-Type: application/sdp 1464 ...Omit Content-Disposition here; defaults are ok 1465 ...SDP goes here 1467 --boundary1 1469 Content-Type: application/pidf+xml 1470 Content-ID: 1471 Content-Disposition: by-reference;handling=optional 1473 ...PIDF-LO goes here 1475 --boundary1-- 1477 Content-Type: application/emergencyCall.ProviderInfo+xml 1478 Content-ID: <1234567890@atlanta.example.com> 1479 Content-Disposition: by-reference;handling=optional 1481 ...Additional data goes here 1483 --boundary1-- 1485 Figure 10: Example for use of the Content-Disposition Parameter in 1486 SIP. 1488 5. Examples 1490 This section provides three examples of communicating additional 1491 data. In Figure 11 additional data is communicated in a SIP INVITE 1492 per value. In Figure 12 we illustrate how additional data is added 1493 by a SIP proxy per reference. Finally, an example for including 1494 additional data in the element of a PIDF-LO is 1495 illustrated. 1497 INVITE sips:bob@biloxi.example.com SIP/2.0 1498 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1499 Max-Forwards: 70 1500 To: Bob 1501 From: Alice ;tag=9fxced76sl 1502 Call-ID: 3848276298220188511@atlanta.example.com 1503 Call-Info: ;purpose=icon, 1504 ;purpose=info, 1505 1506 ;purpose=emergencyCallData.ProviderInfo 1507 Geolocation: 1508 Geolocation-Routing: no 1509 Accept: application/sdp, application/pidf+xml, 1510 application/emergencyCallProviderinfo+xml 1511 CSeq: 31862 INVITE 1512 Contact: 1513 Content-Type: multipart/mixed; boundary=boundary1 1515 Content-Length: ... 1517 --boundary1 1519 Content-Type: application/sdp 1521 ...SDP goes here 1523 --boundary1 1525 Content-Type: application/pidf+xml 1526 Content-ID: 1527 Content-Disposition: by-reference;handling=optional 1529 ...PIDF-LO goes here 1531 --boundary1-- 1533 Content-Type: application/emergencyCall.ProviderInfo+xml 1534 Content-ID: <1234567890@atlanta.example.com> 1535 Content-Disposition: by-reference;handling=optional 1537 ...Additional data goes here 1539 --boundary1-- 1541 Figure 11: Example: Attaching Additional Data via CID to a SIP 1542 INVITE. 1544 INVITE sips:bob@biloxi.example.com SIP/2.0 1545 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1546 Max-Forwards: 70 1547 To: Bob 1548 From: Alice ;tag=9fxced76sl 1549 Call-ID: 3848276298220188511@atlanta.example.com 1550 Call-Info: ;purpose=icon, 1551 ;purpose=info, 1552 1553 ;purpose=emergencyCallData.ProviderInfo 1554 Geolocation: 1555 Geolocation-Routing: no 1556 Accept: application/sdp, application/pidf+xml, 1557 application/emergencyCallProviderinfo+xml 1558 CSeq: 31862 INVITE 1559 Contact: 1560 Content-Type: multipart/mixed; boundary=boundary1 1562 Content-Length: ... 1564 --boundary1 1566 Content-Type: application/sdp 1568 ...SDP goes here 1570 --boundary1 1572 Content-Type: application/pidf+xml 1573 Content-ID: 1574 Content-Disposition: by-reference;handling=optional 1576 ...PIDF-LO goes here 1578 --boundary1-- 1580 Figure 12: Example: Attaching Additional Data per Reference in a SIP 1581 INVITE. 1583 1584 1589 1590 1591 1592 1594 AU 1595 NSW 1596 Wollongong 1597 North Wollongong 1598 Flinders 1599 Street 1600 Campbell Street 1601 Gilligan's Island 1602 Corner 1603 Video Rental Store 1604 2500 1605 Westerns and Classics 1606 store 1607 Private Box 15 1608 1609 1610 1611 true 1612 1613 2013-07-10T20:00:00Z 1614 1615 1616 802.11 1617 1620 1623 1624 1626 University of California, Irvine 1627 1628 urn:nena:companyid:uci 1629 NENA 1630 Other 1631 tel:+1 9498245222 1632 EN 1633 1635 1637 This is an example text. 1638 1640 1641 1642 1643 mac:1234567890ab 1644 2013-07-09T20:57:29Z 1645 1646 1647 Figure 13: Example: Including Additional Data via the Provided-By 1648 Element in a PIDF-LO. 1650 6. XML Schemas 1652 This section defines the XML schemas of the five data blocks. 1653 Additionally, the Provided-By schema is specified. 1655 6.1. emergencyCall.ProviderInfo XML Schema 1657 1658 1667 1670 1672 1673 1674 1675 1676 1678 1682 1683 1684 1685 1686 1687 1689 1690 1691 1693 1695 1697 1699 1701 1703 1706 1708 1711 1713 1714 1716 1718 Figure 14: emergencyCall.ProviderInfo XML Schema. 1720 6.2. emergencyCall.SvcInfo XML Schema 1722 1723 1730 1733 1735 1736 1737 1739 1742 1744 1747 1749 1750 1752 1754 Figure 15: emergencyCall.SvcInfo XML Schema. 1756 6.3. emergencyCall.DevInfo XML Schema 1758 1759 1766 1769 1771 1772 1773 1775 1777 1779 1781 1783 1785 1788 1790 1791 1793 1795 Figure 16: emergencyCall.DevInfo XML Schema. 1797 6.4. emergencyCall.SubInfo XML Schema 1799 1800 1808 1811 1813 1815 1816 1817 1818 1821 1823 1824 1825 1826 1828 1830 Figure 17: emergencyCall.SubInfo XML Schema. 1832 6.5. emergencyCall.Comment XML Schema 1834 1835 1842 1845 1847 1848 1849 1852 1854 1855 1857 1858 1859 1860 1861 1862 1863 1865 1867 Figure 18: EmergencyCall.Comment XML Schema. 1869 6.6. Provided-By XML Schema 1871 This section defines the Provided-By schema. 1873 1874 1887 1888 1889 1890 1891 1893 1895 1896 1898 1902 1906 1909 1911 1913 1915 1916 1917 1918 1919 1921 1922 1924 1926 1927 1928 1929 1931 1932 1933 1936 1939 1942 1945 1949 1952 1953 1955 1957 Figure 19: Provided-By XML Schema. 1959 7. Security Considerations 1961 The information in this data structure will usually be considered 1962 private. HTTPS is specified to require the provider of the 1963 information to validate the credentials of the requester. While the 1964 creation of a public key infrastructure (PKI) that has global scope 1965 may be difficult, the alternatives to creating devices and services 1966 that can provide critical information securely are more daunting. 1967 The provider may enforce any policy it wishes to use, but PSAPs and 1968 responder agencies should deploy a PKI so that providers of 1969 additional data can check the certificate of the client and decide 1970 the appropriate policy to enforce based on that certificate. 1972 Ideally, the PSAP and emergency responders will be given credentials 1973 signed by an authority trusted by the data provider. In most 1974 circumstances, nationally recognized credentials would be sufficient, 1975 and if the emergency services arranges a PKI, data providers could be 1976 provisioned with the root CA public key for a given nation. Some 1977 nations are developing a PKI for this, and related, purposes. Since 1978 calls could be made from devices where the device and/or the service 1979 provider(s) are not local to the emergency authorities, globally 1980 recognized credentials are useful. This might be accomplished by 1981 extending the notion of the "forest guide" described in [RFC5222] to 1982 allow the forest guide to provide the credential of the PKI root for 1983 areas that it has coverage information for, but standards for such a 1984 mechanism are not yet available. In its absence, the data provider 1985 will need to obtain the root CA credentials for any areas it is 1986 willing to provide additional data by out of band means. With the 1987 credential of the root CA for a national emergency services PKI, the 1988 data provider server can validate the credentials of an entity 1989 requesting additional data by reference. 1991 The data provider also needs a credential that can be verified by the 1992 emergency services to know that it is receiving data from the right 1993 server. The emergency authorities could provide credentials, 1994 distinguishable from credentials it provides to emergency responders 1995 and PSAPs, which could be used to validate data providers. Such 1996 credentials would have to be acceptable to any PSAP or responder that 1997 could receive a call with additional data supplied by that provider. 1998 This would be extensible to global credential validation using the 1999 forest guide as above. In the absence of such credentials, the 2000 emergency authorities could maintain a list of local data providers' 2001 credentials provided to it out of band. At a minimum, the emergency 2002 authorities could obtain a credential from the DNS entry of the 2003 domain in the Additional Data URI to at least validate that the 2004 server is known to the domain providing the URI. 2006 Data provided by devices by reference have similar credential 2007 validation issues to service providers, and the solutions are the 2008 same. 2010 8. Privacy Considerations 2012 This document enables functionality for conveying additional 2013 information about the caller to the callee. Some of this information 2014 is personal data and therefore privacy concerns arise. An explicit 2015 privacy indicator for information directly relating to the callers 2016 identity is defined and use is mandatory. However, observance of 2017 this request for privacy and what information it relates to is 2018 controlled by the destination jurisdiction. 2020 There are a number of privacy concerns with regular real-time 2021 communication services that are also applicable to emergency calling. 2022 Data protection regulation world-wide has, however, decided to create 2023 exceptions for emergency services since the drawbacks of disclosing 2024 personal data in comparison to the benefit for the emergency caller 2025 are often towards the latter. Hence, the data protection rights of 2026 individuals are often waived for emergency situations. There are, 2027 however, still various countries that offer some degree of anonymity 2028 for the caller towards PSAP call takers. 2030 The functionality defined in this document, however, far exceeds the 2031 amount of information sharing found in the Plain old telephone system 2032 (POTS). For this reason there are additional privacy threats to 2033 consider, which are described in more detail in [RFC6973]. 2035 Stored Data Compromise: First, there is an increased risk of stored 2036 data compromise since additional data is collected and stored in 2037 databases. Without adequate measures to secure stored data from 2038 unauthorized or inappropriate access at access network operators, 2039 service providers, end devices, as well as PSAPs individuals are 2040 exposed to potential financial, reputational, or physical harm. 2042 Misattribution: If the personal data collected and conveyed is 2043 incorrect or inaccurate then this may lead to misattribution. 2044 Misattribution occurs when data or communications related to one 2045 individual are attributed to another. 2047 Identification: By the nature of the additional data and its 2048 capability to provide much richer information about the caller, 2049 the call, and the location the calling party is identified in a 2050 much better way. Some users may feel uncomfortable with this 2051 degree of information sharing even in emergency services 2052 situations. 2054 Secondary Use: Furthermore, there is the risk of secondary use. 2055 Secondary use is the use of collected information about an 2056 individual without the individual's consent for a purpose 2057 different from that for which the information was collected. The 2058 stated purpose of the additional data is for emergency services 2059 purposes but theoretically the same information could be used for 2060 any other call as well. Additionally, parties involved in the 2061 emergency call may retain the obtained information and may re-use 2062 it for other, non-emergency services purposes. 2064 Disclosure: When the data defined in this document is not properly 2065 security (while in transit with traditional communication security 2066 techniques, and while at rest using access control mechanisms) 2067 there is the risk of disclosure, which is the revelation of 2068 information about an individual that affects the way others judge 2069 the individual. 2071 To mitigate these privacy risks the following countermeasures can be 2072 taken. 2074 In regions where callers can elect to suppress certain personally 2075 identifying information, the network or PSAP functionality can 2076 inspect privacy flags within the SIP headers to determine what 2077 information may be passed, stored, or displayed to comply with local 2078 policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token. 2079 The presence of this privacy type in a Privacy header field indicates 2080 that the user would like the network asserted identity to be kept 2081 private with respect to SIP entities outside the trust domain with 2082 which the user authenticated, including the PSAP. 2084 This document defines various data structures that constitutes 2085 personal data. Local regulations may govern what data must be 2086 provided in emergency calls, but in general, the emergency call 2087 system is often aided by the kinds of information described in this 2088 document. There is a tradeoff between the privacy considerations and 2089 the utility of the data. For adequate protection this specification 2090 requires all data exchanges to be secured via communication security 2091 techniques (namely TLS) against eavesdropping and inception. 2092 Furthermore, security safeguards are required to prevent unauthorized 2093 access to data at rest. Various security incidents over the last 10 2094 years have shown data breaches are not not uncommon and are often 2095 caused by lack of proper access control frameworks, software bugs 2096 (buffer overflows), or missing input parsing (SQL injection attacks). 2097 The risks of data breaches is increased with the obligation for 2098 emergency services to retain emergency call related data for extended 2099 periods, e.g., several years are the norm. 2101 Finally, it is also worth to highlight the nature of the SIP 2102 communication architecture, which introduces additional complications 2103 for privacy. Some forms of data can be sent by value in the SIP 2104 signaling or by value (URL in SIP signaling). When data is sent by 2105 value, all intermediaries have access to the data. As such, these 2106 intermediaries may also introduce additional privacy risk. 2107 Therefore, in situations where the conveyed information raises 2108 privacy concerns and intermediaries are involved transmitting a 2109 reference is more appropriate (assuming proper access control 2110 policies are available for distinguishing the different entities 2111 dereferencing the reference). Without access control policies any 2112 party in possession of the reference is able to resolve the reference 2113 and to obtain the data, including intermediaries. 2115 9. IANA Considerations 2116 9.1. Registry creation 2118 This document creates a new registry called 'Emergency Call 2119 Additional Data'. The following sub-registries are created in 2120 Emergency Call Additional Data: 2122 9.1.1. Provider ID Series Registry 2124 This document creates a new sub-registry called 'Additional Call Data 2125 Provider ID Series'. As defined in [RFC5226], this registry operates 2126 under "Expert Review" rules. The expert should determine that the 2127 entity requesting a new value is a legitimate issuer of service 2128 provider IDs suitable for use in Additional Call Data. 2130 The content of this registry includes: 2132 Name: The identifier which will be used in the ProviderIDSeries 2133 element 2135 Source: The full name of the organization issuing the identifiers 2137 URL: A URL to the organization for further information 2139 The initial set of values is listed in Figure 20. 2141 +-----------+--------------------------+----------------------+ 2142 | Name | Source | URL | 2143 +-----------+--------------------------+----------------------+ 2144 | NENA | National Emergency | http://www.nena.org | 2145 | | Number Association | | 2146 | EENA | European Emergency | http://www.eena.org | 2147 | | Number Association | | 2148 +-----------+--------------------------+----------------------+ 2150 Figure 20: Provider ID Series Registry. 2152 9.1.2. Service Provider Type Registry 2154 This document creates a new sub-registry called 'Service Provider 2155 Type'. As defined in [RFC5226], this registry operates under "Expert 2156 Review". The expert should determine that the proposed new value is 2157 distinct from existing values and appropriate for use in the 2158 TypeOfServicerProvider element 2160 The content of this registry includes: 2162 Name: Value to be used in TypeOfServiceProvider. 2164 Description: A short description of the type of service provider 2166 The initial set of values is defined in Figure 1. 2168 9.1.3. Service Delivered Registry 2170 This document creates a new sub-registry called 'Service Delivered'. 2171 As defined in [RFC5226], this registry operates under "Expert Review" 2172 rules. The expert should consider whether the proposed service is 2173 unique from existing services and the definition of the service will 2174 be clear to implementors and PSAPS/responders. 2176 The content of this registry includes: 2178 Name: Enumeration token of the service. 2180 Description: Short description identifying the service. 2182 The initial set of values are defined in Figure 3. 2184 9.1.4. Device Classification Registry 2186 This document creates a new sub-registry called 'Device 2187 Classification'. As defined in [RFC5226], this registry operates 2188 under "Expert Review" rules. The expert should consider whether the 2189 proposed class is unique from existing classes and the definition of 2190 the class will be clear to implementors and PSAPS/responders. 2192 The content of this registry includes: 2194 Name: Enumeration token of the device classification. 2196 Description: Short description identifying the device type. 2198 The initial set of values are defined in Figure 5. 2200 9.1.5. Device ID Type Type Registry 2202 This document creates a new sub-registry called 'Additional Call Data 2203 Device ID Type'. As defined in [RFC5226], this registry operates 2204 under "Expert Review" rules. The expert should ascertain that the 2205 proposed type is well understood, and provides the information useful 2206 to PSAPs and responders to uniquely identify a device. 2208 The content of this registry includes: 2210 Name: Enumeration token of the device id type. 2212 Description: Short description identifying type of device id. 2214 The initial set of values are defined in Figure 6. 2216 9.1.6. Device/Service Data Type Registry 2218 This document creates a new sub-registry called 'Device/Service Data 2219 Type Registry'. As defined in [RFC5226], this registry operates 2220 under "Expert Review" and "Specification Required" rules. The expert 2221 should ascertain that the proposed type is well understood, and 2222 provides information useful to PSAPs and responders. The 2223 specification must contain a complete description of the data, and a 2224 precise format specification suitable to allow interoperable 2225 implementations. 2227 The content of this registry includes: 2229 Name: Enumeration token of the data type. 2231 Description: Short description identifying the the data. 2233 Specification: Citation for the specification of the data. 2235 The initial set of values are listed in Figure 21. 2237 +---------+----------------------------------------+----------------+ 2238 | Token | Description | Specification | 2239 +---------+----------------------------------------+----------------+ 2240 | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | 2241 +---------+----------------------------------------+----------------+ 2242 | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | 2243 +---------+----------------------------------------+----------------+ 2245 Figure 21: Device/Service Data Type Registry. 2247 9.1.7. Additional Data Blocks Registry 2249 This document creates a new sub-registry called 'Additional Data 2250 Blocks' in the purpose registry established by RFC 3261 [RFC3261]. 2251 As defined in [RFC5226], this registry operates under "Expert Review" 2252 and "Specification Required" rules. The expert is responsible for 2253 verifying that the document contains a complete and clear 2254 specification and the proposed functionality does not obviously 2255 duplicate existing functionality. 2257 The content of this registry includes: 2259 Name: Element Name of enclosing block. 2261 Reference: The document that describes the block 2263 The initial set of values are listed in Figure 22. 2265 +--------------+------------+ 2266 | Token | Reference | 2267 +--------------+------------+ 2268 | ProviderInfo | [This RFC] | 2269 | SvcInfo | [This RFC] | 2270 | DevInfo | [This RFC] | 2271 | Subscriber | [This RFC] | 2272 | Comment | [This RFC] | 2273 +--------------+------------+ 2275 Figure 22: Additional Data Blocks Registry. 2277 9.2. 'emergencyCallData' Purpose Parameter Value 2279 This document defines the 'emergencyCall' value for the "purpose" 2280 parameter of the Call-Info header field. The Call-Info header and 2281 the corresponding registry for the 'purpose' parameter was 2282 established with RFC 3261 [RFC3261]. 2284 Header Parameter New 2285 Field Name Value Reference 2286 ---------- --------- ----------------- --------- 2287 Call-Info purpose emergencyCall [This RFC] 2289 9.3. URN Sub-Namespace Registration for provided-by Registry Entry 2291 This section registers the namespace specified in Section 9.5.1 in 2292 the provided-by registry established by RFC 4119, for usage within 2293 the element of a PIDF-LO. 2295 The schema for the provided-by schema used by this document is 2296 specified in Section 6.6. 2298 9.4. MIME Registrations 2300 9.4.1. MIME Content-type Registration for 'application/ 2301 emergencyCall.ProviderInfo+xml' 2303 This specification requests the registration of a new MIME type 2304 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2305 RFC 3023 [RFC3023]. 2307 MIME media type name: application 2309 MIME subtype name: emergencyCall.ProviderInfo+xml 2311 Mandatory parameters: none 2313 Optional parameters: charset Indicates the character encoding of 2314 enclosed XML. 2316 Encoding considerations: Uses XML, which can employ 8-bit 2317 characters, depending on the character encoding used. See 2318 Section 3.2 of RFC 3023 [RFC3023]. 2320 Security considerations: This content type is designed to carry 2321 the data provider information, which is a sub-category of 2322 additional data about an emergency call. Since this data contains 2323 personal information appropriate precautions have to be taken to 2324 limit unauthorized access, inappropriate disclosure to third 2325 parties, and eavesdropping of this information. Please refer to 2326 Section 7 and Section 8 for more information. 2328 Interoperability considerations: None 2330 Published specification: [TBD: This specification] 2332 Applications which use this media type: Emergency Services 2334 Additional information: Magic Number: None File Extension: .xml 2335 Macintosh file type code: 'TEXT' 2337 Person and email address for further information: Hannes 2338 Tschofenig, Hannes.Tschofenig@gmx.net 2340 Intended usage: LIMITED USE 2342 Author: This specification is a work item of the IETF ECRIT 2343 working group, with mailing list address . 2345 Change controller: The IESG 2347 9.4.2. MIME Content-type Registration for 'application/ 2348 emergencyCall.SvcInfo+xml' 2350 This specification requests the registration of a new MIME type 2351 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2352 RFC 3023 [RFC3023]. 2354 MIME media type name: application 2356 MIME subtype name: emergencyCall.SvcInfo+xml 2358 Mandatory parameters: none 2360 Optional parameters: charset Indicates the character encoding of 2361 enclosed XML. 2363 Encoding considerations: Uses XML, which can employ 8-bit 2364 characters, depending on the character encoding used. See 2365 Section 3.2 of RFC 3023 [RFC3023]. 2367 Security considerations: This content type is designed to carry 2368 the service information, which is a sub-category of additional 2369 data about an emergency call. Since this data contains personal 2370 information appropriate precautions have to be taken to limit 2371 unauthorized access, inappropriate disclosure to third parties, 2372 and eavesdropping of this information. Please refer to Section 7 2373 and Section 8 for more information. 2375 Interoperability considerations: None 2377 Published specification: [TBD: This specification] 2379 Applications which use this media type: Emergency Services 2381 Additional information: Magic Number: None File Extension: .xml 2382 Macintosh file type code: 'TEXT' 2384 Person and email address for further information: Hannes 2385 Tschofenig, Hannes.Tschofenig@gmx.net 2387 Intended usage: LIMITED USE 2389 Author: This specification is a work item of the IETF ECRIT 2390 working group, with mailing list address . 2392 Change controller: The IESG 2394 9.4.3. MIME Content-type Registration for 'application/ 2395 emergencyCall.DevInfo+xml' 2397 This specification requests the registration of a new MIME type 2398 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2399 RFC 3023 [RFC3023]. 2401 MIME media type name: application 2403 MIME subtype name: emergencyCall.DevInfo+xml 2405 Mandatory parameters: none 2407 Optional parameters: charset Indicates the character encoding of 2408 enclosed XML. 2410 Encoding considerations: Uses XML, which can employ 8-bit 2411 characters, depending on the character encoding used. See 2412 Section 3.2 of RFC 3023 [RFC3023]. 2414 Security considerations: This content type is designed to carry 2415 the device information information, which is a sub-category of 2416 additional data about an emergency call. Since this data contains 2417 personal information appropriate precautions have to be taken to 2418 limit unauthorized access, inappropriate disclosure to third 2419 parties, and eavesdropping of this information. Please refer to 2420 Section 7 and Section 8 for more information. 2422 Interoperability considerations: None 2424 Published specification: [TBD: This specification] 2426 Applications which use this media type: Emergency Services 2428 Additional information: Magic Number: None File Extension: .xml 2429 Macintosh file type code: 'TEXT' 2431 Person and email address for further information: Hannes 2432 Tschofenig, Hannes.Tschofenig@gmx.net 2434 Intended usage: LIMITED USE 2436 Author: This specification is a work item of the IETF ECRIT 2437 working group, with mailing list address . 2439 Change controller: The IESG 2441 9.4.4. MIME Content-type Registration for 'application/ 2442 emergencyCall.SubInfo+xml' 2444 This specification requests the registration of a new MIME type 2445 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2446 RFC 3023 [RFC3023]. 2448 MIME media type name: application 2450 MIME subtype name: emergencyCall.SubInfo+xml 2452 Mandatory parameters: none 2454 Optional parameters: charset Indicates the character encoding of 2455 enclosed XML. 2457 Encoding considerations: Uses XML, which can employ 8-bit 2458 characters, depending on the character encoding used. See 2459 Section 3.2 of RFC 3023 [RFC3023]. 2461 Security considerations: This content type is designed to carry 2462 owner/subscriber information, which is a sub-category of 2463 additional data about an emergency call. Since this data contains 2464 personal information appropriate precautions have to be taken to 2465 limit unauthorized access, inappropriate disclosure to third 2466 parties, and eavesdropping of this information. Please refer to 2467 Section 7 and Section 8 for more information. 2469 Interoperability considerations: None 2471 Published specification: [TBD: This specification] 2473 Applications which use this media type: Emergency Services 2475 Additional information: Magic Number: None File Extension: .xml 2476 Macintosh file type code: 'TEXT' 2478 Person and email address for further information: Hannes 2479 Tschofenig, Hannes.Tschofenig@gmx.net 2481 Intended usage: LIMITED USE 2483 Author: This specification is a work item of the IETF ECRIT 2484 working group, with mailing list address . 2486 Change controller: The IESG 2488 9.4.5. MIME Content-type Registration for 'application/ 2489 emergencyCall.Comment+xml' 2491 This specification requests the registration of a new MIME type 2492 according to the procedures of RFC 4288 [RFC4288] and guidelines in 2493 RFC 3023 [RFC3023]. 2495 MIME media type name: application 2497 MIME subtype name: emergencyCall.Comment+xml 2499 Mandatory parameters: none 2501 Optional parameters: charset Indicates the character encoding of 2502 enclosed XML. 2504 Encoding considerations: Uses XML, which can employ 8-bit 2505 characters, depending on the character encoding used. See 2506 Section 3.2 of RFC 3023 [RFC3023]. 2508 Security considerations: This content type is designed to carry a 2509 comment, which is a sub-category of additional data about an 2510 emergency call. This data may contain personal information. 2511 Appropriate precautions may have to be taken to limit unauthorized 2512 access, inappropriate disclosure to third parties, and 2513 eavesdropping of this information. Please refer to Section 7 and 2514 Section 8 for more information. 2516 Interoperability considerations: None 2518 Published specification: [TBD: This specification] 2520 Applications which use this media type: Emergency Services 2522 Additional information: Magic Number: None File Extension: .xml 2523 Macintosh file type code: 'TEXT' 2525 Person and email address for further information: Hannes 2526 Tschofenig, Hannes.Tschofenig@gmx.net 2528 Intended usage: LIMITED USE 2530 Author: This specification is a work item of the IETF ECRIT 2531 working group, with mailing list address . 2533 Change controller: The IESG 2535 9.5. URN Sub-Namespace Registration 2537 9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 2538 This section registers a new XML namespace, as per the guidelines in 2539 RFC 3688 [RFC3688]. 2541 URI: urn:ietf:params:xml:ns:emergencyCallAddlData 2543 Registrant Contact: IETF, ECRIT working group, , as 2544 delegated by the IESG . 2546 XML: 2548 BEGIN 2549 2550 2552 2553 2554 2556 Namespace for Additional Emergency Call Data 2557 2558 2559

Namespace for Additional Data related to an Emergency Call

2560

See [TBD: This document].

2561 2562 2563 END 2565 9.5.2. Registration for 2566 urn:ietf:params:xml:ns:emergencyCallProviderInfo 2568 This section registers a new XML namespace, as per the guidelines in 2569 RFC 3688 [RFC3688]. 2571 URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo 2573 Registrant Contact: IETF, ECRIT working group, , as 2574 delegated by the IESG . 2576 XML: 2578 BEGIN 2579 2580 2583 2584 2585 2587 Namespace for Additional Emergency Call Data: 2588 Data Provider Information 2589 2590 2591

Namespace for Additional Data related to an Emergency Call

2592

Data Provider Information

2593

See [TBD: This document].

2594 2595 2596 END 2598 9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2600 This section registers a new XML namespace, as per the guidelines in 2601 RFC 3688 [RFC3688]. 2603 URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo 2605 Registrant Contact: IETF, ECRIT working group, , as 2606 delegated by the IESG . 2608 XML: 2610 BEGIN 2611 2612 2614 2615 2616 2618 Namespace for Additional Emergency Call Data: 2619 Service Information 2620 2621 2622

Namespace for Additional Data related to an Emergency Call

2623

Service Information

2624

See [TBD: This document].

2625 2626 2627 END 2629 9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 2631 This section registers a new XML namespace, as per the guidelines in 2632 RFC 3688 [RFC3688]. 2634 URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo 2636 Registrant Contact: IETF, ECRIT working group, , as 2637 delegated by the IESG . 2639 XML: 2641 BEGIN 2642 2643 2645 2646 2647 2649 Namespace for Additional Emergency Call Data: 2650 Device Information 2651 2652 2653

Namespace for Additional Data related to an Emergency Call

2654

Device Information

2655

See [TBD: This document].

2656 2657 2658 END 2660 9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 2662 This section registers a new XML namespace, as per the guidelines in 2663 RFC 3688 [RFC3688]. 2665 URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo 2667 Registrant Contact: IETF, ECRIT working group, , as 2668 delegated by the IESG . 2670 XML: 2672 BEGIN 2673 2674 2676 2677 2678 2680 Namespace for Additional Emergency Call Data: 2681 Owner/Subscriber Information 2682 2683 2684

Namespace for Additional Data related to an Emergency Call

2685

Owner/Subscriber Information

2686

See [TBD: This document].

2687 2688 2689 END 2691 9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 2693 This section registers a new XML namespace, as per the guidelines in 2694 RFC 3688 [RFC3688]. 2696 URI: urn:ietf:params:xml:ns:emergencyCall.Comment 2698 Registrant Contact: IETF, ECRIT working group, , as 2699 delegated by the IESG . 2701 XML: 2703 BEGIN 2704 2705 2707 2708 2709 2711 Namespace for Additional Emergency Call Data:Comment 2712 2713 2714

Namespace for Additional Data related to an Emergency Call

2715

Comment

2716

See [TBD: This document].

2717 2718 2719 END 2721 9.6. Schema Registrations 2723 This specification registers five schemas, as per the guidelines in 2724 RFC 3688 [RFC3688]. 2726 URI: urn:ietf:params:xml:schema:additional- 2727 data:emergencyCallProviderInfo 2729 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2730 delegated by the IESG (iesg@ietf.org). 2732 XML: The XML schema can be found in Figure 14. 2734 URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo 2736 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as 2737 delegated by the IESG (iesg@ietf.org). 2739 XML: The XML schema can be found in Figure 15. 2741 URI: urn:ietf:params:xml:schema:additional- 2742 data:emergencyCallDevInfo 2744 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2745 delegated by the IESG (iesg@ietf.org). 2747 XML: The XML schema can be found in Figure 16. 2749 URI: urn:ietf:params:xml:schema:additional- 2750 data:emergencyCall.SubInfo 2752 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2753 delegated by the IESG (iesg@ietf.org). 2755 XML: The XML schema can be found in Section 6.4. 2757 URI: urn:ietf:params:xml:schema:additional- 2758 data:emergencyCall.Comment 2760 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as 2761 delegated by the IESG (iesg@ietf.org). 2763 XML: The XML schema can be found in Section 6.5. 2765 9.7. VCard Parameter Value Registration 2767 This document registers a new value in the vCARD Parameter Values 2768 registry as defined by [RFC6350] with the following template: 2770 Value: main 2772 Purpose: The main telephone number, typically of an enterprise, as 2773 opposed to a direct dial number of an individual employee 2775 Conformance: This value can be used with the "TYPE" parameter 2776 applied on the "TEL" property. 2778 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 2779 00 2781 10. Acknowledgments 2783 This work was originally started in NENA and has benefitted from a 2784 large number of participants in NENA standardization efforts, 2785 originally in the Long Term Definition Working Group, the Data 2786 Technical Committee and most recently the Additional Data working 2787 group. The authors are grateful for the initial work and extended 2788 comments provided by many NENA participants, including Delaine 2789 Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James 2790 Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, 2791 and Robert (Bob) Sherry. 2793 We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin 2794 Thomson, Keith Drage, Laura Liess, and Barbara Stark for their review 2795 comments. 2797 11. References 2799 11.1. Normative References 2801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2802 Requirement Levels", BCP 14, RFC 2119, March 1997. 2804 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2805 Locators", RFC 2392, August 1998. 2807 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2808 Types", RFC 3023, January 2001. 2810 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 2811 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 2812 and QSIG Objects", RFC 3204, December 2001. 2814 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2815 A., Peterson, J., Sparks, R., Handley, M., and E. 2816 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2817 June 2002. 2819 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 2820 Extensions to the Session Initiation Protocol (SIP) for 2821 Asserted Identity within Trusted Networks", RFC 3325, 2822 November 2002. 2824 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 2825 Extensions (MIME) Parameter", RFC 3459, January 2003. 2827 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2828 January 2004. 2830 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2831 Format", RFC 4119, December 2005. 2833 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2834 Registration Procedures", RFC 4288, December 2005. 2836 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2837 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2838 May 2008. 2840 [RFC5621] Camarillo, G., "Message Body Handling in the Session 2841 Initiation Protocol (SIP)", RFC 5621, September 2009. 2843 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 2844 August 2011. 2846 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2847 6351, August 2011. 2849 11.2. Informational References 2851 [I-D.ietf-geopriv-relative-location] 2852 Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 2853 Thomson, "Relative Location Representation", draft-ietf- 2854 geopriv-relative-location-08 (work in progress), September 2855 2013. 2857 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 2858 Emergency Context Resolution with Internet Technologies", 2859 RFC 5012, January 2008. 2861 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 2862 Format for Presence Information Data Format Location 2863 Object (PIDF-LO)", RFC 5139, February 2008. 2865 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 2866 Tschofenig, "LoST: A Location-to-Service Translation 2867 Protocol", RFC 5222, August 2008. 2869 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2870 Presence Information Data Format Location Object (PIDF-LO) 2871 Usage Clarification, Considerations, and Recommendations", 2872 RFC 5491, March 2009. 2874 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 2875 Thomson, "Dynamic Extensions to the Presence Information 2876 Data Format Location Object (PIDF-LO)", RFC 5962, 2877 September 2010. 2879 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 2880 5985, September 2010. 2882 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2883 "Framework for Emergency Calling Using Internet 2884 Multimedia", RFC 6443, December 2011. 2886 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 2887 R. George, "Specifying Civic Address Extensions in the 2888 Presence Information Data Format Location Object (PIDF- 2889 LO)", RFC 6848, January 2013. 2891 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 2892 Communications Services in Support of Emergency Calling", 2893 BCP 181, RFC 6881, March 2013. 2895 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2896 Morris, J., Hansen, M., and R. Smith, "Privacy 2897 Considerations for Internet Protocols", RFC 6973, July 2898 2013. 2900 Appendix A. XML Schema for vCard/xCard 2902 This section contains the vCard/xCard XML schema version of the Relax 2903 NG schema defined in RFC 6351 [RFC6351] for simplified use with the 2904 XML schemas defined in this document. The schema in RFC 6351 2905 [RFC6351] is the normative source and this section is informative 2906 only. 2908 2909 2913 2919 2920 2921 vCard Format Specification 2922 2923 2924 2925 2926 2927 2928 2929 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2944 2945 2946 2948 2949 2950 2951 2952 2954 2955 2956 2958 2959 2960 2961 2962 2964 2965 2966 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 3011 3012 3013 3014 3018 3019 3020 Section 5: Parameters 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 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 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 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 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 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 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 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 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 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 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 3948 3949 3950 3951 3952 3953 3954 3956 3957 3958 3959 3960 3961 3962 3964 3965 3966 3968 3970 3971 3972 3974 3975 3976 3977 3979 Authors' Addresses 3981 Brian Rosen 3982 NeuStar 3983 470 Conrad Dr. 3984 Mars, PA 16046 3985 US 3987 Phone: +1 724 382 1051 3988 Email: br@brianrosen.net 3990 Hannes Tschofenig 3991 Nokia Solutions and Networks 3992 Linnoitustie 6 3993 Espoo 02600 3994 Finland 3996 Phone: +358 (50) 4871445 3997 Email: Hannes.Tschofenig@gmx.net 3998 URI: http://www.tschofenig.priv.at 4000 Roger Marshall 4001 TeleCommunication Systems, Inc. 4002 2401 Elliott Avenue 4003 Seattle, WA 98121 4004 US 4006 Phone: +1 206 792 2424 4007 Email: rmarshall@telecomsys.com 4008 URI: http://www.telecomsys.com 4009 Randall Gellens 4010 Qualcomm Technologies, Inc. 4011 5775 Morehouse Drive 4012 San Diego, CA 92121 4013 US 4015 Email: rg+ietf@qti.qualcomm.com 4017 James Winterbottom 4018 AU 4020 Email: a.james.winterbottom@gmail.com