< draft-ietf-ecrit-additional-data-36.txt		draft-ietf-ecrit-additional-data-37.txt >
	ECRIT R. Gellens		ECRIT R. Gellens
	Internet-Draft Qualcomm Technologies, Inc.		Internet-Draft Qualcomm Technologies, Inc.
	Updates: 6443, 6881 (if approved) B. Rosen		Updates: 6443, 6881 (if approved) B. Rosen
	Intended status: Standards Track NeuStar		Intended status: Standards Track NeuStar
	Expires: April 6, 2016 H. Tschofenig		Expires: April 14, 2016 H. Tschofenig
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	J. Winterbottom		J. Winterbottom
	October 4, 2015		October 12, 2015
	Additional Data Related to an Emergency Call		Additional Data Related to an Emergency Call
	draft-ietf-ecrit-additional-data-36.txt		draft-ietf-ecrit-additional-data-37.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 as		data to the PSAP. The intent is that every emergency call carry as
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 April 6, 2016.		This Internet-Draft will expire on April 14, 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 35, line 34 ¶		skipping to change at page 35, line 34 ¶
	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.
	Note that, as with any mechanism, failures are possible. For		Note that, as with any mechanism, failures are possible. For
	example, a block (provided by value or by reference) might not be the		example, a block (provided by value or by reference) might not be the
	type indicated by the "purpose" parameter, or might be badly formed,		type indicated by the "purpose" parameter, or might be badly formed,
	etc. The general principle that applies to emergency calls is that		etc. The general principle that applies to emergency calls is that
	it is more important for the call to go through than for for		it is more important for the call to go through than for everything
	everything to be correct. Thus, most PSAPs will process a call if at		to be correct. Thus, most PSAPs will process a call if at all
	all possible, even if data is missing or other failures occur.		possible, even if data is missing or other failures occur.
	6.1. Transmitting Blocks using Call-Info		6.1. Transmitting Blocks using Call-Info
	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', a dot		containing a purpose value starting with 'EmergencyCallData', a dot
	("."), and the type of data available at the URI. The type of data		("."), and the type of data available at the URI. The type of data
	is denoted by including the root of the MIME media subtype (the		is denoted by including the root of the MIME media subtype (the
	'EmergencyCallData' prefix is not repeated), omitting any suffix such		'EmergencyCallData' prefix is not repeated), omitting any suffix such
	as '+xml'). For example, when referencing a block with MIME media		as '+xml'). For example, when referencing a block with MIME media
	skipping to change at page 84, line 48 ¶		skipping to change at page 84, line 48 ¶
	group. The authors are grateful for the initial work and extended		group. The authors are grateful for the initial work and extended
	comments provided by many NENA participants, including Delaine		comments provided by many NENA participants, including Delaine
	Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James		Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
	Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra,		Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra,
	and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank		and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank
	Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback		Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback
	regarding the vCard/xCard use in this specification.		regarding the vCard/xCard use in this specification.
	We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin		We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
	Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris		Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris
	Santer, Archie Cobbs, Magnus Nystrom, and Francis Dupont for their		Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, and Francis
	review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry		Dupont for their review comments. Alissa Cooper, Guy Caron, Ben
	Leiba deserves special mention for their detailed and extensive		Campbell, and Barry Leiba deserves special mention for their detailed
	review comments, which were very helpful and appreciated.		and extensive review comments, which were very helpful and
			appreciated.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
End of changes. 6 change blocks.
	11 lines changed or deleted		12 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/