draft-ietf-ecrit-car-crash-18.txt		draft-ietf-ecrit-car-crash-19.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 21, 2017 NeuStar, Inc.		Expires: May 18, 2017 NeuStar, Inc.
	H. Tschofenig		H. Tschofenig
	Individual		Individual
	October 18, 2016		November 14, 2016
	Next-Generation Vehicle-Initiated Emergency Calls		Next-Generation Vehicle-Initiated Emergency Calls
	draft-ietf-ecrit-car-crash-18.txt		draft-ietf-ecrit-car-crash-19.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 21, 2017.		This Internet-Draft will expire on May 18, 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 43 ¶		skipping to change at page 2, line 43 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 . . . . . . . . . . . . . . . . 10
	6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 14		7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16		9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 17
	10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17		10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17
	10.1. New values for the 'action' attribute' . . . . . . . . . 18		10.1. New values for the 'action' attribute' . . . . . . . . . 19
	10.2. Request Example . . . . . . . . . . . . . . . . . . . . 19		10.2. Request Example . . . . . . . . . . . . . . . . . . . . 19
	10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 19		10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 20
	10.4. The <capabilities> element . . . . . . . . . . . . . . . 20		10.4. The <capabilities> element . . . . . . . . . . . . . . . 20
	11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22		12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22
	12.1. Overall Description . . . . . . . . . . . . . . . . . . 22		12.1. Overall Description . . . . . . . . . . . . . . . . . . 23
	12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23		12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23
	12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23		12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24
	12.4. Info Package Parameters . . . . . . . . . . . . . . . . 23		12.4. Info Package Parameters . . . . . . . . . . . . . . . . 24
	12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23		12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24
	12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24		12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24
	12.7. Info Package Usage Restrictions . . . . . . . . . . . . 24		12.7. Info Package Usage Restrictions . . . . . . . . . . . . 24
	12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24		12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25
	12.9. Info Package Security Considerations . . . . . . . . . . 25		12.9. Info Package Security Considerations . . . . . . . . . . 25
	12.10. Implementation Details . . . . . . . . . . . . . . . . . 25		12.10. Implementation Details . . . . . . . . . . . . . . . . . 25
	12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25		12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
	13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 31		14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31		15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	16.1. MIME Media 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 . . . . . . . . . . . . . . . . . . . 33		16.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
	16.4. Static Message Registry . . . . . . . . . . . . . . . . 34		16.4. Emergency Call Static Message Registry . . . . . . . . . 34
	16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35		16.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 35
	16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36		16.6. Emergency Call Vehicle 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-17 to draft-ietf-18 . . . . . . 37		18.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 37
	18.2. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38		18.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38
	18.3. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38		18.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38
	18.4. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38		18.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38
	18.5. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38		18.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
	18.6. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38		18.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
	18.7. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38		18.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
	18.8. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38		18.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
	18.9. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39		18.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39
	18.10. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39		18.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39
	18.11. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39		18.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39
	18.12. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39		18.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39
	18.13. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39		18.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
	18.14. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39		18.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
	18.15. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39		18.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
	18.16. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40		18.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40
	18.17. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40		18.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40
	18.18. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40		18.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40
	18.19. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40		18.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
			18.20. 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 . . . . . . . . . . . . . . . . . 42		19.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].
	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 21, line 12 ¶		skipping to change at page 21, line 23 ¶
	values' attribute set to all supported lamp IDs. A registry is		values' attribute set to all supported lamp IDs. A registry is
	created in Section 16.5 to contain lamp ID values.		created in Section 16.5 to contain lamp ID values.
	If the "enable-camera" action is supported, a <request> child element		If the "enable-camera" action is supported, a <request> child element
	with the 'action' attribute set to "enable-camera" is included, with		with the 'action' attribute set to "enable-camera" is included, with
	the 'supported-values' attribute set to all supported camera IDs. A		the 'supported-values' attribute set to all supported camera IDs. A
	registry is created in Section 16.6 to contain camera ID values.		registry is created in Section 16.6 to contain camera ID values.
	10.4.1. Capabilities Example		10.4.1. Capabilities Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<EmergencyCallData.control		<EmergencyCallData.control
	xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"		xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<capabilities>		<capabilities>
	<request action="send-data" supported-values="VEDS"/>		<request action="send-data" supported-values="VEDS"/>
	<request action="lamp"		<request action="lamp"
	supported-values="head;interior;fog-front;fog-rear;brake;		supported-values="head;interior;fog-front;
	position-front;position-rear;turn-left;turn-right;hazard"/>		fog-rear;brake;position-front;position-rear;
	<request action="msg-static" msgid="3"/>		turn-left;turn-right;hazard"/>
	<request action="msg-dynamic"/>		<request action="msg-static" msgid="3"/>
	<request action="honk"/>		<request action="msg-dynamic"/>
	<request action="enable-camera" supported-values="backup; interior"/>		<request action="honk"/>
	</capabilities>		<request action="enable-camera"
			supported-values="backup; interior"/>
			</capabilities>
	</EmergencyCallData.control>		</EmergencyCallData.control>
	Figure 9: Capabilities Example		Figure 9: Capabilities Example
	11. Test Calls		11. Test Calls
	An NG-ACN test call is a call that is recognized and treated to some		An NG-ACN test call is a call that is recognized and treated to some
	extent as an NG-ACN call but not given emergency call treatment and		extent as an NG-ACN call but not given emergency call treatment and
	not handled by a call taker. The specific handling of test NG-ACN		not handled by a call taker. The specific handling of test NG-ACN
	calls is not itself standardized; the test call facility is intended		calls is not itself standardized; the test call facility is intended
	to allow the IVS, user, or TSP to verify that an NG-ACN call can be		to allow the IVS, user, or TSP to verify that an NG-ACN call can be
	skipping to change at page 32, line 4 ¶		skipping to change at page 32, line 4 ¶
	implementations need to be careful that access is only provided		implementations need to be careful that access is only provided
	within the context of an emergency call or to an emergency services		within the context of an emergency call or to an emergency services
	provider (e.g., by verifying that the request for camera access is		provider (e.g., by verifying that the request for camera access is
	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].		"Emergency Call Metadata/Control Data" registry created in
	This document registers a new INFO package.		[I-D.ietf-ecrit-ecall]. This document registers a new INFO package.
	16.1. MIME Media 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 6838 [RFC6838] and guidelines in
	RFC 3023 [RFC3023].		RFC 7303 [RFC7303].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: EmergencyCallData.VEDS+xml		MIME subtype name: EmergencyCallData.VEDS+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset
	Indicates the character encoding of enclosed XML.		Indicates the character encoding of enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 7303 [RFC7303].
	Security considerations:		Security considerations:
	This media type is designed to carry vehicle crash data during		This media type is designed to carry vehicle crash data during
	an emergency call.		an emergency call.
	This data can contain personal information including vehicle		This data can contain personal information including vehicle
	VIN, location, direction, etc. Appropriate precautions need to		VIN, location, direction, etc. Appropriate precautions need to
	be taken to limit unauthorized access, inappropriate disclosure		be taken to limit unauthorized access, inappropriate disclosure
	to third parties, and eavesdropping of this information.		to third parties, and eavesdropping of this information.
	skipping to change at page 33, line 38 ¶		skipping to change at page 33, line 38 ¶
	Data registry		Data registry
	This specification requests IANA to add the 'VEDS' entry to the		This specification requests IANA to add the 'VEDS' entry to the
	Emergency Call Additional Data registry, with a reference to this		Emergency Call Additional Data registry, with a reference to this
	document. The Emergency Call Additional Data registry was		document. The Emergency Call Additional Data registry was
	established by [RFC7852].		established by [RFC7852].
	16.3. New Action Values		16.3. New Action Values
	This document adds new values for the 'action' attribute of the		This document adds new values for the 'action' attribute of the
	<request> element in the "Action Registry" registry created by		<request> element in the "Emergency Call Action" registry created by
	[I-D.ietf-ecrit-ecall].		[I-D.ietf-ecrit-ecall].
	+---------------+--------------------------------------+		+---------------+--------------------------------------+
	| Name | Description |		| Name | Description |
	+---------------+--------------------------------------+		+---------------+--------------------------------------+
	| msg-static | Section 10.1 of [TBD: THIS DOCUMENT] |		| msg-static | Section 10.1 of [TBD: THIS DOCUMENT] |
	| | |		| | |
	| msg-dynamic | Section 10.1 of [TBD: THIS DOCUMENT] |		| msg-dynamic | Section 10.1 of [TBD: THIS DOCUMENT] |
	| | |		| | |
	| honk | Section 10.1 of [TBD: THIS DOCUMENT] |		| honk | Section 10.1 of [TBD: THIS DOCUMENT] |
	| | |		| | |
	| lamp | Section 10.1 of [TBD: THIS DOCUMENT] |		| lamp | Section 10.1 of [TBD: THIS DOCUMENT] |
	| | |		| | |
	| enable-camera | Section 10.1 of [TBD: THIS DOCUMENT] |		| enable-camera | Section 10.1 of [TBD: THIS DOCUMENT] |
	+---------------+--------------------------------------+		+---------------+--------------------------------------+
	Table 2: Action Registry New Values		Table 2: Emergency Call Action Registry New Values
	16.4. Static Message Registry		16.4. Emergency Call Static Message Registry
	This document creates a new sub-registry called "Static Message		This document creates a new sub-registry called "Emergency Call
	Registry" in the "Metadata/Control Data" registry established by		Static Message" in the "Emergency Call Metadata/Control Data"
	[I-D.ietf-ecrit-ecall]. Because all compliant vehicles are expected		registry established by [I-D.ietf-ecrit-ecall]. Because all
	to support all static messages translated into all languages		compliant vehicles are expected to support all static messages
	supported by the vehicle, it is important to limit the number of such		translated into all languages supported by the vehicle, it is
	messages. As defined in [RFC5226], this registry operates under		important to limit the number of such messages. As defined in
	"Publication Required" rules, which require a stable, public document		[RFC5226], this registry operates under "Publication Required" rules,
	and implies expert review of the publication. The expert should		which require a stable, public document and implies expert review of
	determine that the document has been published by an appropriate		the publication. The expert should determine that the document has
	emergency services organization (e.g., NENA, EENA, APCO) or by the		been published by an appropriate emergency services organization
	IETF with input from an emergency services organization, and that the		(e.g., NENA, EENA, APCO) or by the IETF with input from an emergency
	proposed message is sufficiently distinguishable from other messages.		services organization, and that the proposed message is sufficiently
			distinguishable from other messages.
	The contents of this registry are:		The contents of this registry are:
	ID: An integer identifier to be used in the 'msgid' attribute of a		ID: An integer identifier to be used in the 'msgid' attribute of a
	metadata/control <request> element.		metadata/control <request> element.
	Message: The text of the message. Messages are listed in the		Message: The text of the message. Messages are listed in the
	registry in English; vehicles are expected to implement		registry in English; vehicles are expected to implement
	translations into languages supported by the vehicle.		translations into languages supported by the vehicle.
	skipping to change at page 35, line 8 ¶		skipping to change at page 35, line 8 ¶
	determined by the registrant; IANA assigns the IDs. Each message is		determined by the registrant; IANA assigns the IDs. Each message is
	assigned a consecutive integer value as its ID. This allows an IVS		assigned a consecutive integer value as its ID. This allows an IVS
	to indicate by a single integer value that it supports all messages		to indicate by a single integer value that it supports all messages
	with that value or lower.		with that value or lower.
	The initial set of values is listed in Table 3.		The initial set of values is listed in Table 3.
	+----+--------------------------------------------------------------+		+----+--------------------------------------------------------------+
	| ID | Message |		| ID | Message |
	+----+--------------------------------------------------------------+		+----+--------------------------------------------------------------+
	| 1 | Emergency authorities are aware of your incident and |		| 1 | Emergency services has noted your information and location, |
	| | location, but are unable to speak with you right now. We |		| | but cannot speak with you right now. We will help you as |
	| | will help you as soon as possible. |		| | soon as possible. |
	+----+--------------------------------------------------------------+		+----+--------------------------------------------------------------+
	Table 3: Static Message Registry		Table 3: Emergency Call Static Message Registry Initial Values
	16.5. Lamp ID Registry		16.5. Emergency Call Vehicle Lamp ID Registry
	This document creates a new sub-registry called "Lamp ID Registry" in		This document creates a new sub-registry called "Emergency Call
	the "Metadata/Control Data" registry established by		Vehicle Lamp ID" in the "Emergency Call Metadata/Control Data"
	[I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies		registry established by [I-D.ietf-ecrit-ecall]. This new sub-
	the names of automotive lamps (lights). As defined in [RFC5226],		registry uniquely identifies the names of automotive lamps (lights).
	this registry operates under "Expert Review" rules. The expert		As defined in [RFC5226], this registry operates under "Expert Review"
	should determine that the proposed lamp name is clearly		rules. The expert should determine that the proposed lamp name is
	understandable and is sufficiently distinguishable from other lamp		clearly understandable and is sufficiently distinguishable from other
	names.		lamp names.
	The contents of this registry are:		The contents of this registry are:
	Name: The identifier to be used in the 'lamp-ID' attribute of a		Name: The identifier to be used in the 'lamp-ID' attribute of a
	metadata/control <request> element.		metadata/control <request> element.
	Description: A description of the lamp (light).		Description: A description of the lamp (light).
	The initial set of values is listed in Table 4.		The initial set of values is listed in Table 4.
	skipping to change at page 36, line 31 ¶		skipping to change at page 36, line 31 ¶
	| | |		| | |
	| position-rear | Rear position/parking/standing lamps |		| position-rear | Rear position/parking/standing lamps |
	| | |		| | |
	| turn-left | Left turn/directional lamps |		| turn-left | Left turn/directional lamps |
	| | |		| | |
	| turn-right | Right turn/directional lamps |		| turn-right | Right turn/directional lamps |
	| | |		| | |
	| hazard | Hazard/four-way lamps |		| hazard | Hazard/four-way lamps |
	+----------------+---------------------------------------------+		+----------------+---------------------------------------------+
	Table 4: Lamp ID Registry Initial Values		Table 4: Emergency Call Lamp ID Registry Initial Values
	16.6. Camera ID Registry		16.6. Emergency Call Vehicle Camera ID Registry
	This document creates a new sub-registry called "Camera ID Registry"		This document creates a new sub-registry called "Emergency Call
	in the "Metadata/Control Data" registry established by		Vehicle Camera ID" in the "Emergency Call Metadata/Control Data"
	[I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies		registry established by [I-D.ietf-ecrit-ecall]. This new sub-
	automotive cameras. As defined in [RFC5226], this registry operates		registry uniquely identifies automotive cameras. As defined in
	under "Expert Review" rules. The expert should determine that the		[RFC5226], this registry operates under "Expert Review" rules. The
	proposed camera name is clearly understandable and is sufficiently		expert should determine that the proposed camera name is clearly
	distinguishable from other camera names.		understandable and is sufficiently distinguishable from other camera
			names.
	The contents of this registry are:		The contents of this registry are:
	Name: The identifier to be used in the 'camera-ID' attribute of a		Name: The identifier to be used in the 'camera-ID' attribute of a
	control <request> element.		control <request> element.
	Description: A description of the camera.		Description: A description of the camera.
	The initial set of values is listed in Table 5.		The initial set of values is listed in Table 5.
	skipping to change at page 37, line 34 ¶		skipping to change at page 37, line 34 ¶
	| | |		| | |
	| lane | Used by systems to identify road lane and/or |		| lane | Used by systems to identify road lane and/or |
	| | monitor vehicle's position within lane |		| | monitor vehicle's position within lane |
	| | |		| | |
	| interior | Shows the interior (e.g., driver) |		| interior | Shows the interior (e.g., driver) |
	| | |		| | |
	| night-front | Night-vision view of what is in front of the |		| night-front | Night-vision view of what is in front of the |
	| | vehicle |		| | vehicle |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	Table 5: Camera ID Registry Initial Values		Table 5: Emergency Call Vehicle Camera ID Registry Initial Values
	17. Acknowledgements		17. Acknowledgements
	We would like to thank Lena Chaponniere, Stephen Edge, and Christer		We would like to thank Lena Chaponniere, Stephen Edge, Christer
	Holmberg for their review and suggestions; Robert Sparks and Paul		Holmberg, and Allison Mankin for their review and suggestions; Robert
	Kyzivat for their help with the SIP mechanisms; Michael Montag,		Sparks and Paul Kyzivat for their help with the SIP mechanisms;
	Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex		Michael Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar
	Buddenberg for their feedback; and Ulrich Dietz for his help with		Hellstrom, and Rex Buddenberg for their feedback; and Ulrich Dietz
	earlier versions of the original version of this document.		for his help with 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-17 to draft-ietf-18		18.1. Changes from draft-ietf-18 to draft-ietf-19
			o Fixed various nits
			18.2. Changes from draft-ietf-17 to draft-ietf-18
	o Added additional text to "Rate of Info Requests"		o Added additional text to "Rate of Info Requests"
	o Further corrected "content type" to "media type"		o Further corrected "content type" to "media type"
	18.2. Changes from draft-ietf-16 to draft-ietf-17		18.3. 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.3. Changes from draft-ietf-14 to draft-ietf-15		18.4. 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.4. Changes from draft-ietf-13 to draft-ietf-14		18.5. 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.5. Changes from draft-ietf-11 to draft-ietf-13		18.6. Changes from draft-ietf-11 to draft-ietf-13
	o Fixed typos		o Fixed typos
	18.6. Changes from draft-ietf-10 to draft-ietf-11		18.7. 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.7. Changes from draft-ietf-09 to draft-ietf-10		18.8. 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.8. Changes from draft-ietf-08 to draft-ietf-09		18.9. 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.9. Changes from draft-ietf-07 to draft-ietf-08		18.10. 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.10. Changes from draft-ietf-06 to draft-ietf-07		18.11. Changes from draft-ietf-06 to draft-ietf-07
	o Minor editorial changes		o Minor editorial changes
	18.11. Changes from draft-ietf-05 to draft-ietf-06		18.12. 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.12. Changes from draft-ietf-04 to draft-ietf-05		18.13. 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.13. Changes from draft-ietf-03 to draft-ietf-04		18.14. 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.14. Changes from draft-ietf-02 to draft-ietf-03		18.15. Changes from draft-ietf-02 to draft-ietf-03
	o Additional clarifications and corrections		o Additional clarifications and corrections
	18.15. Changes from draft-ietf-01 to draft-ietf-02		18.16. 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.16. Changes from draft-ietf-00 to draft-ietf-01		18.17. 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.17. Changes from draft-gellens-02 to draft-ietf-00		18.18. 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.18. Changes from draft-gellens-01 to -02		18.19. 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.19. Changes from draft-gellens-00 to -01		18.20. 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
	[I-D.ietf-ecrit-ecall]		[I-D.ietf-ecrit-ecall]
	Gellens, R. and H. Tschofenig, "Next-Generation Pan-		Gellens, R. and H. Tschofenig, "Next-Generation Pan-
	European eCall", draft-ietf-ecrit-ecall-17 (work in		European eCall", draft-ietf-ecrit-ecall-19 (work in
	progress), October 2016.		progress), October 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
	<http://www.rfc-editor.org/info/rfc3023>.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
	<http://www.rfc-editor.org/info/rfc4119>.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
	December 2005, <http://www.rfc-editor.org/info/rfc4288>.
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	Emergency and Other Well-Known Services", RFC 5031,
	DOI 10.17487/RFC5031, January 2008,
	<http://www.rfc-editor.org/info/rfc5031>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Presence Information Data Format Location Object (PIDF-LO)		Specifications and Registration Procedures", BCP 13,
	Usage Clarification, Considerations, and Recommendations",		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	RFC 5491, DOI 10.17487/RFC5491, March 2009,		<http://www.rfc-editor.org/info/rfc6838>.
	<http://www.rfc-editor.org/info/rfc5491>.
	[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
	Thomson, "Dynamic Extensions to the Presence Information
	Data Format Location Object (PIDF-LO)", RFC 5962,
	DOI 10.17487/RFC5962, September 2010,
	<http://www.rfc-editor.org/info/rfc5962>.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
	2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",		Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,		BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
	<http://www.rfc-editor.org/info/rfc6881>.		<http://www.rfc-editor.org/info/rfc6881>.
			[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
			DOI 10.17487/RFC7303, July 2014,
			<http://www.rfc-editor.org/info/rfc7303>.
	[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and		[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
	J. Winterbottom, "Additional Data Related to an Emergency		J. Winterbottom, "Additional Data Related to an Emergency
	Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,		Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
	<http://www.rfc-editor.org/info/rfc7852>.		<http://www.rfc-editor.org/info/rfc7852>.
	[VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/		[VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/
	NENA Data Standardization Workgroup, , "Vehicular		NENA Data Standardization Workgroup, , "Vehicular
	Emergency Data Set (VEDS) version 3", July 2012,		Emergency Data Set (VEDS) version 3", July 2012,
	<https://www.apcointl.org/resources/telematics/aacn-and-		<https://www.apcointl.org/resources/telematics/aacn-and-
	veds.html>.		veds.html>.
	skipping to change at page 42, line 23 ¶		skipping to change at page 42, line 10 ¶
	Shanmugam, "Security Threats and Requirements for		Shanmugam, "Security Threats and Requirements for
	Emergency Call Marking and Mapping", RFC 5069,		Emergency Call Marking and Mapping", RFC 5069,
	DOI 10.17487/RFC5069, January 2008,		DOI 10.17487/RFC5069, January 2008,
	<http://www.rfc-editor.org/info/rfc5069>.		<http://www.rfc-editor.org/info/rfc5069>.
	[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session		[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
	Initiation Protocol (SIP) INFO Method and Package		Initiation Protocol (SIP) INFO Method and Package
	Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,		Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
	<http://www.rfc-editor.org/info/rfc6086>.		<http://www.rfc-editor.org/info/rfc6086>.
			[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
			"Framework for Emergency Calling Using Internet
			Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
			2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,		[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
	"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,		"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
	December 2014, <http://www.rfc-editor.org/info/rfc7378>.		December 2014, <http://www.rfc-editor.org/info/rfc7378>.
	[triage-2008]		[triage-2008]
	National Center for Injury Prevention and Control, and		National Center for Injury Prevention and Control, and
	Centers for Disease Control and Prevention,		Centers for Disease Control and Prevention,
	"Recommendations from the Expert Panel: Advanced Automatic		"Recommendations from the Expert Panel: Advanced Automatic
	Collision Notification and Triage of the Injured Patient",		Collision Notification and Triage of the Injured Patient",
	2008, <https://stacks.cdc.gov/view/cdc/5304/>.		2008, <https://stacks.cdc.gov/view/cdc/5304/>.
End of changes. 57 change blocks.
	154 lines changed or deleted		144 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/