< draft-ietf-ecrit-data-only-ea-20.txt		draft-ietf-ecrit-data-only-ea-21.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft		Internet-Draft
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: August 2, 2020 Columbia U.		Expires: August 17, 2020 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	Core Technology Consulting		Core Technology Consulting
	January 30, 2020		February 14, 2020
	Non-Interactive Emergency Calls		Non-Interactive Emergency Calls
	draft-ietf-ecrit-data-only-ea-20		draft-ietf-ecrit-data-only-ea-21
	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. These calls involve a person,		various parameters for that session. These calls involve a person,
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 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 August 2, 2020.		This Internet-Draft will expire on August 17, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		(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
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Registration of the		10.1. Registration of the
	'application/EmergencyCallData.cap+xml' MIME type . . . 17		'application/EmergencyCallData.cap+xml' MIME type . . . 17
	10.2. IANA Registration of 'cap' Additional Data Block . . . . 18		10.2. IANA Registration of 'cap' Additional Data Block . . . . 18
	10.3. IANA Registration for 425 Response Code . . . . . . . . 18		10.3. IANA Registration for 425 Response Code . . . . . . . . 18
	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 . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	[RFC6443] describes how devices use the Internet to place emergency		[RFC6443] describes how devices use the Internet to place emergency
	calls and how Public Safety Answering Points (PSAPs) handle Internet		calls and how Public Safety Answering Points (PSAPs) handle Internet
	multimedia emergency calls natively. The exchange of multimedia		multimedia emergency calls natively. The exchange of multimedia
	traffic for emergency services involves a SIP session establishment		traffic for emergency services involves a SIP session establishment
	starting with a SIP INVITE that negotiates various parameters for		starting with a SIP INVITE that negotiates various parameters for
	that session.		that session.
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 37 ¶
	similar to the string phrase used for SIP response codes. The		similar to the string phrase used for SIP response codes. The
	strings in this document are recommendations, and are not		strings in this document are recommendations, and are not
	standardized -- meaning an operator can change the strings -- but		standardized -- meaning an operator can change the strings -- but
	MUST NOT change the meaning of the error code. Similar to how RFC		MUST NOT change the meaning of the error code. Similar to how RFC
	3261 specifies, there MUST NOT be more than one string per error		3261 specifies, there MUST NOT be more than one string per error
	code.		code.
	The AlertMsg-Error header field MAY be included in any response if an		The AlertMsg-Error header field MAY be included in any response if an
	alert message was in the request part of the same transaction. For		alert message was in the request part of the same transaction. For
	example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can		example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
	accept this MESSAGE, thus creating a dialog, even though its UA		accept this MESSAGE, even though its UA determined that the alert
	determined that the alert message contained in the MESSAGE was bad.		message contained in the MESSAGE was bad. The PSAP merely includes
	The PSAP merely includes an AlertMsg-Error header field value in the		an AlertMsg-Error header field value in the 200 OK to the MESSAGE,
	200 OK to the MESSAGE, thus informing the UA that the MESSAGE was		thus informing the UA that the MESSAGE was accepted but the alert
	accepted but the alert provided was bad.		provided was bad.
	If, on the other hand, the PSAP cannot accept the transaction without		If, on the other hand, the PSAP cannot accept the transaction without
	a suitable alert message, a 425 response is sent.		a suitable alert message, a 425 response is sent.
	A SIP intermediary that requires the UA's alert message in order to		A SIP intermediary that requires the UA's alert message in order to
	properly process the transaction may also sends a 425 with an		properly process the transaction may also sends a 425 with an
	AlertMsg-Error code.		AlertMsg-Error code.
	This document defines an initial list of AlertMsg-Error values for		This document defines an initial list of AlertMsg-Error values for
	any SIP response, including provisional responses (other than 100		any SIP response, including provisional responses (other than 100
	Trying) and the new 425 response. There MUST be no more than one		Trying) and the new 425 response. There MUST be no more than one
	AlertMsg-Error code in a SIP response.		AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in
			provisional responses must be sent using the mechanism defined in
			[RFC3262]; or, if that mechanism is not negotiated, it must be
			repeated in the final response to the transaction.
	AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"		AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"
	AlertMsg-Error: 101 ; code="Alert Payload was not present or could		AlertMsg-Error: 101 ; code="Alert Payload was not present or could
	not be found"		not be found"
	AlertMsg-Error: 102 ; code="Not enough information to determine the		AlertMsg-Error: 102 ; code="Not enough information to determine the
	purpose of the alert"		purpose of the alert"
	AlertMsg-Error: 103 ; code="Alert Payload was corrupted"		AlertMsg-Error: 103 ; code="Alert Payload was corrupted"
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 15 ¶
	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
	an aggregator.		an aggregator.
	MESSAGE sip:aggregator@example.com SIP/2.0		MESSAGE sip:aggregator@example.com SIP/2.0
	Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse		Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:sensor1@example.com;tag=49583		From: sip:sensor1@example.com;tag=49583
	To: sip:aggregator@example.com		To: sip:aggregator@example.com
	Call-ID: asd88asd77a@2001:DB8:0:0FF		Call-ID: asd88asd77a@2001:db8::ff
	Geolocation: <cid:abcdef@example.com>		Geolocation: <cid:abcdef@example.com>
	;routing-allowed=yes		;routing-allowed=yes
	Supported: geolocation		Supported: geolocation
	Accept: application/pidf+xml,application/EmergencyCallData.cap+xml		Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap		Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 26 ¶
	Geolocation: <cid:abcdef@example.com>		Geolocation: <cid:abcdef@example.com>
	;routing-allowed=yes		;routing-allowed=yes
	Supported: geolocation		Supported: geolocation
	Accept: application/pidf+xml,application/EmergencyCallData.cap+xml		Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap		Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/EmergencyCallData.cap+xml		Content-Type: application/EmergencyCallData.cap+xml
	Content-ID: <abcdef2@example.com>		Content-ID: <abcdef2@example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
	<?xml version="1.0" encoding="UTF-8"?>
	<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">		<?xml version="1.0" encoding="UTF-8"?>
			<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
	<identifier>S-1</identifier>		<identifier>S-1</identifier>
	<sender>sip:sensor1@example.com</sender>		<sender>sip:sensor1@example.com</sender>
	<sent>2008-11-19T14:57:00-07:00</sent>		<sent>2008-11-19T14:57:00-07:00</sent>
	<status>Actual</status>		<status>Actual</status>
	<msgType>Alert</msgType>		<msgType>Alert</msgType>
	<scope>Private</scope>		<scope>Private</scope>
	<incidents>abc1234</incidents>		<incidents>abc1234</incidents>
	<info>		<info>
	<category>Security</category>		<category>Security</category>
	<event>BURGLARY</event>		<event>BURGLARY</event>
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 9 ¶
	<senderName>SENSOR 1</senderName>		<senderName>SENSOR 1</senderName>
	<parameter>		<parameter>
	<valueName>SENSOR-DATA-NAMESPACE1</valueName>		<valueName>SENSOR-DATA-NAMESPACE1</valueName>
	<value>123</value>		<value>123</value>
	</parameter>		</parameter>
	<parameter>		<parameter>
	<valueName>SENSOR-DATA-NAMESPACE2</valueName>		<valueName>SENSOR-DATA-NAMESPACE2</valueName>
	<value>TRUE</value>		<value>TRUE</value>
	</parameter>		</parameter>
	</info>		</info>
	</alert>		</alert>
	--boundary1		--boundary1
	Content-Type: application/pidf+xml		Content-Type: application/pidf+xml
	Content-ID: <abcdef2@example.com>		Content-ID: <abcdef2@example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence		<presence
	xmlns="urn:ietf:params:xml:ns:pidf"		xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gbp=		xmlns:gbp=
	"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"		"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	entity="pres:alice@atlanta.example.com">		entity="pres:alice@atlanta.example.com">
	skipping to change at page 16, line 20 ¶		skipping to change at page 16, line 20 ¶
	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 could 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 authenticated 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, such as P-Asserted-
	be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity		Identity [RFC3325] or SIP Identity [RFC8224]. The latter
	[RFC8224]. The latter provides a cryptographic assurance while		provides a cryptographic assurance while the former relies on a
	the former relies on a chain of trust model.		chain of trust model. These mechanisms can be reused.
	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.4.1 of [cap] specifies the signing algorithms of CAP		Section 3.3.4.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 [RFC8224], to		use of SIP security mechanisms, such as the SIP Identity PASSporT
	tie the CAP message to the SIP message. To provide protection of the		[RFC8225], to tie the CAP message to the SIP message. To provide
	entire SIP message exchange between neighboring SIP entities, the		protection of the entire SIP message exchange between neighboring SIP
	usage of TLS is REQUIRED.		entities, the 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 non-interactive messages,		provided for any emergency calls, including non-interactive messages,
	is subject to local regulations.		is subject to local regulations.
	10. IANA Considerations		10. IANA Considerations
	10.1. Registration of the 'application/EmergencyCallData.cap+xml' MIME		10.1. Registration of the 'application/EmergencyCallData.cap+xml' MIME
	type		type
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 20 ¶
	Additional information: OASIS has published the Common Alerting		Additional information: OASIS has published the Common Alerting
	Protocol at http://www.oasis-open.org/committees/		Protocol at http://www.oasis-open.org/committees/
	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: The IESG
	Other information: This media type is a specialization of		Other information: This media type is a specialization of
	application/xml [RFC7303], and many of the considerations		application/xml [RFC7303], 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
	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 32 ¶
	Header Name compact Reference		Header Name compact Reference
	----------------- ------- ---------		----------------- ------- ---------
	AlertMsg-Error [this doc]		AlertMsg-Error [this doc]
	2. In the portion titled "Header Field Parameters and Parameter		2. In the portion titled "Header Field Parameters and Parameter
	Values", add		Values", add
	Predefined		Predefined
	Header Field Parameter Name Values Reference		Header Field Parameter Name Values Reference
	----------------- ------------------- ---------- ---------		----------------- ------------------- ---------- ---------
	AlertMsg-Error code yes [this doc]		AlertMsg-Error code no [this doc]
	10.5. IANA Registration for the SIP AlertMsg-Error Codes		10.5. IANA Registration for the SIP AlertMsg-Error Codes
	This document creates a new registry for SIP, called "AlertMsg-Error		This document creates a new registry for SIP, called "AlertMsg-Error
	Codes". AlertMsg-Error codes provide reasons for an error discovered		Codes". AlertMsg-Error codes provide reasons for an error discovered
	by a recipient, categorized by the action to be taken by the error		by a recipient, categorized by the action to be taken by the error
	recipient. The initial values for this registry are shown below.		recipient. The initial values for this registry are shown below.
	Registry Name: AlertMsg-Error Codes		Registry Name: AlertMsg-Error Codes
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	[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-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
			[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
			Provisional Responses in Session Initiation Protocol
			(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
			<https://www.rfc-editor.org/info/rfc3262>.
	[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-editor.org/info/rfc3428>.		<https://www.rfc-editor.org/info/rfc3428>.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,		Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
	<https://www.rfc-editor.org/info/rfc4119>.		<https://www.rfc-editor.org/info/rfc4119>.
	skipping to change at page 22, line 11 ¶		skipping to change at page 22, line 17 ¶
	[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>.
	[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		[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 8224,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,		DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.		<https://www.rfc-editor.org/info/rfc8224>.
			[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
			Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
			<https://www.rfc-editor.org/info/rfc8225>.
	[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-editor.org/info/rfc3325>.		<https://www.rfc-editor.org/info/rfc3325>.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.		[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation		Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,		Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
	<https://www.rfc-editor.org/info/rfc5222>.		<https://www.rfc-editor.org/info/rfc5222>.
End of changes. 21 change blocks.
	28 lines changed or deleted		40 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/