< draft-ietf-ecrit-data-only-ea-17.txt		draft-ietf-ecrit-data-only-ea-18.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft		Internet-Draft
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: September 12, 2019 Columbia U.		Expires: October 19, 2019 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	Core Technology Consulting		Core Technology Consulting
	March 11, 2019		April 17, 2019
	Data-Only Emergency Calls		Data-Only Emergency Calls
	draft-ietf-ecrit-data-only-ea-17		draft-ietf-ecrit-data-only-ea-18
	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 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 September 12, 2019.		This Internet-Draft will expire on October 19, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	involves making the data available via HTTPS (either at the		involves making the data available via HTTPS (either at the
	originator or at another entity), placing a URI to the data in the		originator or at another entity), placing a URI to the data in the
	'Call-Info' header field, and the recipient using HTTPS to retrieve		'Call-Info' header field, and the recipient using HTTPS to retrieve
	the data. The CAP message itself can be sent by-reference using this		the data. The CAP message itself can be sent by-reference using this
	mechanism, as well as any or all of the Additional Data blocks that		mechanism, as well as any or all 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@example.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
	an aggregator.		an aggregator.
	MESSAGE sip:aggregator@domain.com SIP/2.0		MESSAGE sip:aggregator@example.com SIP/2.0
	Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse		Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:sensor1@domain.com;tag=49583		From: sip:sensor1@example.com;tag=49583
	To: sip:aggregator@domain.com		To: sip:aggregator@example.com
	Call-ID: asd88asd77a@2001:DB8:0:0FF		Call-ID: asd88asd77a@2001:DB8:0:0FF
	Geolocation: <cid:abcdef@domain.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@domain.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@domain.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"?>
	<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">		<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
	<identifier>S-1</identifier>		<identifier>S-1</identifier>
	<sender>sip:sensor1@domain.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>
	<urgency>Expected</urgency>		<urgency>Expected</urgency>
	<certainty>Likely</certainty>		<certainty>Likely</certainty>
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	<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@domain.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"
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	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
	Supported: geolocation		Supported: geolocation
	Accept: application/pidf+xml,application/EmergencyCallData.cap+xml		Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
	Call-info: cid:abcdef2@domain.com;purpose=EmergencyCallData.cap		Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	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>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">		<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
	<identifier>S-1</identifier>		<identifier>S-1</identifier>
	<sender>sip:sensor1@domain.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>
	<urgency>Expected</urgency>		<urgency>Expected</urgency>
	<certainty>Likely</certainty>		<certainty>Likely</certainty>
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	</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@domain.com>		Content-ID: <abcdef2@example.com>
	<?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 33 ¶		skipping to change at page 16, line 33 ¶
	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
	[RFC8224]. 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.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
	skipping to change at page 17, line 31 ¶		skipping to change at page 17, line 31 ¶
	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		characters, depending on the character encoding used. See
	[RFC3023], Section 3.2.		[RFC7303], 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 23 ¶		skipping to change at page 18, line 23 ¶
	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 [RFC3023], 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
	"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 25 ¶		skipping to change at page 20, line 25 ¶
	Details of these error codes are in Section 5.		Details of these error codes are in Section 5.
	11. Acknowledgments		11. Acknowledgments
	The authors would like to thank the participants of the Early Warning		The authors would like to thank the participants of the Early Warning
	adhoc meeting at IETF#69 for their feedback. Additionally, we would		adhoc meeting at IETF#69 for their feedback. Additionally, we would
	like to thank the members of the NENA Long Term Direction Working		like to thank the members of the NENA Long Term Direction Working
	Group for their feedback.		Group for their feedback.
	Additionally, we would like to thank Martin Thomson, James		Additionally, we would like to thank Martin Thomson, James
	Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for		Winterbottom, Shida Schubert, Bernard Aboba, Marc Linsner, Christer
	their review comments.		Holmberg and Ivo Sedlacek for their review comments.
	12. References		12. References
	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.2", October 2005, <https://docs.oasis-
			open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf>.
	[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>.
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 16 ¶
	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>.
	[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-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
	Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,		DOI 10.17487/RFC7303, July 2014,
	<https://www.rfc-editor.org/info/rfc3023>.		<https://www.rfc-editor.org/info/rfc7303>.
	[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-editor.org/info/rfc6442>.		<https://www.rfc-editor.org/info/rfc6442>.
End of changes. 21 change blocks.
	26 lines changed or deleted		27 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/