< draft-ietf-ecrit-data-only-ea-15.txt		draft-ietf-ecrit-data-only-ea-16.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: October 25, 2018 Columbia U.		Expires: April 26, 2019 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	Core Technology Consulting		Core Technology Consulting
	April 23, 2018		October 23, 2018
	Data-Only Emergency Calls		Data-Only Emergency Calls
	draft-ietf-ecrit-data-only-ea-15		draft-ietf-ecrit-data-only-ea-16
	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 43 ¶		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 http://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 April 26, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://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 7 ¶		skipping to change at page 3, line 7 ¶
	10.4. IANA Registration of New AlertMsg-Error Header Field . . 19		10.4. IANA Registration of New AlertMsg-Error Header Field . . 19
	10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19		10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	12.1. Normative References . . . . . . . . . . . . . . . . . . 20		12.1. Normative References . . . . . . . . . . . . . . . . . . 20
	12.2. Informative References . . . . . . . . . . . . . . . . . 21		12.2. Informative References . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	RFC 6443 [RFC6443] describes how devices use the Internet to place		[RFC6443] describes how devices use the Internet to place emergency
	emergency calls and how Public Safety Answering Points (PSAPs) handle		calls and how Public Safety Answering Points (PSAPs) handle Internet
	Internet multimedia emergency calls natively. The exchange of		multimedia emergency calls natively. The exchange of multimedia
	multimedia traffic for emergency services involves a SIP session		traffic for emergency services involves a SIP session establishment
	establishment starting with a SIP INVITE that negotiates various		starting with a SIP INVITE that negotiates various parameters for
	parameters for that session.		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 certain types of		environments includes sensors issuing alerts, or certain types of
	medical monitors. 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.
	skipping to change at page 3, line 52 ¶		skipping to change at page 3, line 52 ¶
	(a URI is included in the message, which when dereferenced returns		(a URI is included in the message, which when dereferenced returns
	the CAP message). The additional data mechanism is also used to send		the CAP message). The additional data mechanism is also used to send
	alert specific data beyond that available in the CAP message. This		alert specific data beyond that available in the CAP message. This
	document also describes how a SIP MESSAGE [RFC3428] transaction can		document also describes how a SIP MESSAGE [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 [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
	location-based emergency alert routing.		location-based emergency alert routing.
	1. Emergency alerts containing only data are targeted to an		1. Emergency alerts containing only data are targeted to an
	intermediary recipient responsible for evaluating the next steps.		intermediary recipient responsible for evaluating the next steps.
	These steps could include:		These steps could include:
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 17 ¶
	with a Call-Info header field with a purpose of		with a Call-Info header field with a purpose of
	"EmergencyCallData.cap". The header field may contain a URI that is		"EmergencyCallData.cap". The header field may contain a URI that is
	used by the recipient (or in some cases, an intermediary) to obtain		used by the recipient (or in some cases, an intermediary) to obtain
	the CAP message. Alternative, the Call-Info header field may contain		the CAP message. Alternative, the Call-Info header field may contain
	a Content Indirect url [RFC2392] and the CAP message included in the		a Content Indirect url [RFC2392] and the CAP message included in the
	body of the message. In the latter case, the CAP message is located		body of the message. In the latter case, the CAP message is located
	in a MIME block of the type 'application/emergencyCallData.cap+xml'.		in a MIME block of the type 'application/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 [RFC3261]. This is the appropriate response when a User
	when a User Agent Server (UAS) does not recognize the request method		Agent Server (UAS) does not recognize the request method and is not
	and is not capable of supporting it for any user.		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		[RFC3261] if the SIP server is refusing to service the request
	request because the message body of the request is in a format not		because the message body of the request is in a format not supported
	supported by the server for the requested method. The server MUST		by the server for the requested method. The server MUST return a
	return a list of acceptable formats using the Accept, Accept-		list of acceptable formats using the Accept, Accept-Encoding, or
	Encoding, or Accept-Language header fields, depending on the specific		Accept-Language header fields, depending on the specific problem with
	problem with the content.		the content.
	4.2. Profiling of the CAP Document Content		4.2. Profiling of the CAP Document Content
	The usage of CAP MUST conform to the specification provided with		The usage of CAP MUST conform to the specification provided with
	[cap]. For usage with SIP the following additional requirements are		[cap]. For usage with SIP the following additional requirements are
	imposed:		imposed:
	sender: The following restrictions and conditions apply to setting		sender: The following restrictions and conditions apply to setting
	the value of the <sender> element:		the value of the <sender> element:
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	; (message-header from 3261)		; (message-header from 3261)
	AlertMsg-Error = "AlertMsg-Error" HCOLON		AlertMsg-Error = "AlertMsg-Error" HCOLON
	ErrorValue		ErrorValue
	ErrorValue = error-code		ErrorValue = error-code
	*(SEMI error-params)		*(SEMI error-params)
	error-code = 1*3DIGIT		error-code = 1*3DIGIT
	error-params = error-code-text		error-params = error-code-text
	/ generic-param ; from RFC3261		/ generic-param ; from RFC3261
	error-code-text = "code" EQUAL quoted-string ; from RFC3261		error-code-text = "code" EQUAL quoted-string ; from RFC3261
	HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is		HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined
	defined in RFC5234 [RFC5234].		in [RFC5234].
	The AlertMsg-Error header field MUST contain only one ErrorValue to		The AlertMsg-Error header field MUST contain only one ErrorValue to
	indicate what was wrong with the alert payload the recipient		indicate what was wrong with the alert payload the recipient
	determined was bad.		determined was bad.
	The ErrorValue contains a 3-digit error code indicating what was		The ErrorValue contains a 3-digit error code indicating what was
	wrong with the alert in the request. This error code has a		wrong with the alert in the request. This error code has a
	corresponding quoted error text string that is human understandable.		corresponding quoted error text string that is human understandable.
	The text string is OPTIONAL, but RECOMMENDED for human readability,		The text string is OPTIONAL, but RECOMMENDED for human readability,
	similar to the string phrase used for SIP response codes. That said,		similar to the string phrase used for SIP response codes. That said,
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 18 ¶
	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
	[RFC4474]. The latter provides a cryptographic assurance while		[RFC8224]. The latter provides a cryptographic assurance while
	the former relies on a chain of trust model.		the former relies on a chain of trust model.
	2. CAP provides additional security mechanisms and the ability to		2. CAP provides additional security mechanisms and the ability to
	carry further information about the sender's identity.		carry further information about the sender's identity.
	Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP		Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP
	documents.		documents.
	In addition to the desire to perform identity-based access control,		In addition to the desire to perform identity-based access control,
	the classic communication security threats need to be considered,		the classic communication security threats need to be considered,
	including integrity protection to prevent forgery or replay of alert		including integrity protection to prevent forgery or replay of alert
	messages in transit. To deal with replay of alerts, a CAP document		messages in transit. To deal with replay of alerts, a CAP document
	contains the mandatory <identifier>, <sender>, <sent> elements and an		contains the mandatory <identifier>, <sender>, <sent> elements and an
	optional <expire> element. Together, these elements make the CAP		optional <expire> element. Together, these elements make the CAP
	document unique for a specific sender and provide time restrictions.		document unique for a specific sender and provide time restrictions.
	An entity that has already received a CAP message within the		An entity that has already received a CAP message within the
	indicated timeframe is able to detect a replayed message and, if the		indicated timeframe is able to detect a replayed message and, if the
	content of that message is unchanged, then no additional security		content of that message is unchanged, then no additional security
	vulnerability is created. Additionally, it is RECOMMENDED to make		vulnerability is created. Additionally, it is RECOMMENDED to make
	use of SIP security mechanisms, such as SIP Identity [RFC4474], to		use of SIP security mechanisms, such as SIP Identity [RFC8224], to
	tie the CAP message to the SIP message. To provide protection of the		tie the CAP message to the SIP message. To provide protection of the
	entire SIP message exchange between neighboring SIP entities, the		entire SIP message exchange between neighboring SIP entities, the
	usage of TLS is REQUIRED.		usage of TLS is REQUIRED.
	Note that none of the security mechanism in this document protect		Note that none of the security mechanism in this document protect
	against a compromised sensor sending crafted alerts. Privacy		against a compromised sensor sending crafted alerts. Privacy
	provided for any emergency calls, including data-only messages, is		provided for any emergency calls, including data-only messages, is
	subject to local regulations.		subject to local regulations.
	10. IANA Considerations		10. IANA Considerations
	skipping to change at page 17, line 22 ¶		skipping to change at page 17, line 22 ¶
	MIME media type name: application		MIME media type name: application
	MIME subtype name: cap+xml		MIME subtype name: cap+xml
	Required parameters: (none)		Required parameters: (none)
	Optional parameters: charset; Indicates the character encoding of		Optional parameters: charset; Indicates the character encoding of
	enclosed XML. Default is UTF-8 [RFC3629].		enclosed XML. Default is UTF-8 [RFC3629].
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See RFC		characters, depending on the character encoding used. See
	3023 [RFC3023], Section 3.2.		[RFC3023], Section 3.2.
	Security considerations: This content type is designed to carry		Security considerations: This content type is designed to carry
	payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace		payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace
	by the RFC number of this specification] discusses security		by the RFC number of this specification] discusses security
	considerations for this.		considerations for this.
	Interoperability considerations: This content type provides a way to		Interoperability considerations: This content type provides a way to
	convey CAP payloads.		convey CAP payloads.
	Published specification: RFC XXX [Replace by the RFC number of this		Published specification: RFC XXX [Replace by the RFC number of this
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	documents.php&wg_abbrev=emergency		documents.php&wg_abbrev=emergency
	Person and email address to contact for further information: Hannes		Person and email address to contact for further information: Hannes
	Tschofenig, hannes.tschofenig@gmx.net		Tschofenig, hannes.tschofenig@gmx.net
	Intended usage: Limited use		Intended usage: Limited use
	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 [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 [RFC7852]. The token is "cap", the Data About is		Registry defined in [RFC7852]. The token is "cap", the Data About is
	"The Call" and the reference is this document.		"The Call" and the reference is this document.
	10.3. IANA Registration for 425 Response Code		10.3. IANA Registration for 425 Response Code
	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, <https://www.rfc-		DOI 10.17487/RFC3261, June 2002,
	editor.org/info/rfc3261>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC3428, December 2002,
	editor.org/info/rfc3428>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC5234, January 2008,
	editor.org/info/rfc5234>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC6442, December 2011,
	editor.org/info/rfc6442>.		<https://www.rfc-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>.
	[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and		[RFC7852] 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", RFC 7852, DOI 10.17487/RFC7852, July 2016,		Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
	<https://www.rfc-editor.org/info/rfc7852>.		<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		[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC4474, August 2006, <https://www.rfc-		DOI 10.17487/RFC8224, February 2018,
	editor.org/info/rfc4474>.		<https://www.rfc-editor.org/info/rfc8224>.
	[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, <https://www.rfc-		DOI 10.17487/RFC3325, November 2002,
	editor.org/info/rfc3325>.		<https://www.rfc-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.
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
	US		US
	Email: br@brianrosen.net		Email: br@brianrosen.net
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
End of changes. 23 change blocks.
	46 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/