One document matched: draft-barnes-atoca-cap-mime-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-barnes-atoca-cap-mime-01" ipr="trust200902">
<front>
<title abbrev="CAP MIME registration">Media Type Registration for Common
Alerting Protocol</title>
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>1300 N 17th St</street>
<city>Arlington</city>
<region>VA</region>
<code>22209</code>
<country>US</country>
</postal>
<email>rbarnes@bbn.com</email>
</address>
</author>
<author fullname="Brian Rosen" initials="B." surname="Rosen">
<organization>Neustar</organization>
<address>
<postal>
<street>470 Conrad Dr.</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="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>
</address>
</author>
<date month="October" year="2011" />
<abstract>
<t>This document registers the media type "application/cap+xml" for
Common Alerting Protocol (CAP) format .</t>
</abstract>
<note title="Requirements Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The <xref target="CAP">Common Alerting Protocol (CAP)</xref> is an
XML document format for exchanging emergency alerts and public warnings.
This document registers a media type for CAP documents. The full
specification for CAP can be found at the following URL:</t>
<t><http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf></t>
<t>The following is an example of a CAP message for a severe
thunderstorm warning:</t>
<figure>
<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>
</section>
<section anchor="IANA" title="IANA Considerations">
<t></t>
<section title="Registration of the 'application/common-alerting-protocol+xml' media type">
<t><list style="hanging">
<t hangText="To: ">ietf-types@iana.org</t>
<t hangText="Subject: ">Registration of media type
application/cap+xml</t>
<t hangText="Type name:">application</t>
<t hangText="Subtype name:">cap+xml</t>
<t hangText="Required parameters: ">(none)</t>
<t hangText="Optional parameters: ">charset; Indicates the
character encoding of the enclosed XML. Default is UTF-8 <xref
target="RFC3629"></xref>.</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"></xref>, Section 3.2.</t>
<t hangText="Security considerations: ">Transmission of CAP
payloads does not introduce new security risks</t>
<t hangText="Interoperability considerations: ">CAP is widely used
for emergency management.</t>
<t hangText="Published specification: ">RFC XXXX [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: "><list style="hanging">
<t hangText="Magic number: ">(none)</t>
<t hangText="File extension: ">.cap</t>
<t hangText="Macintosh file type code: ">'TEXT'</t>
</list></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="Restrictions on usage: ">(none)</t>
<t hangText="Author: ">The CAP format was originally standardized
by OASIS <xref target="CAP"></xref>. This document was developed
by the IETF ATOCA working group.</t>
<t hangText="Change controller: ">The IESG
<iesg@ietf.org></t>
<t hangText="Other information: ">This media type is a
specialization of application/xml <xref target="RFC3023"></xref>,
and many of the considerations described there also apply to
application/cap+xml.</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The introduction of the CAP MIME type does not present any new risks
in itself. CAP messages are used to encode emergency alerts, which means
that false CAP messages can have significant negative effects, such as
the unnecessary evacuation of an area. Systems that process CAP messages
will need to have mechanisms for integrity protection and origin
authentication, in order to ensure either that end alert recipients do
not receive false alerts or that they can distinguish valid alerts from
false alerts.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc ?>
<reference anchor="CAP">
<front>
<title>Common Alerting Protocol v1.1</title>
<author fullname="" initials="A" surname="Botterell">
<organization></organization>
</author>
<author initials="E." surname="Jones">
<organization>J</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="October" year="2005" />
</front>
<format target="http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf"
type="PDF" />
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3023"?>
<?rfc include="reference.RFC.3629"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:36:59 |