< draft-ietf-ecrit-ecall-05.txt		draft-ietf-ecrit-ecall-06.txt >
	ECRIT R. Gellens		ECRIT R. Gellens
	Internet-Draft Qualcomm Technologies, Inc.		Internet-Draft Qualcomm Technologies, Inc.
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: May 8, 2016 (Individual)		Expires: August 22, 2016 (Individual)
	November 5, 2015		February 19, 2016
	Next-Generation Pan-European eCall		Next-Generation Pan-European eCall
	draft-ietf-ecrit-ecall-05.txt		draft-ietf-ecrit-ecall-06.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. eCall deployment is required in the very		calls placed by vehicles. eCall deployment is required in the very
	near future in European Union member states, and eCall (and eCall-		near future in European Union member states, and eCall (and eCall-
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 May 8, 2016.		This Internet-Draft will expire on August 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4		2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6		4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6
	5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 9
	9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10		9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 10
	9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11
	9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12		9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12
	9.1.1.1. Attributes of the <ack> element . . . . . . . . . 13		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 Elements of the <ack> element . . . . . . . 12
	9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14		9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 13
	9.1.2. The <capabilities> element . . . . . . . . . . . . . 15		9.1.2. The <capabilities> element . . . . . . . . . . . . . 14
	9.1.2.1. Child Elements of the <capabilities> element . . 15		9.1.2.1. Child Elements of the <capabilities> element . . 14
	9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16		9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15
	9.1.3. The <request> element . . . . . . . . . . . . . . . . 17		9.1.3. The <request> element . . . . . . . . . . . . . . . . 16
	9.1.3.1. Attributes of the <request> element . . . . . . . 17		9.1.3.1. Attributes of the <request> element . . . . . . . 16
	9.1.3.2. Child Elements of the <request> element . . . . . 19		9.1.3.2. Child Elements of the <request> element . . . . . 18
	9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19		9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19
	9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20		9.2. The emergencyCallData.eCall INFO package . . . . . . . . 19
	10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 25		11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26		12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
	13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27		13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	14.1. Service URN Registrations . . . . . . . . . . . . . . . 30		14.1. Service URN Registrations . . . . . . . . . . . . . . . 29
	14.2. MIME Content-type Registration for		14.2. MIME Content-type Registration for
	'application/emergencyCallData.eCall.MSD+xml' . . . . . 30		'application/emergencyCallData.eCall.MSD+xml' . . . . . 30
	14.3. MIME Content-type Registration for		14.3. MIME Content-type Registration for
	'application/emergencyCallData.eCall.control+xml' . . . 32		'application/emergencyCallData.eCall.control+xml' . . . 31
	14.4. Registration of the 'eCall.MSD' entry in the Emergency		14.4. Registration of the 'eCall.MSD' entry in the Emergency
	Call Additional Data Blocks registry . . . . . . . . . . 33		Call Additional Data Blocks registry . . . . . . . . . . 33
	14.5. Registration of the 'eCall.control' entry in the		14.5. Registration of the 'eCall.control' entry in the
	Emergency Call Additional Data Blocks registry . . . . . 34		Emergency Call Additional Data Blocks registry . . . . . 33
	14.6. Registration of the emergencyCallData.eCall Info Package 34		14.6. Registration of the emergencyCallData.eCall Info Package 33
	14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34		14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33
	14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34		14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33
	14.7.2. Registration for		14.7.2. Registration for
	urn:ietf:params:xml:ns:eCall:control . . . . . . . . 35		urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34
	14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35		14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35
	14.8.1. eCall Control Action Registry . . . . . . . . . . . 35		14.8.1. eCall Control Action Registry . . . . . . . . . . . 35
	14.8.2. eCall Static Message Registry . . . . . . . . . . . 36		14.8.2. eCall Static Message Registry . . . . . . . . . . . 36
	14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37		14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37
	14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38		14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38
	14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39		14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39
	15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40		15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40		16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
	17. Changes from Previous Versions . . . . . . . . . . . . . . . 40		17. Changes from Previous Versions . . . . . . . . . . . . . . . 39
	17.1. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40		17.1. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40
	17.2. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40		17.2. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40
	17.3. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41		17.3. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40
	17.4. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41		17.4. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40
	17.5. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41		17.5. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40
	17.6. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41		17.6. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41
	17.7. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42		17.7. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41
	17.8. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42		17.8. Changes from draft-gellens-02 to -03 . . . . . . . . . . 41
	17.9. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42		17.9. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		17.10. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41
			18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	18.1. Normative References . . . . . . . . . . . . . . . . . . 42		18.1. Normative References . . . . . . . . . . . . . . . . . . 42
	18.2. Informative references . . . . . . . . . . . . . . . . . 43		18.2. Informative references . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	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 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	emergency calls because eCalls are special types of emergency calls		emergency calls because eCalls are special types of emergency calls
	(with implications for the types of response required) and need to be		(with implications for the types of response required) and need to be
	handled by specially designated PSAPs. In an environment that uses		handled by specially designated PSAPs. In an environment that uses
	ESInets, the originating network passes all types of emergency calls		ESInets, the originating network passes all types of emergency calls
	to an ESInet (which have a request URI containing the "SOS" service		to an ESInet (which have a request URI containing the "SOS" service
	URN). The ESInet is then responsible for routing such calls to the		URN). The ESInet is then responsible for routing such calls to the
	appropriate PSAP. In an environment without an ESInet, the emergency		appropriate PSAP. In an environment without an ESInet, the emergency
	services authorities and the originating network jointly determine		services authorities and the originating network jointly determine
	how such calls are routed.		how such calls are routed.
	7.1. ESInets
	This section provides background information on ESInets for
	information only.
	An Emergency Services IP Network (ESInet) is a network operated by
	emergency services authorities. It handles emergency call routing
	and processing before delivery to a PSAP. In the NG1-1-2
	architecture adopted by EENA, each PSAP is connected to one or more
	ESInets. Each originating network is also connected to one or more
	ESInets. The ESInets maintain policy-based routing rules which
	control the routing and processing of emergency calls. The
	centralization of such rules within ESInets provides for a cleaner
	separation between the responsibilities of the originating network
	and that of the emergency services network, and provides greater
	flexibility and control over processing of emergency calls by the
	emergency services authorities. This makes it easier to react
	quickly to unusual situations that require changes in how emergency
	calls are routed or handled (e.g., a natural disaster closes a PSAP),
	as well as ease in making long-term changes that affect such routing
	(e.g., cooperative agreements to specially handle calls requiring
	translation or relay services). ESInets might support the ability to
	interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that
	are not IP PSAPs (similarly to the ability to interwork IP emergency
	calls to legacy non-IP PSAPs). Note that in order to support legacy
	eCall-capable PSAPs that are not IP PSAPs and are not attached to an
	ESInet, an originating network might need the ability to route an
	eCall itself (e.g., to an interworking facility with interconnection
	to a suitable legacy eCall capable PSAP) based on the eCall and
	manual or automatic indications. The ETSI TR "Mobile Standards Group
	(MSG); eCall for VoIP" [MSG_TR] discusses transition issues in Clause
	7.
	8. Test Calls		8. Test Calls
	eCall requires the ability to place test calls. These are calls that		eCall requires the ability to place test calls. These are calls that
	are recognized and treated to some extent as eCalls but are not given		are recognized and treated to some extent as eCalls but are not given
	emergency call treatment and are not handled by call takers. The		emergency call treatment and are not handled by call takers. The
	test call facility allows the IVS or user to verify that an eCall can		test call facility allows the IVS or user to verify that an eCall can
	be successfully established with voice communication. The IVS can		be successfully established with voice communication. The IVS can
	also verify that the MSD was successfully received.		also verify that the MSD was successfully received.
	A service URN starting with "test." indicates a test call. For		A service URN starting with "test." indicates a test call. For
	skipping to change at page 26, line 43 ¶		skipping to change at page 25, line 43 ¶
	Implementors need to be aware that, potentially, the data objects		Implementors need to be aware that, potentially, the data objects
	described here and elsewhere might be malformed, might contain		described here and elsewhere might be malformed, might contain
	unexpected characters, excessively long attribute values, elements,		unexpected characters, excessively long attribute values, elements,
	etc. (This applies across the board, not just to the 'text'		etc. (This applies across the board, not just to the 'text'
	attribute of a <request> element.)		attribute of a <request> element.)
	Since this document depends on [I-D.ietf-ecrit-additional-data], the		Since this document depends on [I-D.ietf-ecrit-additional-data], the
	security considerations discussed there apply here (see especially		security considerations discussed there apply here (see especially
	the discussion of TLS, TLS versions, cypher suites, and PKI).		the discussion of TLS, TLS versions, cypher suites, and PKI).
			When vehicle data or control/metadata is contained in a signed or
			encrypted body part, the enclosing multipart (e.g., multipart/signed
			or multipart/encrypted) has the same Content-ID as the data part.
			This allows an entity to identify and access the data blocks it is
			interested in without having to dive deeply into the message
			structure or decrypt parts it is not interested in. (The 'purpose'
			parameter in a Call-Info header field identifies the data, and the
			CID URL points to the data block in the body, which has a matching
			Content-ID body part header field).
	12. Privacy Considerations		12. Privacy Considerations
	Since this document builds on [I-D.ietf-ecrit-additional-data], the		Since this document builds on [I-D.ietf-ecrit-additional-data], the
	data structures specified there, and the corresponding privacy		data structures specified there, and the corresponding privacy
	considerations discussed there, apply here as well. The MSD carries		considerations discussed there, apply here as well. The MSD carries
	some additional identifying and personal information (mostly about		some additional identifying and personal information (mostly about
	the vehicle and less about the owner), as well as location		the vehicle and less about the owner), as well as location
	information, and so needs to be protected against unauthorized		information, and so needs to be protected against unauthorized
	disclosure. Local regulations may impose additional privacy		disclosure. Local regulations may impose additional privacy
	protection requirements. The additional functionality enabled by		protection requirements. The additional functionality enabled by
	skipping to change at page 40, line 24 ¶		skipping to change at page 39, line 42 ¶
	Table 6: eCall Camera ID Registry Initial Values		Table 6: eCall Camera ID Registry Initial Values
	15. Contributors		15. Contributors
	Brian Rosen was a co-author of the original document upon which this		Brian Rosen was a co-author of the original document upon which this
	document is based.		document is based.
	16. Acknowledgements		16. Acknowledgements
	We would like to thank Bob Williams and Ban Al-Bakri for their		We would like to thank Bob Williams and Ban Al-Bakri for their
	feedback and suggestions, and Keith Drage, James Winterbottom, and		feedback and suggestions, and Keith Drage, James Winterbottom, Wes
	Wes George for their review and comments. We would like to thank		George, and Rex Buddenber for their review and comments. We would
	Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz		like to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and
	for their help with the original document upon which this document is		Ulrich Dietz for their help with the original document upon which
	based.		this document is based.
	17. Changes from Previous Versions		17. Changes from Previous Versions
			17.1. Changes from draft-ietf-05 to draft-ietf-06
	17.1. Changes from draft-ietf-04 to draft-ietf-05		o Added additional security and privacy clarifications regarding
			signed and encrypted data
			o Additional security and privacy text
			o Deleted informative section on ESINets as unnecessary.
			17.2. 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
	17.2. Changes from draft-ietf-03 to draft-ietf-04		17.3. 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
	17.3. Changes from draft-ietf-02 to draft-ietf-03		17.4. 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
	17.4. Changes from draft-ietf-01 to draft-ietf-02		17.5. 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
	17.5. Changes from draft-ietf-00 to draft-ietf-01		17.6. 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
	17.6. Changes from draft-gellens-03 to draft-ietf-00		17.7. 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
	17.7. Changes from draft-gellens-02 to -03		17.8. Changes from draft-gellens-02 to -03
	o Clarifications and editorial improvements.		o Clarifications and editorial improvements.
	17.8. Changes from draft-gellens-01 to -02		17.9. 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.
	17.9. Changes from draft-gellens-00 to -01		17.10. 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
	[I-D.ietf-ecrit-additional-data]		[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
	18. References		18. References
	18.1. Normative References		18.1. Normative References
	[EN_16072]		[EN_16072]
	CEN, , "Intelligent transport systems - eSafety - Pan-		CEN, , "Intelligent transport systems - eSafety - Pan-
	European eCall operating requirements", December 2011.		European eCall operating requirements", December 2011.
	[I-D.ietf-ecrit-additional-data]		[I-D.ietf-ecrit-additional-data]
	Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and		Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
	J. Winterbottom, "Additional Data Related to an Emergency		J. Winterbottom, "Additional Data Related to an Emergency
	Call", draft-ietf-ecrit-additional-data-37 (work in		Call", draft-ietf-ecrit-additional-data-37 (work in
End of changes. 26 change blocks.
	91 lines changed or deleted		73 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/