idnits 2.17.1 draft-ietf-ecrit-additional-data-01.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-ecrit-additional-data-00', but the file name used is 'draft-ietf-ecrit-additional-data-01' 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: There is much private data in this information. Local regulations may govern what data must be provided in emergency calls, but in general, the emergency call system is often aided by the kinds of information described in this document. There is a tradeoff between the privacy considerations and the utility of the data. Certainly, if the data cannot be protected, due to failure of the TLS mechanisms described here, data not required by regulation SHOULD not be sent. -- The document date (July 12, 2011) is 4644 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 753, but not defined == Missing Reference: 'RFC5367' is mentioned on line 753, but not defined == Missing Reference: 'TBD' is mentioned on line 792, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 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: January 13, 2012 Nokia Siemens Networks 6 July 12, 2011 8 Additional Data related to an Emergency Call 9 draft-ietf-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, or access 15 network may have information about the call which the PSAP may be 16 able to use. This document describes an XML data structure that 17 contains this kind of information in a standardized form. A URI that 18 points to the structure can be included in the SIP signaling with the 19 call, or the data may be included in the body of a SIP message. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 13, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Additional Data about a Call . . . . . . . . . . . . . . . . . 5 58 3.1. Data Provider Information Block . . . . . . . . . . . . . 5 59 3.1.1. Data Provider String . . . . . . . . . . . . . . . . . 6 60 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . . 6 61 3.1.3. Data Provider Contact URI . . . . . . . . . . . . . . 7 62 3.1.4. Data Provider Languages(s) supported . . . . . . . . . 7 63 3.1.5. vCARD of Data Provider . . . . . . . . . . . . . . . . 8 64 3.2. Service Information . . . . . . . . . . . . . . . . . . . 9 65 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 9 66 3.2.2. Service Delivered by Provider to End User . . . . . . 9 67 3.3. Device Information . . . . . . . . . . . . . . . . . . . . 10 68 3.3.1. Device Classification . . . . . . . . . . . . . . . . 10 69 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 12 70 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 13 71 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . . 13 72 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 14 73 3.3.6. Device/service specific additional data structure . . 15 74 3.4. Regulatory Information . . . . . . . . . . . . . . . . . . 16 75 3.4.1. Telephone Number Privacy Indicator . . . . . . . . . . 16 76 3.5. Owner/Subscriber Information . . . . . . . . . . . . . . . 17 77 3.5.1. vCARD for Subscriber's Data . . . . . . . . . . . . . 17 78 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 6.1. 'emergencyCallData' Purpose Parameter Value . . . . . . . 21 82 6.2. provided-by registry entry . . . . . . . . . . . . . . . . 21 83 6.3. MIME registrations . . . . . . . . . . . . . . . . . . . . 21 84 6.4. URN Sub-Namespace Registration for 85 urn:ietf:params:xml:ns:additional-data . . . . . . . . . . 21 86 6.5. Additional Data Schema Registration . . . . . . . . . . . 22 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 88 8. Normative References . . . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 When an emergency call is sent to a PSAP, there is a rich set of data 94 in the headers with the call, but the device, as well as any other 95 service provider in the path may have even more information that 96 would be useful to a PSAP. This information may include the identity 97 and contact information of the service provider, subscriber identity 98 and contact information, the type of service the service provider 99 provides, what kind of device the user has, etc. Some kinds of 100 devices or services have device or service dependent data. For 101 example, a car telematics system or service may have crash 102 information. A medical monitoring device may have sensor data. 103 While the details of the information may vary by device or service, 104 there needs to be a common way to send such data to a PSAP. 106 For the call takers this will enable more intelligent decision making 107 and therefore better response in case of an emergency. A pre- 108 requisite is to offer the technical capabilities to let call takers 109 to gain access to this information stored elsewhere (granted that 110 they have authorization to access it). 112 This document focuses on the data that can be obtained about a call 113 and a mechanism for transporting it in an existing SIP header field, 114 the Call-Info header. For this purpose a new token, namely 115 'emergencyCallData' is defined to be carried in the "purpose" 116 parameter. If the "purpose" parameter set to 'emergencyCallData' 117 then the Call-Info contains a HTTPS URL that points to a data 118 structure with information about the call or a CID that allows the 119 data structure to be placed in the body of the message. In addition, 120 this document describes a "provided-by" namespace per [RFC4119] for 121 passing information known to the access network 123 The data is defined as a series of "blocks" that represent a class of 124 information. Each of the blocks is a MIME type, and an extensible 125 set of these types constitute the data structure. A registry is 126 defined to list the block types that may be included. 128 The data structure contains an element which itself is a URI that has 129 device or service dependent data. Thus the common Additional Data 130 about a Call defined by this document contains a 'hook', in the form 131 of a URI for a device or service dependent data structure. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Additional Data about a Call 141 The Additional Data about a Call is information specific to a call 142 known by the device that sends it or a service provider in the path 143 of a call or in the access network the call originates in. The 144 Additional Data about a Call is a set of information blocks. Each 145 block is a MIME type, and any set of blocks may be included in the 146 set. 148 Three mechanisms are provided to transport the data set. A URI to 149 the data set may be inserted in a SIP INVITE or MESSAGE transaction 150 with a Call-Info header containing a purpose of "emergenyCallData". 151 If the data is provided by reference, it may be retrieved with an 152 HTTPS Get from the URI. The URI MUST specify an HTTPS scheme, and 153 TLS protection for the data MUST be negotiated. 155 The data may be supplied by value in a SIP INVITE or MESSAGE message. 156 In this case, Content Indirection [RFC2392] is used, with the CID URL 157 pointing to the body of the message. 159 More than one Call-Info header with an emergencyCallData purpose can 160 be expected. The device may insert one, and any intermediary service 161 provider may insert its own. When there are multiple intermediaries 162 each intermediary may each insert one. For example, a device may 163 provide one, a telematics service provider may provide one and the 164 mobile carrier handling the call may provide one. 166 The access network may supply Additional Data about a Call. For this 167 purpose, this document defines a namespace and adds the namespace to 168 the "provided-by" registry defined by [RFC4119] 170 Additional Data about a Call is defined as a series of blocks. Each 171 block is defined as a mime type, with an XML data structure. MIME- 172 multipart is used to enclose the set of blocks constituting the 173 information provided by an entity (service provider or device). The 174 sections below define the blocks. 176 3.1. Data Provider Information Block 178 This block is intended to be provided by any service provider in the 179 path of the call or the access network provider. It includes 180 identification and contact information. This block SHOULD be 181 provided for every service provider in the path of the call, and the 182 access network provider. Devices also use this block to provide 183 identifying information. The MIME type is "addDataProviderInfo". 185 3.1.1. Data Provider String 187 Data Element: Data Provider String 189 Use: Required 191 XML Element: 193 Description: This is a plain language string suitable for displaying 194 the name of the service provider that created the additional data 195 structure. If the device created the structure the value is 196 identical to the contact header in the SIP Invite. This data is 197 required and should reflect the contact information of the owner 198 of the device. 200 Reason for Need: Inform the call taker about the identity of the 201 entity providing the additional call data structure. 203 How Used by Call Taker: Allows the call taker to interpret the data 204 in this structure. The source of the information often influences 205 how the information is used, believed or verified. 207 3.1.2. Data Provider ID 209 Data Element: Data Provider ID 211 Use: Conditional 213 XML Element: 215 Description: A jurisdiction specific code for the provider shown in 216 the element that created the structure of the 217 call. NOTE: In the US, the NENA Company ID must appear here. 218 Additional information may be found at 219 http://www.nena.org/nena-company-id. The NENA Company ID shall be 220 in the form of any URI for example: urn:nena:companyid:. This data is required unless the additional data 222 structure is provided by the device. 224 Reason for Need: Inform the call taker about the identity of the 225 entity providing the additional call data structure. 227 How Used by Call Taker: Where jurisdictions have lists of providers 228 the Provider Company ID can lead to a wealth of information 229 associated with the code. 231 3.1.3. Data Provider Contact URI 233 Data Element: Data Provider Contact URI 235 Use: Required 237 XML Element: 239 Description: For a Service Provider the contact SHOULD be a 24x7 240 contact URI. This must be a SIP URI. If a telephone number is 241 the contact address it should be provided in the form of 242 sip:telephonenumber@serviceprovider:user=phone. If the call is 243 from a device, this data is required and should reflect the 244 contact information of the owner of the device. 246 Reason for Need: Additional data providers may need to be contacted 247 for error or other unusual circumstances. 249 How Used by Call Taker: To contact the supplier of the additional 250 data provider structure. 252 3.1.4. Data Provider Languages(s) supported 254 Data Element: Data Provider Language(s) supported 256 Use: Conditional 258 XML Element: 259 Description: Provided by's alpha 2-character code as defined in ISO 260 639-1:2002 261 (http://www.iso.org/iso/catalogue_detail?csnumber=22109) Codes for 262 the representation of names of languages -- Part 1: Alpha-2 code 263 Multiple instances of this element may occur. Order is 264 significant; preferred language should appear first. This data is 265 required unless the message is from a data only device. 267 Reason for Need: Information needed to determine if 9-1-1 Authority 268 can communicate with the Service Provider or if language line will 269 be needed. 271 How Used by Call Taker: If call taker cannot speak language(s) 272 supported by the Service Provider, language line will need to be 273 added in to conversation. 275 3.1.5. vCARD of Data Provider 277 Data Element: vCARD of Data Provider 279 Use: Optional 281 XML Element: 283 Description: There are many fields in the vCARD. The creator of the 284 data structure is encouraged to provide as much information as 285 they have available. A minimum of subscriber provided by's name, 286 address and general contact number should be provided. 288 Reason for Need: Information needed to determine additional contact 289 information. 291 How Used by Call Taker: Assists call taker by providing additional 292 contact information that may not be included in the SIP invite or 293 the PIDF-LO. Can display a picture of the caller to the call 294 taker. 296 3.2. Service Information 298 This block describes the service that the service provider provides 299 to the caller. It SHOULD be included by all SPs in the path of the 300 call. The mime type is "addCallSvcInfo" 302 3.2.1. Service Environment 304 Data Element: Service Environment 306 Use: Required 308 XML Element: 310 Description: This defines if the call service type is a Business or 311 Residence caller. Currently, the only valid entries are Business 312 or Residence. 314 Reason for Need: To assist in determining equipment and manpower 315 requirements. 317 How Used by Call Taker: Information may be used to determine 318 equipment and manpower requirements for emergency responders. 320 3.2.2. Service Delivered by Provider to End User 322 Data Element: Service Delivered by Provider to End User 324 Use: Required 326 XML Element: 328 Description: This defines the type of service the end user has 329 subscribed to. The implied mobility of this service can not be 330 relied upon. A registry will reflect the following valid entries: 332 * Mobile Telephone Service: Includes Satellite, CDMA, GSM, Wi-Fi, 333 WiMAX, LTE (Long Term Evolution) 335 * Fixed Public Pay/Coin telephones: Any coin or credit card 336 operated device. 338 * One way outbound service 340 * Inmate call/service 342 * Soft dialtone/quick service/warm disconnect/suspended 344 * Multi-line telephone system (MLTS): Includes all PBX, Centrex, 345 key systems, Shared Tenant Service. 347 * Sensor, unattended: Includes devices that generate DATA ONLY. 348 This is one-way information exchange and there will be no other 349 form of communication. 351 * Sensor, attended: Includes devices that are supported by a 352 monitoring service provider or automatically open a two-way 353 communication path. 355 * Wireline: Plain Old Telephone Service (POTS). 357 * VoIP Telephone Service: A type of service that offers 358 communication over internet protocol, such as Fixed, Nomadic, 359 Mobile, Unknown 361 Reason for Need: Knowing the type of service may assist the PSAP 362 with the handling of the call. 364 How Used by Call Taker: Calltaker may be able to determine if the 365 caller is stationary or mobile and if they will have voice 366 communications with the caller or is it a data only event. 368 3.3. Device Information 370 This block provides information about the device used to place the 371 call. It should be provided by any service provider that knows what 372 device is being used, and by the device itself. The mime type is 373 "addDataDevInfo". 375 3.3.1. Device Classification 376 Data Element: Device Classification 378 Use: Optional 380 XML Element: 382 Description: If the device provides the data structure, the device 383 information should be provided. If the Service Provider provides 384 the structure and it knows what the device is, the Service 385 Provider should provide the device information. Often the carrier 386 does not know what the device is. It is possible to receive 2 387 data structures, one created by the device and one created by the 388 Service Provider. Information about the device, not how it is 389 being used. This data element defines the kind of device making 390 the emergency call. A registry will reflect the following valid 391 entries: 393 * Cordless handset 395 * Fixed phone 397 * Mobile handset 399 * ATA - analog terminal adapter 401 * Satellite phone 403 * Stationary computing device (alarm system, data sensor) 405 * Guardian devices 407 * Desktop PC 409 * Laptop computing device 411 * Tablet computing device 413 * Alarm system 415 * Data sensor 417 * Personal beacons (spot) 419 * Auto telematics (indicates VEDS data set) 420 * Trucking telematics 422 * Farm equipment telematics 424 * Marine telematics 426 * PDA (personal digital assistant) 428 * PND (personal navigation device) 430 * Smart phone 432 * Internet tablet 434 * Gaming console 436 * Video phone 438 * Other text device 440 * Not Available 442 Reason for Need: The device classification describes the capability 443 of the calling device. For example, does the device require human 444 intervention to initiate a call or is this call the result of 445 programmed instructions. Does the calling device have the ability 446 to rebid for location or condition changes? Is this device 447 interactive or a one-way reporting device? 449 How Used by Call Taker: May assist with location of caller. For 450 example, a cordless handset may be outside or next door. May 451 provide calltaker some context about the caller. 453 3.3.2. Device Manufacturer 455 Data Element: Device Manufacturer 457 Use: Optional 459 XML Element: 460 Description: Manufacturer is electronically stored on the device. 461 Different devices may use different conventions to provide their 462 information. We need to know what it represents, so a registry is 463 in order. Need to be able to standardize as much as possible with 464 a uniform naming convention. A registry will reflect the valid 465 entries. 467 Reason for Need: Used by PSAP management for post-mortem 468 investigation/resolution. 470 How Used by Call Taker: Probably not used by calltaker, but by PSAP 471 management. 473 3.3.3. Device Model Number 475 Data Element: Device Model Number 477 Use: Optional 479 XML Element: 481 Description: Model number is electronically stored on the device. 483 Reason for Need: Used by PSAP management for after action 484 investigation/resolution. 486 How Used by Call Taker: Probably not used by calltaker, but by PSAP 487 management. 489 3.3.4. Unique Device Identifier 491 Data Element: Unique Device Identifier 493 Use: Optional 495 XML Element: 496 Description: Characters that identify the specific device making the 497 call or creating an event. 499 Reason for Need: May be needed when trying to obtain a subpoena to 500 obtain customer information in instances where location info did 501 not display or someone is making false emergency calls. May also 502 be used when working with safe houses that are using non- 503 initialized phones. 505 How Used by Call Taker: Probably not used by calltaker they would 506 need to refer to management for investigation. 508 3.3.5. Type of Device Identifier 510 Data Element: Type of Device Identifier 512 Use: Optional 514 XML Element: 516 Description: Identifies the type of device identifier being 517 generated in the unique device identifier data element. A 518 registry will reflect the following valid entries: 520 * MEID (CDMA) 522 * ESN (Electronic Serial Number - superseded by MEID) 524 * MAC (Media Access Control) Address - any IEEE device with an 525 Ethernet, Wi-Fi connection 527 * WiMAX has a device certificate 529 * IMEI (International Mobile Equipment Identifier - GSM) 531 * Unique Device Identifier (Unique identifier for medical 532 devices) 534 * RFID (Radio Frequency Identification) 536 * Sensors (types to be identified in a future document version) 537 * Manufacturer Serial Number 539 Reason for Need: Calls from uninitiated devices would give an 540 identifier that could be associated with erroneous calls --- use 541 the number to identify what type of capabilities there are. Could 542 also use this information to block specific types of calls. 544 How Used by Call Taker: Additional information that may be used to 545 assist with call handling. 547 3.3.6. Device/service specific additional data structure 549 Data Element: Device/service specific additional data structure 551 Use: Optional 553 XML Element: 555 Description: A URI representing additional data whose schema is 556 specific to the device or service which created it. An example is 557 the VEDs structure for a vehicle telematics device. The structure 558 can be referenced via URI and used in the policy routing function 559 business rules/policies or for access by call takers or 560 responders. Non-NENA XML schemas must be registered. Some 561 possible sources are: 563 * NPAC 565 * Hazmat International Association of Fire Chiefs 567 * DHS/EPA E-Plan for HazMat 569 * NFPA - National Fire Protection Association 571 * National Alliance for Public Safety GIS (NA-PSG) 573 * US DOT Pipeline and Hazardous Materials Safety Administration 574 (PHMSA) examples of additional data. 576 * Fire Service Data Model 578 * IEEE 1512 - USDOT Model for traffic incidents 579 * Smart Building (NIST) 581 * VEDS 583 Different data may be created by each classification; i.e., 584 telematics creates VEDS data set - can be different types of data 585 depending on device. May want to describe type of data for each 586 device. 588 Reason for Need: This data element will allow for identification of 589 externally defined schemas, which may have additional data that 590 will assist in emergency response. 592 How Used by Call Taker: This data element will allow the end user 593 (calltaker or first responder) to know what type of additional 594 data may be available to aid in providing the needed emergency 595 services. 597 3.4. Regulatory Information 599 In some jurisdictions, handling of emergency calls involves 600 information known by a service provider that must, by regulation, be 601 passed to the emergency system. The mime type is "addCallReg". 603 3.4.1. Telephone Number Privacy Indicator 605 Data Element: Telephone Number Privacy Indicator 607 Use: Required 609 XML Element: 611 Description: Some State regulations require that Non-Published 612 subscriber name remains private to all including 9-1-1. Where 613 this regulation is in place, the end user's name must be overlaid 614 with blanks or the verbiage, "Non-Published Number." 616 Reason for Need: Some State regulations require that Non-Published 617 subscriber name remains private to all including emergency calls. 618 Where this regulation is in place, the end user's name must be 619 overlaid with blanks or the verbiage, "Non-Published Number". 621 How Used by Call Taker: This is not beneficial to PSAPs; however, 622 they must follow state regulations. This indicator will allow for 623 coding that overlays the non-published subscriber name with the 624 verbiage "Non-Published Number." 626 3.5. Owner/Subscriber Information 628 This block describes the owner of the device (if provided by the 629 device) or the subscriber information, if provided by a service 630 provider. The contact location is NOT necessarily the location of 631 the caller or incident, but is rather the nominal contact address. 632 The mime type is "addCallSub". 634 3.5.1. vCARD for Subscriber's Data 636 Data Element: vCARD for Subscriber's Data 638 Use: Required 640 XML Element: 642 Description: Information known by the Service Provider about the 643 subscriber; i.e., Name, Address, Calling Party Number, Main 644 Telephone Number and any other data. If the subscriber is an 645 enterprise, this is the vCARD of the enterprise and the Company 646 Name is used not the Name of the Caller. The telephone number is 647 the main telephone number at the location of the call. The 648 address should be where the call is originating from. 650 Reason for Need: Critical information required for proper call 651 handling and dispatching. 653 How Used by Call Taker: Critical information required for proper 654 call handling and dispatching. 656 4. XML Schema 658 NOTE: This section is not yet updated. 660 661 667 668 669 670 671 673 674 675 676 677 678 679 680 681 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 710 Figure 1: XML Schema 712 5. Security Considerations 714 The information in this data structure will usually be considered 715 private. HTTPS is specified to require the provider of the 716 information to validate the credentials of the requester. While the 717 creation of a PKI that has global scope may be difficult, the 718 alternatives to creating devices and services that can provide 719 critical information securely are more daunting. 721 The Call-info header with purpose='emergencyCallData' MUST only be 722 sent on an emergency call, which can be ascertained by the presence 723 of an emergency service urn in a Route header of a SIP message. 725 727 729 732 There is much private data in this information. Local regulations 733 may govern what data must be provided in emergency calls, but in 734 general, the emergency call system is often aided by the kinds of 735 information described in this document. There is a tradeoff between 736 the privacy considerations and the utility of the data. Certainly, 737 if the data cannot be protected, due to failure of the TLS mechanisms 738 described here, data not required by regulation SHOULD not be sent. 740 6. IANA Considerations 742 6.1. 'emergencyCallData' Purpose Parameter Value 744 This document defines the 'emergencyCallData' value for the "purpose" 745 parameter of the Call-Info header field. A reference to this RFC (in 746 double brackets) has been added to the existing "purpose" Call-Info 747 parameter entry in the SIP Parameters registry, which currently looks 748 as follows: 750 Predefined 751 Header Field Parameter Name Values Reference 752 ------------- -------------- --------- --------- 753 Call-Info purpose Yes [RFC3261][RFC5367] 755 6.2. provided-by registry entry 757 This section registers the namespace specified in ??? in the 758 provided-by registry established by RFC4119. 760 TBD 762 6.3. MIME registrations 764 TBD 766 6.4. URN Sub-Namespace Registration for 767 urn:ietf:params:xml:ns:additional-data 769 This section registers a new XML namespace, as per the guidelines in 770 [RFC3688]. 772 URI: urn:ietf:params:xml:ns:additional-data 774 Registrant Contact: IETF, ECRIT working group, , as 775 delegated by the IESG . 777 XML: 779 BEGIN 780 781 783 784 785 787 Additional Data Namespace 788 789 790

Namespace for Additional Data

791

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

792

See [TBD].

793 794 795 END 797 6.5. Additional Data Schema Registration 799 This specification registers a schema, as per the guidelines in 800 [RFC3688]. 802 URI: urn:ietf:params:xml:schema:additional-data 804 Registrant Contact: IETF, ECRIT Working Group (geopriv@ietf.org), 805 as delegated by the IESG (iesg@ietf.org). 807 XML: The XML can be found as the sole content of Section 4. 809 7. Acknowledgments 811 The authors would like to thank the following persons for their work 812 in the NENA Data Technical Committee: Delaine Arnold (Data Technical 813 Committee Chair), Marc Berryman, Erica Aubut (Data Technical 814 Committee Vice-Chair), Susan Sherwood, Ric Atkins, Patty Bluhm, 815 Eileen Boroski, David Connel, Maryls Davis, Paul-David de la Rosby, 816 Gordon Chinander, David Froneberger, Marilyn Haroutunian, Roger 817 Hixson, Rick Jones, Roger Marshall, Tom Muehleisen, Ira Pyles, Carl 818 Reed, Susan Seet, and Skip Walls. The authors would also like to 819 thank Tom Breen, Technical Committee Chair/Liaison; Busam, Technical 820 Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee 821 Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison; 822 Roger Hixson, Technical Director; and Rick Jones, Operations Issues 823 Director for their support and assistance. 825 8. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, March 1997. 830 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 831 Locators", RFC 2392, August 1998. 833 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 834 January 2004. 836 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 837 Format", RFC 4119, December 2005. 839 Authors' Addresses 841 Brian Rosen 842 NeuStar 843 470 Conrad Dr. 844 Mars, PA 16046 845 US 847 Phone: +1 724 382 1051 848 Email: br@brianrosen.net 850 Hannes Tschofenig 851 Nokia Siemens Networks 852 Linnoitustie 6 853 Espoo 02600 854 Finland 856 Phone: +358 (50) 4871445 857 Email: Hannes.Tschofenig@gmx.net 858 URI: http://www.tschofenig.priv.at