Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Common Alerting Protocol.
Nothing was collected or created yet.
Common Alerting Protocol
View on Wikipediafrom Wikipedia
The Common Alerting Protocol (CAP) is an XML-based data format for exchanging public warnings and emergencies between alerting technologies. CAP allows a warning message to be consistently disseminated simultaneously over many warning systems to many applications, such as Google Public Alerts and Cell Broadcast. CAP increases warning effectiveness and simplifies the task of activating a warning for responsible officials.
Standardized alerts can be received from many sources and configure their applications to process and respond to the alerts as desired. Alerts from the Department of Homeland Security, the Department of the Interior's United States Geological Survey, and the United States Department of Commerce's National Oceanic and Atmospheric Administration (NOAA), and state and local government agencies can all be received in the same format by the same application. That application can, for example, sound different alarms, based on the information received.
By normalizing alert data across threats, jurisdictions, and warning systems, CAP also can be used to detect trends and patterns in warning activity, such as trends that might indicate an undetected hazard or hostile act. From a procedural perspective, CAP reinforces a research-based template for effective warning message content and structure.
The CAP data structure is backward-compatible with existing alert formats including the Specific Area Message Encoding (SAME) used in NOAA Weather Radio and the broadcast Emergency Alert System as well as new technology such as the Wireless Emergency Alerts (WEA), while adding capabilities such as the following:
- Flexible geographic targeting by using latitude/longitude “boxes” and other geospatial representations in three dimensions
- Multilingual and multi-audience messaging
- Phased and delayed effective times and expirations
- Enhanced message update and cancellation features
- Template support for framing complete and effective warning messages
- Digital encryption and signature capability
- Facility for digital images, audio, and video.
Background
[edit]The US National Science and Technology Council (NSTC) November 2000 report on "Effective Disaster Warnings" recommended that "standard method should be developed to collect and relay instantaneously and automatically all types of hazard warnings and reports locally, regionally and nationally for input into a wide variety of dissemination systems."[1]
In 2001, an international independent group of over 120 emergency managers that was convened online by California emergency telecommunications expert Art Botterell began specifying and prototyping the Common Alerting Protocol data structure based on the recommendations of the NSTC report. The project was embraced by the non-profit Partnership for Public Warning and a number of international warning system vendors.[2] A series of field trials and long-term demonstration projects during 2002-03 led to the submission of a draft CAP specification to the OASIS standards process for formalization.
The CAP 1.0 specification was approved by OASIS in April 2004. Based on experience with CAP 1.0, the OASIS Emergency Management Technical Committee adopted an updated CAP 1.1 specification in October 2005.[3][4] At a meeting in Geneva in October 2006 the CAP 1.1 specification was taken under consideration by the International Telecommunication Union's Standardization Sector for adoption as an ITU-T recommendation. CAP was subsequently adopted as Recommendation X.1303.[5]
CAP specification version 1.2 has been available since July 2010 at the OASIS website.[6]
Implementation
[edit]Worldwide
[edit]In 2007, the International Telecommunication Union, Telecommunication Standardization Sector (ITU-T) adopted the Common Alerting Protocol as Recommendation X.1303.[7][8] The recommendation annex contains an authoritative ASN.1 module translation of the CAP XML schema that may be useful for some implementations. Rec. X.1303 is within the remit of ITU‑T Study Group 17 (Security), Rapporteur Group on Cybersecurity (Q.4/17) for purposes of further evolution of the standard.[9]
Australia
[edit]The Australian Government Standard for Common Alerting Protocol (CAP-AU-STD, 2012) was developed by a CAP-AU-STD stakeholder group comprising federal agencies Emergency Management Australia, the Bureau of Meteorology, GeoScience Australia, Department of Agriculture, Fisheries and Forestry and the Department of Health as well as a number of State Government authorities and emergency services agencies. The project was co-ordinated by the Australian Government Attorney-General's Department (Australian Emergency Management).[10][11]
Canada
[edit]In Canada, a working group composed of public alerting practitioners and government agencies has developed a CAP Canadian Profile (CAP-CP) based on CAP but specialized to address the needs of Canadian public alerting stakeholders, such as bilingualism, geocoding for Canada, managed lists of locations and events, etc. The Canadian government has adopted CAP-CP for its National Public Alerting System (NPAS) project. The CAP‑CP working group, along with stakeholders and projects such as the Canadian Public Safety Operations Organization (CanOps) and Netalerts' Sarnia Lambton trial, are now working with and refining CAP‑CP for national application in Canada.[citation needed]
CAP has been implemented for a small-scale, grassroots hazard information system in Sri Lanka following the 2004 Indian Ocean Tsunami. This implementation was part of the "HazInfo Project", funded by Canada's International Development Research Centre.[12]
The province of Alberta adopted CAP as part of its Alberta Emergency Alert system. In March 2015, Alert Ready, a national public warning system based upon CAP-CP, was officially launched. Participation in the system by all broadcasters and television providers is mandated by the Canadian Radio-television and Telecommunications Commission.[13][14][15]
Germany
[edit]The Federal Office for Citizen Protection and Disaster Support (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe, BBK) is working on an implementation based on CAP 1.2, which will allow for Internet-based access to data provided by the nation's modular warning system MoWaS.[16] The development of MoWaS is based on the satellite-based warning system SatWaS from 2001, which only provides information to less than 150 state and media entities. In case no broadcast receiver, like a radio or television, is running nearby, the resulting warning effect of SatWaS would be severely limited, because many state-run emergency sirens have been left unmaintained or were dismantled altogether. The use of CAP support in MoWaS should alleviate this problem.
Italy
[edit]The Department of Firefighters, Public Rescue and Civil Defence (Dipartimento dei Vigili del Fuoco, del Soccorso Pubblico e della Difesa Civile ) of the Italian Ministry of the Interior adopted the CAP protocol with two Ministerial Decrees in 2008 and 2011. Since then, its 100 provincial control rooms, 18 regional control rooms and the national control centre exchange a daily average of 25,000 CAP private messages concerning rescue operations in real time. As per the decrees, any emergency stakeholder in Italy which wants to exchange or share data with the Fire Corps in the course of large scale emergency or rescue operations has to adopt the CAP protocol.
The first use of CAP protocol in a civil protection activity in Italy was recorded in 2009, in the aftermath of the Central Italy Earthquake, when the Fire Corps exchanged data with the Ministry for Cultural Heritage to coordinate their efforts in designing and implementing provisional measures for monuments and historical buildings.
On April 5, 2017, an agreement between the "Corpo Nazionale dei Vigili del Fuoco" and the "Arma dei Carabinieri" has been signed to improve the forest fire fighting activities. The interoperability of data exchange that the agreement allows is based on the use of the CAP protocol.
United States
[edit]On September 30, 2010, the Federal Emergency Management Agency (FEMA) officially adopted CAP as the protocol for its new Integrated Public Alert and Warning System (IPAWS), which is designed to disseminate emergency messages via various platforms, including broadcast media (Emergency Alert System), wireless devices (Wireless Emergency Alerts), and other platforms.[17][18]
See also
[edit]References
[edit]- ^ "Archived copy" (PDF). Archived from the original (PDF) on 2006-05-13. Retrieved 2006-05-03.
{{cite web}}: CS1 maint: archived copy as title (link) - ^ "Partnership for Public Warning". ppw.us. Archived from the original on 28 September 2002.
- ^ "OASIS - Committees - OASIS Emergency Management TC". Archived from the original on 2003-02-07.
- ^ Common Alerting Protocol, v. 1.1 oasis-open.org
- ^ "X.1303 : Common alerting protocol (CAP 1.1)". International Telecommunication Union. Retrieved 2019-04-30.
- ^ Common Alerting Protocol Version 1.2 oasis-open.org
- ^ "ITU Telecommunication Standardization Sector". ITU.
- ^ tsbmail. "X.1303 : Common alerting protocol (CAP 1.1)". itu.int.
- ^ "ITU-T Study Group 17 (Study Period 2013-2016)". itu.int.
- ^ "Emergency Management Capabilities - Attorney General's Department". ag.gov.au. Archived from the original on 2018-01-15. Retrieved 2018-01-15.
- ^ "Common Alerting Protocol – Australia (CAP-AU-STD) - Data.gov.au". data.gov.au.
- ^ "Evaluating Last-Mile Hazard Information Dissemination (HazInfo)". lirneasia.net. Archived from the original on 2007-07-09. Retrieved 2007-01-31.
- ^ "Public Alerting Bulletin to Last Mile Distributors" (PDF). Pelmorex. Archived from the original (PDF) on 6 May 2015. Retrieved 9 June 2015.
- ^ "Alberta emergency system goes digital". CBC News. Retrieved 9 June 2015.
- ^ "Digital alert system hard to decipher: critics". CBC News. Retrieved 9 June 2015.
- ^ "Bundesamt für Bevölkerungsschutz und Katastrophenhilfe - Warnmultiplikatoren".
- ^ Oxenford, Davis Wright Tremaine LLP-David D.; Tol, Jennifer; Frewer (10 February 2012). "FCC revises emergency alert system rules; reminds participants of June 30, 2012 CAP compliance deadline". Lexology.com. Retrieved 2019-08-24.
- ^ "FEMA Adopts Digital Message Format for EAS CAP Standard, Triggering 180-Day Clock for Compliance". Broadcast Law Blog. 2010-09-30. Retrieved 2019-08-24.
External links
[edit]Common Alerting Protocol
View on Grokipediafrom Grokipedia
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]
elements within a single alert message, each specified with a language code compliant with RFC 3066 (e.g., "en-US" for American English or "es-US" for American Spanish). This allows the same alert to convey instructions in diverse languages, accommodating multicultural populations without requiring separate messages. Additionally, the protocol includes provisions for digital signatures applied to the entire element using XML-Signature standards, ensuring message authenticity and integrity against tampering. For richer content, CAP's element facilitates attachments of multimedia such as images (e.g., GIF or JPEG), audio files, or video streams, referenced via URI with MIME types to support visual and auditory aids in warnings.[8]
The protocol enables phased alerting through optional and timestamps to control the validity period of an alert, alongside values like "Update" or "Ack" for modifying or canceling prior messages, allowing dynamic management of evolving situations. Priority is further refined using three enumerated attributes in the element: urgency (Immediate, Expected, Future, Past, or Unknown) to indicate time sensitivity; severity (Extreme, Severe, Moderate, Minor, or Unknown) to assess impact magnitude; and certainty (Observed, Likely, Possible, Unlikely, or Unknown) to gauge event probability. These features collectively support structured, adaptable alerting processes.[8]
Among its primary benefits, CAP promotes interoperability by providing a standardized XML-based format that enables a single alert to trigger multiple dissemination channels, including broadcast media, cell broadcasts, social media, and mobile applications, thereby expanding reach without custom integrations. This reuse of messages across systems reduces operational costs and complexity for emergency managers, as one CAP document can serve diverse warning infrastructures rather than requiring bespoke formats. Furthermore, the protocol's emphasis on clear, actionable elements—such as geospatial precision and multimedia—enhances public response by delivering targeted, comprehensible instructions that facilitate timely protective actions.[8][2]
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 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</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]