< draft-ietf-ecrit-ecall-23.txt		draft-ietf-ecrit-ecall-24.txt >
	ECRIT R. Gellens		ECRIT R. Gellens
	Internet-Draft Core Technology Consulting		Internet-Draft Core Technology Consulting
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: July 20, 2017 Individual		Expires: July 23, 2017 Individual
	January 16, 2017		January 19, 2017
	Next-Generation Pan-European eCall		Next-Generation Pan-European eCall
	draft-ietf-ecrit-ecall-23.txt		draft-ietf-ecrit-ecall-24.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 the pan European in-		mechanisms to support the next generation of the pan European in-
	vehicle emergency call service defined under the eSafety initiative		vehicle emergency call service defined under the eSafety initiative
	of the European Commission (generally referred to as "eCall"). eCall		of the European Commission (generally referred to as "eCall"). eCall
	is a standardized and mandated system for a special form of emergency		is a standardized and mandated system for a special form of emergency
	calls placed by vehicles, providing real-time communications and an		calls placed by vehicles, providing real-time communications and an
	integrated set of related data.		integrated set of related data.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 July 20, 2017.		This Internet-Draft will expire on July 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 42 ¶		skipping to change at page 2, line 42 ¶
	9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 13		9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 13
	9.1.1.1. Attributes of the <ack> element . . . . . . . . . 14		9.1.1.1. Attributes of the <ack> element . . . . . . . . . 14
	9.1.1.2. Child Element of the <ack> element . . . . . . . 14		9.1.1.2. Child Element of the <ack> element . . . . . . . 14
	9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 15		9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 15
	9.1.2. The <capabilities> element . . . . . . . . . . . . . 15		9.1.2. The <capabilities> element . . . . . . . . . . . . . 15
	9.1.2.1. Child Element of the <capabilities> element . . . 15		9.1.2.1. Child Element of the <capabilities> element . . . 15
	9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16		9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16
	9.1.3. The <request> element . . . . . . . . . . . . . . . . 16		9.1.3. The <request> element . . . . . . . . . . . . . . . . 16
	9.1.3.1. Attributes of the <request> element . . . . . . . 17		9.1.3.1. Attributes of the <request> element . . . . . . . 17
	9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18		9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18
	10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19		10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 24		11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25		12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
	13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	14.1. The EmergencyCallData Media Subtree . . . . . . . . . . 28		14.1. The EmergencyCallData Media Subtree . . . . . . . . . . 28
	14.2. Service URN Registrations . . . . . . . . . . . . . . . 29		14.2. Service URN Registrations . . . . . . . . . . . . . . . 29
	14.3. MIME Structured Syntax Suffix Registration for +PER . . 29		14.3. MIME Structured Syntax Suffix Registration for +PER . . 29
	14.4. MIME Media Type Registration for		14.4. MIME Media Type Registration for
	'application/emergencyCallData.eCall.MSD+per' . . . . . 31		'application/emergencyCallData.eCall.MSD+per' . . . . . 31
	14.5. MIME Media Type Registration for		14.5. MIME Media Type Registration for
	'application/emergencyCallData.control+xml' . . . . . . 32		'application/emergencyCallData.control+xml' . . . . . . 32
	14.6. Registration of the 'eCall.MSD' entry in the Emergency		14.6. Registration of the 'eCall.MSD' entry in the Emergency
	Call Additional Data Types registry . . . . . . . . . . 33		Call Additional Data Types registry . . . . . . . . . . 33
	14.7. Registration of the 'control' entry in the Emergency		14.7. Registration of the 'control' entry in the Emergency
	Call Additional Data Types registry . . . . . . . . . . 34		Call Additional Data Types registry . . . . . . . . . . 34
	14.8. URN Sub-Namespace Registration . . . . . . . . . . . . . 34		14.8. URN Sub-Namespace Registration . . . . . . . . . . . . . 34
	14.8.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34		14.8.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34
	14.8.2. Registration for urn:ietf:params:xml:ns:control . . 34		14.8.2. Registration for
			urn:ietf:params:xml:ns:EmergencyCallData:control . . 34
	14.9. Registry Creation . . . . . . . . . . . . . . . . . . . 35		14.9. Registry Creation . . . . . . . . . . . . . . . . . . . 35
	14.9.1. Emergency Call Action Registry . . . . . . . . . . . 35		14.9.1. Emergency Call Action Registry . . . . . . . . . . . 35
	14.9.2. Emergency Call Action Failure Reason Registry . . . 36		14.9.2. Emergency Call Action Failure Reason Registry . . . 36
	14.10. The emergencyCallData.eCall.MSD INFO package . . . . . . 37		14.10. The emergencyCallData.eCall.MSD INFO package . . . . . . 37
	14.10.1. Overall Description . . . . . . . . . . . . . . . . 37		14.10.1. Overall Description . . . . . . . . . . . . . . . . 37
	14.10.2. Applicability . . . . . . . . . . . . . . . . . . . 38		14.10.2. Applicability . . . . . . . . . . . . . . . . . . . 38
	14.10.3. Info Package Name . . . . . . . . . . . . . . . . . 38		14.10.3. Info Package Name . . . . . . . . . . . . . . . . . 38
	14.10.4. Info Package Parameters . . . . . . . . . . . . . . 38		14.10.4. Info Package Parameters . . . . . . . . . . . . . . 38
	14.10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 39		14.10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 39
	14.10.6. INFO Request Body Parts . . . . . . . . . . . . . . 39		14.10.6. INFO Request Body Parts . . . . . . . . . . . . . . 39
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 42 ¶
	///----\\\ IMS emergency call with eCall URN +------+		///----\\\ IMS emergency call with eCall URN +------+
	IVS ----------------------------------------->+ PSAP |		IVS ----------------------------------------->+ PSAP |
	\\\----/// vehicle data included in call setup +------+		\\\----/// vehicle data included in call setup +------+
	Figure 2: NG-eCall		Figure 2: NG-eCall
	See Section 6 for information on how the MSD is transported within an		See Section 6 for information on how the MSD is transported within an
	NG-eCall.		NG-eCall.
	This document registers new service URN children within the "sos"		This document adds new service URN children within the "sos"
	subservice. These URNs provide the mechanism by which an eCall is		subservice. These URNs provide the mechanism by which an eCall is
	identified, and differentiate between manually and automatically		identified, and differentiate between manually and automatically
	triggered eCalls (which might be subject to different treatment,		triggered eCalls (which might be subject to different treatment,
	depending on policy). The two service URNs are:		depending on policy). The two service URNs are:
	urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual,		urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual,
	which requests resources associated with an emergency call placed by		which requests resources associated with an emergency call placed by
	an in-vehicle system, carrying a standardized set of data related to		an in-vehicle system, carrying a standardized set of data related to
	the vehicle and incident.		the vehicle and incident. These are registered in Section 14.2
	Call routing is outside the scope of this document.		Call routing is outside the scope of this document.
	8. Test Calls		8. Test Calls
	eCall requires the ability to place test calls (see [TS22.101] clause		eCall requires the ability to place test calls (see [TS22.101] clause
	10.7 and [EN_16062] clause 7.2.2). These are calls that are		10.7 and [EN_16062] clause 7.2.2). These are calls that are
	recognized and treated to some extent as eCalls but are not given		recognized and treated to some extent as eCalls but are not given
	emergency call treatment and are not handled by call takers. The		emergency call treatment and are not handled by call takers. The
	specific handling of test eCalls is not itself standardized;		specific handling of test eCalls is not itself standardized;
	typically, the test call facility allows the IVS or user to verify		typically, the test call facility allows the IVS or user to verify
	that an eCall can be successfully established with voice		that an eCall can be successfully established with voice
	communication. The IVS might also be able to verify that the MSD was		communication. The IVS might also be able to verify that the MSD was
	successfully received.		successfully received.
	A service URN starting with "test." indicates a test call. For		A service URN starting with "test." indicates a test call. For
	eCall, "urn:service:test.sos.ecall" indicates such a test feature.		eCall, "urn:service:test.sos.ecall" indicates such a test feature.
	This functionality is defined in [RFC6881].		This functionality is defined in [RFC6881].
	This document registers "urn:service:test.sos.ecall" for eCall test		This document specifies "urn:service:test.sos.ecall" for eCall test
	calls.		calls. This is registered in Section 14.2
	The circuit switched eCall test call facility is a non-emergency		The circuit switched eCall test call facility is a non-emergency
	number so does not get treated as an emergency call. For NG-eCall,		number so does not get treated as an emergency call. For NG-eCall,
	MNOs, emergency authorities, and PSAPs can determine how to treat a		MNOs, emergency authorities, and PSAPs can determine how to treat a
	vehicle call requesting the "test" service URN so that the desired		vehicle call requesting the "test" service URN so that the desired
	functionality is tested, but this is outside the scope of this		functionality is tested, but this is outside the scope of this
	document.		document.
	9. The Metadata/Control Object		9. The Metadata/Control Object
	skipping to change at page 16, line 25 ¶		skipping to change at page 16, line 25 ¶
	It is OPTIONAL for the IVS to support the <capabilities> element. If		It is OPTIONAL for the IVS to support the <capabilities> element. If
	the IVS does not send a <capabilities> element, this indicates that		the IVS does not send a <capabilities> element, this indicates that
	the only <request> action supported by the IVS is 'send-data' with		the only <request> action supported by the IVS is 'send-data' with
	'datatype' set to 'eCall.MSD'.		'datatype' set to 'eCall.MSD'.
	9.1.2.2. Capabilities Example		9.1.2.2. 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">
	<capabilities>		<capabilities>
	<request action="send-data" supported-values="eCall.MSD"/>		<request action="send-data" supported-values="eCall.MSD"/>
	</capabilities>		</capabilities>
	</EmergencyCallData.Control>		</EmergencyCallData.Control>
	Figure 4: Capabilities Example		Figure 4: Capabilities Example
	9.1.3. The <request> element		9.1.3. The <request> element
	skipping to change at page 18, line 37 ¶		skipping to change at page 18, line 37 ¶
	Direction: Sent from the PSAP to the IVS		Direction: Sent from the PSAP to the IVS
	Description: Defined for extension. Identifies the element to be		Description: Defined for extension. Identifies the element to be
	acted on. Permitted values depend on the request type. Documents		acted on. Permitted values depend on the request type. Documents
	that make use of it are expected to explain when it is required,		that make use of it are expected to explain when it is required,
	the permitted values, and how it is used.		the permitted values, and how it is used.
	9.1.3.2. Request Example		9.1.3.2. Request 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">
	<request action="send-data" datatype="eCall.MSD"/>		<request action="send-data" datatype="eCall.MSD"/>
	</emergencyCallData.control>		</emergencyCallData.control>
	Figure 5: Request Example		Figure 5: Request Example
	10. Examples		10. Examples
	Figure 6 illustrates an eCall. The call uses the request URI		Figure 6 illustrates an eCall. The call uses the request URI
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 32 ¶
	...Session Description Protocol (SDP) goes here...		...Session Description Protocol (SDP) goes here...
	--boundaryX		--boundaryX
	Content-Type: application/emergencyCallData.control+xml		Content-Type: application/emergencyCallData.control+xml
	Content-ID: <2345678901@atlanta.example.com>		Content-ID: <2345678901@atlanta.example.com>
	Content-Disposition: by-reference		Content-Disposition: by-reference
	<?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">
	<ack received="true" ref="1234567890@atlanta.example.com"/>		<ack received="true" ref="1234567890@atlanta.example.com"/>
	</emergencyCallData.control>		</emergencyCallData.control>
	--boundaryX--		--boundaryX--
	Figure 9: 200 OK response to INVITE		Figure 9: 200 OK response to INVITE
	Figure 10 illustrates a SIP INFO request containing a metadata/		Figure 10 illustrates a SIP INFO request containing a metadata/
	control block requesting an eCall MSD. (For simplicity, the example		control block requesting an eCall MSD. (For simplicity, the example
	skipping to change at page 23, line 25 ¶		skipping to change at page 23, line 25 ¶
	Content-Disposition: Info-Package		Content-Disposition: Info-Package
	Content-Length: ...		Content-Length: ...
	--boundaryZZZ		--boundaryZZZ
	Content-Disposition: by-reference		Content-Disposition: by-reference
	Content-Type: application/emergencyCallData.control+xml		Content-Type: application/emergencyCallData.control+xml
	Content-ID: <3456789012@atlanta.example.com>		Content-ID: <3456789012@atlanta.example.com>
	<?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">
	<request action="send-data" datatype="eCall.MSD"/>		<request action="send-data" datatype="eCall.MSD"/>
	</emergencyCallData.control>		</emergencyCallData.control>
	--boundaryZZZ--		--boundaryZZZ--
	Figure 10: INFO requesting MSD		Figure 10: INFO requesting MSD
	Figure 11 illustrates a SIP INFO request containing an MSD. For		Figure 11 illustrates a SIP INFO request containing an MSD. For
	simplicity, the example does not show all SIP headers. Because the		simplicity, the example does not show all SIP headers. Because the
	skipping to change at page 30, line 45 ¶		skipping to change at page 30, line 45 ¶
	Security considerations:		Security considerations:
	Because of the binary and structured nature of PER, it is not		Because of the binary and structured nature of PER, it is not
	difficult to construct malicious content that could cause		difficult to construct malicious content that could cause
	buffer overruns, stack overflows, and other attack vectors.		buffer overruns, stack overflows, and other attack vectors.
	Implementors should be aware of these issues and take		Implementors should be aware of these issues and take
	appropriate measures to guard against buffer overruns, stack		appropriate measures to guard against buffer overruns, stack
	overflows, and related attack vectors.		overflows, and related attack vectors.
	Contact: Apps Area Working Group (apps-discuss@ietf.org)		Contact: Apps Area Working Group (art@ietf.org)
	Author/Change controller:		Author/Change controller:
	The Apps Area Working Group. IESG has change control over this		The Apps Area Working Group. IESG has change control over this
	registration.		registration.
	14.4. MIME Media Type Registration for 'application/		14.4. MIME Media Type Registration for 'application/
	emergencyCallData.eCall.MSD+per'		emergencyCallData.eCall.MSD+per'
	IANA is requested to add application/emergencyCallData.eCall.MSD+per		IANA is requested to add application/emergencyCallData.eCall.MSD+per
	skipping to change at page 34, line 43 ¶		skipping to change at page 34, line 43 ¶
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>Namespace for eCall Data</title>		<title>Namespace for eCall Data</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for eCall Data</h1>		<h1>Namespace for eCall Data</h1>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	14.8.2. Registration for urn:ietf:params:xml:ns:control		14.8.2. Registration for
			urn:ietf:params:xml:ns:EmergencyCallData:control
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:control		URI: urn:ietf:params:xml:ns:EmergencyCallData:control
	Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as		Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
	delegated by the IESG <iesg@ietf.org>.		delegated by the IESG <iesg@ietf.org>.
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>Namespace for eCall Data:		<title>Namespace for Emergency Call Data Control Block</title>
	Control Block</title>		</head>
	</head>		<body>
	<body>		<h1>Namespace for Emergency Call Data Control Block</h1>
	<h1>Namespace for eCall Data</h1>		<p>See [TBD: This document].</p>
	<h2>Control Block</h2>		</body>
	<p>See [TBD: This document].</p>		</html>
	</body>		END
	</html>
	END
	14.9. Registry Creation		14.9. Registry Creation
	This document creates a new registry called "Emergency Call Metadata/		This document creates a new registry called "Emergency Call Metadata/
	Control Data". The following sub-registries are created for this		Control Data". The following sub-registries are created for this
	registry.		registry.
	14.9.1. Emergency Call Action Registry		14.9.1. Emergency Call Action Registry
	This document creates a new sub-registry called "Emergency Call		This document creates a new sub-registry called "Emergency Call
	skipping to change at page 40, line 31 ¶		skipping to change at page 40, line 31 ¶
	15. Contributors		15. Contributors
	Brian Rosen was a co-author of the original document upon which this		Brian Rosen was a co-author of the original document upon which this
	document is based.		document is based.
	16. Acknowledgements		16. Acknowledgements
	We would like to thank Bob Williams and Ban Al-Bakri for their		We would like to thank Bob Williams and Ban Al-Bakri for their
	feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Alissa		feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Alissa
	Cooper, Keith Drage, Stephen Edge, Wes George, Allison Mankin, Ivo		Cooper, Keith Drage, Stephen Edge, Wes George, Mirja Kuehlewind,
	Sedlacek, and James Winterbottom for their review and comments;		Allison Mankin, Alexey Melnikov, Ivo Sedlacek, and James Winterbottom
	Robert Sparks and Paul Kyzivat for their help with the SIP		for their review and comments; Robert Sparks and Paul Kyzivat for
	mechanisms; Mark Baker and Ned Freed for their help with the media		their help with the SIP mechanisms; Mark Baker and Ned Freed for
	subtype registration issue. We would like to thank Michael Montag,		their help with the media subtype registration issue. We would like
	Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz for their help		to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and
	with the original document upon which this document is based.		Ulrich Dietz for their help with the original document upon which
	Christer Holmberg deserves special mention for his many detailed		this document is based. Christer Holmberg deserves special mention
	reviews.		for his many detailed reviews.
	17. Changes from Previous Versions		17. Changes from Previous Versions
	RFC Editor: Please remove this section prior to publication.		RFC Editor: Please remove this section prior to publication.
	17.1. Changes from draft-ietf-19 to draft-ietf-20		17.1. Changes from draft-ietf-19 to draft-ietf-20
	o Fixed various nits		o Fixed various nits
	17.2. Changes from draft-ietf-18 to draft-ietf-19		17.2. Changes from draft-ietf-18 to draft-ietf-19
	skipping to change at page 46, line 37 ¶		skipping to change at page 46, line 37 ¶
	Circuit Switched Networks, EN 16062", April 2015.		Circuit Switched Networks, EN 16062", April 2015.
	[EN_16072]		[EN_16072]
	CEN, , "Intelligent transport systems -- eSafety -- Pan-		CEN, , "Intelligent transport systems -- eSafety -- Pan-
	European eCall operating requirements, EN 16072", April		European eCall operating requirements, EN 16072", April
	2015.		2015.
	[I-D.ietf-ecrit-car-crash]		[I-D.ietf-ecrit-car-crash]
	Gellens, R., Rosen, B., and H. Tschofenig, "Next-		Gellens, R., Rosen, B., and H. Tschofenig, "Next-
	Generation Vehicle-Initiated Emergency Calls", draft-ietf-		Generation Vehicle-Initiated Emergency Calls", draft-ietf-
	ecrit-car-crash-20 (work in progress), December 2016.		ecrit-car-crash-21 (work in progress), January 2017.
	[ITU.X691]		[ITU.X691]
	International Telecommunications Union, , "Information		International Telecommunications Union, , "Information
	technology -- ASN.1 encoding rules: Specification of		technology -- ASN.1 encoding rules: Specification of
	Packed Encoding Rules (PER), ITU-T X.691", July 2002,		Packed Encoding Rules (PER), ITU-T X.691", July 2002,
	<https://www.itu.int/ITU-T/studygroups/com17/languages/		<https://www.itu.int/ITU-T/studygroups/com17/languages/
	X.691-0207.pdf>.		X.691-0207.pdf>.
	[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for		[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for
	VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),		VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),
End of changes. 18 change blocks.
	50 lines changed or deleted		45 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/