< draft-ietf-ecrit-additional-data-13.txt		draft-ietf-ecrit-additional-data-14.txt >
	skipping to change at page 1, line 16 ¶		skipping to change at page 1, line 16 ¶
	Expires: April 19, 2014 Nokia Solutions and Networks		Expires: April 19, 2014 Nokia Solutions and Networks
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	R. Gellens		R. Gellens
	Qualcomm Technologies, Inc.		Qualcomm Technologies, Inc.
	J. Winterbottom		J. Winterbottom
	October 16, 2013		October 16, 2013
	Additional Data related to an Emergency Call		Additional Data related to an Emergency Call
	draft-ietf-ecrit-additional-data-13.txt		draft-ietf-ecrit-additional-data-14.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 device that sends it, as well as any application service		(PSAP), the device that sends it, as well as any application service
	provider in the path of the call, or access network provider through		provider in the path of the call, or access network provider through
	which the call originated may have information about the call, the		which the call originated may have information about the call, the
	caller or the location which the PSAP may be able to use. This		caller or the location which the PSAP may be able to use. This
	document describes data structures and a mechanism to convey such		document describes data structures and a mechanism to convey such
	data to the PSAP. The mechanism uses a Uniform Resource Identifier		data to the PSAP. The mechanism uses a Uniform Resource Identifier
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 29 ¶
	Reason for Need: Additional data providers may need to be contacted		Reason for Need: Additional data providers may need to be contacted
	for error or other unusual circumstances.		for error or other unusual circumstances.
	How Used by Call Taker: To contact the supplier of the additional		How Used by Call Taker: To contact the supplier of the additional
	data for assistance in handling the call.		data for assistance in handling the call.
	3.1.6. Data Provider Languages(s) Supported		3.1.6. Data Provider Languages(s) Supported
	Data Element: Data Provider Language(s) supported		Data Element: Data Provider Language(s) supported
	Use: Conditional		Use: Required.
	XML Element: <Language>		XML Element: <Language>
	Description: The language used by the entity at the Data Provider		Description: The language used by the entity at the Data Provider
	Contact URI as an alpha 2-character code as defined in ISO		Contact URI as an alpha 2-character code as defined in ISO
	639-1:2002 Codes for the representation of names of languages --		639-1:2002 Codes for the representation of names of languages --
	Part 1: Alpha-2 code Multiple instances of this element may occur.		Part 1: Alpha-2 code Multiple instances of this element may occur.
	Order is significant; preferred language should appear first.		Order is significant; preferred language should appear first. The
	This data is required if a Data Provider Contact URI is provided.		content MUST reflect the languages supported at the contact URI.
	The content must reflect the languages supported at the contact
	URI.
	Reason for Need: Information needed to determine if emergency		Reason for Need: Information needed to determine if emergency
	service authority can communicate with the service provider or if		service authority can communicate with the service provider or if
	an interpreter will be needed.		an interpreter will be needed.
	How Used by Call Taker: If call taker cannot speak language(s)		How Used by Call Taker: If call taker cannot speak language(s)
	supported by the service provider, a translation service will need		supported by the service provider, a translation service will need
	to be added to the conversation.		to be added to the conversation. Alternatively, other persons at
			the PSAP, besides the call taker, might be consulted for help
			(depending on the urgency and the type of interaction).
	3.1.7. xCard of Data Provider		3.1.7. xCard of Data Provider
	Data Element: xCard of Data Provider		Data Element: xCard of Data Provider
	Use: Optional		Use: Optional
	XML Element: <DataProviderContact>		XML Element: <DataProviderContact>
	Description: There are many fields in the xCard and the creator of		Description: There are many fields in the xCard and the creator of
	the data structure is encouraged to provide as much information as		the data structure is encouraged to provide as much information as
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	Reason for Need: Identify the entity the subcontractor works for.		Reason for Need: Identify the entity the subcontractor works for.
	How Used by Call Taker: Allows the call taker to understand what the		How Used by Call Taker: Allows the call taker to understand what the
	relationship between data providers and the service providers in		relationship between data providers and the service providers in
	the path of the call are.		the path of the call are.
	3.1.9. Subcontractor Priority		3.1.9. Subcontractor Priority
	Data Element: Subcontractor Priority		Data Element: Subcontractor Priority
	Use: Conditional		Use: Conditional. This data is required if the Data Provider type
			is "subcontractor".
	XML Element: <SubcontractorPriority>		XML Element: <SubcontractorPriority>
	Description: If the subcontractor should be contacted first, this		Description: If the subcontractor has to be contacted first then
	element should have a "sub" value. If the access or origination		this element MUST have the value "sub". If the access or service
	service provider should be contacted first, this element should		provider has to be contacted first then this element MUST have the
	have a "main" value. This data is required if the Data Provider		value "main".
	type is "subcontractor".
	Reason for Need: Inform the call taker whether the network operator		Reason for Need: Inform the call taker whom to contact first, if
	or the subcontractor should be contacted first if support is		support is needed.
	needed.
	How Used by Call Taker: To decide which entity to contact first if		How Used by Call Taker: To decide which entity to contact first if
	assistance is needed.		assistance is needed.
	3.1.10. emergencyCall.ProviderInfo Example		3.1.10. emergencyCall.ProviderInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ad:emergencyCall.ProviderInfo		<ad:emergencyCall.ProviderInfo
	xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	skipping to change at page 21, line 6 ¶		skipping to change at page 21, line 6 ¶
	3.3.6. Device/Service Specific Additional Data Structure		3.3.6. Device/Service Specific Additional Data Structure
	Data Element: Device/service specific additional data structure		Data Element: Device/service specific additional data structure
	Use: Optional		Use: Optional
	XML Element: <DeviceSpecificData>		XML Element: <DeviceSpecificData>
	Description: A URI representing additional data whose schema is		Description: A URI representing additional data whose schema is
	specific to the device or service which created it. An example is		specific to the device or service which created it. An example is
	the VEDs structure for a vehicle telematics device. The URI, when		the Vehicular Emergency Data Set (VEDS) structure for a vehicle
	dereferenced, MUST yield a data structure defined by the Device/		telematics device. The URI, when dereferenced, MUST yield a data
	service specific additional data type value. Different data may		structure defined by the Device/service specific additional data
	be created by each classification; e.g., telematics creates VEDS		type value. Different data may be created by each classification;
	data set.		e.g., a telematics created VEDS data set.
	Reason for Need: Provides device/service specific data that may be		Reason for Need: Provides device/service specific data that may be
	used by the call taker and/or responders.		used by the call taker and/or responders.
	How Used by Call Taker: Provide information to guide call takers to		How Used by Call Taker: Provide information to guide call takers to
	select appropriate responders, give appropriate pre-arrival		select appropriate responders, give appropriate pre-arrival
	instructions to callers, and advise responders of what to be		instructions to callers, and advise responders of what to be
	prepared for. May be used by responders to guide assistance		prepared for. May be used by responders to guide assistance
	provided.		provided.
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 39 ¶
	XML Element: <DeviceSpecificType>		XML Element: <DeviceSpecificType>
	Description: Value from a registry defined by this document to		Description: Value from a registry defined by this document to
	describe the type of data that can be retrieved from the device/		describe the type of data that can be retrieved from the device/
	service specific additional data structure. Initial values are:		service specific additional data structure. Initial values are:
	* IEEE 1512		* IEEE 1512
	* VEDS		* VEDS
	IEEE 1512 is the USDoT model for traffic incidents and Vehicular		IEEE 1512 is the USDoT model for traffic incidents and VEDS
	Emergency Data Set (VEDS) provides data elements needed for an		provides data elements needed for an efficient emergency response
	efficient emergency response to vehicular emergency incidents.		to vehicular emergency incidents.
	Reason for Need: This data element allows identification of		Reason for Need: This data element allows identification of
	externally defined schemas, which may have additional data that		externally defined schemas, which may have additional data that
	may assist in emergency response.		may assist in emergency response.
	How Used by Call Taker: This data element allows the end user		How Used by Call Taker: This data element allows the end user
	(calltaker or first responder) to know what type of additional		(calltaker or first responder) to know what type of additional
	data may be available to aid in providing the needed emergency		data may be available to aid in providing the needed emergency
	services.		services.
	skipping to change at page 42, line 39 ¶		skipping to change at page 42, line 39 ¶
	</xs:schema>		</xs:schema>
	Figure 19: Provided-By XML Schema.		Figure 19: Provided-By XML Schema.
	7. Security Considerations		7. Security Considerations
	The information in this data structure will usually be considered		The information in this data structure will usually be considered
	private. HTTPS is specified to require the provider of the		private. HTTPS is specified to require the provider of the
	information to validate the credentials of the requester. While the		information to validate the credentials of the requester. While the
	creation of a PKI that has global scope may be difficult, the		creation of a public key infrastructure (PKI) that has global scope
	alternatives to creating devices and services that can provide		may be difficult, the alternatives to creating devices and services
	critical information securely are more daunting. The provider may		that can provide critical information securely are more daunting.
	enforce any policy it wishes to use, but PSAPs and responder agencies		The provider may enforce any policy it wishes to use, but PSAPs and
	should deploy a PKI so that providers of additional data can check		responder agencies should deploy a PKI so that providers of
	the certificate of the client and decide the appropriate policy to		additional data can check the certificate of the client and decide
	enforce based on that certificate.		the appropriate policy to enforce based on that certificate.
	Ideally, the PSAP and emergency responders will be given credentials		Ideally, the PSAP and emergency responders will be given credentials
	signed by an authority trusted by the data provider. In most		signed by an authority trusted by the data provider. In most
	circumstances, nationally recognized credentials would be sufficient,		circumstances, nationally recognized credentials would be sufficient,
	and if the emergency services arranges a PKI, data providers could be		and if the emergency services arranges a PKI, data providers could be
	provisioned with the root CA public key for a given nation. Some		provisioned with the root CA public key for a given nation. Some
	nations are developing a PKI for this, and related, purposes. Since		nations are developing a PKI for this, and related, purposes. Since
	calls could be made from devices where the device and/or the service		calls could be made from devices where the device and/or the service
	provider(s) are not local to the emergency authorities, globally		provider(s) are not local to the emergency authorities, globally
	recognized credentials are useful. This might be accomplished by		recognized credentials are useful. This might be accomplished by
End of changes. 10 change blocks.
	31 lines changed or deleted		30 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/