< draft-ietf-ecrit-car-crash-17.txt		draft-ietf-ecrit-car-crash-18.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 20, 2017 NeuStar, Inc.		Expires: April 21, 2017 NeuStar, Inc.
	H. Tschofenig		H. Tschofenig
	Individual		Individual
	October 17, 2016		October 18, 2016
	Next-Generation Vehicle-Initiated Emergency Calls		Next-Generation Vehicle-Initiated Emergency Calls
	draft-ietf-ecrit-car-crash-17.txt		draft-ietf-ecrit-car-crash-18.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 20, 2017.		This Internet-Draft will expire on April 21, 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 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7		3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8		4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8
	5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9		5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9
	6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13		7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16
	10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 18		10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17
	10.1. New values for the 'action' attribute' . . . . . . . . . 19		10.1. New values for the 'action' attribute' . . . . . . . . . 18
	10.2. Request Example . . . . . . . . . . . . . . . . . . . . 20		10.2. Request Example . . . . . . . . . . . . . . . . . . . . 19
	10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 20		10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 19
	10.4. The <capabilities> element . . . . . . . . . . . . . . . 21		10.4. The <capabilities> element . . . . . . . . . . . . . . . 20
	11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 23		12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22
	12.1. Overall Description . . . . . . . . . . . . . . . . . . 23		12.1. Overall Description . . . . . . . . . . . . . . . . . . 22
	12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 24		12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23
	12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24		12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23
	12.4. Info Package Parameters . . . . . . . . . . . . . . . . 24		12.4. Info Package Parameters . . . . . . . . . . . . . . . . 23
	12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24		12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23
	12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24		12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24
	12.7. Info Package Usage Restrictions . . . . . . . . . . . . 25		12.7. Info Package Usage Restrictions . . . . . . . . . . . . 24
	12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25		12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24
	12.9. Info Package Security Considerations . . . . . . . . . . 25		12.9. Info Package Security Considerations . . . . . . . . . . 25
	12.10. Implementation Details . . . . . . . . . . . . . . . . . 26		12.10. Implementation Details . . . . . . . . . . . . . . . . . 25
	12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26		12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
	13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 31		14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31		15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	16.1. MIME Content-type Registration for		16.1. MIME Media Type Registration for
	'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32		'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32
	16.2. Registration of the 'VEDS' entry in the Emergency Call		16.2. Registration of the 'VEDS' entry in the Emergency Call
	Additional Data registry . . . . . . . . . . . . . . . . 33		Additional Data registry . . . . . . . . . . . . . . . . 33
	16.3. New Action Values . . . . . . . . . . . . . . . . . . . 34		16.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
	16.4. Static Message Registry . . . . . . . . . . . . . . . . 34		16.4. Static Message Registry . . . . . . . . . . . . . . . . 34
	16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35		16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35
	16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36		16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36
	17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37		17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
	18. Changes from Previous Versions . . . . . . . . . . . . . . . 37		18. Changes from Previous Versions . . . . . . . . . . . . . . . 37
	18.1. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 37		18.1. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 37
	18.2. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38		18.2. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38
	18.3. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38		18.3. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38
	18.4. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38		18.4. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
	18.5. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38		18.5. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
	18.6. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38		18.6. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
	18.7. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38		18.7. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
	18.8. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38		18.8. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
	18.9. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39		18.9. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39
	18.10. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39		18.10. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39
	18.11. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39		18.11. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39
	18.12. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39		18.12. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
	18.13. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39		18.13. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
	18.14. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39		18.14. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
	18.15. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39		18.15. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
	18.16. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40		18.16. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40
	18.17. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40		18.17. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40
	18.18. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40		18.18. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
			18.19. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	19.1. Normative References . . . . . . . . . . . . . . . . . . 40		19.1. Normative References . . . . . . . . . . . . . . . . . . 40
	19.2. Informative references . . . . . . . . . . . . . . . . . 41		19.2. Informative references . . . . . . . . . . . . . . . . . 42
	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].
	This document re-uses terminology defined in Section 3 of [RFC5012].		This document re-uses terminology defined in Section 3 of [RFC5012].
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	set of vehicle (crash) data, specifically, the Vehicle Emergency Data		set of vehicle (crash) data, specifically, the Vehicle Emergency Data
	Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This		Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This
	document is an extension of [I-D.ietf-ecrit-ecall], with the		document is an extension of [I-D.ietf-ecrit-ecall], with the
	differences being that this document makes the MSD data set optional		differences being that this document makes the MSD data set optional
	and VEDS mandatory, and adds new attribute values to the metadata/		and VEDS mandatory, and adds new attribute values to the metadata/
	control object defined in that document. This document also		control object defined in that document. This document also
	registers a new INFO package (identical to that defined in		registers a new INFO package (identical to that defined in
	[I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type).		[I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type).
	This document registers the 'application/EmergencyCallData.VEDS+xml'		This document registers the 'application/EmergencyCallData.VEDS+xml'
	MIME content-type, registers the 'VEDS' entry in the Emergency Call		MIME media type, registers the 'VEDS' entry in the Emergency Call
	Additional Data registry, and registers an INFO package to enable		Additional Data registry, and registers an INFO package to enable
	carrying this and related data in INFO requests.		carrying this and related data in INFO requests.
	Section 6 introduces VEDS. Section 7 describes how VEDS data and		Section 6 introduces VEDS. Section 7 describes how VEDS data and
	metadata/control blocks are transported within NG-ACN calls.		metadata/control blocks are transported within NG-ACN calls.
	Section 8 describes how such calls are placed.		Section 8 describes how such calls are placed.
	These mechanisms are used to place emergency calls that are		These mechanisms are used to place emergency calls that are
	identifiable as ACN calls and that carry standardized crash data in		identifiable as ACN calls and that carry standardized crash data in
	an interoperable way.		an interoperable way.
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 23 ¶
	the likelihood of severe injuries to the vehicle occupants, etc.		the likelihood of severe injuries to the vehicle occupants, etc.
	This data better informs the PSAP and emergency responders as to the		This data better informs the PSAP and emergency responders as to the
	type of response that might be needed. Some of this information has		type of response that might be needed. Some of this information has
	been included in U.S. government guidelines for field triage of		been included in U.S. government guidelines for field triage of
	injured patients [triage-2008] [triage-2011]. These guidelines are		injured patients [triage-2008] [triage-2011]. These guidelines are
	designed to help responders identify the potential existence of		designed to help responders identify the potential existence of
	severe internal injuries and to make critical decisions about how and		severe internal injuries and to make critical decisions about how and
	where a patient needs to be transported.		where a patient needs to be transported.
	VEDS is an XML structure (see [VEDS]) transported in SIP using the		VEDS is an XML structure (see [VEDS]) transported in SIP using the
	'application/EmergencyCallData.VEDS+xml' MIME content-type.		'application/EmergencyCallData.VEDS+xml' MIME media type.
	VEDS is a versatile structure that can accomodate varied needs.
	However, if additional sets of data are needed (e.g., in the future
	or in different regions), the steps to enable each data block are
	very briefly summarized below:
	o A standardized format and encoding (such as XML) is defined and		If new data blocks are needed (e.g., in other regions or for enhanced
	published by a Standards Development Organization (SDO)		data), the steps required during standardization are briefly
			summarized below:
	o A MIME Content-Type is registered for it (typically under the		o A set of data is standardized by an SDO or appropriate
	'Application' media type) with a sub-type in the		organization
	'EmergencyCallData.' tree		o A MIME media type for the crash data set is registered with IANA
	o An entry for the block is added to the Emergency Call Additional		* If the data is specifically for use in emergency calling, the
	Data Blocks sub-registry (established by [RFC7852]); the registry		MIME media type is normally under the 'application' type with a
	entry is the root of the MIME sub-type (not including the		subtype starting with 'EmergencyCallData.'
	'EmergencyCallData.' prefix and any suffix such as '+xml')		* If the data format is XML, then by convention the name has a
			suffix of '+xml'
			o The item is registered in the Emergency Call Additional Data
			registry, as defined in Section 9.1.7 of [RFC7852]
	o A new INFO package is registered that permits carrying the new		* For emergency-call-specific formats, the registered name is the
	media type and the metadata/control object (defined in		root of the MIME media type (not including the
	[I-D.ietf-ecrit-ecall]) in INFO requests.		'EmergencyCallData' prefix and any suffix such as '+xml') as
			described in Section 4.1 of [RFC7852].
			o A new INFO package is registered that permits carrying the the new
			media type, the metadata/control object (defined in
			[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
			objects, in INFO messages.
	7. Data Transport		7. Data Transport
	[RFC7852] establishes a general mechanism for attaching blocks of		[RFC7852] establishes a general mechanism for attaching blocks of
	data to a SIP emergency call. This mechanism permits certain		data to a SIP emergency call. This mechanism permits certain
	emergency call MIME types to be attached to SIP messages. This		emergency call MIME types to be attached to SIP messages. This
	document makes use of that mechanism. This document also registers		document makes use of that mechanism. This document also registers
	an INFO package (in Section 12) to enable NG-ACN related data blocks		an INFO package (in Section 12) to enable NG-ACN related data blocks
	to be carried in SIP INFO requests (per [RFC6086], new INFO usages		to be carried in SIP INFO requests (per [RFC6086], new INFO usages
	require the definition of an INFO package).		require the definition of an INFO package).
	An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS])		An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS])
	by attaching it to a SIP message as a MIME body part per [RFC7852].		by attaching it to a SIP message as a MIME body part per [RFC7852].
	The body part is identified by its MIME content-type ('application/		The body part is identified by its MIME media type ('application/
	emergencyCallData.VEDS+xml') in the Content-Type header field of the		emergencyCallData.VEDS+xml') in the Content-Type header field of the
	body part. The body part is assigned a unique identifier which is		body part. The body part is assigned a unique identifier which is
	listed in a Content-ID header field in the body part. The SIP		listed in a Content-ID header field in the body part. The SIP
	message is marked as containing the VEDS data by adding (or appending		message is marked as containing the VEDS data by adding (or appending
	to) a Call-Info header field at the top level of the SIP message.		to) a Call-Info header field at the top level of the SIP message.
	This Call-Info header field contains a CID URL referencing the body		This Call-Info header field contains a CID URL referencing the body
	part's unique identifier, and a 'purpose' parameter identifying the		part's unique identifier, and a 'purpose' parameter identifying the
	data as a VEDS data block per the Emergency Call Additional Data		data as a VEDS data block per the Emergency Call Additional Data
	Blocks registry entry; the 'purpose' parameter's value is		Blocks registry entry; the 'purpose' parameter's value is
	'emergencyCallData.VEDS'. A VEDS data block is carried in a SIP INFO		'emergencyCallData.VEDS'. A VEDS data block is carried in a SIP INFO
	request by using the INFO package defined in Section 12.		request by using the INFO package defined in Section 12.
	A PSAP or IVS transmits a metadata/control object (see		A PSAP or IVS transmits a metadata/control object (see
	[I-D.ietf-ecrit-ecall]) by attaching it to a SIP message as a MIME		[I-D.ietf-ecrit-ecall]) by attaching it to a SIP message as a MIME
	body part per [RFC7852]. The body part is identified by its MIME		body part per [RFC7852]. The body part is identified by its MIME
	content-type ('application/emergencyCallData.control+xml') in the		media type ('application/emergencyCallData.control+xml') in the
	Content-Type header field of the body part. The body part is		Content-Type header field of the body part. The body part is
	assigned a unique identifier which is listed in a Content-ID header		assigned a unique identifier which is listed in a Content-ID header
	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
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 17 ¶
	VEDS).		VEDS).
	8. Call Setup		8. 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
	standardized and registered formats, attached as additional data		standardized and registered formats, attached as additional data
	blocks as specified in Section 4.1 of [RFC7852]. As described in		blocks as specified in Section 4.1 of [RFC7852]. As described in
	that document, each data block is identified by its MIME content-		that document, each data block is identified by its MIME media type,
	type, and pointed to by a CID URL in a Call-Info header with a		and pointed to by a CID URL in a Call-Info header with a 'purpose'
	'purpose' parameter value corresponding to the data block.		parameter value corresponding to the data block.
	If new data blocks are needed (e.g., in other regions or in the
	future), the steps required during standardization are briefly
	summarized below:
	o A set of data is standardized by an SDO or appropriate
	organization
	o A MIME Content-Type for the crash data set is registered with IANA
	* If the data is specifically for use in emergency calling, the
	MIME type is normally under the 'application' type with a
	subtype starting with 'EmergencyCallData.'
	* If the data format is XML, then by convention the name has a
	suffix of '+xml'
	o The item is registered in the Emergency Call Additional Data
	registry, as defined in Section 9.1.7 of [RFC7852]
	* For emergency-call-specific formats, the registered name is the
	root of the MIME Content-Type (not including the
	'EmergencyCallData' prefix and any suffix such as '+xml') as
	described in Section 4.1 of [RFC7852].
	o A new INFO package is registered that permits carrying the the new
	media type, the metadata/control object (defined in
	[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
	objects, in INFO messages.
	When placing an emergency call, the crash data set and IVS capability		When placing an emergency call, the crash data set and IVS capability
	data are transported as described in Section 7.		data are transported as described in Section 7.
	The Vehicle Emergency Data Set (VEDS) is an XML structure defined by		The Vehicle Emergency Data Set (VEDS) is an XML structure defined by
	the Association of Public-Safety Communications Officials (APCO) and		the Association of Public-Safety Communications Officials (APCO) and
	the National Emergency Number Association (NENA) [VEDS]. It is		the National Emergency Number Association (NENA) [VEDS]. It is
	carried in body part with MIME content-type 'application/		carried in a body part with MIME media type 'application/
	EmergencyCallData.VEDS+xml'.		EmergencyCallData.VEDS+xml'.
	Entities along the path between the vehicle and the PSAP are able to		Entities along the path between the vehicle and the PSAP are able to
	identify the call as an ACN call and handle it appropriately. The		identify the call as an ACN call and handle it appropriately. The
	PSAP is able to identify the crash and capabilities data attached to		PSAP is able to identify the crash and capabilities data attached to
	the INVITE by examining the Call-Info header fields for 'purpose'		the INVITE by examining the Call-Info header fields for 'purpose'
	parameters whose values start with 'EmergencyCallData.' The PSAP is		parameters whose values start with 'EmergencyCallData.' The PSAP is
	able to access the data it is capable of handling and is interested		able to access the data it is capable of handling and is interested
	in by checking the 'purpose' parameter values.		in by checking the 'purpose' parameter values.
	skipping to change at page 25, line 35 ¶		skipping to change at page 24, line 42 ¶
	See [TBD: THIS DOCUMENT] for more information.		See [TBD: THIS DOCUMENT] for more information.
	12.7. Info Package Usage Restrictions		12.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].
	12.8. Rate of INFO Requests		12.8. Rate of INFO Requests
	The rate of SIP INFO requests associated with the		The SIP INFO request is used within an established emergency call
	emergencyCallData.eCall.VEDS info package is normally quite low (most		dialog for the PSAP to request the IVS to send an updated data set,
	dialogs are likely to contain zero INFO requests, while others can be		and for the IVS to send the requested data set. Because this is
	expected to carry an occasional request).		normally done only on manual request of the PSAP call taker (who
			suspects some aspect of the vehicle state has changed), the rate of
			SIP INFO requests associated with the emergencyCallData.eCall.VEDS
			info package is normally quite low (most dialogs are likely to
			contain zero INFO requests, while others can be expected to carry an
			occasional request).
	12.9. Info Package Security Considerations		12.9. Info Package Security Considerations
	The MIME media type registations for the data blocks that can be		The MIME media type registations for the data blocks that can be
	carried using this INFO package contains a discussion of the security		carried using this INFO package contains a discussion of the security
	and/or privacy considerations specific to that data block. The		and/or privacy considerations specific to that data block. The
	"Security Considerations" and "Privacy Considerations" sections of		"Security Considerations" and "Privacy Considerations" sections of
	[TBD: THIS DOCUMENT] discuss security and privacy considerations of		[TBD: THIS DOCUMENT] discuss security and privacy considerations of
	the data carried in vehicle-initiated emergency calls as described in		the data carried in vehicle-initiated emergency calls as described in
	that document.		that document.
	skipping to change at page 32, line 24 ¶		skipping to change at page 32, line 7 ¶
	signed by a certificate issued by an emergency services registrar).		signed by a certificate issued by an emergency services registrar).
	16. IANA Considerations		16. IANA Considerations
	This document registers the 'application/EmergencyCall.VEDS+xml' MIME		This document registers the 'application/EmergencyCall.VEDS+xml' MIME
	media type, and adds "VEDS" to the Emergency Call Additional Data		media type, and adds "VEDS" to the Emergency Call Additional Data
	registry. This document adds to and creates sub-registries in the		registry. This document adds to and creates sub-registries in the
	'Metadata/Control Data' registry created in [I-D.ietf-ecrit-ecall].		'Metadata/Control Data' registry created in [I-D.ietf-ecrit-ecall].
	This document registers a new INFO package.		This document registers a new INFO package.
	16.1. MIME Content-type Registration for 'application/		16.1. MIME Media Type Registration for 'application/
	EmergencyCall.VEDS+xml'		EmergencyCall.VEDS+xml'
	This specification requests the registration of a new MIME media type		This specification requests the registration of a new MIME media type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: EmergencyCallData.VEDS+xml		MIME subtype name: EmergencyCallData.VEDS+xml
	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.
	18. Changes from Previous Versions		18. Changes from Previous Versions
	18.1. Changes from draft-ietf-16 to draft-ietf-17		18.1. Changes from draft-ietf-17 to draft-ietf-18
			o Added additional text to "Rate of Info Requests"
			o Further corrected "content type" to "media type"
			18.2. Changes from draft-ietf-16 to draft-ietf-17
	o Clarified that an INFO request is expected to have at least one		o Clarified that an INFO request is expected to have at least one
	VEDS, MSD or metadata/control body part		VEDS, MSD or metadata/control body part
	o Corrected "content type" to "media type"		o Corrected "content type" to "media type"
	18.2. Changes from draft-ietf-14 to draft-ietf-15		18.3. Changes from draft-ietf-14 to draft-ietf-15
	o Moved VEDS text from Introduction to new Vehicle Data section		o Moved VEDS text from Introduction to new Vehicle Data section
	o Various clarifications and simplifications		o Various clarifications and simplifications
	18.3. Changes from draft-ietf-13 to draft-ietf-14		18.4. Changes from draft-ietf-13 to draft-ietf-14
	o Body parts now always sent enclosed in multipart (even if only		o Body parts now always sent enclosed in multipart (even if only
	body part in SIP message) and hence always have a Content-		body part in SIP message) and hence always have a Content-
	Disposition of By-Reference		Disposition of By-Reference
	o Fixed typos.		o Fixed typos.
	18.4. Changes from draft-ietf-11 to draft-ietf-13		18.5. Changes from draft-ietf-11 to draft-ietf-13
	o Fixed typos		o Fixed typos
	18.5. Changes from draft-ietf-10 to draft-ietf-11		18.6. 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
	18.6. Changes from draft-ietf-09 to draft-ietf-10		18.7. 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.
	18.7. Changes from draft-ietf-08 to draft-ietf-09		18.8. 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.
	18.8. Changes from draft-ietf-07 to draft-ietf-08		18.9. 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"
	18.9. Changes from draft-ietf-06 to draft-ietf-07		18.10. Changes from draft-ietf-06 to draft-ietf-07
	o Minor editorial changes		o Minor editorial changes
	18.10. Changes from draft-ietf-05 to draft-ietf-06		18.11. 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.
	18.11. Changes from draft-ietf-04 to draft-ietf-05		18.12. 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
	18.12. Changes from draft-ietf-03 to draft-ietf-04		18.13. 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
	18.13. Changes from draft-ietf-02 to draft-ietf-03		18.14. Changes from draft-ietf-02 to draft-ietf-03
	o Additional clarifications and corrections		o Additional clarifications and corrections
	18.14. Changes from draft-ietf-01 to draft-ietf-02		18.15. 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
	18.15. Changes from draft-ietf-00 to draft-ietf-01		18.16. 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
	18.16. Changes from draft-gellens-02 to draft-ietf-00		18.17. 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
	18.17. Changes from draft-gellens-01 to -02		18.18. 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]
	18.18. Changes from draft-gellens-00 to -01		18.19. 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
	19. References		19. References
	19.1. Normative References		19.1. Normative References
End of changes. 43 change blocks.
	123 lines changed or deleted		108 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/