Diff: rfc8876xml2.original.xml

	rfc8876xml2.original.xml	rfc8876.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-stylesheet type=<?xml version="1.0" encoding="US-ASCII"?>	<?xml-stylesheet type=<?xml version="1.0" encoding="US-ASCII"?>

	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc symrefs="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8876" consensus="true"
	<?rfc sortrefs="no"?>	category="std" docName="draft-ietf-ecrit-data-only-ea-22"
	<?rfc iprnotified="no" ?>	ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
	<?rfc strict="no" ?>	xml:lang="en" tocInclude="true" symRefs="true" sortRefs="false"
	<?rfc compact="no" ?>	version="3">
	<?rfc subcompact="no" ?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2392 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2392.xml">
	<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2818.xml">
	<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3261.xml">
	<!ENTITY RFC3262 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3262.xml">
	<!ENTITY RFC3428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3428.xml">
	<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3986.xml">
	<!ENTITY RFC4119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4119.xml">
	<!ENTITY RFC5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5031.xml">
	<!ENTITY RFC5222 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5222.xml">
	<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5234.xml">
	<!ENTITY RFC7303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7303.xml">
	<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3629.xml">
	<!ENTITY RFC8224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8224.xml">
	<!ENTITY RFC8225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8225.xml">
	<!ENTITY RFC3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3325.xml">
	<!ENTITY RFC6442 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6442.xml">
	<!ENTITY RFC6443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6443.xml">
	<!ENTITY RFC6881 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6881.xml">
	<!ENTITY RFC7378 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7378.xml">
	<!ENTITY RFC7852 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7852.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	]>
	<rfc category="std" docName="draft-ietf-ecrit-data-only-ea-22" ipr="trust200902"
	>
	<front>	<front>

	<title>Non-Interactive Emergency Calls</title>	<title>Non-interactive Emergency Calls</title>
		<seriesInfo name="RFC" value="8876"/>
	<author initials="B." surname="Rosen" fullname="Brian Rosen">	<author initials="B." surname="Rosen" fullname="Brian Rosen">

	<address>	<address>
	<postal>	<postal>
	<street>470 Conrad Dr</street>	<street>470 Conrad Dr</street>
	<city>Mars</city>	<city>Mars</city>
	<region> PA </region>	<region> PA </region>
	<code>16046 </code>	<code>16046 </code>

	<country>US </country>	<country>United States of America</country>
	</postal>	</postal>
	<phone> </phone>	<phone> </phone>
	<email>br@brianrosen.net	<email>br@brianrosen.net
	</email>	</email>
	</address>	</address>
	</author>	</author>
	<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">	<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
	<organization abbrev="Columbia U.">Columbia University</organization>	<organization abbrev="Columbia U.">Columbia University</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Department of Computer Science</street>	<street>Department of Computer Science</street>
	<street>450 Computer Science Building</street>	<street>450 Computer Science Building</street>
	<city>New York</city>	<city>New York</city>
	<region>NY</region>	<region>NY</region>
	<code>10027</code>	<code>10027</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 212 939 7004</phone>	<phone>+1 212 939 7004</phone>
	<email>hgs+ecrit@cs.columbia.edu</email>	<email>hgs+ecrit@cs.columbia.edu</email>

	<uri>http://www.cs.columbia.edu</uri>	<uri>https://www.cs.columbia.edu</uri>
	</address>	</address>
	</author>	</author>
	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">

	<organization>ARM Limited</organization>
	<address>	<address>
	<postal>	<postal>
	<street> </street>	<street> </street>
	<country>Austria</country>	<country>Austria</country>
	</postal>	</postal>
	<email>Hannes.Tschofenig@gmx.net</email>	<email>Hannes.Tschofenig@gmx.net</email>

	<uri>http://www.tschofenig.priv.at</uri>	<uri>https://www.tschofenig.priv.at</uri>
	</address>	</address>
	</author>	</author>

	<author fullname="Randall Gellens" initials="R."	<author fullname="Randall Gellens" initials="R." surname="Gellens">
	surname="Gellens">
	<organization>Core Technology Consulting</organization>	<organization>Core Technology Consulting</organization>


	<address>	<address>


	<email>rg+ietf@coretechnologyconsulting.com</email>	<email>rg+ietf@coretechnologyconsulting.com</email>
	<uri>http://www.coretechnologyconsulting.com</uri>	<uri>http://www.coretechnologyconsulting.com</uri>
	</address>	</address>
	</author>	</author>

	<date year="2020"/>	<date month="September" year="2020"/>
	<area>ART</area>	<area>ART</area>
	<workgroup>ECRIT</workgroup>	<workgroup>ECRIT</workgroup>

	<keyword>Internet-Draft</keyword>
	<keyword>CAP</keyword>	<keyword>CAP</keyword>
	<keyword>Common Alerting Protocol</keyword>	<keyword>Common Alerting Protocol</keyword>
	<keyword>Non-Interactive Emergency calls</keyword>	<keyword>Non-Interactive Emergency calls</keyword>

	<abstract>	<abstract>

	<t>	<t>
	Use of the Internet for emergency calling is described in RFC 6443, 'Framework	Use of the Internet for emergency calling is described in RFC 6443, 'Framework
	for Emergency Calling Using Internet Multimedia'. In some cases of emergency	for Emergency Calling Using Internet Multimedia'. In some cases of emergency

	calls, the transmission of application data is all that is needed and no	calls, the transmission of application data is all that is needed, and no
	interactive media channel is established: a situation referred to as	interactive media channel is established: a situation referred to as

	'non-interactive emergency calls', where, unlike most emergency calls, there is	'non-interactive emergency calls', where, unlike most emergency calls, there
	no two way interactive	is no two-way interactive media such as voice or video or text. This document
	media such as voice or video or text. This document describes use of a SIP MESS	describes use of a SIP MESSAGE transaction that includes a container for the
	AGE	data based on the Common Alerting Protocol (CAP). That type of emergency
	transaction that includes a container for the data based on the Common Alerting	request does not establish a session, distinguishing it from SIP INVITE, which
	Protocol (CAP). That type of emergency request does not establish a session,	does. Any device that needs to initiate a request for emergency services
	distinguishing it from SIP INVITE, which does. Any device that needs to	without an interactive media channel would use the mechanisms in this
	initiate a request for emergency services without an interactive media channel	document. </t>
	would use the mechanisms in this document. </t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<!-- /////////////////////////////////////////////////////////////////////// /////////// -->


	<section anchor="introduction" title="Introduction">	<section anchor="introduction" numbered="true" toc="default">
		<name>Introduction</name>
		<t><xref target="RFC6443" format="default"/> describes how devices use
		the Internet to place emergency calls and how Public Safety Answering
		Points (PSAPs) handle Internet multimedia emergency calls natively. The
		exchange of multimedia traffic for emergency services involves a SIP
		session establishment starting with a SIP INVITE that negotiates various
		parameters for that session.</t>
		<t>In some cases, however, there is only application data to be conveyed
		from the end devices to a PSAP or an intermediary. Examples of such
		environments include sensors issuing alerts, and certain types of
		medical monitors. These messages may be alerts to emergency
		authorities and do not require establishment of a session. These types
		of interactions are called 'non-interactive emergency calls'. In this
		document, we use the term "call" so that similarities between
		non-interactive alerts and sessions with interactive media are more
		obvious.
		</t>


	<t><xref target="RFC6443"/> describes how devices use the Interne	<t>Non-interactive emergency calls are similar to regular emergency
	t to place	calls in the sense that they require the emergency indications,
	emergency calls and how Public Safety Answering Points (PSAPs) handle Interne	emergency call routing functionality, and location. However, the
	t multimedia	communication interaction will not lead to the exchange of interactive
	emergency calls natively. The exchange of multimedia traffic for emergency se	media, that is, Real-Time Transport Protocol <xref target="RFC3550"/> pack
	rvices involves a SIP session establishment starting with a SIP INVITE that nego	ets, such as voice, video, or
	tiates various parameters for that session.</t>	real-time text.</t>


	<t>In some cases, however, there is only application data to be conveyed from	<t>
	the end devices to a PSAP or an intermediary.	The Common Alerting Protocol (CAP) <xref target="CAP" format="default"/> is a
	Examples of such environments include sensors issuing alerts, and certain typ	format for exchanging emergency alerts and public warnings. CAP is mainly
	es of medical monitors. These messages may be one-shot alerts to emergency autho	used for conveying alerts and warnings between authorities and from
	rities and do not require establishment of a session. These types of interaction	authorities to the public. The scope of this document is conveying CAP alerts
	s are called 'non-interactive emergency calls'. In this document, we use the te	from private devices to emergency service authorities, as a call without any
	rm "call" so that similarities between non-interactive alerts and sessions with	interactive media.
	interactive media are more obvious.	</t>
	</t>
	<t>Non-interactive emergency calls are similar to regular emergency calls in t
	he sense that they
	require the emergency indications, emergency call routing functionality
	and location.
	However, the communication interaction will not lead
	to the exchange of interactive media, that is, Real-Time Protocol packet
	s, such as voice, video data or real-time text.</t>
	<t>The Common Alerting Protocol (CAP) <xref target="cap"/> is a format for
	exchanging emergency alerts and public warnings. CAP is mainly used
	for conveying alerts and warnings between authorities and from
	authorities to citizens/individuals. This document is concerned with citizen
	-to-authority "alerts", where the alert is a call without any interactive media.
	</t>
	<t>This document describes a method of including a CAP message in a SIP trans
	action by defining it as a block of "additional data" as defined in <xref target
	="RFC7852"/>. The CAP message is included either by value (the CAP message is i
	n the body of the message, using a CID) or by reference (the message includes a
	URI that, when dereferenced, returns
	the CAP message). The additional data mechanism is also used to send alert-sp
	ecific data beyond that available in the CAP message. This document also descri
	bes how a SIP MESSAGE <xref target="RFC3428"/> transaction can be used to send a
	non-interactive call.</t>


		<t>This document describes a method of including a CAP alert in a SIP
		transaction by defining it as a block of "additional data" as defined in
		<xref target="RFC7852" format="default"/>. The CAP alert is included
		either by value (the CAP alert is in the body of the message, using a
		CID) or by reference (the message includes a URI that, when
		dereferenced, returns the CAP alert). The additional data mechanism
		is also used to send alert-specific data beyond that available in the
		CAP alert. This document also describes how a SIP MESSAGE <xref
		target="RFC3428" format="default"/> transaction can be used to send a
		non-interactive call.</t>
	</section>	</section>


	<!-- ///////////////////////////////////////////////////////////////////////	<section anchor="terminology" numbered="true" toc="default">
	/////////// -->	<name>Terminology</name>


	<section anchor="terminology" title="Terminology">	<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
		to be interpreted as described in BCP 14 <xref target="RFC2119"/>
		<xref target="RFC8174"/> when, and only when, they appear in all capitals,
		as shown here.
		</t>


	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<dl>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when
	, and only when, they
	appear in all capitals, as shown here.</t>
	<t>A non-interactive emergency call is an emergency call where there is no two-w
	ay interactive media. </t>
	<t>SIP is the Session Initiation Protocol <xref target="RFC3261"/></t>
	<t>PIDF-LO is Presence Information Data Format - Location Object, a data st
	ructure for carrying location <xref target="RFC4119"/></t>
	<t>LoST is the Location To Service Translation protocol <xref target="RFC52
	22"/></t>
	<t>CID is Content-ID <xref target="RFC2392"/></t>
	<t>CAP is the Common Alerting Protocol <xref target="cap"/></t>
	<t>PSAP is a Public Safety Answering Point, the call center for emergency c
	alls.</t>
	<t>ESRP is an Emergency Services Routing Proxy, a type of SIP Proxy Server
	used in some emergency services networks</t>


	</section>	<dt>Non-interactive emergency call:
		</dt>
		<dd>An emergency call where there is no two-way interactive media
		</dd>


	<!-- ///////////////////////////////////////////////////////////////////////	<dt>SIP:
	/////////// -->	</dt>
		<dd>Session Initiation Protocol <xref target="RFC3261"/>
		</dd>


	<section anchor="arch" title="Architectural Overview">	<dt>PIDF-LO:
	<t>This section illustrates two envisioned usage modes: targeted an	</dt>
	d location-based emergency	<dd>Presence Information Data Format Location Object, a data structure for
		carrying location <xref target="RFC4119"/>
		</dd>

		<dt>LoST:
		</dt>
		<dd>Location To Service Translation protocol <xref target="RFC5222"/>
		</dd>

		<dt>CID:
		</dt>
		<dd>Content-ID <xref target="RFC2392"/>
		</dd>

		<dt>CAP:
		</dt>
		<dd>Common Alerting Protocol <xref target="CAP"/>
		</dd>

		<dt>PSAP:
		</dt>
		<dd>Public Safety Answering Point, the call center for emergency calls
		</dd>

		<dt>ESRP:
		</dt>
		<dd>Emergency Services Routing Proxy, a type of SIP Proxy Server used in some
		emergency services networks
		</dd>

		</dl>

		</section>

		<section anchor="arch" numbered="true" toc="default">
		<name>Architectural Overview</name>
		<t>This section illustrates two envisioned usage modes: targeted and locat
		ion-based emergency
	alert routing.</t>	alert routing.</t>

	<t><list style="numbers">	<ol spacing="normal" type="1">
	<t>Emergency alerts containing only data are targeted to an	<li>
	intermediary recipient responsible for evaluating the next steps. These s	<t>Emergency alerts containing only data are targeted to an
	teps	intermediary recipient responsible for evaluating the next steps.
	could include:	These steps could include:
	<list style="numbers">	</t>
	<t>Sending a non-interactive call containing only data towards a Public	<ol spacing="normal" type="a">
		<li>Sending a non-interactive call containing only data towards a Pu
		blic
	Safety Answering Point (PSAP);	Safety Answering Point (PSAP);

	</t>	</li>
	<t>Establishing a third-party-initiated emergency call towards a PSAP t	<li>Establishing a third-party-initiated emergency call towards a PS
	hat could	AP that could
	include audio, video, and data.	include audio, video, and data.

	</t>	</li>
	</list>	</ol>
	</t>	</li>
	<t>Emergency alerts may be targeted to a Service URN <xref target="RFC5031"/>	<li>Emergency alerts may be targeted to a service URN <xref
	used for IP-based	target="RFC5031" format="default"/> used for IP-based emergency calls
	emergency calls where the recipient is not known to	where the recipient is not known to the originator. In this scenario,
	the originator. In this scenario, the alert may contain	the alert may contain only data (e.g., a SIP MESSAGE with CAP content,
	only data (e.g., a CAP, Geolocation header field and one or more Call-Inf	a Geolocation header field, and one or more Call-Info header fields
	o header fields	containing additional data <xref target="RFC7852" format="default"/>).
	containing Additional Data <xref target="RFC7852"/> in a SIP MESSAGE).	</li>
	</t>	</ol>
	</list>	<t>
	</t>	<xref target="targeted" format="default"/> shows a deployment variant where a se
	<t>	nsor
	<xref target="targeted"/> shows a deployment variant where a sensor
	is pre-configured (using techniques outside the	is pre-configured (using techniques outside the
	scope of this document) to issue an alert to an aggregator	scope of this document) to issue an alert to an aggregator
	that processes these messages and performs whatever steps are necessary to appropriately	that processes these messages and performs whatever steps are necessary to appropriately
	react to the alert. For example, a security firm may use different sensor inputs to	react to the alert. For example, a security firm may use different sensor inputs to
	dispatch their security staff to a building they protect or to initiate a third-party emergency call.</t>	dispatch their security staff to a building they protect or to initiate a third-party emergency call.</t>

		<figure anchor="targeted">
	<t>	<name>Targeted Emergency Alert Routing</name>
	<figure anchor="targeted" title="Targeted Emergency Alert Routing">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork xml:space="preserve">
	<![CDATA[
	+------------+ +------------+	+------------+ +------------+
	\| Sensor \| \| Aggregator \|	\| Sensor \| \| Aggregator \|
	\| \| \| \|	\| \| \| \|
	+---+--------+ +------+-----+	+---+--------+ +------+-----+
	\| \|	\| \|
	Sensors \|	Sensors \|
	trigger \|	trigger \|
	emergency \|	emergency \|
	alert \|	alert \|
	\| SIP MESSAGE with CAP \|	\| SIP MESSAGE with CAP \|

	skipping to change at line 217 ¶	skipping to change at line 256 ¶
	\| Aggregator	\| Aggregator
	\| processes	\| processes
	\| emergency	\| emergency
	\| alert	\| alert
	\| SIP 200 (OK) \|	\| SIP 200 (OK) \|
	\|<-----------------------------\|	\|<-----------------------------\|
	\| \|	\| \|
	\| \|	\| \|
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	</t>
	<t>	<t>

	In <xref target="location"/> a scenario is shown whereby the alert is ro	In <xref target="location" format="default"/>, a scenario is shown
	uted	where the alert is routed using location information and a service
	using location information and a Service URN. An emergency services rout	URN. An emergency services routing proxy (ESRP) may use LoST (a
	ing	protocol defined by <xref target="RFC5222" format="default"/>, which
	proxy (ESRP) may use LoST (a protocol defined by <xref target="RFC5222"/	translates a location to a URI used to route an emergency call) to
	> which translates a location	determine the next-hop proxy to route the alert message to. A possible
	to a URI used to route an emergency call) to determine the next-hop prox	receiver is a PSAP, and the recipient of the alert may be a call
	y to route the alert	taker. In the generic case, there is very likely no prior relationship
	message to. A possible receiver is a PSAP and the recipient of the alert	between the originator and the receiver, e.g., a PSAP. For example, a
	may be a call taker. In the generic case, there is very likely no prior	PSAP is likely to receive and accept alerts from entities it has no
	relationship between	previous relationship with. This scenario is similar to a classic
	the originator and the receiver, e.g., a PSAP. For example, a PSAP is li	voice emergency services call, and the description in <xref
	kely to receive and	target="RFC6881" format="default"/> is applicable. In this use case,
	accept alerts from entities it has no previous relationship with. This s	the only difference between an emergency call and an emergency
	cenario is similar to a	non-interactive call is that the former uses INVITE, creates a
	classic voice emergency services call and the description in	session, and negotiates one or more media streams, while the latter
	<xref target="RFC6881"/> is applicable. In this use case, the only diff	uses MESSAGE, does not create a session, and does not have interactive
	erence between an emergency call and an emergency non-interactive call is that t	media.
	he former uses INVITE, creates a session, and negotiates one or more media strea
	ms, while the latter uses MESSAGE, does not create a session, and does not have
	interactive media.
	</t>	</t>

	<t>	<figure anchor="location">
	<figure anchor="location" title="Location-Based Emergency Alert Routing">	<name>Location-Based Emergency Alert Routing</name>
	<artwork xml:space="preserve">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<![CDATA[
	+----------+ +----------+ +-----------+	+----------+ +----------+ +-----------+
	\|Sensor or \| \| ESRP \| \| PSAP \|	\|Sensor or \| \| ESRP \| \| PSAP \|
	\|Aggregator\| \| \| \| \|	\|Aggregator\| \| \| \| \|
	+----+-----+ +---+------+ +----+------+	+----+-----+ +---+------+ +----+------+
	\| \| \|	\| \| \|
	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) \|
	\| \|----------------------------->\|	\| \|----------------------------->\|
	\| \| \|	\| \| \|

	skipping to change at line 270 ¶	skipping to change at line 315 ¶
	\| \| alert	\| \| alert
	\| \| SIP 200 (OK) \|	\| \| SIP 200 (OK) \|
	\| \|<-----------------------------\|	\| \|<-----------------------------\|
	\| \| \|	\| \| \|
	\| SIP 200 (OK) \| \|	\| SIP 200 (OK) \| \|
	\|<------------------\| \|	\|<------------------\| \|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	</t>
	</section>	</section>


	<!-- ///////////////////////////////////////////////////////////////////////	<section numbered="true" toc="default">
	/////////// -->	<name>Protocol Specification</name>
		<section numbered="true" toc="default">
	<section title="Protocol Specification">	<name>CAP Transport</name>
		<t>This document addresses sending a CAP alert in a SIP MESSAGE
	<section title="CAP Transport">	transaction for a non-interactive emergency call. Behavior
		with other transactions is not defined.</t>
	<t>A CAP message is sent in the initial message of any SIP transaction.	<t>The CAP alert is included in a SIP message as an additional data
	However, this document only addresses sending a CAP message in a SIP MESSAGE tr	block <xref target="RFC7852" format="default"/>. Accordingly, it is
	ansaction for a one-shot, non-interactive emergency call. Behavior with other t	conveyed in the SIP message with a Call-Info header field with a
	ransactions is not defined.</t>	purpose of "EmergencyCallData.cap". The header field may contain a
		URI that is used by the recipient (or in some cases, an intermediary)
	<t>The CAP message is included in a SIP message as an additional-data block <xre	to obtain the CAP alert. Alternatively, the Call-Info header field
	f target="RFC7852"/>. Accordingly, it is introduced to the SIP message with a C	may contain a Content-ID URL <xref target="RFC2392" format="default"/>
	all-Info header field with a purpose of "EmergencyCallData.cap".	and the CAP alert included in the body of the message. In the
	The header field may contain a URI that is used by the recipient (or in some cas	latter case, the CAP alert is located in a MIME block of the type
	es, an intermediary) to obtain the CAP message. Alternatively, the Call-Info he	'application/emergencyCallData.cap+xml'.</t>
	ader field may contain a Content-ID url <xref target="RFC2392"/> and the CAP mes	<t>If the SIP server does not support the functionality required to
	sage included in the body of the message. In the latter case, the CAP message i	fulfill the request, then a 501 Not Implemented will be returned as
	s located in a MIME block of the type 'application/emergencyCallData.cap+xml'.</	specified in <xref target="RFC3261" format="default"/>. This is the
	t>	appropriate response when a User Agent Server (UAS) does not recognize
	<t>If the SIP server does not support the functionality required to fulf	the request method and is not capable of supporting it for any
	ill the	user.</t>
	request then a 501 Not Implemented will be returned as specified in <xref tar	<t>The 415 Unsupported Media Type error will be returned as specified in
	get="RFC3261"/>. This is the appropriate response when a User Agent Server (UAS)	<xref target="RFC3261" format="default"/>
	does not
	recognize the request method and is not capable of supporting it for
	any user.</t>

	<t>The 415 Unsupported Media Type error will be returned as specified in
	<xref target="RFC3261"/>
	if the SIP server is refusing to service the request because the message	if the SIP server is refusing to service the request because the message
	body of the request is in a format not supported by the server for	body of the request is in a format not supported by the server for

	the requested method. The server MUST return a list of acceptable	the requested method. The server <bcp14>MUST</bcp14> return a list of accept able
	formats using the Accept, Accept-Encoding, or Accept-Language header	formats using the Accept, Accept-Encoding, or Accept-Language header
	fields, depending on the specific problem with the content.</t>	fields, depending on the specific problem with the content.</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Profiling of the CAP Document Content">	<name>Profiling of the CAP Document Content</name>
	<t>The usage of CAP MUST conform to the specification provided with <xre	<t>The usage of CAP <bcp14>MUST</bcp14> conform to the specification
	f target="cap"/>.	provided with <xref target="CAP" format="default"/>. For usage with
	For usage with SIP the following additional requirements are imposed (	SIP, the following additional requirements are imposed (where "sender"
	where "sender" and "author" are as defined in CAP and "Originator" is the entity	and "author" are as defined in CAP and "originator" is the entity
	sending the alert): </t>	sending the CAP alert, which may be different from the entity sending
	<t><list	the SIP MESSAGE): </t>
	style="hanging">	<dl newline="false" spacing="normal">
	<t hangText="sender:">The following restrictions and conditions apply	<dt>sender:</dt>
	to setting the value of the <sender> element:	<dd>
	<list style="symbols">	<t>The following restrictions and conditions apply to setting the va
	<t>	lue of the <sender> element:
	Originator is a SIP entity, Author indication irrelevant: When th	</t>
	e alert was created by a	<ul spacing="normal">
	SIP-based originator and it is not useful to be explicit about th	<li>
	e author of the alert,	Originator is a SIP entity, Author indication irrelevant: When
	then the <sender> element	the alert was created by a SIP-based originator and it is not
	MUST be populated with the SIP URI of the user agent.	useful to be explicit about the author of the alert, then the
	</t>	<sender> element <bcp14>MUST</bcp14> be populated with
	<t>
	Originator is a non-SIP entity, Author indication irrelevant:
	When the alert was created by a non-SIP based
	entity and the identity of this original sender is to be preserve
	d, then this identity MUST be
	placed into the <sender> element. In this situation it is n
	ot useful to be explicit about
	the author of the alert. The specific type of identity being used
	will depend on the technology
	used by the original originator.
	</t>
	<t>
	Author indication relevant: When the author is different from the
	actual originator of the
	message and this distinction should be preserved, then the <se
	nder> element MUST NOT contain
	the SIP URI of the user agent.	the SIP URI of the user agent.

	</t>	</li>
	</list></t>	<li>
		Originator is a non-SIP entity, Author indication irrelevant:
		When the alert was created by a non-SIP-based entity and the
		identity of this original sender is to be preserved, then this
		identity <bcp14>MUST</bcp14> be placed into the <sender>
		element. In this situation, it is not useful to be explicit
		about the author of the alert. The specific type of identity
		being used will depend on the technology used by the
		originator.
		</li>
		<li>
		Author indication relevant: When the author is different from
		the originator of the message and this distinction
		should be preserved, then the <sender> element
		<bcp14>MUST NOT</bcp14> contain the SIP URI of the user agent.
		</li>
		</ul>
		</dd>
		<dt>incidents:</dt>
		<dd>
		<t> The <incidents> element <bcp14>MUST</bcp14> be present.
		This incident identifier <bcp14>MUST</bcp14> be chosen in such a
		way that it is unique for a given <sender, expires,
		incidents> combination. Note that the <expires> element
		is <bcp14>OPTIONAL</bcp14> and might not be present.</t>


	<t hangText="incidents:"> The <incidents> element MUST be presen	</dd>
	t. This	<dt>scope:</dt>
	incident identifier MUST be chosen in such a way that it is unique	<dd>
	for a given	<t>The value of the <scope> element <bcp14>MAY</bcp14> be
	<sender, expires, incidents> combination. Note that the <e	set to "Private" if the alert is not meant for public consumption.
	xpires> element	The <addresses> element is, however, not used by this
	is OPTIONAL and might not be present.<vspace blankLines="1"/></t>	specification since the message routing is performed by SIP and
	<t hangText="scope:">The value of the <scope> element MAY be s	the respective address information is already available in other
	et to	SIP header fields. Populating information twice into different
	"Private" if the alert is not meant for public consumption.	parts of the message may lead to inconsistency. </t>
	The <addresses> element is, however, not used by this specif	</dd>
	ication since the	<dt>parameter:</dt>
	message routing is performed by SIP and the respective address inf	<dd>
	ormation is already	The <parameter> element <bcp14>MAY</bcp14> contain
	available in other SIP header fields. Populating information twice	additional information specific to the sender, conforming to the
	into different parts of	CAP alert syntax.
	the message may lead to inconsistency. <vspace blankLines="1"/> </	</dd>
	t>	<dt>area:</dt>
	<t hangText="parameter:">The <parameter> element MAY contain a	<dd>It is <bcp14>RECOMMENDED</bcp14> to omit this element when
	dditional	constructing a message. If the CAP alert is given to the SIP
	information specific to the sender, conforming to the CAP message	entity to transport and it already contains an <area> element,
	syntax. <vspace blankLines="1"/></t>	then the specified location information <bcp14>SHOULD</bcp14> be
	<t hangText="area:">It is RECOMMENDED to omit this element when cons	copied into a PIDF-LO structure (the data format for location used
	tructing a message.	by emergency calls on the Internet) referenced by the SIP
	If the CAP message is given to the SIP entity to transport and it al	'Geolocation' header field. If the CAP alert is being created by
	ready contains an <area> element, then the specified	the SIP entity using a PIDF-LO structure referenced by 'geolocation'
	location information SHOULD be copied into a PIDF-LO structure (the	to construct <area>, implementers must be aware that
	data format for location used by emergency calls on the Internet) referenced by	<area> is limited to a circle or polygon, and conversion of
	the SIP 'Geolocation' header field. If the CAP message is being created by the	other shapes will be required. Points <bcp14>SHOULD</bcp14> be
	SIP entity using a PIDF-LO structure referenced by 'geolocation' to construct &l	converted to a circle with a radius equal to the uncertainty of the
	t;area>, implementers must be aware that <area> is limited to a circle	point. Arc-bands and ellipses <bcp14>SHOULD</bcp14> be converted
	or polygon, and conversion of other shapes will be required. Points SHOULD be c	to polygons with similar coverage, and 3D locations
	onverted to a circle with a radius equal to the uncertainty of the point. Arc-	<bcp14>SHOULD</bcp14> be converted to 2D forms with similar
	bands and ellipses SHOULD be converted to polygons with similar	coverage.
	coverage, and 3D locations SHOULD be converted to 2D forms with	</dd>
	similar coverage.	</dl>
	</t>	</section>
	</list></t>	<section numbered="true" toc="default">
		<name>Sending a Non-interactive Emergency Call</name>
		<t>A non-interactive emergency call is sent using a SIP MESSAGE
		transaction with a CAP URI or body part as described above in a manner
		similar to how an emergency call with interactive media is sent, as
		described in <xref target="RFC6881" format="default"/>. The MESSAGE
		transaction does not create a session nor establish interactive media
		streams, but otherwise, the header content of the transaction,
		routing, and processing of non-interactive calls are the same as those
		of other emergency calls.</t>
	</section>	</section>

	<section title="Sending a non-interactive Emergency Call">
	<t>A non-interactive emergency call is sent using a SIP MESSAGE transaction
	with a CAP URI or body part as described above in a manner similar to how an em
	ergency call with interactive media is sent, as described in <xref target="RFC68
	81"/>. The MESSAGE transaction does not create a session nor establish interact
	ive media streams, but otherwise, the header content of the transaction, routing
	, and processing of non-interactive calls are the same as those of other emergen
	cy calls.</t>
	</section>
	</section>	</section>


	<!-- ///////////////////////////////////////////////////////////////////////	<section anchor="error" numbered="true" toc="default">
	/////////// -->	<name>Error Handling</name>
		<t>This section defines a new error response code and a header field for
	<section anchor="error" title="Error Handling">	additional information.</t>
		<section numbered="true" toc="default">
	<t>This section defines a new error response code and a header field for additio	<name>425 (Bad Alert Message) Response Code</name>
	nal information.</t>	<t>This SIP extension creates a new response code
		defined as follows:
	<section title="425 (Bad Alert Message) Response Code">	</t>
		<ul empty="true" spacing="normal">
	<t>This SIP extension creates a new location-specific response code,	<li>425 (Bad Alert Message)</li>
	defined as follows:	</ul>
	<list style="empty">	<t>The 425 response code is a rejection of the request, indicating
	<t>425 (Bad Alert Message)</t>	that it was malformed enough that no reasonable emergency response to
	</list>	the alert can be determined.</t>
	</t>

	<t>The 425 response code is a rejection of
	the request, indicating that it was malformed enough that no reasonable emerg
	ency response to the alert can be determined.</t>

	<t>A SIP intermediary can also this code to reject an alert it receives from a
	User Agent (UA) when it detects that the provided alert is malformed.</t>

	<t><xref target="error-header"/> describes an AlertMsg-Error header field with
	more details about what was wrong with the alert message in
	the request. This header field MUST be included in the 425 response.</t>

	<t>It is usually the case that emergency calls are not rejected if there is any
	useful information that can be acted upon. 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 responder.</t>

	<t>A 425 response code MUST NOT be sent in response to a request that lacks an a
	lert message, as the user agent in that case may not
	support this extension. </t>

	<t>A 425 response is a final response within
	a transaction, and MUST NOT terminate an existing dialog.</t>
	</section>

	<section anchor="error-header" title="The AlertMsg-Error Header Field">


	<t>The AlertMsg-Error header field provides additional information about what wa	<t>A SIP intermediary can also use this code to reject an alert it
	s wrong with the original request. In some cases the provided information will b	receives from a User Agent (UA) when it detects that the provided
	e used for debugging purposes.</t>	alert is malformed.</t>
		<t>


	<t>The AlertMsg-Error	<xref target="error-header" format="default"/> describes an
	header field has the following ABNF <xref target="RFC5234"/>:</t>	AlertMsg-Error header field with more details about what was wrong
		with the alert message in the request. This header field
		<bcp14>MUST</bcp14> be included in the 425 response.</t>
		<t>It is usually the case that emergency calls are not rejected if
		there is any useful information that can be acted upon. 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
		responder.</t>
		<t>A 425 response code <bcp14>MUST NOT</bcp14> be sent in response to
		a request that lacks an alert message (i.e., CAP data), as the user agen
		t in that case
		may not support this extension. </t>
		<t>A 425 response is a final response within
		a transaction and <bcp14>MUST NOT</bcp14> terminate an existing dialog.</t>
		</section>
		<section anchor="error-header" numbered="true" toc="default">
		<name>The AlertMsg-Error Header Field</name>
		<t>The AlertMsg-Error header field provides additional information
		about what was wrong with the original request. In some cases, the
		provided information will be used for debugging purposes.</t>
		<t>The AlertMsg-Error header field has the following ABNF <xref
		target="RFC5234" format="default"/>:</t>


	<t>	<sourcecode type="abnf">
	<figure>
	<artwork>
	<![CDATA[
	message-header =/ AlertMsg-Error	message-header =/ AlertMsg-Error

	; (message-header from RFC3261)	; (message-header from RFC 3261)
	AlertMsg-Error = "AlertMsg-Error" HCOLON	AlertMsg-Error = "AlertMsg-Error" HCOLON
	ErrorValue	ErrorValue
	ErrorValue = error-code	ErrorValue = error-code
	*(SEMI error-params)	*(SEMI error-params)
	error-code = 3DIGIT	error-code = 3DIGIT
	error-params = error-code-text	error-params = error-code-text

	/ generic-param ; from RFC3261	/ generic-param ; from RFC 3261
	error-code-text = "message" EQUAL quoted-string ; from RFC3261	error-code-text = "message" EQUAL quoted-string ; from RFC 3261
	]]></artwork>	</sourcecode>
	</figure>
	</t>

	<t>HCOLON, SEMI, and EQUAL are defined in <xref target="RFC3261"/>. DIGIT is
	defined in <xref target="RFC5234"/>.</t>


	<t>The AlertMsg-Error header field MUST contain only one	<t>HCOLON, SEMI, and EQUAL are defined in <xref target="RFC3261"
		format="default"/>. DIGIT is defined in <xref target="RFC5234"
		format="default"/>.</t>
		<t>The AlertMsg-Error header field <bcp14>MUST</bcp14> contain only one
	ErrorValue to indicate what was wrong with the alert payload	ErrorValue to indicate what was wrong with the alert payload
	the recipient determined was bad.</t>	the recipient determined was bad.</t>

		<t>
	<t>
	The ErrorValue	The ErrorValue
	contains a 3-digit error code indicating what was wrong with the	contains a 3-digit error code indicating what was wrong with the
	alert in the request. This error code has a corresponding quoted	alert in the request. This error code has a corresponding quoted
	error text string that is human readable. The text string is	error text string that is human readable. The text string is

	OPTIONAL, but RECOMMENDED for human readability, similar to the	<bcp14>OPTIONAL</bcp14>, but <bcp14>RECOMMENDED</bcp14> for human readability , similar to the
	string phrase used for SIP response codes. 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 MUST	standardized -- meaning an operator can change the strings but <bcp14>MUST
	NOT change the meaning of the error code.	NOT</bcp14> change the meaning of the error code.
	The code space for ErrorValue is separate from SIP Status Codes.	The code space for ErrorValue is separate from SIP Status Codes.

	</t>	</t>
	<t>	<t>
	The AlertMsg-Error header field MAY be included in any response	The AlertMsg-Error header field <bcp14>MAY</bcp14> be included in any respons
		e
	if an alert message was in the request part of the same transaction.	if an alert message was in the request part of the same transaction.
	For	For
	example, suppose a UA includes an alert in a MESSAGE to a PSAP. The PSAP can	example, suppose a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
	accept this MESSAGE, even though its UA	accept this MESSAGE, 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	The PSAP merely
	includes an AlertMsg-Error header field value in the 200 OK to the	includes an AlertMsg-Error header field value in the 200 OK to the
	MESSAGE, thus informing the UA that the MESSAGE was accepted but the alert	MESSAGE, thus informing the UA that the MESSAGE was accepted but the alert
	provided was bad.</t>	provided was bad.</t>

		<t>If, on the other hand, the PSAP cannot accept the transaction without
	<t>If, on the other hand, the PSAP cannot accept the transaction without a	a
	suitable alert message, a 425 response is sent.</t>	suitable alert message, a 425 response is sent.</t>

		<t>A SIP intermediary that requires the UA's alert message in order to
	<t>A SIP intermediary that requires the UA's alert message in order to	properly process the transaction may also send a 425 response with an
	properly process the transaction may also send a 425 with an	AlertMsg-Error code.</t>
	AlertMsg-Error code.</t>	<t>This document defines an initial list of AlertMsg-Error values for
		any SIP response, including provisional responses (other than 100
	<t>This document defines an initial list of AlertMsg-Error values for any	Trying) and the new 425 response. There <bcp14>MUST NOT</bcp14> be
	SIP response, including provisional responses (other than 100	more than one AlertMsg-Error code in a SIP response. AlertMsg-Error
	Trying) and the new 425 response. There MUST NOT be more than	values sent in provisional responses <bcp14>MUST</bcp14> be sent using
	one AlertMsg-Error code in a SIP response. AlertMsg-Error	the mechanism defined in <xref target="RFC3262" format="default"/>; or,
	values sent in provisional responses MUST be sent using the mechanism	if that mechanism is not negotiated, they <bcp14>MUST</bcp14> be repeate
	defined in <xref target="RFC3262"/>; or, if that mechanism is not negotiated, MU	d
	ST be	in the final response to the transaction.
	repeated in the final response to the transaction.
	</t>	</t>


	<t>AlertMsg-Error: 100 ; message="Cannot Process the Alert Payload"</t>	<sourcecode>
		AlertMsg-Error: 100 ; message="Cannot process the alert payload"


	<t>AlertMsg-Error: 101 ; message="Alert Payload was not present or could not be	AlertMsg-Error: 101 ; message="Alert payload was not present or could
	found"</t>	not be found"


	<t>AlertMsg-Error: 102 ; message="Not enough information to determine	AlertMsg-Error: 102 ; message="Not enough information to determine
	the purpose of the alert"</t>	the purpose of the alert"


	<t>AlertMsg-Error: 103 ; message="Alert Payload was corrupted"</t>	AlertMsg-Error: 103 ; message="Alert payload was corrupted"
		</sourcecode>


	<t>Additionally, if an entity cannot or chooses not to process the alert message	<t>Additionally, if an entity cannot or chooses not to process the alert
	from a SIP request, a 500 (Server Internal Error) SHOULD be used	message
		from a SIP request, a 500 (Server Internal Error) <bcp14>SHOULD</bcp14> be us
		ed
	with or without a configurable Retry-After header field.</t>	with or without a configurable Retry-After header field.</t>

		</section>
		</section>


	</section>	<section anchor="callbacks" numbered="true" toc="default">
		<name>Call Backs</name>
	</section>	<t>This document does not describe any method for the recipient to call ba
	<!-- ///////////////////////////////////////////////////////////////////////	ck the sender of a non-interactive call. Usually, these alerts are sent by auto
	/////////// -->	mata, which do not have a mechanism to receive calls of any kind. The identifie
		r in the 'From' header field may be useful to obtain more information, but any s
	<section anchor="callbacks" title="Call Backs">	uch mechanism is not defined in this document. The CAP alert may contain relate
	<t>This document does not describe any method for the recipient to call back the	d contact information for the sender.</t>
	sender of a non-interactive call. Usually, these alerts are sent by automata,	</section>
	which do not have a mechanism to receive calls of any kind. The identifier in t	<section anchor="largedata" numbered="true" toc="default">
	he 'From' header field may be useful to obtain more information, but any such me	<name>Handling Large Amounts of Data</name>
	chanism is not defined in this document. The CAP message may contain related co	<t>Sensors may have large quantities of data that
	ntact information for the sender.</t>	they may wish to send. Including large amounts of data (tens of
	</section>	kilobytes) in a MESSAGE is not advisable because SIP entities are
		usually not equipped to handle very large messages. In such cases, the
	<section anchor="largedata" title="Handling Large Amounts of Data">	sender <bcp14>SHOULD</bcp14> make use of the by-reference mechanisms
	<t>It is not atypical for sensors to have large quantities of data that they may	defined in <xref target="RFC7852" format="default"/>, which involves
	wish	making the data available via HTTPS <xref target="RFC2818"
	to send. Including large amounts of data (tens of kilobytes) in a MESSAGE is no	format="default"/> (either at the originator or at another entity),
	t advisable,	placing a URI to the data in the 'Call-Info' header field, and the
	because SIP entities are usually not equipped to handle very large messages.	recipient uses HTTPS to retrieve the data. The CAP alert itself can
	In such cases, the sender SHOULD make use of the by-reference mechanisms defined	be sent by reference using this mechanism, as can any or all of the
	in <xref target="RFC7852"/>, which involves making the data available via HTTPS	additional data blocks that may contain sensor-specific data.</t>
	<xref target="RFC2818"/> (either at the originator or at another entity), placin	<t>There are no rate-limiting mechanisms for any SIP transactions that
	g a URI to the data in the 'Call-Info' header field, and the recipient uses	are standardized, although implementations often include such functions.
	HTTPS to retrieve the data. The CAP message itself can be sent by reference	Non-interactive emergency calls are typically handled the same as any
	using this mechanism, as can any or all of the Additional Data	emergency call, which means a human call-taker is involved. Implementatio
	blocks that may contain sensor-specific data.</t>	ns should take note of this limitation, especially when calls are placed automat
		ically without human initiation.</t>
	<t>There are no rate limiting mechanisms for any SIP transactions that are stand	</section>
	ardized, although implementations often include such functions. Non-interactive
	emergency calls are typically handled the same as any emergency call, which mea
	ns a human call-taker is involved. Implementations should take note of this lim
	itation, especially when calls are placed automatically without human initiation
	.</t>
	</section>
	<!-- ///////////////////////////////////////////////////////////////////
	/////////////// -->

	<section anchor="example" title="Example">


		<section anchor="example" numbered="true" toc="default">
		<name>Example</name>
	<t>The following example shows a CAP document indicating a BURGLARY alert issued by	<t>The following example shows a CAP document indicating a BURGLARY alert issued by
	a sensor called 'sensor1@example.com'. The location of the sensor can be	a sensor called 'sensor1@example.com'. The location of the sensor can be

	obtained from the attached location information provided via the 'geoloc ation' header field	obtained from the attached location information provided via the 'Geoloc ation' header field
	contained in the SIP MESSAGE structure. Additionally, the sensor provide d some	contained in the SIP MESSAGE structure. Additionally, the sensor provide d some
	data along with the alert message, using proprietary information element s intended only to be	data along with the alert message, using proprietary information element s intended only to be
	processed by the receiver, a SIP entity acting as an aggregator.</t>	processed by the receiver, a SIP entity acting as an aggregator.</t>

	<t>
	<figure anchor="warning1" title="Example Message conveying an Alert to a	<figure anchor="warning1">
	n aggregator">	<name>Example Message Conveying an Alert to an Aggregator</name>
	<artwork>
	<![CDATA[	<sourcecode><![CDATA[
	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::ff	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
	CSeq: 1 MESSAGE	CSeq: 1 MESSAGE

	skipping to change at line 590 ¶	skipping to change at line 682 ¶
	</gbp:retransmission-allowed>	</gbp:retransmission-allowed>
	<gbp:retention-expiry>2020-02-04T20:57:29Z	<gbp:retention-expiry>2020-02-04T20:57:29Z
	</gbp:retention-expiry>	</gbp:retention-expiry>
	</gp:usage-rules>	</gp:usage-rules>
	<gp:method>802.11</gp:method>	<gp:method>802.11</gp:method>
	</gp:geopriv>	</gp:geopriv>
	<dm:timestamp>2020-01-04T20:57:29Z</dm:timestamp>	<dm:timestamp>2020-01-04T20:57:29Z</dm:timestamp>
	</dm:device>	</dm:device>
	</presence>	</presence>
	--boundary1--	--boundary1--

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	</t>
	<t>The following shows the same CAP document sent as a non-interactive eme rgency call towards a PSAP.</t>	<t>The following shows the same CAP document sent as a non-interactive eme rgency call towards a PSAP.</t>

	<t>	<figure anchor="warning2">
	<figure anchor="warning2" title="Example Message conveying an Alert to a	<name>Example Message Conveying an Alert to a PSAP</name>
	PSAP">	<sourcecode><![CDATA[
	<artwork>
	<![CDATA[
	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
	Supported: geolocation	Supported: geolocation

	skipping to change at line 680 ¶	skipping to change at line 770 ¶
	</gbp:retransmission-allowed>	</gbp:retransmission-allowed>
	<gbp:retention-expiry>2020-02-04T20:57:25Z	<gbp:retention-expiry>2020-02-04T20:57:25Z
	</gbp:retention-expiry>	</gbp:retention-expiry>
	</gp:usage-rules>	</gp:usage-rules>
	<gp:method>802.11</gp:method>	<gp:method>802.11</gp:method>
	</gp:geopriv>	</gp:geopriv>
	<dm:timestamp>2020-01-04T20:57:25Z</dm:timestamp>	<dm:timestamp>2020-01-04T20:57:25Z</dm:timestamp>
	</dm:device>	</dm:device>
	</presence>	</presence>
	--boundary1--	--boundary1--

	]]></artwork>	]]>
	</figure>	</sourcecode>
	</t>	</figure>
	</section>	</section>

	<!-- ///////////////////////////////////////////////////////////////////////
	/////////// -->


	<section anchor="sec-cons" title="Security Considerations">	<section anchor="sec-cons" numbered="true" toc="default">
		<name>Security Considerations</name>
	<t> This section discusses security considerations when SIP user agents is sue emergency	<t> This section discusses security considerations when SIP user agents is sue emergency
	alerts utilizing MESSAGE and CAP. Location-specific threats are not uniq ue to this document and are	alerts utilizing MESSAGE and CAP. Location-specific threats are not uniq ue to this document and are

	discussed in <xref target="RFC7378"/> and <xref target="RFC6442"/>.</t>	discussed in <xref target="RFC7378" format="default"/> and <xref
		target="RFC6442" format="default"/>.</t>


	<t>The ECRIT emergency services architecture <xref target="RFC6443"/> co	<t>The Emergency Context Resolution with Internet Technologies (ECRIT)
	nsiders classic individual-to-authority emergency calling where the identity of	emergency services architecture <xref target="RFC6443"
	the emergency caller does not play a role at the time of the call establishment	format="default"/> considers classic individual-to-authority emergency
	itself, i.e., a response to the emergency call does not depend on the identity o	calling where the identity of the emergency caller does not play a role
	f the caller. In the case of emergency alerts generated by devices such as senso	at the time of the call establishment itself, i.e., a response to the
	rs, the processing may be different in order to reduce the number of falsely gen	emergency call does not depend on the identity of the caller. In the
	erated emergency alerts. Alerts could get triggered based on certain sensor inpu	case of emergency alerts generated by devices such as sensors, the
	t that might have been caused by factors other than the actual occurrence of an	processing may be different in order to reduce the number of falsely
	alert-relevant event. For example, a sensor may simply be malfunctioning. For th	generated emergency alerts. Alerts could get triggered based on certain
	is reason, not all alert messages are directly sent to a PSAP, but rather may be	sensor input that might have been caused by factors other than the
	pre-processed by a separate entity, potentially under supervision by a human, t	actual occurrence of an alert-relevant event. For example, a sensor may
	o filter alerts and potentially correlate received alerts with others to obtain	simply be malfunctioning. For this reason, not all alert messages are
	a larger picture of the ongoing situation. </t>	directly sent to a PSAP, but rather, may be pre-processed by a separate
		entity, potentially under supervision by a human, to filter alerts and
		potentially correlate received alerts with others to obtain a larger
		picture of the ongoing situation. </t>
		<t>In any case, for alerts initiated by sensors, the identity could play
		an important role in deciding whether to accept or ignore an incoming
		alert message. With the scenario shown in <xref target="targeted"
		format="default"/>, it is very likely that only authenticated sensor
		input will be processed. For this reason, it needs to be possible to
		refuse to accept alert messages from unknown origins. Two types of
		information elements can be used for this purpose:
		</t>
		<ol spacing="normal" type="1">
		<li>SIP itself provides security mechanisms that allow the verification
		of the originator's identity, such as P-Asserted-Identity <xref target="RFC3325"
		format="default"/> or SIP Identity <xref target="RFC8224" format="default"/>. T
		he latter provides a cryptographic assurance while the former relies on a chain-
		of-trust model. These mechanisms can be reused.</li>
		<li>CAP provides additional security mechanisms and the ability to carry
		further information about the sender's identity. Section 3.3.4.1 of <xref targe
		t="CAP" format="default"/> specifies the signing algorithms of CAP
		documents.</li>
		</ol>
		<t>The specific policy and mechanisms used in a given deployment are out
		of scope for this document.</t>
		<t>There is no rate limiting mechanisms in SIP, and all kinds of
		emergency calls, including those defined in this document, could be used
		by malicious actors or misbehaving devices to effect a denial-of-service
		attack on the emergency services. The mechanism defined in this
		document does not introduce any new considerations, although it may be
		more likely that devices that place non-interactive emergency calls
		without a human initiating them may be more likely than those that
		require a user to initiate them.</t>
		<t>Implementors should note that automated emergency calls may be prohibit
		ed or regulated in some jurisdictions, and there may be penalties for "false pos
		itive" calls.</t>
		<t>This document describes potential retrieval of information by
		dereferencing URIs found in a Call Info header of a SIP MESSAGE. These
		may include a CAP alert as well as other additional data <xref
		target="RFC7852"/> blocks. The domain of the device sending the SIP
		MESSAGE; the domain of the server holding the CAP alert, if sent by
		reference; and the domain of other additional data blocks, if sent by
		reference, may all be different. No assumptions can be made that there
		are trust relationships between these entities. Recipients
		<bcp14>MUST</bcp14> take precautions in retrieving any additional data
		blocks passed by reference, including the CAP alert, because the URI
		may point to a malicious actor or entity not expecting to be referred to
		for this purpose. The considerations in handling URIs in <xref
		target="RFC3986" format="default"/> apply.</t>
		<t>Use of timestamps to prevent replay is subject to the availability of
		accurate time at all participants. Because emergency event notification
		via this mechanism is relatively low frequency and generally involves
		human interaction, implementations may wish to consider messages with
		times within a small number of seconds of each other to be effectively
		simultaneous for the purposes of detecting replay. Implementations may
		also wish to consider that most deployed time distribution protocols
		likely to be used by these systems are not presently secure.</t>
		<t>In addition to the desire to perform identity-based access control,
		the classic communication security threats need to be considered,
		including integrity protection to prevent forgery or replay of alert
		messages in transit. To deal with replay of alerts, a CAP document
		contains the mandatory <identifier>, <sender>, and
		<sent> elements and an optional <expire> element. Together,
		these elements make the CAP document unique for a specific sender and
		provide time restrictions. An entity that has already received a CAP
		alert within the indicated timeframe is able to detect a replayed
		message and, if the content of that message is unchanged, then no
		additional security vulnerability is created. Additionally, it is
		<bcp14>RECOMMENDED</bcp14> to make use of SIP security mechanisms, such
		as the SIP Identity PASSporT <xref target="RFC8225" format="default"/>,
		to tie the CAP alert to the SIP message. To provide protection of the
		entire SIP message exchange between neighboring SIP entities, the usage
		of TLS is <bcp14>RECOMMENDED</bcp14>. <xref target="RFC6443"
		format="default"/> discusses the issues of using TLS with emergency
		calls, which are equally applicable to non-interactive emergency
		calls.</t>
		<t>Note that none of the security mechanisms in this document protect
		against a compromised sensor sending crafted alerts. Confidentiality
		provided for any emergency calls, including non-interactive messages, is
		subject to local regulations. Privacy issues are discussed in <xref
		target="RFC7852" format="default"/> and are applicable here.
		</t>
		</section>


	<t>In any case, for alerts initiated by sensors, the identity could play an impo	<section numbered="true" toc="default">
	rtant role in deciding whether to accept or ignore an incoming alert message. Wi	<name>IANA Considerations</name>
	th the scenario shown in <xref target="targeted"/> it is very likely that only a
	uthenticated sensor input will be processed. For this reason, it needs to be pos
	sible to refuse to accept alert messages from unknown origins. Two types of info
	rmation elements can be used for this purpose:
	<list style="numbers">
	<t>SIP itself provides security mechanisms that allow the verification of the or
	iginator's identity, such as P-Asserted-Identity <xref target="RFC3325"/> or SIP
	Identity <xref target="RFC8224"/>. The latter provides a cryptographic assuranc
	e while the former relies on a chain of trust model. These mechanisms can be reu
	sed.</t>
	<t>CAP provides additional security mechanisms and the ability to carry further
	information about the sender's identity. Section 3.3.4.1 of <xref target="cap"/>
	specifies the signing algorithms of CAP
	documents.</t>
	</list></t>
	<t>The specific policy and mechanisms used in a given deployment are out of scop
	e for this document.</t>
	<t>There is no rate limiting mechanisms in SIP, and all kinds of emergency calls
	, including those defined in this document could be used by malicious actors, or
	misbehaving devices to effect a denial of service attack on the emergency servi
	ces. The mechanism defined in this document does not introduce any new consider
	ations although it may be more likely that devices that place non-interactive em
	ergency calls without a human initiating them may be more likely than those that
	require a user to initiate them.</t>
	<t>Implementors should note that automated emergency calls may be prohibited or
	regulated in some jurisdictions, and there may be penalties for "false positive"
	calls.</t>
	<t>This document describes potential retrieval of information by dereferencing U
	RIs found in a Call Info header of a SIP MESSAGE. These may include a CAP messa
	ge as well as other Additional Data (RFC7852) blocks. The domain of the device
	sending the SIP MESSAGE, the domain of the server holding the CAP message, if se
	nt by reference, and the domain of other Additional Data blocks, if sent by refe
	rence, may all be different. No assumptions can be made that there are trust re
	lationships between these entities. Recipients MUST take precautions in retriev
	ing any Additional Data blocks passed by reference, including the CAP message, b
	ecause the URI may point to a malicious actor or entity not expecting to be
	referred to for this purpose. The considerations in handling URIs in <xref targ
	et="RFC3986"/> apply.</t>
	<t>Use of timestamps to prevent replay is subject to the availability of accurat
	e time at all participants. Because emergency event notification via this mecha
	nism is relatively low frequency and generally involves human interaction, imple
	mentations may wish to consider messages with times within small number of secon
	ds of each other to be effectively simultaneous for the purposes of detecting re
	play. Implementations may also wish to consider that most deployed time distrib
	ution protocols likely to be used by these systems are not presently secure.</t>
	<t>In addition to the desire to perform identity-based access control, the class
	ic communication security threats need to be considered, including integrity pro
	tection to prevent forgery or replay of alert messages in transit. To deal with
	replay of alerts, a CAP document contains the mandatory <identifier>, <
	sender>, <sent> elements and an optional <expire> element. Togeth
	er, these elements make the CAP document unique for a specific sender and provid
	e time restrictions. An entity that has already received a CAP message within th
	e indicated timeframe is able to detect a
	replayed message and, if the content of that message is unchanged,
	then no additional
	security vulnerability is created. Additionally, it is RECOMMENDED
	to make use of SIP
	security mechanisms, such as the SIP Identity PASSporT <xref targe
	t="RFC8225"/>, to tie the
	CAP message to the SIP message. To provide protection of the entir
	e SIP message exchange between neighboring SIP entities, the usage of TLS is REC
	OMMENDED. <xref target="RFC6443"/> discusses the issues of using TLS with emerg
	ency calls, which are equally applicable to non-interactive emergency calls</t>


	<t>Note that none of the security mechanisms in this document protect against a	<section numbered="true" toc="default">
	compromised sensor sending crafted alerts. Confidentiality provided for any eme	<name>'application/EmergencyCallData.cap+xml' Media Type</name>
	rgency calls, including non-interactive messages, is subject to local regulation	<dl newline="false" spacing="normal">
	s. Privacy issues are discussed in <xref target="RFC7852"/> and are applicable h	<dt>Type name:</dt>
	ere.	<dd>
	</t>	<t>application </t>


	</section>	</dd>
		<dt>Subtype name:</dt>
		<dd>
		<t>EmergencyCallData.cap+xml</t>


	<!-- ///////////////////////////////////////////////////////////////////////	</dd>
	/////////// -->	<dt>Required parameters:</dt>
		<dd>
		<t>N/A</t>


	<section title="IANA Considerations">	</dd>
	<section title="Registration of the 'application/EmergencyCallData.cap+xml	<dt>Optional parameters:</dt>
	' media type">	<dd>
	<t>	<t> charset; Indicates the character encoding of
	<list style="hanging">	enclosed XML. Default is UTF-8 <xref target="RFC3629" format="defa
	<t hangText="To:"> ietf-types@iana.org<vspace blankLines="1"/> </t>	ult"/>.</t>
	<t hangText="Subject:">Registration of media type application/
	EmergencyCallData.cap+xml<vspace blankLines="1"/></t>
	<t hangText="Type name:"> application <vspace blankLines="1"/></t>


	<t hangText="Subtype name:">cap+xml <vspace blankLines="1"/></t>	</dd>
	<t hangText="Required parameters:"> (none)<vspace blankLines="1"/> <	<dt>Encoding considerations:</dt>
	/t>	<dd>
	<t hangText="Optional parameters:"> charset; Indicates the character	<t> 7bit, 8bit, or binary. See <xref sectionFormat="of" target="RFC7
	encoding of	303" section="3.2"/>.</t>
	enclosed XML. Default is UTF-8 <xref target="RFC3629"/>.<vspace bl
	ankLines="1"/></t>


	<t hangText="Encoding considerations:"> 7bit, 8bit or binary. See <x	</dd>
	ref target="RFC7303"/>,	<dt>Security considerations:</dt>
	Section 3.2.<vspace blankLines="1"/></t>	<dd>
	<t hangText="Security considerations:"> This content type is designe	<t> This content type is designed to carry payloads of the Common
	d to carry payloads	Alerting Protocol (CAP). RFC 8876 discusses security
	of the Common Alerting Protocol (CAP). RFC XXX [Replace by the RF	considerations for this. </t>
	C number of this
	specification] discusses security considerations for this. <vspace
	blankLines="1"/></t>
	<t hangText="Interoperability considerations:"> This content type pr
	ovides a way to
	convey CAP payloads.<vspace blankLines="1"/> </t>


	<t hangText="Published specification:"> RFC XXX [Replace by the RFC	</dd>
	number of this	<dt>Interoperability considerations:</dt>
	specification]. <vspace blankLines="1"/></t>	<dd>
	<t hangText="Applications which use this media type:"> Applications	<t> This content type provides a way to
	that convey alerts	convey CAP payloads.</t>
	and warnings according to the CAP standard.<vspace blankLines="1"/
	></t>
	<t hangText="Fragment Identifier Considerations: N/A"> .<vspace blank
	Lines="1"/></t>


	<t hangText="Additional information:"> OASIS has published the Commo	</dd>
	n Alerting Protocol	<dt>Published specification:</dt>
	at http://www.oasis-open.org/committees/documents.php&wg_abbre	<dd>
	v=emergency <vspace blankLines="1"/></t>	<t> RFC 8876</t>


	<t hangText="Person and email address to contact for further informa	</dd>
	tion:"> Hannes	<dt>Applications that use this media type:</dt>
	Tschofenig, hannes.tschofenig@gmx.net <vspace blankLines="1"/></t>	<dd>
	<t hangText="Intended usage:"> Limited use <vspace blankLines="1"/><	<t> Applications that convey alerts
	/t>	and warnings according to the CAP standard.</t>
	<t hangText="Author/Change controller:"> The IESG <vspace blankLines
	="1"/></t>
	<t hangText="Other information:"> This media type is a specializatio
	n of application/xml
	<xref target="RFC7303"/>, and many of the considerations described
	there also
	apply to application/cap+xml. <vspace blankLines="1"/></t>
	</list>
	</t>
	</section>
	<section title="IANA Registration of 'cap' Additional Data Block">
	<t>This document registers a new block type in the sub-registry called 'Emergenc
	y Call Data
	Types' of the Emergency Call Additional Data Registry defined in <xref target
	="RFC7852"/>. The token is "cap", the Data About is "The Call" and the referenc
	e is this document. </t>
	</section>
	<section title="IANA Registration for 425 Response Code">


	<t>In the SIP Response Codes registry, the following is added</t>	</dd>
		<dt>Fragment identifier considerations: N/A</dt>
		<dd>


	<t>Reference: RFC-XXXX (i.e., this document)</t>	</dd>
	<t>Response code: 425 (recommended number to assign)</t>	<dt>Additional information:</dt>
	<t>Default reason phrase: Bad Alert Message</t>	<dd>
		<t> OASIS has published the Common Alerting Protocol
		at <eref
		target="https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.
		pdf"
		brackets="angle"/></t>


	<t>	</dd>
	<figure>	<dt>Person and email address to contact for further information:</dt>
	<artwork>	<dd>
	<![CDATA[	<t><br/><contact fullname="Hannes Tschofenig"/> <hannes.tschofeni
	Registry:	g@gmx.net></t>
	Response Code Reference
	------------------------------------------ ---------
	Request Failure 4xx
	425 Bad Alert Message [this doc]
	]]></artwork>
	</figure>
	</t>


	<t>This SIP Response code is defined in <xref target="error"/>.</t>	</dd>
		<dt>Intended usage:</dt>
		<dd>
		<t> Limited use </t>


	</section>	</dd>
		<dt>Author/Change controller:</dt>
		<dd>
		<t> The IESG </t>


	<section title="IANA Registration of New AlertMsg-Error Header Field">	</dd>
		<dt>Other information:</dt>
		<dd>
		<t> This media type is a specialization of 'application/xml' <xref
		target="RFC7303" format="default"/>, and many of the
		considerations described there also apply to
		application/EmergencyCallData.cap+xml.</t>


	<t>The SIP AlertMsg-error header field is created by this document,	</dd>
	with its definition and rules in <xref target="error"/>, to be	</dl>
	added to the IANA Session Initiation Protocol (SIP) Parameters registry with	</section>
	two actions:	<section numbered="true" toc="default">
		<name>'cap' Additional Data Block</name>
		<t>Per this document, IANA has registered a new block type in the
		"Emergency Call Data Types" subregistry of the "Emergency Call Additiona
		l Data"
		registry defined in <xref target="RFC7852" format="default"/>. The
		token is "cap", the Data About is "The Call", and the reference is
		this document. </t>
		</section>
		<section numbered="true" toc="default">
		<name>425 Response Code</name>
		<t>In the SIP "Response Codes" registry, the following has been added
		under Request Failure 4xx.</t>

		<table anchor="bad-alert-message">
		<name>Response Codes Registry Addition
		</name>
		<thead>
		<tr>
		<th>Response Code</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>425</td>
		<td>Bad Alert Message</td>
		<td>RFC 8876</td>
		</tr>
		</tbody>
		</table>

		<t>This SIP Response code is defined in <xref target="error" format="def
		ault"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>AlertMsg-Error Header Field</name>
		<t>The SIP AlertMsg-Error header field is created by this document,
		with its definition and rules in <xref target="error"
		format="default"/>.
		The IANA "Session Initiation Protocol (SIP) Parameters" registry
		has been updated as follows.


	<list style="numbers">
	<t>Update the Header Fields registry with
	<vspace blankLines="1"/>
	<figure>
	<artwork>
	<![CDATA[
	Registry:
	Header Name compact Reference
	----------------- ------- ---------
	AlertMsg-Error [this doc]
	]]></artwork>
	</figure>
	</t>
	<t>In the portion titled "Header Field Parameters and Parameter
	Values", add
	<vspace blankLines="1"/>
	<figure>
	<artwork>
	<![CDATA[
	Predefined
	Header Field Parameter Name Values Reference
	----------------- ------------------- ---------- ---------
	AlertMsg-Error code no [this doc]
	]]></artwork>
	</figure>
	</t>
	</list>
	</t>	</t>

	</section>	<ol spacing="normal" type="1">
		<li>
		<t>In the "Header Fields" subregistry, the following has been added:
		</t>


	<section title="IANA Registration for the SIP AlertMsg-Error Codes">	<table anchor="header-fields-registry">
		<name>Header Fields Registry Addition
		</name>
		<thead>
		<tr>
		<th>Head Name</th>


	<t>This document creates a new registry for SIP, called	<th>compact
	"AlertMsg-Error Codes". AlertMsg-Error codes provide reasons	</th>

		<th>Reference
		</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>AlertMsg-Error
		</td>
		<td>
		</td>
		<td>RFC 8876</td>
		</tr>

		</tbody>
		</table>
		</li>
		<li>
		<t>In the "Header Field Parameters and Parameter
		Values" subregistry, the following has been added:
		</t>

		<table anchor="header-field-parameters-values">
		<name>Header Field Parameters and Parameter Values Registry Addition
		</name>
		<thead>
		<tr>
		<th>Header Field</th>
		<th>Parameter Name</th>
		<th>Predefined Values</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>AlertMsg-Error
		</td>
		<td>code
		</td>
		<td>no
		</td>
		<td>RFC 8876
		</td>
		</tr>

		</tbody>
		</table>

		</li>
		</ol>
		</section>
		<section numbered="true" toc="default">
		<name>SIP AlertMsg-Error Codes</name>
		<t>This document creates a new registry called
		"SIP AlertMsg-Error Codes". AlertMsg-Error codes provide reasons
	for an error discovered by a recipient, categorized by	for an error discovered by a recipient, categorized by
	the action to be taken by the error recipient. The initial values for this	the action to be taken by the error recipient. The initial values for this

	registry are shown below.</t>	registry are shown below. The registration procedure is Specification
		Required <xref target="RFC8126"/>.</t>
	<t>Registry Name: AlertMsg-Error Codes</t>
	<t>Reference: [this doc]</t>
	<t>Registration Procedures: Specification Required</t>


	<t>	<table anchor="registry-initial-values">
	<figure>	<name>SIP AlertMsg-Error Codes Registry Creation
	<artwork>	</name>
	<![CDATA[	<thead>
	Code Default Reason Phrase Reference	<tr>
	100 "Cannot Process the Alert Payload" [this doc]	<th>Code
		</th>


	101 "Alert Payload was not present or could not be found" [this doc]	<th>Default Reason Phrase
		</th>


	102 "Not enough information to determine	<th>Reference
	the purpose of the alert" [this doc]	</th>
		</tr>
		</thead>


	103 "Alert Payload was corrupted" [this doc]	<tbody>
	]]></artwork>	<tr>
	</figure>	<td>100
	</t>	</td>
		<td>"Cannot process the alert payload"
		</td>
		<td>RFC 8876
		</td>
		</tr>


	<t>Details of these error codes are in <xref target="error"/>.</t>	<tr>
	</section>	<td>101
		</td>
		<td>"Alert payload was not present or could not be found"
		</td>
		<td>RFC 8876
		</td>
		</tr>


	</section>	<tr>
		<td>102
		</td>
		<td>"Not enough information to determine the purpose of the alert"
		</td>
		<td>RFC 8876
		</td>
		</tr>


	<!-- ///////////////////////////////////////////////////////////////////////	<tr>
	/////////// -->	<td>103
		</td>
		<td>"Alert payload was corrupted"
		</td>
		<td>RFC 8876
		</td>
		</tr>
		</tbody>
		</table>


	<section title="Acknowledgments">	<t>Details of these error codes are in <xref target="error" format="defa
	<t>The authors would like to thank the participants of the Early Warning a	ult"/>.</t>
	dhoc meeting at	</section>
	IETF#69 for their feedback. Additionally, we would like to thank the mem
	bers of the NENA
	Long Term Direction Working Group for their feedback. </t>
	<t>Additionally, we would like to thank Martin Thomson, James Winterbottom
	, Shida Schubert,
	Bernard Aboba, Marc Linsner, Christer Holmberg and Ivo Sedlacek for thei
	r review comments.</t>
	</section>	</section>


	<!-- /////////////////////////////////////////////////////////////////////// /////////// -->
	</middle>	</middle>


	<!-- /////////////////////////////////////////////////////////////////////////
	///////// -->

	<back>	<back>

	<references title="Normative References">	<references>
	<reference anchor="RFC2119" >	<name>References</name>
	<front>	<references>
	<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Re	<name>Normative References</name>
	quirement Levels</title>
	<author fullname="Scott Bradner" initials="S." surname="Bradner">
	<organization>Harvard University</organization>
	</author>
	<date month="March" year="1997"/>
	</front>
	<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" ty
	pe="TXT"/>
	</reference>
	<reference anchor="cap" target="https://docs.oasis-open.org/emergency/cap/
	v1.2/CAP-v1.2-os.pdf">
	<front>
	<title>Common Alerting Protocol v. 1.2 </title>
	<author fullname="Elysa Jones" initials="E." surname="Jones">
	<organization>Warning Systems, Inc</organization>
	</author>
	<author fullname="Art Botterell" initials="A." surname="Botterell">
	<organization>Individual</organization>
	</author>
	<date month="October" year="2005"/>
	</front>
	<format type="PDF"/>
	</reference>
	&RFC2392;
	&RFC2818;
	&RFC3261;
	&RFC3262;
	&RFC3428;
	&RFC4119;
	&RFC5234;
	&RFC7303;
	&RFC3629;
	&RFC3986;
	&RFC6442;
	&RFC6881;
	&RFC7852;
	&RFC8174;
	&RFC8225;
	</references>


	<references title="Informative References"> &RFC7378;	<reference anchor="CAP" target="https://docs.oasis-open.org/emergency/ca
	&RFC8224; &RFC5031; &RFC3325; &RFC5222; &RFC6443; </references>	p/v1.2/CAP-v1.2-os.pdf">
		<front>
		<title>Common Alerting Protocol Version 1.2 </title>
		<author fullname="Elysa Jones" initials="E." surname="Jones">
		<organization>Warning Systems, Inc</organization>
		</author>
		<author fullname="Art Botterell" initials="A." surname="Botterell">
		<organization>Individual</organization>
		</author>
		<date month="July" year="2010"/>
		</front>
		<refcontent>OASIS Standard CAP-V1.2</refcontent>

		</reference>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2392.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2818.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3261.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3262.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3428.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5234.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7303.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3629.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3986.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6442.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6881.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7852.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8225.xml"/>

		</references>
		<references>
		<name>Informative References</name>
		<xi:include
		href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7378.x
		ml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8224.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5031.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3325.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5222.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6443.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3550.xml"/>
		</references>
		</references>

		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>The authors would like to thank the participants of the Early Warning
		ad hoc meeting at IETF 69 for their feedback. Additionally, we would
		like to thank the members of the NENA Long Term Direction Working Group
		for their feedback. </t>
		<t>Additionally, we would like to thank <contact fullname="Martin
		Thomson"/>, <contact fullname="James Winterbottom"/>, <contact
		fullname="Shida Schubert"/>, <contact fullname="Bernard Aboba"/>,
		<contact fullname="Marc Linsner"/>, <contact fullname="Christer
		Holmberg"/>, and <contact fullname="Ivo Sedlacek"/> for their review
		comments.</t>
		</section>
	</back>	</back>


	</rfc>	</rfc>

End of changes. 109 change blocks.
	769 lines changed or deleted	871 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/