of 47
8/2/2019 (Oasis)Cap v1.2
1/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 1 of 47
Common Alerting Protocol Version 1.2OASIS Standard
01 July 2010Specification URIs:This Version:
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.doc (Authoritative)
Previous Version:http://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.doc (Authoritative)
Latest Version:http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.doc (Authoritative)
Technical Committee:OASIS Emergency Management TC
Chair:Elysa Jones, Warning Systems, Inc.
Editor:Jacob Westfall, Individual
Related work:This specification is related to:
OASIS Standard CAP-V1.1, October 2005 http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf OASIS Standard CAP-V1.1 , Approved Errata October 2007 http://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdf
Declared XML Namespace:urn:oasis:names:tc:emergency:cap:1.2
Abstract:The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazardemergency alerts and public warnings over all kinds of networks. CAP allows a consistentwarning message to be disseminated simultaneously over many different warning systems, thusincreasing warning effectiveness while simplifying the warning task. CAP also facilitates thedetection of emerging patterns in local warnings of various kinds, such as might indicate anundetected hazard or hostile act. And CAP provides a template for effective warning messagesbased on best practices identified in academic research and real-world experience.
Status:This document was last revised or approved by the Emergency Management TC on the abovedate. The level of approval is also listed above. Check the Latest Version or Latest ApprovedVersion location noted above for possible later revisions of this document.
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.dochttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.dochttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.dochttp://www.oasis-open.org/committees/emergencyhttp://www.oasis-open.org/committees/emergencyhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://docs.oasis-open.org/emergency/cap/v1.1/errata/CAP-v1.1-errata.pdfhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdfhttp://www.oasis-open.org/committees/emergencyhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.dochttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.dochttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/cs01/CAP-v1.2-cs01.htmlhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.dochttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdfhttp://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html8/2/2019 (Oasis)Cap v1.2
2/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 2 of 47
Technical Committee members should send comments on this specification to the TechnicalCommittees email list. Others should send comments to the Technical Committee by using theSend A Comment button on the Technical Committees web page at http://www.oasis-open.org/committees/emergency/.
For information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/emergency/ipr.php .
The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/emergency/.
http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/ipr.phphttp://www.oasis-open.org/committees/emergency/http://www.oasis-open.org/committees/emergency/8/2/2019 (Oasis)Cap v1.2
3/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 3 of 47
NoticesCopyright OASIS 2010. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS IntellectualProperty Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works thatcomment on or otherwise explain it or assist in its implementation may be prepared, copied, published,and distributed, in whole or in part, without restriction of any kind, provided that the above copyright noticeand this section are included on all such copies and derivative works. However, this document itself maynot be modified in any way, including by removing the copyright notice or references to OASIS, except asneeded for the purpose of developing any document or deliverable produced by an OASIS TechnicalCommittee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, mustbe followed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successorsor assigns.This document and the information contained herein is provided on an "AS IS" basis and OASISDISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANYOWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that wouldnecessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard,to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses tosuch patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee thatproduced this specification.OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership ofany patent claims that would necessarily be infringed by implementations of this specification by a patentholder that is not willing to provide a license to such patent claims in a manner consistent with the IPRMode of the OASIS Technical Committee that produced this specification. OASIS may include suchclaims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the implementation or use of the technology described in this document orthe extent to which any license under such rights might or might not be available; neither does itrepresent that it has made any effort to identify any such rights. Information on OASIS' procedures withrespect to rights in any document or deliverable produced by an OASIS Technical Committee can befound on the OASIS website. Copies of claims of rights made available for publication and anyassurances of licenses to be made available, or the result of an attempt made to obtain a general licenseor permission for the use of such proprietary rights by implementers or users of this OASIS CommitteeSpecification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes norepresentation that any information or list of intellectual property rights will at any time be complete, orthat any claims in such list are, in fact, Essential Claims.The names "OASIS" and CAP are trademarks of OASIS , the owner and developer of this specification,and should be used only to refer to the organization and its official outputs. OASIS welcomes referenceto, and implementation and use of, specifications, while reserving the right to enforce its marks againstmisleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/who/trademark.phphttp://www.oasis-open.org/who/trademark.phphttp://www.oasis-open.org/who/trademark.phphttp://www.oasis-open.org/who/trademark.phphttp://www.oasis-open.org/8/2/2019 (Oasis)Cap v1.2
4/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 4 of 47
Table of Contents1 Introduction ........................................................................................................................................... 6
1.1 Purpose ............................................................................................................................................ 6 1.2 History .............................................................................................................................................. 6 1.3 Structure of the CAP Alert Message ................................................................................................. 7
1.3.1 ....................................................................................................................................... 7 1.3.2 ........................................................................................................................................ 7 1.3.3 ................................................................................................................................ 7 1.3.4 ....................................................................................................................................... 7
1.4 Applications of the CAP Alert Message ............................................................................................ 7 1.5 Terminology ...................................................................................................................................... 8 1.6 Normative References ...................................................................................................................... 8
2 Design Principles and Concepts (non-normative) ................................................................................. 9 2.1 Design Philosophy ............................................................................................................................ 9
2.2 Requirements for Design .................................................................................................................. 9
2.3 Examples of Use Scenarios ............................................................................................................ 10 2.3.1 Manual Origination .................................................................................................................. 10 2.3.2 Automated Origination by Autonomous Sensor System .......................................................... 10 2.3.3 Aggregation and Correlation on Real-time Map....................................................................... 10 2.3.4 Integrated Public Alerting ........................................................................................................ 11 2.3.5 Repudiating a False Alarm ...................................................................................................... 11
3 Alert Message Structure (normative) .................................................................................................. 12 3.1 Document Object Model ................................................................................................................. 12 3.2 Data Dictionary ............................................................................................................................... 13
3.2.1 "alert" Element and Sub-elements ........................................................................................... 13
3.2.2 "info" Element and Sub-elements ............................................................................................ 16 3.2.3 "resource" Element and Sub-elements .................................................................................... 23 3.2.4 "area" Element and Sub-elements ........................................................................................... 24
3.3 Implementation Notes ......................................................................................................................273.3.1 WGS 84 Note .......................................................................................................................... 273.3.2 DateTime Data Type ............................................................................................................... 273.3.3 Character Entity References.................................................................................................... 273.3.4 Security Note ........................................................................................................................... 27
3.3.4.1 Digital Signatures ............................................................................................................. 273.4 XML Schema .................................................................................................................................. 283.5 Use of ASN.1 to Specify and Encode the CAP Alert Message ....................................................... 32
3.5.1 General .................................................................................................................................... 323.5.2 Formal Mappings and Specification ......................................................................................... 323.5.3 ASN.1 Schema ........................................................................................................................ 32
4 Conformance (normative) ................................................................................................................... 37 4.1 Conformance Targets ..................................................................................................................... 374.2 Conformance as a CAP V1.2 Message .......................................................................................... 37 4.3 Conformance as a CAP V1.2 Message Producer ........................................................................... 37 4.4 Conformance as a CAP V1.2 Message Consumer ......................................................................... 38
8/2/2019 (Oasis)Cap v1.2
5/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 5 of 47
Appendix A. CAP Alert Message Example................................................................................................ 39 A.1. Homeland Security Advisory System Alert .................................................................................... 39 A.2. Severe Thunderstorm Warning ..................................................................................................... 40 A.3. Earthquake Report (Update Message) .......................................................................................... 41 A.4. AMBER Alert (Multilingual Message) ............................................................................................ 42
Appendix B. Acknowledgments ................................................................................................................. 43 OASIS Emergency Management Technical Committee ....................................................................... 43 Appendix C. Revision History .................................................................................................................... 45
8/2/2019 (Oasis)Cap v1.2
6/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 6 of 47
1 Introduction1
1.1 Purpose2The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all3types of alerts and notifications. It does not address any particular application or telecommunications4method. The CAP format is compatible with emerging techniques, such as Web services, as well as5existing formats including the Specific Area Message Encoding (SAME) used for the United States6National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert7System (EAS), while offering enhanced capabilities that include:8
Flexible geographic targeting using latitude/longitude shapes and other geospatial9representations in three dimensions;10
Multilingual and multi-audience messaging;11
Phased and delayed effective times and expirations;12
Enhanced message update and cancellation features;13
Template support for framing complete and effective warning messages;14Compatible with digital signature capability; and,15
Facility for digital images and audio.16
Key benefits of CAP will include reduction of costs and operational complexity by eliminating the need for17multiple custom software interfaces to the many warning sources and dissemination systems involved in18all-hazard warning . The CAP message format can be converted to and from the native formats of all19kinds of sensor and alerting technologies, forming a basis for a technology-independent national and20international warning internet. 21
1.2 History22The National Science and Techno logy Council report on Effective Disaster Warnings released in23November, 2000 recommended that a standard method should be developed to collect and relay24instantaneously and automatically all types of hazard warnings and reports locally, regionally and25nationally for input into a wide variety of dissemination systems. 26An international working group of more than 130 emergency managers and information technology and27telecommunications experts convened in 2001 and adopted the specific recommendations of the NSTC28report as a point of departure for the design of a Common Alerting Protocol (CAP). Their draft went29through several revisions and was tested in demonstrations and field trials in Virginia (supported by the30ComCARE Alliance) and in California (in cooperation with the California Office of Emergency Services)31during 2002 and 2003.32In 2002 the CAP initiative was endorsed by the national non-profit Partnership for Public Warning, which33sponsored its contribution in 2003 to the OASIS standards process. In 2004, CAP version 1.0 was34adopted as an OASIS Standard. In 2005, changes based on user feedback were incorporated into CAP35
and version 1.1 was released. As part of the International Telecommunication Union (ITU-T) adoption of36 CAP, a CAP 1.1 Errata was released in 2007 to support ASN.1 encoding. Version 1.2 is a minor release37to resolve issues identified by the EM-TC CAP Call for Comments initiated in April 2008 and also38incorporates feedback from CAP profile development efforts.39
40
41
8/2/2019 (Oasis)Cap v1.2
7/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 7 of 47
1.3 Structure of the CAP Alert Message42Each CAP Alert Message consists of an segment, which may contain one or more 43segments, each of which may include one or more and/or segments. Under most44circumstances CAP messages with a value of Alert SHOULD include at least one 45element. (See the document object model diagram in section 3.1, below.)46
1.3.1 47The segment provides basic information about the current message: its purpose, its source and48its status, as well as a unique identifier for the current message and links to any other, related messages.49An segment may be used alone for message acknowledgements, cancellations or other system50functions, but most segments will include at least one segment.51
1.3.2 52The segment describes an anticipated or actual event in terms of its urgency (time available to53prepare), severity (intensity of impact) and certainty (confidence in the observation or prediction), as well54as providing both categorical and textual descriptions of the subject event. It may also provide55instructions for appropriate response by message recipients and various other details (hazard duration,56
technical parameters, contact information, links to additional information sources, etc.) Multiple 57 segments may be used to describe differing parameters (e.g., for different probability or intensity bands)58or to provide the information in multiple languages.59
1.3.3 60The segment provides an optional reference to additional information related to the 61segment within which it appears in the form of a digital asset such as an image or audio file.62
1.3.4 63The segment describes a geographic area to which the segment in which it appears64applies. Textual and coded descriptions (such as postal codes) are supported, but the preferred65representations use geospatial shapes (polygons and circles) and an altitude or altitude range, expressed66in standard latitude / longitude / altitude terms in accordance with a specified geospatial datum.67
1.4 Applications of the CAP Alert Message68The primary use of the CAP Alert Message is to provide a single input to activate all kinds of alerting and69public warning systems. This reduces the workload associated with using multiple warning systems while70enhancing technical reliability and target-audience effectiveness. It also helps ensure consistency in the71information transmitted over multiple delivery systems, another key to warning effectiveness.72A secondary application of CAP is to normalize warnings from various sources so they can be aggregated73and compared in tabular or graphic form as an aid to situational awareness and pattern detection.74Although primarily designed as an interoperability standard for use among warning systems and other75emergency information systems, the CAP Alert Message can be delivered directly to alert recipients over76
various networks, including data broadcasts. Location-aware receiving devices could use the information77 in a CAP Alert Message to determine, based on their current location, whether that particular message78was relevant to their users.79
The CAP Alert Message can also be used by sensor systems as a format for reporting significant events80to collection and analysis systems and centers.81
82
8/2/2019 (Oasis)Cap v1.2
8/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 8 of 47
1.5 Terminology83The k ey words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD84NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described85in [RFC2119] . 86
The words warning , alert and notification are used interchangeably throughout this document.87
The term coordinate pair is used in this document to refer to a comma -delimited pair of decimal values88describing a geospatial location in degrees, unprojected, in the form [latitude],[longitude]. Latitud es in89the Southern Hemisphere and longitudes in the Western Hemisphere are signed negative by means of a90leading dash.91
1.6 Normative References92[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels ,93
http://www.ietf.org/rfc/rfc2119.txt , IETF RFC 2119, March 1997.94[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition,95
http://www.w3.org/TR/xmlschema-2/#dateTime , W3C REC-xmlschema-2,96October 2004.97
[FIPS 180-2] National Institute for Standards and Technology, Secure Hash Standard,98http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf , 99August 2002.100
[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/ , W3C101REC-xml-names-19990114, January 1999.102
[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,103http://www.ietf.org/rfc/rfc2046.txt , IETF RFC 2046, November 1996.104
[RFC3066] H. Alvestrand, Tags for the Identification of Languages,105http://www.ietf.org/rfc/rfc3066.txt , IETF RFC 3066, January 2001.106
[WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic107System 1984, http://earth-info.nga.mil/GandG/tr8350_2.html , NGA Technical108Report TR8350.2, January 2000.109
[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition),110
http://www.w3.org/TR/REC-xml/ , W3C REC-XML-20040204, February 2004.111[XMLSIG] Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Signature Syntax and 112
Processing , http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ , W3C113Recommendation, February 2002. 114
[ITU-T X.680] ITU-T Recommendation X.680, Information technology Abstract Syntax 115Notation One (ASN.1): Specification of basic notation .116
[ITU-T X.691] ITU-T Recommendation X.691, Information technology ASN.1 encoding rules: 117Specification of Packed Encoding Rules (PER) .118
[ITU-T X.693] ITU-T Recommendation X.693, Information technology ASN.1 encoding rules: 119Specification of XML Encoding Rules (XER) .120
[ITU-T X.694] ITU-T Recommendation X.694, Information technology ASN.1 encoding rules: 121Mapping W3C XML schema definitions into ASN.1 .122
123
http://www.ietf.org/rfc/rfc2119.txthttp://www.ietf.org/rfc/rfc2119.txthttp://www.w3.org/TR/xmlschema-2/#dateTimehttp://www.w3.org/TR/xmlschema-2/#dateTimehttp://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfhttp://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfhttp://www.w3.org/TR/REC-xml-names/http://www.w3.org/TR/REC-xml-names/http://www.w3.org/TR/REC-xml-names/http://www.ietf.org/rfc/rfc2046.txthttp://www.ietf.org/rfc/rfc2046.txthttp://www.ietf.org/rfc/rfc3066.txthttp://www.ietf.org/rfc/rfc3066.txthttp://earth-info.nga.mil/GandG/tr8350_2.htmlhttp://earth-info.nga.mil/GandG/tr8350_2.htmlhttp://earth-info.nga.mil/GandG/tr8350_2.htmlhttp://www.w3.org/TR/REC-xml/http://www.w3.org/TR/REC-xml/http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/http://www.w3.org/TR/REC-xml/http://earth-info.nga.mil/GandG/tr8350_2.htmlhttp://www.ietf.org/rfc/rfc3066.txthttp://www.ietf.org/rfc/rfc2046.txthttp://www.w3.org/TR/REC-xml-names/http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfhttp://www.w3.org/TR/xmlschema-2/#dateTimehttp://www.ietf.org/rfc/rfc2119.txt8/2/2019 (Oasis)Cap v1.2
9/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 9 of 47
2 Design Principles and Concepts (non-normative)124
2.1 Design Philosophy125Among the principles which guided the design of the CAP Alert Message were:126
Interoperability First and foremost, the CAP Alert Message should provide a means for127interoperable exchange of alerts and notifications among all kinds of emergency information128systems.129
Completeness The CAP Alert Message format should provide for all the elements of an130effective public warning message.131
Simple implementation The design should not place undue burdens of complexity on132technical implementers.133
Simple XML and portable structure Although the primary anticipated use of the CAP Alert134Message is as an XML document, the format should remain sufficiently abstract to be adaptable135to other coding schemes.136
Multi-use format One message schema supports multiple message types (e.g., alert / update / 137cancellations / acknowledgements / error messages) in various applications (actual / exercise / 138test / system message).139
Familiarity The data elements and code values should be meaningful to warning originators140and non-expert recipients alike.141
Interdisciplinary and international utility The design should allow a broad range of142applications in public safety and emergency management and allied applications and should be143applicable worldwide.144
2.2 Requirements for Design145Note: The following requirements were used as a basis for design and review of the CAP146
Alert Message format. This list is non-normative and not intended to be exhaustive.147The Common Alerting Protocol SHOULD:148
Provide a specification for a simple, extensible format for digital representation of warning149messages and notifications;150
Enable integration of diverse sensor and dissemination systems;151
Be usable over multiple transmission systems, including both TCP/IP-based networks and one-152way "broadcast" channels;153
Support credible end-to-end authentication and validation of all messages;154
Provide a unique identifier (e.g., an ID number) for each warning message and for each message155originator;156
Provide for multiple message types, such as:157
Warnings158
Acknowledgements159 Expirations and cancellations160
Updates and amendments161 Reports of results from dissemination systems162
Administrative and system messages163
Provide for multiple message types, such as:164
8/2/2019 (Oasis)Cap v1.2
10/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 10 of 47
Geographic targeting165 Level of urgency166
Level of certainty167 Level of threat severity168
Provide a mechanism for referencing supplemental information (e.g., digital audio or image files,169
additional text);170Use an established open-standard data representation;171
Be based on a program of real-world cross-platform testing and evaluation;172
Provide a clear basis for certification and further protocol evaluation and improvement; and,173
Provide a clear logical structure that is relevant and clearly applicable to the needs of emergency174response and public safety users and warning system operators.175
2.3 Examples of Use Scenarios176Note: The following examples of use scenarios were used as a basis for design and177review of the CAP Alert Message format. These scenarios are non-normative and not178intended to be exhaustive or to reflect actual practices.179
2.3.1 Manual Origination180The Incident Commander at an industrial fire with potential of a major explosion decides to issue a public181alert with three components: a) An evacuation of the area within half a mile of the fire; b) a shelter-in-182place instruction for people in a polygon roughly describing a downwind dispersion plume extending183several miles downwind and half a mile upwind from the fire; and c) a request for all media and civilian184aircraft to remain above 2500 feet above ground level when within a half mile radius of the fire.185Using a portable computer and a web page (and a pop-up drawing tool to enter the polygon) the Incident186Commander issues the alert as a CAP message to a local alerting network.187
2.3.2 Automated Origination by Autonomous Sensor System188
A set of automatic tsunami warning sirens has been installed along a popular Northwest beach. A189wireless network of sensor devices collocated with the sirens controls their activation. When triggered,190each sensor generates a CAP message containing its location and the sensed data at that location that is191needed for the tsunami determination. Each siren activates when the combination of its own readings and192those reported at by other devices on the network indicate an immediate tsunami threat. In addition, a193network component assembles a summary CAP message describing the event and feeds it to regional194and national alerting networks.195
2.3.3 Aggregation and Correlation on Real-time Map196At the State Operations Center a computerized map of the state depicts, in real time, all current and197recent warning activity throughout the state. All major warning systems in the state the Emergency198Alert System, siren systems, telephone alerting and other systems have been equipped to report the199
details of their activation in the form of a CAP message. (Since many of them are now activated by way200 of CAP messages, this is frequently just a matter of forwarding the activation message to the state201center.)202Using this visualization tool, state officials can monitor for emerging patterns of local warning activity and203correlate it with other real time data (e.g., telephone central office traffic loads, 9-1-1 traffic volume,204seismic data, automatic vehicular crash notifications, etc.).205
206
8/2/2019 (Oasis)Cap v1.2
11/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 11 of 47
2.3.4 Integrated Public Alerting207As part of an integrated warning system funded by local industry, all warning systems in a community can208be activated simultaneously by the issuance, from an authorized authority, of a single CAP message.209
Each system converts the CAP message data into the form suitable for its technology (text captioning on210TV, synthesized voice on radio and telephone, activation of the appropriate signal on sirens, etc.).
211
Systems that can target their messages to particular geographic areas implement the targeting specified212 in the CAP message with as little spillover as their technology permits. 213
In this way, not only is the reliability and reach of the overall warning system maximized, but citizens also214get corroboration of the alert through multiple channels, which increases the chance of the warning being215acted upon.216
2.3.5 Repudiating a False Alarm217Inadvertently the integrated alerting network has been activated with an inaccurate warning message.218This activation comes to officials' attention immediately through their own monitoring facilities (e.g., 2.3.3219above). Having determined that the alert is, in fact, inappropriate, the officials issue a cancellation220message that refers directly to the erroneous prior alert. Alerting systems that are still in the process of221delivering the alert (e.g., telephone dialing systems) stop doing so. Broadcast systems deliver the222
cancellation message. Other systems (e.g., highway signs) simply reset to their normal state.223
8/2/2019 (Oasis)Cap v1.2
12/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 12 of 47
3 Alert Message Structure (normative)224
3.1 Document Object Model225
226227
8/2/2019 (Oasis)Cap v1.2
13/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 13 of 47
228
3.2 Data Dictionary229Note: Unless explicitly constrained within this Data Dictionary or the XML Schema230(Section 3.4), CAP elements MAY have null values. Implementers MUST check for this231condition wherever it might affect application performance.232
233
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
3.2.1 "alert" Element and Sub-elements
alert cap.
alert.group
The containerfor allcomponent
parts of thealert message(REQUIRED)
(1) Surrounds CAP alert message sub-elements.
(2) MUST include the xmlns attributereferencing the CAP URN as thenamespace, e.g.:
[sub-elements]
(3) In addition to the specified sub-elements, MAY contain one or more blocks.
identifier cap.
alert.identifier.
identifier
The identifierof the alert
message(REQUIRED)
(1) A number or string uniquely identifyingthis message, assigned by the sender.
(2) MUST NOT include spaces, commas orrestricted characters (< and &).
sender cap.alert.
sender.identifier
The identifierof the senderof the alertmessage(REQUIRED)
(1) Identifies the originator of this alert.Guaranteed by assigner to be uniqueglobally; e.g., may be based on anInternet domain name.
(2) MUST NOT include spaces, commas orrestricted characters (< and &).
sent cap.
alert.sent.
time
The time and
date of theorigination ofthe alertmessage(REQUIRED)
(1) The date and time SHALL be
represented in the DateTime Data Type(See Implementation Notes) format (e.g.,"2002-05-24T16:49:00-07:00 " for 24May 2002 at 16:49 PDT).(2) Alphabetic timezone designators suchas Z MUST NOT be used. The timezonefor UTC MUST be represe nted as -00:00.
8/2/2019 (Oasis)Cap v1.2
14/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 14 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
status cap.
alert.status.code
The code
denoting theappropriatehandling ofthe alertmessage(REQUIRED)
Code Values:
Actual - Actionable by all targetedrecipientsExercise - Actionable only by designatedexercise participants; exercise identifierSHOULD appear in
System - For messages that supportalert network internal functions
Test - Technical testing only, allrecipients disregard
Draft A preliminary template or draft,not actionable in its current form
msgType cap.
alert.msgType.
code
The codedenoting thenature of thealert message(REQUIRED)
Code Values:
Alert - Initial information requiringattention by targeted recipients
Update - Updates and supercedes theearlier message(s) identified inCancel - Cancels the earlier message(s)identified in Ack - Acknowledges receipt andacceptance of the message(s) identified in
Error - Indicates rejection of themessage(s) identified in ;explanation SHOULD appear in
source cap.alert.
source.identifier
The textidentifying thesource of thealert message(OPTIONAL)
The particular source of this alert; e.g., anoperator or a specific device.
scope cap.
alert.scope.
code
The codedenoting the
intendeddistribution ofthe alertmessage(REQUIRED)
Code Values:
Public - For general dissemination tounrestricted audiencesRestricted - For dissemination only tousers with a known operationalrequirement (see , below)Private - For dissemination only tospecified addresses (see ,below)
8/2/2019 (Oasis)Cap v1.2
15/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 15 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
restriction cap.
alert.restriction.text
The text
describing therule for limitingdistribution ofthe restrictedalert message(CONDITIONAL )
Used when value is "Restricted".
addresses cap.alert.
addresses.group
The grouplisting ofintendedrecipients ofthe alertmessage
(CONDITIONAL )
(1) Required when is Private,optional when is Public or Restricted.
(2) Each recipient SHALL be identified byan identifier or an address.
(3) Multiple space-delimited addressesMAY be included. Addresses includingwhitespace MUST be enclosed indouble-quotes.
code cap.alert.code.code
The codedenoting thespecialhandling of thealert message(OPTIONAL)
(1) Any user-defined flag or special codeused to flag the alert message forspecial handling.
(2) Multiple instances MAY occur.
note cap.
alert.note.
text
The textdescribing thepurpose orsignificance ofthe alertmessage(OPTIONAL)
The message note is primarily intended foruse with Exercise and Error.
references cap.
alert.references.
group
The grouplistingidentifyingearliermessage(s)
referenced bythe alertmessage(OPTIONAL)
(1) The extended message identifier(s) (inthe form sender,identifier,sent) of anearlier CAP message or messagesreferenced by this one.
(2) If multiple messages are referenced,
they SHALL be separated bywhitespace.
8/2/2019 (Oasis)Cap v1.2
16/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 16 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
incidents cap.
alert.incidents.group
The group
listing namingthe referentincident(s) ofthe alertmessage(OPTIONAL)
(1) Used to collate multiple messages
referring to different aspects of thesame incident.(2) If multiple incident identifiers are
referenced, they SHALL be separatedby whitespace. Incident namesincluding whitespace SHALL besurrounded by double-quotes.
3.2.2 "info" Element and Sub-elements
info cap.
alertInfo.info.group
The container
for allcomponentparts of the infosub-element ofthe alertmessage(OPTIONAL)
(1) Multiple occurrences are permitted
within a single . If targeting ofmultiple blocks in the samelanguage overlaps, information in laterblocks may expand but may notoverride the corresponding values inearlier ones. Each set of blockscontaining the same language identifierSHALL be treated as a separatesequence.
(2) In addition to the specified sub-elements, MAY contain one or more blocks and/or one or more blocks.
language cap.
alertInfo.language.
code
The codedenoting thelanguage of theinfo sub-element of thealert message(OPTIONAL)
(1) Code Values: Natural languageidentifier per [RFC 3066].
(2) If not present, an implicit default valueof "en-US" SHALL be assumed.
(3) A null value in this element SHALL beconsidered equivalent to en -US.
8/2/2019 (Oasis)Cap v1.2
17/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 17 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
category cap.
alertInfo.category.code
The code
denoting thecategory ofthe subjectevent of thealert message(REQUIRED)
(1) Code Values:
Geo - Geophysical (inc. landslide)Met - Meteorological (inc. flood)Safety - General emergency and publicsafetySecurity - Law enforcement, military,homeland and local/private securityRescue - Rescue and recovery
Fire - Fire suppression and rescueHealth - Medical and public health
Env - Pollution and other environmental
Transport - Public and privatetransportationInfra - Utility, telecommunication, othernon-transport infrastructureCBRNE Chemical, Biological,Radiological, Nuclear or High-YieldExplosive threat or attack
Other - Other events(2) Multiple instances MAY occur within an
block.
event cap.alertInfo.
event.text
The textdenoting thetype of thesubject eventof the alertmessage(REQUIRED)
8/2/2019 (Oasis)Cap v1.2
18/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 18 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
responseType cap.
alertInfo.responseType.code
The code
denoting thetype of actionrecommendedfor the targetaudience(OPTIONAL)
(1) Code Values:
Shelter Take shelter in place or perEvacuate Relocate as instructed in thePrepare Make preparations per theExecute Execute a pre-planned activityidentified in Avoid Avoid the subject event as perthe Monitor Attend to information sources
as described in Assess Evaluate the information in thismessage. (This value SHOULD NOT beused in public warning applications.)
AllClear The subject event no longerposes a threat or concern and any followon action is described in None No action recommended
(2) Multiple instances MAY occur within an block.
urgency cap.
alertInfo.urgency.code
The codedenoting theurgency of thesubject eventof the alertmessage(REQUIRED)
(1) The , , and elements collectively distinguishless emphatic from more emphaticmessages.(2) Code Values:
Immediate - Responsive actionSHOULD be taken immediately
Expected - Responsive action SHOULDbe taken soon (within next hour)
Future - Responsive action SHOULD betaken in the near future
Past - Responsive action is no longer
requiredUnknown - Urgency not known
8/2/2019 (Oasis)Cap v1.2
19/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 19 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
severity cap.
alertInfo.severity.code
The code
denoting theseverity of thesubject eventof the alertmessage(REQUIRED)
(1) The , , and
elements collectively distinguishless emphatic from more emphaticmessages.
(2) Code Values:Extreme - Extraordinary threat to life orpropertySevere - Significant threat to life orpropertyModerate - Possible threat to life orpropertyMinor Minimal to no known threat tolife or propertyUnknown - Severity unknown
certainty cap.
alertInfo.certainty.code
The codedenoting thecertainty ofthe subjectevent of thealert message(REQUIRED)
(1) The , , and elements collectively distinguishless emphatic from more emphaticmessages.(2) Code Values:
Observed Determined to haveoccurred or to be ongoing
Likely - Likely (p > ~50%)Possible - Possible but not likely (p
8/2/2019 (Oasis)Cap v1.2
20/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 20 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
eventCode cap.
alertInfo.eventCode.code
A system-
specific codeidentifying theevent type ofthe alertmessage(OPTIONAL)
(1) Any system-specific code for event
typing, in the form:
valueName
value
where the content of valueName is a user -assigned string designating the domain ofthe code, and the content of value is astring (which may represent a number)denoting the value itself (e.g., valueName="SAME" and value=" CEM").
(2) Values of valueName that areacronyms SHOULD be represented in allcapital letters without periods (e.g., SAME,FIPS, ZIP).
(3) Multiple instances MAY occur within an block.
effective cap.
alertInfo.effective.time
The effectivetime of theinformation ofthe alertmessage(OPTIONAL)
(1) The date and time SHALL berepresented in the DateTime Data Type(See Implementation Notes) format (e.g.,2002-05-24T16:49:00-07:00 for 24May 2002 at 16: 49 PDT).(2) Alphabetic timezone designators suchas Z MUST NOT be used. The timezonefor UTC MUST be represented as -00:00.
(3) If this item is not included, the effectivetime SHALL be assumed to be the same asin .
onset cap.alertInfo.
onset.time
The expectedtime of thebeginning ofthe subjectevent of thealert message
(OPTIONAL)
(1) The date and time SHALL berepresented in the DateTime Data Type(See Implementation Notes) format (e.g.,2002-05-24T16:49:00-07:00 for 24May 2002 at 16: 49 PDT).
(2) Alphabetic timezone designators suchas Z MUST NOT be used. The timezonefor UTC MUST be represented as -00:00.
8/2/2019 (Oasis)Cap v1.2
21/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 21 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
expires cap.
alertInfo.expires.time
The expiry time
of theinformation ofthe alertmessage(OPTIONAL)
(1) The date and time SHALL be
represented in the DateTime Data Type(See Implementation Notes) format (e.g.,2002-05-24T16:49:00-07:00 for 24May 2002 at 16:49 PDT).(2) Alphabetic timezone designators suchas Z MUST NOT be used. The timezonefor UTC MUST be represented as -00:00.
(3) If this item is not provided, eachrecipient is free to set its own policy as towhen the message is no longer in effect.
senderName cap.
alertInfo.senderName.text
The text
naming theoriginator of thealert message(OPTIONAL)
The human-readable name of the agency or
authority issuing this alert.
headline cap.
alertInfo.headline.
text
The textheadline of thealert message(OPTIONAL)
A brief human-readable headline. Note thatsome displays (for example, shortmessaging service devices) may onlypresent this headline; it SHOULD be madeas direct and actionable as possible whileremaining short. 160 characters MAY be auseful target limit for headline length.
description cap.
alertInfo.description.
text
The textdescribing thesubject eventof the alertmessage(OPTIONAL)
An extended human readable description ofthe hazard or event that occasioned thismessage.
instruction cap.alertInfo.
instruction.text
The textdescribing therecommendedaction to betaken by
recipients ofthe alertmessage(OPTIONAL)
An extended human readable instruction totargeted recipients. If different instructionsare intended for different recipients, theyshould be represented by use of multiple blocks.
8/2/2019 (Oasis)Cap v1.2
22/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 22 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
web cap
alertInfo.web.identifier
The identifier of
the hyperlinkassociatingadditionalinformationwith the alertmessage(OPTIONAL)
A full, absolute URI for an HTML page or
other text resource with additional orreference information regarding this alert.
contact cap.
alertInfo.contact.
text
The textdescribing thecontact forfollow-up andconfirmation of
the alertmessage(OPTIONAL)
parameter cap.alertInfo.
parameter.code
A system-specificadditionalparameterassociated withthe alertmessage(OPTIONAL)
(1) Any system-specific datum, in the form:
valueName
value
where the content of valueName is auser-assigned string designating thedomain of the code, and the content ofvalue is a string (which may represent anumber) denoting the value itself (e.g.,valueName =" SAME" and value=" CIV").
(2) Values of valueName that areacronyms SHOULD be represented in allcapital letters without periods (e.g., SAME,FIPS, ZIP).(3) Multiple instances MAY occur within an block.
8/2/2019 (Oasis)Cap v1.2
23/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 23 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
3.2.3 "resource" Element and Sub-elements
resource cap
alertInfoResource.resource.group
The containerfor allcomponentparts of theresource sub-element of theinfo sub-element of thealert element(OPTIONAL)
(1) Refers to an additional file withsupplemental information related to this element; e.g., an image or audio file.
(2) Multiple instances MAY occur within an block.
resourceDesc cap.alertInfoResource.resourceDesc.text
The textdescribing thetype andcontent of theresource file(REQUIRED)
The human-readable text describing thetype and content, such as map or photo,of the resource file.
mimeType cap.
alertInfoResource.mimeType.
identifier
The identifierof the MIMEcontent typeand sub-typedescribing the
resource file(REQUIRED)
MIME content type and sub-type asdescribed in [RFC 2046]. (As of thisdocument, the current IANA registeredMIME types are listed athttp://www.iana.org/assignments/media-
types/)
size cap.
alertInfoResource.size.
integer
The integerindicating thesize of theresource file(OPTIONAL)
(1) Approximate size of the resource file inbytes.(2) For based resources, SHOULD be included if available.
uri cap.alertInfoResource.
uri.identifier
The identifier ofthe hyperlinkfor the
resource file(OPTIONAL)
A full absolute URI, typically a UniformResource Locator that can be used toretrieve the resource over the Internet
ORa relative URI to name the content of a element if one is present in thisresource block.
8/2/2019 (Oasis)Cap v1.2
24/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 24 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
derefUri cap
alertInfoResource.derefUri.data
The base-64
encoded datacontent of theresource file(CONDITIONAL)
(1) MAY be used either with or instead of
the element in messages transmittedover one-way (e.g., broadcast) data linkswhere retrieval of a resource via a URI isnot feasible.(2) Clients intended for use with one-waydata links MUST support this element.(3) This element MUST NOT be usedunless the sender is certain that all directclients are capable of processing it.
(4) If messages including this element areforwarded onto a two-way network, theforwarder MUST strip the element and SHOULD extract the filecontents and provide a link to aretrievable version of the file.
(5) Providers of one-way data links MAYenforce additional restrictions on the use ofthis element, including message-size limitsand restrictions regarding file types.
digest cap.
alertInfoResource.digest.
code
The coderepresentingthe digitaldigest (hash)computed fromthe resourcefile(OPTIONAL)
Calculated using the Secure HashAlgorithm (SHA-1) per [FIPS 180-2] .
3.2.4 "area" Element and Sub-elements
area cap.
alertInfoArea.area.
group
The containerfor allcomponentparts of thearea sub-
element of theinfo sub-element of thealert message(OPTIONAL)
(1) Multiple occurrences permitted, in whichcase the target area for the block isthe union of all the included blocks.
(2) MAY contain one or multiple instancesof , or . Ifmultiple , or elements are included, the area describedby this block is represented by theunion of all the included elements.
8/2/2019 (Oasis)Cap v1.2
25/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 25 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
areaDesc cap.
alertInfoArea.areaDesc.text
The text
describing theaffected areaof the alertmessage(REQUIRED)
A text description of the affected area.
polygon cap.
alertInfoArea.polygon.
group
The pairedvalues of pointsdefining apolygon thatdelineates theaffected area ofthe alert
message(OPTIONAL)
(1) Code Values: The geographic polygon isrepresented by a whitespace-delimited listof [WGS 84] coordinate pairs. (See WGS84 Note at end of this section)(2) A minimum of 4 coordinate pairs MUSTbe present and the first and last pairs ofcoordinates MUST be the same.
(3) Multiple instances MAY occur within an block.
circle cap.
alertInfoArea.circle.
group
The pairedvalues of apoint andradiusdelineating theaffected area ofthe alertmessage(OPTIONAL)
(1) Code Values: The circular area isrepresented by a central point given as a[WGS 84] coordinate pair followed by aspace character and a radius value inkilometers. (See WGS 84 Note at end ofthis section)(2) Multiple instances MAY occur within an block.
8/2/2019 (Oasis)Cap v1.2
26/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 26 of 47
ElementName
Context. Class.Attribute.Representation
Definition and(Optionality)
Notes or Value Domain
geocode cap.
alertInfoArea.geocode.code
The geographic
codedelineating theaffected area ofthe alertmessage(OPTIONAL)
(1) Any geographically-based code to
describe a message target area, in theform:
valueName
value
where the content of valueName is a user -assigned string designating the domain ofthe code, and the content of value is astring (which may represent a number)denoting the value itself (e.g., valueName="SAME" and value=" 006113 ").
(2) Values of valueName that areacronyms SHOULD be represented in allcapital letters without periods (e.g., SAME,FIPS, ZIP).(3) Multiple instances MAY occur within an block.(4) This element is primarily for compatibilitywith other systems. Use of this elementpresumes knowledge of the coding systemon the part of recipients; therefore, forinteroperability, it SHOULD be used inconcert with an equivalent description in the
more universally understood and forms whenever possible.
altitude cap.alertInfoArea.
altitude.quantity
The specific orminimumaltitude of theaffected area ofthe alertmessage(OPTIONAL)
(1) If used with the element thisvalue is the lower limit of a range.Otherwise, this value specifies a specificaltitude.
(2) The altitude measure is in feet abovemean sea level per the [WGS 84] datum.
ceiling cap.
alertInfoArea.ceiling.quantity
The maximumaltitude of theaffected area ofthe alertmessage(CONDITIONAL )
(1) MUST NOT be used except incombination with the element.
(2) The ceiling measure is in feet abovemean sea level per the [WGS 84] datum.
8/2/2019 (Oasis)Cap v1.2
27/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 27 of 47
3.3 Implementation Notes234
3.3.1 WGS 84 Note235Geographic locations in CAP are defined using [WGS 84] (World Geodetic System 1984), equivalent to236EPSG (European Petroleum Survey Group) code 4326 (2 dimensions). CAP does not assign237
responsibilities for coordinate transformations from and to other Spatial Reference Systems. See section238 1.5 Terminology for the format of coordinate pairs within CAP elements.239
3.3.2 DateTime Data Type240All [dateTime] elements (, , , and ) SHALL be specified in the form241"YYYY-MM-DDThh:mm:ssXzh:zm" where:242
YYYY indicates the year243
MM indicates the month244
DD indicates the day245
T indicates the symbol T marking the start of the required time secti on246
hh indicates the hour247
mm indicates the minute248
ss indicates the second249
X indicates either the symbol + if the preceding date and time are in a time zone ahead of UTC,250or the symbol - if the preceding date and time are in a time zone behind UTC. If t he time is in251UTC, the symbol - will be used. 252
zh indicates the hours of offset from the preceding date and time to UTC, or 00 if the preceding253time is in UTC254
zm indicates the minutes of offset from the preceding date and time to UTC, or 00 if the255preceding time is in UTC256
For example, a value of 2002 -05-30T09:30:10- 05:00 would indicate May 30, 2002 at 9:30:10 AM 257Eastern Standard Time, which would be 2:30:10PM Universal Coordinated Time (UTC). That same258
time might be indicated by 2002 -05-30T14:30:10- 00:00. 259
3.3.3 Character Entity References260The use of character entity references, such as HTML entities (e.g. ) is discouraged.261
3.3.4 Security Note262Because CAP is an XML-based format, existing XML security mechanisms can be used to secure and263authenticate its content. While these mechanisms are available to secure CAP Alert Messages, they264should not be used indiscriminately.265
3.3.4.1 Digital Signatures266The element of a CAP Alert Message MAY have an Enveloped Signature, as described by XML-267Signature and Syntax Processing [XMLSIG] . Other XML signature mechanisms MUST NOT be used in268CAP Alert Messages.269Processors MUST NOT reject a CAP Alert Message containing such a signature simply because they are270not capable of verifying it; they MUST continue processing and SHOULD inform the user of their failure to271validate the signature.272
8/2/2019 (Oasis)Cap v1.2
28/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 28 of 47
In other words, the presence of an element with the namespace URI [XMLSIG] and a local name of273 as a child of the element must not cause a processor to fail merely because of its274presence.275
3.4 XML Schema276277
278279 286
287288
CAP Alert Message (version 1.2)289290291
292293294295
296297
298299
300301
302303
304305306307308309
310
311 312313
314315
316317318319320
321322
323324325
326327
328 329330
331332
333334335336337338339340
341
8/2/2019 (Oasis)Cap v1.2
29/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 29 of 47
342343344
345346
347348349350 351352353354355356357358
359360
361362363
364365
366367 368369370371372373374
375376
377378
379380
381382383384 385
386387
388389
390391
392393394395396
397398
399400
401402
403404405406407
408409
410411412
413
8/2/2019 (Oasis)Cap v1.2
30/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 30 of 47
414415416
417418
419420
421422 423424
425426
427428
429430
431432
433434
435436
437438
439 440441442443444445446447
448449
450451
452453
454455
456 457458459460461462463
464465
466467
468469
470472474475
476477
478479
480481
482483484
485
8/2/2019 (Oasis)Cap v1.2
31/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 31 of 47
486487
488489
490492493
494 495496497498
499500501502
8/2/2019 (Oasis)Cap v1.2
32/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 32 of 47
3.5 Use of ASN.1 to Specify and Encode the CAP Alert Message503
3.5.1 General504The ASN.1 (see ITU-T Rec X.680) schema in 3.5.3 provides an alternative formulation of the XML505schema defined in 3.4. If the ASN.1 Extended XML Encoding Rules (see ITU-T Rec X.693) are applied506to this ASN.1 schema, the permitted XML is identical to that supported by the XML schema in 3.4. If the507ASN.1 Unaligned Packed Encoding Rules (see ITU-T Rec X.691) are applied to it, the resulting binary508encodings are more compact than the corresponding XML encodings.509
3.5.2 Formal Mappings and Specification510The normative specification of the compact binary encoding is in 3.5.3 with the application of the ASN.1511Unaligned Packed Encoding Rules (see ITU-T Rec. X.691).512The semantics of the fields in the ASN.1 specification are identical to those of the XSD specification, and513the mapping of the fields from the XSD specification to the ASN.1 specification is formally defined in ITU-514T Rec. X.694.515
Implementations can produce and process the CAP alert XML messages using either ASN.1-based or516
XSD-based tools (or other ad hoc software).517Implementations can produce and process the CAP alert compact binary messages using ASN.1-based518tools (or by other ad hoc software).519
Any XML encoded CAP alert messages can be converted to compact binary messages by decoding with520an ASN.1 tool configured for the Extended XML Encoding Rules and re-encoding the resulting abstract521values with an ASN.1 tool configured for Unaligned Packed Encoding Rules.522Any compact binary CAP alert messages can be converted to XML encoded messages by decoding with523an ASN.1 tool configured for Unaligned Packed Encoding Rules and re-encoding the resulting abstract524values with an ASN.1 tool configured for Extended XML Encoding Rules.525
3.5.3 ASN.1 Schema526
CAP-1-2 {itu-t recommendation x cap(1303) version1-2(2)}527DEFINITIONS XER INSTRUCTIONS AUTOMATIC TAGS ::=528-- CAP Alert Message (version 1.2) 529BEGIN530
531Alert ::= SEQUENCE {532
identifier IdentifierString,533-- Unambiguous identification of the message534- - from all messages from535-- this sender, in a format defined by the sender and 536-- identified in the "sender" field below. 537
sender String,538-- The globally unambiguous identification of the sender. 539-- This specification does not define the root of 540- - a global identification tree (there is no international541-- agreement on such a root), so it relies
542 -- on human-readable text to define globally and 543- - unambiguously the sender. 544-- An internet domain name or use of "iri:/ITU-T/..."545- - are possible, but 546-- the choice needs to be clearly stated in human-readable form. 547
sent DateTime (CONSTRAINED BY {/* XML representation of the XSD548pattern "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d[-,+]\d\d:\d\d" */}) , 549
status AlertStatus,550msgType AlertMessageType,551source String OPTIONAL,552
-- Not standardised human-readable identification553
8/2/2019 (Oasis)Cap v1.2
33/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 33 of 47
- - of the source of the alert. 554scope AlertScope,555restriction String OPTIONAL,556
-- Not standardised human-readable restrictions557- - on the distribution of the alert message 558
addresses String OPTIONAL,559-- A space separated list of addressees for private messages560-- (see 3.2.1) 561 code-list SEQUENCE SIZE((0..MAX)) OF code String,562-- A sequence codes for special handling 563- - (see 3.2.1)564
-- The format and semantics of the codes are not defined in this565-- specification. 566
note String OPTIONAL,567-- Not standardised human-readable clarifying text for the alert568-- (see 3.2.1) 569
references String OPTIONAL,570-- Space-separated references to earlier messages571
-- (see 3.2.1) 572incidents String OPTIONAL,573
-- Space-separated references to related incidents574-- (see 3.2.1) 575
info-list SEQUENCE SIZE((0..MAX)) OF info AlertInformation }576577AlertStatus ::= ENUMERATED {578
actual,579draft,580exercise,581system,582test }583
584AlertMessageType ::= ENUMERATED {585
ack,586alert,587cancel,588error,589update }590
591 AlertScope ::= ENUMERATED {592private,593public,594restricted }595
596AlertInformation ::= SEQUENCE {597
language Language -- DEFAULT "en-US" -- ,598-- The language used in this value of the Info type599-- (see 3.2.2)600
category-list SEQUENCE (SIZE(1..MAX)) OF601category InformationCategory,602
event String,603-- Not standardised human-readable text describing the604- - type of the event (see 3.2.2)605
responseType-list SEQUENCE SIZE((0..MAX)) OF606 responseType InformationResponseType,607urgency HowUrgent,608severity HowSevere,609certainty HowCertain,610audience String OPTIONAL,611
-- Not standardised human-readable text describing the612- - intended audience for the message (see 3.2.2)613
eventCode-list SEQUENCE SIZE((0..MAX)) OF eventCode SEQUENCE {614valueName ValueName,615value Value },616
8/2/2019 (Oasis)Cap v1.2
34/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 34 of 47
effective DateTime (CONSTRAINED BY {/* XML representation of the617XSD pattern "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d[-,+]\d\d:\d\d" */}) OPTIONAL,618
onset DateTime (CONSTRAINED BY {/* XML representation of the619XSD pattern "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d[-,+]\d\d:\d\d" */}) OPTIONAL,620
expires DateTime (CONSTRAINED BY {/* XML representation of the621XSD pattern "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d[-,+]\d\d:\d\d" */}) OPTIONAL,622
senderName String OPTIONAL,623-- Not standardised human-readable name of the authority 624 - - issuing the message (see 3.2.2)625
headline String (SIZE (1..160,...)) OPTIONAL,626-- Not standardised human-readable short statement (headline)627- - of the alert (see 3.2.2)628
description String OPTIONAL,629-- Not standardised human-readable extended description of 630- - the event (see 3.2.2)631
instruction String OPTIONAL,632-- Not standardised human-readable recommended action633
-- (see 3.2.2)634web AnyURI OPTIONAL,635contact String OPTIONAL,636
-- Not standardised human-readable contact details for 637-- follow-up (see 3.2.2)638
parameter-list SEQUENCE SIZE((0..MAX)) OF parameter SEQUENCE {639 -- System-specific parameters (see 3.2.2)640valueName ValueName,641value Value },642
resource-list SEQUENCE SIZE((0..MAX)) OF resource ResourceFile,643area-list SEQUENCE SIZE((0..MAX)) OF Area }644
645InformationCategory ::= ENUMERATED {646
cBRNE,647env,648fire,649geo,650health,651infra,652met,653other,654 rescue,655safety,656security,657transport }658
659InformationResponseType ::= ENUMERATED {660
allClear,661assess,662avoid,663evacuate,664execute,665monitor,666none,667prepare,668shelter }669670
HowUrgent ::= ENUMERATED {671expected,672future,673immediate,674past,675unknown }676
677HowSevere ::= ENUMERATED {678
extreme,679minor,680
8/2/2019 (Oasis)Cap v1.2
35/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 35 of 47
moderate,681severe,682unknown }683
684HowCertain ::= ENUMERATED {685
likely,686observed,687possible,688 unknown,689unlikely }690
691ResourceFile ::= SEQUENCE {692
-- Information about an associated resource file693-- (see 3.2.3)694
resourceDesc String,695-- Not standardised human-readable description of the type696- - and content of 697-- an associated resource file (for example a map or 698-- photograph)(see 3.2.3)699
mimeType String,700size INTEGER OPTIONAL, -- In bytes 701uri AnyURI OPTIONAL,702derefUri String OPTIONAL,703 -- An alternative to the URI giving the Base64-encoded 704
- - content of the resource file (see 3.2.3)705digest String OPTIONAL706
-- SHA-1 hash of the resource file for error detection707-- (see 3.2.3) -- }708
709Area ::= SEQUENCE {710
-- Identification of an affected area 711areaDesc String,712
-- Not standardised human-readable description of the area 713polygon-list SEQUENCE OF polygon String,714
-- Each element is a space-separated list of coordinate pairs715-- The complete list starts and ends with the same point and 716-- defines the polygon that defines the area717
-- (see 3.2.4) .718 circle-list SEQUENCE OF circle String,719-- A space-separated list of coordinates for a point and a radius 720
geocode-list SEQUENCE SIZE((0..MAX)) OF geocode SEQUENCE {721-- A geographic code designating the alert target area722
-- (see 3.2.4)723valueName ValueName,724value Value },725
altitude REAL OPTIONAL,726-- Specific or minimum altitude of the affected area727
ceiling REAL OPTIONAL728-- Maximum altitude of the affected area -- }729
730ValueName ::= String -- A not standardised name for 731
-- an information event code, a parameter or a geocode 732
733 Value ::= String -- The value of the information event code,734-- parameter or geocode735
736String ::= UTF8String (FROM (737
{0,0,0,9} -- TAB738| {0,0,0,10} -- CR739| {0,0,0,13} -- LF740| {0,0,0,32}..{0,0,215,255} -- Space to the start of the S-zone 741| {0,0,224,0}..{0,0,255,253} -- Rest of BMP after S-zone742| {0,1,0,0}..{0,16,255,253} -- Other planes -- ) )743
744
8/2/2019 (Oasis)Cap v1.2
36/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 36 of 47
StringChar ::= String (SIZE(1))745746
SpaceAndComma ::= UTF8String (FROM (747{0,0,0,32} -- SPACE748
| {0,0,0,44} -- COMMA -- ) )749750
IdentifierString ::= String (FROM (StringChar EXCEPT SpaceAndComma))751
752 Language ::= VisibleString(FROM ("a".."z" | "A".."Z" | "-" | "0".."9"))753(PATTERN "[a-zA-Z]#(1,8)(-[a-zA-Z0-9]#(1,8))*")754
-- The semantics of Language is specified in IETF RFC 3066 755756
DateTime ::= TIME (SETTINGS "Basic=Date-Time Date=YMD757Year=Basic Time=HMS Local-or-UTC=LD")758
-- This is the ISO 8601 format using local time and a759-- time difference760
761StringWithNoCRLFHT ::= UTF8String (FROM (762
{0,0,0,32}..{0,0,215,255}763|{0,0,224,0}..{0,0,255,253}764|{0,1,0,0}..{0,16,255,255}))765
766AnyURI ::= StringWithNoCRLFHT (CONSTRAINED BY {767 /* Shall be a valid URI as defined in IETF RFC 2396 */})768
769ENCODING-CONTROL XER770
GLOBAL-DEFAULTS MODIFIED-ENCODINGS771GLOBAL-DEFAULTS CONTROL-NAMESPACE772
"http://www.w3.org/2001/XMLSchema-instance" PREFIX "xsi"773NAMESPACE ALL, ALL IN ALL AS "urn:oasis:names:tc:emergency:cap:1.2"774
PREFIX "cap"775NAME Alert, Area AS UNCAPITALIZED776UNTAGGED SEQUENCE OF777DEFAULT-FOR-EMPTY AlertInformation.language AS "en-US"778TEXT AlertStatus:ALL,779
AlertMessageType:ALL,780AlertScope:ALL,781InformationCategory:ALL,782 InformationResponseType:ALL,783HowUrgent:ALL,784HowSevere:ALL,785HowCertain:ALL AS CAPITALIZED786
WHITESPACE Language, AnyURI COLLAPSE787END788
789
8/2/2019 (Oasis)Cap v1.2
37/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 37 of 47
4 Conformance790An implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level791requirements defined within this specification.792
This specification references a number of other specifications. In order to comply with this specification,793an implementation MUST implement the portions of referenced specifications necessary to comply with794the required provisions of this specification. Additionally, the implementation of the portions of the795referenced specifications that are specifically cited in this specification MUST comply with the rules for796those portions as established in the referenced specification.797
798
4.1 Conformance Targets799The following conformance targets are defined in order to support the specification of conformance to this800standard:801
a) CAP V1.2 Message802b) CAP V1.2 Message Producer803c) CAP V1.2 Message Consumer804
805
4.2 Conformance as a CAP V1.2 Message806An XML 1.0 document is a conforming CAP V1.2 Message if and only if:807
a) it is valid according to the schema located at http://docs.oasis-808open.org/emergency/cap/v1.2/CAP-v1.2. xsd and809
b) the content of its elements and the values of its attributes meet all the additional mandatory810requirements specified in Section 3.811
812
4.3 Conformance as a CAP V1.2 Message Producer813A software entity is a conforming CAP V1.2 Message Producer if and only if:814
a) it is constructed in such a way that any XML document produced by it and present in a place in815which a conforming CAP V1.2 Message is expected (based on contextual information) is indeed a816conforming CAP V1.2 Message according to this standard.817
The condition in (a) above can be satisfied in many different ways. Here are some examples of possible818scenarios:819
a distribution element(for example, EDXL-DE) transfers messages carrying CAP V1.2 Messages;820a client has sent a request for a CAP V1.2 Message to a server which claims to be a conforming821CAP V1.2 Message Producer, and has received a response which is therefore expected to carry822
a conforming CAP V1.2 Message;823 a local test environment has been set up, and the application under test (which claims to be a824
conforming CAP V1.2 Message Producer) has the ability to produce a CAP V1.2 Message and825write it to a file in a directory in response to a request coming from the testing tool; the testing tool826has sent many requests to the application under test and is now verifying all the files present in827the directory, which is expected to contain only conforming CAP V1.2 Messages;828
829
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.8/2/2019 (Oasis)Cap v1.2
38/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 38 of 47
4.4 Conformance as a CAP V1.2 Message Consumer830A software entity is a conforming CAP V1.2 Message Consumer if and only if:831
a) it is constructed in such a way that it is able to successfully validate and ingest a conforming CAP832V1.2 Message according to this standard.833
The condition in (a) above can be satisfied in many different ways. Here is one example of a possible834scenario:835
a client receives and processes a CAP V1.2 Message from a server which claims to be a836conforming CAP V1.2 Message Producer837
838839
8/2/2019 (Oasis)Cap v1.2
39/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 39 of 47
Appendix A. CAP Alert Message Example840XML examples are included below and are also available as separate files, along with ASN.1 binary841encoded examples, in the CAP 1.2 document repository http://docs.oasis-open.org/emergency/cap/v1.2/ 842
A.1. Homeland Security Advisory System Alert843The following is a speculative example in the form of a CAP XML message.844
845846
[email protected]:39:01-05:00849Actual850Alert851Public852853
Security854Homeland Security Advisory System Update855Immediate856 Severe857Likely858U.S. Government, Department of Homeland Security859Homeland Security Sets Code ORANGE860The Department of Homeland Security has elevated the Homeland Security Advisory861
System threat level to ORANGE / High in response to intelligence which may indicate a heightened862threat of terrorism.863
A High Condition is declared when there is a high risk of terrorist attacks. In864addition to the Protective Measures taken in the previous Threat Conditions, Federal departments865and agencies should consider agency-specific Protective Measures in accordance with their866existing plans.867
http://www.dhs.gov/dhspublic/display?theme=29868869
HSAS870ORANGE871
872873 Image file (GIF)874
image/gif875http://www.dhs.gov/dhspublic/getAdvisoryImage876
877878
U.S. nationwide and interests worldwide879880
881 882
883
8/2/2019 (Oasis)Cap v1.2
40/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 40 of 47
A.2. Severe Thunderstorm Warning884The following is a speculative example in the form of a CAP XML message.885
886887
[email protected]:57:00-07:00890Actual891Alert892Public893894
Met895SEVERE THUNDERSTORM896Shelter897Immediate898Severe899Observed900901
SAME902SVR903
9042003-06-17T16:00:00-07:00
905 NATIONAL WEATHER SERVICE SACRAMENTO CA906SEVERE THUNDERSTORM WARNING907 AT 254 PM PDT...NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED A SEVERE908
THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...MOVING909SOUTHWEST AT 5 MPH. HAIL...INTENSE RAIN AND STRONG DAMAGING WINDS ARE LIKELY WITH THIS910STORM.911
TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STORM PASSES.912BARUFFALDI/JUSKIE913914
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA, EXTREME NORTHEASTERN915CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA916
38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14917918
SAME919006109920
921922 SAME923
006009924925926
SAME927006003928
929930
931932
933
8/2/2019 (Oasis)Cap v1.2
41/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 41 of 47
A.3. Earthquake Report (Update Message) 934The following is a speculative example in the form of a CAP XML message.935
936937
[email protected]:56:00-07:[email protected],TRI13970876.1,2003-06-11T20:30:00-07:00944945
Geo946Earthquake947Past948Minor949Observed950Southern California Seismic Network (TriNet) operated by Caltech and951
USGS952EQ 3.4 Imperial County CA953A minor earthquake measuring 3.4 on the Richter scale occurred near Brawley,954
California at 8:30 PM Pacific Daylight Time on Wednesday, June 11, 2003. (This event has now been955 reviewed by a seismologist)956
http://www.trinet.org/scsn/scsn.html957958
EventID95913970876960
961962
Version9631964
965966
Magnitude9673.4 Ml968
969970
Depth97111.8 mi.972 973
974Quality975Excellent976
977978
1 mi. WSW of Brawley, CA; 11 mi. N of El Centro, CA; 30 mi. E of OCOTILLO979(quarry); 1 mi. N of the Imperial Fault980
32.9525,-115.5527 0981982
983984
985
8/2/2019 (Oasis)Cap v1.2
42/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 42 of 47
A.4. AMBER Alert (Multilingual Message)986The following is a speculative example in the form of a CAP XML message.987
988989
KAR0-0306112239-SW990 [email protected]:39:00-07:00992Actual993Alert994SW995Public996997
en-US998Rescue999Child Abduction1000Immediate1001Severe1002Likely10031004
SAME1005CAE1006
1007 Los Angeles Police Dept - LAPD1008Amber Alert in Los Angeles County1009DATE/TIME: 06/11/03, 1915 HRS. VICTIM(S): KHAYRI DOE JR. M/B BLK/BRO 3'0", 401010
LBS. LIGHT COMPLEXION. DOB 06/24/01. WEARING RED SHORTS, WHITE T-SHIRT, W/BLUE COLLAR.1011LOCATION: 5721 DOE ST., LOS ANGELES, CA. SUSPECT(S): KHAYRI DOE SR. DOB 04/18/71 M/B, BLK HAIR,1012BRO EYE. VEHICLE: 81' BUICK 2-DR, BLUE (4XXX000).1013
DET. SMITH, 77TH DIV, LOS ANGELES POLICE DEPT-LAPD AT 213 485-238910141015
Los Angeles County10161017
SAME10180060371019
10201021
10221023
es-US1024 Rescue1025Abduccin de Nio1026Immediate1027Severe1028Likely10291030
SAME1031CAE1032
1033Departamento de Polica de Los ngeles - LAPD1034Alerta Amber en el condado de Los ngeles1035DATE/TIME: 06/11/03, 1915 HORAS. VCTIMAS: KHAYRI DOE JR. M/B BLK/BRO 3'0", 401036
LIBRAS. TEZ LIGERA. DOB 06/24/01. CORTOCIRCUITOS ROJOS QUE USAN, CAMISETA BLANCA, COLLAR DE1037W/BLUE. LOCALIZACIN: 5721 DOE ST., LOS NGELES. SOSPECHOSO: KHAYRI DOE ST. DOB 04/18/71 M/B,1038PELO DEL NEGRO, OJO DE BRO. VEHCULO: 81' BUICK 2-DR, AZUL (4XXX000)1039
DET. SMITH, 77TH DIV, LOS ANGELES POLICE DEPT-LAPD AT 213 485-238910401041 condado de Los ngeles1042
1043SAME10440060371045
10461047
1048 1049
8/2/2019 (Oasis)Cap v1.2
43/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 43 of 47
Appendix B. Acknowledgments1050
OASIS Emergency Management Technical Committee 1051Doug Allport, Canadian Association for Public Alerting and Notification (CAPAN)1052Patti Aymond, IEM1053Himadri Banerjee, Previstar Inc.1054Frank Bell, Individual1055Art Botterell, Contra Costa County Community Warning System1056John Bradley, Individual1057Rex Brooks, Individual1058Robert Bunge, NOAA's National Weather Service1059Toby Considine, University of North Carolina at Chapel Hill1060William Cox, Cox Software Architects LLC1061Olivier Dubuisson, France Telecom1062Sukumar Dwarkanath, SRA International1063David Ellis, Sandia National Laboratories1064
Thomas Ferrentino, Individual1065Jack Fox, US Department of Homeland Security1066Patrick Gannon, Warning Systems, Inc.1067Timothy Gilmore, US Department of Homeland Security1068James Goodson, US Department of Homeland Security1069Tim Grapes, Evolution Technologies Inc.1070Gary Ham, Individual1071Harry Haury, NuParadigm Government Systems, Inc.1072Werner Joerg, IEM1073Elysa Jones, Warning Systems, Inc.1074Jeff Jortner, Sandia National Laboratories1075William Kalin, US Department of Homeland Security1076Ram Kumar, Individual1077
Jeff Kyser, Warning Systems, Inc.1078 Ron Lake, Galdos Systems Inc.1079David Lamendsdorf, Emergency Interoperability Consortium1080Mike McDougall, Individual1081Donald McGarry, Mitre Corporation1082Tom Merkle, Lockheed Martin1083Enoch Moses, ManTech Enterprise Integration Center (e-IC)1084Brian Nelson, Sandia National Laboratories1085Camille Osterloh, US Department of Homeland Security1086John Pitale, Edmond Scientific Company1087Mark Pleimann, Mitre Corporation1088Donald Ponikvar, US Department of Homeland Security1089Jacqueline Postell, US Department of Homeland Security1090Carl Reed, Open Geospatial Consortium, Inc. (OGC)1091Dean Reese, ESI Acquisition, Inc.1092Kirby Rice, Eye Street Solutions1093Howard Ryan, Desktop Alert Inc.1094Tracy Ryan, Emergency Interoperability Consortium1095Josh Shows, ESI Acquisition, Inc.1096Aviv Siegel, AtHoc, Inc.1097Andrew Sonner, Evolution Technologies Inc.1098Christopher Springer, US Department of Homeland Security1099Steve Streetman, US Department of Homeland Security1100Lee Tincher, Evolution Technologies Inc.1101
8/2/2019 (Oasis)Cap v1.2
44/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 44 of 47
James Trawick, viaRadio Corporation1102Alessandro Triglia, OSS Nokalva1103Richard Vandame, US Department of Homeland Security1104Matt Walton, Individual1105Jeff Waters, US Department of Defense (DoD)1106David Webber, Individual1107Jacob Westfall, Individual1108David Yarbrough, Northrop Grumman1109
11101111
8/2/2019 (Oasis)Cap v1.2
45/47
CAP-v1.2-os 1 July 2010Copyright OASIS Open 2010. All Rights Reserved. Page 45 of 47
Appendix C. Revision History 1112
Rev Date By Whom What
1.2 2010-03-02 Jacob Westfall Technical Committee approved changes that removed XMLDigital Encryption within CAP messages.
1.2 2009-12-22 Jacob Westfall Technical Committee approved the v. 1.2 draft submitted bythe Messaging Subcommittee