< draft-ietf-ecrit-additional-data-31.txt		draft-ietf-ecrit-additional-data-32.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 4, 2016 NeuStar		Expires: January 5, 2016 NeuStar
	H. Tschofenig		H. Tschofenig
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	J. Winterbottom		J. Winterbottom
	July 3, 2015		July 4, 2015
	Additional Data Related to an Emergency Call		Additional Data Related to an Emergency Call
	draft-ietf-ecrit-additional-data-31.txt		draft-ietf-ecrit-additional-data-32.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 4, 2016.		This Internet-Draft will expire on January 5, 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 33, line 11 ¶		skipping to change at page 33, line 11 ¶
	in an existing SIP header field, the Call-Info header, is		in an existing SIP header field, the Call-Info header, is
	defined. The URI points to the additional data structure. The		defined. The URI points to the additional data structure. The
	Call-Info header is specified in Section 20.9 of [RFC3261]. This		Call-Info header is specified in Section 20.9 of [RFC3261]. This
	document adds a new compound token starting with the value		document adds a new compound token starting with the value
	'EmergencyCallData' for the Call-Info "purpose" parameter. If		'EmergencyCallData' for the Call-Info "purpose" parameter. If
	the "purpose" parameter is set to a value starting with		the "purpose" parameter is set to a value starting with
	'EmergencyCallData', then the Call-Info header contains either an		'EmergencyCallData', then the Call-Info header contains either an
	HTTPS URL pointing to an external resource or a CID (content		HTTPS URL pointing to an external resource or a CID (content
	indirection) URI that allows the data structure to be placed in		indirection) URI that allows the data structure to be placed in
	the body of the SIP message. The "purpose" parameter also		the body of the SIP message. The "purpose" parameter also
	indicates the kind of data (by its MIME type) that is available		indicates the kind of data (by its MIME subtype) that is
	at the URI. As the data is conveyed using a URI in the SIP		available at the URI. As the data is conveyed using a URI in the
	signaling, the data itself may reside on an external resource, or		SIP signaling, the data itself may reside on an external
	may be contained within the body of the SIP message. When the		resource, or may be contained within the body of the SIP message.
	URI refers to data at an external resource, the data is said to		When the URI refers to data at an external resource, the data is
	be passed by reference. When the URI refers to data contained		said to be passed by reference. When the URI refers to data
	within the body of the SIP message, the data is said to be passed		contained within the body of the SIP message, the data is said to
	by value. A PSAP or emergency responder is able to examine the		be passed by value. A PSAP or emergency responder is able to
	type of data provided and selectively inspect the data it is		examine the type of data provided and selectively inspect the
	interested in, while forwarding all of it (the values or		data it is interested in, while forwarding all of it (the values
	references) to downstream entities. To be conveyed in a SIP		or references) to downstream entities. To be conveyed in a SIP
	body, additional data about a call is defined as a series of MIME		body, additional data about a call is defined as a series of MIME
	objects. Each block defined in this document is an XML data		objects. Each block defined in this document is an XML data
	structure identified by its MIME type. (Blocks defined by others		structure identified by its MIME type. (Blocks defined by others
	may be encoded in XML or not, as identified by their MIME		may be encoded in XML or not, as identified by their MIME
	registration.) As usual, whenever more than one MIME part is		registration.) As usual, whenever more than one MIME part is
	included in the body of a message, MIME multipart (i.e.,		included in the body of a message, MIME multipart (i.e.,
	'multipart/mixed') encloses them all. This document defines a		'multipart/mixed') encloses them all. This document defines a
	set of XML schemas and MIME types used for each block defined		set of XML schemas and MIME types used for each block defined
	here. When additional data is passed by value in the SIP		here. When additional data is passed by value in the SIP
	signaling, each CID URL points to one block in the body.		signaling, each CID URL points to one block in the body.
	skipping to change at page 34, line 38 ¶		skipping to change at page 34, line 38 ¶
	entities are expected to provide sets of data, the data itself needs		entities are expected to provide sets of data, the data itself needs
	information describing the source. Consequently, each entity adding		information describing the source. Consequently, each entity adding
	additional data MUST supply a "Data Provider" block. All other		additional data MUST supply a "Data Provider" block. All other
	blocks are optional, but each entity SHOULD supply all blocks where		blocks are optional, but each entity SHOULD supply all blocks where
	it has at least some of the information in the block.		it has at least some of the information in the block.
	5.1. Transmitting Blocks using the Call-Info Header		5.1. Transmitting Blocks using the Call-Info Header
	A URI to a block MAY be inserted in any SIP request or response		A URI to a block MAY be inserted in any SIP request or response
	method (most often INVITE or MESSAGE) with a Call-Info header field		method (most often INVITE or MESSAGE) with a Call-Info header field
	containing a purpose value starting with 'EmergencyCallData' and the		containing a purpose value starting with 'EmergencyCallData', a dot
	type of data available at the URI. The type of data is denoted by		("."), and the type of data available at the URI. The type of data
	including the root of the MIME type (not including the		is denoted by including the root of the MIME subtype (the
	'EmergencyCallData' prefix and any suffix such as '+xml') with a '.'		'EmergencyCallData' prefix is not repeated), omitting any suffix such
	separator. For example, when referencing a block with MIME type		as '+xml'). For example, when referencing a block with MIME type
	'application/EmergencyCallData.ProviderInfo+xml', the 'purpose'		'application/EmergencyCallData.ProviderInfo+xml', the 'purpose'
	parameter is set to 'EmergencyCallData.ProviderInfo'. An example		parameter is set to 'EmergencyCallData.ProviderInfo'. An example
	"Call-Info" header field for this would be:		"Call-Info" header field for this would be:
	Call-Info: https://www.example.com/23sedde3;		Call-Info: https://www.example.com/23sedde3;
	purpose="EmergencyCallData.ProviderInfo"		purpose="EmergencyCallData.ProviderInfo"
	A Call-info header with a purpose value starting with		A Call-info header with a purpose value starting with
	'EmergencyCallData' only has meaning in the context of an emergency		'EmergencyCallData' only has meaning in the context of an emergency
	call (as ascertained by the presence of an emergency service URN in a		call (as ascertained by the presence of an emergency service URN in a
	skipping to change at page 69, line 49 ¶		skipping to change at page 69, line 49 ¶
	obviously duplicate existing functionality. The expert is also		obviously duplicate existing functionality. The expert is also
	responsible for verifying that the block is correctly categorized per		responsible for verifying that the block is correctly categorized per
	the description of the categories in Section 1.		the description of the categories in Section 1.
	The registry contains an entry for every data block that can be sent		The registry contains an entry for every data block that can be sent
	with an emergency call using the mechanisms as specified in this		with an emergency call using the mechanisms as specified in this
	document. Each data block is identified by the "root" of its MIME		document. Each data block is identified by the "root" of its MIME
	subtype (which is the part after 'EmergencyCallData.'). If the MIME		subtype (which is the part after 'EmergencyCallData.'). If the MIME
	subtype does not start with 'EmergencyCallData.', then it cannot be		subtype does not start with 'EmergencyCallData.', then it cannot be
	registered here nor used in a Call-Info header as specified in this		registered here nor used in a Call-Info header as specified in this
	document. The subtype MAY exist under any MIME type (although most		document. The subtype MAY exist under any MIME media type (although
	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 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: Indicates if the data describes the call, the caller, or
	the location (or is applicable to all), which helps PSAPs and		the location (or is applicable to all), which helps PSAPs and
	other entities determine if they wish to process the block. The		other entities determine if they wish to process the block. The
	value MUST be either "The Call", "The Caller", "The Location", or		value MUST be either "The Call", "The Caller", "The Location", or
End of changes. 8 change blocks.
	23 lines changed or deleted		23 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/