idnits 2.17.1 draft-rosen-ecrit-additional-data-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 5169 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: 'RFC3261' is mentioned on line 683, but not defined == Missing Reference: 'RFC5367' is mentioned on line 683, but not defined == Missing Reference: 'TBD' is mentioned on line 711, but not defined Summary: 1 error (**), 0 flaws (~~), 4 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: September 2, 2010 Nokia Siemens Networks 6 March 1, 2010 8 Additional Data related to a Call for Emergency Call Purposes 9 draft-rosen-ecrit-additional-data-00.txt 11 Abstract 13 When an emergency call is sent to a PSAP, the device that sends it, 14 as well as any service provider in the path of the call may have 15 information about the call which the PSAP may be able to use. This 16 document describes an XML data structure that contains this kind of 17 information in a standardized form. A URI that points to the 18 structure can be included in the SIP signaling with the call. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 2, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Additional Data about a Call . . . . . . . . . . . . . . . . . 5 63 3.1. Data Provided by . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Provided by Company ID . . . . . . . . . . . . . . . . . . 6 65 3.3. Provided by Contact URI . . . . . . . . . . . . . . . . . 6 66 3.4. Provided by Languages(s) supported . . . . . . . . . . . . 7 67 3.5. vCARD of Provided By . . . . . . . . . . . . . . . . . . . 7 68 3.6. Service Environment . . . . . . . . . . . . . . . . . . . 8 69 3.7. Service Delivered by Provider to End User . . . . . . . . 8 70 3.8. Device Classification . . . . . . . . . . . . . . . . . . 10 71 3.9. Device Manufacturer . . . . . . . . . . . . . . . . . . . 11 72 3.10. Device Model Number . . . . . . . . . . . . . . . . . . . 12 73 3.11. Unique Device Identifier . . . . . . . . . . . . . . . . . 12 74 3.12. Type of Device Identifier . . . . . . . . . . . . . . . . 13 75 3.13. Device/service specific additional data structure . . . . 14 76 3.14. Telephone Number Privacy Indicator . . . . . . . . . . . . 15 77 3.15. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 16 78 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 6.1. 'emergencyCallData' Purpose Parameter Value . . . . . . . 20 82 6.2. URN Sub-Namespace Registration for 83 urn:ietf:params:xml:ns:additional-data . . . . . . . . . . 20 84 6.3. Additional Data Schema Registration . . . . . . . . . . . 21 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 86 8. Normative References . . . . . . . . . . . . . . . . . . . . . 23 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 When an emergency call is sent to a PSAP, there is a rich set of data 92 in the headers with the call, but the device, as well as any other 93 service provider in the path may have even more information that 94 would be useful to a PSAP. This information may include the identity 95 and contact information of the service provider, subscriber identity 96 and contact information, the type of service the service provider 97 provides, what kind of device the user has, etc. Some kinds of 98 devices or services have device or service dependent data. For 99 example, a car telematics system or service may have crash 100 information. A medical monitoring device may have sensor data. 101 While the details of the information may vary by device or service, 102 there needs to be a common way to send such data to a PSAP. 104 For the call takers this will enable more intelligent decision making 105 and therefore better response in case of an emergency. A pre- 106 requisite is to offer the technical capabilities to let call takers 107 to gain access to this information stored elsewhere (granted that 108 they have authorization to access it). 110 This document focuses on the data that can be obtained about a call 111 and an existing SIP header field, the Call-Info header, is used for 112 this purpose by defining a new token, namely 'emergencyCallData' 113 carried in the "purpose" parameter. If the "purpose" parameter set 114 to 'emergencyCallData' then the Call-Info contains a HTTPS URL that 115 points to an XML data structure with information about the call. The 116 initial XML data structure was defined by a working group within the 117 National Emergency Number Association (NENA) and is included in this 118 document. 120 The data structure contains an element which itself is a URI that has 121 device or service dependent data. Thus the common Additional Data 122 about a Call defined by this document contains a 'hook', in the form 123 of a URI for a device or service dependent data structure. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. Additional Data about a Call 133 The Additional Data about a Call is information specific to a call 134 known by the device that sends it or a service provider in the path 135 of a call. The Additional Data about a Call is an XML data 136 structure. An HTTPS URI to that structure may be inserted in a SIP 137 INVITE or MESSAGE transaction with a Call-Info header containing a 138 purpose of "emergenyCallData". The data, which must conform to the 139 schema in Section 4 may be retrieved with an HTTPS Get. HTTPS MUST be 140 used. 142 More than one Call-Info header with an emergencyCallData purpose can 143 be expected. The device may insert one, and any intermediary service 144 provider may insert its own. When there are multiple intermediaries 145 each intermediary may each insert one. For example, a device may 146 provide one, a telematics service provider may provide one and the 147 mobile carrier handling the call may provide one. 149 3.1. Data Provided by 151 Data Element: Data Provided by 153 Use: Required 155 XML Element: 157 Description: This is a plain language string suitable for displaying 158 the name of the service provider that created the additional data 159 structure. If the device created the structure the value is 160 identical to the contact header in the SIP Invite. This data is 161 required and should reflect the contact information of the owner 162 of the device. 164 Reason for Need: Inform the call taker about the identity of the 165 entity providing the additional call data structure. 167 How Used by Call Taker: Allows the call taker to interpret the data 168 in this structure. The source of the information often influences 169 how the information is used, believed or verified. 171 3.2. Provided by Company ID 173 Data Element: Provided by Company ID 175 Use: Conditional 177 XML Element: 179 Description: A jurisdiction specific code for the provider shown in 180 the element that created the structure of the 181 call. NOTE: In the US, the NENA Company ID must appear here. 182 Additional information may be found at 183 http://www.nena.org/nena-company-id. The NENA Company ID shall be 184 in the form of any URI for example: urn:nena:companyid:. This data is required unless the additional data 186 structure is provided by the device. 188 Reason for Need: Inform the call taker about the identity of the 189 entity providing the additional call data structure. 191 How Used by Call Taker: Where jurisdictions have lists of providers 192 the Provider Company ID can lead to a wealth of information 193 associated with the code. 195 3.3. Provided by Contact URI 197 Data Element: Provided by Contact URI 199 Use: Required 201 XML Element: 203 Description: For a Service Provider the contact should be a 24x7 204 contact number. If provided by an entity without a 24X7, they 205 must provide the provided by contact information. This must be a 206 SIP URI. If a telephone number is the contact address it should 207 be provided in the form of 208 sip:telephonenumber@serviceprovider:user=phone. If the call is 209 from a device, this data is required and should reflect the 210 contact information of the owner of the device. 212 Reason for Need: Additional data providers may need to be contacted 213 for error or other unusual circumstances. 215 How Used by Call Taker: To contact the supplier of the additional 216 data provider structure. 218 3.4. Provided by Languages(s) supported 220 Data Element: Provided by Language(s) supported 222 Use: Conditional 224 XML Element: 226 Description: Provided by's alpha 2-character code as defined in ISO 227 639-1:2002 228 (http://www.iso.org/iso/catalogue_detail?csnumber=22109) Codes for 229 the representation of names of languages -- Part 1: Alpha-2 code 230 Multiple instances of this element may occur. Order is 231 significant; preferred language should appear first. This data is 232 required unless the message is from a data only device. 234 Reason for Need: Information needed to determine if 9-1-1 Authority 235 can communicate with the Service Provider or if language line will 236 be needed. 238 How Used by Call Taker: If call taker cannot speak language(s) 239 supported by the Service Provider, language line will need to be 240 added in to conversation. 242 3.5. vCARD of Provided By 244 Data Element: vCARD of Provided By 246 Use: Optional 248 XML Element: 249 Description: There are many fields in the vCARD. The creator of the 250 data structure is encouraged to provide as much information as 251 they have available. A minimum of subscriber provided by's name, 252 address and contact number should be provided. 254 Reason for Need: Information needed to determine additional contact 255 information. 257 How Used by Call Taker: Assists call taker by providing additional 258 contact information that may not be included in the SIP invite or 259 the PIDF-LO. Can display a picture of the caller to the call 260 taker. 262 3.6. Service Environment 264 Data Element: Service Environment 266 Use: Required 268 XML Element: 270 Description: This defines if the call service type is a Business or 271 Residence caller. Currently, the only valid entries are Business 272 or Residence. 274 Reason for Need: To assist in determining equipment and manpower 275 requirements. 277 How Used by Call Taker: Information may be used to determine 278 equipment and manpower requirements for emergency responders. 280 3.7. Service Delivered by Provider to End User 282 Data Element: Service Delivered by Provider to End User 284 Use: Required 285 XML Element: 287 Description: This defines the type of service the end user has 288 subscribed to. The implied mobility of this service can not be 289 relied upon. A registry will reflect the following valid entries: 291 * Mobile Telephone Service: Includes Satellite, CDMA, GSM, Wi-Fi, 292 WiMAX, LTE (Long Term Evolution) 294 * Fixed Public Pay/Coin telephones: Any coin or credit card 295 operated device. 297 * One way outbound service 299 * Inmate call/service 301 * Soft dialtone/quick service/warm disconnect/suspended 303 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 304 key systems, Shared Tenant Service. 306 * Sensor, unattended: Includes devices that generate DATA ONLY. 307 This is one-way information exchange and there will be no other 308 form of communication. 310 * Sensor, attended: Includes devices that are supported by a 311 monitoring service provider or automatically open a two-way 312 communication path. 314 * Wireline: Plain Old Telephone Service (POTS). 316 * VoIP Telephone Service: A type of service that offers 317 communication over internet protocol, such as Fixed, Nomadic, 318 Mobile, Unknown 320 Reason for Need: Knowing the type of service may assist the PSAP 321 with the handling of the call. 323 How Used by Call Taker: Calltaker may be able to determine if the 324 caller is stationary or mobile and if they will have voice 325 communications with the caller or is it a data only event. 327 3.8. Device Classification 329 Data Element: Device Classification 331 Use: Optional 333 XML Element: 335 Description: If the device provides the data structure, the device 336 information should be provided. If the Service Provider provides 337 the structure and it knows what the device is, the Service 338 Provider should provide the device information. Often the carrier 339 does not know what the device is. It is possible to receive 2 340 data structures, one created by the device and one created by the 341 Service Provider. Information about the device, not how it is 342 being used. This data element defines the kind of device making 343 the emergency call. A registry will reflect the following valid 344 entries: 346 * Cordless handset 348 * Fixed phone 350 * Mobile handset 352 * ATA - analog terminal adapter 354 * Satellite phone 356 * Stationary computing device (alarm system, data sensor) 358 * Guardian devices 360 * Desktop PC 362 * Laptop computing device 364 * Tablet computing device 366 * Alarm system 368 * Data sensor 370 * Personal beacons (spot) 371 * Auto telematics (indicates VEDS data set) 373 * Trucking telematics 375 * Farm equipment telematics 377 * Marine telematics 379 * PDA (personal digital assistant) 381 * PND (personal navigation device) 383 * Smart phone 385 * Internet tablet 387 * Gaming console 389 * Video phone 391 * Other text device 393 * Not Available 395 Reason for Need: The device classification describes the capability 396 of the calling device. For example, does the device require human 397 intervention to initiate a call or is this call the result of 398 programmed instructions. Does the calling device have the ability 399 to rebid for location or condition changes? Is this device 400 interactive or a one-way reporting device? 402 How Used by Call Taker: May assist with location of caller. For 403 example, a cordless handset may be outside or next door. May 404 provide calltaker some context about the caller. 406 3.9. Device Manufacturer 408 Data Element: Device Manufacturer 410 Use: Optional 411 XML Element: 413 Description: Manufacturer is electronically stored on the device. 414 Different devices may use different conventions to provide their 415 information. We need to know what it represents, so a registry is 416 in order. Need to be able to standardize as much as possible with 417 a uniform naming convention. A registry will reflect the valid 418 entries. 420 Reason for Need: Used by PSAP management for post-mortem 421 investigation/resolution. 423 How Used by Call Taker: Probably not used by calltaker, but by PSAP 424 management. 426 3.10. Device Model Number 428 Data Element: Device Model Number 430 Use: Optional 432 XML Element: 434 Description: Model number is electronically stored on the device. 436 Reason for Need: Used by PSAP management for after action 437 investigation/resolution. 439 How Used by Call Taker: Probably not used by calltaker, but by PSAP 440 management. 442 3.11. Unique Device Identifier 444 Data Element: Unique Device Identifier 446 Use: Optional 447 XML Element: 449 Description: Characters that identify the specific device making the 450 call or creating an event. 452 Reason for Need: May be needed when trying to obtain a subpoena to 453 obtain customer information in instances where location info did 454 not display or someone is making false emergency calls. May also 455 be used when working with safe houses that are using non- 456 initialized phones. 458 How Used by Call Taker: Probably not used by calltaker they would 459 need to refer to management for investigation. 461 3.12. Type of Device Identifier 463 Data Element: Type of Device Identifier 465 Use: Optional 467 XML Element: 469 Description: Identifies the type of device identifier being 470 generated in the unique device identifier data element. A 471 registry will reflect the following valid entries: 473 * MEID (CDMA) 475 * ESN (Electronic Serial Number - superseded by MEID) 477 * MAC (Media Access Control) Address - any IEEE device with an 478 Ethernet, Wi-Fi connection 480 * WiMAX has a device certificate 482 * IMEI (International Mobile Equipment Identifier - GSM) 484 * Unique Device Identifier (Unique identifier for medical 485 devices) 487 * RFID (Radio Frequency Identification) 488 * Sensors (types to be identified in a future document version) 490 * Manufacturer Serial Number 492 Reason for Need: Calls from uninitiated devices would give an 493 identifier that could be associated with erroneous calls --- use 494 the number to identify what type of capabilities there are. Could 495 also use this information to block specific types of calls. 497 How Used by Call Taker: Additional information that may be used to 498 assist with call handling. 500 3.13. Device/service specific additional data structure 502 Data Element: Device/service specific additional data structure 504 Use: Optional 506 XML Element: 508 Description: A URI representing additional data whose schema is 509 specific to the device or service which created it. An example is 510 the VEDs structure for a vehicle telematics device. The structure 511 can be referenced via URI and used in the policy routing function 512 business rules/policies or for access by call takers or 513 responders. Non-NENA XML schemas must be registered. Some 514 possible sources are: 516 * NPAC 518 * Hazmat International Association of Fire Chiefs 520 * DHS/EPA E-Plan for HazMat 522 * NFPA - National Fire Protection Association 524 * National Alliance for Public Safety GIS (NA-PSG) 526 * US DOT Pipeline and Hazardous Materials Safety Administration 527 (PHMSA) examples of additional data. 529 * Fire Service Data Model 530 * IEEE 1512 - USDOT Model for traffic incidents 532 * Smart Building (NIST) 534 * VEDS 536 Different data may be created by each classification; i.e., 537 telematics creates VEDS data set - can be different types of data 538 depending on device. May want to describe type of data for each 539 device. 541 Reason for Need: This data element will allow for identification of 542 externally defined schemas, which may have additional data that 543 will assist in emergency response. 545 How Used by Call Taker: This data element will allow the end user 546 (calltaker or first responder) to know what type of additional 547 data may be available to aid in providing the needed emergency 548 services. 550 3.14. Telephone Number Privacy Indicator 552 Data Element: Telephone Number Privacy Indicator 554 Use: Required 556 XML Element: 558 Description: Some State regulations require that Non-Published 559 subscriber name remains private to all including 9-1-1. Where 560 this regulation is in place, the end user's name must be overlaid 561 with blanks or the verbiage, "Non-Published Number." 563 Reason for Need: Some State regulations require that Non-Published 564 subscriber name remains private to all including emergency calls. 565 Where this regulation is in place, the end user's name must be 566 overlaid with blanks or the verbiage, "Non-Published Number". 568 How Used by Call Taker: This is not beneficial to PSAPs; however, 569 they must follow state regulations. This indicator will allow for 570 coding that overlays the non-published subscriber name with the 571 verbiage "Non-Published Number." 573 3.15. vCARD for Subscriber's Data 575 Data Element: vCARD for Subscriber's Data 577 Use: Required 579 XML Element: 581 Description: Information known by the Service Provider about the 582 subscriber; i.e., Name, Address, Calling Party Number, Main 583 Telephone Number and any other data. If the subscriber is an 584 enterprise, this is the vCARD of the enterprise and the Company 585 Name is used not the Name of the Caller. The telephone number is 586 the main telephone number at the location of the call. The 587 address should be where the call is originating from. 589 Reason for Need: Critical information required for proper call 590 handling and dispatching. 592 How Used by Call Taker: Critical information required for proper 593 call handling and dispatching. 595 4. XML Schema 597 598 604 605 606 607 608 610 611 612 613 614 615 616 617 618 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 643 644 645 646 648 Figure 1: XML Schema 650 5. Security Considerations 652 The information in this data structure will usually be considered 653 private. HTTPS is specified to require the provider of the 654 information to validate the credentials of the requester. While the 655 creation of a PKI that has global scope may be difficult, the 656 alternatives to creating devices and services that can provide 657 critical information securely are more daunting. 659 The Call-info header with purpose='emergencyCallData' MUST only be 660 sent on an emergency call, which can be ascertained by the presence 661 of an emergency service urn in a Route header of a SIP message. 663 665 667 670 6. IANA Considerations 672 6.1. 'emergencyCallData' Purpose Parameter Value 674 This document defines the 'emergencyCallData' value for the "purpose" 675 parameter of the Call-Info header field. A reference to this RFC (in 676 double brackets) has been added to the existing "purpose" Call-Info 677 parameter entry in the SIP Parameters registry, which currently looks 678 as follows: 680 Predefined 681 Header Field Parameter Name Values Reference 682 ------------- -------------- --------- --------- 683 Call-Info purpose Yes [RFC3261][RFC5367] 685 6.2. URN Sub-Namespace Registration for 686 urn:ietf:params:xml:ns:additional-data 688 This section registers a new XML namespace, as per the guidelines in 689 [RFC3688]. 691 URI: urn:ietf:params:xml:ns:additional-data 693 Registrant Contact: IETF, ECRIT working group, , as 694 delegated by the IESG . 696 XML: 698 BEGIN 699 700 702 703 704 706 Additional Data Namespace 707 708 709

Namespace for Additional Data

710

urn:ietf:params:xml:ns:additional-data

711

See [TBD].

712 713 714 END 716 6.3. Additional Data Schema Registration 718 This specification registers a schema, as per the guidelines in 719 [RFC3688]. 721 URI: urn:ietf:params:xml:schema:additional-data 723 Registrant Contact: IETF, ECRIT Working Group (geopriv@ietf.org), 724 as delegated by the IESG (iesg@ietf.org). 726 XML: The XML can be found as the sole content of Section 4. 728 7. Acknowledgments 730 The authors would like to thank the following persons for their work 731 in the NENA Data Technical Committee: Delaine Arnold (Data Technical 732 Committee Chair), Marc Berryman, Erica Aubut (Data Technical 733 Committee Vice-Chair), Susan Sherwood, Ric Atkins, Patty Bluhm, 734 Eileen Boroski, David Connel, Maryls Davis, Paul-David de la Rosby, 735 Gordon Chinander, David Froneberger, Marilyn Haroutunian, Roger 736 Hixson, Rick Jones, Roger Marshall, Tom Muehleisen, Ira Pyles, Carl 737 Reed, Susan Seet, and Skip Walls. The authors would also like to 738 thank Tom Breen, Technical Committee Chair/Liaison; Busam, Technical 739 Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee 740 Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison; 741 Roger Hixson, Technical Director; and Rick Jones, Operations Issues 742 Director for their support and assistance. 744 8. Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 750 January 2004. 752 Authors' Addresses 754 Brian Rosen 755 NeuStar 756 470 Conrad Dr. 757 Mars, PA 16046 758 US 760 Phone: +1 724 382 1051 761 Email: br@brianrosen.net 763 Hannes Tschofenig 764 Nokia Siemens Networks 765 Linnoitustie 6 766 Espoo 02600 767 Finland 769 Phone: +358 (50) 4871445 770 Email: Hannes.Tschofenig@gmx.net 771 URI: http://www.tschofenig.priv.at