draft-ietf-ecrit-additional-data-32.txt   draft-ietf-ecrit-additional-data-33.txt 
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: January 5, 2016 NeuStar Expires: January 20, 2016 NeuStar
H. Tschofenig H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
July 4, 2015 July 19, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-32.txt draft-ietf-ecrit-additional-data-33.txt
Abstract Abstract
When an emergency call is sent to a Public Safety Answering Point When an emergency call is sent to a Public Safety Answering Point
(PSAP), the originating device, the access network provider to which (PSAP), the originating device, the access network provider to which
the device is connected, and all service providers in the path of the the device is connected, and all service providers in the path of the
call have information about the call, the caller or the location call have information about the call, the caller or the location
which is helpful for the PSAP to have in handling the emergency. which is helpful for the PSAP to have in handling the emergency.
This document describes data structures and mechanisms to convey such This document describes data structures and mechanisms to convey such
data to the PSAP. The intent is that every emergency call carry the data to the PSAP. The intent is that every emergency call carry the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2016. This Internet-Draft will expire on January 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Service Mobility Environment . . . . . . . . . . . . 20 4.2.3. Service Mobility Environment . . . . . . . . . . . . 20
4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21
4.3. Device Information . . . . . . . . . . . . . . . . . . . 22 4.3. Device Information . . . . . . . . . . . . . . . . . . . 22
4.3.1. Device Classification . . . . . . . . . . . . . . . . 22 4.3.1. Device Classification . . . . . . . . . . . . . . . . 22
4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23
4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24
4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24
4.3.5. Device/Service-Specific Additional Data Structure . . 25 4.3.5. Device/Service-Specific Additional Data Structure . . 25
4.3.6. Device/Service Specific Additional Data Structure 4.3.6. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 25 Type . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7. Issues with getting new types of data into use . . . 26 4.3.7. Issues with getting new types of data into use . . . 26
4.3.8. Choosing between defining a new type of block or new 4.3.8. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 27 type of device/service specific additional data . . . 27
4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28 4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28
4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28
4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28
4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29
4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 29 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 30
4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32
5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 32 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33
5.1. Transmitting Blocks using the Call-Info Header . . . . . 34 5.1. Transmitting Blocks using the Call-Info Header . . . . . 34
5.2. Transmitting Blocks by Reference using the <provided-by> 5.2. Transmitting Blocks by Reference using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 36 Element . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52 7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52 7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52
7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54 7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54
7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55 7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55
7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 57 7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 57
7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 58 7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 58
7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 59 7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 59
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 63 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 63
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
skipping to change at page 9, line 22 skipping to change at page 9, line 22
network provider if those entities do not add any other blocks. network provider if those entities do not add any other blocks.
Devices SHOULD use this block to provide identifying information. Devices SHOULD use this block to provide identifying information.
The MIME subtype is "application/EmergencyCallData.ProviderInfo+xml". The MIME subtype is "application/EmergencyCallData.ProviderInfo+xml".
An access network provider SHOULD provide this block either by value An access network provider SHOULD provide this block either by value
or by reference in the <provided-by> element of a PIDF-LO or by reference in the <provided-by> element of a PIDF-LO
4.1.1. Data Provider String 4.1.1. Data Provider String
Data Element: Data Provider String Data Element: Data Provider String
Use: Conditional Use: Conditional. Optional for blocks supplied by the originating
device, mandatory otherwise.
XML Element: <DataProviderString> XML Element: <DataProviderString>
Description: This is a plain text string suitable for displaying the Description: This is a plain text string suitable for displaying the
name of the service provider that supplied the data structure. If name of the service provider that supplied the data structure. If
the device creates the structure, it SHOULD use the value of the the device creates the structure, it SHOULD use the value of the
contact header in the SIP INVITE. contact header in the SIP INVITE.
Reason for Need: Inform the call taker of the identity of the entity Reason for Need: Inform the call taker of the identity of the entity
providing the data. providing the data.
skipping to change at page 24, line 45 skipping to change at page 24, line 45
The <TypeOfDeviceID> attribute identifies the type of device The <TypeOfDeviceID> attribute identifies the type of device
identifier. A registry is created in Section 10.1.7 with an identifier. A registry is created in Section 10.1.7 with an
initial set of values shown in Figure 9. initial set of values shown in Figure 9.
Reason for Need: Uniquely identifies the device (or, in the case of Reason for Need: Uniquely identifies the device (or, in the case of
IMSI, a SIM), independent of any signaling identifiers present in IMSI, a SIM), independent of any signaling identifiers present in
the call signaling stream. the call signaling stream.
How Used by Call Taker: Probably not used by the call taker; may be How Used by Call Taker: Probably not used by the call taker; may be
used by PSAP management during an investigation. used by PSAP management during an investigation. (For example, if
a PSAP experiences repeated false/accidental calls and there is no
callback number or it isn't usable, the PSAP may need to try and
track down the device using various means (e.g., contacting
service providers in the area). In the case of handsets without
current service, it may be possible to determine who last had
service. Another example might be a disconnected call where the
call taker believes there is a need for assistance but was not
able to obtain a location or other information).
Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID> Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID>
+--------+------------------------------------------+ +--------+------------------------------------------+
| Token | Description | | Token | Description |
+--------+------------------------------------------+ +--------+------------------------------------------+
| MEID | Mobile Equipment Identifier (CDMA) | | MEID | Mobile Equipment Identifier (CDMA) |
| ESN | Electronic Serial Number (GSM) | | ESN | Electronic Serial Number (GSM) |
| MAC | Media Access Control Address (IEEE) | | MAC | Media Access Control Address (IEEE) |
| WiMAX | Device Certificate Unique ID | | WiMAX | Device Certificate Unique ID |
| IMEI | International Mobile Equipment ID (GSM) | | IMEI | International Mobile Equipment ID (GSM) |
| IMSI | International Mobile Subscriber ID (GSM) | | IMSI | International Mobile Subscriber ID (GSM) |
| UDI | Unique Device Identifier | | UDI | Unique Device Identifier |
skipping to change at page 27, line 10 skipping to change at page 27, line 18
The mechanisms this document describes are meant to encourage The mechanisms this document describes are meant to encourage
development of widely supported, common data formats for classes of development of widely supported, common data formats for classes of
devices. If all manufacturers of a class of device use the same devices. If all manufacturers of a class of device use the same
format, and the data can be shown to improve outcomes, then PSAPs and format, and the data can be shown to improve outcomes, then PSAPs and
responders may be encouraged to upgrade their systems and train their responders may be encouraged to upgrade their systems and train their
staff to use the data. Variations, however well intentioned, are staff to use the data. Variations, however well intentioned, are
unlikely to be supported. unlikely to be supported.
Implementers should consider that data from sensor-based devices in Implementers should consider that data from sensor-based devices in
some cases may not be useful to call takers or PSAPs (and privacy or some cases may not be useful to call takers or PSAPs (and privacy,
other considerations may preclude the PSAP from touching the data), liability, or other considerations might preclude the PSAP from
but may be of use to responders. Each data item provided with the touching the data), but may be of use to responders. Each data item
call in conformance with this document can be accessed by responders provided with the call in conformance with this document can be
or other entities in the emergency services, whether or not the data accessed by responders or other entities in the emergency services,
is accessed by the PSAP. whether or not the data is accessed by the PSAP.
4.3.8. Choosing between defining a new type of block or new type of 4.3.8. Choosing between defining a new type of block or new type of
device/service specific additional data device/service specific additional data
For devices that have device or service specific data, there are two For devices that have device or service specific data, there are two
choices to carry it. A new block can be defined, or the device/ choices to carry it. A new block can be defined, or the device/
service specific additional data URL the DeviceInfo block can be used service specific additional data URL the DeviceInfo block can be used
and a new type for it defined . The data passed would likely be the and a new type for it defined . The data passed would likely be the
same in both cases. Considerations for choosing which mechanism to same in both cases. Considerations for choosing which mechanism to
register under include: register under include:
skipping to change at page 28, line 31 skipping to change at page 28, line 36
4.4. Owner/Subscriber Information 4.4. Owner/Subscriber Information
This block describes the owner of the device (if provided by the This block describes the owner of the device (if provided by the
device) or the subscriber information (if provided by a service device) or the subscriber information (if provided by a service
provider). The contact location is not necessarily the location of provider). The contact location is not necessarily the location of
the caller or incident, but is rather the nominal contact address. the caller or incident, but is rather the nominal contact address.
The MIME type is "application/EmergencyCallData.SubscriberInfo+xml". The MIME type is "application/EmergencyCallData.SubscriberInfo+xml".
In some jurisdictions some or all parts of the subscriber-specific In some jurisdictions some or all parts of the subscriber-specific
information are subject to privacy constraints. These constraints information are subject to privacy constraints. These constraints
vary but dictate what information can be displayed and logged. A vary but dictate which information can be displayed and logged. A
general privacy indicator expressing a desire for privacy by the general privacy indicator expressing a desire for privacy by the
subscriber is provided. The interpretation of how this is applied is subscriber is provided. The interpretation of how this is applied is
left to the receiving jurisdiction as the custodians of the local left to the receiving jurisdiction as the custodians of the local
regulatory requirements. This matches an equivalent privacy flag regulatory requirements. This matches an equivalent privacy flag
provided in some legacy emergency call systems. provided in some legacy emergency call systems.
4.4.1. Subscriber Data Privacy Indicator 4.4.1. Subscriber Data Privacy Indicator
Attribute: 'privacyRequested', Boolean. Attribute: 'privacyRequested', Boolean.
skipping to change at page 29, line 6 skipping to change at page 29, line 11
Description: The subscriber data privacy indicator specifically Description: The subscriber data privacy indicator specifically
expresses the subscriber's desire for privacy. In some expresses the subscriber's desire for privacy. In some
jurisdictions subscriber services can have a specific "Type of jurisdictions subscriber services can have a specific "Type of
Service" which prohibits information, such as the name of the Service" which prohibits information, such as the name of the
subscriber, from being displayed. This attribute is provided to subscriber, from being displayed. This attribute is provided to
explicitly indicate whether the subscriber service includes such explicitly indicate whether the subscriber service includes such
constraints. The interpretation of this indicator is left to each constraints. The interpretation of this indicator is left to each
jurisdiction (in keeping with the semantics of the privacy jurisdiction (in keeping with the semantics of the privacy
indicator provided in some legacy emergency call systems). indicator provided in some legacy emergency call systems).
Because the interpretation of this indicator varies based on local
regulations, this document cannot describe the exact semantics nor
indicate which fields are affected (the application of this
indicator might affect the display of data contained in any of the
blocks).
Reason for Need: Some jurisdictions require subscriber privacy to be Reason for Need: Some jurisdictions require subscriber privacy to be
observed when processing emergency calls. observed when processing emergency calls.
How Used by Call Taker: Where privacy is indicated the call taker How Used by Call Taker: Where privacy is indicated the call taker
may not have access to some aspects of the subscriber information. may not have access to some aspects of the subscriber information.
4.4.2. xCard for Subscriber's Data 4.4.2. xCard for Subscriber's Data
Data Element: xCARD for Subscriber's Data Data Element: xCARD for Subscriber's Data
skipping to change at page 69, line 25 skipping to change at page 69, line 25
expert review. The designated expert should ascertain that the expert review. The designated expert should ascertain that the
proposed type is well understood, and provides information useful to proposed type is well understood, and provides information useful to
PSAPs and responders. The specification must contain a complete PSAPs and responders. The specification must contain a complete
description of the data, and a precise format specification suitable description of the data, and a precise format specification suitable
to allow interoperable implementations. to allow interoperable implementations.
The content of this registry includes: The content of this registry includes:
Token: The value to be placed in the <DeviceSpecificType> element. Token: The value to be placed in the <DeviceSpecificType> element.
Description: Short description identifying the the data. Description: Short description identifying the data.
Specification: Citation for the specification of the data. Specification: Citation for the specification of the data.
The initial set of values are listed in Figure 10. The initial set of values are listed in Figure 10.
10.1.9. Emergency Call Data Types Registry 10.1.9. Emergency Call Data Types Registry
This document creates a new sub-registry called 'Emergency Call Data This document creates a new sub-registry called 'Emergency Call Data
Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. Types' in the 'purpose' registry established by RFC 3261 [RFC3261].
As defined in [RFC5226], this registry operates under "Specification As defined in [RFC5226], this registry operates under "Specification
skipping to change at page 70, line 10 skipping to change at page 70, line 10
document. The subtype MAY exist under any MIME media type (although document. The subtype MAY exist under any MIME media type (although
most commonly these are under 'Application/' this is NOT REQUIRED), most commonly these are under 'Application/' this is NOT REQUIRED),
however, to be added to the registry the "root" needs to be unique however, to be added to the registry the "root" needs to be unique
regardless of the MIME media type. regardless of the MIME media type.
The content of this registry includes: The content of this registry includes:
Token: The root of the data's MIME subtype (not including the Token: The root of the data's MIME subtype (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') 'EmergencyCallData' prefix and any suffix such as '+xml')
Data About: Indicates if the data describes the call, the caller, or Data About: A hint as to if the block is considered descriptive of
the location (or is applicable to all), which helps PSAPs and the call, the caller, or the location (or is applicable to more
other entities determine if they wish to process the block. The than one), which may help PSAPs and other entities determine if
value MUST be either "The Call", "The Caller", "The Location", or they wish to process the block. Note that this is only a hint;
"All". New values are created by extending this registry in a entities need to consider the block's contents, not just this
subsequent RFC. field, when determining if they wish to process the block (which
is why the field only exists in the registry, and is not contained
within the block). The value MUST be either "The Call", "The
Caller", "The Location", or "Multiple". New values are created by
extending this registry in a subsequent RFC.
Reference: The document that describes the data object Reference: The document that describes the data object
Note that the values from this registry are part of the Note that the tokens in this registry are part of the
'EmergencyCallData' compound value; when used as a value of the 'EmergencyCallData' compound value; when used as a value of the
'purpose' parameter of the Call-Info header, the values listed in 'purpose' parameter of the Call-Info header, the values listed in
this registry are prefixed by 'EmergencyCallData.' per the the this registry are prefixed by 'EmergencyCallData.' per the
'EmergencyCallData' registation Section 10.2. 'EmergencyCallData' registation Section 10.2.
The initial set of values are listed in Figure 25. The initial set of values are listed in Figure 25.
+----------------+--------------+------------+ +----------------+--------------+------------+
| Token | Data About | Reference | | Token | Data About | Reference |
+----------------+--------------+------------+ +----------------+--------------+------------+
| ProviderInfo | The Call | [This RFC] | | ProviderInfo | The Call | [This RFC] |
| ServiceInfo | The Call | [This RFC] | | ServiceInfo | The Call | [This RFC] |
| DeviceInfo | The Call | [This RFC] | | DeviceInfo | The Call | [This RFC] |
 End of changes. 20 change blocks. 
28 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/