1 Introduction

1.1 Purpose

In order to meet the needs of the Australian emergency management community, this Common Alerting Protocol (CAP) Australia Profile constrains the CAP v1.2 Standard for receipt and translation with and among Australian CAP Users.

The CAP provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats while offering enhanced capabilities that include:

. Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions;

. Multilingual and multi-audience messaging;

. Enhanced message update and cancellation features;

. Template support for framing complete and effective warning messages;

. Compatible with digital encryption and signature capability; and

. Facility for digital images and audio.

The purpose of this document is to:

. Facilitate the adoption of the international CAP standard within Australia;

. Provide the Profile for the Common Alerting Protocol – Australia (CAP-AU);

. Provide guidance and reference material to assist Australian agencies and organisations to implement the CAP Standard; and

. Define the set of rules and managed lists of values that are recommended for CAP use within hazard alerting systems that are implemented in Australia, and systems that seek to interoperate with Australian CAP systems.

1.2 Process

This profile was developed in accordance with OASIS Technical Committee Process, for inclusion as an attachment within the Australian Government Standard for the CAP Australia Profile (CAP-AU-STD) that was developed in parallel by the Australian Commonwealth Attorney-General's Department using the Australian Government National Standards Framework (NSF) process.

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The words warning, alert and notification are used interchangeably throughout this document.

Managed List - As used in this document refers to a collection of permitted values specific to a given element within a CAP-AU file (for example, the AUeventLIST).

Profile – As used in this document, a Profile refers to a collection of rules, managed lists, and other references, which pertain to the CAP v1.2 Standard. A Profile is accepted as necessary to address needs specific to a country or system using the CAP v1.2 Standard, and to the full community of users identifying with the profile. Profile elements are identified by using a valueName URN prefix unique to that Profile and only Profile elements should use this prefix. The Internet Engineering Task Force (IETF) RFC 3121 Namespace memo is applied to create valueNames for a Profile, and the character formatting complies with IETF RFC 2141, including case in-sensitivity.

Example: urn:oasis:names:tc:emergency:cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0

Layer – As used in this document, a Layer refers to message elements that are not required by the CAP v1.2 Standard nor a Profile but may involve other information for a specific community of users.

The IETF RFC 3121 Namespace memo is applied to create valueNames for a Layer, and the character formatting complies with IETF RFC 2141, including case in-sensitivity.

. <type> will be "layer"

. <sub-type> is a unique string identifying additional information about the <type>. This might also be the Agency who publishes the information.

. <document identifier> is further information such as a further identifying name, sub-segment, or version number.

Layer creators should ensure that their valueNames follow this format, do not conflict with established CAP-AU valueNames, and uniquely identify their organisation.

Example: layer:Agency Name:Name of Layer

Rule Set – As used in this document refers to a collection of rules which are applied to the use of the CAP v1.2 Standard, which impose usage requirements beyond those of the Standard, but also remain in compliance with the Standard.

1.4 Normative References

[AUeventLIST] Australian Government, Attachment B to CAP-AU-STD, Australian All-Hazards Event Code List, 28 February 2012.

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

[ISO 639.2] Codes for the Representation of Names of Languages, 18 October 2010.

http://www.loc.gov/standards/iso639-2/php/English_list.php

[namespaces] T. Bray, Namespaces in XML, W3C REC-xml-names-19990114, January 1999. http://www.w3.org/TR/REC-xml-names/

[National Standards Framework (NSF)] Australian Government Information Management Office, August 2009. http://www.finance.gov.au/publications/national-standards-framework/index.html

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, IETF RFC 2046, November 1996. http://www.ietf.org/rfc/rfc2046.txt

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt

[RFC2141] R. Moats, URN Syntax, IETF RFC2141, May 1997. http://www.ietf.org/rfc/rfc2141.txt

[RFC3066] H. Alvestrand, Tags for the Identification of Languages, IETF RFC 3066, January 2001. http://www.ietf.org/rfc/rfc3066.txt

[RFC3121] K. Best, A URN Namespace for OASIS, IETF RFC 3121, June 2001. http://www.ietf.org/rfc/rfc3121.txt

[WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic System 1984, NGA Technical Report TR8350.2, January 2000. http://earth-info.nga.mil/GandG/tr8350_2.html

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), W3C REC-XML-20040204, February 2004. http://www.w3.org/TR/REC-xml/

[XMLSIG] Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Signature Syntax and Processing, W3C Recommendation, February 2002. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

[XMLENC] Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax and Processing,

W3C Recommendation, December 2002. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

1.5 Non-Normative References

[Requirements - CAP Australian Profile] Buchanan, K., Trott, G. (editors), Discussion Paper Common Alerting Protocol - Australian Profile, Version 1.0, 30 September 2010.

[CAP-AU-STD] Australian Government, Australian Government Standard for the Common Alerting Protocol – Australia Profile, 30 May 2012.

[GDA94] Australian Government, Geocentric Datum of Australia 1994.

http://www.ga.gov.au/earth-monitoring/geodesy/geodetic-datums/GDA.html

The implementation of the Common Alerting Protocol within Australia is defined within the CAP-AU-STD, which is a multi-part document that provides background, guidance, rules, managed lists and reference information to enable CAP-AU to be implemented.

1.6 Requirements

The requirements for the CAP-AU were gathered from numerous sources including emerging CAP Country Profiles, and existing CAP Users within Australian emergency management organisations. All requirements were collated into the Requirements – CAP Australian Profile document that was reviewed by the Australian CAP Stakeholder Group during the period October 2010 - December 2010, resulting in an agreed list of CAP-AU requirements. The requirements were finalised as a result of the outcomes from the CAP event codes workshop conducted in February 2011, including establishment of the proposed list of Australian event codes.

2 CAP v1.2 Australia Profile

The Element and Sub-elements tables in the following sub-sections specify the constraints placed by the CAP-AU Profile on the CAP v1.2 message in order for the message to be a valid CAP-AU message. The CAP-AU constraints are additional to any constraints imposed by the OASIS CAP v1.2 Standard. The tables contain only those elements and sub-elements that apply a specific constraint or condition prescribed by the CAP-AU Profile. The value and description for each element and sub element are found in the CAP v1.2 Standard. The value for the <code> element provides the version of the CAP-AU Profile to be used for this initial version of the Profile. CAP-AU alert messages exist in a lifecycle, which has a beginning, middle and end. Messages are transactions on a hazard alert and each message updates the state of the alert.

Definitions applying to the CAP-AU Profile Element and Sub-elements Tables

The elements tables below represent the requirements and guidelines that are intended to apply to all CAP-AU messages. The following definitions apply to the components shown in the tables:

Element - a CAP-XML element as described in the CAP v1.2 Standard:

. A bold listed Element name denotes that the element is REQUIRED to be used by this Profile to assure conformance with the CAP v1.2 Standard.

. A non-bolded Element name denotes that this Profile and the CAP v1.2 Standard will accept that use of the element is OPTIONAL.

Use - a rule outlining the usage specifics of an element. As per the CAP v1.2 Standard, one of "REQUIRED", or "Optional", and as per CAP-AU Profile one of "REQUIRED", "CONDITIONAL" or "Optional". Any sub-elements of the <info>, <resource> or <area> elements whose use is specified as REQUIRED, are only mandatory inclusions when the <info> ,<resource> or <area> element is included in a CAP-AU message.

Type - a categorisation of "Technical" in relation to format or structure that relates to the CAP v1.2 Standard or CAP-AU Profile, or "Policy" if the element relates to the business of public alerting.

Notes - any special notes regarding implementation of a rule.

Example - XML examples or snippets, which illustrate a typical use of a rule.

Table 1: CAP v1.2 Australia Profile Specification

CAP Element	Use	Profile Specification Normative	Type	Profile Specification Non-Normative
2.1 "alert" Elements and Sub-elements
alert	REQUIRED	Note: The <alert> element is not specific to any included <info> element, but is to serve as a general reference to all associated <info> elements and their content.	Technical
identifier	REQUIRED	Notes: 1) SHALL be assigned by the message producer. 2) For messages that are to be shared between organisations, the <identifier> SHOULD enable the message to be associated with a specific hazard event and originating organisation. 3) A national database of hazard event identifiers does not yet exist in Australia.	Technical	Example: CAP v1.2 Standard
sender	REQUIRED	Notes: 1) It is RECOMMENDED that a valid email address in the format example@domain that identifies the agency that assembled the message, or another agency that originated the message be used. 2) Use of Third Level Domain (example@bom.gov.au) or Fourth Level Domain (example@ses.sa.gov.au) names as the <sender> value, are considered acceptable methods to create uniqueness. 3) If an alert message created by another agency is being passed through a system, such as a data aggregator, with no alterations, then the <sender> can remain as is. However, if any changes are made to the message, or if the aggregator is the authority to its clients, the <sender> value should change to reflect the aggregator, and the original message's extended identifier (sender, identifier, sent) is to be added to the <incidents> block, with a <source> value added identifying the original sender and what was changed.	Technical	Example (note 3): When the Duty Operations Officer at the Fire and Emergency Services Authority (FESA) of Western Australia (WA) receives hazard alerting information from the WA Police (WAPOL) in non-CAP format (i.e. it was received via a telephone call), the FESA Duty Operations Officer reformats the data into CAP format using that State's alerting system, then redistributes the message on behalf of WAPOL. <alert> ... <sender>example@fesa.wa.gov.au</sender> <info> <senderName>Western Australia Police </senderName> ... </alert>
status	REQUIRED	Notes: 1) Value of "Actual" SHALL be used when messages are intended for public dissemination. 2) Value of "Test" denotes that alert SHALL be treated as a log-only event and not be broadcast as a valid alert.	Technical	Example: CAP v1.2 Standard
msgType	REQUIRED	Notes: 1) Processing of "Ack" or "Error" messages is optional, and systems may impose their own associated rules. 2) Message states, and the transition from one state to another, are implied with the use of the <msgType> and <references> elements. 3) For alert messages intended for public distribution, a <msgType> of "Alert", "Update" or "Cancel" does affect the message state, and an <info> element is REQUIRED. 4) For alert messages with a <msgType> of "Ack" or "Error", an info element is not required, as these messages are primarily intended for system level purposes and not for distribution to the public.	Technical	Example A. Weather alert for public distribution: <alert> <sender>example@bom.gov.au</sender> <scope>Public</scope> <status>Actual</status> <msgType>Alert</msgType> ... <code>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0</code> ... <info> ... </info> </alert> Example B. Message that is not intended for public distribution: <alert> <status>Actual</status> <msgType>Error</msgType> <source>example@bom.gov.au</source> <scope>Private</scope> ... <addresses>insert valid recipient addresses </addresses> <code>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0</code> <note>Invalid eventCode</note> <references>TEST-1,2011-01-01T12:00:00+10:00 </references> ... <info> ... </info> </alert>
restriction	CONDITIONAL	Notes: 1) Can be used to reflect the combined classification of all of the <info> elements and the handling of the entire message. 2) Classifications SHALL be in accordance with national security classifications and non-national security markings listed in the Australian Government Protective Security Policy Framework (PSPF).	Technical	Example: <alert> ... <scope>Restricted</scope> <restriction>CONFIDENTIAL</restriction> <addresses>insert valid recipient addresses </addresses> ... <info> </alert>
code	REQUIRED	Notes: 1) The value for <code> SHALL be "urn:oasis:names:tc:emergency:cap:1.2:profile:CAP-AU:1.0" 2) A value used to identify which version(s) of the CAP-AU Profile the alert message is intended to be compliant with. Used by the message producer to assure conformance with the Profile approved for use within the Australian environment. 3) Does not preclude the option of using <code> for other purposes, such as version referencing, interoperability, layer identification, system specific functions, user-defined values, flags, special codes, etc.	Policy	Example. To denote interoperability where a message can be processed using profiles from different countries or organisations – this example identifies compatibility with the Australian (CAP-AU) and Canadian (CAP-CP) Profiles: <alert> ... <scope>Public</scope> <code>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0</code> <code>profile:CAP-CP:0.4</code> ... </alert>
references	OPTIONAL	Notes: 1) For "Update" and "Cancel" messages, all related messages that have not yet expired MUST be included as a reference, as a missed message could result in an alert playing beyond its intended time. Include the entire update trail, not just the most recent update. 2) Referencing all alert messages with <info> elements that still have an <expires> time in the future, ensures that any messages that may still be playing incorrectly are properly superseded by the most recent Update or Cancel message. This resolves issues caused by transmission delays and/or lost messages that may result in message chains being broken.	Technical	Example A. The first Alert message with a <expires> time of 0001UTC: <alert> <identifier>IDS20210</identifier> <sender>example@bom.gov.au</sender> <sent>2011-05-11T00:35:00+09:30</sent> <status>Actual</status> <msgType>Alert</msgType> ... <info> ... <expires>2011-05-12T00:01:00-00:00</expires> ... </info> </alert> Example B. Subsequent UPDATE message with a 3 hour <expires> time: <alert> <identifier>IDS20211</identifier> <sender>example@bom.gov.au</sender> <sent>2011-05-11T02:00:00+09:30</sent> <status>Actual</status> <msgType>Update</msgType> ... <references>example@bom.gov.au,IDS20210,2011-05-11T00:35:00+09:30 </references> <info> ... <expires>2011-05-11T05:00:00+09:30</expires> ... </info> </alert> Example C. Another subsequent UPDATE message with a 3 hour <expires> time that references the first two related messages: <alert> <identifier>IDS20212</identifier> <sender>example@bom.gov.au</sender> <sent>2011-05-11T03:00:00+09:30</sent> <status>Actual</status> <msgType>Update</msgType> ... <references>example@bom.gov.au,IDS20210, 2011-05-11T00:35:00+09:30 example@bom.gov.au,IDS20211,2011-05-11T02:00:00+09:30</references> ... <info> ... <expires>2011-05-11T06:00:00+09:30</expires> ... </info> </alert> Example D. A further subsequent UPDATE message with a 3 hour <expires> time referencing the most recent two messages as the earliest one has expired and should not be playing anymore for two possible reasons – a) it has been superseded, or b) it has expired: <alert> <identifier>IDS20213</identifier> <sender>example@bom.gov.au</sender> <sent>2011-05-11T04:00:00+09:30</sent> <status>Actual</status> <msgType>Update</msgType> ... <references>example@bom.gov.au,IDS20211,2011-05-11T02:00:00+09:30 example@bom.gov.au,IDS20212,2011-05-11T03:00:00+09:30</references> ... <info> ... <expires>2011-05-11T07:00:00+09:30</expires> ... </info> </alert>
incidents	OPTIONAL		Technical	Example. To denote that all messages showing this sub-element are related to the same hazard event: <alert> <identifier>IDS20213</identifier> <sender>example@bom.gov.au</sender> <incidents>"Cyclone Yasi:2011"</incidents> ... <info> ... </info> </alert>
2.2 "info" Element and Sub-elements Any <info> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <info> element is to be included in a CAP-AU message.
info	OPTIONAL	Notes: 1) This element MUST be included for all alert messages intended for public distribution. 2) Different <info> elements MAY be used to support two separate <area>s that are experiencing different levels of threat, where each <area> uses the same <category>, <event> and <eventCode> values in both <info> elements, but requires different <urgency>/<severity>/<certainty> values. 3) Multilingual messages MUST use separate <info> elements for each language, with all non free-form text elements repeated verbatim in each element. Each element must be identical (i.e., they MUST have the same <eventCode>, urgency, severity, certainty, geocodes) except for those elements which will differ because of language such as free form text and resource links. 4) Multiple <eventCode> elements MAY be included in order to support interoperability between message producer and consumer systems e.g. interpretation of AUeventLIST codes and other nations event code lists.	Policy	Example: Weather alert for public distribution: <alert> ... <status>Actual</status> <msgType>Alert</msgType> <source>example@bom.gov.au</source> <scope>Public</scope> ... <code>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0</code> ... <info> ... </info> </alert>
language	OPTIONAL	Notes: 1) If this sub-element is used, the value SHALL be blank or "en-AU" or an alternate language code that is identified in accordance with country codes specified in the "Codes for the Representation of Names of Languages (ISO 639.2)" 2) CAP v1.2 assumes that a blank or null value in this element SHALL be considered equivalent to US English or "en-US". 3) "en-AU" SHALL be used when the CAPv1.2 default value of "en-US" is not acceptable for the content of the message (standard language code for Australian English defined by ISO 3166-1 alpha-2). 4) MUST be completed by alert message producers to ensure an appropriate value is used. 5) The language value is important for message distributors. 6) Mixing public display content or text from different languages within the same <info> element is not allowed, except for inherently multilingual content (people, places, things) that may or may not include accented characters. Where fixed CAP values, which often appear as a word from a specific language, are used for software processing purposes and not for display, these values are not translated between <info> elements (e.g. <category>, <urgency>, <severity>, <certainty>, <responseType>, etc...). 7) When creating public alert messages in languages other than English, a translation of the event list to the appropriate language should be conducted in advance for inclusion in alerts.	Technical	Example A. Original INFO element expressed in Australian English and enumerated <urgency> value of "immediate" written in english : <info> <language>en-AU</language> ... <urgency>Immediate</urgency> ... <headline>Chemical spill Highway 1</headline> ... </info> Example B. INFO element translated into Italian and enumerated <urgency> value of "immediate" written in English: <info> <language>ita</language> ... <urgency>Immediate</urgency> ... <headline>Chimica fuoriuscita Highway 1 </headline> ... </info>
event	REQUIRED	Note: A CAP-AU Profile message SHALL include only one <event> value that is extracted from either the Tier I or Tier II column of the Australian Event Code List for CAP-AU Profile (AUeventLIST). Using these pre-defined values ensures that all public alert messages are using common terminology to describe hazard events. The <eventcode> value will be extracted from the "Event Code" column of the AUeventLIST.	Policy
responseType	OPTIONAL	Note: It is RECOMMENDED that alert message producers include response types when applicable, along with a corresponding <instruction> value. Using <responseType> allows for automated dissemination in all included languages, of the actions the end user is expected to take when instructions may not be available, or not available in all languages	Technical	Example: <alert> ... <info> ... <responseType>Shelter</responseType> <responseType>Monitor</responseType> ... <instruction>Take cover as threatening conditions approach and monitor local media broadcasts for further updates</instruction> ... </info> <alert>
urgency	REQUIRED	Note: Australian jurisdictions / organisations MAY need to further restrict the urgency values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.	Technical	Example: The Bushfire Alerts Levels used in Australia could be mapped to the CAP v1.2 enumerations as follows: Advice = Expected Watch and Act = Expected Emergency Warning = Immediate
severity	REQUIRED	Note: Australian jurisdictions / organisations MAY need to further restrict the severity values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.	Technical	Example: The Bushfire Alerts Levels used in Australia could be mapped to the CAP v1.2 enumerations as follows: Advice = Moderate Watch and Act = Severe Emergency Warning = Extreme
certainty	REQUIRED	Note: Australian jurisdictions / organisations MAY need to further restrict the certainty values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.	Technical	Example: CAP v1.2 Standard
eventCode	OPTIONAL	Notes: 1) <valueName> SHALL be "urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0" or alternate event code list if authorised. 2) <valueName> MUST reflect the unique short title or URN of the authorised event code list that is to be the source for the <event> value. 3) The CAP-AU Profile SHALL constrain each alert message to one single value from an authorised <eventCode> list in order to avoid any potential confusion or difficulty handling a single alert message containing multiple events. 4) Conventions regarding Event Codes: Code lists not defined by this Profile or not recognised by a receiver SHALL be passed through by CAP-AU Profile-compliant devices. This acknowledges the possible existence of other Australian and non-Australian codes which may appear in alert messages. 5) The version suffix shown in <valueName> (e.g. ":1.0") will change as new versions of the AUeventLIST document are published. As <eventCode> is a multi-use element, messages may be created that use codes from different versions of the Event References document in order to provide backward compatibility and to ease transition between list updates.	Technical	Example A. For the AUeventLIST: <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> Example B. Acceptable – shows two <info> elements with same <event> code, but different <area> data indicating a different <severity> value is relevant to each area. <alert> ... <info> ... <event>Thunderstorm</event> ... <severity>Extreme</severity> ... <eventCode> <valueName>urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> <value>thunderstorm</value> </eventCode> ... <area> <areaDesc>area 1</areaDesc> ... <geocode> <valueName>urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:Gazetteer:2010 </valueName> <value>XXX</value> </geocode> ... </area> </info> <info> ... <event>Thunderstorm</event> ... <severity>Moderate</severity> ... <eventCode> <valueName>urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> <value>thunderstorm</value> </eventCode> ... <area> <areaDesc>area 2</areaDesc> ... <geocode>...</geocode> ... </area> </info> </alert> Example C. Not Acceptable – shows two <info> elements with different <event> codes: <alert> ... <info> ... <event>Thunderstorm</event> ... <eventCode> <valueName>urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> <value>thunderstorm</value> </eventCode> ... <area> <areaDesc>area 1</areaDesc> ... <geocode>...</geocode> ... </area> </info> <info> ... <event>Tornado</event> ... <eventCode> <valueName>urn:oasis:names:tc:emergency :cap:1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> <value>tornado</value> </eventCode> ... <area> <areaDesc>area 2</areaDesc> ... <geocode>...</geocode> ... </area> </info> </alert> Example D. For an updated version of the AUeventLIST where codes may need to be used from the previous list during transition to the new list: <eventCode> <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:AUeventLIST:1.0 </valueName> <value>civilEmerg</value> </eventCode> <eventCode> <valueName>urn:oasis:names:tc:emergency:cap: 1.2:profile:CAP-AU:1.0:AUeventLIST:2.0 </valueName> <value>cccccccccccc</value> </eventCode> Example E. For the Canadian event code list: <eventCode> <valueName>profile:CAP-CP:xxxxxxx:n.n </valueName> <value>cccccccccccc</value> </eventCode> Where xxxxxxx denotes the short title of the Canadian list; n.n denotes the version number of the Canadian list; and cccccccccccc denotes the actual event code to be used.
effective	OPTIONAL	Notes: 1) Messages are considered to be effective when sent, so if this element is not included, the effective time SHALL be assumed to be the same as in <sent>. 2) Usually only included when <msgType> <value> is Alert, in order to direct the effective time of the alert message. 3) DO NOT use when <msgType> <value> is Cancel. 4) When the content of a message applies across multiple timezones, the message producer SHOULD use UTC times in preference to local times. The message producer SHOULD consider whether the message consumer is capable of converting UTC to the correct local time	Technical	Example A. Correctly formatted <effective> time in Hobart, Tasmania at 0700 AEST: <alert> ... <sent>2011-05-13T07:00:00+10:00</sent> ... <info> ... <effective>2011-05-13T07:00:00+10:00 </effective> ... </info> </alert> Example B. Same as A) but using UTC equivalent to 0700 AEST: 12 May 2011 at 2100 hours. <alert> ... <sent>2011-05-12T21:00:00-00:00</sent> ... <info> ... <effective>2011-05-12T21:00:00-00:00 </effective> ... </info></alert>
expires	OPTIONAL	Notes: 1) It is RECOMENDED that alert message producers provide an <expires> value so that distributors, aggregators, recipients and message consumers can interpret how long the information within an <info> element of an alert message should remain in effect. 2) When the content of a message applies across multiple timezones, the message producer SHOULD use UTC times in preference to local times. The message producer SHOULD consider whether the message consumer is capable of converting UTC to the correct local time.	Technical	Example A. Correctly formatted <expires> time in Darwin at 0700 UTC: <alert> ... <info> ... <expires> 2011-05-13T07:00:00-00:00 </expires> ... </info> </alert> Example B. Invalid formats: <expires></expires> <expires>0</expires> <expires>0000-00-00T00:00:00-00:00</expires> <expires>""</expires> <expires>2011-05-13T07:00:00</expires> (missing UTC zone)
senderName	OPTIONAL	Notes: 1) It is strongly RECOMMENDED that this element be populated by alert message producers as this value is expected to be used for public presentation purposes. 2) To be the publicly-recognisable name of the agency issuing the alert. 3) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio. 4) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.	Technical	Example: <alert> ... <sender>example@fesa.wa.gov.au</sender> ... <info> ... <senderName>Western Australia Police </senderName> </alert>
headline	OPTIONAL	Notes: 1) Headline SHALL include human readable adaptations of the following sub-elements that message consumers can be expected to understand: a) text associated with <event>, b) text associated with <areaDesc> value(s), and c) the word "to" followed by value for <expires>. 2) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio. 3) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.	Technical	Example: CAP v1.2 Standard
description	OPTIONAL	Notes: 1) Address essential information first as content may get truncated during transmission. 2) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio. 3) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.	Technical	Example: CAP v1.2 Standard
instruction	OPTIONAL	Notes: 1) Should be completed by alert message producers to improve clarity and provide public with direction concerning what actions to take in order to stay out of harm's way. 2) In circumstances where the <instruction> information is to be added by an alternate authority; the message producer will distribute the initial alert message (without an <instruction> element included) and the alternate authority will receive that message and add the <instruction> element as well as identify the new authoritative source for the information through the <senderName> and other applicable values then re-distribute the message accordingly. 3) Address essential information first as content may get truncated during transmission. 4) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio. 5) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.	Technical	Example: The Bureau of Meteorology issues a cyclone warning using a CAP message. The Bureau has no authority to issue evacuation notices, so an alternate authority like Emergency Management Queensland (EMQ) would re-distribute the cyclone warning with an <instruction> element included.
parameter	CONDITIONAL	Notes: 1) The values are not case sensitive, and SHALL NOT be translated. Multiple MinorChange elements are allowed. 2) It is recommended that alert message producers indicate when an update message contains non-substantive content changes in order to support advanced distribution decisions associated with reducing the number of cases of over-alerting. 3) When an alert message is considered a minor update, all <info> elements MAY contain a "MinorChange" parameter value(s) with an appropriate value setting that details the extent of the minor change: <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:MinorChange</valueName> 4) When no change has occurred in an <info> element relative to the previous message, the value of "none" SHOULD be used. 5) Substantive changes. Adding or removing an <info> element relative to the previous message is considered a substantive change. If a message consumer chooses to ignore this parameter and value, all update messages should be considered substantive as per the intent of the CAP v1.2. 6) If a transmission error occurs and the message consumer does not receive the referenced previous message to which the non-substantive change applies, the current message SHOULD be considered substantive. 7) Non-Substantive changes. This element MUST only be used when all <info> elements in a message contain non-substantive content changes or no change. The addition, removal, or change of the following elements MAY be considered non-substantive: <audience>, <headline>, <description>, <instruction>, <web>, <contact>, <parameter>, <areaDesc>, and <resource> sub-elements. Electing to process non-substantive content is left up to the message producer or consumer. 8) Both message producer and consumer systems are free to impose additional constraints on what they consider to be non-substantive changes. 9) When a change has occurred between <info> elements, the value of "text" SHOULD be used in the <info> element(s) where applicable. For example: some free form text content may have been added or modified. 10) When a correction is made to some free form content, the value of "correction" SHOULD be used in the <info> element(s) where applicable. 11) When the addition, modification, or removal of a <resource> sub-element and its associated content takes place relative to the previous message, the value of "resource" SHOULD be used in the <info> element(s) where applicable. 12) When the addition, modification, or removal of layer based values takes place relative to the previous message, the value of "layer" SHOULD be used in the <info> element(s) where applicable. 13) When the content change does not meet the criteria of the other parameter values, the value of "other" SHOULD be used in the <info> element(s) where applicable. A <note> element should always be used with "other" changes. 14) A <note> element MAY be used to further explain the reason for the minor changes in this update.	Technical	Example: <parameter> <valueName> urn:oasis:names:tc:emergency:cap: 1.2:profile:CAP-AU:1.0:MinorChange </valueName> </value>correction</value> </parameter>
2.3 "resource" Element and Sub-elements Any <resource> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <resource> element is to be included in a CAP-AU message. [There are no profile considerations for this element.]
2.4 "area" Element and Sub-elements Any <area> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <area> element is to be included in a CAP-AU message. Geographic locations in Australia SHOULD be referenced to the Geocentric Datum of Australia 1994 (GDA94). The Intergovernmental Committee on Surveying and Mapping advises that for most practical applications, [GDA94] coordinates can be considered the same as [WGS 84]; therefore, CAP-AU accepts that for the practical purposes of public alerting, the coordinates derived from a [GDA94] reference system SHALL be considered to be equivalent to [WGS 84] coordinates that are required by CAP v1.2.
area	OPTIONAL	Notes: 1) MUST include a minimum of one recognised <geocode> value. 2) Where multiple <area> elements are used, consolidation of <area> elements into as few <area> elements as possible is RECOMMENDED. 3) Area descriptions (like events) MUST be translated by the message producer in cases where the name is not derived from the preferred Location Reference source to ensure the intended audience for the message recognises the area being described. 4) In the case of both single and multiple <area> elements, each <areaDesc> MUST have one value and will be in the language of the <info> element. 5) It is RECOMMENDED that an associated geospatial value for the <polygon> or <circle> elements be included in the <area> element as well. The use of <polygon> and <circle> are preferred where the message consumer has the ability to interpret the geospatial information in those sub-elements. 6) Avoid using both <polygon> and <circle> in a single message when possible; however, if both are used then the <area> should be considered to be the union of the <polygon> and <circle> sub-elements.	Technical	Example: <info> ... <area> <areaDesc>Near Bowen, QLD</areaDesc> ... <circle>-20.085,147.764 10</circle> <geocode> <valueName>urn:oasis:names:tc:emergency: cap:1.2:profile:CAP-AU:1.0:ISO-3166-2 </valueName> <value>AU-QLD</value> </geocode> <altitude></altitude> <ceiling></ceiling> </area> </info> Where: -20.085,147.764 is the Lat/Long for the area near Bowen; and 10 is the radius value in kilometres (Note there is a space character separating the radius value from the lat/long).
areaDesc	REQUIRED	Notes: 1) Textual description of the area SHALL be defined by the combination of area elements that is recognisable to the message consumers. 2) The value SHALL be derived from the Location Reference document specified under <geocode> or other location source providing the source is recognised by the message consumer. 3) The full text, or at least the first ten words, of this element MAY be used in the construction of recorded audio or text-to-speech audio. 4) The full text, or at least the first 60 characters, of this element MAY be used in the construction of video display text.	Technical	Example: CAP v1.2 Standard
geocode	OPTIONAL	Notes: 1) <geocode> SHOULD be used as the backup method to define alert areas whenever the consumer system has no ability to interpret the more accurate geospatial information stated in <polygon> or <circle> sub-elements. Multiple <geocode> sub-elements MAY be used as necessary to fully cover the target area for the alert message. 2) The RECOMMENDED Location Reference source for Australia is the Geo-coded National Address File (G-NAF), maintained by PSMA Australia on behalf of the members of the Intergovernmental Committee on Surveying & Mapping (ICSM). G-NAF covers locations and addresses within the complete national geography of Australia. The latest version of G-NAF can be sourced from: http://www.psma.com.au/products/gnaf.html 3) Location information from the following secondary sources would also be considered suitable to specify if warranted by the hazard situation: a) ISO3166-2 when the area to be covered by the message includes a whole State region (refer: http://www.iso.org/iso/country_codes.html); b) Gazetteer of Australia available from Geoscience Australia (refer: http://www.ga.gov.au/place-name/ ; and c) Postcodes with four (4) decimal characters and no space between characters (refer: http://www.psma.com.au/products/postcodeboundaries.html). 4) A <geocode> consisting of the ISO3166-2 designator for the continent of Australia (i.e. AU) SHALL be used to indicate a message intended for the entire continent of Australia and its Territories. 5) Messages MAY include <geocode>s from different Location Reference sources in order to provide backward compatibility and to ease transition between list updates.	Technical	Examples A (for note 2): <geocode> <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:G-NAF:x.x</valueName> <value>...</value> </geocode> Where: x.x denotes the version of the location reference source being used e.g. 2.4 Example B (for note 3.a): <geocode> <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:ISO-3166-2</valueName> <value>AU-VIC</value> </geocode> Example C (for note 3.b): <geocode> <valueName> urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:Gazetteer:YYYY </valueName> <value>...</value> </geocode> Where: YYYY denotes the year version of the location reference source being used e.g. 2010. Example D (for note 3.c): <geocode> <valueName>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0:Postcode-Boundaries:x.x </valueName> <value>2600</value> </geocode> Where: x.x denotes the version of the Postcode Boundaries reference

3 Conformance

Conformance Requirements for CAP-AU Profile

An implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined within this specification.

This specification references a number of other specifications. In order to comply with this specification, an implementation MUST implement the portions of referenced specifications necessary to comply with the required provisions of this specification. Additionally, the implementation of the portions of the referenced specifications that are specifically cited in this specification MUST comply with the rules for those portions as established in the referenced specification.

3.1 Conformance Targets

The three following conformance targets are defined in order to support the specification of conformance to this standard:

a) CAP-AU Profile Message

b) CAP-AU Profile Message Producer

c) CAP-AU Profile Message Consumer

A CAP-AU Profile Message is an XML 1.0 document whose syntax and semantics are specified in this standard.

A CAP-AU Profile Message Producer is a software entity that produces CAP-AU Profile Messages.

A CAP-AU Profile Message Consumer is a software entity that consumes CAP-AU Profile Messages.

3.2 Conformance as a CAP-AU Profile Message

An XML 1.0 document is a conforming CAP-AU Profile Message if and only if:

it is valid according to the schema in Section 3.4 of the specification located at http://docs.oasis-open.org/emergency/cap/v1.2/ and
the content of its elements and the values of its attributes meet all the additional mandatory requirements specified in Section 2.

3.3 Conformance as a CAP-AU Profile Message Producer

A software entity is a conforming CAP-AU Profile Message Producer if and only if it is constructed in such a way that any XML document produced by it and present in a place in which a conforming CAP-AU Profile Message is expected (based on contextual information) is indeed a conforming CAP-AU Profile Message according to this standard.

The condition above can be satisfied in many different ways. Here are some examples of possible scenarios:

a standard protocol (for example, EDXL-DE) transfers messages carrying CAP-AU Profile Messages; a client has sent a request for an CAP-AU Profile Message to a server which claims to be a conforming CAP-AU Profile Message Producer, and has received a response which is therefore expected to carry a conforming CAP-AU Profile Message;
a local test environment has been set up, and the application under test (which claims to be a conforming CAP-AU Profile Message Producer) has the ability to produce a CAP-AU Profile Message and write it to a file in a directory in response to a request coming from the testing tool; the testing tool has sent many requests to the application under test and is now verifying all the files present in the directory, which is expected to contain only conforming CAP-AU Profile Messages;

3.4 Conformance as a CAP-AU Profile Message Consumer

A software entity is a conforming CAP-AU Profile Message Consumer if and only if it is constructed in such a way that it is able to successfully validate and ingest a CAP-AU Profile Message, as defined in Sec 3.2

The condition above can be satisfied in many different ways. Here is one example of a possible scenario:

a client receives and processes a CAP-AU Profile Message from a server which claims to be a conforming CAP-AU Profile Message Producer

Conformance to the CAP-AU Profile SHALL be measured in three steps:

the message produced by the CAP-AU system contains the REQUIRED elements from both the CAP v1.2 and the CAP-AU Profile standards;
the message producer can successfully construct a CAP message that conforms to the CAP v1.2 and the CAP-AU Profile standards; and
the message consumer can successfully validate and ingest a conforming CAP message.

Appendix A. Acknowledgments

Content within this document was also derived from contributions provided by the CAP - Canadian Profile Working Group administering the CAP - Canadian Profile; and CAPAN (Canadian Association for Public Alerting and Notification).

The TC particularly wishes to acknowledge the CAP Profiles Subcommittee Chair Sukumar Dwarkanath and Secretary Gary Timm whose efforts ensured this profile was completed in both a timely and professional manner; and to Rex Brooks, Jacob Westfall, Werner Joerg and Norm Paulsen for their diligence regarding application of the CAP rules within this Profile. In addition, the expertise that each of the following individuals has been willing to offer to assist creation of this specification is gratefully acknowledged:

Participants:

Aviv Siegel, AtHoc, Inc.

Camille Osterloh, Individual

Doug Allport, Canadian Association for Public Alerting and Notification (CAPAN)

Elysa Jones, Individual

Gary Ham, Individual

Gary Timm, SRA International, Inc.

Greg Trott, Australian Government, Attorney-General's Department

Herbert White, NOAA's National Weather Service

Jacob Westfall, Individual

Lewis Leinenweber, SE Solutions, Inc.

Norm Paulsen, Environment Canada

Patti Aymond, IEM

Rex Brooks, Network Centric Operations Industry Consortium

Robert Bunge, NOAA's National Weather Service

Robert Torchon, Individual

Sukumar Dwarkanath, SRA International, Inc.

Thomas Ferrentino, Individual

Tim Grapes, SE Solutions, Inc.

Werner Joerg, IEM

Appendix B. Revision History

Revision	Date	Editor	Changes Made
WD01	30 Nov 2011	Elysa Jones	First complete draft with base provided by Greg Trott and CAP Profile Subcommittee decisions included
WD02	1 Dec 2011	Elysa Jones	Changes addressed during CAP Profile Subcommittee meeting 30 Nov 2011: a. Added lines 101-102 in non-normative section 1.5 and note into header of "area" element on page 31 regarding GDA94 b. Removed note from page 13 and updated all occurrences of the URN for the profile on pages 5, 10, 11, 12, 16, 18, 19, 20, 21, 22, 23, 27, 28, 31, 32, 33 to "urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0" c. Removed note from page 34 and updated all occurrences of the conformance target names on pages 33 and 34 "CAP-AU" d. Corrected the company names for Trott, Leinenweber and Grapes in the acknowledgements e. Updated the table of contents
WD03	9 Dec 2011	Elysa Jones	Changes addressed during the EM-TC meeting 6 Dec 2011: a. Removed the reference to CAP Logo and guidance from the last line of the Notices section. It will now appear on the front page in the related works section. b. Deleted lines 105-113 of the non-normative section which referenced attachments to an Australian document.
WD04	30 Jan 2012	Elysa Jones	Changes addressed by the CAP Profiles subcommittee in response to public review comments: a. Removed brackets around copyright in the OASIS notice, added related works section to cite the CAP logo Committee Note, and fixed formatting of the pdf. b. Corrections to Table 1: corrected a document name; added clarifying sentence to Note 1 <event> sub-element; corrected sentence in Note 1 of <eventCode>; added words to Note 2 of <eventCode>; added sentence to Note 3 of <eventCode>; fixed <value> in Example B of <eventCode>; added clarification to Note 7 of <area>; clarified Note 1 of <geocode>; added new <area> Note 8; fixed typo in Note 2 of <effective>; corrected <expires> time in the example; added examples to <urgency> and <severity>; clarified Notes for <urgency>, <severity> and <certainty>; fixed typos in <effective> and <resource> elements; clarified Notes for <urgency>, <severity> and <certainty> c. Add term "Layer" and definition to 1.3 d. Additional changes to Table 1: removed Note 2 from <alert>; added recommendation to Note 1 of <sender>; changed Note 3 of <sender> to use message identifier and source element; removed Note 4 and Example 4 of <sender>; changed <source> to <sender> and corrected placement of <sender> in Example A of <msgType>; removed Note 3 and renumber subsequent notes of <info>; added clarification of what must be identical in multilingual messages of <info>; deleted Note 2 and Note 3 and moved examples from <event> to <eventCode>; clarified Note 3 and Note 4 of <eventCode>; changed <effective> and <expires> from REQUIRED to OPTIONAL; clarified Note 1 and removed Note 2 from <expires>; reworded Note 1 and removed Note 4 in <effective>; changed <effective> Examples A and B; corrected Note 2 of <instruction>; added sentence to Note 1 of <parameter>; corrected Note 2 of <parameter>; corrected Note 3 of <parameter>; removed Note 15 and 16 from <parameter>; removed Notes 1, 2, 3 from <resource>; corrected URN in example of <area>; removed Note 2 of <area>; removed Note 6 of <area>; replaced 8 Notes in <geocode> with 5 Notes and corrected corresponding example references; corrected URN in Example B and D of <geocode>; e. Switched headers for Table 1 "Use" and "Type"
WD05	14 Mar 2012 16 Mar 2012	Elysa Jones Werner Joerg	Minor corrections to update publication dates, address minor spelling and spacing errors. Fixed formatting and footers.