< draft-ietf-ecrit-ecall-10.txt		draft-ietf-ecrit-ecall-11.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: January 22, 2017 Individual		Expires: February 2, 2017 Individual
	July 21, 2016		August 1, 2016
	Next-Generation Pan-European eCall		Next-Generation Pan-European eCall
	draft-ietf-ecrit-ecall-10.txt		draft-ietf-ecrit-ecall-11.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.
	This document also registers a MIME Content Type and an Emergency		This document also registers MIME Content Types and an Emergency Call
	Call Additional Data Block for the eCall vehicle data and metadata/		Additional Data Blocks for the eCall vehicle data and metadata/
	control data.		control data.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 22, 2017.		This Internet-Draft will expire on February 2, 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 23 ¶		skipping to change at page 2, line 23 ¶
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4		2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6		4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6
	5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7		6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 9		7.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 9
	8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10		9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 10
	9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11		9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 12
	9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12		9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12
	9.1.1.1. Attributes of the <ack> element . . . . . . . . . 12		9.1.1.1. Attributes of the <ack> element . . . . . . . . . 12
	9.1.1.2. Child Elements of the <ack> element . . . . . . . 13		9.1.1.2. Child Element of the <ack> element . . . . . . . 13
	9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 13		9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14
	9.1.2. The <request> element . . . . . . . . . . . . . . . . 13		9.1.2. The <capabilities> element . . . . . . . . . . . . . 14
	9.1.2.1. Attributes of the <request> element . . . . . . . 13		9.1.2.1. Child Elements of the <capabilities> element . . 14
	9.1.2.2. Request Example . . . . . . . . . . . . . . . . . 14		9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15
	10. The emergencyCallData.eCall INFO package . . . . . . . . . . 14		9.1.3. The <request> element . . . . . . . . . . . . . . . . 15
	10.1. INFO Package Requirements . . . . . . . . . . . . . . . 14		9.1.3.1. Attributes of the <request> element . . . . . . . 15
	10.1.1. Overall Description . . . . . . . . . . . . . . . . 15		9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 17
	10.1.2. Applicability . . . . . . . . . . . . . . . . . . . 15		10. The emergencyCallData.eCall.MSD INFO package . . . . . . . . 17
	10.1.3. Info Package Name . . . . . . . . . . . . . . . . . 15		10.1. INFO Package Requirements . . . . . . . . . . . . . . . 17
	10.1.4. Info Package Parameters . . . . . . . . . . . . . . 16		10.1.1. Overall Description . . . . . . . . . . . . . . . . 18
	10.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 16		10.1.2. Applicability . . . . . . . . . . . . . . . . . . . 18
	10.1.6. INFO Message Body Parts . . . . . . . . . . . . . . 16		10.1.3. Info Package Name . . . . . . . . . . . . . . . . . 18
	10.1.7. Info Package Usage Restrictions . . . . . . . . . . 16		10.1.4. Info Package Parameters . . . . . . . . . . . . . . 19
	10.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . 16		10.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 19
	10.1.9. Info Package Security Considerations . . . . . . . . 16		10.1.6. INFO Message Body Parts . . . . . . . . . . . . . . 19
	10.1.10. Implementation Details . . . . . . . . . . . . . . . 16		10.1.7. Info Package Usage Restrictions . . . . . . . . . . 19
	10.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 17		10.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . 19
	11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10.1.9. Info Package Security Considerations . . . . . . . . 19
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 22		10.1.10. Implementation Details . . . . . . . . . . . . . . . 19
	13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23		10.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 19
	14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	15.1. Service URN Registrations . . . . . . . . . . . . . . . 25		13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
			14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26
			15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
			15.1. Service URN Registrations . . . . . . . . . . . . . . . 29
	15.2. MIME Content-type Registration for		15.2. MIME Content-type Registration for
	'application/emergencyCallData.eCall.MSD+per' . . . . . 26		'application/emergencyCallData.eCall.MSD+per' . . . . . 30
	15.3. MIME Content-type Registration for		15.3. MIME Content-type Registration for
	'application/emergencyCallData.eCall.control+xml' . . . 27		'application/emergencyCallData.eCall.control+xml' . . . 31
	15.4. Registration of the 'eCall.MSD' entry in the Emergency		15.4. Registration of the 'eCall.MSD' entry in the Emergency
	Call Additional Data Blocks registry . . . . . . . . . . 29		Call Additional Data Blocks registry . . . . . . . . . . 32
	15.5. Registration of the 'eCall.control' entry in the		15.5. Registration of the 'eCall.control' entry in the
	Emergency Call Additional Data Blocks registry . . . . . 29		Emergency Call Additional Data Blocks registry . . . . . 33
	15.6. Registration of the emergencyCallData.eCall Info Package 29		15.6. Registration of the emergencyCallData.eCall Info Package 33
	15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 29		15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33
	15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 29		15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33
	15.7.2. Registration for		15.7.2. Registration for
	urn:ietf:params:xml:ns:eCall:control . . . . . . . . 30		urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34
	15.8. Registry creation . . . . . . . . . . . . . . . . . . . 31		15.8. Registry creation . . . . . . . . . . . . . . . . . . . 34
	15.8.1. eCall Control Action Registry . . . . . . . . . . . 31		15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 34
	15.8.2. eCall Control Extension Registry . . . . . . . . . . 32		15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 35
	16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32		16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
	17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	18. Changes from Previous Versions . . . . . . . . . . . . . . . 33		18. Changes from Previous Versions . . . . . . . . . . . . . . . 36
	18.1. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 33		18.1. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 36
	18.2. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 33		18.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 37
	18.3. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 34		18.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 37
	18.4. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 34		18.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 37
	18.5. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 34		18.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38
	18.6. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 34		18.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38
	18.7. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 34		18.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38
	18.8. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 34		18.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38
	18.9. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 35		18.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 38
	18.10. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 35		18.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39
	18.11. Changes from draft-gellens-02 to -03 . . . . . . . . . . 35		18.11. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 39
	18.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 35		18.12. Changes from draft-gellens-02 to -03 . . . . . . . . . . 39
	18.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 35		18.13. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		18.14. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39
	19.1. Normative References . . . . . . . . . . . . . . . . . . 36		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	19.2. Informative references . . . . . . . . . . . . . . . . . 37		19.1. Normative References . . . . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		19.2. Informative references . . . . . . . . . . . . . . . . . 41
			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].
	Additionally, we use the following abbreviations:		Additionally, we use the following abbreviations:
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	call setup mark the call as an eCall, and further indicate if the		call setup mark the call as an eCall, and further indicate if the
	call was automatically or manually triggered. The call is routed to		call was automatically or manually triggered. The call is routed to
	an eCall-capable PSAP, a voice channel is established between the		an eCall-capable PSAP, a voice channel is established between the
	vehicle and the PSAP, and an eCall in-band modem is used to carry a		vehicle and the PSAP, and an eCall in-band modem is used to carry a
	defined set of vehicle, sensor (e.g., crash related), and location		defined set of vehicle, sensor (e.g., crash related), and location
	data (the Minimum Set of Data or MSD) within the voice channel. The		data (the Minimum Set of Data or MSD) within the voice channel. The
	same in-band mechanism is used for the PSAP to acknowledge successful		same in-band mechanism is used for the PSAP to acknowledge successful
	receipt of the MSD, and to request the vehicle to send a new MSD		receipt of the MSD, and to request the vehicle to send a new MSD
	(e.g., to check if the state of or location of the vehicle or its		(e.g., to check if the state of or location of the vehicle or its
	occupants has changed). NG-eCall moves from circuit switched to all-		occupants has changed). NG-eCall moves from circuit switched to all-
	IP, and carries the vehicle data and other eCall-specific data as		IP, and carries the vehicle data and eCall signaling as additional
	additional data carried with the call. This document describes how		data carried with the call. This document describes how IETF
	IETF mechanisms for IP-based emergency calls, including [RFC6443] and		mechanisms for IP-based emergency calls, including [RFC6443] and
	[I-D.ietf-ecrit-additional-data] are used to provide the signaling		[RFC7852] are used to provide the signaling and data exchange of the
	and data exchange of the next generation of pan-European eCall.		next generation of pan-European eCall.
	The European Telecommunications Standards Institute (ETSI) [SDO-ETSI]		The European Telecommunications Standards Institute (ETSI) [SDO-ETSI]
	has published a Technical Report titled "Mobile Standards Group		has published a Technical Report titled "Mobile Standards Group
	(MSG); eCall for VoIP" [MSG_TR] that presents findings and		(MSG); eCall for VoIP" [MSG_TR] that presents findings and
	recommendations regarding support for eCall in an all-IP environment.		recommendations regarding support for eCall in an all-IP environment.
	The recommendations include the use of 3GPP IMS emergency calling		The recommendations include the use of 3GPP IMS emergency calling
	with additional elements identifying the call as an eCall and as		with additional elements identifying the call as an eCall and as
	carrying eCall data and with mechanisms for carrying the data and		carrying eCall data and with mechanisms for carrying the data and
	eCall-specific signaling. 3GPP IMS emergency services support		eCall signaling. 3GPP IMS emergency services support multimedia,
	multimedia, providing the ability to carry voice, text, and video.		providing the ability to carry voice, text, and video. This
	This capability is referred to within 3GPP as Multimedia Emergency		capability is referred to within 3GPP as Multimedia Emergency
	Services (MMES).		Services (MMES).
	A transition period will exist during which time the various entities		A transition period will exist during which time the various entities
	involved in initiating and handling an eCall might support next-		involved in initiating and handling an eCall might support next-
	generation eCall, legacy eCall, or both. The issues of migration and		generation eCall, legacy eCall, or both. The issues of migration and
	co-existence during the transition period is outside the scope of		co-existence during the transition period are outside the scope of
	this document.		this document.
			The MSD is carried in the MIME type 'application/
			emergencyCallData.eCall.MSD+per' and the metadata/control block is
			carried in the MIME type 'application/
			emergencyCallData.eCall.control+xml' (both of which are registered in
			this document).
	4. eCall Requirements		4. eCall Requirements
	eCall requirements are specified by CEN in [EN_16072] and by 3GPP in		eCall requirements are specified by CEN in [EN_16072] and by 3GPP in
	[TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle		[TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle
	data are contained in EN 15722 [msd].		data are contained in EN 15722 [msd].
	5. Vehicle Data		5. Vehicle Data
	Pan-European eCall provides a standardized and mandated set of		Pan-European eCall provides a standardized and mandated set of
	vehicle related data, known as the Minimum Set of Data (MSD). The		vehicle related data, known as the Minimum Set of Data (MSD). The
	skipping to change at page 6, line 46 ¶		skipping to change at page 7, line 4 ¶
	which is specified in Annex A of EN 15722 [msd] (the XML encoding		which is specified in Annex A of EN 15722 [msd] (the XML encoding
	specified in Annex C is not used in this document).		specified in Annex C is not used in this document).
	This document registers the 'application/		This document registers the 'application/
	emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD		emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD
	to be carried in SIP. As an ASN.1 PER encoded object, the data is		to be carried in SIP. As an ASN.1 PER encoded object, the data is
	binary and transported using binary content transfer encoding within		binary and transported using binary content transfer encoding within
	SIP messages. This document also adds the 'eCall.MSD' entry to the		SIP messages. This document also adds the 'eCall.MSD' entry to the
	Emergency Call Additional Data Blocks registry to enable the MSD to		Emergency Call Additional Data Blocks registry to enable the MSD to
	be recognized as such in a SIP-based eCall emergency call. (See		be recognized as such in a SIP-based eCall emergency call. (See
	[I-D.ietf-ecrit-additional-data] for more information about the
	registry and how it is used.)		[RFC7852] for more information about the registry and how it is
			used.)
	See Section 6 for a discussion of how the MSD vehicle data is		See Section 6 for a discussion of how the MSD vehicle data is
	conveyed in an NG-eCall.		conveyed in an NG-eCall.
	6. Data Transport		6. Data Transport
	The "Additional Data related to an Emergency Call" document		[RFC7852] establishes a general mechanism for attaching blocks of
	[I-D.ietf-ecrit-additional-data] establishes a general mechanism for		data to a SIP emergency call. This mechanism permits certain
	attaching blocks of data to a SIP emergency call. This mechanism		emergency call MIME types to be attached to SIP messages. This
	permits certain MIME types to be attached to SIP messages. This
	document makes use of that mechanism.		document makes use of that mechanism.
	Note that if additional data sets are defined and registered (e.g.,		Note that if additional data sets are defined and registered (e.g.,
	in the future or in other regions) and transmitted using the same		in the future or in other regions) and transmitted using the same
	mechanisms, the size and frequency of transmission during a dialog		mechanisms, the size and frequency of transmission during a dialog
	need to be evaluated to be sure it is appropriate to use the		need to be evaluated to be sure it is appropriate to use the
	signaling channel.		signaling channel.
	An In-Vehicle System (IVS) transmits the MSD (see Section 5) by		An In-Vehicle System (IVS) transmits the MSD (see Section 5) by
	encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP		encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP
	message as a MIME body part per [I-D.ietf-ecrit-additional-data].		message as a MIME body part per [RFC7852]. The body part is
	The body part is identified by its MIME content-type ('application/		identified by its MIME content-type ('application/
	emergencyCallData.eCall.MSD+per') in the Content-Type header field of		emergencyCallData.eCall.MSD+per') in the Content-Type header field of
	the body part. The body part is assigned a unique identifier which		the 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		is listed in a Content-ID header field in the body part. The SIP
	message is marked as containing the MSD by adding (or appending to) a		message is marked as containing the MSD 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		Call-Info header field contains a CID URL referencing the body part's
	unique identifier, and a 'purpose' parameter identifying the data as		unique identifier, and a 'purpose' parameter identifying the data as
	the eCall MSD per the Emergency Call Additional Data Blocks registry		the eCall MSD per the Emergency Call Additional Data Blocks registry
	entry; the 'purpose' parameter's value is		entry; the 'purpose' parameter's value is
	'emergencyCallData.eCall.MSD'.		'emergencyCallData.eCall.MSD'.
	A PSAP transmits a metadata/control object (see Section 9) by		A PSAP or IVS transmits a metadata/control object (see Section 9) by
	encoding it per the description in this document and attaching it to		encoding it per the description in this document and attaching it to
	a SIP message as a MIME body part per		a SIP message as a MIME body part per [RFC7852]. The body part is
	[I-D.ietf-ecrit-additional-data]. The body part is identified by its		identified by its MIME content-type ('application/
	MIME content-type ('application/emergencyCallData.eCall.control+xml')		emergencyCallData.eCall.control+xml') in the Content-Type header
	in the Content-Type header field of the body part. The body part is		field of the body part. The body part is assigned a unique
	assigned a unique identifier which is listed in a Content-ID header		identifier which is listed in a Content-ID header field in the body
	field in the body part. The SIP message is marked as containing the		part. The SIP message is marked as containing the metadata/control
	MSD by adding (or appending to) a Call-Info header field at the top		object by adding (or appending to) a Call-Info header field at the
	level of the SIP message. This Call-Info header field contains a CID		top level of the SIP message. This Call-Info header field contains a
	URL referencing the body part's unique identifier, and a 'purpose'		CID URL referencing the body part's unique identifier, and a
	parameter identifying the data as an eCall metadata/control block per		'purpose' parameter identifying the data as an eCall metadata/control
	the Emergency Call Additional Data Blocks registry entry; the		block per the Emergency Call Additional Data Blocks registry entry;
	'purpose' parameter's value is 'emergencyCallData.eCall.control'.		the 'purpose' parameter's value is 'emergencyCallData.eCall.control'.
	An In-Vehicle System (IVS) initiating an NG-eCall attaches the MSD to		An In-Vehicle System (IVS) initiating an NG-eCall attaches the MSD to
	the initial INVITE. The PSAP creates a metadata/control object		the initial INVITE and optionally attaches a metadata/control object
	acknowledging receipt of the MSD and attaches it to the SIP response		informing the PSAP of its capabilities. The PSAP creates a metadata/
	to the INVITE.		control object acknowledging receipt of the MSD and attaches it to
			the SIP response to the INVITE.
	A PSAP can request the vehicle to send an updated MSD during a call.		A PSAP can request the vehicle to send an updated MSD during a call.
	The PSAP creates a metadata/control object requesting the MSD and		The PSAP creates a metadata/control object requesting the MSD and
	attaches it to a SIP INFO message which it sends within the dialog.		attaches it to a SIP INFO message which it sends within the dialog.
	The IVS then attaches an updated MSD to a SIP INFO message and sends		The IVS then attaches an updated MSD to a SIP INFO message and sends
	it within the dialog. The metadata/control object and the MSD are		it within the dialog. The metadata/control object and the MSD are
	attached to an INFO message in the same way they are attached to		attached to an INFO message in the same way they are attached to
	other messages (such as the INVITE and the reply to the INVITE as		other messages (such as the INVITE and the reply to the INVITE as
	discussed above). See Section 10 for information about the use of		discussed above). INFO messages are sent using an appropriate INFO
	INFO messages to carry data within an eCall.		Package. See Section 10 for information about the use of INFO
			messages to carry data within an eCall.
	When data is being carried in an INFO request message, the body part		When data is being carried in an INFO request message, the body part
	also carries a Content-Disposition header field set to "Info-		also carries a Content-Disposition header field set to "Info-
	Package".		Package".
	Support for the data blocks defined in		Support for the data blocks defined in [RFC7852] is NOT REQUIRED for
	[I-D.ietf-ecrit-additional-data] is NOT REQUIRED for conformance with		conformance with this document.
	this document.
	7. Call Setup		7. Call Setup
	In circuit-switched eCall, the IVS places a special form of a 112		In circuit-switched eCall, the IVS places a special form of a 112
	emergency call which carries an eCall flag (indicating that the call		emergency call which carries an eCall flag (indicating that the call
	is an eCall and also if the call was manually or automatically		is an eCall and also if the call was manually or automatically
	triggered); the mobile network operator (MNO) recognizes the eCall		triggered); the mobile network operator (MNO) recognizes the eCall
	flag and routes the call to an eCall-capable PSAP; vehicle data is		flag and routes the call to an eCall-capable PSAP; vehicle data is
	transmitted to the PSAP via the eCall in-band modem (in the voice		transmitted to the PSAP via the eCall in-band modem (in the voice
	channel).		channel).
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 11 ¶
	This document registers "urn:service:test.sos.ecall" for eCall test		This document registers "urn:service:test.sos.ecall" for eCall test
	calls.		calls.
	The CS-eCall test call facility is a non-emergency number so does not		The CS-eCall test call facility is a non-emergency number so does not
	get treated as an emergency call. For NG-eCall, MNOs, emergency		get treated as an emergency call. For NG-eCall, MNOs, emergency
	authorities, and PSAPs can determine how to treat a vehicle call		authorities, and PSAPs can determine how to treat a vehicle call
	requesting the "test" service URN so that the desired functionality		requesting the "test" service URN so that the desired functionality
	is tested, but this is outside the scope of this document.		is tested, but this is outside the scope of this document.
	9. eCall-Specific Control/Metadata		9. The Metadata/Control Object
	eCall requires the ability for the PSAP to acknowledge successful		eCall requires the ability for the PSAP to acknowledge successful
	receipt of an MSD sent by the IVS, and for the PSAP to request that		receipt of an MSD sent by the IVS, and for the PSAP to request that
	the IVS send an MSD (e.g., the call taker can initiate a request for		the IVS send an MSD (e.g., the call taker can initiate a request for
	a new MSD to see if there have been changes in the vehicle's state,		a new MSD to see if there have been changes in the vehicle's state,
	e.g., location, direction, number of fastened seatbelts).		e.g., location, direction, number of fastened seatbelts).
	This document defines a block of metadata/control data as an XML		This document defines a block of metadata/control data as an XML
	structure containing eCall-specific elements. When the PSAP needs to		structure containing elements used for eCall and other vehicle-
	send an eCall control block that is in response to data sent by the		initiated emergency call systems (i.e., in other regions) and
	IVS in a SIP request (e.g., the MSD in the initial INVITE), the		extension points. (This metadata/control block is in effect a high-
	control block can be sent in the SIP response to that request (e.g.,		level protocol between the PSAP and IVS.) When the PSAP sends an
	the response to the INVITE request). When the PSAP needs to send an		eCall metadata/control block in response to data sent by the IVS in a
	eCall control block in other circumstances (e.g., mid-call), the		SIP request other than INFO (e.g., the MSD in the initial INVITE),
	control block can be transmitted from the PSAP to the IVS in a SIP		the metadata/control block is sent in the SIP response to that
			request (e.g., the response to the INVITE request). When the PSAP
			sends an eCall control block in other circumstances (e.g., mid-call),
			the control block is transmitted from the PSAP to the IVS in a SIP
	INFO request within the established dialog. The IVS sends the		INFO request within the established dialog. The IVS sends the
	requested data (the MSD) in a new INFO request. This mechanism		requested data (the MSD) in a new INFO request (per [RFC6086]). This
	flexibly allows the PSAP to send eCall-specific data to the IVS and		mechanism flexibly allows the PSAP to send eCall-specific data to the
	the IVS to respond. See Section 6 for more information on attaching		IVS and the IVS to respond. INFO messages are sent using an
	a metadata/control block to a SIP message.		appropriate INFO Package. See Section 6 for more information on
			attaching a metadata/control block to a SIP message. See Section 10
			for information about the use of INFO messages to carry data within
			an eCall.
	This mechanism requires		This mechanism requires
	o An XML definition of the eCall control object		o An XML definition of the eCall control object
	o An extension mechanism by which new elements, attributes, and		o Extension points for use by eCall-like systems in other regions
	values can be added to the control object definition
	o A MIME type registration for the control object (so it can be		o A MIME type registration for the control object (so it can be
	carried in SIP messages and responses)		carried in SIP messages and responses)
	o An entry in the Emergency Call Additional Data Blocks sub-registry		o An entry in the Emergency Call Additional Data Blocks registry so
	(established by [I-D.ietf-ecrit-additional-data]) so that the		that the control block can be recognized as emergency call
	control block can be recognized as emergency call specific data		specific data within SIP messages
	within SIP messages		o An Info-Package registration per [RFC6086] permitting the
	o An Info-Package registration per [RFC6086] permitting data blocks		metadata/control block and the MSD within INFO messages
	registered in the Emergency Call Additional Data Blocks sub-
	registry (established by [I-D.ietf-ecrit-additional-data]) within
	Info messages
	When the IVS includes an unsolicited MSD in a SIP request (e.g., the		When the IVS includes an unsolicited MSD in a SIP request (e.g., the
	initial INVITE), the PSAP sends a metadata/control block indicating		initial INVITE), the PSAP sends a metadata/control block indicating
	successful/unsuccessful receipt of the MSD in the SIP response to the		successful/unsuccessful receipt of the MSD in the SIP response to the
	request. This also informs the IVS that an NG-eCall is in operation.		request. This also informs the IVS that an NG-eCall is in operation.
	If the IVS receives a SIP response without the metadata/control		If the IVS receives a SIP response without the metadata/control
	block, it indicates that the SIP dialog is not an NG-eCall (e.g.,		block, it indicates that the SIP dialog is not an NG-eCall (e.g.,
	some part of the call is being handled as a legacy call). When the		some part of the call is being handled as a legacy call). When the
	IVS sends a solicited MSD (e.g., in a SIP INFO request sent following		IVS sends a solicited MSD (e.g., in a SIP INFO request sent following
	receipt of a SIP INFO request containing a metadata/control block		receipt of a SIP INFO request containing a metadata/control block
	skipping to change at page 11, line 31 ¶		skipping to change at page 11, line 39 ¶
	determine that the call was successful on a technical level (e.g.,		determine that the call was successful on a technical level (e.g.,
	not helpful to retry as a CS-eCall). The SIP response codes 600		not helpful to retry as a CS-eCall). The SIP response codes 600
	(Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when		(Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when
	the PSAP wants to reject a call but inform the vehicle occupants that		the PSAP wants to reject a call but inform the vehicle occupants that
	it is aware of the situation. (Note that there could be edge cases		it is aware of the situation. (Note that there could be edge cases
	where the PSAP response is not received by the IVS, e.g., if an		where the PSAP response is not received by the IVS, e.g., if an
	intermediary sends a CANCEL, and an error response is forwarded		intermediary sends a CANCEL, and an error response is forwarded
	towards the IVS before the error response from the PSAP is received,		towards the IVS before the error response from the PSAP is received,
	the response will be dropped, but these are unlikely to occur here.)		the response will be dropped, but these are unlikely to occur here.)
	9.1. The eCall Control Block		The metadata/control block is carried in the MIME type 'application/
			emergencyCallData.eCall.control+xml'.
	The eCall control block is an XML data structure allowing for
	acknowledgments and requests. It is carried in a SIP body part with
	a specific MIME content type. It can be extended via an IANA
	registry to add additional elements, attributes, and values. Two
	top-level elements are defined for use within an eCall control block:
	ack Used in a control block sent by the PSAP to acknowledge		The metadata/control block is designed for use with with pan-European
	receipt of a data set sent by the IVS.		eCall and also eCall-like systems (i.e., in other regions), and has
			extension points to accomodate variances. Note that eCall-like
			systems might define their own vehicle data blocks, and so might need
			to register a new INFO package to accomodate the new data MIME type
			and the metadata/control object.
	request Used in a control block sent by the PSAP to request the		9.1. The eCall Control Block
	vehicle to perform an action. The only action defined
	in this document is a request for the IVS to send an
	MSD.
	Mandatory Actions (the IVS and the PSAP MUST support):		The eCall control block is an XML data structure allowing for
			acknowledgments, requests, and capabilities information. It is
			carried in a SIP body part with a specific MIME content type. Three
			elements are defined for use within an eCall control block:
	o Transmit data object		ack Acknowledges receipt of data or a request.
	Optional Actions (the IVS and the PSAP MAY support):		capabilities: Used in a control block sent from the IVS to the PSAP
			(e.g., in the initial INVITE) to inform the PSAP of the
			vehicle capabilities. Child elements contain all
			actions and data types supported by the vehicle. It is
			OPTIONAL for the IVS to send this block. Omitting the
			block indicates that the IVS supports only the
			mandatory functionality defined in this document.
	o None		request Used in a control block sent by the PSAP to the IVS, to
			request the vehicle to perform an action.
	The <ack> element indicates the object being acknowledged (e.g., the		The <ack> element indicates the object being acknowledged and reports
	MSD), and reports success or failure.		success or failure.
	The <request> element contains attributes to indicate the request and		The <request> element contains attributes to indicate the request and
	to supply related information. The 'action' attribute is mandatory		to supply related information. The 'action' attribute is mandatory
	and indicates the specific action. An IANA registry is created in		and indicates the specific action. An IANA registry is created in
	Section 15.8.1 to contain the allowed values.		Section 15.8.1 to contain the allowed values.
	Extensibility: New elements, child elements, attributes of new and		The <capabilities> element has child <request> elements to indicate
	existing elements, and values for new and existing attributes can be		the actions supported by the IVS.
	added in the IANA registry created in Section 15.8.2. The registry
	permits implementors to see what has been added, with a reference to
	the defining document. (Implementations are not expected to
	dynamically check the registry.) Implementations MUST ignore
	unrecognized elements, attributes, and values (this allows new items
	to be added without breaking older implementations).
	9.1.1. The <ack> element		9.1.1. The <ack> element
	The <ack> element is transmitted by the PSAP to acknowledge receipt		The <ack> element acknowledges receipt of an eCall data object or
	of an eCall data object. An <ack> element sent by a PSAP references		request. An <ack> element references the unique ID of the data
	the unique ID of the data object that was sent by the IVS, and		object being acknowledged. The PSAP MUST send an <ack> element
	further indicates if the PSAP considers the receipt successful or		acknowledging reeipt of an unsolicited MSD (e.g., sent by the IVS in
	not.		the INVITE); this <ack> element indicates if the PSAP considers the
			MSD successfully received or not. An <ack> element is not sent for a
			<capabilities> element.
	The <ack> element has the following attributes:		The <ack> element has the following attributes:
	9.1.1.1. Attributes of the <ack> element		9.1.1.1. Attributes of the <ack> element
	The <ack> element has the following attributes:		The <ack> element has the following attributes:
	Name: ref		Name: ref
	Usage: Mandatory		Usage: Mandatory
	Type: anyURI		Type: anyURI
	Description: References the Content-ID of the body part that		Direction: In this document, sent from the PSAP to the IVS
	contained the data object being acknowledged.		Description: References the Content-ID of the body part being
			acknowledged.
	Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>		Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>
	Name: received		Name: received
	Usage: Conditional: mandatory in an >ack< element sent by a PSAP		Usage: Conditional: mandatory in an >ack< element sent by a PSAP
	Type: Boolean		Type: Boolean
	Description: Indicates if the referenced object was successfully		Direction: In this document, sent from the PSAP to the IVS
	received or not		Description: Indicates if the referenced object was considered
			successfully received or not
	Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>		Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>
	9.1.1.2. Child Elements of the <ack> element		9.1.1.2. Child Element of the <ack> element
	The <ack> element has no child elements		For extensibility, the <ack> element has the following child element:
			Name: actionResult
			Usage: Optional
			Direction: Provided for extension, sent from the IVS to the PSAP
			Description: An <actionResult> element indicates the result of an
			action (other than a 'send-data' action). When an <ack> element
			is in response to a control object with multiple <request>
			elements, the <ack> element contains an <actionResult> element for
			each <request> element that is not a 'send-data' action. The
			<actionResult> element has the following attributes:
			Name: action
			Usage: Mandatory
			Type: token
			Direction: In this document, sent from the PSAP to the IVS
			Description: Contains the value of the 'action' attribute of the
			<request> element
			Name: success
			Usage: Mandatory
			Type: Boolean
			Direction: Provided for extension, sent from the IVS to the PSAP
			Description: Indicates if the action was successfully
			accomplished
			Name: reason
			Usage: Conditional
			Type: token
			Direction: Provided for extension, sent from the IVS to the PSAP
			Description: Used when 'success' is "False", this attribute
			contains a reason code for a failure. A registry for reason
			codes is defined in Section 15.8.2.
			Name: details
			Usage: optional
			Type: string
			Direction: Provided for extension, sent from the IVS to the PSAP
			Description: Contains further explanation of the circumstances of
			a success or failure. The contents are implementation-specific
			and human-readable.
	9.1.1.3. Ack Examples		9.1.1.3. Ack Examples
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<EmergencyCallData.eCall.Control		<EmergencyCallData.eCall.Control
	xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"		xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation=		xsi:schemaLocation=
	"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">		"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
	<ack received="true" ref="1234567890@atlanta.example.com"/>		<ack received="true" ref="1234567890@atlanta.example.com"/>
	</EmergencyCallData.eCall.Control>		</EmergencyCallData.eCall.Control>
	Figure 3: Ack Example from PSAP to IVS		Figure 3: Ack Example from PSAP to IVS
	9.1.2. The <request> element		9.1.2. The <capabilities> element
	A <request> element allows the PSAP to request that the IVS send an		The <capabilities> element is transmitted by the IVS to indicate to
	MSD. The following attributes are defined:		the PSAP its capabilities. No attributes for this element are
			currently defined. The following child elements are defined:
	9.1.2.1. Attributes of the <request> element		9.1.2.1. Child Elements of the <capabilities> element
			The <capabilities> element has the following child elements:
			Name: request
			Usage: Mandatory
			Description: The <capabilities> element contains a <request> child
			element per action supported by the vehicle.
			Examples:
			<request action="send-data" supported-values="eCall.MSD" />
			It is OPTIONAL for the IVS to support the <capabilities> element. If
			the IVS does not send a <capabilities> element, this indicates that
			the only <request> action supported by the IVS is 'send-data' with
			'datatype' set to 'eCall.MSD'.
			9.1.2.2. Capabilities Example
			<?xml version="1.0" encoding="UTF-8"?>
			<EmergencyCallData.eCallControl
			xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
			eCall-control">
			<capabilities>
			<request action="send-data" supported-values="eCall.MSD"/>
			</capabilities>
			</EmergencyCallData.eCallControl>
			Figure 4: Capabilities Example
			9.1.3. The <request> element
			A <request> element appears one or more times on its own or as a
			child of a <capabilities> element. It allows the PSAP to request
			that the IVS perform an action. The only action that MUST be
			supported is to send an MSD. The following attributes and child
			elements are defined:
			9.1.3.1. Attributes of the <request> element
	The <request> element has the following attributes:		The <request> element has the following attributes:
	Name: action		Name: action
	Usage: Mandatory		Usage: Mandatory
	Type: token		Type: token
			Direction: In this document, sent from the PSAP to the IVS; for
			extension, sent from the IVS to the PSAP
	Description: Identifies the action that the vehicle is requested to		Description: Identifies the action that the vehicle is requested to
	perform. An IANA registry is established in Section 15.8.1 to		perform. An IANA registry is established in Section 15.8.1 to
	contain the allowed values.		contain the allowed values.
	Example: action="send-data"		Example: action="send-data"
			Name: msgid
			Usage: Conditional
			Type: int
			Direction: Sent from the PSAP to the IVS
			Description: Defined for extensibility.
			Example: msgid="3"
			Name: persistance
			Usage: Optional
			Type: duration
			Direction: Sent from the PSAP to the IVS
			Description: Defined for extensibility. Specifies how long to carry
			on the specified action. If absent, the default is for the
			duration of the call.
			Example: persistance="PT1H"
	Name: datatype		Name: datatype
	Usage: Conditional		Usage: Conditional
	Type: token		Type: token
	Description: Mandatory with a "send-data" action. Specifies the		Direction: In this document, sent from the PSAP to the IVS; as an
	data block that the IVS is requested to transmit, using the same		extension, sent from the IVS to the PSAP
	identifier as in the 'purpose' attribute set in a Call-Info header		Description: Mandatory with a "send-data" action within a <request>
	field to point to the data block. Permitted values are contained		element that is not within a <capabilities> element. Specifies
	in the 'Emergency Call Data Types' IANA registry established in		the data block that the IVS is requested to transmit, using the
	[I-D.ietf-ecrit-additional-data]. Only the "eCall.MSD" value is		same identifier as in the 'purpose' attribute set in a Call-Info
	mandatory to support.		header field to point to the data block. Permitted values are
			contained in the 'Emergency Call Data Types' IANA registry
			established in [RFC7852]. Only the "eCall.MSD" value is mandatory
			to support.
	Example: datatype="eCall.MSD"		Example: datatype="eCall.MSD"
	9.1.2.2. Request Example		Name: supported-values
			Usage: Conditional
			Type: string
			Direction: Sent from the IVS to the PSAP
			Description: Defined for extensibility. Used in a <request> element
			that is a child of a <capability> element, this attribute lists
			all supported values of the action type. Permitted values depend
			on the action value. Multiple values are separated with a
			semicolon.
			Name: requested-state
			Usage: Conditional
			Type: token
			Direction: Sent from the PSAP to the IVS
			Description: Defined for extension. Indicates the requested state
			of an element associated with the request type. Permitted values
			depend on the request type.
			Name: element-ID
			Usage: Conditional
			Type: token
			Direction: Sent from the PSAP to the IVS
			Description: Defined for extension. Identifies the element to be
			acted on. Permitted values depend on the request type.
			9.1.3.2. Request Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<EmergencyCallData.eCall.Control		<EmergencyCallData.eCall.Control
	xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"		xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation=		xsi:schemaLocation=
	"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">		"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
	<request action="send-data" datatype="eCall.MSD"/>		<request action="send-data" datatype="eCall.MSD"/>
	</EmergencyCallData.eCall.Control>		</EmergencyCallData.eCall.Control>
	Figure 4: Request Example		Figure 5: Request Example
	10. The emergencyCallData.eCall INFO package		10. The emergencyCallData.eCall.MSD INFO package
	This document registers the 'emergencyCallData.eCall' INFO package.		This document registers the 'emergencyCallData.eCall.MSD' INFO
			package.
	Both endpoints (the IVS and the PSAP equipment) include		Both endpoints (the IVS and the PSAP equipment) include
	'emergencyCallData.eCall' in a Recv-Info header field per [RFC6086]		'emergencyCallData.eCall.MSD' in a Recv-Info header field per
	to indicate ability to receive INFO messages carrying data as		[RFC6086] to indicate ability to receive INFO messages carrying data
	described here.		as described here.
	Support for the 'emergencyCallData.eCall' INFO package indicates the		Support for the 'emergencyCallData.eCall.MSD' INFO package indicates
	ability to receive body parts registered in the 'Emergency Call Data		the ability to receive the MSD and metadata/control body parts as
	Types' IANA registry. Because new body parts can be added to the		specified in [TBD: THIS DOCUMENT].
	registry, implementations MUST ignore any unsupported or unrecognized
	body parts. Only the 'application/emergencyCallData.eCall.MSD+per'
	and 'application/emergencyCallData.eCall.control+xml' body parts are
	REQUIRED to be supported for conformance with this document.
	An INFO request message carrying data related to an emergency call		An INFO request message carrying body parts related to an emergency
	has an Info-Package header field set to 'emergencyCallData.eCall' per		call as described in [TBD: THIS DOCUMENT] has an Info-Package header
	[RFC6086]. See Section 6 for details on how to attach eCall data to		field set to 'emergencyCallData.eCall.MSD' per [RFC6086].
	an INFO message.
	10.1. INFO Package Requirements		10.1. INFO Package Requirements
	The requirements of Section 10 of [RFC6086] are addressed in the		The requirements of Section 10 of [RFC6086] are addressed in the
	following sections.		following sections.
	10.1.1. Overall Description		10.1.1. Overall Description
	This section describes "what type of information is carried in INFO		This section describes "what type of information is carried in INFO
	requests associated with the Info Package, and for what types of		requests associated with the Info Package, and for what types of
	applications and functionalities UAs can use the Info Package."		applications and functionalities UAs can use the Info Package."
	INFO requests associated with the emergencyCallData.eCall INFO		INFO requests associated with the emergencyCallData.eCall.MSD INFO
	package carry data associated with emergency calls as registered in		package carry data associated with emergency calls as defined in
	the 'Emergency Call Data Types' IANA registry. The application is		[TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency
	emergency calls established using SIP. The functionality is to carry		calls established using SIP. The functionality is to carry vehicle
	data, metadata, and control information (requests) between vehicles		data and metadata/control information between vehicles and PSAPs.
	and PSAPs. Refer to [TBD: THIS DOCUMENT] for more information.		Refer to [TBD: THIS DOCUMENT] for more information.
	10.1.2. Applicability		10.1.2. Applicability
	This section describes "why the Info Package mechanism, rather than		This section describes "why the Info Package mechanism, rather than
	some other mechanism, has been chosen for the specific use-case...."		some other mechanism, has been chosen for the specific use-case...."
	The use of INFO is based on an analysis of the requirements against		The use of INFO is based on an analysis of the requirements against
	the intent and effects of INFO versus other approaches (which		the intent and effects of INFO versus other approaches (which
	included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane		included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane
	transport, and non-SIP protocols). In particular, the transport of		transport, and non-SIP protocols). In particular, the transport of
	skipping to change at page 15, line 50 ¶		skipping to change at page 18, line 50 ¶
	of messages needing to be exchanged in a dialog is normally zero or		of messages needing to be exchanged in a dialog is normally zero or
	very few, and the size of the data is likewise very small. The		very few, and the size of the data is likewise very small. The
	overhead caused by user plane setup (e.g., to use MSRP as transport)		overhead caused by user plane setup (e.g., to use MSRP as transport)
	would be disproportionately large.		would be disproportionately large.
	Based on the the analyses, the SIP INFO method was chosen to provide		Based on the the analyses, the SIP INFO method was chosen to provide
	for mid-call data transport.		for mid-call data transport.
	10.1.3. Info Package Name		10.1.3. Info Package Name
	The info package name is emergencyCallData.eCall.		The info package name is emergencyCallData.eCall.MSD
	10.1.4. Info Package Parameters		10.1.4. Info Package Parameters
	None.		None
	10.1.5. SIP Option-Tags		10.1.5. SIP Option-Tags
	None.		None
	10.1.6. INFO Message Body Parts		10.1.6. INFO Message Body Parts
	Only those body parts registered in the 'Emergency Call Data Types'		The 'application/emergencyCallData.eCall.MSD+per' and 'application/
	IANA registry are associated with this INFO package.		emergencyCallData.eCall.control+xml' MIME types are associated with
			this INFO package. See [TBD: THIS DOCUMENT] for more information.
	When more than one body part is included, they are enclosed in a
	multipart body part (e.g., multipart/mixed). When a body part is
	digitally signed or encrypted, it is enclosed in an appropriate body
	part (e.g., multipart/signed or multipart/encrypted).
	The Content-Disposition value of a message body part associated with
	the emergencyCallData.eCall info package is "info-package".
	10.1.7. Info Package Usage Restrictions		10.1.7. Info Package Usage Restrictions
	None.		Usage is limited to vehicle-initiated emergency calls as defined in
			[TBD: THIS DOCUMENT].
	10.1.8. Rate of INFO Requests		10.1.8. Rate of INFO Requests
	The rate of SIP INFO requests associated with the		The rate of SIP INFO requests associated with the
	emergencyCallData.eCall info package is expected to be quite low		emergencyCallData.eCall.MSD info package is normally quite low (most
	(most dialogs are likely to contain zero INFO requests, while others		dialogs are likely to contain zero INFO requests, while others can be
	can be expected to carry occasional requests).		expected to carry an occasional request).
	10.1.9. Info Package Security Considerations		10.1.9. Info Package Security Considerations
	The MIME content type registation for each data block listed in the		The MIME content type registations for the data blocks that can be
	'Emergency Call Data Types' IANA registry contains a discussion of		carried using this IFO package contains a discussion of the security
	the security and/or privacy considerations specific to that data		and/or privacy considerations specific to that data block. The
	block. The "Security Considerations" and "Privacy Considerations"		"Security Considerations" and "Privacy Considerations" sections of
	sections of [TBD: THIS DOCUMENT] discuss security and privacy		[TBD: THIS DOCUMENT] discuss security and privacy considerations of
	considerations of the data carried in eCealls.		the data carried in eCalls.
	10.1.10. Implementation Details		10.1.10. Implementation Details
	See [TBD: THIS DOCUMENT] for protocol details.		See [TBD: THIS DOCUMENT] for protocol details.
	10.1.11. Examples		10.1.11. Examples
	See [TBD: THIS DOCUMENT] for protocol examples.		See [TBD: THIS DOCUMENT] for protocol examples.
	11. Examples		11. Examples
	Figure 5 illustrates an eCall. The call uses the request URI		Figure 6 illustrates an eCall. The call uses the request URI
	'urn:service:sos.ecall.automatic' service URN and is recognized as an		'urn:service:sos.ecall.automatic' service URN and is recognized as an
	eCall, and further as one that was invoked automatically by the IVS		eCall, and further as one that was invoked automatically by the IVS
	due to a crash or other serious incident. In this example, the		due to a crash or other serious incident. In this example, the
	originating network routes the call to an ESInet which routes the		originating network routes the call to an ESInet which routes the
	call to the appropriate NG-eCall capable PSAP. The emergency call is		call to the appropriate NG-eCall capable PSAP. The emergency call is
	received by the ESInet's Emergency Services Routing Proxy (ESRP), as		received by the ESInet's Emergency Services Routing Proxy (ESRP), as
	the entry point into the ESInet. The ESRP routes the call to a PSAP,		the entry point into the ESInet. The ESRP routes the call to a PSAP,
	where it is received by a call taker. In deployments where there is		where it is received by a call taker. In deployments where there is
	no ESInet, the originating network routes the call directly to the		no ESInet, the originating network routes the call directly to the
	appropriate NG-eCall capable PSAP, an illustration of which would be		appropriate NG-eCall capable PSAP, an illustration of which would be
	skipping to change at page 17, line 40 ¶		skipping to change at page 20, line 30 ¶
	Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker |		Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker |
	| | | +------+ +-------+ |		| | | +------+ +-------+ |
	| | | |		| | | |
	| | | +-------+ |		| | | +-------+ |
	| | | | PSAP3 | |		| | | | PSAP3 | |
	| Originating| | +-------+ |		| Originating| | +-------+ |
	| Mobile | | |		| Mobile | | |
	| Network | | ESInet |		| Network | | ESInet |
	+------------+ +---------------------------------------+		+------------+ +---------------------------------------+
	Figure 5: Example of NG-eCall Message Flow		Figure 6: Example of NG-eCall Message Flow
	Figure 6 illustrates an eCall call flow with a mid-call PSAP request		Figure 7 illustrates an eCall call flow with a mid-call PSAP request
	for an updated MSD. The call flow shows the IVS initiating an		for an updated MSD. The call flow shows the IVS initiating an
	emergency call, including the MSD in the INVITE. The PSAP includes		emergency call, including the MSD in the INVITE. The PSAP includes
	in the 200 OK response a metadata/control object acknowledging		in the 200 OK response a metadata/control object acknowledging
	receipt of the MSD. During the call, the PSAP sends a request for an		receipt of the MSD. During the call, the PSAP sends a request for an
	MSD in an INFO message. The IVS sends the requested MSD in a new		MSD in an INFO message. The IVS sends the requested MSD in a new
	INFO message.		INFO message.
	IVS PSAP		IVS PSAP
	|(1) INVITE (eCall MSD) |		|(1) INVITE (eCall MSD) |
	|------------------------------------------->|		|------------------------------------------->|
	skipping to change at page 18, line 36 ¶		skipping to change at page 21, line 36 ¶
	| |		| |
	|(8) BYE |		|(8) BYE |
	|<-------------------------------------------|		|<-------------------------------------------|
	| |		| |
	|(9) end media streams |		|(9) end media streams |
	|............................................|		|............................................|
	| |		| |
	|(10) 200 OK |		|(10) 200 OK |
	|------------------------------------------->|		|------------------------------------------->|
	Figure 6: NG-eCall Call Flow Illustration		Figure 7: NG-eCall Call Flow Illustration
	The example, shown in Figure 7, illustrates a SIP eCall INVITE that		The example, shown in Figure 8, illustrates a SIP eCall INVITE that
	contains an MSD. For simplicity, the example does not show all SIP		contains an MSD. For simplicity, the example does not show all SIP
	headers, nor the SDP contents, nor does it show any additional data		headers, nor the SDP contents, nor does it show any additional data
	blocks added by the IVS or the originating mobile network. Because		blocks added by the IVS or the originating mobile network. Because
	the MSD is encoded in ASN.1 PER, which is a binary encoding, its		the MSD is encoded in ASN.1 PER, which is a binary encoding, its
	contents cannot be included in a text document.		contents cannot be included in a text document.
	INVITE urn:service:sos.ecall.automatic SIP/2.0		INVITE urn:service:sos.ecall.automatic SIP/2.0
	To: urn:service:sos.ecall.automatic		To: urn:service:sos.ecall.automatic
	From: <sip:+13145551111@example.com>;tag=9fxced76sl		From: <sip:+13145551111@example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Geolocation: <cid:target123@example.com>		Geolocation: <cid:target123@example.com>
	Geolocation-Routing: no		Geolocation-Routing: no
	Call-Info: cid:1234567890@atlanta.example.com;		Call-Info: cid:1234567890@atlanta.example.com;
	purpose=emergencyCallData.eCall.MSD;		purpose=emergencyCallData.eCall.MSD;
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallData.eCall.control+xml		application/emergencyCallData.eCall.control+xml
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Recv-Info: emergencyCallData.eCall		Recv-Info: emergencyCallData.eCall.MSD
	Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,		Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
	SUBSCRIBE, NOTIFY, UPDATE		SUBSCRIBE, NOTIFY, UPDATE
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	...Session Description Protocol (SDP) goes here...		...Session Description Protocol (SDP) goes here...
	--boundary1		--boundary1
	Content-Type: application/emergencyCallData.eCall.MSD+per		Content-Type: application/emergencyCallData.eCall.MSD+per
	Content-ID: 1234567890@atlanta.example.com		Content-ID: 1234567890@atlanta.example.com
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
	Content-Transfer-Encoding: binary		Content-Transfer-Encoding: binary
	...MSD in ASN.1 PER encoding goes here...		...MSD in ASN.1 PER encoding goes here...
	--boundary1--		--boundary1--
	Figure 7: SIP NG-eCall INVITE		Figure 8: SIP NG-eCall INVITE
	Continuing the example, Figure 8 illustrates a SIP 200 OK response to		Continuing the example, Figure 9 illustrates a SIP 200 OK response to
	the INVITE of Figure 7, containing an eCall control block		the INVITE of Figure 8, containing an eCall control block
	acknowledging successful receipt of the eCall MSD. (For simplicity,		acknowledging successful receipt of the eCall MSD. (For simplicity,
	the example does not show all SIP headers.)		the example does not show all SIP headers.)
	SIP/2.0 200 OK		SIP/2.0 200 OK
	To: <sip:+13145551111@example.com>;tag=9fxced76sl		To: <sip:+13145551111@example.com>;tag=9fxced76sl
	From: Exemplar PSAP <urn:service:sos.ecall.automatic>		From: Exemplar PSAP <urn:service:sos.ecall.automatic>
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: cid:2345678901@atlanta.example.com;		Call-Info: cid:2345678901@atlanta.example.com;
	purpose=emergencyCallData.eCall.control;		purpose=emergencyCallData.eCall.control;
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallData.eCall.control+xml,		application/emergencyCallData.eCall.control+xml,
	application/emergencyCallData.eCall.MSD+per		application/emergencyCallData.eCall.MSD+per
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Recv-Info: emergencyCallData.eCall		Recv-Info: emergencyCallData.eCall.MSD
	Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,		Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
	SUBSCRIBE, NOTIFY, UPDATE		SUBSCRIBE, NOTIFY, UPDATE
	Content-Type: multipart/mixed; boundary=boundaryX		Content-Type: multipart/mixed; boundary=boundaryX
	Content-Length: ...		Content-Length: ...
	--boundaryX		--boundaryX
	Content-Type: application/sdp		Content-Type: application/sdp
	...Session Description Protocol (SDP) goes here...		...Session Description Protocol (SDP) goes here...
	skipping to change at page 20, line 43 ¶		skipping to change at page 23, line 43 ¶
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation=		xsi:schemaLocation=
	"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">		"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
	<ack received="true" ref="1234567890@atlanta.example.com"/>		<ack received="true" ref="1234567890@atlanta.example.com"/>
	</EmergencyCallData.eCall.Control>		</EmergencyCallData.eCall.Control>
	--boundaryX--		--boundaryX--
	Figure 8: 200 OK response to INVITE		Figure 9: 200 OK response to INVITE
	Figure 9 illustrates an INFO message containing an eCall metadata/		Figure 10 illustrates an INFO message containing an eCall metadata/
	control block requesting an eCall MSD. (For simplicity, the example		control block requesting an eCall MSD. (For simplicity, the example
	does not show all SIP headers.)		does not show all SIP headers.)
	INFO sip:+13145551111@example.com SIP/2.0		INFO sip:+13145551111@example.com SIP/2.0
	To: <sip:+13145551111@example.com>;tag=9fxced76sl		To: <sip:+13145551111@example.com>;tag=9fxced76sl
	From: Exemplar PSAP <urn:service:sos.ecall.automatic>		From: Exemplar PSAP <urn:service:sos.ecall.automatic>
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: cid:3456789012@atlanta.example.com;		Call-Info: cid:3456789012@atlanta.example.com;
	purpose=emergencyCallData.eCall.control;		purpose=emergencyCallData.eCall.control;
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallData.eCall.control+xml,		application/emergencyCallData.eCall.control+xml,
	application/emergencyCallData.eCall.MSD+per		application/emergencyCallData.eCall.MSD+per
	CSeq: 41862 INFO		CSeq: 41862 INFO
	Recv-Info: emergencyCallData.eCall		Recv-Info: emergencyCallData.eCall.MSD
	Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,		Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
	SUBSCRIBE, NOTIFY, UPDATE		SUBSCRIBE, NOTIFY, UPDATE
	Content-Type: application/EmergencyCallData.eCall.control+xml		Content-Type: application/EmergencyCallData.eCall.control+xml
	Content-ID: 3456789012@atlanta.example.com		Content-ID: 3456789012@atlanta.example.com
	Content-Disposition: info-package		Content-Disposition: info-package
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<EmergencyCallData.eCall.Control		<EmergencyCallData.eCall.Control
	xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"		xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation=		xsi:schemaLocation=
	"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">		"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
	<request action="send-data" datatype="eCall.MSD"/>		<request action="send-data" datatype="eCall.MSD"/>
	</EmergencyCallData.eCall.Control>		</EmergencyCallData.eCall.Control>
	Figure 9: INFO requesting MSD		Figure 10: INFO requesting MSD
	Figure 10 illustrates a SIP eCall INFO that contains an MSD. For		Figure 11 illustrates a SIP eCall INFO that contains 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
	MSD is encoded in ASN.1 PER, which is a binary encoding, its contents		MSD is encoded in ASN.1 PER, which is a binary encoding, its contents
	cannot be included in a text document.		cannot be included in a text document.
	INFO urn:service:sos.ecall.automatic SIP/2.0		INFO urn:service:sos.ecall.automatic SIP/2.0
	To: urn:service:sos.ecall.automatic		To: urn:service:sos.ecall.automatic
	From: <sip:+13145551111@example.com>;tag=9fxced76sl		From: <sip:+13145551111@example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: cid:4567890123@atlanta.example.com;		Call-Info: cid:4567890123@atlanta.example.com;
	purpose=emergencyCallData.eCall.MSD;		purpose=emergencyCallData.eCall.MSD;
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallData.eCall.control+xml		application/emergencyCallData.eCall.control+xml
	CSeq: 51862 INFO		CSeq: 51862 INFO
	Recv-Info: emergencyCallData.eCall		Recv-Info: emergencyCallData.eCall.MSD
	Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,		Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
	SUBSCRIBE, NOTIFY, UPDATE		SUBSCRIBE, NOTIFY, UPDATE
	Content-Type: application/emergencyCallData.eCall.MSD+per		Content-Type: application/emergencyCallData.eCall.MSD+per
	Content-ID: 4567890123@atlanta.example.com		Content-ID: 4567890123@atlanta.example.com
	Content-Disposition: info-package		Content-Disposition: info-package
	Content-Transfer-Encoding: binary		Content-Transfer-Encoding: binary
	...MSD in ASN.1 PER encoding goes here...		...MSD in ASN.1 PER encoding goes here...
	Figure 10: INFO containing MSD		Figure 11: INFO containing MSD
	12. Security Considerations		12. Security Considerations
	The security considerations described in [RFC5069] apply here.		The security considerations described in [RFC5069] apply here.
	In addition to any network-provided location (which might be		In addition to any network-provided location (which might be
	determined solely by the network, or in cooperation with or possibly		determined solely by the network, or in cooperation with or possibly
	entirely by the originating device), an eCall carries an IVS-supplied		entirely by the originating device), an eCall carries an IVS-supplied
	location within the MSD. This is likely to be useful to the PSAP,		location within the MSD. This is likely to be useful to the PSAP,
	especially when no network-provided location is included, or when the		especially when no network-provided location is included, or when the
	skipping to change at page 23, line 14 ¶		skipping to change at page 26, line 14 ¶
	parsing bugs, etc. Implementations need to be cognizant of the		parsing bugs, etc. Implementations need to be cognizant of the
	potential risks, observe best practices (which might include		potential risks, observe best practices (which might include
	sufficiently capable static code analysis, fuzz testing, component		sufficiently capable static code analysis, fuzz testing, component
	isolation, avoiding use of unsafe coding techniques, third-party		isolation, avoiding use of unsafe coding techniques, third-party
	attack tests, signed software, over-the-air updates, etc.), and have		attack tests, signed software, over-the-air updates, etc.), and have
	multiple levels of protection. Implementors need to be aware that,		multiple levels of protection. Implementors need to be aware that,
	potentially, the data objects described here and elsewhere might be		potentially, the data objects described here and elsewhere might be
	malformed, might contain unexpected characters, excessively long		malformed, might contain unexpected characters, excessively long
	attribute values, elements, etc.		attribute values, elements, etc.
	The security considerations discussed in		The security considerations discussed in [RFC7852] apply here (see
	[I-D.ietf-ecrit-additional-data] apply here (see especially the		especially the discussion of TLS, TLS versions, cypher suites, and
	discussion of TLS, TLS versions, cypher suites, and PKI).		PKI).
	When vehicle data or control/metadata is contained in a signed or		When vehicle data or control/metadata is contained in a signed or
	encrypted body part, the enclosing multipart (e.g., multipart/signed		encrypted body part, the enclosing multipart (e.g., multipart/signed
	or multipart/encrypted) has the same Content-ID as the enclosed data		or multipart/encrypted) has the same Content-ID as the enclosed data
	part. This allows an entity to identify and access the data blocks		part. This allows an entity to identify and access the data blocks
	it is interested in without having to dive deeply into the message		it is interested in without having to dive deeply into the message
	structure or decrypt parts it is not interested in. (The 'purpose'		structure or decrypt parts it is not interested in. (The 'purpose'
	parameter in a Call-Info header field identifies the data and		parameter in a Call-Info header field identifies the data and
	contains a CID URL pointing to the data block in the body, which has		contains a CID URL pointing to the data block in the body, which has
	a matching Content-ID body part header field).		a matching Content-ID body part header field).
	13. Privacy Considerations		13. Privacy Considerations
	The privacy considerations discussed in		The privacy considerations discussed in [RFC7852] apply here. The
	[I-D.ietf-ecrit-additional-data] apply here. The MSD carries some		MSD carries some identifying and personal information (mostly about
	identifying and personal information (mostly about the vehicle and		the vehicle and less about the owner), as well as location
	less about the owner), as well as location information, and so needs		information, and so needs to be protected against unauthorized
	to be protected against unauthorized disclosure. Local regulations		disclosure. Local regulations may impose additional privacy
	may impose additional privacy protection requirements.		protection requirements.
	Privacy considerations specific to the data structure containing		Privacy considerations specific to the data structure containing
	vehicle information are discussed in the "Security Considerations"		vehicle information are discussed in the "Security Considerations"
	block of Section 15.2.		block of Section 15.2.
	Privacy considerations specific to the mechanism by which the PSAP		Privacy considerations specific to the mechanism by which the PSAP
	sends acknowledgments and requests to the vehicle are discussed in		sends acknowledgments and requests to the vehicle are discussed in
	the "Security Considerations" block of Section 15.3.		the "Security Considerations" block of Section 15.3.
	14. XML Schema		14. XML Schema
	This section defines an XML schema for the eCall control block. The		This section defines an XML schema for the eCall control block. The
	text description of the eCall control block in Section 9.1 is		text description of the eCall control block in Section 9.1 is
	normative and supersedes any conflicting aspect of this schema.		normative and supersedes any conflicting aspect of this schema.
			<artwork>
			<![CDATA[
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace=		targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
	"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"		xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"		<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>		schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
	<xs:element name="EmergencyCallData.eCall.Control"		<xs:element name="EmergencyCallData.eCallControl"
	type="pi:eCallControlType"/>		type="pi:eCallControlType"/>
	<xs:simpleType name="iana-token">
	<xs:annotation>
	<xs:documentation>Permitted values specified in IANA
	registries</xs:documentation>
	</xs:annotation>
	</xs:simpleType>
	<xs:complexType name="eCallControlType">		<xs:complexType name="eCallControlType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:choice>		<xs:choice>
			<xs:element name="capabilities"
			type="pi:capabilitiesType"/>
	<xs:element name="request" type="pi:requestType"/>		<xs:element name="request" type="pi:requestType"/>
	<xs:element name="ack" type="pi:ackType"/>		<xs:element name="ack" type="pi:ackType"/>
			<xs:any namespace="##any" processContents="lax"
	<xs:element type="cx:iana-token"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:choice>		</xs:choice>
	<xs:anyAttribute/>		<xs:anyAttribute/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="ackType">		<xs:complexType name="ackType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence minOccurs="1" maxOccurs="unbounded">		<xs:sequence minOccurs="1" maxOccurs="unbounded">
			<xs:element name="actionResult" minOccurs="0"
	<xs:any namespace="##other" processContents="lax"		maxOccurs="unbounded">
			<xs:complexType>
			<xs:attribute name="action"
			type="xs:token"
			use="required"/>
			<xs:attribute name="success"
			type="xs:boolean"
			use="required"/>
			<xs:attribute name="reason"
			type="xs:token">
			<xs:annotation>
			<xs:documentation>conditionally
			mandatory when @success='false"
			to indicate reason code for a
			failure </xs:documentation>
			</xs:annotation>
			</xs:attribute>
			<xs:attribute name="details"
			type="xs:string"/>
			<xs:anyAttribute processContents="skip"/>
			</xs:complexType>
			</xs:element>
			<xs:any namespace="##any" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:attribute type="cx:iana-token"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="ref"		<xs:attribute name="ref"
	type="xs:anyURI"		type="xs:anyURI"
	use="required"/>		use="required"/>
	<xs:attribute name="received"		<xs:attribute name="received"
	type="xs:boolean"/>		type="xs:boolean"/>
	<xs:anyAttribute/>		<xs:anyAttribute/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
			<xs:complexType name="capabilitiesType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence minOccurs="1" maxOccurs="unbounded">
			<xs:element name="request"
			type="pi:requestType"
			minOccurs="1"
			maxOccurs="unbounded"/>
			<xs:any namespace="##any" processContents="lax"
			minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:anyAttribute/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
	<xs:complexType name="requestType">		<xs:complexType name="requestType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:choice minOccurs="1" maxOccurs="unbounded">		<xs:choice minOccurs="1" maxOccurs="unbounded">
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##any" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:element type="cx:iana-token"/>
	</xs:choice>		</xs:choice>
	<xs:attribute name="action" type="xs:token" use="required"/>		<xs:attribute name="action" type="xs:token" use="required"/>
			<xs:attribute name="msgid" type="xs:unsignedInt"/>
	<xs:attribute type="cx:iana-token" minOccurs="0"		<xs:attribute name="persistence" type="xs:duration"/>
	maxOccurs="unbounded"/>		<xs:attribute name="datatype" type="xs:token"/>
			<xs:attribute name="supported-values" type="xs:string"/>
			<xs:attribute name="element-id" type="xs:token"/>
			<xs:attribute name="requested-state" type="xs:token"/>
	<xs:anyAttribute/>		<xs:anyAttribute/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 11: eCall Control Block Schema		Figure 12: eCall Control Block Schema
	15. IANA Considerations		15. IANA Considerations
	15.1. Service URN Registrations		15.1. Service URN Registrations
	IANA is requested to register the URN 'urn:service:sos.ecall' under		IANA is requested to register the URN 'urn:service:sos.ecall' under
	the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].		the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].
	This service requests resources associated with an emergency call		This service requests resources associated with an emergency call
	placed by an in-vehicle system, carrying a standardized set of data		placed by an in-vehicle system, carrying a standardized set of data
	skipping to change at page 27, line 6 ¶		skipping to change at page 30, line 36 ¶
	Security considerations: This content type is designed to carry		Security considerations: This content type is designed to carry
	vehicle and incident-related data during an emergency call. This		vehicle and incident-related data during an emergency call. This
	data contains personal information including vehicle VIN,		data contains personal information including vehicle VIN,
	location, direction, etc. Appropriate precautions need to be		location, direction, etc. Appropriate precautions need to be
	taken to limit unauthorized access, inappropriate disclosure to		taken to limit unauthorized access, inappropriate disclosure to
	third parties, and eavesdropping of this information. In general,		third parties, and eavesdropping of this information. In general,
	it is acceptable for the data to be unprotected while briefly in		it is acceptable for the data to be unprotected while briefly in
	transit within the Mobile Network Operator (MNO); the MNO is		transit within the Mobile Network Operator (MNO); the MNO is
	trusted to not permit the data to be accessed by third parties.		trusted to not permit the data to be accessed by third parties.
	Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data]		Sections 7 and Section 8 of [RFC7852] contain more discussion.
	contain more discussion.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: Annex A of EN 15722 [msd]		Published specification: Annex A of EN 15722 [msd]
	Applications which use this media type: Pan-European eCall		Applications which use this media type: Pan-European eCall
	compliant systems		compliant systems
	Additional information: None		Additional information: None
	skipping to change at page 28, line 40 ¶		skipping to change at page 32, line 20 ¶
	the call to a PSAP. (Calls placed using other means, such as		the call to a PSAP. (Calls placed using other means, such as
	Wi-Fi or over-the-top services, generally incur somewhat higher		Wi-Fi or over-the-top services, generally incur somewhat higher
	levels of risk than calls placed "natively" using cellular		levels of risk than calls placed "natively" using cellular
	networks.) A call-back from a PSAP merits additional		networks.) A call-back from a PSAP merits additional
	consideration, since current mechanisms are not ideal for		consideration, since current mechanisms are not ideal for
	verifying that such a call is indeed a call-back from a PSAP in		verifying that such a call is indeed a call-back from a PSAP in
	response to an emergency call placed by the IVS. See the		response to an emergency call placed by the IVS. See the
	discussion in Section 12 and the PSAP Callback document		discussion in Section 12 and the PSAP Callback document
	[RFC7090].		[RFC7090].
	Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data]		Sections 7 and Section 8 of [RFC7852] contain more discussion.
	contain more discussion.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: This document		Published specification: This document
	Applications which use this media type: Pan-European eCall		Applications which use this media type: Pan-European eCall
	compliant systems		compliant systems
	Additional information: None		Additional information: None
	Magic Number: None		Magic Number: None
	File Extension: .xml		File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Randall Gellens,		Person and email address for further information: Randall Gellens,
	rg+ietf@randy.pensive.org		rg+ietf@randy.pensive.org
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	skipping to change at page 31, line 26 ¶		skipping to change at page 34, line 38 ¶
	<body>		<body>
	<h1>Namespace for eCall Data</h1>		<h1>Namespace for eCall Data</h1>
	<h2>Control Block</h2>		<h2>Control Block</h2>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	15.8. Registry creation		15.8. Registry creation
	This document creates a new registry called 'eCall Control Data'.		This document creates a new registry called 'eCall Metadata/Control
	The following sub-registries are created for this registry.		Data'. The following sub-registries are created for this registry.
	15.8.1. eCall Control Action Registry		15.8.1. Action Registry
	This document creates a new sub-registry called "eCall Control Action		This document creates a new sub-registry called "Action Registry".
	Registry". As defined in [RFC5226], this registry operates under		As defined in [RFC5226], this registry operates under "Expert Review"
	"Expert Review" rules. The expert should determine that the proposed		rules. The expert should determine that the proposed action is
	action is within the purview of a vehicle, is sufficiently		within the purview of a vehicle, is sufficiently distinguishable from
	distinguishable from other actions, and the action is clearly and		other actions, and the action is clearly and fully described. In
	fully described. In most cases, a published and stable document is		most cases, a published and stable document is referenced for the
	referenced for the description of the action.		description of the action.
	The content of this registry includes:		The content of this registry includes:
	Name: The identifier to be used in the 'action' attribute of an		Name: The identifier to be used in the 'action' attribute of an
	eCall control <request> element.		eCall control <request> element.
	Description: A description of the action. In most cases this will		Description: A description of the action. In most cases this will
	be a reference to a published and stable document. The		be a reference to a published and stable document. The
	description MUST specify if any attributes or child elements are		description MUST specify if any attributes or child elements are
	optional or mandatory, and describe the action to be taken by the		optional or mandatory, and describe the action to be taken by the
	vehicle.		vehicle.
	The initial set of values is listed in Table 2.		The initial set of values is listed in Table 2.
	+-----------+--------------------------------------+		+-----------+--------------------------------------+
	| Name | Description |		| Name | Description |
	+-----------+--------------------------------------+		+-----------+--------------------------------------+
	| send-data | See Section 9.1.2.1 of this document |		| send-data | See Section 9.1.3.1 of this document |
	+-----------+--------------------------------------+		+-----------+--------------------------------------+
	Table 2: eCall Control Action Registry Initial Values		Table 2: Action Registry Initial Values
	15.8.2. eCall Control Extension Registry		15.8.2. Reason Registry
	This document creates a new sub-registry called "eCall Control		This document creates a new sub-registry called "Reason Registry"
	Extension Registry". This registry contains elements, attributes,		which contains values for the 'reason' attribute of the
	and values for the eCall metadata/control object. As defined in		<actionResult> element. As defined in [RFC5226], this registry
	[RFC5226], this registry operates under "Expert Review" rules. The		operates under "Expert Review" rules. The expert should determine
	expert should determine that the proposed elements, attributes, and/		that the proposed reason is sufficiently distinguishable from other
	or values are within the purview of a vehicle, are sufficiently		reasons and that the proposed description is understandable and
	distinguishable, and clearly and fully described. In most cases, a		correctly worded.
	published and stable document is referenced for the description of
	each element, attribute, or value. New values MUST indicate for
	which attributes or elements they are appropriate. New attributes
	MUST indicate in which elements they can appear and to which values
	that can be set. New elements MUST indicate if they can appear as
	child elements within other elements, and if so which elements, and/
	or if they can appear at the top level of an eCall metadata/control
	object. New elements MUST also describe which attributes and/or sub-
	elements they can contain and which are optional and which are
	mandatory. Note that this mechanism allows new items to be added
	while maintaining compatibility with existing implementations, since
	unrecognized items are ignored.
	The content of this registry includes:		The content of this registry includes:
	Type: 'Element', 'Attribute', or 'Value'.		ID: A short string identifying the reason, for use in the 'reason'
			attribute of an <actionResult> element.
	Name: The name of the new element or attribute. Not used for new		Description: A description of the reason.
	values.
	Description: A description of the element, attribute, or value. In		The initial set of values is listed in Table 3.
	most cases this will be a reference to a published and stable
	document.		+------------------+------------------------------------------------+
			| ID | Description |
			+------------------+------------------------------------------------+
			| unsupported | The 'action' value is not supported. |
			| | |
			| unable | The action could not be accomplished. |
			| | |
			| data-unsupported | The data item referenced in a 'send-data' |
			| | request is not supported. |
			| | |
			| security-failure | The authenticity of the request or the |
			| | authority of the requestor could not be |
			| | verified. |
			+------------------+------------------------------------------------+
			Table 3: Reason Registry
	16. Contributors		16. 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.
	17. Acknowledgements		17. 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, Keith		feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith
	Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and		Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and
	James Winterbottom for their review and comments; Robert Sparks and		James Winterbottom for their review and comments; Robert Sparks and
	Paul Kyzivat for their help with the SIP mechanisms. We would like		Paul Kyzivat for their help with the SIP mechanisms. We would like
	to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and		to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and
	Ulrich Dietz for their help with the original document upon which		Ulrich Dietz for their help with the original document upon which
	this document is based.		this document is based.
	18. Changes from Previous Versions		18. Changes from Previous Versions
	18.1. Changes from draft-ietf-08 to draft-ietf-09		18.1. Changes from draft-ietf-09 to draft-ietf-11
			o Renamed INFO package to emergencyCallData.eCall.MSD
			o Changed INFO package to only permit MSD and metadata/control MIME
			types
			o Moved <capabilities> element back from car-crash but made it
			OPTIONAL
			o Moved other extension points back from car-crash so that extension
			points are in base spec (and also to get XML schema to compile)
			o Text changes for clarification.
			18.2. Changes from draft-ietf-08 to draft-ietf-09
	o Created a new "Data Transport" section that describes how the MSD		o Created a new "Data Transport" section that describes how the MSD
	and metadata/control blocks are attached, and then referred to		and metadata/control blocks are attached, and then referred to
	that section rather than repeat the information about the CID and		that section rather than repeat the information about the CID and
	Call-Info and so forth, which means most references to the		Call-Info and so forth, which means most references to the
	additional-data draft have now been deleted		additional-data draft have now been deleted
	o Mentioned edge cases where a PSAP response to INVITE isn't		o Mentioned edge cases where a PSAP response to INVITE isn't
	received by the IVS		received by the IVS
	o Reworded description of which status codes are used when a PSAP		o Reworded description of which status codes are used when a PSAP
	wishes to reject a call but inform the vehicle occupants that it		wishes to reject a call but inform the vehicle occupants that it
	is aware of the situation to be more definite		is aware of the situation to be more definite
	o Added examples showing INFO		o Added examples showing INFO
	o Added references for eCall test call requirement		o Added references for eCall test call requirement
	o Described meaning of eCall URNs in Section 8 as well as in IANA		o Described meaning of eCall URNs in Section 8 as well as in IANA
	registration		registration
	18.2. Changes from draft-ietf-07 to draft-ietf-08		18.3. Changes from draft-ietf-07 to draft-ietf-08
	o eCall MSD now encoded as ASN.1 PER, using binary content transfer		o eCall MSD now encoded as ASN.1 PER, using binary content transfer
	encoding		encoding
	o Added text to point out aspects of call handling and metadata/		o Added text to point out aspects of call handling and metadata/
	control usage, such as use in rejected calls, and solicited MSDs		control usage, such as use in rejected calls, and solicited MSDs
	o Revised use of INFO to require that when a request for an MSD is		o Revised use of INFO to require that when a request for an MSD is
	sent in INFO, the MSD sent in response is in its own INFO, not the		sent in INFO, the MSD sent in response is in its own INFO, not the
	response to the requesting INFO		response to the requesting INFO
	o Added material to INFO package registation to comply with		o Added material to INFO package registation to comply with
	Section 10 of [RFC6086]		Section 10 of [RFC6086]
	skipping to change at page 34, line 9 ¶		skipping to change at page 37, line 45 ¶
	control elements, attributes, and values		control elements, attributes, and values
	o Revised test call wording to clarify that specific handling is out		o Revised test call wording to clarify that specific handling is out
	of scope		of scope
	o Revised wording throughout the document to simplify		o Revised wording throughout the document to simplify
	o Moved new Section Section 7.1 to be a subsection of Section 7		o Moved new Section Section 7.1 to be a subsection of Section 7
	o Moved new Section Section 10 to be a main section instead of a		o Moved new Section Section 10 to be a main section instead of a
	subsection of Section 9		subsection of Section 9
	o Revised SIP INFO usage and package registration per advice from		o Revised SIP INFO usage and package registration per advice from
	Robert Sparks and Paul Kyzivat		Robert Sparks and Paul Kyzivat
	18.3. Changes from draft-ietf-06 to draft-ietf-07		18.4. Changes from draft-ietf-06 to draft-ietf-07
	o Fixed typo in Acknowledgements		o Fixed typo in Acknowledgements
	18.4. Changes from draft-ietf-05 to draft-ietf-06		18.5. Changes from draft-ietf-05 to draft-ietf-06
	o Added additional security and privacy clarifications regarding		o Added additional security and privacy clarifications regarding
	signed and encrypted data		signed and encrypted data
	o Additional security and privacy text		o Additional security and privacy text
	o Deleted informative section on ESINets as unnecessary.		o Deleted informative section on ESINets as unnecessary.
	18.5. Changes from draft-ietf-04 to draft-ietf-05		18.6. Changes from draft-ietf-04 to draft-ietf-05
	o Reworked the security and privacy considerations material in the		o Reworked the security and privacy considerations material in the
	document as a whole and in the MIME registation sections of the		document as a whole and in the MIME registation sections of the
	MSD and control objects		MSD and control objects
	o Clarified that the <actionResult> element can appear multiple		o Clarified that the <actionResult> element can appear multiple
	times within an <ack> element		times within an <ack> element
	o Fixed IMS definition		o Fixed IMS definition
	o Added clarifying text for the 'msgid' attribute		o Added clarifying text for the 'msgid' attribute
	18.6. Changes from draft-ietf-03 to draft-ietf-04		18.7. Changes from draft-ietf-03 to draft-ietf-04
	o Added Privacy Considerations section		o Added Privacy Considerations section
	o Reworded most uses of non-normative "may", "should", "must", and		o Reworded most uses of non-normative "may", "should", "must", and
	"recommended."		"recommended."
	o Fixed nits in examples		o Fixed nits in examples
	18.7. Changes from draft-ietf-02 to draft-ietf-03		18.8. Changes from draft-ietf-02 to draft-ietf-03
	o Added request to enable cameras		o Added request to enable cameras
	o Improved examples and XML schema		o Improved examples and XML schema
	o Clarifications and wording improvements		o Clarifications and wording improvements
	18.8. Changes from draft-ietf-01 to draft-ietf-02		18.9. Changes from draft-ietf-01 to draft-ietf-02
	o Added clarifying text reinforcing that the data exchange is for		o Added clarifying text reinforcing that the data exchange is for
	small blocks of data infrequently transmitted		small blocks of data infrequently transmitted
	o Clarified that dynamic media is conveyed using SIP re-INVITE to		o Clarified that dynamic media is conveyed using SIP re-INVITE to
	establish a one-way media stream		establish a one-way media stream
	o Clarified that the scope is the needs of eCall within the SIP		o Clarified that the scope is the needs of eCall within the SIP
	emergency call environment		emergency call environment
	o Added informative statement that the document may be suitable for		o Added informative statement that the document may be suitable for
	reuse by other ACN systems		reuse by other ACN systems
	o Clarified that normative language for the control block applies to		o Clarified that normative language for the control block applies to
	both IVS and PSAP		both IVS and PSAP
	o Removed 'ref', 'supported-mime', and <media> elements		o Removed 'ref', 'supported-mime', and <media> elements
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	18.9. Changes from draft-ietf-00 to draft-ietf-01		18.10. 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 in addition to eCall		crash notification specifications in addition to eCall
	o Added details of the eCall metadata and control functionality		o Added details of the eCall metadata and control functionality
	o Added IANA registration for the MIME content type for the eCall		o Added IANA registration for the MIME content type for the eCall
	control object		control object
	o Added IANA registries for protocol elements and tokens used in the		o Added IANA registries for protocol elements and tokens used in the
	eCall control object		eCall control object
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	18.10. Changes from draft-gellens-03 to draft-ietf-00		18.11. Changes from draft-gellens-03 to draft-ietf-00
	o Renamed from draft-gellens- to draft-ietf-.		o Renamed from draft-gellens- to draft-ietf-.
	o Added mention of and reference to ETSI TR "Mobile Standards Group		o Added mention of and reference to ETSI TR "Mobile Standards Group
	(MSG); eCall for VoIP"		(MSG); eCall for VoIP"
	o Added text to Introduction regarding migration/co-existence being		o Added text to Introduction regarding migration/co-existence being
	out of scope		out of scope
	o Added mention in Security Considerations that even if the network-		o Added mention in Security Considerations that even if the network-
	supplied location is just the cell site, this can be useful as a		supplied location is just the cell site, this can be useful as a
	sanity check on the IVS-supplied location		sanity check on the IVS-supplied location
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	18.11. Changes from draft-gellens-02 to -03		18.12. Changes from draft-gellens-02 to -03
	o Clarifications and editorial improvements.		o Clarifications and editorial improvements.
	18.12. Changes from draft-gellens-01 to -02		18.13. Changes from draft-gellens-01 to -02
	o Minor wording improvements		o Minor wording improvements
	o Removed ".automatic" and ".manual" from		o Removed ".automatic" and ".manual" from
	"urn:service:test.sos.ecall" registration and discussion text.		"urn:service:test.sos.ecall" registration and discussion text.
	18.13. Changes from draft-gellens-00 to -01		18.14. 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		MIME subtypes, in accordance with changes to [RFC7852]
	[I-D.ietf-ecrit-additional-data]
	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
	[EN_16062]		[EN_16062]
	CEN, , "Intelligent transport systems - eSafety - eCall		CEN, , "Intelligent transport systems - eSafety - eCall
	High Level Application Requirements (HLAP) Using GSM/UMTS		High Level Application Requirements (HLAP) Using GSM/UMTS
	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-additional-data]
	Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
	J. Winterbottom, "Additional Data Related to an Emergency
	Call", draft-ietf-ecrit-additional-data-38 (work in
	progress), April 2016.
	[msd] CEN, , "Intelligent transport systems -- eSafety -- eCall		[msd] CEN, , "Intelligent transport systems -- eSafety -- eCall
	minimum set of data (MSD), EN 15722", April 2015.		minimum set of data (MSD), EN 15722", April 2015.
	[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>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	skipping to change at page 37, line 19 ¶		skipping to change at page 41, line 9 ¶
	[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,		[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
	DOI 10.17487/RFC7303, July 2014,		DOI 10.17487/RFC7303, July 2014,
	<http://www.rfc-editor.org/info/rfc7303>.		<http://www.rfc-editor.org/info/rfc7303>.
			[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
			J. Winterbottom, "Additional Data Related to an Emergency
			Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
			<http://www.rfc-editor.org/info/rfc7852>.
	[TS22.101]		[TS22.101]
	3GPP, , "3GPP TS 22.101: Technical Specification Group		3GPP, , "3GPP TS 22.101: Technical Specification Group
	Services and System Aspects; Service aspects; Service		Services and System Aspects; Service aspects; Service
	principles".		principles".
	19.2. Informative references		19.2. Informative references
	[CEN] "European Committee for Standardization",		[CEN] "European Committee for Standardization",
	<http://www.cen.eu>.		<http://www.cen.eu>.
End of changes. 127 change blocks.
	338 lines changed or deleted		512 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/