< draft-ietf-ecrit-car-crash-13.txt		draft-ietf-ecrit-car-crash-14.txt >
	ECRIT R. Gellens		ECRIT R. Gellens
	Internet-Draft Core Technology Consulting		Internet-Draft Core Technology Consulting
	Intended status: Standards Track B. Rosen		Intended status: Standards Track B. Rosen
	Expires: April 6, 2017 NeuStar, Inc.		Expires: April 12, 2017 NeuStar, Inc.
	H. Tschofenig		H. Tschofenig
	Individual		Individual
	October 3, 2016		October 9, 2016
	Next-Generation Vehicle-Initiated Emergency Calls		Next-Generation Vehicle-Initiated Emergency Calls
	draft-ietf-ecrit-car-crash-13.txt		draft-ietf-ecrit-car-crash-14.txt
	Abstract		Abstract
	This document describes how to use IP-based emergency services		This document describes how to use IP-based emergency services
	mechanisms to support the next generation of emergency calls placed		mechanisms to support the next generation of emergency calls placed
	by vehicles (automatically in the event of a crash or serious		by vehicles (automatically in the event of a crash or serious
	incident, or manually invoked by a vehicle occupant) and conveying		incident, or manually invoked by a vehicle occupant) and conveying
	vehicle, sensor, and location data related to the crash or incident.		vehicle, sensor, and location data related to the crash or incident.
	Such calls are often referred to as "Automatic Crash Notification"		Such calls are often referred to as "Automatic Crash Notification"
	(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the		(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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, 2017.		This Internet-Draft will expire on April 12, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19		9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19
	9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 20		9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 20
	9.4. The <capabilities> element . . . . . . . . . . . . . . . 21		9.4. The <capabilities> element . . . . . . . . . . . . . . . 21
	10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 23		11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 23
	11.1. Overall Description . . . . . . . . . . . . . . . . . . 23		11.1. Overall Description . . . . . . . . . . . . . . . . . . 23
	11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 24		11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 24
	11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24		11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24
	11.4. Info Package Parameters . . . . . . . . . . . . . . . . 24		11.4. Info Package Parameters . . . . . . . . . . . . . . . . 24
	11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24		11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24
	11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 24		11.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24
	11.7. Info Package Usage Restrictions . . . . . . . . . . . . 25		11.7. Info Package Usage Restrictions . . . . . . . . . . . . 25
	11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25		11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25
	11.9. Info Package Security Considerations . . . . . . . . . . 25		11.9. Info Package Security Considerations . . . . . . . . . . 25
	11.10. Implementation Details . . . . . . . . . . . . . . . . . 26		11.10. Implementation Details . . . . . . . . . . . . . . . . . 25
	11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26		11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
	12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 31		13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32		14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	15.1. MIME Content-type Registration for		15.1. MIME Content-type Registration for
	'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32		'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32
	15.2. Registration of the 'VEDS' entry in the Emergency Call		15.2. Registration of the 'VEDS' entry in the Emergency Call
	Additional Data registry . . . . . . . . . . . . . . . . 34		Additional Data registry . . . . . . . . . . . . . . . . 33
	15.3. New Action Values . . . . . . . . . . . . . . . . . . . 34		15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
	15.4. Static Message Registry . . . . . . . . . . . . . . . . 34		15.4. Static Message Registry . . . . . . . . . . . . . . . . 34
	15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35		15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35
	15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36		15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37		16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
	17. Changes from Previous Versions . . . . . . . . . . . . . . . 37		17. Changes from Previous Versions . . . . . . . . . . . . . . . 37
	17.1. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 37		17.1. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 37
	17.2. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38		17.2. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
	17.3. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38		17.3. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
	17.4. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38		17.4. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
	17.5. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38		17.5. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
	17.6. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38		17.6. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38
	17.7. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38		17.7. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38
	17.8. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39		17.8. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38
	17.9. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39		17.9. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
	17.10. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39		17.10. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
	17.11. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39		17.11. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
	17.12. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39		17.12. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
	17.13. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39		17.13. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39
	17.14. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39		17.14. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39
	17.15. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40		17.15. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
			17.16. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		18. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	18.1. Normative References . . . . . . . . . . . . . . . . . . 40		18.1. Normative References . . . . . . . . . . . . . . . . . . 40
	18.2. Informative references . . . . . . . . . . . . . . . . . 41		18.2. Informative references . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Terminology		1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	field in the body part. The SIP message is marked as containing the		field in the body part. The SIP message is marked as containing the
	metadata/control block by adding (or appending to) a Call-Info header		metadata/control block by adding (or appending to) a Call-Info header
	field at the top level of the SIP message. This Call-Info header		field at the top level of the SIP message. This Call-Info header
	field contains a CID URL referencing the body part's unique		field contains a CID URL referencing the body part's unique
	identifier, and a 'purpose' parameter identifying the data as a		identifier, and a 'purpose' parameter identifying the data as a
	metadata/control block per the Emergency Call Additional Data Blocks		metadata/control block per the Emergency Call Additional Data Blocks
	registry entry; the 'purpose' parameter's value is		registry entry; the 'purpose' parameter's value is
	'emergencyCallData.control'. A metadata/control object is carried in		'emergencyCallData.control'. A metadata/control object is carried in
	a SIP INFO request by using the INFO package defined in Section 11.		a SIP INFO request by using the INFO package defined in Section 11.
	As is necessary with message bodies, if a VEDS or a metadata/control
	block is sent in the same message with another body part, a
	multipart/mixed body part encloses all body parts. In some cases,
	there are intermediate multipart body parts between the top level
	multipart/mixed and the body part containing the VEDS or metadata/
	control object.
	A body part containing a VEDS or metadata/control object has a		A body part containing a VEDS or metadata/control object has a
	Content-Disposition header field value containing "By-Reference"		Content-Disposition header field value containing "By-Reference" and
	unless it is the only body part in a SIP INFO request, in which case,		is always enclosed in a multipart body part. (In some cases, there
	per [RFC6086], "INFO-Package" is used.		might be intermediate multipart body parts between the top level
			multipart/mixed and the body part containing the VEDS or metadata/
			control object.)
	An In-Vehicle System (IVS) initiating an NG-ACN call includes in the		An In-Vehicle System (IVS) initiating an NG-ACN call includes in the
	initial INVITE a VEDS data block and a metadata/control object		initial INVITE a VEDS data block and a metadata/control object
	informing the PSAP of its capabilities. The VEDS and metadata/		informing the PSAP of its capabilities. The VEDS and metadata/
	control body parts (and PIDF-LO) have a Content-Disposition header		control body parts (and PIDF-LO) have a Content-Disposition header
	field with the value "By-Reference; handling=optional". Specifying		field with the value "By-Reference; handling=optional". Specifying
	handling=optional prevents the INVITE from being rejected if it is		handling=optional prevents the INVITE from being rejected if it is
	processed by a legacy element (e.g., a gateway between SIP and		processed by a legacy element (e.g., a gateway between SIP and
	circuit-switched environments) that does not understand the VEDS or		circuit-switched environments) that does not understand the VEDS or
	metadata/control (or PIDF-LO) objects. The PSAP creates a metadata/		metadata/control (or PIDF-LO) objects. The PSAP creates a metadata/
	control object acknowledging receipt of the VEDS data and includes it		control object acknowledging receipt of the VEDS data and includes it
	in the SIP final response to the INVITE. The metadata/control object		in the SIP final response to the INVITE. The metadata/control object
	is not attached to provisional (e.g., 180) responses.		is not attached to provisional (e.g., 180) responses.
	If the IVS receives an acknowledgment for a VEDS data object with		If the IVS receives an acknowledgment for a VEDS data object with
	received=false, it indicates some fault with the transfer of the		received=false, this indicates that the PSAP was unable to properly
	VEDS, the VEDS content, or the PSAP's ability to properly receive,		decode or process the VEDS. The IVS action is not defined (e.g., it
	decode and act on the VEDS. The IVS action is not defined (e.g., it
	might only log an error). Since the PSAP is able to request an		might only log an error). Since the PSAP is able to request an
	updated VEDS during the call, if an initial VEDS is unsatisfactory in		updated VEDS during the call, if an initial VEDS is unsatisfactory in
	any way, the PSAP can choose to request another one.		any way, the PSAP can choose to request another one.
	A PSAP can request that the vehicle send an updated VEDS data block		A PSAP can request that the vehicle send an updated VEDS data block
	during a call. To do so, the PSAP creates a metadata/control object		during a call. To do so, the PSAP creates a metadata/control object
	requesting VEDS data and attaches it to a SIP INFO request and sends		requesting VEDS data and attaches it to a SIP INFO request and sends
	it within the dialog. The IVS then attaches an updated VEDS data		it within the dialog. The IVS then attaches an updated VEDS data
	object to a SIP INFO request and sends it within the dialog. If the		object to a SIP INFO request and sends it within the dialog. If the
	IVS is unable to send the VEDS, it instead sends a metadata/control		IVS is unable to send the VEDS, it instead sends a metadata/control
	skipping to change at page 15, line 32 ¶		skipping to change at page 15, line 25 ¶
	'false' and a 'reason' parameter (and optionally a 'details'		'false' and a 'reason' parameter (and optionally a 'details'
	parameter) indicating why the request cannot be accomplished. Per		parameter) indicating why the request cannot be accomplished. Per
	[RFC6086], metadata/control objects and VEDS data are sent using the		[RFC6086], metadata/control objects and VEDS data are sent using the
	INFO package defined in Section 11. In addition, to align with the		INFO package defined in Section 11. In addition, to align with the
	way a VEDS or metadata/control block is transmitted in a SIP message		way a VEDS or metadata/control block is transmitted in a SIP message
	other than an INFO request, one or more Call-Info header fields are		other than an INFO request, one or more Call-Info header fields are
	included in the SIP INFO request to reference the VEDS or metadata/		included in the SIP INFO request to reference the VEDS or metadata/
	control block. See Section 11 for more information on the use of		control block. See Section 11 for more information on the use of
	INFO requests within NG-ACN calls.		INFO requests within NG-ACN calls.
			Any metadata/control object sent by a PSAP can request that the
			vehicle perform an action (such as sending a data block, flashing
			lights, providing a camera feed, etc.) The vehicle sends an
			acknowledgement for any request other than a successfully executed
			send-data action. Multiple requests with the same 'action' value
			MUST be sent in separate body parts (to avoid any ambiguity in the
			acknowledgement).
	If the IVS is aware that VEDS data it sent previously has changed, it		If the IVS is aware that VEDS data it sent previously has changed, it
	MAY send an unsolicited VEDS (in any convenient SIP message,		MAY send an unsolicited VEDS (in any convenient SIP message,
	including an INFO request) during the call. The PSAP sends an		including an INFO request) during the call. The PSAP sends an
	acknowledgment of an unsolicited VEDS object (if the IVS sent the		acknowledgment for an unsolicited VEDS object (if the IVS sent the
	unsolicited VEDS in an INFO request, the acknowledgment is sent in a		unsolicited VEDS in an INFO request, the acknowledgment is sent in a
	new INFO request, otherwise it is sent in the response to the message		new INFO request, otherwise it is sent in the response to the message
	containing the VEDS).		containing the VEDS).
	7. Call Setup		7. Call Setup
	A next-generation In-Vehicle System (IVS) initiates an NG-ACN call		A next-generation In-Vehicle System (IVS) initiates an NG-ACN call
	with a SIP INVITE using one of the SOS sub-services		with a SIP INVITE using one of the SOS sub-services
	"SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,		"SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,
	standard sets of crash data and capabilities data encoded in		standard sets of crash data and capabilities data encoded in
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 11 ¶
	metadata/control data to the IVS and the IVS to respond. If control		metadata/control data to the IVS and the IVS to respond. If control
	data sent in a response message requests the IVS to send a new VEDS		data sent in a response message requests the IVS to send a new VEDS
	or other data block, or to perform an action other than sending data,		or other data block, or to perform an action other than sending data,
	the IVS sends the requested data or an acknowledgment regarding the		the IVS sends the requested data or an acknowledgment regarding the
	action in an INFO message within the dialog.		action in an INFO message within the dialog.
	9.1. New values for the 'action' attribute'		9.1. New values for the 'action' attribute'
	The following new "action" values are defined:		The following new "action" values are defined:
	msg-static: displays or plays a predefined message (translated as		msg-static displays or plays a predefined message (translated as
	appropriate for the language of the vehicle's interface). A		appropriate for the language of the vehicle's interface). A
	registry is created in Section 15.4 for messages and their IDs.		registry is created in Section 15.4 for messages and their IDs.
	Vehicles include the highest registered message in their		Vehicles include the highest registered message in their
	<capabilities> element to indicate support for all messages up to		<capabilities> element to indicate support for all messages up to
	and including the indicated value.		and including the indicated value.
	msg-dynamic displays or speaks (via text-to-speech) a dynamic		msg-dynamic displays or speaks (via text-to-speech) a dynamic
	message included in the request.		message included in the request.
	honk sounds the horn.		honk sounds the horn.
	skipping to change at page 24, line 47 ¶		skipping to change at page 24, line 47 ¶
	The info package name is emergencyCallData.eCall.VEDS		The info package name is emergencyCallData.eCall.VEDS
	11.4. Info Package Parameters		11.4. Info Package Parameters
	None		None
	11.5. SIP Option-Tags		11.5. SIP Option-Tags
	None		None
	11.6. INFO Message Body Parts		11.6. INFO Request Body Parts
	The body for an emergencyCallData.eCall.VEDS info package is:
	o an application/emergencyCallData.eCall.VEDS+xml (containing a VEDS
	data block), or
	o an application/emergencyCallData.control+xml (containing a
	metadata/control object), or
	o an application/emergencyCallData.eCall.MSD+per (containing an
	MSD), or
	o a multipart body containing:
	* zero or one application/emergencyCallData.eCall.VEDS+xml part
	(containing a VEDS data block),
	* zero or more application/emergencyCallData.control+xml
	(containing a metadata/control object),
	* zero or one application/emergencyCallData.eCall.MSD+per part		The body for an emergencyCallData.eCall.VEDS info package is a
	(containing an MSD),		multipart body. Zero or one application/
			emergencyCallData.eCall.VEDS+xml (containing a VEDS data block) part,
			zero or more application/emergencyCallData.control+xml (containing a
			metadata/control object) parts, and zero or one application/
			emergencyCallData.eCall.MSD+per (containing an MSD) part are
			permitted. Intermediate multipart body parts MAY appear.
	The body parts are sent per [RFC6086], and in addition, to align with		The body parts are sent per [RFC6086], and in addition, to align with
	with how these body parts are sent in non-INFO messages, each		with how these body parts are sent in non-INFO messages, each
	associated body part is referenced by a Call-Info header field at the		associated body part is referenced by a Call-Info header field at the
	top level of the SIP message. If the body part is the only body		top level of the SIP message. The body part has a Content-
	part, it has a Content-Disposition header field value of "INFO-		Disposition header field set to "By-Reference".
	Package". If the body part is contained within a multipart, it has a
	Content-Disposition header field value of "By-Reference".
	Service providers are not expected to attach [RFC7852] Additional		Service providers are not expected to attach [RFC7852] Additional
	Data to an INFO request.		Data to an INFO request.
	See [TBD: THIS DOCUMENT] for more information.		See [TBD: THIS DOCUMENT] for more information.
	11.7. Info Package Usage Restrictions		11.7. Info Package Usage Restrictions
	Usage is limited to vehicle-initiated emergency calls as defined in		Usage is limited to vehicle-initiated emergency calls as defined in
	[TBD: THIS DOCUMENT].		[TBD: THIS DOCUMENT].
	skipping to change at page 37, line 47 ¶		skipping to change at page 37, line 47 ¶
	We would like to thank Lena Chaponniere, Stephen Edge, and Christer		We would like to thank Lena Chaponniere, Stephen Edge, and Christer
	Holmberg for their review and suggestions; Robert Sparks and Paul		Holmberg for their review and suggestions; Robert Sparks and Paul
	Kyzivat for their help with the SIP mechanisms; Michael Montag,		Kyzivat for their help with the SIP mechanisms; Michael Montag,
	Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex		Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex
	Buddenberg for their feedback; and Ulrich Dietz for his help with		Buddenberg for their feedback; and Ulrich Dietz for his help with
	earlier versions of the original version of this document.		earlier versions of the original version of this document.
	17. Changes from Previous Versions		17. Changes from Previous Versions
	17.1. Changes from draft-ietf-11 to draft-ietf-13		17.1. Changes from draft-ietf-13 to draft-ietf-14
			o Body parts now always sent enclosed in multipart (even if only
			body part in SIP message) and hence always have a Content-
			Disposition of By-Reference
			o Fixed typos.
			17.2. Changes from draft-ietf-11 to draft-ietf-13
	o Fixed typos		o Fixed typos
	17.2. Changes from draft-ietf-10 to draft-ietf-11		17.3. Changes from draft-ietf-10 to draft-ietf-11
	o Clarifications suggested by Christer		o Clarifications suggested by Christer
	o Corrections to Content-Disposition text and examples as suggested		o Corrections to Content-Disposition text and examples as suggested
	by Paul Kyzivat		by Paul Kyzivat
	o Clarifications to Content-Disposition text and examples to clarify		o Clarifications to Content-Disposition text and examples to clarify
	that handling=optional is only used in the initial INVITE		that handling=optional is only used in the initial INVITE
	17.3. Changes from draft-ietf-09 to draft-ietf-10		17.4. Changes from draft-ietf-09 to draft-ietf-10
	o Fixed errors in examples found by Dale in eCall draft		o Fixed errors in examples found by Dale in eCall draft
	o Removed enclosing sub-section of INFO package registration section		o Removed enclosing sub-section of INFO package registration section
	o Added text per Christer and Dale's suggestions that the MSD and		o Added text per Christer and Dale's suggestions that the MSD and
	metadata/control blocks are sent in INFO with a Call-Info header		metadata/control blocks are sent in INFO with a Call-Info header
	field referencing them		field referencing them
	o Other text changes per comments received from Christer and Ivo		o Other text changes per comments received from Christer and Ivo
	against eCall draft.		against eCall draft.
	17.4. Changes from draft-ietf-08 to draft-ietf-09		17.5. Changes from draft-ietf-08 to draft-ietf-09
	o Added INFO package registration for eCall.VEDS		o Added INFO package registration for eCall.VEDS
	o Moved <capabilities> element and other extension points back to		o Moved <capabilities> element and other extension points back to
	eCall document so that extension points are in base spec (and also		eCall document so that extension points are in base spec (and also
	to get XML schema to compile)		to get XML schema to compile)
	o Text changes for clarification.		o Text changes for clarification.
	17.5. Changes from draft-ietf-07 to draft-ietf-08		17.6. Changes from draft-ietf-07 to draft-ietf-08
	o Moved much of the metadata/control object from		o Moved much of the metadata/control object from
	[I-D.ietf-ecrit-ecall] to this document as extensions		[I-D.ietf-ecrit-ecall] to this document as extensions
	o Editorial clarifications and simplifications		o Editorial clarifications and simplifications
	o Moved "Call Routing" to be a subsection of "Call Setup"		o Moved "Call Routing" to be a subsection of "Call Setup"
	o Deleted "Profile" section and moved some of its text into		o Deleted "Profile" section and moved some of its text into
	"Introduction"		"Introduction"
	17.6. Changes from draft-ietf-06 to draft-ietf-07		17.7. Changes from draft-ietf-06 to draft-ietf-07
	o Minor editorial changes		o Minor editorial changes
	17.7. Changes from draft-ietf-05 to draft-ietf-06		17.8. Changes from draft-ietf-05 to draft-ietf-06
	o Added clarifying text regarding signed and encrypted data		o Added clarifying text regarding signed and encrypted data
	o Additional informative text in "Migration to Next-Generation"		o Additional informative text in "Migration to Next-Generation"
	section		section
	o Additional clarifying text regarding security and privacy.		o Additional clarifying text regarding security and privacy.
	17.8. Changes from draft-ietf-04 to draft-ietf-05		17.9. Changes from draft-ietf-04 to draft-ietf-05
	o Reworded security text in main document and in MIME registration		o Reworded security text in main document and in MIME registration
	for the VEDS object		for the VEDS object
	17.9. Changes from draft-ietf-03 to draft-ietf-04		17.10. Changes from draft-ietf-03 to draft-ietf-04
	o Added example VEDS object		o Added example VEDS object
	o Additional clarifications and corrections		o Additional clarifications and corrections
	o Removed references from Abstract		o Removed references from Abstract
	o Moved Document Scope section to follow Introduction		o Moved Document Scope section to follow Introduction
	17.10. Changes from draft-ietf-02 to draft-ietf-03		17.11. Changes from draft-ietf-02 to draft-ietf-03
	o Additional clarifications and corrections		o Additional clarifications and corrections
	17.11. Changes from draft-ietf-01 to draft-ietf-02		17.12. Changes from draft-ietf-01 to draft-ietf-02
	o This document now refers to [I-D.ietf-ecrit-ecall] for technical		o This document now refers to [I-D.ietf-ecrit-ecall] for technical
	aspects including the service URN; this document no longer		aspects including the service URN; this document no longer
	proposes a unique service URN for non-eCall NG-ACN calls; the same		proposes a unique service URN for non-eCall NG-ACN calls; the same
	service URN is now used for all NG-ACN calls including NG-eCall		service URN is now used for all NG-ACN calls including NG-eCall
	and non-eCall		and non-eCall
	o Added discussion of an NG-ACN call placed to a PSAP that doesn't		o Added discussion of an NG-ACN call placed to a PSAP that doesn't
	support it		support it
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	17.12. Changes from draft-ietf-00 to draft-ietf-01		17.13. Changes from draft-ietf-00 to draft-ietf-01
	o Added further discussion of test calls		o Added further discussion of test calls
	o Added further clarification to the document scope		o Added further clarification to the document scope
	o Mentioned that multi-region vehicles may need to support other		o Mentioned that multi-region vehicles may need to support other
	crash notification specifications such as eCall		crash notification specifications such as eCall
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	17.13. Changes from draft-gellens-02 to draft-ietf-00		17.14. Changes from draft-gellens-02 to draft-ietf-00
	o Renamed from draft-gellens- to draft-ietf-		o Renamed from draft-gellens- to draft-ietf-
	o Added text to Introduction to clarify that during a CS ACN, the		o Added text to Introduction to clarify that during a CS ACN, the
	PSAP call taker usually needs to listen to the data and transcribe		PSAP call taker usually needs to listen to the data and transcribe
	it		it
	17.14. Changes from draft-gellens-01 to -02		17.15. Changes from draft-gellens-01 to -02
	o Fixed case of 'EmergencyCallData', in accordance with changes to		o Fixed case of 'EmergencyCallData', in accordance with changes to
	[RFC7852]		[RFC7852]
	17.15. Changes from draft-gellens-00 to -01		17.16. Changes from draft-gellens-00 to -01
	o Now using 'EmergencyCallData' for purpose parameter values and		o Now using 'EmergencyCallData' for purpose parameter values and
	MIME subtypes, in accordance with changes to [RFC7852]		MIME subtypes, in accordance with changes to [RFC7852]
	o Added reference to RFC 6443		o Added reference to RFC 6443
	o Fixed bug that caused Figure captions to not appear		o Fixed bug that caused Figure captions to not appear
	18. References		18. References
	18.1. Normative References		18.1. Normative References
End of changes. 34 change blocks.
	81 lines changed or deleted		76 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/