One document matched: draft-ietf-ecrit-data-only-ea-02.xml
<?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 RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3311 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml">
<!ENTITY RFC3428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3428.xml">
<!ENTITY RFC3903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY RFC6086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6086.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC3265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY RFC3903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY RFC3023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY RFC3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY I-D.ietf-ecrit-phonebcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY I-D.ietf-ecrit-trustworthy-location SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-trustworthy-location.xml">
<!ENTITY I-D.ietf-atoca-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-atoca-requirements.xml">
<!ENTITY I-D.ietf-sipcore-location-conveyance SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-location-conveyance.xml">
]>
<rfc category="exp" docName="draft-ietf-ecrit-data-only-ea-02.txt" ipr="trust200902">
<front>
<title abbrev="Data-Only Emergency Alerts">Common Alerting Protocol (CAP) based
Emergency Alerts using the Session Initiation Protocol (SIP)</title>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>NeuStar, Inc. </organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region> PA </region>
<code>16046 </code>
<country>US </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>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2011"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>CAP</keyword>
<keyword>Common Alerting Protocol</keyword>
<keyword>Data-Only Emergency Alerts</keyword>
<abstract>
<t> The Common Alerting Protocol (CAP) is a document format for
exchanging emergency alerts and public warnings. CAP is mainly used
for conveying alerts and warnings between authorities and from
authorities to citizen/individuals. This document describes how
devices use CAP to issue emergency alerts.</t>
</abstract>
</front>
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="introduction" title="Introduction">
<t>The Common Alerting Protocol (CAP) <xref target="cap"/> is an XML document format for
exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and
warnings between authorities and from authorities to citizen/individuals. This document
describes how data-only emergency calls are able to utilize the same CAP document format.</t>
<t>Emergency alerts containing data are similar to regular emergency calls in
the sense that they require emergency call routing functionality and
may even have the same location requirements. On the other hand, the
communication interaction may occur without establishment
of a voice or video channel.</t>
<t>Data-only emergency alerts are similar to regular emergency calls in the sense that they
require emergency call routing functionality and may even have the same location requirements.
On the other hand, the initial communication interaction will not lead
to the establishment of a voice or video channel.</t>
<t>
Based on the deployment experience with non-IP based systems, two
major deployment scenarios are envisaged:
</t>
<t><list style="numbers">
<t>Emergency alerts containing only data are targeted to a
recipient responsible for evaluating the next steps, which
could include:
<list style="numbers">
<t>Sending an alert containing only data toward a Public
Safety Answering Point (PSAP);
</t>
<t>Establishing an emergency call with a PSAP that could
include audio/video as well as data
</t>
</list>
</t>
<t>Emergency alerts targeted to a Service URN 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 and a PIDF-LO payload in a SIP MESSAGE)
or could be included along with
establishment of an audio/video channel (e.g. SIP INVITE)
</t>
</list>
</t>
<t>We describe these two cases in more detail in <xref target="arch"/>.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 <xref target="RFC2119"/>.</t>
<t>This document utilizes terminology introduced in <xref target="I-D.ietf-atoca-requirements"/>.
In particular, the terms for author, originator, receiver and recipient, are relevant for this
document. The originator and the receiver are SIP-based entities while the author and the recipient
are entities that relate to the alert message delivery, when this is relevant for the communication.
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="arch" title="Architectural Overview">
<t>This section illustrates two envisioned usage modes; targeted and location-based emergency
alert routing. <xref target="targeted"/> shows a deployment variant where a sensor,
as the author and originator of the alert, is pre-configured (using techniques outside the
scope of this document) to issue an alert to a receiver or an aggregator, a special form of mediator,
that processes these messages and performs whatever steps are necessary to appropriately
react on 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 Emergency Alert Routing">
<artwork xml:space="preserve">
<![CDATA[
+------------+ +------------+
| Sensor | | Aggregator |
| | | |
+---+--------+ +------+-----+
| |
Sensors |
trigger |
emergency |
alert |
| MESSAGE with CAP |
|----------------------------->|
| |
| Aggregator
| processes
| emergency
| alert
| 200 (OK) |
|<-----------------------------|
| |
| |
]]></artwork>
</figure>
</t>
<t>
In <xref target="location"/> a scenario is shown whereby the alert is routed
using location information and the Service URN. An emergency services routing
proxy (ESRP) may use LoST to determine the next hop proxy to route the alert
message to. A possible receiver is a PSAP and the recipient of the alert
may be call taker. In the generic case, there is very likely no prior relationship between
the originator and the receiver, e.g. PSAP. A PSAP, for example, is likely to receive and
accept alerts from entities it cannot authorize. This scenario corresponds more to the
classical emergency services use case and the description in
<xref target="I-D.ietf-ecrit-phonebcp"/> is applicable.
</t>
<t>
<figure anchor="location" title="Location-Based Emergency Alert Routing">
<artwork xml:space="preserve">
<![CDATA[
+-----------+ +----------+
+--------+ | ESRP | | PSAP |
| Sensor | | | | |
+---+----+ +---+-------+ +---+------+
| | |
Sensors | |
trigger | |
emergency | |
alert | |
| | |
| | |
| MESSAGE with CAP | |
| (including Service URN, |
| such as urn:service:sos) |
|------------------->| |
| | |
| ESRP performs |
| emergency alert |
| routing |
| | MESSAGE with CAP |
| | (including identity info) |
| |----------------------------->|
| | |
| | PSAP
| | processes
| | emergency
| | alert
| | 200 (OK) |
| |<-----------------------------|
| | |
| 200 (OK) | |
|<-------------------| |
| | |
| | |
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Protocol Specification">
<section title="CAP Transport">
<t>Since alerts structured via CAP require a "push" medium. The following SIP requests
MAY carry the CAP payload defined in this document: INVITE <xref target="RFC3261"/>, UPDATE <xref target="RFC3311"/>,
MESSAGE <xref target="RFC3428"/>, INFO <xref target="RFC6086"/>, NOTIFY <xref target="RFC3265"/>, and PUBLISH <xref target="RFC3903"/>.
The MIME type is set to 'application/cap+xml'.</t>
<t>If the server does not support the functionality required to fulfill the
request then a 501 Not Implemented MUST be returned by RFC 3261 <xref target="RFC3261"/>. This is the appropriate response when a 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 MUST be returned by RFC 3261 <xref target="RFC3261"/>
if the 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 return a list of acceptable
formats using the Accept, Accept-Encoding, or Accept-Language header
field, depending on the specific problem with the content.</t>
</section>
<section title="Profiling of the CAP Document Content">
<t>The usage of CAP MUST conform to the specification provided with <xref target="cap"/>.
For the usage with SIP the following additional requirements are imposed: </t>
<t><list
style="hanging">
<t hangText="sender:">A few sub-categories for putting a value in the <sender> element have to be considered:
<list style="hanging">
<t hangText="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 <sender> element
MUST be populated with the SIP URI of the user agent.</t>
<t hangText="Originator is a non-SIP entity, Author indication irrelevant:">
In case that the alert was created by a non-SIP based
entity and the identity of this original sender wants to be preserved then this identity MUST be
placed into the <sender> element. In this category the it is not useful to be explicit about the author of the alert. The specific type of identity being used will depends on the technology being used by the original originator.</t>
<t hangText="Author indication relevant:"> In case the author is different from the actual originator of the message and this distinction wants to be preserved then the <sender> element MUST NOT contain the SIP URI.
</t>
</list>
<vspace blankLines="1"/></t>
<t hangText="incidents:"> The <incidents> element MUST be present whenever there is
a possibility that alert information needs to be updated. The initial message will
then contain an incident identifier carried in the <incidents> element. This
incident identifier MUST be chosen in such a way that it is unique for a given
<sender, expires, incidents> combination. Note that the <expires> element
is optional and may not be present.<vspace blankLines="1"/></t>
<t hangText="scope:">The value of the <scope> element MUST be set to
"Private" as the alert is not meant for public consumption.
The <addresses> 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 headers. Populating information twice into different parts of
the message may lead to inconsistency. <vspace blankLines="1"/> </t>
<t hangText="parameter:">The <parameter> element MAY contain additional
information specific to the sensor. <vspace blankLines="1"/></t>
<t hangText="area:">It is RECOMMENDED to omit this element when constructing a message.
In case that the CAP message already contained an <area> element then the specified
location information MUST be copied into the PIDF-LO structure of the 'geolocation'
header.</t>
</list></t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="error" title="Error Handling">
<t>This section defines a new error response code and a header field for additional information.</t>
<section title="425 (Bad Alert Message) Response Code">
<t>This SIP extension creates a new location-specific response code,
defined as follows,
<list style="empty">
<t>425 (Bad Alert Message)</t>
</list>
</t>
<t>The 425 response code is a rejection of
the request due to its included alert content, indicating that it was malformed or not satisfactory for the
recipient's purpose.</t>
<t>A SIP intermediary can also reject an alert it receives from a
UA when it understands that the provided alert is malformed.</t>
<t><xref target="error-header"/> describes a 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 only appropriate to generate a 425 response when the
responding entity has no other information in
the request that are usable by the responder.</t>
<t>A 425 response code MUST NOT be sent in response to a request that lacks an alert message entirely, as the user agent in that case may not
support this extension at all. </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 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"/>:</t>
<t>
<figure>
<artwork>
<![CDATA[
message-header /= AlertMsg-Error
; (message-header from 3261)
AlertMsg-Error = "AlertMsg-Error" HCOLON
ErrorValue
ErrorValue = error-code
*(SEMI error-params)
error-code = 1*3DIGIT
error-params = error-code-text
/ generic-param ; from RFC3261
error-code-text = "code" EQUAL quoted-string ; from RFC3261
]]></artwork>
</figure>
</t>
<t>HCOLON, SEMI, and EQUAL are defined in RFC3261 <xref target="RFC3261"/>. DIGIT is
defined in RFC5234 <xref target="RFC5234"/>.</t>
<t>The AlertMsg-Error header field MUST 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 understandable. The text string are
OPTIONAL, but RECOMMENDED for human readability, similar to the
string phrase used for SIP response codes. That said, the strings
are complete enough for rendering to the user, if so desired. The
strings in this document are recommendations, and are not
standardized - meaning an operator can change the strings - but MUST
NOT change the meaning of the error code. Similar to how RFC 3261
specifies, there MUST NOT be more than one string per error code.
</t>
<t>
The AlertMsg-Error header field MAY be included in any response
as an alert message was in the request part of the same transaction.
For
example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP can
accept this MESSAGE, thus creating a dialog, even though his UA
determined the alert message contained in the MESSAGE was bad.
The PSAP merely
includes a AlertMsg-Error header value in the 200 OK to the
MESSAGE 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 MESSAGE 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 MESSAGE may also sends a 425 with a
AlertMsg-Error code.</t>
<t>This document defines an initial list of error code ranges for any
SIP response, including provisional responses (other than 100
Trying) and the new 425 response. There MUST be no more than
one AlertMsg-Error code in a SIP response.</t>
<t>AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"</t>
<t>AlertMsg-Error: 101 ; code="Alert Payload was not present or could not be found"</t>
<t>AlertMsg-Error: 102 ; code="Not enough information to determine
the purpose of the alert"</t>
<t>AlertMsg-Error: 103 ; code="Alert Payload was corrupted"</t>
<t>Additionally, if an LR cannot or chooses not to process the alert message
from a SIP request, a 500 (Server Internal Error) SHOULD be used
with or without a configurable Retry-After header field.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="example" title="Example">
<t><xref target="warning1"/> shows a CAP document indicating a BURLARY alert issued by
a sensor with the identity 'sensor1@domain.com'. The location of the sensor can be
obtained from the attached location information provided via the 'geolocation' header
contained in the SIP MESSAGE structure. Additionally, the sensor provided some
data long with the alert message using proprietary information elements only to be
processed by the receiver, a SIP entity acting as an aggregator. This example
reflects the description in <xref target="targeted"/>.</t>
<t>
<figure anchor="warning1" title="Example Message conveying an Alert">
<artwork>
<![CDATA[
MESSAGE sip:aggregator@domain.com SIP/2.0
Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:sensor1@domain.com;tag=49583
To: sip:aggregator@domain.com
Call-ID: asd88asd77a@1.2.3.4
Geolocation: <cid:abcdef@domain.com>
;routing-allowed=yes
Supported: geolocation
Accept: application/pidf+xml, application/cap+xml
CSeq: 1 MESSAGE
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: cap+xml
Content-ID: <abcdef2@domain.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@domain.com</sender>
<sent>2008-11-19T14:57:00-07:00</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@domain.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>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="sec-cons" title="Security Considerations">
<t> This section discusses security considerations when SIP user agents issue emergency
alerts utilizing CAP. Location specific threats are not unique to this document and are
discussed in <xref target="I-D.ietf-ecrit-trustworthy-location"/> and <xref target="I-D.ietf-sipcore-location-conveyance"/>.</t>
<t>The ECRIT emergency services architecture <xref target="I-D.ietf-ecrit-phonebcp"/> considers classical individual-to-authority emergency calling and 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 will not depend on the identity of the caller. In case of emergency alerts generated by devices, like sensors, the processing may be different in order to reduce the number of falsely generated emergency alerts. Alerts may get triggered based on certain sensor input that may have been caused by other factors than the actual occurrence of an alert relevant event. For example, a sensor may simply be malfunctioning. For this purpose not all alert messages are directly sent to a PSAP but are rather 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. These two message routing examples are shown in <xref target="targeted"/> and in <xref target="location"/>.</t>
<t>In any case, for alerts that are initiated by sensors the identity may play an important role in deciding whether to accept or ignore an incoming alert message. With the scenario shown in <xref target="targeted"/> it is very likely that only authorized sensor input will be processed. For this purpose it needs to be ensured that no alert messages from an unknown origin are accepted. Two types of information elements can be used for this purpose:
<list style="numbers">
<t>SIP itself provides security mechanisms that allow the verification of the originator's identity. These mechanisms can be re-used, such as P-Asserted-Identity <xref target="RFC3325"/> or SIP Identity <xref target="RFC4474"/>. The latter provides a cryptographic assurance while the former relies on a chain of trust model.</t>
<t>CAP provides additional security mechanisms and the ability to carry additional information about the sender's identity. Section 3.3.2.1 of <xref target="cap"/> specifies the signing algorithms of CAP
documents.</t>
</list>
</t>
<t>In addition to the desire to perform identity-based access control the classical communication security threats need to be considered, including integrity protection to prevent forgery and 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. These attributes make the CAP document
unique for a specific sender and provide time restrictions. An entity that has
received a CAP message already 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 to make use of SIP
security mechanisms, such as SIP Identity <xref target="RFC4474"/>, to tie the
CAP message to the SIP message. To provide protection of the entire SIP message exchange between neighboring SIP entities the usage of TLS is mandatory.</t>
<t>Note that none of the security mechanism in this document protect against a compromised sensor sending crafted alerts.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="IANA Considerations">
<section title="Registration of the 'application/cap+xml' MIME type">
<t>
<list style="hanging">
<t hangText="To:"> ietf-types@iana.org<vspace blankLines="1"/> </t>
<t hangText="Subject:">Registration of MIME media type application/
cap+xml<vspace blankLines="1"/></t>
<t hangText="MIME media type name:"> application <vspace blankLines="1"/></t>
<t hangText="MIME subtype name:">cap+xml <vspace blankLines="1"/></t>
<t hangText="Required parameters:"> (none)<vspace blankLines="1"/> </t>
<t hangText="Optional parameters:"> charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 <xref target="RFC3629"/>.<vspace blankLines="1"/></t>
<t hangText="Encoding considerations:"> Uses XML, which can employ 8-bit characters,
depending on the character encoding used. See RFC 3023 <xref target="RFC3023"/>,
Section 3.2.<vspace blankLines="1"/></t>
<t hangText="Security considerations:"> This content type is designed to carry payloads
of the Common Alerting Protocol (CAP). <vspace blankLines="1"/></t>
<t hangText="Interoperability considerations:"> This content type provides a way to
convey CAP payloads.<vspace blankLines="1"/> </t>
<t hangText="Published specification:"> RFC XXX [Replace by the RFC number of this
specification]. <vspace blankLines="1"/></t>
<t hangText="Applications which use this media type:"> Applications that convey alerts
and warnings according to the CAP standard.<vspace blankLines="1"/></t>
<t hangText="Additional information:"> OASIS has published the Common Alerting Protocol
at http://www.oasis-open.org/committees/documents.php&wg_abbrev=emergency <vspace blankLines="1"/></t>
<t hangText="Person and email address to contact for further information:"> Hannes
Tschofenig, Hannes.Tschofenig@nsn.com <vspace blankLines="1"/></t>
<t hangText="Intended usage:"> Limited use <vspace blankLines="1"/></t>
<t hangText="Author/Change controller:"> IETF ECRIT working group <vspace blankLines="1"/></t>
<t hangText="Other information:"> This media type is a specialization of application/xml
RFC 3023 <xref target="RFC3023"/>, and many of the considerations described there also
apply to application/cap+xml. <vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="IANA Registration for 425 Response Code">
<t>In the SIP 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
------------------------------------------ ---------
Request Failure 4xx
425 Bad Alert Message [this doc]
]]></artwork>
</figure>
</t>
<t>This SIP Response code is defined in <xref target="error"/>.</t>
</section>
<section title="IANA Registration of New AlertMsg-Error Header Field">
<t>The SIP AlertMsg-error header field is created by this document,
with its definition and rules in <xref target="error"/>, to be
added to the IANA sip-parameters registry with two actions:
<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 yes [this doc]
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="IANA Registration for the SIP AlertMsg-Error Codes">
<t>This document creates a new registry for SIP, called
"AlertMsg-Error Codes". AlertMsg-Error codes provide reason
for the error discovered by recipients, categorized by
action to be taken by 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: Specification Required</t>
<t>
<figure>
<artwork>
<![CDATA[
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process the Alert Payload" [this doc]
101 "Alert Payload was not present or could not be found" [this doc]
102 "Not enough information to determine
the purpose of the alert" [this doc]
103 "Alert Payload was corrupted" [this doc]
]]></artwork>
</figure>
</t>
<t>Details of these error codes are in <xref target="error"/>.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>The authors would like to thank the participants of the Early Warning adhoc 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 Martin Thomson, James Winterbottom, Shida Schubert,
Bernard Aboba, and Marc Linsner 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">
<front>
<title>Common Alerting Protocol v. 1.1 </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
target="http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/14205/emergency-CAPv1.1-Committee%20Specification.pdf"
type="PDF"/>
</reference> &RFC3023; &RFC3629; &I-D.ietf-ecrit-phonebcp; &I-D.ietf-sipcore-location-conveyance;
&RFC3261; &RFC3311; &RFC3428; &RFC6086; &RFC3265; &RFC3903; &RFC5234;
</references>
<references title="Informative References"> &I-D.ietf-atoca-requirements; &I-D.ietf-ecrit-trustworthy-location;
&RFC4474; &RFC3325; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:33:29 |