< draft-ietf-ecrit-data-only-ea-19.txt		draft-ietf-ecrit-data-only-ea-20.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft		Internet-Draft
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: July 31, 2020 Columbia U.		Expires: August 2, 2020 Columbia U.
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	R. Gellens		R. Gellens
	Core Technology Consulting		Core Technology Consulting
	January 28, 2020		January 30, 2020
	Non-Interactive Emergency Calls		Non-Interactive Emergency Calls
	draft-ietf-ecrit-data-only-ea-19		draft-ietf-ecrit-data-only-ea-20
	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 July 31, 2020.		This Internet-Draft will expire on August 2, 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 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	message is in the body of the message, using a CID) or by reference		message is in the body of the message, using a CID) or by reference
	(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 non-interactive call.		be used to send a non-interactive 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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	SIP is the Session Initiation Protocol [RFC3261]		SIP is the Session Initiation Protocol [RFC3261]
	PIDF-LO is Presence Information Data Format - Location Object, a data		PIDF-LO is Presence Information Data Format - Location Object, a data
	structure for carrying location [RFC4119]		structure for carrying location [RFC4119]
	LoST is the Location To Service Translation protocol [RFC5222]		LoST is the Location To Service Translation protocol [RFC5222]
	CID is Content InDirection [RFC2392]		CID is Content InDirection [RFC2392]
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	| | |		| | |
	Sensors | |		Sensors | |
	trigger | |		trigger | |
	emergency | |		emergency | |
	alert | |		alert | |
	| | |		| | |
	| | |		| | |
	| SIP MESSAGE w/CAP | |		| SIP MESSAGE w/CAP | |
	| (including Service URN, |		| (including Service URN, |
	| such as urn:service:sos) |		| such as urn:service:sos) |
	|-------------------| |		|------------------>| |
	| | |		| | |
	| ESRP performs |		| ESRP performs |
	| emergency alert |		| emergency alert |
	| routing |		| routing |
	| | MESSAGE with CAP |		| | MESSAGE with CAP |
	| | (including identity info) |		| | (including identity info) |
	| |----------------------------->|		| |----------------------------->|
	| | |		| | |
	| | PSAP		| | PSAP
	| | processes		| | processes
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	A CAP message may be sent in the initial message of any SIP		A CAP message may be sent in the initial message of any SIP
	transaction. However, this document only addresses sending a CAP		transaction. However, this document only addresses sending a CAP
	message in a SIP MESSAGE transaction for a one-shot, non-interactive		message in a SIP MESSAGE transaction for a one-shot, non-interactive
	emergency call. Behavior with other transactions is not defined.		emergency call. Behavior with other transactions is not defined.
	The CAP message is included in a SIP message as an additional-data		The CAP message is included in a SIP message as an additional-data
	block [RFC7852]. Accordingly, it is introduced to the SIP message		block [RFC7852]. Accordingly, it is introduced to the SIP message
	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. Alternatively, the Call-Info header field may
	a Content Indirect url [RFC2392] and the CAP message included in the		contain a Content Indirect url [RFC2392] and the CAP message included
	body of the message. In the latter case, the CAP message is located		in the body of the message. In the latter case, the CAP message is
	in a MIME block of the type 'application/emergencyCallData.cap+xml'.		located 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 will be returned as
	specified in [RFC3261]. This is the appropriate response when a User		specified in [RFC3261]. This is the appropriate response when a User
	Agent Server (UAS) does not recognize the request method and is not		Agent Server (UAS) does not recognize the request method 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 will be returned as specified in
	[RFC3261] if the SIP server is refusing to service the request		[RFC3261] if the SIP server is refusing to service the request
	because the message body of the request is in a format not supported		because the message body of the request is in a format not supported
	by the server for the requested method. The server MUST return a		by the server for the requested method. The server MUST return a
	list of acceptable formats using the Accept, Accept-Encoding, or		list of acceptable formats using the Accept, Accept-Encoding, or
	Accept-Language header fields, depending on the specific problem with		Accept-Language header fields, depending on the specific 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
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 27 ¶
	in [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 readable. The		corresponding quoted error text string that is human readable. The
	text string is OPTIONAL, but RECOMMENDED for human readability,		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. The
	the strings are complete enough for rendering to the user, if so		strings in this document are recommendations, and are not
	desired. The strings in this document are recommendations, and are		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 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, 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
	skipping to change at page 21, line 15 ¶		skipping to change at page 21, line 15 ¶
	[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>.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
	<https://www.rfc-editor.org/info/rfc5222>.
	[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>.
	[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,		[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
	DOI 10.17487/RFC7303, July 2014,		DOI 10.17487/RFC7303, July 2014,
	<https://www.rfc-editor.org/info/rfc7303>.		<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
	skipping to change at page 21, line 48 ¶		skipping to change at page 21, line 43 ¶
	[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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	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>.
	[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>.
	[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.
			Tschofenig, "LoST: A Location-to-Service Translation
			Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
			<https://www.rfc-editor.org/info/rfc5222>.
	[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
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
End of changes. 13 change blocks.
	22 lines changed or deleted		28 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/