<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type=<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?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">
]> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8876" consensus="true"
     category="std" docName="draft-ietf-ecrit-data-only-ea-22" ipr="trust200902">
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="false"
     version="3">

  <front>
    <title>Non-Interactive
    <title>Non-interactive Emergency Calls</title>
    <seriesInfo name="RFC" value="8876"/>
    <author initials="B." surname="Rosen" fullname="Brian Rosen">
      <address>
        <postal>
          <street>470 Conrad Dr</street>
          <city>Mars</city>
          <region> PA </region>
          <code>16046 </code>
          <country>US </country>
          <country>United States of America</country>
        </postal>
        <phone> </phone>
        <email>br@brianrosen.net
        </email>
      </address>
    </author>
    <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
      <organization abbrev="Columbia U.">Columbia University</organization>
      <address>
        <postal>
          <street>Department of Computer Science</street>
          <street>450 Computer Science Building</street>
          <city>New York</city>
          <region>NY</region>
          <code>10027</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 212 939 7004</phone>
        <email>hgs+ecrit@cs.columbia.edu</email>
        <uri>http://www.cs.columbia.edu</uri>
        <uri>https://www.cs.columbia.edu</uri>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>ARM Limited</organization>

      <address>
        <postal>
          <street> </street>
          <country>Austria</country>
        </postal>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
        <uri>https://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <author fullname="Randall Gellens" initials="R." surname="Gellens">
      <organization>Core Technology Consulting</organization>
      <address>
        <email>rg+ietf@coretechnologyconsulting.com</email>
        <uri>http://www.coretechnologyconsulting.com</uri>
      </address>
    </author>
    <date month="September" year="2020"/>
    <area>ART</area>
    <workgroup>ECRIT</workgroup>
    <keyword>Internet-Draft</keyword>

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

    <abstract>
      <t>
Use of the Internet for emergency calling is described in RFC 6443, 'Framework
for Emergency Calling Using Internet Multimedia'.  In some cases of emergency
calls, the transmission of application data is all that is needed needed, and no
interactive media channel is established: a situation referred to as
'non-interactive emergency calls', where, unlike most emergency calls, there
is no two way two-way interactive media such as voice or video or text.  This document
describes use of a SIP MESSAGE transaction that includes a container for the
data based on the Common Alerting Protocol (CAP).  That type of emergency
request does not establish a session, distinguishing it from SIP INVITE, which
does.  Any device that needs to initiate a request for emergency services
without an interactive media channel would use the mechanisms in this
document.  </t>
    </abstract>
  </front>
  <middle>
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC6443"/> 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 one-shot 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>Non-interactive emergency calls are similar to regular emergency
      calls in the sense that they require the emergency indications,
      emergency call routing functionality functionality, and location.  However, the
      communication interaction will not lead to the exchange of interactive
      media, that is, Real-Time Transport Protocol <xref target="RFC3550"/> packets, such as voice, video data video, or
      real-time text.</t>
<t>The

<t>
The Common Alerting Protocol (CAP) <xref target="cap"/> target="CAP" format="default"/> 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 public.  The scope of this document is conveying CAP alerts
from private devices to emergency service authorities, as a call without any
interactive media.</t> media.
</t>

      <t>This document describes a method of including a CAP message alert in a SIP
      transaction by defining it as a block of "additional data" as defined in
      <xref target="RFC7852"/>. target="RFC7852" format="default"/>.  The CAP message alert is included
      either by value (the CAP message 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 message). alert).  The additional data mechanism
      is also used to send alert-specific data beyond that available in the
      CAP message. alert.  This document also describes how a SIP MESSAGE <xref target="RFC3428"/>
      target="RFC3428" format="default"/> transaction can be used to send a
      non-interactive call.</t>
    </section>

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

    <section anchor="terminology" title="Terminology">

      <t>The numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>
<t>A non-interactive here.
        </t>

<dl>

<dt>Non-interactive emergency call is an call:
</dt>
<dd>An emergency call where there is no two-way interactive media. </t>
     <t>SIP is the Session media
</dd>

<dt>SIP:
</dt>
<dd>Session Initiation Protocol <xref target="RFC3261"/></t>
     <t>PIDF-LO is Presence target="RFC3261"/>
</dd>

<dt>PIDF-LO:
</dt>
<dd>Presence Information Data Format - Location Object, a data structure for
carrying location <xref target="RFC4119"/></t>
     <t>LoST is the Location target="RFC4119"/>
</dd>

<dt>LoST:
</dt>
<dd>Location To Service Translation protocol <xref target="RFC5222"/></t>
     <t>CID is Content-ID target="RFC5222"/>
</dd>

<dt>CID:
</dt>
<dd>Content-ID <xref target="RFC2392"/></t>
     <t>CAP is the Common target="RFC2392"/>
</dd>

<dt>CAP:
</dt>
<dd>Common Alerting Protocol <xref target="cap"/></t>
     <t>PSAP is a Public target="CAP"/>
</dd>

<dt>PSAP:
</dt>
<dd>Public Safety Answering Point, the call center for emergency calls.</t>
     <t>ESRP is an Emergency calls
</dd>

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

</dl>

    </section>

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

        <section anchor="arch" title="Architectural Overview"> numbered="true" toc="default">
      <name>Architectural Overview</name>
      <t>This section illustrates two envisioned usage modes: targeted and location-based emergency
      alert routing.</t>
<t><list style="numbers">
      <ol spacing="normal" type="1">
        <li>
          <t>Emergency alerts containing only data are targeted to an
          intermediary recipient responsible for evaluating the next steps.
          These steps could include:
     <list style="numbers">
         <t>Sending
          </t>
          <ol spacing="normal" type="a">
            <li>Sending a non-interactive call containing only data towards a Public
            Safety Answering Point (PSAP);
         </t>
         <t>Establishing
         </li>
            <li>Establishing a third-party-initiated emergency call towards a PSAP that could
            include audio, video, and data.
         </t>
    </list>
  </t>
  <t>Emergency
         </li>
          </ol>
        </li>
        <li>Emergency alerts may be targeted to a Service service URN <xref target="RFC5031"/>
        target="RFC5031" format="default"/> used for IP-based emergency calls
        where the recipient is not known to the originator.  In this scenario,
        the alert may contain only data (e.g., a CAP, SIP MESSAGE with CAP content,
        a Geolocation header field field, and one or more Call-Info header fields
        containing Additional Data additional data <xref target="RFC7852"/> in a SIP MESSAGE).
  </t>
  </list>
</t> target="RFC7852" format="default"/>).
  </li>
      </ol>
      <t>
<xref target="targeted"/> target="targeted" format="default"/> shows a deployment variant where a sensor
     is pre-configured (using techniques outside the
      scope of this document) to issue an alert to an aggregator
      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
      dispatch their security staff to a building they protect or to initiate a third-party emergency call.</t>

     <t>
      <figure anchor="targeted" title="Targeted anchor="targeted">
        <name>Targeted Emergency Alert Routing"> Routing</name>
        <artwork xml:space="preserve">
          <![CDATA[ name="" type="" align="left" alt=""><![CDATA[
 +------------+              +------------+
 | Sensor     |              | Aggregator |
 |            |              |            |
 +---+--------+              +------+-----+
     |                              |
  Sensors                           |
  trigger                           |
  emergency                         |
  alert                             |
     |    SIP MESSAGE with CAP      |
     |----------------------------->|
     |                              |
     |                           Aggregator
     |                           processes
     |                           emergency
     |                           alert
     |      SIP 200 (OK)            |
     |<-----------------------------|
     |                              |
     |                              |
          ]]></artwork>
      </figure>
</t>
      <t>
        In <xref target="location"/> target="location" format="default"/>, a scenario is shown whereby
        where the alert is routed using location information and a Service service
        URN. An emergency services routing proxy (ESRP) may use LoST (a
        protocol defined by <xref target="RFC5222"/> target="RFC5222" format="default"/>, which
        translates a location to a URI used to route an emergency call) to
        determine the next-hop proxy to route the alert message to. A possible
        receiver is a PSAP PSAP, and the recipient of the alert may be a call
        taker. In the generic case, there is very likely no prior relationship
        between the originator and the receiver, e.g., a PSAP. For example, a
        PSAP is likely to receive and accept alerts from entities it has no
        previous relationship with. This scenario is similar to a classic
        voice emergency services call call, and the description in <xref target="RFC6881"/>
        target="RFC6881" format="default"/> is applicable.  In this use case,
        the only difference between an emergency call and an emergency
        non-interactive call is that the former uses INVITE, creates a
        session, and negotiates one or more media streams, while the latter
        uses MESSAGE, does not create a session, and does not have interactive
        media.
      </t>
      <t>
      <figure anchor="location" title="Location-Based anchor="location">
        <name>Location-Based Emergency Alert Routing"> Routing</name>
        <artwork xml:space="preserve">
          <![CDATA[ name="" type="" align="left" alt=""><![CDATA[
   +----------+         +----------+                  +-----------+
   |Sensor or |         |  ESRP    |                  |   PSAP    |
   |Aggregator|         |          |                  |           |
   +----+-----+         +---+------+                  +----+------+
        |                   |                              |
     Sensors                |                              |
     trigger                |                              |
     emergency              |                              |
     alert                  |                              |
        |                   |                              |
        |                   |                              |
        | SIP MESSAGE w/CAP |                              |
        | (including Service service URN,                          |
        | such as urn:service:sos)                         |
        |------------------>|                              |
        |                   |                              |
        |              ESRP performs                       |
        |              emergency alert                     |
        |              routing                             |
        |                   |  MESSAGE with CAP            |
        |                   |  (including identity info)   |
        |                   |----------------------------->|
        |                   |                              |
        |                   |                           PSAP
        |                   |                           processes
        |                   |                           emergency
        |                   |                           alert
        |                   |      SIP 200 (OK)            |
        |                   |<-----------------------------|
        |                   |                              |
        |  SIP 200 (OK)     |                              |
        |<------------------|                              |
        |                   |                              |
        |                   |                              |
]]></artwork>
      </figure>

      </t>
    </section>

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

    <section title="Protocol Specification"> numbered="true" toc="default">
      <name>Protocol Specification</name>
      <section title="CAP Transport">

        <t>A CAP message is sent in the initial message of any SIP transaction.  However, this numbered="true" toc="default">
        <name>CAP Transport</name>
        <t>This document only addresses sending a CAP message alert in a SIP MESSAGE
        transaction for a one-shot, non-interactive emergency call.  Behavior
        with other transactions is not defined.</t>
        <t>The CAP message alert is included in a SIP message as an additional-data additional data
        block <xref target="RFC7852"/>. target="RFC7852" format="default"/>.  Accordingly, it is introduced to
        conveyed in the SIP message with a Call-Info header field with a
        purpose of "EmergencyCallData.cap".  The header field may contain a
        URI that is used by the recipient (or in some cases, an intermediary)
        to obtain the CAP message. alert.  Alternatively, the Call-Info header field
        may contain a Content-ID url URL <xref target="RFC2392"/> target="RFC2392" format="default"/>
        and the CAP message alert included in the body of the message.  In the
        latter case, the CAP message alert is located in a MIME block of the type
        'application/emergencyCallData.cap+xml'.</t>
        <t>If the SIP server does not support the functionality required to
        fulfill the
   request request, then a 501 Not Implemented will be returned as
        specified in <xref target="RFC3261"/>. target="RFC3261" format="default"/>. This is the
        appropriate response when a User Agent Server (UAS) 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"/> target="RFC3261" format="default"/>
        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
   the requested method.  The server MUST <bcp14>MUST</bcp14> return a list of acceptable
   formats using the Accept, Accept-Encoding, or Accept-Language header
   fields, depending on the specific problem with the content.</t>
      </section>
      <section title="Profiling numbered="true" toc="default">
        <name>Profiling of the CAP Document Content"> Content</name>
        <t>The usage of CAP MUST <bcp14>MUST</bcp14> conform to the specification
        provided with <xref target="cap"/>. target="CAP" format="default"/>.  For usage with SIP
        SIP, the following additional requirements are imposed (where "sender"
        and "author" are as defined in CAP and "Originator" "originator" is the entity
	sending the alert): CAP alert, which may be different from the entity sending
	the SIP MESSAGE): </t>
        <t><list
            style="hanging">
           <t hangText="sender:">The
        <dl newline="false" spacing="normal">
          <dt>sender:</dt>
          <dd>
            <t>The following restrictions and conditions apply to setting the value of the &lt;sender&gt; element:
           <list style="symbols">
              <t>
            </t>
            <ul spacing="normal">
              <li>
		Originator is a SIP entity, Author indication irrelevant: When
		the alert was created by a SIP-based originator and it is not
		useful to be explicit about the author of the alert, then the
		&lt;sender&gt; element
              	MUST <bcp14>MUST</bcp14> be populated with
		the SIP URI of the user agent.
	     </t>
             <t>
	     </li>
              <li>
		Originator is a non-SIP entity, Author indication irrelevant:
		When the alert was created by a non-SIP based non-SIP-based entity and the
		identity of this original sender is to be preserved, then this
		identity MUST <bcp14>MUST</bcp14> be placed into the &lt;sender&gt;
		element. In this situation 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 original
		originator.
	     </t>
             <t>
	     </li>
              <li>
		Author indication relevant: When the author is different from
		the actual originator of the message and this distinction
		should be preserved, then the &lt;sender&gt; element MUST NOT
		<bcp14>MUST NOT</bcp14> contain the SIP URI of the user agent.
	     </t>
           </list></t>

          <t hangText="incidents:">
	     </li>
            </ul>
          </dd>
          <dt>incidents:</dt>
          <dd>
            <t> The &lt;incidents&gt; element MUST <bcp14>MUST</bcp14> be present.
            This incident identifier MUST <bcp14>MUST</bcp14> be chosen in such a
            way that it is unique for a given &lt;sender, expires,
            incidents&gt; combination. Note that the &lt;expires&gt; element
            is OPTIONAL <bcp14>OPTIONAL</bcp14> and might not be present.<vspace blankLines="1"/></t>
            <t hangText="scope:">The present.</t>

          </dd>
          <dt>scope:</dt>
          <dd>
            <t>The value of the &lt;scope&gt; element MAY <bcp14>MAY</bcp14> be
            set to "Private" if the alert is not meant for public consumption.
            The &lt;addresses&gt; element is, however, not used by this
            specification since the message routing is performed by SIP and
            the respective address information is already available in other
            SIP header fields. Populating information twice into different
            parts of the message may lead to inconsistency. <vspace blankLines="1"/> </t>
            <t hangText="parameter:">The
          </dd>
          <dt>parameter:</dt>
          <dd>
            The &lt;parameter&gt; element MAY <bcp14>MAY</bcp14> contain
            additional information specific to the sender, conforming to the
            CAP message alert syntax. <vspace blankLines="1"/></t>
            <t hangText="area:">It
          </dd>
          <dt>area:</dt>
          <dd>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to omit this element when
          constructing a message.  If the CAP message alert is given to the SIP
          entity to transport and it already contains an &lt;area&gt; element,
          then the specified location information SHOULD <bcp14>SHOULD</bcp14> be
          copied into a PIDF-LO structure (the data format for location used
          by emergency calls on the Internet) referenced by the SIP
          'Geolocation' header field.  If the CAP message alert is being created by
          the SIP entity using a PIDF-LO structure referenced by 'geolocation'
          to construct &lt;area&gt;, implementers must be aware that
          &lt;area&gt; is limited to a circle or polygon, and conversion of
          other shapes will be required.  Points SHOULD <bcp14>SHOULD</bcp14> be
          converted to a circle with a radius equal to the uncertainty of the
          point.  Arc-
     bands  Arc-bands and ellipses SHOULD <bcp14>SHOULD</bcp14> be converted
          to polygons with similar coverage, and 3D locations SHOULD
          <bcp14>SHOULD</bcp14> be converted to 2D forms with similar
          coverage.
            </t>
          </list></t>
            </dd>
        </dl>
      </section>
      <section title="Sending numbered="true" toc="default">
        <name>Sending a non-interactive Non-interactive Emergency Call"> 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"/>. 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 anchor="error" title="Error Handling"> numbered="true" toc="default">
      <name>Error Handling</name>
      <t>This section defines a new error response code and a header field for
      additional information.</t>
      <section title="425 numbered="true" toc="default">
        <name>425 (Bad Alert Message) Response Code"> Code</name>
        <t>This SIP extension creates a new location-specific response code, code
        defined as follows:
   <list style="empty">
   <t>425
        </t>
        <ul empty="true" spacing="normal">
          <li>425 (Bad Alert Message)</t>
   </list>
</t> Message)</li>
        </ul>
        <t>The 425 response code is a rejection of the request, indicating
        that it was malformed enough that no reasonable emergency response to
        the alert can be determined.</t>

        <t>A SIP intermediary can also use 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"/>
        <t>

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

<t>
<figure>
          <artwork>
            <![CDATA[
        target="RFC5234" format="default"/>:</t>

<sourcecode type="abnf">
   message-header   =/ AlertMsg-Error
                           ; (message-header from RFC3261) RFC 3261)
   AlertMsg-Error   = "AlertMsg-Error" HCOLON
                           ErrorValue
   ErrorValue       =  error-code
                            *(SEMI error-params)
   error-code       = 3DIGIT
   error-params     = error-code-text
                            / generic-param ; from RFC3261 RFC 3261
   error-code-text  = "message" EQUAL quoted-string ; from RFC3261
]]></artwork>
        </figure>
      </t> RFC 3261
</sourcecode>

        <t>HCOLON, SEMI, and EQUAL are defined in <xref target="RFC3261"/>. target="RFC3261"
        format="default"/>. DIGIT is defined in <xref target="RFC5234"/>.</t> target="RFC5234"
        format="default"/>.</t>
        <t>The AlertMsg-Error header field MUST <bcp14>MUST</bcp14> contain only one
   ErrorValue to indicate what was wrong with the alert payload
   the recipient determined was bad.</t>
        <t>
   The ErrorValue
   contains a 3-digit error code indicating what was wrong with the
   alert in the request.  This error code has a corresponding quoted
   error text string that is human readable.  The text string is
   OPTIONAL,
   <bcp14>OPTIONAL</bcp14>, but RECOMMENDED <bcp14>RECOMMENDED</bcp14> for human readability, similar to the
   string phrase used for SIP response codes. The
   strings in this document are recommendations, recommendations and are not
   standardized -- meaning an operator can change the strings -- but MUST
   NOT <bcp14>MUST
   NOT</bcp14> change the meaning of the error code.
   The code space for ErrorValue is separate from SIP Status Codes.
        </t>
        <t>
   The AlertMsg-Error header field MAY <bcp14>MAY</bcp14> be included in any response
    if an alert message was in the request part of the same transaction.
    For
   example, suppose a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
   accept this MESSAGE, even though its UA
   determined that the alert message contained in the MESSAGE was bad.
   The PSAP merely
   includes an AlertMsg-Error header field value in the 200 OK to the
   MESSAGE, thus informing the UA that the MESSAGE was accepted but the alert
   provided was bad.</t>
        <t>If, on the other hand, the PSAP cannot accept the transaction without a
   suitable alert message, a 425 response is sent.</t>
        <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
        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
        Trying) and the new 425 response. There MUST NOT <bcp14>MUST NOT</bcp14> be
        more than one AlertMsg-Error code in a SIP response. AlertMsg-Error
        values sent in provisional responses MUST <bcp14>MUST</bcp14> be sent using
        the mechanism defined in <xref target="RFC3262"/>; target="RFC3262" format="default"/>; or,
        if that mechanism is not negotiated, MUST they <bcp14>MUST</bcp14> be repeated
        in the final response to the transaction.
</t>

<t>AlertMsg-Error:

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

<t>AlertMsg-Error: alert payload"

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

<t>AlertMsg-Error: found"

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

<t>AlertMsg-Error: alert"

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

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

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

    <section anchor="example" title="Example"> numbered="true" toc="default">
      <name>Example</name>
      <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
        obtained from the attached location information provided via the 'geolocation' 'Geolocation' header field
        contained in the SIP MESSAGE structure. Additionally, the sensor provided some
        data along with the alert message, using proprietary information elements intended only to be
        processed by the receiver, a SIP entity acting as an aggregator.</t>
      <t>

      <figure anchor="warning1" title="Example anchor="warning1">
        <name>Example Message conveying Conveying an Alert to an aggregator">
          <artwork>
            <![CDATA[ Aggregator</name>

<sourcecode><![CDATA[
   MESSAGE sip:aggregator@example.com SIP/2.0
   Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
   Max-Forwards: 70
   From: sip:sensor1@example.com;tag=49583
   To: sip:aggregator@example.com
   Call-ID: asd88asd77a@2001:db8::ff
   Geolocation: <cid:abcdef@example.com>
     ;routing-allowed=yes
   Supported: geolocation
   CSeq: 1 MESSAGE
   Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1
   Content-Type: application/EmergencyCallData.cap+xml
   Content-ID: <abcdef2@example.com>
   Content-Disposition: by-reference;handling=optional

   <?xml version="1.0" encoding="UTF-8"?>

   <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>S-1</identifier>
    <sender>sip:sensor1@example.com</sender>
    <sent>2020-01-04T20:57:35Z</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Private</scope>
    <incidents>abc1234</incidents>
    <info>
        <category>Security</category>
        <event>BURGLARY</event>
        <urgency>Expected</urgency>
        <certainty>Likely</certainty>
        <severity>Moderate</severity>
        <senderName>SENSOR 1</senderName>
        <parameter>
          <valueName>SENSOR-DATA-NAMESPACE1</valueName>
          <value>123</value>
        </parameter>
        <parameter>
          <valueName>SENSOR-DATA-NAMESPACE2</valueName>
          <value>TRUE</value>
        </parameter>
    </info>
  </alert>

   --boundary1
   Content-Type: application/pidf+xml
   Content-ID: <abcdef2@example.com>

   <?xml version="1.0" encoding="UTF-8"?>
       <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gbp=
                 "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          entity="pres:alice@atlanta.example.com">
        <dm:device id="sensor">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>44.85249659 -93.238665712</gml:pos>
                </gml:Point>
             </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>
              <gbp:retention-expiry>2020-02-04T20:57:29Z
              </gbp:retention-expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
          </gp:geopriv>
          <dm:timestamp>2020-01-04T20:57:29Z</dm:timestamp>
        </dm:device>
      </presence>
   --boundary1--
          ]]></artwork>
          ]]></sourcecode>
      </figure>
      </t>
      <t>The following shows the same CAP document sent as a non-interactive emergency call towards a PSAP.</t>
      <t>
      <figure anchor="warning2" title="Example anchor="warning2">
        <name>Example Message conveying Conveying an Alert to a PSAP">
          <artwork>
            <![CDATA[ PSAP</name>
<sourcecode><![CDATA[
   MESSAGE urn:service:sos SIP/2.0
   Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
   Max-Forwards: 70
   From: sip:aggregator@example.com;tag=32336
   To: 112
   Call-ID: asdf33443a@example.com
   Route: sip:psap1.example.gov
   Geolocation: <cid:abcdef@example.com>
     ;routing-allowed=yes
   Supported: geolocation
   Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
   CSeq: 1 MESSAGE
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/EmergencyCallData.cap+xml
   Content-ID: <abcdef2@example.com>
  <?xml version="1.0" encoding="UTF-8"?>

  <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>S-1</identifier>
    <sender>sip:sensor1@example.com</sender>
    <sent>2020-01-04T20:57:35Z</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Private</scope>
    <incidents>abc1234</incidents>
    <info>
        <category>Security</category>
        <event>BURGLARY</event>
        <urgency>Expected</urgency>
        <certainty>Likely</certainty>
        <severity>Moderate</severity>
        <senderName>SENSOR 1</senderName>
        <parameter>
          <valueName>SENSOR-DATA-NAMESPACE1</valueName>
          <value>123</value>
        </parameter>
        <parameter>
          <valueName>SENSOR-DATA-NAMESPACE2</valueName>
          <value>TRUE</value>
        </parameter>
    </info>
   </alert>

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <abcdef2@example.com>
   <?xml version="1.0" encoding="UTF-8"?>
       <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gbp=
                 "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          entity="pres:alice@atlanta.example.com">
        <dm:device id="sensor">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>44.85249659 -93.2386657124</gml:pos>
                </gml:Point>
             </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>
              <gbp:retention-expiry>2020-02-04T20:57:25Z
              </gbp:retention-expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
          </gp:geopriv>
          <dm:timestamp>2020-01-04T20:57:25Z</dm:timestamp>
        </dm:device>
      </presence>
   --boundary1--
          ]]></artwork>
          ]]>
</sourcecode>
      </figure>
      </t>
    </section>

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

    <section anchor="sec-cons" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> This section discusses security considerations when SIP user agents issue emergency
        alerts utilizing MESSAGE and CAP. Location-specific threats are not unique to this document and are
        discussed in <xref target="RFC7378"/> target="RFC7378" format="default"/> and <xref target="RFC6442"/>.</t>
	target="RFC6442" format="default"/>.</t>

      <t>The ECRIT Emergency Context Resolution with Internet Technologies (ECRIT)
      emergency services architecture <xref target="RFC6443"/> target="RFC6443"
      format="default"/> considers classic individual-to-authority emergency
      calling where the identity of the emergency caller does not play a role
      at the time of the call establishment itself, i.e., a response to the
      emergency call does not depend on the identity of the caller. In the
      case of emergency alerts generated by devices such as sensors, the
      processing may be different in order to reduce the number of falsely
      generated emergency alerts. Alerts could get triggered based on certain
      sensor input that might have been caused by factors other than the
      actual occurrence of an alert-relevant event. For example, a sensor may
      simply be malfunctioning. For this reason, not all alert messages are
      directly sent to a PSAP, but rather 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"/> 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:
<list style="numbers">
<t>SIP
</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"/> target="RFC3325" format="default"/> or SIP Identity <xref target="RFC8224"/>. target="RFC8224" format="default"/>. The latter provides a cryptographic assurance while the former relies on a chain of trust chain-of-trust model. These mechanisms can be reused.</t>
<t>CAP 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 target="cap"/> target="CAP" format="default"/> specifies the signing algorithms of CAP
              documents.</t>
</list></t>
              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 document, could be used
      by malicious actors, actors or misbehaving devices to effect a denial of service denial-of-service
      attack on the emergency services.  The mechanism defined in this
      document does not introduce any new considerations 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 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 URIs found in a Call Info header of a SIP MESSAGE.  These
      may include a CAP message alert as well as other Additional Data (RFC7852) additional data <xref
      target="RFC7852"/> blocks.  The domain of the device sending the SIP MESSAGE,
      MESSAGE; the domain of the server holding the CAP message, alert, if sent by reference,
      reference; and the domain of other Additional Data 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 MUST
      <bcp14>MUST</bcp14> take precautions in retrieving any Additional Data additional data
      blocks passed by reference, including the CAP message, 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"/>
      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 &lt;identifier&gt;, &lt;sender&gt;, and
      &lt;sent&gt; elements and an optional &lt;expire&gt; 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 message
      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 RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> to make use of SIP security mechanisms, such
      as the SIP Identity PASSporT <xref target="RFC8225"/>, target="RFC8225" format="default"/>,
      to tie the CAP message alert to the SIP message. To provide protection of the
      entire SIP message exchange between neighboring SIP entities, the usage
      of TLS is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.  <xref target="RFC6443"/> target="RFC6443"
      format="default"/> discusses the issues of using TLS with emergency
      calls, which are equally applicable to non-interactive emergency calls</t>
      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"/>
      target="RFC7852" format="default"/> and are applicable here.
</t>
    </section>

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

    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section title="Registration of the 'application/EmergencyCallData.cap+xml' media type">
        <t>
          <list style="hanging">
            <t hangText="To:"> ietf-types@iana.org<vspace blankLines="1"/> </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>
            <t hangText="Required parameters:"> (none)<vspace blankLines="1"/> numbered="true" toc="default">
        <name>'application/EmergencyCallData.cap+xml' Media Type</name>
        <dl newline="false" spacing="normal">
          <dt>Type name:</dt>
          <dd>
            <t>application </t>
            <t hangText="Optional parameters:">

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

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

          </dd>
          <dt>Optional parameters:</dt>
          <dd>
            <t> charset; Indicates the character encoding of
              enclosed XML. Default is UTF-8 <xref target="RFC3629"/>.<vspace blankLines="1"/></t>

            <t hangText="Encoding considerations:"> target="RFC3629" format="default"/>.</t>

          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t> 7bit, 8bit 8bit, or binary. See <xref target="RFC7303"/>,
              Section 3.2.<vspace blankLines="1"/></t>
            <t hangText="Security considerations:"> sectionFormat="of" target="RFC7303" section="3.2"/>.</t>

          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t> This content type is designed to carry payloads of the Common
            Alerting Protocol (CAP).  RFC XXX [Replace by the RFC number of this
              specification] 8876 discusses security
            considerations for this. <vspace blankLines="1"/></t>
            <t hangText="Interoperability considerations:"> </t>

          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t> This content type provides a way to
              convey CAP payloads.<vspace blankLines="1"/> </t>

            <t hangText="Published specification:"> RFC XXX [Replace by the payloads.</t>

          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t> RFC number of this
              specification]. <vspace blankLines="1"/></t>
            <t hangText="Applications which 8876</t>

          </dd>
          <dt>Applications that use this media type:"> type:</dt>
          <dd>
            <t> Applications that convey alerts
              and warnings according to the CAP standard.<vspace blankLines="1"/></t>
           <t hangText="Fragment Identifier Considerations: N/A"> .<vspace blankLines="1"/></t>

            <t hangText="Additional information:"> standard.</t>

          </dd>
          <dt>Fragment identifier considerations: N/A</dt>
          <dd>

          </dd>
          <dt>Additional information:</dt>
          <dd>
            <t> OASIS has published the Common Alerting Protocol
              at http://www.oasis-open.org/committees/documents.php&amp;wg_abbrev=emergency <vspace blankLines="1"/></t>

            <t hangText="Person <eref
	      target="https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf"
	      brackets="angle"/></t>

          </dd>
          <dt>Person and email address to contact for further information:"> Hannes
              Tschofenig, hannes.tschofenig@gmx.net <vspace blankLines="1"/></t>
            <t hangText="Intended usage:"> information:</dt>
          <dd>
            <t><br/><contact fullname="Hannes Tschofenig"/> &lt;hannes.tschofenig@gmx.net&gt;</t>

          </dd>
          <dt>Intended usage:</dt>
          <dd>
            <t> Limited use <vspace blankLines="1"/></t>
            <t hangText="Author/Change controller:"> </t>

          </dd>
          <dt>Author/Change controller:</dt>
          <dd>
            <t> The IESG <vspace blankLines="1"/></t>
            <t hangText="Other information:"> </t>

          </dd>
          <dt>Other information:</dt>
          <dd>
            <t> This media type is a specialization of application/xml 'application/xml' <xref target="RFC7303"/>,
            target="RFC7303" format="default"/>, and many of the
            considerations described there also apply to application/cap+xml. <vspace blankLines="1"/></t>
          </list>
        </t>
	    application/EmergencyCallData.cap+xml.</t>

          </dd>
        </dl>
      </section>
      <section title="IANA Registration of 'cap' numbered="true" toc="default">
        <name>'cap' Additional Data Block">
<t>This document registers Block</name>
        <t>Per this document, IANA has registered a new block type in the sub-registry called 'Emergency
        "Emergency Call Data
   Types' Types" subregistry of the Emergency "Emergency Call Additional Data Registry Data"
        registry defined in <xref target="RFC7852"/>. target="RFC7852" format="default"/>.  The
        token is "cap", the Data About is "The Call" Call", and the reference is
        this document.  </t>
      </section>
      <section title="IANA Registration for 425 numbered="true" toc="default">
        <name>425 Response Code"> Code</name>
        <t>In the SIP Response Codes "Response Codes" registry, the following is added</t>

<t>Reference: RFC-XXXX (i.e., this document)</t>
<t>Response code: 425 (recommended number to assign)</t>
<t>Default reason phrase: Bad Alert Message</t>

  <t>
        <figure>
          <artwork>
            <![CDATA[
   Registry:
     Response Code                               Reference
     ------------------------------------------  --------- has been added
	under Request Failure 4xx
       425 Bad 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                   [this doc]
          ]]></artwork>
        </figure>
      </t> Message</td>
      <td>RFC 8876</td>
    </tr>
  </tbody>
</table>

        <t>This SIP Response code is defined in <xref target="error"/>.</t> target="error" format="default"/>.</t>
      </section>
      <section title="IANA Registration of New AlertMsg-Error numbered="true" toc="default">
        <name>AlertMsg-Error Header Field"> Field</name>
        <t>The SIP AlertMsg-error AlertMsg-Error header field is created by this document,
   with its definition and rules in <xref target="error"/>, to be
   added to the target="error"
   format="default"/>.
   The IANA Session "Session Initiation Protocol (SIP) Parameters Parameters" registry with two actions:

<list style="numbers">
  <t>Update
   has been updated as follows.

</t>
        <ol spacing="normal" type="1">
          <li>
            <t>In the Header Fields registry with
     <vspace blankLines="1"/>
             <figure>
          <artwork>
            <![CDATA[
   Registry:
     Header Name        compact    Reference
     -----------------  -------    ---------
     AlertMsg-Error             [this doc]
          ]]></artwork>
        </figure> "Header Fields" subregistry, the following has been added:
            </t>

<table anchor="header-fields-registry">
<name>Header Fields Registry Addition
</name>
  <thead>
    <tr>
      <th>Head Name</th>

      <th>compact
      </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 portion titled "Header Field Parameters and Parameter
      Values", add
<vspace blankLines="1"/>
        <figure>
          <artwork>
            <![CDATA[
                                            Predefined
   Header
      Values" subregistry, the following has been added:
</t>

<table anchor="header-field-parameters-values">
<name>Header Field Parameters and Parameter Name Values      Reference
   -----------------   -------------------  ----------  ---------
   AlertMsg-Error      code                 no          [this doc]
          ]]></artwork>
        </figure>
      </t>
</list>
</t> 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 title="IANA Registration for the SIP numbered="true" toc="default">
        <name>SIP AlertMsg-Error Codes"> Codes</name>
        <t>This document creates a new registry for SIP, called
   "AlertMsg-Error
   "SIP AlertMsg-Error Codes". AlertMsg-Error codes provide reasons
   for an error discovered by a recipient, categorized by
   the action to be taken by the error recipient.  The initial values for this
   registry are shown below.</t>

<t>Registry Name: AlertMsg-Error Codes</t>
<t>Reference: [this doc]</t>
<t>Registration Procedures: below. The registration procedure is Specification Required</t>

<t>
        <figure>
          <artwork>
            <![CDATA[
Code Default
	Required <xref target="RFC8126"/>.</t>

<table anchor="registry-initial-values">
<name>SIP AlertMsg-Error Codes Registry Creation
</name>
  <thead>
    <tr>
      <th>Code
      </th>

      <th>Default Reason Phrase                                 Reference
---- ---------------------------------------------------   ---------
100  "Cannot Process
      </th>

      <th>Reference
      </th>
</tr>
  </thead>

  <tbody>
     <tr>
     <td>100
     </td>
     <td>"Cannot process the Alert Payload"                    [this doc]

101  "Alert Payload alert payload"
     </td>
     <td>RFC 8876
     </td>
     </tr>

     <tr>
     <td>101
     </td>
     <td>"Alert payload was not present or could not be found" [this doc]

102  "Not
     </td>
     <td>RFC 8876
     </td>
     </tr>

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

103  "Alert Payload
     </td>
     <td>RFC 8876
     </td>
     </tr>

     <tr>
     <td>103
     </td>
     <td>"Alert payload was corrupted"                         [this doc]
          ]]></artwork>
        </figure>
      </t>
     </td>
     <td>RFC 8876
     </td>
     </tr>
  </tbody>
</table>

        <t>Details of these error codes are in <xref target="error"/>.</t> target="error" format="default"/>.</t>
      </section>
    </section>

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

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="CAP" target="https://docs.oasis-open.org/emergency/cap/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.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2392.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3428.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7303.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6442.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6881.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7852.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>

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

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank the participants of the Early Warning adhoc
      ad hoc meeting at
        IETF#69 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 Martin Thomson, James Winterbottom, Shida Schubert,
        Bernard Aboba, Marc Linsner, Christer Holmberg and Ivo Sedlacek <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>

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

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

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119" >
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement 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" type="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;
    &RFC8224; &RFC5031; &RFC3325; &RFC5222; &RFC6443; </references>
  </back>

</rfc>