One document matched: draft-rosen-atoca-cap-01.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 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 RFC5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY RFC5491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml">
<!ENTITY RFC5139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml">
<!ENTITY RFC4660 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4660.xml">
<!ENTITY RFC4661 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4661.xml">
<!ENTITY I-D.ietf-sipcore-event-rate-control SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-event-rate-control.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.forte-lost-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.forte-lost-extensions.xml">
<!ENTITY I-D.forte-ecrit-service-classification SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.forte-ecrit-service-classification.xml">
]>
<rfc category="std" docName="draft-rosen-atoca-cap-01.txt" ipr="trust200902">
<front>
<title abbrev="SIP CAP"> Session Initiation Protocol (SIP) Event Package for the Common Alerting
Protocol (CAP)</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="2010"/>
<area>Internet</area>
<workgroup>ATOCA</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>CAP</keyword>
<keyword>Common Alerting Protocol</keyword>
<abstract>
<t>The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency
alerts and public warnings. This document allows CAP documents to be distributed via the
event notification mechanism available with the Session Initiation Protocol (SIP). </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. The abstract architectural description for the distribution of alerts can be found in <xref target="I-D.ietf-atoca-requirements"/>.
</t>
<t>This document specifies how CAP documents are
distributed via the event notification mechanism available with the Session Initiation
Protocol (SIP). Additionally, a MIME object is registered to allow CAP documents to be exchanged in other
SIP messages.</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>Note that early warning specific definitions can be found in <xref target="I-D.ietf-atoca-requirements"/>.
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="The 'common-alerting-protocol' Event Package">
<t>RFC 3265 <xref target="RFC3265"/> defines a SIP extension for subscribing to remote nodes
and receiving notifications of changes (events) in their states. It leaves the definition of
many aspects of these events to concrete extensions, i.e. event packages. This document defines such a new "common-alerting-protocol" event package.
RFC 3903 <xref target="RFC3903"/> defines an extension that allows SIP User
Agents to publish event state. Event Publication
Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in
the "common-alerting-protocol event package. Acting as a notifier, the ESC notifies
subscribers about emergency alerts and public warnings. </t>
<section title="Package Name">
<t> The name of this package is "common-alerting-protocol". As specified in RFC 3265 <xref
target="RFC3265"/>, this value appears in the Event header field present in SUBSCRIBE
and NOTIFY requests. As specified in RFC 3903 <xref target="RFC3903"/>, this value also
appears in the Event header field present in PUBLISH requests. </t>
</section>
<section title="Event Package Parameters">
<t> RFC 3265 <xref target="RFC3265"/> allows event packages to define additional parameters
carried in the Event header field. This event package does
not define additional parameters. </t>
</section>
<section title="SUBSCRIBE Bodies">
<t>RFC 3265 <xref target="RFC3265"/> allows a SUBSCRIBE request to contain a body. This
document allows the body to contain event filters, see <xref target="RFC4660"/> and <xref target="RFC4661"/> with the information elements listed in the subsections below.</t>
<section title="Location Filter">
<t> The 2D location shapes listed in
<xref target="RFC5491"/> (e.g., <Point>
<Polygon>, <Circle>, <Ellipse>,
<ArcBand>) and the <civicAddress> element, defined in
<xref target="RFC5139"/>. Repeating these elements is allowed and the semantic is
equivalent to a union. The <alertArea> element indicates the area of interest; whenever an event
happens in this area an alert message is delivered.
</t>
<t> An example can be found below: </t>
<t>
<figure title="Example of a SIP SUBSCRIBE Body with a Location Filter">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:af="urn:ietf:params:xml:ns:alert-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<af:alertArea>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
5000
</gs:radius>
</gs:Circle>
</af:alertArea>
</trigger>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section title="Service Filter">
<t>To filter different types of alerts the <serviceFilter> element MUST be included as a child element of the <what> element and it MUST list one or more Service URNs <xref target="RFC5031"/>, which indicate the type
of alerts the recipient is interested in. This document registers a number of alerts relevant for exigent communications, which can be found in <xref
target="iana"/>.
</t>
<t> An example can be found below: </t>
<t>
<figure title="Example of a SIP SUBSCRIBE Body with a Service Filter">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:af="urn:ietf:params:xml:ns:alert-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<af:serviceFilter>
urn:service:warning.met
</af:serviceFilter>
</what>
</filter>
</filter-set>
]]></artwork>
</figure>
</t>
</section>
<section anchor="rate-control" title="Rate Control">
<t><xref target="I-D.ietf-sipcore-event-rate-control"/> extends the SIP events
framework by defining three "Event" header field
parameters that allow a subscriber to set a minimum, a maximum and an
average rate of event notifications generated by the notifier. This
allows a subscriber to have overall control over the stream of
notifications, for example to avoid being flooded.</t>
<t>
A notifier is required to send a NOTIFY request immediately after
creation of a subscription. If state is not available at that time,
then the NOTIFY request may be sent with no content. A separate
NOTIFY containing an alert message may be generated some time
later when it becomes available.
<xref target="fig-rate-control"/> shows a SUBSCRIBE/NOTIFY exchange.
</t>
<t>
<figure anchor="fig-rate-control" title="SUBSCRIBE/NOTIFY with Rate Control">
<artwork>
<![CDATA[
Subscriber Notifier
|---SUBSCRIBE(1)--->| Create subscription
|<-------200--------|
|<-----NOTIFY(2)----| Return initial notify with no state
|--------200------->|
|<-----NOTIFY(3)----| Alert message comes available
|--------200------->|
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Subscription Duration">
<t>The default expiration time for subscriptions within this package is 3600 seconds. As per
RFC 3265 <xref target="RFC3265"/>, the subscriber MAY specify an alternate expiration in
the Expires header field. </t>
</section>
<section title="NOTIFY Bodies">
<t> As described in RFC 3265 <xref target="RFC3265"/>, the NOTIFY message will contain
bodies describing the state of the subscribed resource. This body is in a format listed in
the Accept header field of the SUBSCRIBE request, or a package-specific default format if
the Accept header field was omitted from the SUBSCRIBE request. </t>
<t> In this event package, the body of the notification contains a Common Alerting Protocol
(CAP) document, i.e., an XML document. The format of the XML documents used by CAP are
described in <xref target="cap"/>. </t>
<t>For an initial notify, unlike for other event packages, there is no current initial
state, unless there's a pending alert. Hence, returning a NOTIFY with a non-empty body
only makes sense if there are indeed active alerts.</t>
<t> All subscribers and notifiers of the "common-alerting-protocol" event package MUST
support the "application/common-alerting-protocol+xml" data format. The SUBSCRIBE request
MAY contain an Accept header field. If no such header field is present, it has a default
value of "application/common-alerting-protocol+xml" (assuming that the Event header field
contains a value of "common-alerting-protocol"). If the Accept header field is present, it
MUST include "application/common-alerting-protocol+xml". </t>
</section>
<section title="Notifier Processing of SUBSCRIBE Requests">
<t> The contents of a CAP document may contain public information, depending on the alert
message type and the intended recipient of the alert message. It is, however, expected
that in many cases providing CAP documents does not require authorization by subscribers.
</t>
</section>
<section title="Notifier Generation of NOTIFY Requests">
<t> RFC 3265 <xref target="RFC3265"/> details the formatting and structure of NOTIFY
messages. However, packages are mandated to provide detailed information on when to send a
NOTIFY, how to compute the state of the resource, how to generate neutral or fake state
information, and whether state information is complete or partial. This section describes
those details for the common-alerting-protocol event package. </t>
<t> A notifier MAY send a NOTIFY at any time. Typically, it will send one when an alert or
early warning message is available. The NOTIFY request contains a body containing one or
multiple CAP document(s). The times at which the NOTIFY is sent for a particular
subscriber, and the contents of the body within that notification, are subject to any
rules specified by the authorization policy that governs the subscription. </t>
<t>If the subscription is rejected, a NOTIFY
MAY be sent. As described in RFC 3265 <xref target="RFC3265"/>, the Subscription-State
header field indicates the state of the subscription. </t>
<t>The body of the NOTIFY MUST be sent using one of the types listed in the Accept header
field in the most recent SUBSCRIBE request, or using the type
"application/common-alerting-protocol+xml" if no Accept header field was present.</t>
<t> Notifiers act as Event State Compositors (ESC). Thus, they learn the
'common-alerting-protocol' event state via PUBLISH requests sent from authorized Event
Publication Agents (EPAs). A Notifier may also be an EPA, or might accept PUBLISH requests
from authorized EPAs.
</t>
</section>
<section title="Subscriber Processing of NOTIFY Requests">
<t> RFC 3265 <xref target="RFC3265"/> leaves it to event packages to describe the process
followed by the subscriber upon receipt of a NOTIFY request, including any logic required
to form a coherent resource state. </t>
</section>
<section title="Handling of Forked Requests">
<t> RFC 3265 <xref target="RFC3265"/> requires each package to describe handling of forked
SUBSCRIBE requests. </t>
<t>Given that a single SUBSCRIBE might include multiple services and locations, it is
reasonable and useful for a SUBSCRIBE request to fork and to reach multiple UAs. This
is equivalent to multiple sources providing alerts for the same geographical, with a
dedicated relay serving an aggregation function.</t>
<t>As a result, a forked SUBSCRIBE request can install
multiple subscriptions. Subscribers to this package MUST be prepared
to install subscription state for each NOTIFY generated as a result
of a single SUBSCRIBE.
</t>
</section>
<section title="Rate of Notifications">
<t> RFC 3265 <xref target="RFC3265"/> requires each package to specify the maximum rate at
which notifications can be sent. </t>
<t> Notifiers SHOULD NOT generate notifications for a single user at a rate of more than
once every five seconds. </t>
</section>
<section title="State Agents">
<t> RFC 3265 <xref target="RFC3265"/> requires each package to consider the role of state
agents in the package and, if they are used, to specify how authentication and
authorization are done. This specification allows state agents to be located in the
network.</t>
</section>
<section title="Examples">
<t>An example is provided in <xref target="example"/>. </t>
</section>
<section title="Use of URIs to Retrieve State">
<t> RFC 3265 <xref target="RFC3265"/> allows packages to use URIs to retrieve large state
documents. </t>
<t> CAP documents are fairly small. This event package does not provide a mechanism to use
URIs to retrieve large state documents. </t>
</section>
<section title="PUBLISH Bodies">
<t>RFC 3903 <xref target="RFC3903"/> requires event packages to define the content types
expected in PUBLISH requests. </t>
<t> In this event package, the body of a PUBLISH request may contain a CAP document. A CAP
document describes an emergency alert or an early warning event. </t>
<t> All EPAs and ESCs MUST support the "application/common-alerting-protocol+xml" data
format and MAY support other formats. </t>
</section>
<section title="PUBLISH Response Bodies">
<t> This specification assumes that the response to a PUBLISH does not contain a body.</t>
</section>
<section title="Multiple Sources for Event State">
<t> RFC 3903 <xref target="RFC3903"/> requires event packages to specify whether multiple
sources can contribute to the event state view at the ESC. </t>
<t> This event package allows different EPAs to publish CAP documents for a particular user.
The concept of composition is not applicable for this application usage.</t>
</section>
<section title="Event State Segmentation">
<t> RFC 3903 <xref target="RFC3903"/> defines segments within a state document. Each segment
is defined as one of potentially many identifiable sections in the published event state. </t>
<t> This event package defines does not differentiate between different segments. </t>
</section>
<section title="Rate of Publication">
<t> RFC 3903 <xref target="RFC3903"/> allows event packages to define their own rate of
publication. This event package allows rate control to be utilized, as described in <xref target="rate-control"/>.</t>
<!-- <t> There are no rate-limiting recommendations for common-alerting-protocol publication.
Since emergency alerts and early warning events are typically rare there is no
periodicity, nor a minimum or maximum rate of publication. </t>
--> </section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="example" title="Examples">
<t>Here is an example of a CAP document.</t>
<t>
<figure title="Example for a Severe Thunderstorm Warning">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>KSTO1055887203</identifier>
<sender>KSTO@NWS.NOAA.GOV</sender>
<sent>2003-06-17T14:57:00-07:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Met</category>
<event>SEVERE THUNDERSTORM</event>
<urgency>Severe</urgency>
<certainty>Likely</certainty>
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description> AT 254 PM PDT...
NATIONAL WEATHER SERVICE
DOPPLER RADAR INDICATED A SEVERE
THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
OR ABOUT 18 MILES SOUTHEAST OF
KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
INTENSE RAIN AND STRONG DAMAGING WINDS
ARE LIKELY WITH THIS STORM </description>
<instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
UNTIL THE STORM PASSES </instruction>
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
IN CALIFORNIA, EXTREME NORTHEASTERN
CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
ALPINE COUNTY IN CALIFORNIA </areaDesc>
<polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14 </polygon>
</area>
</info>
</alert>
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="sec-cons" title="Security Considerations">
<t> This section discusses security considerations when using SIP to distribute warning
messages using CAP.</t>
<t>Based on the framework outlined in <xref target="I-D.ietf-atoca-requirements"/> the following
security concerns arise:
<list style="hanging">
<t hangText="Amplification Attacks:">An adversary could inject alerts into the message handling system and therefore a single PUBLISH request could potentially results in millions of NOTIFY messages delivered to receivers. Injecting messages may happen at a number of ways, such as by adversaries who manage to impersonate a legitimate originator, a relay or gateway.
Ensuring that only authorized entities are permitted to inject alerts is a pre-condition. This does, however, not help if the host of a trusted participant in the message handling system got compromised.</t>
<t hangText="Forgery of Alerts:">Alerts may get modified or replayed. The former is possible if the adversary manages to get access to a relay or gateway. Two mechanisms are proposed for countering forgery: using digital signatures or channel security (TLS). The first provides end-to-end security; the second utilizes a hop by hop security model based on a transitive chain of trust.</t>
</list>
</t>
<t>The sub-sections below discuss these threats and their countermeasures in more detail. </t>
<section anchor="sec-cons-authorization" title="Amplification">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/>The attacker could then conceivably attempt to impersonate
an originator, or a relay. A side effect of being able to inject an alert
for distribution is the amplification effect. <vspace blankLines="1"/></t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/>
When an entity receives a CAP message it has to determine
whether the entity distributing the CAP messages is genuine to avoid accepting
messages that are injected by malicious entities.
<vspace blankLines="1"/>
When receiving a CAP document a couple of verification steps
must be performed. First, it needs to be ensured that the message was delivered via a
trusted entity and that the communication channel
between the User Agent and it's SIP proxy is properly secured to exclude various
attacks at the SIP level. Then, the message contains the <sender> that
may contain an entity that falls within the white list of the entity receiving the
message. Finally, the message is protected by a digital signature and the entity
signing the CAP message may again be listed in a white list of the receiving entity
and may therefore be trusted. If none of these verification checks lead to a positive
indication of a known sender then the CAP document should be treated as suspicious and
configuration at the receiving entity may dictate how to process and display CAP
documents in such a case. </t>
</list>
</t>
<section anchor="sec-cons-forged-assn" title="Forgery of Alerts">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/> A malicious user could forge a CAP document. Alternatively, a CAP document distributed earlier could be replied.<vspace
blankLines="1"/>
</t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/> To avoid forgery, the entities must assure that
proper mechanisms for protecting the CAP documents are employed, for example signing the CAP
document itself or securing the communication between participating entities using TLS. Section 3.3.2.1 of <xref target="cap"/> specifies the signing of CAP
documents.
<vspace blankLines="1"/>Regarding replay attacks the following observations can be made. 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 originator/author 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. Recipients who enter the area of a disaster after the
initial distribution of warnings may not yet have seen the original CAP message and, as such, would
not be able to distinguish a replay from the initial message being sent around.
However, if the threat that lead to the distribution of warning messages is still
imminent then there is no reason not to worry about that message. The originator/author
distributing the alert is, however, adviced to carefully select a
value for the <expires> element and it is RECOMMENDED to set a value for this
element.
</t>
</list>
</t>
</section>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="iana" title="IANA Considerations">
<section title="Registration of the 'common-alerting-protocol' Event Package">
<t> This specification registers an event package, based on the registration procedures
defined in RFC 3265 <xref target="RFC3265"/>. The following is the information required
for such a registration: <list style="hanging">
<t hangText="Package Name:"> common-alerting-protocol </t>
<t hangText="Package or Template-Package:"> This is a package. </t>
<t hangText="Published Document:"> RFC XXX [Replace by the RFC number of this
specification]. </t>
<t hangText="Person to Contact:"> Hannes Tschofenig, Hannes.Tschofenig@nsn.com</t>
</list>
</t>
</section>
<section title="Registration of the 'application/common-alerting-protocol+xml' MIME type">
<t>
<list style="hanging">
<t hangText="To:"> ietf-types@iana.org </t>
<t hangText="Subject:">Registration of MIME media type application/
common-alerting-protocol+xml</t>
<t hangText="MIME media type name:"> application </t>
<t hangText="MIME subtype name:">common-alerting-protocol+xml </t>
<t hangText="Required parameters:"> (none) </t>
<t hangText="Optional parameters:"> charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 <xref target="RFC3629"/>.</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.</t>
<t hangText="Security considerations:"> This content type is designed to carry payloads
of the Common Alerting Protocol (CAP). </t>
<t hangText="Interoperability considerations:"> This content type provides a way to
convey CAP payloads. </t>
<t hangText="Published specification:"> RFC XXX [Replace by the RFC number of this
specification]. </t>
<t hangText="Applications which use this media type:"> Applications that convey alerts
and early warnings according to the CAP standard.</t>
<t hangText="Additional information:"> OASIS has published the Common Alerting Protocol
at <xref target="cap"/>.</t>
<t hangText="Person & email address to contact for further information:"> Hannes
Tschofenig, Hannes.Tschofenig@nsn.com </t>
<t hangText="Intended usage:"> Limited use </t>
<t hangText="Author/Change controller:"> IETF SIPPING working group </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/common-alerting-protocol+xml. </t>
</list>
</t>
</section>
<section title="Early Warning Service URNs">
<t>In according with RFC 5031 this document defines a new top-level service called
'warning'. This section defines the first service registration within the IANA registry
using the top-level service label 'warning'. </t>
<t> The 'warning' service type describes emergency services requiring an immediate action or
remedy by the recipient of the alert message as instructed by the author of the message.
Additional sub-services can be added after expert review and must be of general public
interest and have a similar emergency nature. The expert is designated by the ECRIT
working group, its successor, or, in their absence, the IESG. The expert review should
only approve emergency services that are offered widely and in different countries, with
approximately the same caller expectation in terms of services rendered. </t>
<t> The following list contains the initial IANA registration for the 'warning' service. </t>
<t>
<list style="hanging">
<t hangText="urn:service:warning.geo:"> Geophysical (inc. landslide) </t>
<t hangText="urn:service:warning.met:"> Meteorological (inc. flood) </t>
<t hangText="urn:service:warning.safety:"> General emergency and public safety </t>
<t hangText="urn:service:warning.security:">Law enforcement, military, homeland and local/private
security </t>
<t hangText="urn:service:warning.rescue:"> Rescue and recovery </t>
<t hangText="urn:service:warning.fire:">Fire suppression and rescue </t>
<t hangText="urn:service:warning.health:"> Medical and public health </t>
<t hangText="urn:service:warning.env:">Pollution and other environmental </t>
<t hangText="urn:service:warning.transport:">Public and private transportation </t>
<t hangText="urn:service:warning.infra:"> Utility, telecommunication, other non-transport
infrastructure </t>
<t hangText="urn:service:warning.cbrne:">Chemical, Biological, Radiological, Nuclear or High-Yield
Explosive threat or attack </t>
<t hangText="urn:service:warning.other:">Other events </t>
</list>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Open Issues">
<t>The authors would like to point to a number of issues that require discussion:
<list style="hanging">
<t hangText="Rate Control:">The -00 version of the document introduced rate control for notifications <xref target="rate-control"/>. Is this functionality is needed? </t>
<t hangText="Early Warning Service URNs:">Specifying services is always difficult since there is no universally agreed service semantic. This document contains a proposal that re-use the classification in the CAP specification <xref target="cap"/>. Is the proposal acceptable? </t>
<t hangText="Event Filter:">By using <xref target="RFC4660"/> and <xref target="RFC4661"/> filters in the body of a SUBSCRIBE the number of notifications can be reduced to those of interest to the subscriber. There is a certain overhead associated with the generic usage of those event filters. Should alternatives be considered?</t>
<t hangText="Forked SUBSCRIBE Requests:">This document allows forked subscribe request. This is useful when a single
service is offered by more than one entity and therefore related to the cases discussed in <xref target="I-D.forte-lost-extensions"/> and in <xref target="I-D.forte-ecrit-service-classification"/>. For example, imagine a warning service like 'urn:service:warning.geo' that is advertised by a number of different service providers.
</t>
<t hangText="Security:"> The security consideration section was re-written and focuses now mostly on two types of attacks, namely amplificiation and forgery. Does this reflect the understanding of the group?</t>
</list>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>The authors would like to thank Cullen Jennings for his early support and
the participants of the Early Warning Adhoc meeting at IETF#69 for their feedback.</t>
<t>We would furthermore like to thank Martin Thomson for his detailed draft review in July 2010.</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> &RFC3265; &RFC3903; &RFC3023; &RFC3629;
&RFC5491; &RFC5139; &RFC5031; &I-D.ietf-sipcore-event-rate-control; &RFC4660; &RFC4661;</references>
<references title="Informative References">
&I-D.ietf-atoca-requirements;
&I-D.forte-lost-extensions;
&I-D.forte-ecrit-service-classification;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 00:07:45 |