< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/