< draft-ietf-ecrit-ecall-19.txt		draft-ietf-ecrit-ecall-20.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: April 21, 2017 Individual		Expires: May 18, 2017 Individual
	October 18, 2016		November 14, 2016
	Next-Generation Pan-European eCall		Next-Generation Pan-European eCall
	draft-ietf-ecrit-ecall-19.txt		draft-ietf-ecrit-ecall-20.txt
	Abstract		Abstract
	This document describes how to use IP-based emergency services		This document describes how to use IP-based emergency services
	mechanisms to support the next generation of the pan European in-		mechanisms to support the next generation of the pan European in-
	vehicle emergency call service defined under the eSafety initiative		vehicle emergency call service defined under the eSafety initiative
	of the European Commission (generally referred to as "eCall"). eCall		of the European Commission (generally referred to as "eCall"). eCall
	is a standardized and mandated system for a special form of emergency		is a standardized and mandated system for a special form of emergency
	calls placed by vehicles, providing real-time communications and an		calls placed by vehicles, providing real-time communications and an
	integrated set of related data.		integrated set of related data.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 21, 2017.		This Internet-Draft will expire on May 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	10.7. Info Package Usage Restrictions . . . . . . . . . . . . 20		10.7. Info Package Usage Restrictions . . . . . . . . . . . . 20
	10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 20		10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 20
	10.9. Info Package Security Considerations . . . . . . . . . . 20		10.9. Info Package Security Considerations . . . . . . . . . . 20
	10.10. Implementation Details . . . . . . . . . . . . . . . . . 21		10.10. Implementation Details . . . . . . . . . . . . . . . . . 21
	10.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21		10.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21
	11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 26		12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27		13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
	14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 28		14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 28
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	15.1. Service URN Registrations . . . . . . . . . . . . . . . 30		15.1. Service URN Registrations . . . . . . . . . . . . . . . 31
	15.2. MIME Media Type Registration for		15.2. MIME Media Type Registration for
	'application/emergencyCallData.eCall.MSD+per' . . . . . 31		'application/emergencyCallData.eCall.MSD+per' . . . . . 31
	15.3. MIME Media Type Registration for		15.3. MIME Media Type Registration for
	'application/emergencyCallData.control+xml' . . . . . . 32		'application/emergencyCallData.control+xml' . . . . . . 32
	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 . . . . . . . . . . 34		Call Additional Data Blocks registry . . . . . . . . . . 34
	15.5. Registration of the 'control' entry in the Emergency		15.5. Registration of the 'control' entry in the Emergency
	Call Additional Data Blocks registry . . . . . . . . . . 34		Call Additional Data Blocks registry . . . . . . . . . . 34
	15.6. Registration of the emergencyCallData.eCall Info Package 34		15.6. Registration of the emergencyCallData.eCall Info Package 34
	15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34		15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34
	15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34		15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34
	15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35		15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35
	15.8. Registry creation . . . . . . . . . . . . . . . . . . . 36		15.8. Registry Creation . . . . . . . . . . . . . . . . . . . 36
	15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 36		15.8.1. Emergency Call Action Registry . . . . . . . . . . . 36
	15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 37		15.8.2. Emergency Call Action Failure Reason Registry . . . 37
	16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38		16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38
	17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38		17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
	18. Changes from Previous Versions . . . . . . . . . . . . . . . 38		18. Changes from Previous Versions . . . . . . . . . . . . . . . 38
	18.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38		18.1. Changes from draft-ietf-19 to draft-ietf-20 . . . . . . 38
	18.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38		18.2. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38
	18.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38		18.3. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38
	18.4. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38		18.4. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38
	18.5. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 39		18.5. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38
	18.6. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 39		18.6. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 39
	18.7. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 39		18.7. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 39
	18.8. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39		18.8. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 39
	18.9. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39		18.9. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39
	18.10. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 40		18.10. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39
	18.11. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 40		18.11. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 40
	18.12. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40		18.12. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 40
	18.13. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 41		18.13. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40
	18.14. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 41		18.14. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 41
	18.15. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 41		18.15. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 41
	18.16. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41		18.16. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 41
	18.17. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41		18.17. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41
	18.18. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 42		18.18. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41
	18.19. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 42		18.19. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 42
	18.20. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42		18.20. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 42
	18.21. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42		18.21. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42
	18.22. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42		18.22. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42
			18.23. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	19.1. Normative References . . . . . . . . . . . . . . . . . . 43		19.1. Normative References . . . . . . . . . . . . . . . . . . 43
	19.2. Informative references . . . . . . . . . . . . . . . . . 44		19.2. Informative references . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	1. Terminology		1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	| MSD | Minimum Set of Data |		| MSD | Minimum Set of Data |
	| | |		| | |
	| PSAP | Public Safety Answering Point |		| PSAP | Public Safety Answering Point |
	+--------+----------------------------------------+		+--------+----------------------------------------+
	2. Document Scope		2. Document Scope
	This document is focused on the signaling, data exchange, and		This document is focused on the signaling, data exchange, and
	protocol needs of next-generation eCall (NG-eCall, also referred to		protocol needs of next-generation eCall (NG-eCall, also referred to
	as packet-switched eCall or all-IP eCall) within the SIP framework		as packet-switched eCall or all-IP eCall) within the SIP framework
	for emergency calls, as described in [RFC6443] and [RFC6881]. eCall		for emergency calls (as described in [RFC6443] and [RFC6881]). eCall
	itself is specified by 3GPP (3rd Generation Partnership Project) and		itself is specified by 3GPP (3rd Generation Partnership Project) and
	CEN (European Committee for Standardization) and these specifications		CEN (European Committee for Standardization) and these specifications
	include far greater scope than is covered here.		include far greater scope than is covered here.
	The eCall service operates over cellular wireless communication, but		The eCall service operates over cellular wireless communication, but
	this document does not address cellular-specific details, nor client		this document does not address cellular-specific details, nor client
	domain selection (e.g., circuit-switched versus packet-switched).		domain selection (e.g., circuit-switched versus packet-switched).
	All such aspects are the purview of their respective standards		All such aspects are the purview of their respective standards
	bodies. The scope of this document is limited to eCall operating		bodies. The scope of this document is limited to eCall operating
	within a SIP-based environment (e.g., 3GPP IMS Emergency Calling		within a SIP-based environment (e.g., 3GPP IMS Emergency Calling
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	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 eCall signaling as additional		IP, and carries the vehicle data and eCall signaling as additional
	data carried with the call. This document describes how IETF		data carried with the call. This document describes how IETF
	mechanisms for IP-based emergency calls, including [RFC6443] and		mechanisms for IP-based emergency calls (including [RFC6443] and
	[RFC7852] are used to provide the signaling and data exchange of the		[RFC7852]) are used to provide the signaling 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 signaling. 3GPP IMS emergency services support multimedia,		eCall signaling. 3GPP IMS emergency services support multimedia,
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 44 ¶
	package defined in Section 10 . In addition, to align with how an		package defined in Section 10 . In addition, to align with how an
	MSD or metadata/control block is transmitted in a SIP message other		MSD or metadata/control block is transmitted in a SIP message other
	than an INFO request, a Call-Info header field is included in the SIP		than an INFO request, a Call-Info header field is included in the SIP
	INFO request to reference the MSD or metadata/control block. See		INFO request to reference the MSD or metadata/control block. See
	Section 10 for information about the use of INFO requests to carry		Section 10 for information about the use of INFO requests to carry
	data within an eCall.		data within an eCall.
	The IVS is not expected to send an unsolicited MSD after the initial		The IVS is not expected to send an unsolicited MSD after the initial
	INVITE.		INVITE.
	Support for the data blocks defined in [RFC7852] is NOT REQUIRED for		This document does not mandate support for the data blocks defined in
	conformance with this document.		[RFC7852].
	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 28, line 19 ¶		skipping to change at page 28, line 19 ¶
	14. XML Schema		14. XML Schema
	This section defines an XML schema for the control block. The text		This section defines an XML schema for the control block. The text
	description of the control block in Section 9.1 is normative and		description of the control block in Section 9.1 is normative and
	supersedes any conflicting aspect of this schema.		supersedes any conflicting aspect of this schema.
	<artwork>		<artwork>
	<![CDATA[		<![CDATA[
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"		targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData: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:control"		xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData: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"/>
	<xs:element name="EmergencyCallData.control"		<xs:element name="EmergencyCallData.control"
	type="pi:controlType"/>		type="pi:controlType"/>
	<xs:complexType name="controlType">		<xs:complexType name="controlType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:choice>		<xs:choice>
	<xs:element name="capabilities"		<xs:element name="capabilities"
	type="pi:capabilitiesType"/>		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:any namespace="##any" 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:element name="actionResult" minOccurs="0"
	maxOccurs="unbounded">		maxOccurs="unbounded">
	<xs:complexType>		<xs:complexType>
	<xs:attribute name="action"		<xs:attribute name="action"
	type="xs:token"		type="xs:token"
	use="required"/>		use="required"/>
	<xs:attribute name="success"		<xs:attribute name="success"
	type="xs:boolean"		type="xs:boolean"
	use="required"/>		use="required"/>
	<xs:attribute name="reason"		<xs:attribute name="reason"
	type="xs:token">		type="xs:token">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>conditionally		<xs:documentation>
	mandatory when @success='false"		conditionally mandatory
	to indicate reason code for a		when @success='false"
	failure </xs:documentation>		to indicate reason code
			for a failure
			</xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="details"		<xs:attribute name="details"
	type="xs:string"/>		type="xs:string"/>
	<xs:anyAttribute processContents="skip"/>		<xs:anyAttribute
			processContents="skip"/>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:any namespace="##any" processContents="lax"		<xs:any namespace="##any" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</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"
	skipping to change at page 29, line 49 ¶		skipping to change at page 30, line 4 ¶
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="capabilitiesType">		<xs:complexType name="capabilitiesType">
	<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="request"		<xs:element name="request"
	type="pi:requestType"		type="pi:requestType"
	minOccurs="1"		minOccurs="1"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:any namespace="##any" processContents="lax"		<xs:any namespace="##any" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:anyAttribute/>		<xs:anyAttribute/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</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="##any" processContents="lax"		<xs:any namespace="##any" processContents="lax"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</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 name="msgid" type="xs:unsignedInt"/>
	<xs:attribute name="persistence" type="xs:duration"/>		<xs:attribute name="persistence"
			type="xs:duration"/>
	<xs:attribute name="datatype" type="xs:token"/>		<xs:attribute name="datatype" type="xs:token"/>
	<xs:attribute name="supported-values" type="xs:string"/>		<xs:attribute name="supported-values"
			type="xs:string"/>
	<xs:attribute name="element-id" type="xs:token"/>		<xs:attribute name="element-id" type="xs:token"/>
	<xs:attribute name="requested-state" 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 12: Control Block Schema		Figure 12: Control Block Schema
	15. IANA Considerations		15. IANA Considerations
	skipping to change at page 36, line 24 ¶		skipping to change at page 36, line 24 ¶
	Control Block</title>		Control Block</title>
	</head>		</head>
	<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 'Metadata/Control Data'.		This document creates a new registry called "Emergency Call Metadata/
	The following sub-registries are created for this registry.		Control Data". The following sub-registries are created for this
			registry.
	15.8.1. Action Registry		15.8.1. Emergency Call Action Registry
	This document creates a new sub-registry called "Action Registry".		This document creates a new sub-registry called "Emergency Call
	As defined in [RFC5226], this registry operates under "Expert Review"		Action". As defined in [RFC5226], this registry operates under
	rules. The expert should determine that the proposed action is		"Expert Review" rules. The expert should determine that the proposed
	within the purview of a vehicle, is sufficiently distinguishable from		action is within the purview of a vehicle, is sufficiently
	other actions, and the action is clearly and fully described. In		distinguishable from other actions, and the action is clearly and
	most cases, a published and stable document is referenced for the		fully described. In most cases, a published and stable document is
	description of the action.		referenced for the 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 a		Name: The identifier to be used in the 'action' attribute of a
	control <request> element.		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.3.1 of this document |		| send-data | See Section 9.1.3.1 of this document |
	+-----------+--------------------------------------+		+-----------+--------------------------------------+
	Table 2: Action Registry Initial Values		Table 2: Emergency Call Action Registry Initial Values
	15.8.2. Reason Registry		15.8.2. Emergency Call Action Failure Reason Registry
	This document creates a new sub-registry called "Reason Registry"		This document creates a new sub-registry called "Emergency Call
	which contains values for the 'reason' attribute of the		Action Failure Reason" which contains values for the 'reason'
	<actionResult> element. As defined in [RFC5226], this registry		attribute of the <actionResult> element. As defined in [RFC5226],
	operates under "Expert Review" rules. The expert should determine		this registry operates under "Expert Review" rules. The expert
	that the proposed reason is sufficiently distinguishable from other		should determine that the proposed reason is sufficiently
	reasons and that the proposed description is understandable and		distinguishable from other reasons and that the proposed description
	correctly worded.		is understandable and correctly worded.
	The content of this registry includes:		The content of this registry includes:
	ID: A short string identifying the reason, for use in the 'reason'		ID: A short string identifying the reason, for use in the 'reason'
	attribute of an <actionResult> element.		attribute of an <actionResult> element.
	Description: A description of the reason.		Description: A description of the reason.
	The initial set of values is listed in Table 3.		The initial set of values is listed in Table 3.
	skipping to change at page 37, line 51 ¶		skipping to change at page 37, line 51 ¶
	| | appropriate). |		| | appropriate). |
	| | |		| | |
	| data-unsupported | The data item referenced in a 'send-data' |		| data-unsupported | The data item referenced in a 'send-data' |
	| | request is not supported. |		| | request is not supported. |
	| | |		| | |
	| security-failure | The authenticity of the request or the |		| security-failure | The authenticity of the request or the |
	| | authority of the requestor could not be |		| | authority of the requestor could not be |
	| | verified. |		| | verified. |
	+------------------+------------------------------------------------+		+------------------+------------------------------------------------+
	Table 3: Reason Registry		Table 3: Emergency Call Action Failure Reason Registry Initial Values
	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, Ivo Sedlacek, and James Winterbottom		Drage, Stephen Edge, Wes George, Allison Mankin, Ivo Sedlacek, and
	for their review and comments; Robert Sparks and Paul Kyzivat for		James Winterbottom for their review and comments; Robert Sparks and
	their help with the SIP mechanisms; Mark Baker and Ned Freed for		Paul Kyzivat for their help with the SIP mechanisms; Mark Baker and
	their help with the media subtype registration issue. We would like		Ned Freed for their help with the media subtype registration issue.
	to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and		We would like to thank Michael Montag, Arnoud van Wijk, Gunnar
	Ulrich Dietz for their help with the original document upon which		Hellstrom, and Ulrich Dietz for their help with the original document
	this document is based. Christer Holmberg deserves special mention		upon which this document is based. Christer Holmberg deserves
	for his many detailed reviews.		special mention for his many detailed reviews.
	18. Changes from Previous Versions		18. Changes from Previous Versions
	18.1. Changes from draft-ietf-18 to draft-ietf-19		18.1. Changes from draft-ietf-19 to draft-ietf-20
			o Fixed various nits
			18.2. Changes from draft-ietf-18 to draft-ietf-19
	o Added additional text to "Rate of Info Requests"		o Added additional text to "Rate of Info Requests"
	o Added additional text to "Security Considerations"		o Added additional text to "Security Considerations"
	o Further corrected "content type" to "media type"		o Further corrected "content type" to "media type"
	18.2. Changes from draft-ietf-17 to draft-ietf-18		18.3. Changes from draft-ietf-17 to draft-ietf-18
	o Added reference to 3GPP TS24.229		o Added reference to 3GPP TS24.229
	o Clarified that an INFO request is expected to have at least one		o Clarified that an INFO request is expected to have at least one
	MSD or metadata/control body part		MSD or metadata/control body part
	o Fixed minor errors in examples		o Fixed minor errors in examples
	o Corrected "content type" to "media type"		o Corrected "content type" to "media type"
	o Deleted "xsi:schemaLocation" from examples		o Deleted "xsi:schemaLocation" from examples
	18.3. Changes from draft-ietf-16 to draft-ietf-17		18.4. Changes from draft-ietf-16 to draft-ietf-17
	o Clarify Content-Disposition value in INFO requests		o Clarify Content-Disposition value in INFO requests
	18.4. Changes from draft-ietf-15 to draft-ietf-16		18.5. Changes from draft-ietf-15 to draft-ietf-16
	o Various clarifications and simplifications		o Various clarifications and simplifications
	o Added reference to 3GPP 23.167		o Added reference to 3GPP 23.167
	18.5. Changes from draft-ietf-14 to draft-ietf-15		18.6. Changes from draft-ietf-14 to draft-ietf-15
	o eCall body parts now always sent enclosed in multipart (even if		o eCall body parts now always sent enclosed in multipart (even if
	only body part in SIP message) and hence always have a Content-		only body part in SIP message) and hence always have a Content-
	Disposition of By-Reference		Disposition of By-Reference
	o Fixed errors in attribute directionality text		o Fixed errors in attribute directionality text
	o Fixed typos.		o Fixed typos.
	18.6. Changes from draft-ietf-13 to draft-ietf-14		18.7. Changes from draft-ietf-13 to draft-ietf-14
	o Added text to the IANA Considerations to formalize the		o Added text to the IANA Considerations to formalize the
	EmergencyCallData media subtree		EmergencyCallData media subtree
	o Fixed some typos		o Fixed some typos
	18.7. Changes from draft-ietf-12 to draft-ietf-13		18.8. Changes from draft-ietf-12 to draft-ietf-13
	o Clarifications suggested by Christer		o Clarifications suggested by Christer
	o Corrections to Content-Disposition text and examples as suggested		o Corrections to Content-Disposition text and examples as suggested
	by Paul Kyzivat		by Paul Kyzivat
	o Clarifications to Content-Disposition text and examples to clarify		o Clarifications to Content-Disposition text and examples to clarify
	that handling=optional is only used in the initial INVITE		that handling=optional is only used in the initial INVITE
	18.8. Changes from draft-ietf-11 to draft-ietf-12		18.9. Changes from draft-ietf-11 to draft-ietf-12
	o Fixed errors in examples found by Dale		o Fixed errors in examples found by Dale
	o Removed enclosing sub-section of INFO package registration section		o Removed enclosing sub-section of INFO package registration section
	o Added text per Christer and Dale's suggestions that the MSD and		o Added text per Christer and Dale's suggestions that the MSD and
	metadata/control blocks are sent in INFO with a Call-Info header		metadata/control blocks are sent in INFO with a Call-Info header
	field referencing them		field referencing them
	o Deleted Call Routing section (7.1) in favor of a statement that		o Deleted Call Routing section (7.1) in favor of a statement that
	call routing is outside the scope of the document		call routing is outside the scope of the document
	o Other text changes per comments received from Christer and Ivo.		o Other text changes per comments received from Christer and Ivo.
	18.9. Changes from draft-ietf-09 to draft-ietf-11		18.10. Changes from draft-ietf-09 to draft-ietf-11
	o Renamed INFO package to emergencyCallData.eCall.MSD		o Renamed INFO package to emergencyCallData.eCall.MSD
	o Changed INFO package to only permit MSD and metadata/control MIME		o Changed INFO package to only permit MSD and metadata/control MIME
	types		types
	o Moved <capabilities> element back from car-crash but made it		o Moved <capabilities> element back from car-crash but made it
	OPTIONAL		OPTIONAL
	o Moved other extension points back from car-crash so that extension		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)		points are in base spec (and also to get XML schema to compile)
	o Text changes for clarification.		o Text changes for clarification.
	18.10. Changes from draft-ietf-08 to draft-ietf-09		18.11. 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.11. Changes from draft-ietf-07 to draft-ietf-08		18.12. 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 40, line 45 ¶		skipping to change at page 40, 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 7.1 to be a subsection of 7		o Moved new Section 7.1 to be a subsection of 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.12. Changes from draft-ietf-06 to draft-ietf-07		18.13. Changes from draft-ietf-06 to draft-ietf-07
	o Fixed typo in Acknowledgements		o Fixed typo in Acknowledgements
	18.13. Changes from draft-ietf-05 to draft-ietf-06		18.14. 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.14. Changes from draft-ietf-04 to draft-ietf-05		18.15. 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.15. Changes from draft-ietf-03 to draft-ietf-04		18.16. 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.16. Changes from draft-ietf-02 to draft-ietf-03		18.17. 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.17. Changes from draft-ietf-01 to draft-ietf-02		18.18. 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.18. Changes from draft-ietf-00 to draft-ietf-01		18.19. 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 media type for the control		o Added IANA registration for the MIME media type for the control
	object		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
	control object		control object
	o Minor wording improvements and clarifications		o Minor wording improvements and clarifications
	18.19. Changes from draft-gellens-03 to draft-ietf-00		18.20. 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.20. Changes from draft-gellens-02 to -03		18.21. Changes from draft-gellens-02 to -03
	o Clarifications and editorial improvements.		o Clarifications and editorial improvements.
	18.21. Changes from draft-gellens-01 to -02		18.22. 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.22. Changes from draft-gellens-00 to -01		18.23. Changes from draft-gellens-00 to -01
	o Now using 'EmergencyCallData' for purpose parameter values and		o Now using 'EmergencyCallData' for purpose parameter values and
	MIME subtypes, in accordance with changes to [RFC7852]		MIME subtypes, in accordance with changes to [RFC7852]
	o Added reference to RFC 6443		o Added reference to RFC 6443
	o Fixed bug that caused Figure captions to not appear		o Fixed bug that caused Figure captions to not appear
	19. References		19. References
	19.1. Normative References		19.1. Normative References
	[EN_16062]		[EN_16062]
	skipping to change at page 43, line 38 ¶		skipping to change at page 43, line 38 ¶
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for		[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	Emergency and Other Well-Known Services", RFC 5031,		Emergency and Other Well-Known Services", RFC 5031,
	DOI 10.17487/RFC5031, January 2008,		DOI 10.17487/RFC5031, January 2008,
	<http://www.rfc-editor.org/info/rfc5031>.		<http://www.rfc-editor.org/info/rfc5031>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
	2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<http://www.rfc-editor.org/info/rfc6838>.		<http://www.rfc-editor.org/info/rfc6838>.
	[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>.
	skipping to change at page 44, line 27 ¶		skipping to change at page 44, line 23 ¶
	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>.
	[I-D.ietf-ecrit-car-crash]		[I-D.ietf-ecrit-car-crash]
	Gellens, R., Rosen, B., and H. Tschofenig, "Next-		Gellens, R., Rosen, B., and H. Tschofenig, "Next-
	Generation Vehicle-Initiated Emergency Calls", draft-ietf-		Generation Vehicle-Initiated Emergency Calls", draft-ietf-
	ecrit-car-crash-16 (work in progress), October 2016.		ecrit-car-crash-18 (work in progress), October 2016.
	[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for		[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for
	VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),		VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),
	April 2014.		April 2014.
	[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for		[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	RFC 5012, DOI 10.17487/RFC5012, January 2008,		RFC 5012, DOI 10.17487/RFC5012, January 2008,
	<http://www.rfc-editor.org/info/rfc5012>.		<http://www.rfc-editor.org/info/rfc5012>.
	skipping to change at page 44, line 49 ¶		skipping to change at page 44, line 45 ¶
	Shanmugam, "Security Threats and Requirements for		Shanmugam, "Security Threats and Requirements for
	Emergency Call Marking and Mapping", RFC 5069,		Emergency Call Marking and Mapping", RFC 5069,
	DOI 10.17487/RFC5069, January 2008,		DOI 10.17487/RFC5069, January 2008,
	<http://www.rfc-editor.org/info/rfc5069>.		<http://www.rfc-editor.org/info/rfc5069>.
	[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session		[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
	Initiation Protocol (SIP) INFO Method and Package		Initiation Protocol (SIP) INFO Method and Package
	Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,		Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
	<http://www.rfc-editor.org/info/rfc6086>.		<http://www.rfc-editor.org/info/rfc6086>.
			[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
			"Framework for Emergency Calling Using Internet
			Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
			2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.		[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
	Patel, "Public Safety Answering Point (PSAP) Callback",		Patel, "Public Safety Answering Point (PSAP) Callback",
	RFC 7090, DOI 10.17487/RFC7090, April 2014,		RFC 7090, DOI 10.17487/RFC7090, April 2014,
	<http://www.rfc-editor.org/info/rfc7090>.		<http://www.rfc-editor.org/info/rfc7090>.
	[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,		[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
	"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,		"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
	December 2014, <http://www.rfc-editor.org/info/rfc7378>.		December 2014, <http://www.rfc-editor.org/info/rfc7378>.
	[SDO-3GPP]		[SDO-3GPP]
End of changes. 54 change blocks.
	123 lines changed or deleted		136 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/