< draft-ietf-ecrit-data-only-ea-13.txt		draft-ietf-ecrit-data-only-ea-14.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: January 20, 2017 Columbia U.		Expires: May 3, 2018 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	July 19, 2016		October 30, 2017
	Data-Only Emergency Calls		Data-Only Emergency Calls
	draft-ietf-ecrit-data-only-ea-13.txt		draft-ietf-ecrit-data-only-ea-14
	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 SIP session establishment starting with		emergency services involves a Session Initiation Protocol (SIP)
	a SIP INVITE that negotiates various parameters for that session.		session establishment starting with a SIP INVITE that negotiates
			various parameters for that session.
	In some cases, however, the transmission of application data is all		In some cases, however, the transmission of application data is all
	that is needed. Examples of such environments include alerts issued		that is needed. Examples of such environments include alerts issued
	by a temperature sensor, burglar alarm, or chemical spill sensor.		by a temperature sensor, burglar alarm, or chemical spill sensor.
	Often these alerts are conveyed as one-shot data transmissions.		Often these alerts are conveyed as one-shot data transmissions.
	These type of interactions are called 'data-only emergency calls'.		These type of interactions are called 'data-only emergency calls'.
	This document describes a container for the data based on the Common		This document describes a container for the data based on the Common
	Alerting Protocol (CAP) and its transmission using the SIP MESSAGE		Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
	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 January 20, 2017.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	URI that is used by the recipient (or in some cases, an intermediary)		URI that is used by the recipient (or in some cases, an intermediary)
	to obtain the CAP message. Alternative, the Call-Info header field		to obtain the CAP message. Alternative, the Call-Info header field
	may contain a Content Indirect url [RFC2392] and the CAP message		may contain a Content Indirect url [RFC2392] and the CAP message
	included in the body of the message. In the latter case, the CAP		included in the body of the message. In the latter case, the CAP
	message is located in a MIME block of the type 'application/		message is located 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 UAS does not recognize the request method and is not capable		when a User Agent Server (UAS) does not recognize the request method
	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
	supported by the server for the requested method. The server MUST		supported by the server for the requested method. The server MUST
	return a list of acceptable formats using the Accept, Accept-		return a list of acceptable formats using the Accept, Accept-
	Encoding, or Accept-Language header fields, depending on the specific		Encoding, or Accept-Language header fields, depending on the specific
	problem with the content.		problem with the content.
	4.2. Profiling of the CAP Document Content		4.2. Profiling of the CAP Document Content
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	scope: The value of the <scope> element MAY be set to "Private" if		scope: The value of the <scope> element MAY be set to "Private" if
	the alert is not meant for public consumption. The <addresses>		the alert is not meant for public consumption. The <addresses>
	element is, however, not used by this specification since the		element is, however, not used by this specification since the
	message routing is performed by SIP and the respective address		message routing is performed by SIP and the respective address
	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 sendor.		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 of 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 as described above in a manner similar to how
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 16 ¶
	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:
	425 (Bad Alert Message)		425 (Bad Alert Message)
	The 425 response code is a rejection of the request due to its		The 425 response code is a rejection of the request due to its
	included alert content, indicating that it was malformed or not		included alert content, indicating that it was malformed or not
	satisfactory for the recipient's purpose.		satisfactory for the recipient's purpose.
	A SIP intermediary can also reject an alert it receives from a UA		A SIP intermediary can also reject an alert it receives from a User
	when it understands that the provided alert is malformed.		Agent (UA) when it understands that the provided alert is malformed.
	Section 5.2 describes an AlertMsg-Error header field with more		Section 5.2 describes an AlertMsg-Error header field with more
	details about what was wrong with the alert message in the request.		details about what was wrong with the alert message in the request.
	This header field MUST be included in the 425 response.		This header field MUST be included in the 425 response.
	It is only appropriate to generate a 425 response when the responding		It is only appropriate to generate a 425 response when the responding
	entity has no other information in the request that is usable by the		entity has no other information in the request that is usable by the
	responder.		responder.
	A 425 response code MUST NOT be sent in response to a request that		A 425 response code MUST NOT be sent in response to a request that
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is		HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is
	defined in RFC5234 [RFC5234].		defined in RFC5234 [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 are 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,
	the strings are complete enough for rendering to the user, if so		the strings are complete enough for rendering to the user, if so
	desired. The strings in this document are recommendations, and are		desired. The strings in this document are recommendations, and are
	not standardized -- meaning an operator can change the strings -- but		not 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 an MESSAGE to a PSAP. The PSAP		example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
	can accept this MESSAGE, thus creating a dialog, even though its UA		accept this MESSAGE, thus creating a dialog, even though its UA
	determined that the alert message contained in the MESSAGE was bad.		determined that the alert message contained in the MESSAGE was bad.
	The PSAP merely includes an AlertMsg-Error header field value in the		The PSAP merely includes an AlertMsg-Error header field value in the
	200 OK to the MESSAGE, thus informing the UA that the MESSAGE was		200 OK to the MESSAGE, thus informing the UA that the MESSAGE was
	accepted but the alert provided was bad.		accepted but the alert 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
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	use of the by-reference mechanisms defined in		use of the by-reference mechanisms defined in
	[I-D.ietf-ecrit-additional-data], which involves making the data		[I-D.ietf-ecrit-additional-data], which involves making the data
	available via HTTPS (either at the originator or at another entity),		available via HTTPS (either at the originator or at another entity),
	placing a URI to the data in the 'Call-Info' header field, and the		placing a URI to the data in the 'Call-Info' header field, and the
	recipient using HTTPS to retrieve the data. The CAP message itself		recipient using HTTPS to retrieve the data. The CAP message itself
	can be sent by-reference using this mechanism, as well as any or all		can be sent by-reference using this mechanism, as well as any or all
	of the Additional Data blocks that may contain sensor-specific data.		of the Additional Data blocks that may contain sensor-specific data.
	8. Example		8. Example
	This example shows a CAP document indicating a BURGLARY alert issued		The following example shows a CAP document indicating a BURGLARY
	by a sensor called 'sensor1@domain.com'. The location of the sensor		alert issued by a sensor called 'sensor1@domain.com'. The location
	can be obtained from the attached location information provided via		of the sensor can be obtained from the attached location information
	the 'geolocation' header field contained in the SIP MESSAGE		provided via the 'geolocation' header field contained in the SIP
	structure. Additionally, the sensor provided some data along with		MESSAGE structure. Additionally, the sensor provided some data along
	the alert message, using proprietary information elements intended		with the alert message, using proprietary information elements
	only to be processed by the receiver, a SIP entity acting as an		intended only to be processed by the receiver, a SIP entity acting as
	aggregator.		an aggregator.
	MESSAGE sip:aggregator@domain.com SIP/2.0		MESSAGE sip:aggregator@domain.com SIP/2.0
	Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse		Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:sensor1@domain.com;tag=49583		From: sip:sensor1@domain.com;tag=49583
	To: sip:aggregator@domain.com		To: sip:aggregator@domain.com
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@2001:DB8:0:0FF
	Geolocation: <cid:abcdef@domain.com>		Geolocation: <cid:abcdef@domain.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@domain.com;purpose=EmergencyCallData.cap		Call-Info: cid:abcdef2@domain.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 13, line 37 ¶		skipping to change at page 13, line 37 ¶
	</gp:usage-rules>		</gp:usage-rules>
	<gp:method>802.11</gp:method>		<gp:method>802.11</gp:method>
	</gp:geopriv>		</gp:geopriv>
	<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>		<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
	</dm:device>		</dm:device>
	</presence>		</presence>
	--boundary1--		--boundary1--
	Figure 3: Example Message conveying an Alert to an aggregator		Figure 3: Example Message conveying an Alert to an aggregator
	This shows the same CAP document sent as a data-only emergency call		The following shows the same CAP document sent as a data-only
	towards a PSAP.		emergency call towards a PSAP.
	MESSAGE urn:service:sos SIP/2.0		MESSAGE urn:service:sos SIP/2.0
	Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa		Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:aggregator@example.com;tag=32336		From: sip:aggregator@example.com;tag=32336
	To: 112		To: 112
	Call-ID: asdf33443a@example.com		Call-ID: asdf33443a@example.com
	Route: sip:psap1.example.gov		Route: sip:psap1.example.gov
	Geolocation: <cid:abcdef@example.com>		Geolocation: <cid:abcdef@example.com>
	;routing-allowed=yes		;routing-allowed=yes
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 40 ¶
	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 [RFC4474], 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 MANDATORY.		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
	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 20, line 40 ¶		skipping to change at page 20, line 40 ¶
	12.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	[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,
	<http://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,
	<http://www.rfc-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,		DOI 10.17487/RFC3428, December 2002,
	<http://www.rfc-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,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-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,
	<http://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, <http://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,
	<http://www.rfc-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,
	<http://www.rfc-editor.org/info/rfc6881>.		<https://www.rfc-editor.org/info/rfc6881>.
	[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-38 (work in		Call", draft-ietf-ecrit-additional-data-38 (work in
	progress), April 2016.		progress), April 2016.
	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, <http://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,
	<http://www.rfc-editor.org/info/rfc4474>.		<https://www.rfc-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,
	<http://www.rfc-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, <http://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.
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
	US		US
	Email: br@brianrosen.net		Email: br@brianrosen.net
End of changes. 29 change blocks.
	41 lines changed or deleted		42 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/