Common Alerting Protocol
The Common Alerting Protocol (CAP) is an international, non-proprietary digital data standard for exchanging all-hazard emergency alerts and public warnings, allowing a single input to be disseminated simultaneously over diverse networks such as radio, television, cell broadcasts, and the internet.[1] Developed by the Organization for the Advancement of Structured Information Standards (OASIS) Emergency Management Technical Committee and also standardized as ITU-T Recommendation X.1303, CAP uses an XML-based format to structure alert messages, supporting features like geographic targeting, multilingual text, and multimedia attachments to enhance accessibility for diverse audiences, including those who are deaf, blind, or non-native speakers.[1][2][3] Originating from recommendations in a 2000 U.S. National Science and Technology Council report on effective disaster warnings, CAP was first approved as an OASIS Standard in October 2004 (version 1.0), with subsequent updates to version 1.1 in October 2005 and version 1.2 in July 2010, which remains the current iteration as of 2025.[1][4] The protocol addresses longstanding challenges in coordinating alert dissemination by providing a flexible, technology-independent framework that eliminates the need for custom interfaces between warning systems, thereby reducing costs and complexity while enabling rapid detection of patterns in emergencies.[1][5] In the United States, CAP forms the core messaging standard for the Federal Emergency Management Agency's (FEMA) Integrated Public Alert and Warning System (IPAWS), where it was mandated by the Federal Communications Commission (FCC) in 2012 for use in the Emergency Alert System (EAS) by broadcasters and other participants.[2][6] Internationally, CAP has been adopted by organizations such as the World Meteorological Organization (WMO) for global weather and disaster alerts, and it supports implementations in countries including Australia, New Zealand, and various European nations, facilitating cross-border emergency communication.[5][7] Key message types in CAP include initial alerts, updates, and cancellations, with built-in digital signatures for authentication and support for urgency levels such as Immediate and Expected to guide public response.[1]Introduction
Definition and Purpose
The Common Alerting Protocol (CAP) is an XML-based data format designed for the exchange of all-hazards emergency alerts and public warnings across diverse networks and devices.[1] Developed as an open, non-proprietary standard, it enables the creation of a single alert message that can be disseminated simultaneously over various communication channels, such as the internet, radio, television, and mobile devices.[2] This format supports interoperability by providing a consistent structure for alerts, allowing emergency managers to target specific audiences through multilingual messaging and geospatial coordinates.[1] The primary purpose of CAP is to enhance the effectiveness of public warnings by facilitating consistent, targeted dissemination of alerts, thereby reducing duplication of efforts, minimizing costs, and simplifying integration among alerting systems.[1] By eliminating the need for multiple custom interfaces between vendors and networks, CAP promotes broader competition and innovation in alert technologies while ensuring that warnings reach the right people at the right time.[1] Its design emphasizes geospatial targeting using latitude/longitude shapes and multilingual support to accommodate diverse populations and regions.[1] CAP's all-hazards scope encompasses a wide range of threats, including natural disasters like floods and earthquakes, technological incidents such as chemical spills, terrorism, and other public safety risks, without limitations to specific domains.[1] This comprehensive approach ensures that the protocol can be applied universally to geophysical, meteorological, health, environmental, and infrastructure-related events.[1] The development of CAP originated from needs identified in a 2000 report on effective warning systems by the Working Group on Natural Disaster Information Systems of the National Science and Technology Council, titled "Effective Disaster Warnings," which highlighted the lack of standardized formats for alert exchange as a barrier to interoperability.[1] It has since evolved through versions standardized by OASIS, with the current iteration reflecting ongoing refinements for global use.[1]Key Features and Benefits
The Common Alerting Protocol (CAP) incorporates advanced geospatial targeting capabilities, allowing alerts to be directed precisely to affected areas using various descriptors such as coordinate pairs, polygons, circles, and geocodes. Coordinate pairs specify points using the WGS 84 datum in latitude and longitude format, while polygons are defined by a sequence of at least four coordinate pairs (with the first and last identical) to outline complex shapes. Circles denote a central point and radius in kilometers, and geocodes employ system-specific codes like FIPS or SAME for administrative boundaries. These mechanisms enable alert originators to tailor warnings to specific geographic regions, minimizing unnecessary notifications and enhancing relevance for recipients.[8] CAP supports multilingual dissemination by permitting multipleHistory and Development
Origins and Early Efforts
The origins of the Common Alerting Protocol (CAP) trace back to the November 2000 report titled "Effective Disaster Warnings" by the Working Group on Natural Disaster Information Systems under the U.S. National Science and Technology Council (NSTC), which highlighted the limitations of fragmented warning systems and recommended developing a standardized digital message format to enable consistent exchange of emergency alerts across diverse networks and media.[9] This report emphasized the need for an all-hazards approach to address both natural disasters and emerging threats, including potential man-made events, by overcoming silos in existing legacy systems such as the U.S. Emergency Alert System (EAS), which was primarily designed for national-level broadcasts and struggled with local or multi-jurisdictional coordination.[1] In response to these recommendations and intensified focus following the September 11, 2001, terrorist attacks, which underscored the urgency for unified, flexible alerting capable of handling terrorism alongside natural disasters, an international working group comprising over 130 emergency managers, information technology specialists, and telecommunications experts convened in 2001 to design CAP as an extensible XML-based standard.[1] The group used the NSTC report as its foundational reference, aiming to create a protocol that could integrate alerts across radio, television, internet, and other channels while supporting multilingual and multimedia content to break down communication barriers in siloed systems like EAS. Early validation occurred through pilot demonstrations and field trials in 2002, including a pilot in California, in cooperation with the California Office of Emergency Services, which tested CAP's ability to disseminate integrated all-hazards messages over broadcast and digital networks.[10] These pilots focused on practical interoperability, simulating real-world scenarios to refine the draft specification for broader adoption. In the same year, the CAP initiative received endorsement from the Partnership for Public Warning (PPW), a national non-profit organization dedicated to enhancing public warning capabilities, which recognized its potential to unify disparate alerting technologies.[1] This support led to PPW sponsoring CAP's submission in 2003 to the Organization for the Advancement of Structured Information Standards (OASIS) for development as an open international standard, paving the way for formal standardization efforts.[1]Standardization Process
The OASIS Emergency Management Technical Committee (EMTC) was formed in February 2003 to advance standards for incident management and emergency communications, including the development of the Common Alerting Protocol (CAP).[11] Following initial committee drafts, CAP version 1.0 was approved by OASIS membership and adopted as an OASIS Standard on April 1, 2004, establishing a foundational XML-based format for emergency alerts. This version underwent a public review process and ballot within the EMTC before final approval, marking CAP's entry into formal standardization. Building on implementation experience, CAP version 1.1 was developed to address user feedback from version 1.0, including refinements for more effective message updates and error handling. It was approved by OASIS membership and adopted as an OASIS Standard on October 1, 2005. In 2007, an errata document was released on October 2 to correct minor technical issues, such as clarifications in schema definitions and support for Abstract Syntax Notation One (ASN.1) encoding in preparation for international adoption.[12] CAP version 1.2 incorporated public comments solicited by the EMTC in 2008, along with enhancements to support broader interoperability.[1] Key additions included formal ASN.1 encoding specifications and expanded options for response types to better accommodate diverse alerting scenarios.[1] The version was approved by OASIS membership and adopted as an OASIS Standard on July 1, 2010. Since CAP 1.2, no major revisions have been released by OASIS, with efforts shifting toward the creation of national and regional profiles as well as alignment with international bodies like the International Telecommunication Union (ITU), which adopted CAP 1.2 in 2014.[1] In 2024, OASIS marked the 20th anniversary of CAP's standardization, emphasizing its enduring role in global emergency alerting systems. In 2021, a Call to Action on Emergency Alerting was launched, setting a goal for 100% global CAP implementation by 2025, aligning with the United Nations' Early Warnings for All initiative.[13]Technical Specifications
Overall Structure
The Common Alerting Protocol (CAP) defines a standardized XML-based message format for emergency alerts, organized hierarchically to ensure machine-readable dissemination across diverse networks. At its core, a CAP message is encapsulated within a root<alert> element, which serves as the primary container for all essential components, including metadata that identifies and contextualizes the alert. This root element includes required attributes such as identifier for a unique message ID, sender for the originator's identifier, sent for the timestamp of message creation in ISO 8601 DateTime format, status indicating handling instructions (e.g., "Actual" for operational alerts or "Test" for simulations), and msgType specifying the message purpose (e.g., "Alert" for initial notifications, "Update" for revisions, "Cancel" for revocations, "Ack" for acknowledgments, or "Error" for reporting issues).[1] Additional attributes like scope (e.g., "Public" for broad distribution) further refine the message's applicability.[1]
Nested within the <alert> element are optional child elements that provide detailed alert content, including <info> (repeatable for multiple languages, event segments, or audience-specific details), <references> (for linking to related CAP messages), and <incidents> (for identifying associated incidents).[1] The <info> element contains descriptive information about the hazard, such as urgency, severity, and recommended actions, along with child elements like <headline> (a brief summary), <description> (event details), and <instruction> (actions for the public).[1] Within each <info> block, the optional <resource> element links to supplementary materials like images, audio files, or videos for enhanced communication, while the <area> element specifies geographic targeting using formats such as polygons, circles, or geocode identifiers to delimit affected regions.[1] These elements enable flexible, comprehensive alerts tailored to specific scenarios without mandating their inclusion in every message.
CAP messages adhere to the XML namespace urn:oasis:names:tc:[emergency](/page/Emergency):cap:1.2, facilitating interoperability and validation against the official schema available at http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.xsd.[](https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html) This schema ensures structural integrity and conformance during parsing by alerting systems. Primarily encoded in XML for readability and ease of integration, CAP also supports ASN.1 encoding—specifically through Unaligned Packed Encoding Rules (PER) as defined in ITU-T Recommendation X.691—for more compact binary transmission in bandwidth-constrained environments like mobile or satellite networks.[1][14]
Core Elements and Attributes
The Common Alerting Protocol (CAP) defines a structured XML format where the root<alert> element encapsulates the entire message, with the repeatable <info> child element providing detailed alert information; within each <info>, the repeatable <resource> and <area> elements support attachments and geospatial targeting, respectively.[1] These core components ensure interoperability by standardizing the representation of emergency data across diverse alerting systems.[1]
The <alert> element serves as the mandatory root container and includes several required attributes to identify and contextualize the message. The identifier attribute provides a unique, globally routable identifier for the alert, formatted without spaces, commas, or special characters like < or & to facilitate machine processing.[1] The sender attribute specifies the identifier of the originating authority, typically a domain name or similar unique string adhering to the same formatting rules.[1] The sent attribute records the date and time of message origination in UTC format, such as "2002-05-24T16:49:00-07:00", using the XML Schema datetime type.[1] The status attribute indicates the message's handling code, with allowed values including "Actual" for operational alerts, "Exercise" for drills, "System" for internal system messages, "Test" for trial runs, and "Draft" for preliminary versions.[1] The msgType attribute specifies the message purpose, with values "Alert" for initial notifications, "Update" for revisions, "Ack" for acknowledgments, "Error" for issues, and "Cancel" for revocations.[1] The scope attribute defines the intended distribution, with values "Public" for general dissemination, "Restricted" for limited audiences, and "Private" for specific recipients.[1] Optional attributes include source, a text string identifying the alert's origin; restriction, required for "Restricted" scope to specify access limits; and addresses, a space-delimited list of recipients for "Private" scope, with quoting for entries containing whitespace.[1]
The <info> element, which may repeat to support multiple languages or perspectives, conveys the core alert semantics and is essential for human-readable interpretation.[1] Its optional language attribute uses RFC 3066 codes, defaulting to "en-US", to indicate the content's language.[1] The required category attribute classifies the event type, with enumerated values such as "Met" for meteorological hazards, "Safety" for general safety threats, "Rescue" for search-and-rescue operations, alongside others like "Geo", "Security", "Fire", "Health", "Env", "Transport", "Infra", "CBRNE", and "Other"; multiple categories can be specified.[1] The event attribute provides a free-text description of the specific event, such as "Tornado Warning".[1] Required codes for urgency include "Immediate" for threats requiring action within minutes, "Expected" for hours, "Future" for days or more, "Past" for resolved events, and "Unknown"; severity ranges from "Extreme" for life-threatening impacts to "Minor" for minimal effects or "Unknown"; while certainty assesses likelihood as "Observed" for confirmed events, "Likely", "Possible", "Unlikely", or "Unknown".[1] Optional elements include responseType with codes like "Shelter", "Evacuate", "Prepare", "Monitor", "AllClear", or "None" to guide actions; audience for describing targeted recipients; eventCode for system-specific identifiers, structured as pairs like <valueName>SAME</valueName><value>CEM</value>; <headline> for a brief event summary; <description> for detailed information; and <instruction> for public response guidance.[1]
The <resource> element, repeatable for multiple attachments within <info>, enables inclusion of supplementary materials like images or documents to enhance alert comprehension.[1] Required attributes are resourceDesc, a concise text description of the resource's content (e.g., "satellite image"), and mimeType specifying the format per RFC 2046 (e.g., "image/jpeg").[1] Optional attributes include size for the resource's byte length, recommended when a uri is provided; [uri](/page/Uri) as the full retrieval location; and digest using SHA-1 hashing per FIPS 180-2 to verify integrity.[1]
The <area> element, also repeatable within <info>, defines the geographic scope of the alert using a combination of narrative and precise coordinates for targeted dissemination.[1] The required areaDesc attribute offers a human-readable textual summary of the affected region.[1] Optional geospatial descriptors include polygon for WGS 84 latitude-longitude pairs forming closed shapes (at least four points, with the first and last identical, e.g., "38.47,-120.14 38.47,-120.23 ..."); circle for a center point and radius in kilometers (e.g., "32.9525,-115.5527 10"); and geocode for predefined codes like FIPS or SAME, formatted as <valueName>FIPS6</valueName><value>06059</value>.[1] For vertical targeting, optional altitude specifies the minimum altitude in feet above sea level, paired with ceiling for the maximum if a range is intended.[1]
Standards and Interoperability
OASIS and ITU Standards
The Common Alerting Protocol (CAP) is maintained by the OASIS Emergency Management Technical Committee (EM-TC), an open standards body that oversees its development and governance through collaborative, non-proprietary processes allowing contributions from members and the public.[1] CAP version 1.2 was approved as an OASIS Standard on July 1, 2010, establishing it as the core reference for emergency alerting formats.[1] This version emphasizes machine-readable XML structures for all-hazard alerts, with ongoing support provided via the committee's public comment mechanisms.[15] In parallel, the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) adopted CAP version 1.1 as Recommendation X.1303 in September 2007, aligning it with global telecommunications infrastructures for emergency services. This recommendation, technically equivalent to the OASIS CAP 1.1 with approved errata from October 2007, promotes CAP's use in international networks to standardize alert dissemination across diverse systems like mobile and broadcast media.[3] In March 2014, ITU-T further adopted CAP version 1.2 as Recommendation X.1303 bis, technically equivalent to the OASIS CAP 1.2.[16] By integrating CAP into ITU frameworks, it facilitates seamless emergency communications in telecommunication environments worldwide. CAP's standardization by OASIS and ITU underscores its role in enabling interoperability for cross-border emergency alerts, allowing consistent messaging across jurisdictions without proprietary barriers.[17] It aligns with the United Nations Office for Disaster Risk Reduction (UNDRR) guidelines for multi-hazard early warning systems (MHEWS), supporting end-to-end alerting that includes risk assessment, monitoring, and community response for hazards like floods and earthquakes.[18] Similarly, the World Meteorological Organization (WMO) incorporates CAP into its Technical Regulations (WMO-No. 49, 2023) to harmonize weather-related warnings, such as through platforms like MeteoAlarm for Europe-wide, multilingual alerts that enhance cross-border cooperation.[19] These alignments ensure CAP's alerts can be rapidly shared via global systems, improving response times and inclusivity for diverse populations.[20] Since CAP 1.2's release, maintenance has focused on periodic non-normative errata to address minor issues, with no major version updates introduced, preserving stability for widespread adoption.[1] Efforts have shifted toward conformance testing tools and profiles, such as the OASIS EM-TC's validation resources and WMO's CAP Composer, which verify message compliance and support integration testing across alerting systems.[21] These tools promote reliable implementation, ensuring CAP's interoperability in real-world multi-channel deployments.[19]Profiles and Extensions
Profiles represent specialized adaptations of the Common Alerting Protocol (CAP) that constrain or extend the base standard to meet regional or domain-specific needs, such as incorporating local terminology, codes, or dissemination rules while ensuring adherence to the core XML schema.[1] The OASIS Emergency CAP Profiles Subcommittee develops these variants to promote consistent implementation across alerting systems.[22] One example is the CAP DWD profile, created by the German Weather Service (Deutscher Wetterdienst, DWD), which builds on CAP v1.2 by adding syntactic extensions like mandatory event codes (e.g., "II" for event types and numeric identifiers for hazards such as 247 for strong heat) and geocode values based on the 8-digit Official Municipality Key (AGS) prefixed by administrative type (e.g., "1" for districts).[23] This profile requires Central European Time (CET/CEST) timestamps and assured elements like language and effective time to support machine-readable meteorological, health, and coastal warnings in Germany.[23] The CAP-NZ profile for New Zealand provides national guidelines for CAP deployment, defining local event types, urgency levels, and integration requirements for all-hazard public warnings across media like mobile and broadcast systems.[7] It emphasizes standardization for emergency management authorities to generate and exchange alerts compatible with international networks.[24] Common extensions to CAP include enhanced event coding via the<eventCode> element, which permits multiple system-specific schemes within a single message to describe hazards precisely, such as using domain-value pairs like <valueName>SAME</valueName><value>[SVR](/page/SVR)</value> for a severe thunderstorm.[1] For environmental hazards, extensions may draw from thesauri like the Global Environmental Multi-lingual Thesaurus (GEMET) to standardize terminology in alert descriptions.
Digital signatures represent another key extension, implemented through XML Digital Signature (XML-DSig) to provide enveloped authentication on the <alert> root element, ensuring message integrity and origin verification without altering the core structure. CAP processors must accept messages even if signatures cannot be verified, logging failures for user notification.[1]
CAP integrates with the Commercial Mobile Alert System (CMAS) by formatting alerts for geo-targeted delivery via wireless networks, as part of the U.S. Integrated Public Alert and Warning System (IPAWS), where CAP messages are validated and routed to mobile providers for imminent threat notifications.[2]
The EU-Alert profile adapts CAP for cell broadcast technology, where authorities generate CAP messages specifying event type, severity, and target areas (e.g., via ellipse-defined geofencing with latitude, longitude, and axes), which are then encoded into compact 122-bit Emergency Warning Messages for dissemination across EU member states.[25]
WMO's HydroSOS initiative extends CAP for hydrological events by supporting standardized alert generation and exchange in projects like those in Bangladesh, enabling consistent warnings for water resource status, floods, and droughts through integrated multi-hazard systems.[26]
These profiles and extensions maintain CAP's foundational interoperability by adhering to the OASIS conformance targets, which validate messages against the XML schema and optional features like signatures, allowing customized yet exchangeable alerts across global networks.[1]