annexure 8 -...

34
2009 VICTORIAN BUSHFIRES ROYAL COMMISSION Letters Patent Issued 16 February 2009 Witness Statement of Jillian Patricia Edwards Date of Document: 3 June 2009 Filed on behalf of: Australasian Fire and Emergency Service Authorities Council (AFAC) Prepared by: AFAC Corporate Counsel ANNEXURE 8 WIT.039.001.0053

Upload: lyhanh

Post on 28-Mar-2018

218 views

Category:

Documents


3 download

TRANSCRIPT

2009 VICTORIAN BUSHFIRES ROYAL COMMISSION

Letters Patent Issued 16 February 2009

Witness Statement of Jillian Patricia Edwards

Date of Document: 3 June 2009

Filed on behalf of:

Australasian Fire and Emergency Service Authorities Council (AFAC)

Prepared by: AFAC Corporate Counsel

ANNEXURE 8

WIT.039.001.0053

(. I,f ~, c,o I: 0 I

" '. 1'·6.· ..'.." '. "~',~."

.1j'-:UITn6lritldenG:lfi·w:CAP~V1.1

l .. :"j:'m,:http://www.oasls-open.org/appslorg/workgrouplemergenoy/download.php/14205/emergency­CAPv1.1-Committee%20Speclflcation.doc

·:l--nical ;"'kn,,\;~l·.:"

OASIS Emergency Management TC~~l~m'{~):

ElysaJones, Wamlng Systems, Inc <[email protected]'n>Art Sotterell, Individual <acb@lncid,iJ,Tl,com>

Aki!3'in"c~:

TheCommon Alerting Protocol (CAP)ls asimple butgeneral format for exchanging all-hazardemergenoy alerts and public warnings over all kinds ofnetworks. CAPallows a consistentWaming message to be disseminated simultaneously overmanydifferent warning systems, thusincreasing warning effectiveness while simplifying thewamlng task. CAPalso facilitates thedetection of emergingpatterns In localwamlngs ofvarious kinds. such as might Indicate anlJl1detected hazard or hostile act. And CAP prOVides a template for effective waming messagesbasedon best practices Identified In academic research andreal-world experience.

$~tlllle:

This document is the OASIS standard, adopted bya vote of the general membership endingSeptember 30,2005. Additional infonnation, including implementation guidelines and samplefiles, maybe found through theEmergency management TCweb page(htq Ilw\A~"J.oa~'ls~

OI'I;;,\;.tx~i,:r·: ,l:"nlttsss/emargancy/).

For information on whether anypatents have been disclosed that maybeessential toimplementing this apeclfloatlon, and anyoffers of patent 1I0ensing terms, please refer to theIntellectual Property Rights section of the Emergency Management TC webpage(http://wlfliw.oasis~open.org/committees/emergsncylipr.php).

CAP-V1.1Copyright © OASISOpen 2005. All Rights Reserved.

1 October 2005Page 1 or 3'5

WIT.039.001.0054

[, I ( '{l"j'CC.C, .• ' ,', t:

OASIStakes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the Implementation oruseof the technology described inthis documentorthe extentto whichany license under such rights might or mightnot be available; neither doesItrepresentthat it has made any effort to identify any sucl1 rights. Information on OASIS's procedures withrespectto rights in OASIS specifications can befound at the OASIS website. Caples ofclaims of rightsmadeavailable for publication and any assurances oflicenses to be madeavailable, or the resultof anattemptmade to obtain a general license or permission for the use of suchproprietary rights byImplemantors or usersof this specification, can be obtained from the OASIS President.OASIS invites any interested party to bringto Itsattention any copyrights, patents or patent applications,or other proprietary rights whichmay covertechnology thatmay be required to Implement thisspeoiflcatlon. Please address the Information to theOASIS President.Copyright© OASIS Open 2005. All Rights Reserved.

This document andtranslations of it may be copied andfurnished to others, andderivative worksthatcommenton or otherwise explain It or assist In itsImplementation may be prepared, copied, publlshedand distributed, In whole or Inpart, without restriction of anykind, provided that the above copyright noticeand this paragraph are included on all such copies and derivative works, However, this document itselfdoes not be modified in anyway, such as by removing the copyright notloe or references to OASIS,exceptas needed for thepurpose of developing OASIS specifications, Inwhich case theprocedures forcopyrights defined In the OASIS Intellectual Property Rights document mustbe followed, or as required totranslate It into languages otherthan Engllsh,The limited permissions granted above are perpetual andwill not be revoked by OASiS or its successorsor assigns.This document andthe information contained herein is provlded on an "AS IS" basis and OASISDISCLAIMS ALI-WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUTNOT LIMITED TO ANYWARRANTY THAT THEUSEOF THE INFORMATION HEREIN WILL NOTINFRINGE ANY RIGHTS ORANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FORA PARTICULAR PURPOSE.

CAP·V1.1Copyright@ OASIS Open2006. All Rights Reserved,

1 October2005Page20f36

WIT.039.001.0055

Introduction , , 41.1 Purpose ,.....•,.., ' " .., , , ," " ""'"'' ,.,,.., , " ,.", " ,,.."..41.2 History , , , , ,.41,3 Structure of the CAPAlert Message 4

1.3.1 <alert> , , , , , 51.3.2 <Info> ,', .., , , , , 51.3.3 <resource> , " , , 51.3.4 <area> , " , , 5

1.4Applications of the CAP Alert Message , :..51.5Terminology 51.6Normative References , " " ..6

2 Design Principles and Concepts (non-normative) 72.1 Design Philosophy., , , , 72.2 Requlremente for Oe8Ign , " " 72.3 Examples of Use Scenarios : " ,.." " , " 8

2.3.1 Manual Origination , , , 82.3.2 Automated Origination by Autonomous Sensor System 82.3.3 Aggregation and Correlation on Real-time Map " 82.3.4 Integrated 'PubllcAlartlng"." . , 82.3.5 RepUdiating a FalseAlarm 9

3 AlertMessage Structure(normative) , 10

3.1 Document Object Model 103.2 Data Dictionary , 11

3.2.1 'Ialert" Elementand Sub-elements " 113.2.2 "info"Elementand sub-elements " , , :143.2.3 "resource" Element and Sub-elements " "." " 213.2.4 "area"Element andSub-elements " 22

3.3 Implementation Notes : , 253.3.1 WGS-84 Note , 253.3.2 Security Note , 25

3.4XMLSchema , 25Appendix A. CAPAlert Message Example , , 29

A.1. Homeland SecurityAdvisory System Alert " 29A.2. Severe Thunderstorm WarnIng " , , 30A.3. Earthquake Report , 31AA. AMBER Alert (Including EAS Activation) 32

AppendIx 8. AcknOWledgments , 33OASIS Emergency Management Technical Committee 33

AppendiX C. Revision History , 35

CAP-V1.1Copyright© OASISOpen 2005, All RIghts Reserved.

1 Oclober2005Page3 of 35

WIT.039.001.0056

85

8687688990919293949696979899

100101102103104105106107108109110111112

[RFC2119]

[dateTime]

[FIPS 180~2]

[namespacas]

[RFC2046J

[RFC2119]

[RFC3066]

I,WGS 84]

[XML i.0}

[XMLSIG)

[XMLENC)

S. Bradner, Key wordsfor use in RFCsto Indicate Requirement Levels,i::r ofg ':1c/rfc:2119.txt, IETFRFC2119, March 1997.

N. Freed, XML Schema Part 2: Datatypes Second Edition,hitp:llwl/vw,w3.orgi ,'; \,;,1,"schema-2N.'d"rteTime,W3C REC-xmlschema-2,October2004.National Institutefor Standards andTechnology, Secure Hash Standard,http://csrc.nlstgov/jJbllcalions/fipsfi'iI' ;j ., 0-2/fij.::; r Q~·'·iithc! .ngenoiice.IJdf,August2002.T. Bray, Namespaces InXML, http://w\filw.w3.org/rr~/REC-)(rnl·names/, W3CREC-xml-names-19990114, January 1999.N.Freed, MUltipurpose Internet Mall Extenslqns (MIME) PartTwo: Media Types,htlp:llwww.iet'f."rg/li·.hi<;<;,.>W.L-:" IETF RFC2046, November 1996.S. Bradner, Key wordsfor use InRFCsto Indioate Requirement Levels,l..Itlp:llwww.i....tf.orglrfc!iL..:;·.lt-J .•:;(. IETF RFC 2119, March 1997.H. Alvestrand, rags for theIdentification of Languages,htij:;,·i''''',\,.ietf.org/rld: 'I :~.(;,jr.:.l,'.i, IETF RFC 3066, January 2001.National Geospatial Intelligence Agency, Department of Defense WorldGeodeticSystem 1984, I.Llp:/iJc1i(i,·i:l(u.lidi:'i,:il/Gand(i!ll'i)::>i50.).hhni, NGA TechnicalReportTR8350.2, January 2000.T. Bray, Extensible Markup Language (XML) 1.0 (Third Edillon),htlp:llwww.w3.ol·g/;.~.!<ii:; .:;!i. W3C REC-XML-20040204, February 2004.Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Slgnalure Syntax andProcessing, .: 'iJ/ fiU:\:: writ., "';J:ilul,'ii;)',cofe-20020212/, W3CRecommendation, February 2002.Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax andProcessing,htll:,:llwww.W3.orglTR/2002/REC-xmlenc-core-2002121 01, W3CRecommendMion, December 2002.

CAPN1.1Copyright © OASIS Open 2005. All Rights Reserved,

1 October 2005page6 of 35

WIT.039.001.0057

113 g g(~~OQlrro [PfJHull~e~~®~ ~[(1(Cn ~~©)nl1~®lg~~~ ~fi'U(O)~1\"'!rU(QJfiQITlf1J@l~~~@~

114 z,~ [iJ~si~ru Phih)$iDphy115 Among the principles which guidedthe design of theCAPAlertMessage were:

116 0 Interoperability - Firstand foremost, the CAP AlertMessage should provide a means for117 interoperable exchange of alerts andnotifications amohg all kinds of emergency Information118 systems.119 0 Completeness - TheCAPAlertMessage format should provide for all theelements of an120 effective publlcwarnln", message.

121 0 Simple Implementation - Thedesign should notplace undue burdens ofcomplexity on122 technical implementers. .

123 0 Simple XlIIlL and portable structure - Although theprimary anticipated use of the CAP Alert124 Message Ieas anXMLdocument, the format should remain sufficiently abstract to be adaptable125 to othercoding schemes.126 0 Multl-ua& fonnat - Onemessage schema supports multiple message types (e.g., alert! update!127 cancellations I acknowledgements! errormessages) Invarious applications (actual! exercise!128 test! system message.)129 G Familiarity - The dataelements and code values should bemeaningful towarning originators130 andnon-expert recipients alike.131 0 Inltrdllclpllnary artdlnternatlonal utility - Thedesign should allow a broad range of132 applications In public safety andemergency management and allied applications andshould be133 appllcabl~ worldwide.

134 ~.~ ~sqQ,d&'emlt:lfll~$ fior Desig8IJ135 Note: ThefollowIng requirements wereused as a basis fordesign and review of the CAP136 AlertMessage format. This list Isnon-normative and notintended to beexhaustive.

137 TheCommon Alerting Protocol SHOULD:138 '" Provide a specification for a simple, extensible format for digital representation of warning139 meSsages and notlflcatlons;140 '" Enable Integration of diverse sensor and dissemination systems;

141 0 Beusable over multiple transmission systems, including both TCPIIP-based networks and one-142 way"broadcast" channels;143 o Support credible end-to-end authentication and validation ofall messages;

144 e Provide a unique identIfier (e.g., an ID number) foreach warning message and for each message145 originator;146 e Provlde formUltiple message types, such as:

147 - Warnings148 - Acknowledgements149 - Expirations andcancellations150 - Updates and amendments151 - Reports of results fromdissemination systems152 - Administrative and system messages

153 0 Provide formultiple message types, such as:

CAP·V1.1Copyright II:) OASISOpen2005. All Rights ReselVed.

1October 2005Page7 of 35

WIT.039.001.0058

154 - Geographic targeting155 - Levelof urgency156 - Level of certainty157 - Levelof threatseverity

158 "Provide a mechanism for referencing supplemental information (e.g,. digital audio or Image files,159 additional text);

160 0 Usean established open-standard data representation;

161 0 Be basedona program of real-world cross-platform testing and evaluation;

162 Q Providea clearbasis fer certification andfurther protocol evaluation and Improvement; and,

163 o Provide a clearlogical structure that is relevant and clearly applicable to theneeds of emergency164 response and public safety users andwarning system operators.

165 ~DJ ~~SJm~O>~®$ ©~ Uh$~ ~C®llUtBJlT!(0~

166 Note: The follOWing examples of use scenarios were usedas a basis for design and167 review of the CAPAlertMessage format. These scenarios arenon-normative and not168 intended to be exhaustive or to reflectactual practices.

169 ~D~D '\I M~~U21! Olti~ifl1l21\thjlf{iJ

170 "The Incident Commander atan industrlal firewithpotential of a majorexplosion decides to issue a public171 alert withthree components; a)An evacuation ofthe area within halfa mileof the fire; b) a shelter-in-172 place instruction for people Ina polygon roughly describing a downwind dispersion 'plume' extending173 severalmilesdownwind andhalfa mile upwind from thefire; andc) a request for all media and civilian174 aircraftto remain above 2500 feetaboveground level when within a halfmileradius of the fire.175 "Usinga portable computer anda web page(and a pop-up drawing toolto enterthepolygon) the Incident176 Commander Issues the alertas a CAP message toa local alerting network."

177 ~D~.2 Au~oma1ed Origina~i(m by AuioriomollJs SenSOi" Sysiarri178 "A set of automatic tsunami warning sirens has been Installed along a popular NorthWest beach. A179 wirelessnetwork of sensor devIces collocated with thesirens controls theiractivation. When triggered,180 each sensor generates a CAP message containing its location andthesensed data at that locatlon that is181 needed for the tsunami determination. Eachsiren activates when the combination of its own readings and182 thosereported at byotherdevices on the network indicate anImmediate teunarnl threat. Inaddltion, a183 network component assembles a summary CAPmessage describing theevent and feeds it to regional184 and national alerting networks."

185 &;.~,3 Ag~u'~gBl'ldon o:ulld CO~Tsl;''ij;loru on Re~iu'lime M~p

186 "At the StateOperations Center a computerized map of thestate depicts, in realtime, all current and187 recent warning activity throughout the state. All major warning systems in thestate - the Emergency188 Alert System, siren systems, telephone alerting and other syetems -« haVe been equipped to report the189 detailsof theiractivation in theform of a CAPmessage. (Since many of them arenow activated byway190 of CAP messages, this is frequently just a matter of forwarding the activation message to thestate191 center.)192 "Using this visualization tool,state officials can monitor foremerging patterns of local warning activity and193 correlate It withotherreal timedata{e.g., telephone central office traffic loads, 9-101 traffic volume,194 seismic data, automatic vehicular crashnotifications, etc),"

195 ~.3,4 1i1i:\S@i'&~~d P,"!bil~ f.\iGw~iu·i~

196 •As partof an Integrated warning system funded bylocal industry, all warning systems Ina community197 can beactlvated simultaneously by the issuance byauthorized authority of a single CAP message.

CAP-V1.1Copyrlght@ OASISOpen 2005. AllRights Reserved.

1 October 2005Page 8 of 35

WIT.039.001.0059

198 "Eachsystem converts the CAP message dataintothe form suitable for its technology (text captioning on199 TV, synthesized volceon radio andtelephone, activation of the appropriate signal onsirens, etc.).200 Systems thatcan targettheir messages to particular geographIc areas -Implement the targeting specified201 in the CAPmessage with as little 'spill' as theirtechnology permits.202 "In this way, notonlyIs the reliability and reach of theoverall warning system maximized, butcitizens also203 get corroboratlon of the atertthrough multiple channels, which increases thechance of thewarning being204 actedupon."

205 ~t3,~ Repu~cli~v.nffil~ 8l FI~~r.e AiE:HT~\

206 "Inadvertently the integrated alerting network hasbeen activated with anInaccurate warning messaqe,207 This activation comes to officials' attention immediately through theirown monitoring facilities (e.g., 2.3.3208 above). HavIng determined that the alert is, in fact, Inappropriate, the officials Issue a cancellation209 message thatrefers directly to the erroneous prior alert. Alerting systems thatarestili in theprocess of210 delivering thealert(e.g., telephone dialing systems) stop doing so. Broadcaslsystemsdellverthe211 cancellation message. Other systems (e.g., highway signs) simply reset totheirnormal state."

CAP·V1.1COpyright e OASI S Open 2005, All Rights Reserved.

1 October2005Page9 of 36

WIT.039.001.0060

alertMessage 10 (identifil\!r)Sender ID (sender)Sellt Date/Time (sent) Elell1ents Inboldface are

Message status (status) mandatory; elements in italics

Message Type (msgType)have default values thatwillbeassumed If the element Is not

source (source) present: asterisks n Indicatescope (scope) that multiple Instances areRestriction (restrictlon) permitted,

Addl'esses (addresses)Handling Code (code) ..Note (note)Reference IDs(references)Incident IDs (Incidents)

4

*info resourceLal1guag~ (language) Descril)tiollEvent Category (category) * (rescurcepesc)

Evel1t Type(event) * MIME Type (mhneTyI>e)

Response Type(response'lype) ..IV

File Size (size)

Ul'gency(urgency) URI (uri)

Severity (severity) Dereferencecl URI (del'efUI'I)

Certainty (certainty)' Digest (digest)

Audlence (audience)Event Code (eventCode)"Effeotlve DatelTlme (effective) areaOnsetDatelTime (onset) Area DescriptionExpiration Datemme (expires) (areaDesc)

Sender Name (sencierName) * Area Polygon (polygon) .,

Headline (headline) Area Circle (circle) ..

Event Description (description) Area Geooode (geooocte)"

lnstructlone (Instruction) Altkucle (altitude)

Information URL (web) Ceiling (ceiling)

Contact Info(contact)Parameter (parameter) •

214

CAP-V1.1Copyright@ OASISOpen2005. All Rights Reserved.

1 October 2005Page 10of 35

WIT.039.001.0061

215 ~D~ [Q)£l~~ gn@~8@U1~rfY'

216 Note: Unless explicitly constrained within this Data Dictionary or theXML Schema217 (Section 3.4), CAPelements MAY have null values, 'Implementers MUST check for this218 condition wherever It mightaffectapplication performance.

219

Element Context Class. Definitionand Notes or ValueDomainName Attribute; (Optlonality)

Representation

~,~/U "~i0~"1:" t~!ern~n~: 5lR1d §tlb>"e!8~ti~(S1ir1:$1)

alert cap. The container (1) Surrounds CAP alert message sub-alert. for all elements

component (2) MUST Include thexmlns attributegroup

parts of the referencing theCAP URN asthealert message namespace, e.g.:(REQUIRED) <cap ,alert

xmlna: cap""urn I oasis I names, tc: emergency:capI1.1 n,.

(sub-elements)</oap:alerb

(3) In addition to the specified sub-elements, MAY contain one or more<Info> blocks.

Identifier caP· Theidentifier (1) A number orstring uniquely identifyingalert. oHlle alert thismessage, assigned bythe sender

message (2) MUST NOT Include spaces, commas or

identifier(REQUIRED) restricted characters « and &)

sender cap. Theidentlfier (1) Identifies theoriginator of this alert.

alert. of the sender Guaranteed byassigner to be unique

sender.of the alert globally; e.g., may be based onanmessage Internet domain name

Identifier (REQUIRED) (2) MUST NOT Include spaces, commas orrestricted characters « and&)

sent cap. Thet/meand (1) Thedate and time Is represented inalert. dateof the [dateTime] format (e. g.,"2002- 05-

sel1t.origination of 24T16: 49: 00-07: 00" for24 May 2002 atthe alert 16: 49 PDn.

time message (2) Alphabetic llmezone designators such(REQUIRED) as"Z" MUST NOT be used. ThetimezoneforUTe MUST berepresented as "·00:00"or "+00:00.

CAPN1.1Copyright © OASIS Open 2005, All Rights Reserved,

1 October 2005Page11of35

WIT.039.001.0062

Elemei'lt Content. Clas$. Definition and Notes or Value DomainName Attribute. (Optlonality)

Representation

status cap. The code Code Values:

alert. denoting the "Actual" - Actionable by all targeted

status.appropriate recipientshandling of

code the alert "Exercise"· ActIonable only by designatedmessage exercise participants; exercise identifier(REQUIRED) should appear In <note>

"System" • For messages that supportalertnetwork Internal functions.

"Test"· Technical testing only, allrecipients disregard"Draft" - A preliminary template or draft,not actionable in Itscurrentform.

msgType cap. The code Code Values:

alert. denoting the "Alert" • Initial Information rsqutrlnqnature of the attention by targeted reclplentstype. alert message

code (REQUIRED) "Update" - Updates andsupercedes theearliermessage(s) identified in<references>"Cancel" • Cancels the earliermessage(s)Identified In <references>"Ack" • Acknowledges receipt andacceptance of the message(s» identifiedin <references>"Error" indicates rejection of themessage(s) Identified in <references>;explanation SHOULD appear in <note>

source cap. Thetext Theparticular source of this alert:e.g.,an

alert. identifying the operator or a specific deVice.sourceof the

source. alert messageidentifier (OPTIONAL)

scope cap. The code Code Values:

alert. denoting the "Publip" • Forgeneral dissemination tointended unrestricted audiencesscope. distribution of

code the alert "Restricted" • For dissemination only tomessage users witha known operational(REQUIRED) requirement (see<restriction>, below)

"Private" • Fordlssemlnatlon only tospecified addresses (see<address>,below)

CAp·V1.1Copyright © OASIS Open2006. All Righte Reserved.

1October 2005Page12of 35

WIT.039.001.0063

Element Context. Class. Definition and Notes 01' ValueDomainName Attribute. (Optlonallty)

Representation

restriction cap. Thetext Used when<scope> value is "Restricted"alert. describing the

restriction.rulefor limitingdistribution of

text the restrictedalertmessage(conditional)

addresses cap. Thegroup (1) Used when <scope> valua is "Private"alert. listing of (2) Each recipient SHALL beidentified by

Intendedaddresses. recipients of

an identifier or anaddress

group theprivate alert (3) Multiple space-delimited addressesmessage MAY be Included, Addresses Including(conditional) whltespace MUST beenclosed in

double-quotes.

code cap. Thecode (1) Any user-defined flag orspecial codealert. denoting the used to flagthe alert message for

special special handling.code handling ofthe (2) Multiple Instances MAY occur within a

alertmessage single <Info> block.(OPTIONAL)

note cap, Thetext Themessage note Isprimarily Intended foralert. describing the usewith Cancel and Error alert message

note.purpose or types.significance of

text the alertmessage(OPTIONAL)

references cap. Thegroup (1) Theextended message identifler(s) (inalert. listing the formsender, Identifier, sent) of an

references.identifying earlierCAP message ormessagesearlier referenced bythis one,

group message(s) (2) If multiple messages are referenced,referenced by theySHALL beseparated bythe alert whitespace.message(OPTIONAL)

CAP-V1.1Copyright © OASiS Open 2006. All Rights Reserved.

1 October 2005Page 130f35

WIT.039.001.0064

Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optionality)

Representation

incidents cap. Thegroup (1 ) Used to collate multlple messagesalert. listing naming referring to different aspectsof the

Incidents.thereferent same incidentincident(s) of (2) If mUltiple Incident Identifiers are

group thealert referenced, they SHALLbe separatedmessage bywhltespace. Incident names(OPTIONAL) including whltespace SHALLbe

surrounded by double-quotes

~"~"~ "nutii\/u EU€ih-dl@ur2 ~;iU-lil~ f~QtiLHtJi®u'iiiltBr{~;:s

info cap. Thecontainer (1) Multiple occurrences are permittedalertlnfo. for all within a single <alert>. If targeting of

info.component multiple "info" blocks in the sameparts of the info language overlaps, information In later

group sub-element of blocks may expand but maynotthealert override thecorresponding values Inmessage earlierones. Each set of "info"blocks(OPTIONAL) contaIning the same language Identifier

SHALL betreated as a separatesequence.

(2) Inaddition to the specified sub-elements, MAY contain one or more<resource> blocks and/or oneor more<area> blocks.

language cap. Thecode (1) Code Values: Nalurallanguagealertlnfo. denoting the identifler per[RFC 3066].

language.language of the (2) If notpresent, anImplicitdefault valueinfosub- of lien-US" SHALL be assumed.

code element of thealertmessage (3) A nullvalue in thiselementSHALL be(OPTIONAL) considered equivalent to "en-US."

CAP-V1.1Copyright C> OASIS Open2005. All Rights Reserved.

1 October 2005Page 14 of35

WIT.039.001.0065

Element Context. Class. DefinitIon and Note!! Oi' Value DomainName Attribute. (Optlonality)

Representation

category cap. The code (1) CodeValues:alertlnfo. denoting the "Geo" - Geophysical (Inc. landslide)

category ofcategory. the subject "Met"- Meteorological (inc. flood)

code event of the "Safety" • General emergency andpubllcalert menage safety(REQUIRED) "Securtty" - Lawenforcement, military,

homeland and local/private security

"Rescue" - Rescue and recovery"Fire" " Firesuppression and rescue

"Health" - Medical and public health"Env" • Pollution and otherenvironmental

"Transport" - Publicand privatetransportation

"Infra"· Utility, telecommunication, othernon-transport infrastructure

"CBRNE" - Chemical, Biological,RadiologIcal, Nuclear or High-YieldExplOsive threator attack"other" • Otherevents

(2) Multipleinstances MAY occurwithin asingle<info> block.

evel1lt cap. The text

alertlnfo. denoting the

event.type of theSUbject event

text of the alertmessage(REQUIRED)

CAp·V1.1 .Copyrlght@ OASISOpen 2005. All Rights Reserved.

1October2005Page 15 of 35

WIT.039.001.0066

'\

"'. 'j -.

EIGmGn~ Conteltl. Claise. Definition and Notes or Value DomainName Attribute. (Optionallty)

Representation

responseType cap, The code (1) Code Values:alel1lnfo, denoting the "Shelter' - Take shelter Inplace or perresponseType.

typeof action <instruction>recommended

code for the target "Evacuate" - Relocate as Instructed in theaudience. <Instruction>(OPTIONAL) "Prepare" - Make preparations per the

<instruction>"Execute" - Execute a pre-planned activityidentified in <Instruction>"Monitor" - Attend toInformation sourcesas described In<Instruction>"Assess" - Evaluate the Information in thismessage. (This value SHOULD NOTbeusedin public warning applications.)"None" - Noaction recommended

(2) Multiple instances MAY occurwithinasingle<Info> block.

urgency cap. The code (1)The"urgency" I "severity", and "certainty"alertlnfo. denoting the elements collectively distinguish less

urgency.urgency of the emphatic from more emphatic messages,subject event (2) Code Values:

code of the alert"Immediate" - Responsive actionmessage

(REQUIRED) SHOULD betaken Immediately"Expected" ~ ResponsIve action SHOULDbe taken soon (within nexthour)"F.uture" - Responsive action SHOULD betaken In thenear future"Past" - Responsive action Is no longerrequired"Unknown" - Urgency notknown

CAP-Y1.1Copyright© OASISOpen2005, All Rights Reserved,

1 October2005Page 16of 36

WIT.039.001.0067

Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optlonallty)

Representation

severity cap. The code (1) The "urgency", "severity" I and "certainty"alertlnfo. denoting the elements collectively dl&tlngulsh less

severity.severity of the emphatIc from more emphatic messages.subject event (2)Code Values:

code ofthe alertmessage "Extreme" • Extraordinary threat to life or(REQUIRED) property

"Severe" • Significant threat to lifeorproperty"Moderate" - Possible threat to lifeorproperty"Minor" • Minimal threat to lifeor property·Unknown" • Severity unknown

certainty cap. The code (1) The "urgency', "severity", and "certainty"alertlnfo. denoting the elements collectively distinguish less

certainty.certainty of emphatic from more emphatic messages.the subject (2) Code Values:

code event of theatert message "Observed" - Determined to have(REQUIRED) occurred or to be ongoing.

"Likely" • Likely (p >-50%)"Possible" - Possible butnotlikely (p <=-50%)"Unlikely" - Not expected to occur (p - 0)"Unknown" - Certainty unknown

(3) Forbackward compatibility with CAP1,0, thedeprecated value of "Very Likely"SHOULD betreated asequivalent to"Likely."

audience cap. Thetextalertlnfo. describing the

Intended.audience. audience of thetext alertmessage

(OPTIONAL)

CAP·V1.1Copyright© OASISOpen 2005. All Rights Reserved.

1 October2005Page 17of 35

WIT.039.001.0068

Elament Context. Class. Definition and Notes 01' Value DomainNama Attribute. (Optianallty)

Representi'iioi"l

eventCode cap. A system- (1) Any system-specific codefor eventalertlnfo. specific code typing, in the form:

event.identifying the <eventCode>eventtype of

code the alert<valUeName>valueName</valueName>

message <value>value</value>

(OPTIONAL) </eventcode>

wherethe content of "valueName" Is a user-assignedstring designating the domainofthe code, and thecontent of "value" is astring (which may represent a number)denoting the value itself(e.g., valueName="SAME" andvalue="cEM" ) .

(2) Valuesof "valueName" that areacronyms SHOULD berepresented In allcapital letterswithout periods (e.g.,SAME,FIPS,ZIP).(3) MultipleInstances MAYoccur Within asingle<Info> block.

effective cap. Theeffective (1) The dateandtime is represented in

alertlnfo. timeoftha [dateTlme] format (e. g., "2002-05-

effective.Information of 24T16: 49 :00-o7:00"for 24 May 2002 atthe alert 16: 49 PDT).

time message (2) Alphabetic tlmezone designators such(OPTIONAL) as liZ"MUSTNOT beused. The timezonefor UTC MUST be represented as "-00:00"or "+00:00.

(3) if this Item is not included, the effectivetime SHALL be assumed to be the sameasIn <sent>.

onset cap. Theexpected (1) The dateand time 1s represented In

alertlnfo. timeof the [dateTlme] format (e. g., "2002- 05-

onset.beginning of 24Tl6: 49: 00-07: 00"for 24 May2002 atthe SUbject 16:49 PDT).

time event of the (2) Alphabetic timezone designators suchalertmessage as "Z" MUSTNOT beused. The timezone(OPTIONAL) for UTe MUST be represented as "-00:00"or "+00:00.

CAP·V1.1Copyright © OASIS open 2005. All Rights Reserved.

1 October 2006Page 18 of36

WIT.039.001.0069

Element Context, Class. Definition and Notes or ValueDomainName Attribute. (Optlonallty)

Representation

expires cap. The expiry time (1)ThedateandtimeIs represented inalertlnfo. of the [dateTime]format (e. g., "2002-05-

expires.information of 24T16: 49: 00-07: 00" for 24 May 2002 atthe alert 16:49 PDT).

time message (2)Alphabetic tlmezone designators such(OPTIONAL) asoZ' MUST NOT beused. The timez.onefor UTe MUST be represented as "·00:00' .or "+00:00.(3) If thisItem Isnot provided, eachrecipient Isfreeto setItsownpolicy as towhen themessage is no longer in effect.

senderName cap. The text The human-readable name of theagency oralertlnfo. naming the authority Issuing this alert.

sander.originator ofthealert message

name (OPTIONAL)

headline cap. The text A briefhuman-readable headline. Note that

alertlnfo. headline ofthe some displays (forexample, short

headline.alert message messaging service devices) may only(OPTIONAL) present thisheadline; It SHOULD bemade

text asdirect and actionable aspossible whileremaining short, 160characters MAY beauseful target limitfor headline length.

description cap. The text Anextended human readable description of

alertlnfo. describing the thehazard oreventthat occasioned this

description.eubject event message.ofthe alert

text message(OPTIONAL)

instruction cap. The text Anextended human readable Instruction toalertlnfo. describing the targeted recipients. (If different instructions

recommended areintended for different recipients, theyinstruction. actionto be should be represented by useofmultipletext taken by <Info> blocks.)

recipients ofthe alertmessage(OPTIONAL)

CAP-V1.1Copyright © OASISOpen2005. All Rights Reserved.

1October2006Page19 of 36

WIT.039.001.0070

IElem\\;nt Context. Class. Definition and Notes Of Vaiue DomainName Attribute. (Optionality)

Representation

web cap The identifier of A full, absoluteURIforan HTML page oralertlnfo. the hyperllnk othertext resource with additional or

Information.associating reference information regarding this alertadditional

Identifier informationwiththealertmessage(OPTIONAL)

contact cap. Thetextalertlnfo. describing the

contact forcontact, follow-up andtext confirmation of

the alertmessage(OPTIONAL)

parameter cap. A system- (1)Any system-specific datum, in the form:alertlnfo. specific <parameter:>

parameter.additional <valueName:>valueName< !valueName:>parameter

group associated with <value:>value<!value>

the alert <!parameter:>message wherethe contentof"valueName" Is a(OPTIONAL) user-asslqned string designating the

domain of the code, and thecontent of"value" Is a string (Which may represent anumber) denoting the value Itself(e.g.,valueName .,"SAME" and value="clv".)

(2)Valuesof lvalueName" thatareacronyms SHOULD berepresented In allcapital letterswithout periods (e.g., SAME,FIPS, ZIP),(3)Multiple instances MAY occurwithinasingle <info> block.

CAP-V1.1Copyright© OASIS Open 2005. All Rights Reserved.

1 October2005Page 20of 35

WIT.039.001.0071

Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optlonallty)

Representation

~,~,3 oOf®~©\L.!i"C~H IEla~"i(1i~:rit ~b"i@ Suboo@lem®i'u~$

resource oap Theoontainer (1)Refers to an additional file with

alertlnfoResource. for all supplemental information related to thisoomponent <info> element; e.g.,an Image or audio file

resource. partsof the (2)MUltiple ocourrences MAYoccur within agroup resource sub- single <info> block

element of theinfo sub-element of thealertelement(OPTIONAL)

resourceDesc cap. The text Thehuman-readable text describing thealertlnfoResource. describing the content andkind, suchas "map" or "photo,"

type and of the resource file.resourceDesc. content of thetext resource file

(REQUIRED)

mlmeType cap. The Identifier of MIME content type andSUb-type asa1ertlnfoResource. theMIME described In [RFC2046]. (Asof this

mimeType.content type document, thecurrentlANA registeredand SUb-type MIME types are listedat

identifier describing the http://wwW.lana.org/assignmentsJmedla-resource file types/)(OPTIONAL)

size cap. The integer ApproXimate sizeof the resource file in

alertlnfoResource. indicating the bytes.sizeof the

size. resource fileinteger (OPTIONAL)

uri cap. The identifier of A full absolute URI, typically a UniformalertlnfoResource. the hyperlink Resource Locator that can be used to .

for the retrieve the resource over the Interneturi. resource file ORidentifier (OPTIONAL)

a relative URI to name the content ofa<derefUri> element if one is present In thisresource block.

CAP·Vl.1Copyright @ OASISOpen2005, All Rights Ressrved.

1October 2005Psge 21 of35

WIT.039.001.0072

Elameri'1: Context. ClaGOl. Definition and Notes ci'Value DomainName Attribute. (Optionality)

Representation

derefUrl cap The base-64 (1)MAYbe used either with or insteadofalertlnfoResource. encoded data the <uri> element in messages transmitted

derefUri.contentofthe overone-way (e.g., broadcast) datalinksresource file where retrieval of a resource via a URI is

data (CONDITIONAL) not feasible.(2)Clients Intended forusewith one-waydatalinks~UST support this element.(3)Thiselement MUST NOTbe usedunless the senderis certain that all directclients are capable ofprocessing it.

(4) If messages including this element areforwarded onto a Wlo-way network, theforwarder MUST strip the<derefUri>element and SHOULD extract the filecontents and provide a <uri> link to aretrievable version ofthe file.(5)Providers of one-way data linksMAYenforce additional restrIctions on the useofthiselement, including message-size limitsand restrictions regarding file types.

digest cap. The code Calculated usingtheSecure HashalertlnfoResource. representing Algorithm (SHA-1) per [FIPS 180-2]

digest.the digitaldigest ('hash")

code computed fromthe resourcefile(OPTIONAL)

~,~,<Q. ".~)lu,(:~ffi" l:k~IJ~(·m'i: 8,mJ t';Ub"8~Ii~u~,:&Ht;'J

area cap. The container (1) Multiple occurrences permitted, InwhichalertlnfoArea. forall case the targetarea forthe <Info> blockis

component the union of all the Included <area> blocks.area. parts of the (2) MAY contain oneormultiple Instancesgroup area sub- of <polygon> I <circle> or<geocode>. If

element of the multiple <polygon>, <circle> or <geocode>info sub- elements are Included, theareadescribedelement ofthe by this<area> is theunion of thesealert message represented by the lncluded elements.(OPTIONAL)

CAP·V1.1Copyright© OASIS Open 2005. All Rights Reserved.

1 October2005Page 22 erss

WIT.039.001.0073

element Context. Class, Definition and Notes or Value DomainName Attribute. (Optionality)

Representation

areaDesc cap. The text A text description of theaffectedarea.

alertlnfoArea. describing theaffected area

area. of the alerttext message

(REQUIRED)

polygon cap, Thepaired (1) Code Values: Thegeographic polygon is

alertlnfoArea. values of points represented by a whitespace-delimited list

polygon.defining a of [WGS 84] coordinate pairs. (SeeWGS-polygon that 84 Noteat endof thissection.)

group delineates the (2)Thefirst andlast pairs of coordinatesaffected area of MUST be the same.thealert

(3) SeeCoordInate Precision Noteatendofmessage(OPTIONAL) thissection.

(4)MUltiple Instances MAYoccur within an<area>.

circle cap. Thepaired (1)Code Values: ThecircularareaIsalertlnfoArea, values of a represented by a central point given as a

circle.pointand [WGS·84] coordinates pair followed by aradius space character andaradiusvalueIn

group delineating the kilometers. (See WG$-84 Note at end ofaffected area of thissection.)thealert (2)SeeCoordinate Precision Noteat end ofmessage thissactlon.(OPTIONAL)

(3)MUltiple Instances MAYoccurwithin an<area>.

CAP-V1.1Copyright@ OASISOpen2006. All RightsReserved.

1 October2005Page 23of35

WIT.039.001.0074

Ellitmeil~ Context Class. Definition and Notes or Value Domai~

Name Attribute. (Optionality)Representation

gaocode cap. The geographic (1)Anygeographically-based code toalertlnfoArea. code describe message target area:

geocade.delineating the <parameter>affectedarea of

code the alert <valuaName >va1 ueName<!valueName>

message <value>va 1ue<!value>

(OPTIONAL) </parameter>

where the content of "valueName" Isa user-assigned string designating thedomain ofthecode, and the content of "value" is astring (which may represent anumber)denoting thevalue itself(e.g., valueName""!SAME" andvalue:::"oo6113").

(2)Values of"valueName" thatareacronyms SHOULD berepresented In allcapital letters withoutperiods (e.g., SAME,FIPS, ZIP).(3) Multiple instances MAY occur withinasingle <info> block.(4) This element Is primarily forcompatibilitywith othersystems. Use ()fthis elementpresumes knowledge of thecoding systemonthe partof recipients; therefore, forinteroperability, It SHOULD be used Inconcert withan equivalent description In themore universally understood <polygon> and<circle> forms whenever possible.

altitude cap. The specific or (1) If used with the <ceiling> element thIsalertlnfoArea. minimum value is the lowerlimitof a range.

altitude.altitude of the Otherwise, thisvaluespecifies a specificaffected area of altitude.

quantity the alert (2)The altitude measure is in feetabovemessage mean sealevel per the[WGS. 84] datum.(OPTIONAL)

ceiling cap. The maximum (1) MUST NOT be used except InalertlnfoArea. altitude of the combination with the <altitude> element

affected area of (2) The ceiling measure IsIn feet aboveceiling. the alertquantity message

mean sealevel per the(WGS· 84] datum.

(conditional)

CAP·V1.1Copyright © OASISOpen2005. All Rights Reserved.

1 October2005Page24of 35

WIT.039.001.0075

220

221

222223224225

226

227228229230231232233234235

236

237238239240241242243244245

246

247248249250

3,3. 11 WGS~84 Not~

Geographic locations in CAP are defined using [WGS 84] (World Geodetic System 1984), equivalent toEPSG (European PetroleumSurvey Group) code 4326 (2 dimensions). CAP does not assignresponsibilities for coordinatetransformations from and to other Spatial Reference Systems. See section1.5 Terminology for the format of coordinate pairs within CAPelements.

3.3.2 Security No~e

BeCE,use CAP is anXML-baaad format, existing XML security mechanisms canbeusedto secureandauthenticate its content. V\lhile these mechanisms areavailable to secure CAP Alert Messages, theyshouldnotbe used Indlsorlmlnately.Note thatthis section adds two tags to CAPby referenoe. These are: "Signature and "EncryptedData".Both elements arechildrenof the <alert> element and are optional. If tl1e "EncryptedData" elementexists, no other elements will be visibleuntilafterthe mesaage Is dectYpled. ThIs makes the minimalCAP message analertelement which encloses an EncryptedData element. Themaximal CAP message,if an EnoryptedData element is present is an <alert> element enclosing asingle EncryptedData elementand a single Signature element.

3.3.:U DigitalSignaiures

The alertelement of a CAP Alert Message MAYhave an Enveloped Signature, asdescribed by XML·Signature andSyntax Processing [XMLSIG]. Other XMLsignature mechanisms MUST NOT be used inCAP Alert Mesl3ages.Processors MUST NOT reject a CAPAlert Message containIng such a sIgnature simply because theyarenot capable ofverifying it; they MUSTcontinue processing and MAY Inform theuser of their failuretovalidate thesignature.In otherwords, the presenceof an element withthe namespace URI [XMLSIG] and a localnameof·Signature" asa child of the alert element mustnot cause a processor to fallmerely because of itspresence.

3.3.2.2 EncryptioilThe alertelement of a CAP Alert Message MAY be encrypted, using themechanisms described by XMLEncryption Syntax and ProcessingIXMLENC]. Other XML encryption mechanisms MUST NOTbe usedin CAPAlertMessages; however, transport-layer enoryptlon mechanisms may beused Independently ofthis requirement.

<?xrnl version .. "1.0" encoding .. "UTF-8"?><schema xmlns " ''http://www.w3.org/2001/XMLSchema''

targetNamespace = "urn: eas is lOam!!lS Jtc: emergency: cap, 1.1"XI\11ns Jcap .. "urn: oasis Jnames J tc: smergency: cap: 1.1"xmlrts, xe .. "httpJ //www.w3 •org/2001/XMLschema"elerrtentFormDefault .. "qualified"attributeFor:mPefault = "unqualified">

<element name .. "alert"><annotation>

<dodumentation>CAP Alert Message (version 1.1)</documentation></annotation><complex'rype>

<sequence><element; name" "identifier" type" "string"/><element name .. "sender" type .. "string"/><element name .. "eent" type .. "dateTime"/><element name .. "status">

<simpleType><restriction base .. "string" >

<enumeration value .. "Actua1"1>

CAP-V1.1Copyright@OASIS Open 2005. All Rights Reserved.

1 October2005Page25of35

WIT.039.001.0076

"unbounded">

.. "unbounded" / >

"Exercise" I,"System"/>"Test"!>"Draft"l>

veluevaluevaluevalue e

"restriotion" type 0 "string" minoocurs " "0"1>"addreaSf;ls" type = "string" minoccurs • "0"/>"code" type = "string" minocours " "0" maxOccurs"note" tYl?f;I .. "string" minoccurs u "0"1>"references" type w "string" minOccurs " "0"1>"incidents" type "I'tring" minOcours e "0"1>"info" minoccurs = "0" ma,x,Oocurs ~ "Unbounded">

<enumeration<enumeration<enumeration<enumeration

</restriction><!simpleT¥1'e>

</element><elemf;lnt name. "msgType">

<simpleType><restriction base .. "lOtrin9">

<enumeration value "Alert"l><enumeration value ~ "update"l><enumeration value "Cancel"l>"enumeration valuf;l "Ack"!><f;lnumeration value ~ "Error"!,

"/rf;l5tr10tion></simpleType>

"/f;llement><element name II:l lIsourcell type r=l- '!string " minOccurs • l!OIl/><element name .. "soope">

<simpleType><;restrlction base .. "string">

<enumf;lration value .. "public"l><enumeration value "Restricted"l><enumerat1on value. "private"l>

</rel'triction></l'imple'I'ype>

</element><element name<element name ..<element name<element name ..<elemf;lnt name '"<elemf;lnt nams ..<element name "

<complexType><sequf;lnce>

"element name .. "language" type .. "lenguagf;l" daf auLt; .. "en-US" minOcou~'B • "O"!,<element name .. "oategory" rnaxOccurs .. "unbounded">

<simple'l'ype><reatdction base .. "string'>

<enumeration value .. "Geo-I><enumeration value ~ "Met'l>"enumeration value e "Safety"!><enumeration valuf;l ~ "Security"/><enumeration value e "Rescue"!"<enumf;lration value e "Fire"l><enumeration value e "Health"I'"<enumeration value s "gnv'l><"numeration value "Transport'!><enumeration value .. "Infra"l><enumeration value ~ "CBRNE"/><enUmera.tion value e "other"l>

<h:estrioUon></simpleType>

</element><element name" "event" type ='string"l><element name = "reeponseType" minOocurs .. "0" maxOccurs

<eimpleType><restriotion base e "string">

<enumeration value .. "Shelter"I,<enUmeration va'Lue .. "Evacuate" I>"enumeration value ~ "Prepare"!><enumeration value "Execute"!'<f;lnumeration value "Monitor"!'"enumeration value ~ "None"l>

</restriotion'</simple'I'ype,

<I element><element name .. ·urgency">

<simpleType><restriction base· "string">

<enumeration valuf;I "Immediate"l>..enumeration value .. "Expected"l>"enumeration value. "Future"l><enumeration value "Past"l><enumex-ation value a "Unknown"!>

<!restriction><laimpleType>

"/element><element name" "severity">

<sirnple'type>

CAp·V1.1Copyrlght © OASISOpen2006. All Rights Reserved.

1 October 2006Page 26of 36

WIT.039.001.0077

"0"1,.

"0" maxOccurs .. "unbounded">

"resouroeDesc" type = "string"l>.. "mimeType" type" "string" minOccurs = "0" I>

"ei~e" type'" "integer" minOocurs = "0'1>.. "uri" type e "anyURI" minOccurs '" "0"1>

"derefUri" type = "string" minOccurs .. "0"1>" "digest" type = "string" minOccurs '" "0"1>

"effective" type" "dateTime" form .. "qualified" minOocurs"onset" type" "dsteTime" minOccurs = "0"1>"expires" type. "dateTime" minOccurs " "0"1,."senderName" type'" "string" minocours .. "0"1>"headline" type .. "string" minOccurs " "0"1>"description" type" "string" minOocurs " "0"1>"instructiori" type" "string" minoccurs = "0"1>"web" type = "anyORI" minOccurs = "0"1>"oontact" type " •string" minoccurs " "0" I>"parameter" minOcoure " "0" maxOccurs = "unbounded",.

~~restriction base" "string">~enumeration value .. "Extreme"l>~enumeration value ~ "Severe" I>~enumeration value "Moderate" I""enumeration value .. "Minor"l><enumeration value "Unknown"I"

~/rest:t'iction>

"/i.impleType,,~/element>~element name .. "certainty';>

"simp1eType>~re.. triction base", "string">

"enumeration value .. "Observed" I>~enume):ation value "Liltely" I><enumeration value "Possible"l>':enumera.tion value "Unlikely"l><enumeration value" "Unknown"l>

"/l:estriction>~/simpleType>

~/element><element name .. "audience" type" "string" minOccurs .. "0"1><element name .. "eventCode" minOccure .. "0" maxoccuxs " "unbounded">

"compleXType>"sequence,.

<element ref .. "cap,valueName"l>"element ref "cap,value"l>

</sequence><:/complexType>

</element>"element name<element name '""element name<element name ""element name<element name ..<element nB.l1le ..~element name ..~element name ..<element name ..

"complexType>"sequence>

"element l:'ef "cap,valueName"/"<element ref .. "cap,value"l>

"/eequence></complexTypa>

"/elemepl:>~element name .. "resource" minOocurs '" "0" maxOccurs " "unbounded">

"complexType~

~sequence>

"element name<element name<element name<element name<element name<element name

~/sequence>

"/complexType>~/element>"element name" "area" minOccurs

<complex'l'ype><sequence>

"element name "areaOesc" type" "string"l>"element name" "polygon" type" "string" minOcours '" "0" maxocouz-a " "unbounded"l><element name" "circle" type", "string" minOcours " "0" maxoccurs '" "unbounded" />"element name" "gaocade" minOccurs = "0" maxoccurs .. "unbounded">

"complexType"<sequence>

. "element ref" "cap,valueName"l>"element ref "cap,value"l>

"/aequenoe><:/complexType>

"/element>"element name '" "altitude" type = "string" minOcours " "0" I>~elemant name" "ceiling" type = "atring" minOccurs " "0"1>

</sequence></oomplexType>

</element></sequence>

</complexType><:Ielemen!:>

</sequence>"/camplexType>

CAP·V1.1Copyrighte OASIS Open 2005. All Rights Reserved.

1 Ootober2005Page 27 0135

WIT.039.001.0078

",jelement>",element name",element name

</schema>

"valueName" type D "string"/>"value" type e "string" />

CAP-V1,1Copyright © OASISOpen 2005. All Rights Reserved.

1 October2005Page 280135

WIT.039.001.0079

442

The following Isa speculative example in the form of a CAP XML message.

443

444

( .

< I tl C.I

<?xml version c "1,0" encoding ~ "UTF-B"?<alert xmlns = "\1Ill:oBlliSlnames:tc,emergencYlcap:l.l".

<identifier.43bOB07l3727<!identifier><sender>heesedhs.gov<!sender.<sent>2003-04.02T14,j9101-05:00<!sent.<status.Actual<!status><rnsgTyps>Alert<!msgType.<scope>Public<!ecops.<info>

<Category>Security</category><event>Homeland Seourity Advisory System Update<!event.<urgenoy>Irnmediats<!urgenoy.<severity>severs<!severity.<certainty.tikely<!certainty><sende~ame>U.S. Government, Department of Homeland Security</eenderNams.<beadline.Homslartd Security Bate Code ORANGE</headline><description.The Department of Homeland Security hee eleveted the Homeland Security Advisory

System threat level to ORANGE / High in response to intelligence which may indicate a heightenedthreat of terroriam.<!description>

<instruction> A High Condition is deoleu:ed when there is a high dslt of terrorist attacks , Inadditiort to the Proteotive Meaaures taken in the pre.·vioua Threat Conditions, Fe.deral departmentsand agertoies should oonsider agency-specifio Proteotive Measures in accordanoe with theirexieting.plans.</instxuction>

<web>http://www.dhs.gov/dhspublic/display?theme~29</web.

<par;l.meter><valueName>Ha~</valueName><value>ORANGE<!value>

</pal;ameter><resource.

<tesourceDeso>Image file (GIF)</resourceDesc><oxi.http,!!www.dhs.gov!dhspublic!getAdvisorylrnage<!uri>

</resource•<area>

<areaDeso>U.S. nationwide and interests worldwide</areaDesc.</area>

</info><!alert>

CAP·V1.1Copyrighl@ OASIS0PllO 2005. All Rights Reserved.

1 October 2005Page29 of36

WIT.039.001.0080

484

485

t o~ 0 r ~'\f®n'® i hlL%'U©®~'~'IIr"l)'~u'U (§llJ'rrufIi1L'

The following is a speculativeexample in the formof a CAPXML message.

<?xml version " "1. 0" encoding c "U'l'F-8"? ><alert xmlns c "urn:oasis,names,tc,Bmergency,cap,l.l">

<identifier>KST01055887203</identifier><sendar>[email protected]<laender><sent>2003-06-17T14,57,OO-07,Oo</sent><status>Actual</status><msgT~a>Alert</msgType><scope>Publio</scope>dnfo>

<category>Met</category>cevent>SEVERE ~EONDKRSTORM</event><responeeTypB>shelter</responsBType><urgency> Imrnediate</urgency><severity>8evere</savarity>ccertainty>Observed</certainty><eventCode><valu~ame>Bame</valueName><value>SVR</value>

</eventCode><expires>2003-06-17T16,OO,OO-07:00</expires><sBnqerName>NATIONAL WEATHER SERV1CE SACRAMENTO CA</eenderNeme><headline>SnVERE THUNOERSTORM WARNING</headline><description> AT 254 PM PDT .•. NATIONAL WEATHER SBRVICE DOPP~ER ~AR Ih~ICATED A SEVERE

THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY •.• OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD ... HOVINGSOUTllWBsT AT S MPH. HAIL•.. Im'ENSE RAUl AND STRONG DAMAGING WIND9 All!! LIKELY WI'!'H THISSTOnM.</geecription>

<instructiou>TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STORM PAS9ES.</inatruction><contactsBARUFFALDl/JUSKIE</contact> .<ax-ae>

<areaDeec>l'IX'I'REME NORTH CENTRAL TUOLUMNE COUNTY IN CALII.'ORNrA, EXTREH& NOR.TlIEASTERllCALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA</areaDesc>

<polY9on>38.~7,-120.14 38,34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120,14</polyson><geocod<;l>

<valueNama>FIPS6</valueName><value>006109</value>

</geocode><geocode"

<valueName" FIPS6< IvalueName><velue>006009</value>

</geocode><geoQode>

<valueName>PIPS6</valueName><value>006003</value>

</geocode></aree>

</info></alert>

CAP·V1.1Copyright © OASIS Open2005. All Rights Reserved.

1 October 2005Page 30 013.5

WIT.039.001.0081

l\ o'J. l.C&~ H q~J'(. lq,·C

The following is a speculative example in the formofa CAP XML message.

<?xml version" "1.0 '1 encodfnq 0= "tlTF-8"?><alert xmkns " "u:nlloasis :names : to, el1lergency,oap,l.l">

<identifier>TRI13970976.1</identifier.<sender>[email protected]</sender><sent>2003-06-11T20,56,OO-07,OO<!sent><status>~ctual</Btatus><msgType>~lert</me9Type>

<scopa>Public</ecope><incidents.13970876</incid~nts>

<info><category>Geo</category><event~Earthquake</event><urgsncy>Past</urgency.<ssverity>Minor</severity><certainty>Ohservad</certainty><send~rName>SouthernCalifornia'Seismic Network (TriNet) operated by Caltech and

USQS</eenderName><headline>EQ 3.4 Imperial County CA - PRELIMINARY REPORT</neadline><desoription>~ minor earthquake measuring 3.4 on the Riohter scale occurred near Brawley,

California at 8:53 PM Pacific Daylight Time on wednesday, June 11, 2003. {This is a computer­generated solution and has not 1st been reviewed by a human.)~/deecription>

<web>http.//www.trinet.org/ecsn/scen.html</web><parameter>

<valueName>EventlO</valueName><velue>13970876</value>

</pa.ramete:r><parameter>

~valueName.Ve:rBion</valueName>

<valus>l</value></parameten<parameter>

<velueName.Magnitude</valueName><valus>3.4 Ml</value>

</pa.ramete:r><parameter>

<~alueName>Depth</valueName>

<value>11.9 mi.</value></parameter><paral1leter> '

<valueName>Quslity</velueName><value.Excellent</valuB>

</paratneter><:area~

<areaDeac>1 mi. WSW of Brawley, CAl 11 mi. N of E1 Centro, CAl 20 mi. E of OCOTILLO(quarry) I 1 mi. N of the Imperial Fault</areaOeec>

<circle>32.9525,-115.5527 o</circle></area>

</info></alert>

CAP-V1.1Copyright@ OASIS Open 2005. All Rights Reserved.

1 October 2005Page31of35

WIT.039.001.0082

587

588

589590591592593594595596597598599600601602603604606606607608609610611612613614615616617618619620621622623624625

l ,dice l i:[[!;l t l@Ll (lui1C[~)]@;IKti( i (~ t \\,;U'(j'(§jU@L'l!j

The following is a speculative example in the form of a CAP XMLmessage.

<?xml version a "1.0" encoding ~ ·UTF-B"?;.<alert mnlns ,. "urn,oasia:names,tc,emergency:cap:1.1">

<identi£ier>KARO-0300112239-Sw</identifier><sender>[email protected]</sender><sent>2003-06-11T22,39:00-07:00</sent"<status;.Actual</status><msgType>Alert</msgType><source"SW</source><scope>?ublic</scope><info>

<category>~escue</categ6ry>

<event"child Abduction</event><urgency>Immediate</urgency><severity>severe</severity><certainty>Likely</oertainty><eventCods>

<valueName>S~</valueName>

<value>CAE</valus></eventCode><senderName>LOg ANGELES POLICE DEPT - LAPD</senderName><headline>AMBER ALERT</headline><description>DATE/TIME: 00/11/03, 1915 HRS. VICTIM(S), KHAYRI DOE JR. M/B 'BLK/BRa 3'0", 40

LBS. LIGHT COMPLBXION. DOB 06/24/01. WEARING RED SHORTS, WHITE T-SHIRT, W/BLUE COLLAR.LOCATION: 5721 DOE ST., L~S ~GELES, CA. SUSPECT(S): KHAYRI DOE SR. DOB 04/10/71 M/B, BLK HAIR,BRO EYE. VEHICLE, 81' BUICK 2·DR, BLUE (4XXXOOO) .~/desoription>

<contact>DET. SMI~H, 77TH DIV, LOS ANGELES POLICB DBPT-LAPD AT 213 485-2309~/contact>

<area><~reaDeec>Los Angeles County</areaDesc~

<geocode><valueName>BAME~/valueName>

<value>006037</value></geooode>

</arf!Ja></in£o>

</alert>

CAp·V1.1Copyright© OASISOpen2005. All Rights Reserved.

1 October2005Page32 of 35

WIT.039.001.0083

626 . 1-, IL l t

627 ("{).!~ [,[Ui"lfQ"'7n~y ~G[ l®~t tl: ,..1(~ltll L11.dtl.CC

628 JohnAerts, LA County Information Systems Advisory Body629 PattiAymond, IEM630 MarkBenemerlto, Sungard Availability Services631 Jeff Berg. Motorola632 Art Botterell, Partnership for PublicWaming633 ChrisBranton, IEM634 Rex Brooks, HumanMarkup.org, Inc.635 Thomas Sui.TheBoeing Company636 Len Bullard, Individual637 Charles Campbell, Individual638 Richard Carlton, IndivIdual639 EliotChristian, USDepartment of the Interior640 MarcConnolly, Oracle641 Robin Cover, OASIS642 Michael Daconta, USDepartment of Homeland Security643 David Danko, ESRI644 PaulDenning, Mitre Corporation645 JohnDias, Lawrence Livermore National Laboratory646 Matthew Dovey, Oxford University647 Sukumar Dwar!<anath. Individual648 ScottEdson, LA County Information Systems Advisory Body649 Nas.eamElkarra, Individual650 David, Ellis, Individual651 Paul Embley, Individual652 JackFox, US Department of Homeland Security653 Lawrence Freudinger, NASA654 Gary Ham, Disaster Management Interoperability Services655 Travis HUbbard, Disaster Management (nteroperabllity Services656 Stephen Jepsen, Oracle657 Elysa Jones, Warning Systems. Inc.658 Joyce Kern, Sungard AvailabJllty Services659 Hong-Eng Koh, SunMicrosystems660 JeffKyser, Warning Systems, Inc,661 Louis Lagonik, Lockheed Martin662 Kim Lambert, LMI Government ConSUlting663 RIchard Maslin,S, IBM664 Carl Mattocks, Individual665 Maurice McGinley, Individual.666 TomMerkle, Lockheed Martin667 80na Nasutlon, MTGManagement Consultants, LLC.668 Steve Ollis, Individual669 AshParikh, Raining Data Corporation670 Brian Pattinson, Unisys Corporation671 Gary Poindexter, IndivIdual672 Walid Ramadan, Individual673 Michelle Raymond, Individual674 Carl Reed, Open GIS Consortium (OGC)675 Kent Reed, NIST676 Jeffrey Ricker, Individual677 David Roberts, Unlsys Corporation

CAP-Vl,1Copyright @ OASIS Open 2005. All Rights Reserved.

1 October 2005Page 33 of 35

WIT.039.001.0084

678 Dave Robinson, Wells Fargo679 Eleanor Robinson, Anteon Corporation680 John Ruegg, LA County Information SystemsAdvisory Body681 Barry Schaeffer, Individual682 William Schroeder, ESRIa83 John Sliva, Individual684 Kwasi Speede, Anteon Corporation685 Michael Thompson, The Boeing Company686 Rob Torchon, E Team687 Brett Trusko, OASIS688 Rlcl< Tucker, MItre CorporatIon689 RIchardVandame, US Department of Homeland Security690 Jerry Weltman, IEM691 Preston Wemtz, Individual692 Konstantin \Mlms, Individual693 Bob Wyman Individual694 Jack Zhang Beijing Harmony TechnologiesCo, Ltd695

CAP·V1.1Copyright@ OASIS Open2005. All Rights Reserved.

1 October2005Page34of35

WIT.039.001.0085

696

697

Rev Date ByWhom What

1.1 2005·07·27 Art Botterell Edits to conform object model,datadictionary andschema:

Q Reordered Items Inobject diagram and datadictionary to match sequence required byschema.

0 Edited schema to make<scope> mandatory andtopermit multiple Instances of <responseType>and <eventCode>, In accordance withthedatadictionary•

1.1 2005-07-23 Art Bottarell Applied changes per recommendations of MessagingSubcommittee basedonInl,tial publiccomment periQd:

0 Modified XMLsyntaxof <eventCode> ,<parameter> and<geooode>

0 Added '0raft" valuefor <:status>

• Changed CAPnamespece to URN form0 Tightened usage of dateTImeformats In<sent>,

<effective>, <onset> and<expiration>0 Corrected schema to correct value of"CBRNE'ln

<event>

Q Conformed exam piesin Appendix A tonewnamespace.

1.1 2005·04·28 ElyseJones Technicsl Committee approved thev. 1.1 draftwilh thefollowing addlli onalchanges:

• Normative language added to specify uniquenessor <identifier>

0 Change [dateTi me] formatfor <sent>, <effective>,<onset> and <expires> elements

0 Change <language> elementRFC from 1166 to3066 and addednull

• Changed the<mlneType> element RFC 1521 to2046

0 Added <derefURI;> element

0 Security Note updated andadded DigitalSignature andEncryptlonnoteparagraphe

1.1 2005-01-04 Art Bolterell Messaging Subcommittee approved v. 1.1 draftforsubmission to full Technical Committee:

0 Added <responseType> elament

0 Made <category> element mendatory

0 Amended enum eratedvaluesfor the<certainty>element

0 Deleted the<password> element

0 Various aditorial corrections andclarifications

1.0 2004·04·01 Art Botterell CAP 1.0adopted as OASIS Standard (see CAP 1.0specification document for priorchange history.)

CAP-V1.1Copyright@ OASIS Open 2005. All Rights Reserved.

1 October 2005Page 35of 35

WIT.039.001.0086