< draft-ietf-ecrit-data-only-ea-14.txt		draft-ietf-ecrit-data-only-ea-15.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: May 3, 2018 Columbia U.		Expires: October 25, 2018 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	October 30, 2017		Core Technology Consulting
			April 23, 2018
	Data-Only Emergency Calls		Data-Only Emergency Calls
	draft-ietf-ecrit-data-only-ea-14		draft-ietf-ecrit-data-only-ea-15
	Abstract		Abstract
	RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'		RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
	describes how devices use the Internet to place emergency calls and		describes how devices use the Internet to place emergency calls and
	how Public Safety Answering Points (PSAPs) handle Internet multimedia		how Public Safety Answering Points (PSAPs) handle Internet multimedia
	emergency calls natively. The exchange of multimedia traffic for		emergency calls natively. The exchange of multimedia traffic for
	emergency services involves a Session Initiation Protocol (SIP)		emergency services involves a Session Initiation Protocol (SIP)
	session establishment starting with a SIP INVITE that negotiates		session establishment starting with a SIP INVITE that negotiates
	various parameters for that session.		various parameters for that session.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 43 ¶
	transaction.		transaction.
	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 https://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 October 25, 2018.
	This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	RFC 6443 [RFC6443] describes how devices use the Internet to place		RFC 6443 [RFC6443] describes how devices use the Internet to place
	emergency calls and how Public Safety Answering Points (PSAPs) handle		emergency calls and how Public Safety Answering Points (PSAPs) handle
	Internet multimedia emergency calls natively. The exchange of		Internet multimedia emergency calls natively. The exchange of
	multimedia traffic for emergency services involves a SIP session		multimedia traffic for emergency services involves a SIP session
	establishment starting with a SIP INVITE that negotiates various		establishment starting with a SIP INVITE that negotiates various
	parameters for that session.		parameters for that session.
	In some cases, however, there is only application data to be conveyed		In some cases, however, there is only application data to be conveyed
	from the end devices to a PSAP or an intermediary. Examples of such		from the end devices to a PSAP or an intermediary. Examples of such
	environments includes sensors issuing alerts, or vehicles sending		environments includes sensors issuing alerts, or certain types of
	crash data. These messages may be one-shot alerts to emergency		medical monitors. These messages may be one-shot alerts to emergency
	authorities and do not require establishment of a session. These		authorities and do not require establishment of a session. These
	type of interactions are called 'data-only emergency calls'. In this		type of interactions are called 'data-only emergency calls'. In this
	document, we use the term "call" so that similarities between data-		document, we use the term "call" so that similarities between data-
	only (non-interactive) alerts and sessions with interactive media are		only (non-interactive) alerts and sessions with interactive media are
	more obvious.		more obvious.
	Data-only emergency calls are similar to regular emergency calls in		Data-only emergency calls are similar to regular emergency calls in
	the sense that they require the emergency indications, emergency call		the sense that they require the emergency indications, emergency call
	routing functionality and may even have the same location		routing functionality and may even have the same location
	requirements. However, the communication interaction will not lead		requirements. However, the communication interaction will not lead
	to the exchange of interactive media, that is, Real-Time Protocol		to the exchange of interactive media, that is, Real-Time Protocol
	packets, such as voice, video data or real-time text.		packets, such as voice, video data or real-time text.
	The Common Alerting Protocol (CAP) [cap] is a document format for		The Common Alerting Protocol (CAP) [cap] is a format for exchanging
	exchanging emergency alerts and public warnings. CAP is mainly used		emergency alerts and public warnings. CAP is mainly used for
	for conveying alerts and warnings between authorities and from		conveying alerts and warnings between authorities and from
	authorities to citizen/individuals. This document is concerned with		authorities to citizen/individuals. This document is concerned with
	citizen to authority "alerts", where the alert is a call without any		citizen to authority "alerts", where the alert is a call without any
	interactive media.		interactive media.
	This document describes a method of including a CAP message in a SIP		This document describes a method of including a CAP message in a SIP
	transaction, either by value (the CAP message is in the body of the		transaction by defining it as a block of "additional data" as defined
	message, using a CID) or by reference (a URI is included in the		in [RFC7852]. The CAP message is included either by value (the CAP
	message, which when dereferenced returns the CAP message) by defining		message is in the body of the message, using a CID) or by reference
	it as a block of "additional data" as defined in		(a URI is included in the message, which when dereferenced returns
	[I-D.ietf-ecrit-additional-data]. The additional data mechanism is		the CAP message). The additional data mechanism is also used to send
	also used to send alert specific data beyond that available in the		alert specific data beyond that available in the CAP message. This
	CAP message. This document also describes how a SIP MESSAGE		document also describes how a SIP MESSAGE [RFC3428] transaction can
	[RFC3428] transaction can be used to send a data-only call.		be used to send a data-only call.
	2. Terminology		2. 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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Architectural Overview		3. Architectural Overview
	This section illustrates two envisioned usage modes: targeted and		This section illustrates two envisioned usage modes: targeted and
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	1. Sending a non-interactive call containing only data toward a		1. Sending a non-interactive call containing only data toward a
	Public Safety Answering Point (PSAP);		Public Safety Answering Point (PSAP);
	2. Establishing a third-party initiated emergency call towards a		2. Establishing a third-party initiated emergency call towards a
	PSAP that could include audio, video, and data.		PSAP that could include audio, video, and data.
	2. Emergency alerts may be targeted to a Service URN used for IP-		2. Emergency alerts may be targeted to a Service URN used for IP-
	based emergency calls where the recipient is not known to the		based emergency calls where the recipient is not known to the
	originator. In this scenario, the alert may contain only data		originator. In this scenario, the alert may contain only data
	(e.g., a CAP, Geolocation header field and one or more Call-Info		(e.g., a CAP, Geolocation header field and one or more Call-Info
	header fields containing Additional Data		header fields containing Additional Data [RFC7852] in a SIP
	[I-D.ietf-ecrit-additional-data] in a SIP MESSAGE).		MESSAGE).
	Figure 1 shows a deployment variant where a sensor is pre-configured		Figure 1 shows a deployment variant where a sensor is pre-configured
	(using techniques outside the scope of this document) to issue an		(using techniques outside the scope of this document) to issue an
	alert to an aggregator that processes these messages and performs		alert to an aggregator that processes these messages and performs
	whatever steps are necessary to appropriately react to the alert.		whatever steps are necessary to appropriately react to the alert.
	For example, a security firm may use different sensor inputs to		For example, a security firm may use different sensor inputs to
	dispatch their security staff to a building they protect or to		dispatch their security staff to a building they protect or to
	initiate a third-party emergency call.		initiate a third-party emergency call.
	+------------+ +------------+		+------------+ +------------+
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	route the alert message to. A possible receiver is a PSAP and the		route the alert message to. A possible receiver is a PSAP and the
	recipient of the alert may be a call taker. In the generic case,		recipient of the alert may be a call taker. In the generic case,
	there is very likely no prior relationship between the originator and		there is very likely no prior relationship between the originator and
	the receiver, e.g., a PSAP. A PSAP, for example, is likely to		the receiver, e.g., a PSAP. A PSAP, for example, is likely to
	receive and accept alerts from entities it cannot authorize. This		receive and accept alerts from entities it cannot authorize. This
	scenario corresponds to the classic emergency services use case and		scenario corresponds to the classic emergency services use case and
	the description in [RFC6881] is applicable. In this use case, the		the description in [RFC6881] is applicable. In this use case, the
	only difference between an emergency call and an emergency data-only		only difference between an emergency call and an emergency data-only
	call is that the former uses INVITE, creates a session, and		call is that the former uses INVITE, creates a session, and
	negotiates one or more media streams, while the latter uses MESSAGE,		negotiates one or more media streams, while the latter uses MESSAGE,
	does not create a session, and does not have media.		does not create a session, and does not have interactive media.
	+-----------+ +----------+		+----------+ +----------+ +-----------+
	+--------+ | ESRP | | PSAP |		|Sensor or | | ESRP | | PSAP |
	| Sensor | | | | |		|Aggregator| | | | |
	+---+----+ +---+-------+ +---+------+		+----+-----+ +---+------+ +----+------+
	| | |		| | |
	Sensors | |		Sensors | |
	trigger | |		trigger | |
	emergency | |		emergency | |
	alert | |		alert | |
	| | |		| | |
	| | |		| | |
	| MESSAGE with CAP | |		| MESSAGE with CAP | |
	| (including Service URN, |		| (including Service URN, |
	| such as urn:service:sos) |		| such as urn:service:sos) |
	|------------------->| |		|-------------------| |
	| | |		| | |
	| ESRP performs |		| ESRP performs |
	| emergency alert |		| emergency alert |
	| routing |		| routing |
	| | MESSAGE with CAP |		| | MESSAGE with CAP |
	| | (including identity info) |		| | (including identity info) |
	| |----------------------------->|		| |----------------------------->|
	| | |		| | |
	| | PSAP		| | PSAP
	| | processes		| | processes
	| | emergency		| | emergency
	| | alert		| | alert
	| | 200 (OK) |		| | 200 (OK) |
	| |<-----------------------------|		| |<-----------------------------|
	| | |		| | |
	| 200 (OK) | |		| 200 (OK) | |
	|<-------------------| |		|<------------------| |
	| | |		| | |
	| | |		| | |
	Figure 2: Location-Based Emergency Alert Routing		Figure 2: Location-Based Emergency Alert Routing
	4. Protocol Specification		4. Protocol Specification
	4.1. CAP Transport		4.1. CAP Transport
	A CAP message may be sent in the initial message of any SIP		A CAP message may be sent in the initial message of any SIP
	transaction. However, this document only addresses sending a CAP		transaction. However, this document only addresses sending a CAP
	message in a SIP INVITE that initiates an emergency call, or in a SIP		message in a SIP INVITE that initiates an emergency call, or in a SIP
	MESSAGE transaction for a one-shot, data-only emergency call.		MESSAGE transaction for a one-shot, data-only emergency call.
	Behavior with other transactions is not defined.		Behavior with other transactions is not defined.
	The CAP message is included in a SIP message as an additional-data		The CAP message is included in a SIP message as an additional-data
	block [I-D.ietf-ecrit-additional-data]. Accordingly, it is		block [RFC7852]. Accordingly, it is introduced to the SIP message
	introduced to the SIP message with a Call-Info header field with a		with a Call-Info header field with a purpose of
	purpose of "EmergencyCallData.cap". The header field may contain a		"EmergencyCallData.cap". The header field may contain a URI that is
	URI that is used by the recipient (or in some cases, an intermediary)		used by the recipient (or in some cases, an intermediary) to obtain
	to obtain the CAP message. Alternative, the Call-Info header field		the CAP message. Alternative, the Call-Info header field may contain
	may contain a Content Indirect url [RFC2392] and the CAP message		a Content Indirect url [RFC2392] and the CAP message included in the
	included in the body of the message. In the latter case, the CAP		body of the message. In the latter case, the CAP message is located
	message is located in a MIME block of the type 'application/		in a MIME block of the type 'application/emergencyCallData.cap+xml'.
	emergencyCallData.cap+xml'.
	If the SIP server does not support the functionality required to		If the SIP server does not support the functionality required to
	fulfill the request then a 501 Not Implemented MUST be returned as		fulfill the request then a 501 Not Implemented MUST be returned as
	specified in RFC 3261 [RFC3261]. This is the appropriate response		specified in RFC 3261 [RFC3261]. This is the appropriate response
	when a User Agent Server (UAS) does not recognize the request method		when a User Agent Server (UAS) does not recognize the request method
	and is not capable of supporting it for any user.		and is not capable of supporting it for any user.
	The 415 Unsupported Media Type error MUST be returned as specified in		The 415 Unsupported Media Type error MUST be returned as specified in
	RFC 3261 [RFC3261] if the SIP server is refusing to service the		RFC 3261 [RFC3261] if the SIP server is refusing to service the
	request because the message body of the request is in a format not		request because the message body of the request is in a format not
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	information is already available in other SIP header fields.		information is already available in other SIP header fields.
	Populating information twice into different parts of the message		Populating information twice into different parts of the message
	may lead to inconsistency.		may lead to inconsistency.
	parameter: The <parameter> element MAY contain additional		parameter: The <parameter> element MAY contain additional
	information specific to the sender.		information specific to the sender.
	area: It is RECOMMENDED to omit this element when constructing a		area: It is RECOMMENDED to omit this element when constructing a
	message. If the CAP message already contains an <area> element,		message. If the CAP message already contains an <area> element,
	then the specified location information SHOULD be copied into the		then the specified location information SHOULD be copied into the
	PIDF-LO structure of the 'geolocation' header field.		PIDF-LO structure referenced by the 'geolocation' header field.
	4.3. Sending a Data-Only Emergency Call		4.3. Sending a Data-Only Emergency Call
	A data-only emergency call is sent using a SIP MESSAGE transaction		A data-only emergency call is sent using a SIP MESSAGE transaction
	with a CAP URI or body as described above in a manner similar to how		with a CAP URI or body part as described above in a manner similar to
	an emergency call with interactive media is sent, as described in		how an emergency call with interactive media is sent, as described in
	[RFC6881]. The MESSAGE transaction does not create a session nor		[RFC6881]. The MESSAGE transaction does not create a session nor
	send media, but otherwise, the header content of the transaction,		establish interactive media streams, but otherwise, the header
	routing, and processing of data-only calls are the same as those of		content of the transaction, routing, and processing of data-only
	other emergency calls.		calls are the same as those of other emergency calls.
	5. Error Handling		5. Error Handling
	This section defines a new error response code and a header field for		This section defines a new error response code and a header field for
	additional information.		additional information.
	5.1. 425 (Bad Alert Message) Response Code		5.1. 425 (Bad Alert Message) Response Code
	This SIP extension creates a new location-specific response code,		This SIP extension creates a new location-specific response code,
	defined as follows:		defined as follows:
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 26 ¶
	obtain more information, but any such mechanism is not defined in		obtain more information, but any such mechanism is not defined in
	this document. The CAP message may contain related contact		this document. The CAP message may contain related contact
	information for the sender.		information for the sender.
	7. Handling Large Amounts of Data		7. Handling Large Amounts of Data
	It is not atypical for sensors to have large quantities of data that		It is not atypical for sensors to have large quantities of data that
	they may wish to send. Including large amounts of data in a MESSAGE		they may wish to send. Including large amounts of data in a MESSAGE
	is not advisable, because SIP entities are usually not equipped to		is not advisable, because SIP entities are usually not equipped to
	handle very large messages. In such cases, the sender SHOULD make		handle very large messages. In such cases, the sender SHOULD make
	use of the by-reference mechanisms defined in		use of the by-reference mechanisms defined in [RFC7852], which
	[I-D.ietf-ecrit-additional-data], which involves making the data		involves making the data available via HTTPS (either at the
	available via HTTPS (either at the originator or at another entity),		originator or at another entity), placing a URI to the data in the
	placing a URI to the data in the 'Call-Info' header field, and the		'Call-Info' header field, and the recipient using HTTPS to retrieve
	recipient using HTTPS to retrieve the data. The CAP message itself		the data. The CAP message itself can be sent by-reference using this
	can be sent by-reference using this mechanism, as well as any or all		mechanism, as well as any or all of the Additional Data blocks that
	of the Additional Data blocks that may contain sensor-specific data.		may contain sensor-specific data.
	8. Example		8. Example
	The following example shows a CAP document indicating a BURGLARY		The following example shows a CAP document indicating a BURGLARY
	alert issued by a sensor called 'sensor1@domain.com'. The location		alert issued by a sensor called 'sensor1@domain.com'. The location
	of the sensor can be obtained from the attached location information		of the sensor can be obtained from the attached location information
	provided via the 'geolocation' header field contained in the SIP		provided via the 'geolocation' header field contained in the SIP
	MESSAGE structure. Additionally, the sensor provided some data along		MESSAGE structure. Additionally, the sensor provided some data along
	with the alert message, using proprietary information elements		with the alert message, using proprietary information elements
	intended only to be processed by the receiver, a SIP entity acting as		intended only to be processed by the receiver, a SIP entity acting as
	skipping to change at page 15, line 45 ¶		skipping to change at page 15, line 45 ¶
	threats are not unique to this document and are discussed in		threats are not unique to this document and are discussed in
	[RFC7378] and [RFC6442].		[RFC7378] and [RFC6442].
	The ECRIT emergency services architecture [RFC6443] considers classic		The ECRIT emergency services architecture [RFC6443] considers classic
	individual-to-authority emergency calling where the identity of the		individual-to-authority emergency calling where the identity of the
	emergency caller does not play a role at the time of the call		emergency caller does not play a role at the time of the call
	establishment itself, i.e., a response to the emergency call does not		establishment itself, i.e., a response to the emergency call does not
	depend on the identity of the caller. In the case of emergency		depend on the identity of the caller. In the case of emergency
	alerts generated by devices such as sensors, the processing may be		alerts generated by devices such as sensors, the processing may be
	different in order to reduce the number of falsely generated		different in order to reduce the number of falsely generated
	emergency alerts. Alerts may get triggered based on certain sensor		emergency alerts. Alerts could get triggered based on certain sensor
	input that may have been caused by factors other than the actual		input that might have been caused by factors other than the actual
	occurrence of an alert relevant event. For example, a sensor may		occurrence of an alert-relevant event. For example, a sensor may
	simply be malfunctioning. For this reason, not all alert messages		simply be malfunctioning. For this reason, not all alert messages
	are directly sent to a PSAP, but rather may be pre-processed by a		are directly sent to a PSAP, but rather may be pre-processed by a
	separate entity, potentially under supervision by a human, to filter		separate entity, potentially under supervision by a human, to filter
	alerts and potentially correlate received alerts with others to		alerts and potentially correlate received alerts with others to
	obtain a larger picture of the ongoing situation.		obtain a larger picture of the ongoing situation.
	In any case, for alerts initiated by sensors, the identity may play		In any case, for alerts initiated by sensors, the identity could play
	an important role in deciding whether to accept or ignore an incoming		an important role in deciding whether to accept or ignore an incoming
	alert message. With the scenario shown in Figure 1 it is very likely		alert message. With the scenario shown in Figure 1 it is very likely
	that only authorized sensor input will be processed. For this		that only authorized sensor input will be processed. For this
	reason, it needs to be possible to refuse to accept alert messages		reason, it needs to be possible to refuse to accept alert messages
	from an unknown origin. Two types of information elements can be		from an unknown origin. Two types of information elements can be
	used for this purpose:		used for this purpose:
	1. SIP itself provides security mechanisms that allow the		1. SIP itself provides security mechanisms that allow the
	verification of the originator's identity. These mechanisms can		verification of the originator's identity. These mechanisms can
	be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity		be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity
	skipping to change at page 18, line 24 ¶		skipping to change at page 18, line 24 ¶
	Author/Change controller: IETF ECRIT working group		Author/Change controller: IETF ECRIT working group
	Other information: This media type is a specialization of		Other information: This media type is a specialization of
	application/xml RFC 3023 [RFC3023], and many of the considerations		application/xml RFC 3023 [RFC3023], and many of the considerations
	described there also apply to application/cap+xml.		described there also apply to application/cap+xml.
	10.2. IANA Registration of 'cap' Additional Data Block		10.2. IANA Registration of 'cap' Additional Data Block
	This document registers a new block type in the sub-registry called		This document registers a new block type in the sub-registry called
	'Emergency Call Data Types' of the Emergency Call Additional Data		'Emergency Call Data Types' of the Emergency Call Additional Data
	Registry defined in [I-D.ietf-ecrit-additional-data]. The token is		Registry defined in [RFC7852]. The token is "cap", the Data About is
	"cap", the Data About is "The Call" and the reference is this		"The Call" and the reference is this document.
	document.
	10.3. IANA Registration for 425 Response Code		10.3. IANA Registration for 425 Response Code
	In the SIP Response Codes registry, the following is added		In the SIP Response Codes registry, the following is added
	Reference: RFC-XXXX (i.e., this document)		Reference: RFC-XXXX (i.e., this document)
	Response code: 425 (recommended number to assign)		Response code: 425 (recommended number to assign)
	Default reason phrase: Bad Alert Message		Default reason phrase: Bad Alert Message
	skipping to change at page 20, line 45 ¶		skipping to change at page 20, line 45 ¶
	[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.		[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
	1.1", October 2005.		1.1", October 2005.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,		Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
	<https://www.rfc-editor.org/info/rfc2392>.		<https://www.rfc-editor.org/info/rfc2392>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3261>.		editor.org/info/rfc3261>.
	[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,		[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
	Huitema, C., and D. Gurle, "Session Initiation Protocol		Huitema, C., and D. Gurle, "Session Initiation Protocol
	(SIP) Extension for Instant Messaging", RFC 3428,		(SIP) Extension for Instant Messaging", RFC 3428,
	DOI 10.17487/RFC3428, December 2002,		DOI 10.17487/RFC3428, December 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3428>.		editor.org/info/rfc3428>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5234>.		editor.org/info/rfc5234>.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,		Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
	<https://www.rfc-editor.org/info/rfc3023>.		<https://www.rfc-editor.org/info/rfc3023>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <https://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance		[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	for the Session Initiation Protocol", RFC 6442,		for the Session Initiation Protocol", RFC 6442,
	DOI 10.17487/RFC6442, December 2011,		DOI 10.17487/RFC6442, December 2011, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6442>.		editor.org/info/rfc6442>.
	[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,
	<https://www.rfc-editor.org/info/rfc6881>.		<https://www.rfc-editor.org/info/rfc6881>.
	[I-D.ietf-ecrit-additional-data]		[RFC7852] 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-38 (work in		Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
	progress), April 2016.		<https://www.rfc-editor.org/info/rfc7852>.
	12.2. Informative References		12.2. Informative References
	[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, <https://www.rfc-editor.org/info/rfc7378>.		December 2014, <https://www.rfc-editor.org/info/rfc7378>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 4474,
	DOI 10.17487/RFC4474, August 2006,		DOI 10.17487/RFC4474, August 2006, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc4474>.		editor.org/info/rfc4474>.
	[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private		[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
	Extensions to the Session Initiation Protocol (SIP) for		Extensions to the Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted Networks", RFC 3325,		Asserted Identity within Trusted Networks", RFC 3325,
	DOI 10.17487/RFC3325, November 2002,		DOI 10.17487/RFC3325, November 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3325>.		editor.org/info/rfc3325>.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, DOI 10.17487/RFC6443, December		Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
	2011, <https://www.rfc-editor.org/info/rfc6443>.		2011, <https://www.rfc-editor.org/info/rfc6443>.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar, Inc.		NeuStar, Inc.
	skipping to change at page 22, line 45 ¶		skipping to change at page 22, line 45 ¶
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Hannes Tschofenig		Hannes Tschofenig
	ARM Limited		ARM Limited
	Austria		Austria
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Randall Gellens		Randall Gellens
			Core Technology Consulting
	Email: rg+ietf@randy.pensive.org		Email: rg+ietf@coretechnologyconsulting.com
			URI: http://www.coretechnologyconsulting.com
End of changes. 31 change blocks.
	103 lines changed or deleted		101 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/