Australian Government Standard - OASISA… · that will guide future implementations of CAP during upgrades to alert and warning system technologies. Provides a common standard and

Australian Government Standard

COMMON ALERTING PROTOCOL – AUSTRALIA PROFILE

[ CAP(AU)P ]

Version: 0.2

Date: 13 May 2011

© 2011, Commonwealth of Australia

<<<Copyright statement is being developed at this time by AGD legal staff for insertion into released

version>>>

OASIS LOGO

(If approved)

This document is under development

and is not yet approved for official release

[DRAFT] Common Alerting Protocol – Australia Profile

________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page ii

Copyright © 2011, Commonwealth of Australia

PREFACE

Developers

This CAP(AU)P Australian Government standard was developed by the CAP Stakeholder

Group (CAP SG) and represented by the following bodies:

Agencies Participant Organisations

Commonwealth Emergency Management Australia (EMA)

Commonwealth Bureau of Meteorology (BOM)

Commonwealth Geoscience Australia (GA)

Commonwealth Department of Agriculture, Fisheries and Forestry (DAFF)

Commonwealth Department of Health and Ageing (DOHA)

Jurisdictions Participant Organisations

Australian Capital Territory Emergency Services Agency (ESA)

Fire Brigade

New South Wales Fire and Rescue

Rural Fire Services (RFS)

Northern Territory Police, Fire and Emergency Services (PFES)

Queensland Department of Community Safety (DCS)

Emergency Management Queensland (EMQ)

Police

South Australia Fire and Emergency Services Commission (SAFECOM)

State Emergency Service (SES)

Tasmania Police

State Emergency Service (SES)

Victoria Office of Emergency Services Commissioner (OESC)

Department of Sustainability and Environment (DSE)

Country Fire Authority (CFA)

Western Australia Fire and Emergency Service Authority (FESA)

Non-Government Body Participant Organisation

Industry Body Australasian Fire & Emergency Service Authorities Council

(AFAC)

The Organization for the Advancement of Structured Information Standards (OASIS) was

consulted during the development of this document and contributed to the content and quality

of this document ... <<<Intend to insert an agreed endorsement statement from OASIS that will be extracted

from …>>>


________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page iii


Disclaimer

<<<Disclaimer statement is being developed at this time by AGD legal staff for insertion into released

version>>>

The Attorney-General‟s Department periodically updates the information in this publication.

Before using this publication, please check the following sources to ensure that this edition is

the most recent and updated version of the publication:

Primary reference source: http://www. (GovShare website for CAP(AU)P)

Additional reference sources containing links to the primary source:

o http://www. (EMA website for CAP(AU)P)

o http://www. (OASIS website for CAP(AU)P)

The version at (GovShare website for CAP(AU)P) shall always take precedence. New

versions shall be created only with the express consent of the AGD CAP Custodian.

Intellectual Property Statement

The information contained within this manual is current as at the latest version shown in the

Record of Amendments table.

<<<IP statement is being developed at this time by AGD legal staff for insertion into released version>>>

http://www/

http://www/

http://www/


________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page iv


Record of Amendments

Version Date Amendment(s) Author(s)

0.1 1 Apr 2011 Initial version distributed to OASIS for

review (AGD TRIM 11#253041DOC)

CAP Stage 1& II

Projects

0.2 13 May 2011 Response to OASIS review feedback and

ongoing revision of content and structure

CAP Stage II

Project

Amendment Policy

This CAP(AU)P standard is a living document that will be reviewed periodically by the CAP

Stakeholder Group. New versions will only be published when the CAP Stakeholder Group

decide that sufficient changes warrant revision action.

The CAP Stakeholder Group invites suggestions for improvements and notification of

inaccuracies or ambiguities to be forwarded to the CAP CUSTODIAN at the Attorney-

General‟s Department address listed below.

CAP CUSTODIAN

Attorney-General's Department

3-5 National Circuit

BARTON ACT Australia 2600


TABLE OF CONTENTS

________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page v


1. INTRODUCTION ....................................................................................................................................... 1

1.1. PURPOSE ............................................................................................................................................... 1

1.2. DEVELOPMENT PROCESS ...................................................................................................................... 2

1.3. BENEFITS OF CAP(AU)P ...................................................................................................................... 2

2. REFERENCES ............................................................................................................................................ 3

2.1. BASIS FOR CAP(AU)P .......................................................................................................................... 3

2.2. DOCUMENTS COMPRISING CAP(AU)P .................................................................................................. 3

2.3. TERMINOLOGY APPLICABLE TO CAP(AU)P .......................................................................................... 3

2.4. NORMATIVE REFERENCES ..................................................................................................................... 4

3. CAP(AU)P RULES ...................................................................................................................................... 5

3.1. CAP(AU)P STRUCTURE REQUIREMENTS .............................................................................................. 5

3.2. GENERAL CAP(AU)P RULES ................................................................................................................ 6

3.2.1 Conformance with CAP Reference Standard .................................................................................. 6

3.2.2 Conformance Requirements for CAP(AU)P .................................................................................... 6

3.2.3 Conventions Regarding Case-sensitivity ......................................................................................... 7

3.2.4 Conventions Regarding <valueName> ........................................................................................... 7

3.2.5 Conventions Regarding Time Zone ................................................................................................. 8

3.2.6 Conventions Regarding Automated Translation of Free Form Text ............................................... 8

3.2.7 Management of Invalid CAP Messages ........................................................................................... 9

3.2.8 Definitions applying to the CAP(AU)P Element and Sub-elements Tables................................... 10

3.3. ALERT ELEMENTS AND SUB-ELEMENTS ............................................................................................ 11

3.3.1 <alert> .......................................................................................................................................... 11

3.3.2 <identifier> ................................................................................................................................... 11

3.3.3 <sender> ....................................................................................................................................... 12

3.3.4 <sent> ........................................................................................................................................... 12

3.3.5 <status> ........................................................................................................................................ 13

3.3.6 <msgType> ................................................................................................................................... 13

3.3.7 <source> ....................................................................................................................................... 14

3.3.8 <scope> ........................................................................................................................................ 15

3.3.9 <restriction> ................................................................................................................................. 15

3.3.10 <addresses> ............................................................................................................................. 15

3.3.11 <code> ..................................................................................................................................... 16

3.3.12 <note> ...................................................................................................................................... 16

3.3.13 <references> ............................................................................................................................ 17

3.3.14 <incidents> .............................................................................................................................. 19

3.4. INFO ELEMENTS AND SUB-ELEMENTS ............................................................................................... 20


TABLE OF CONTENTS

________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page vi


3.4.1 <info> ........................................................................................................................................... 20

3.4.2 <language> .................................................................................................................................. 21

3.4.3 <category> ................................................................................................................................... 22

3.4.4 <event> ......................................................................................................................................... 23

3.4.5 <responseType> ........................................................................................................................... 25

3.4.6 <urgency> .................................................................................................................................... 25

3.4.7 <severity> ..................................................................................................................................... 26

3.4.8 <certainty> ................................................................................................................................... 26

3.4.9 <audience> ................................................................................................................................... 26

3.4.10 <eventCode> ............................................................................................................................ 27

3.4.11 <effective> ............................................................................................................................... 28

3.4.12 <onset> .................................................................................................................................... 28

3.4.13 <expires> ................................................................................................................................. 29

3.4.14 <senderName> ......................................................................................................................... 30

3.4.15 <headline> ............................................................................................................................... 30

3.4.16 <description> ........................................................................................................................... 31

3.4.17 <instruction> ........................................................................................................................... 31

3.4.18 <web> ...................................................................................................................................... 32

3.4.19 <contact> ................................................................................................................................. 32

3.4.20 <parameter> ............................................................................................................................ 32

3.5. RESOURCE ELEMENTS AND SUB-ELEMENTS .................................................................................... 35

3.5.1 <resource> ................................................................................................................................... 35

3.5.2 <resourceDesc> ........................................................................................................................... 35

3.5.3 <mimeType> ................................................................................................................................. 35

3.5.4 <size> ........................................................................................................................................... 35

3.5.5 <uri> ............................................................................................................................................. 36

3.5.6 <derefUri> .................................................................................................................................... 36

3.5.7 <digest> ........................................................................................................................................ 36

3.6. AREA ELEMENTS AND SUB-ELEMENTS .............................................................................................. 37

3.6.1 <area> .......................................................................................................................................... 37

3.6.2 <areaDesc> .................................................................................................................................. 38

3.6.3 <polygon> .................................................................................................................................... 38

3.6.4 <circle> ........................................................................................................................................ 38

3.6.5 <geocode> .................................................................................................................................... 38

3.6.6 <altitude> ..................................................................................................................................... 40

3.6.7 <ceiling> ...................................................................................................................................... 40

3.7. ACKNOWLEDGEMENTS ........................................................................................................................ 41


________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page 1


1. INTRODUCTION

Since 2006, the National Forum on Emergency Warnings to the Community has promoted

consideration of the adoption of the Common Alerting Protocol (CAP) as a content standard

for emergency warnings within Australia. In April 2008, the member agencies of Australasian

Fire and Emergency Services Authorities Council (AFAC) agreed to adopt the international

open CAP standard developed by the Organization for the Advancement of Structured

Information Standards (OASIS) as the national standard for handling of the essential content

of alert warning messages.

A national resilience project was commenced in Australia in 2009 in response to outcomes of

the investigation of widespread bushfires in the State of Victoria in February 2009. A study

conducted by the Attorney-General‟s Department (AGD) in 2009-10 determined that the

OASIS CAP standard is the most suitable content standard available for emergency alerts and

warnings and recommended that CAP be adopted in Australia. A follow-on project was

conducted by the National Emergency Management Committee (NEMC) in 2010-11 to

develop the Common Alerting Protocol - Australia Profile or CAP(AU)P, to provide the

Australian community with a common standard for the dissemination of all-hazard alert and

warning messages during any emergency.

1.1. Purpose

The purpose of this document is to:

facilitate the adoption of the international CAP standard within Australia;

provide the “Profile” for the Australian Government standard for the Common Alerting

Protocol - Australia Profile;

provide guidance to assist Australian agencies and organisations to implement this

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.


________________________________________________________________________________________



1.2. Development Process

AGD developed the CAP(AU)P standard using the Australian Government National

Standards Framework (NSF). A foundation of this Framework is that agency and

jurisdictional independence is respected and a mechanism is provided that delivers

transparency and a degree of certainty.

This standard has been developed and refined through a range of agency consultations. Future

development will be managed by the AGD CAP Custodian in consultation with the CAP

Stakeholder Group, and will continue to be subject to endorsement by the Commonwealth

Chief Information Officers Committee (CIOC) and approval by the Cross Jurisdictional Chief

Information Officers Committee (CJCIOC).

The CAP workspace that AGD established on the GovDex website to facilitate stakeholder

collaboration during development of this standard that continues to be managed by the CAP

Custodian to facilitate future upgrade activities. Requests to access the website should be

forwarded to the AGD CAP Custodian, stating nominee‟s name, email address and reasons to

justify access.

1.3. Benefits of CAP(AU)P

Implementation of the CAP(AU)P provides the following benefits to Australia:

Consolidates disparate uses within Australia of earlier versions of the OASIS CAP

standard.

Provides an endorsed government standard to jurisdictions and government agencies

that will guide future implementations of CAP during upgrades to alert and warning

system technologies.

Provides a common standard and interoperability matrix that all Australian jurisdictions

can leverage upon when interoperating with regional neighbours.

Facilitates the basis for a technology-independent national and international 'warning

internet' by enabling conversion to and from the 'native' formats of all kinds of sensor

and alerting technologies.


________________________________________________________________________________________



Provides a single focal point for all jurisdictions and government agencies to jointly

develop future versions of the CAP(AU)P standard, and to contribute Australian issues

to the revision of the international CAP standard.

Reduces costs and operational complexity associated with hazard alerting by eliminating

the need for customising multiple software interfaces to the many warning technologies

and dissemination systems involved in all-hazards warnings.

2. REFERENCES

2.1. Basis for CAP(AU)P

The CAP(AU)P standard is derived from, and compliant with, the OASIS CAPv1.2 standard

that was released by OASIS in July 2010 (henceforth to be referred to as the “Reference

Standard” or CAP). The release of this Australian Government standard for CAP(AU)P

constitutes the formal national agreement within Australia to apply a specific CAP standard

across all current systems in order to resolve variations between CAP implementations in

Australia that could potentially disrupt interoperability or cause confusion with interpretation

of hazard event codes.

2.2. Documents comprising CAP(AU)P

The entire CAP(AU)P is defined within two independently versioned documents, comprising:

CAP(AU)P - this Government standards document; and

AUeventLIST – the Australian Event Code List For CAP(AU)P, which is

Supplementary Document No.1 to the CAP(AU)P that details a managed list of

recognised events associated with hazard alerting in Australia.

2.3. Terminology applicable to CAP(AU)P

Terminology throughout this document SHALL be interpreted in accordance with Internet

Engineering Task Force (IETF) Request for Comments (RFC) 2119. “SHALL” and “MUST”

represent absolute requirements, while other terminology represents guidelines or instructions.

Where the "Non-Conformance Impact” is blank the interpretation should be that no impact

applies. The words “warning,” “alert,” and “message” will be used interchangeably

throughout this document.


________________________________________________________________________________________



In addition, the CAP(AU)P adopts the terminology of the Reference Standard, including:

a. The term “layer” is used in this document to refer to message elements that are not

required under the Reference Standard or under the CAP(AU)P but that may involve a

new rule, other managed lists and / or information specific to a subset of users in

Australia‟s hazard alerting community. A layer is typically supported with the use of

one or more parameter elements within a CAP or CAP(AU)P file.

b. The expression “managed list” is used in this document to refer to a collection of

permitted values specific to a given element within a CAP(AU)P file (for example, the

AUeventLIST).

c. The term “profile” is used in this document to refer to a collection of rules, managed

lists, and other references, which pertain to the Reference Standard. A profile is

accepted as necessary to address needs specific to a country or system using the

Reference Standard, and to the full community of users identifying with the profile.

d. The expression “rule set” is used in this document to refer to a collection of rules which

are applied to the use of the Reference Standard, which impose usage requirements

beyond those of the Reference Standard, but also remain in compliance with the

Reference Standard.

2.4. Normative References

Reference Standard OASIS Standard, Common Alerting Protocol Version 1.2, 01 July

2010, http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf

CAPv1.2 See Reference Standard

National Standards

Framework (NSF)

Australian Government Information Management Office, August

2009, http://www.finance.gov.au/publications/national-standards-

framework/index.html

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

http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf

http://www.finance.gov.au/publications/national-standards-framework/index.html

http://www.finance.gov.au/publications/national-standards-framework/index.html

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


________________________________________________________________________________________



3. CAP(AU)P RULES

This section identifies the CAP(AU)P specific requirements, constraints, and

recommendations. Content extracted from the Reference Standard is only included where

necessary to improve clarity. Differences in Reference Standard interpretations, if any, are

unintended and SHALL not override the Reference Standard.

3.1. CAP(AU)P Structure Requirements

CAP is an Extensible Markup Language (XML)1 message standard that also contains an XML

Schema, which is to be used for validation of the CAP message. The CAP(AU)P message

MUST result in a constrained XML message adhering to the requirements in Table 1.

Table 1: CAP(AU)P Criteria and Miscellaneous Requirements

Number Requirement

1. Unless otherwise stated within this “CAP(AU)P Requirements” table, all OASIS

CAP elements SHALL be adhered to exactly as specified in the OASIS CAP

Reference Standard.

2. The CAP(AU)P MUST not become a new or additional messaging “standard” (i.e.

another Alerts and Warnings standard or another CAP “version”). It is simply a

more constrained version of an existing messaging standard.

3. The CAP(AU)P message MUST comply with the CAP Reference Standard as

follows:.

always validate against the CAP Reference standard Schema. Definition and

Development of the CAP(AU)P message may or may not result in a more

restrictive Schema.

adhere to CAP Reference Standard data dictionary restrictions.

validate within the CAP Reference Standard namespace with no changes to

root elements.

use all required elements (i.e. no deletion of required elements are allowed).

not change attributes for required fields.

4. A CAP(AU)P message MUST be capable of using an existing CAP Reference

standard service (i.e. software designed to apply the standard) to receive and

understand a CAP(AU)P message.

5. A CAP(AU)P message MUST NOT be Proprietary Format.

1 XML is a set of rules for encoding documents in machine-readable form that emphasises simplicity,

generality, and usability over the Internet.


________________________________________________________________________________________



Number Requirement

6. A CAP(AU)P message MAY further constrain the CAP standard. (may be thought

of as a “constraint Schema” against the standard)

7. A CAP(AU)P message MAY add to required element definitions.(only to extend

or interpret the definition)

8. A CAP(AU)P message MAY limit the size of required elements.

9. A CAP(AU)P message MAY exclude optional elements.

10. A CAP(AU)P MAY define elements in a specific, agreed-upon way – as defined

and adjudicated for the Profile.

3.2. General CAP(AU)P Rules

In order to avoid the need to validate content of the CAP(AU)P every time the Reference

Standard is updated, and to eliminate errors in duplicating the information that is already

presented in the OASIS CAP Reference Standard, the information and tables in this section

only detail the element and value requirements that will apply for the CAP(AU)P or that will

extend or constrain the Reference Standard.

Wherever the clause “refer Reference Standard” is used, the component definition is to be

interpreted as per the Reference Standard. The Data Dictionary within the Reference Standard

should always be consulted in parallel with the guidance in this Profile for any additional

direction or guidance that should be applied to each element.

3.2.1 Conformance with CAP Reference Standard

All alert messages must be structured and formatted according to the guidelines set out by the

Reference Standard. Messages that do not conform to this standard are also considered

invalid CAP(AU)P messages.

3.2.2 Conformance Requirements for CAP(AU)P

The OASIS CAP Reference standard states that “An implementation conforms to the

CAPvn.n specification if it satisfies all of the MUST and REQUIRED level requirements


________________________________________________________________________________________



defined within the specification”. Therefore, implementers of CAP(AU)P can assure

compliance with the Australian standard by implementing the portions of both the CAP(AU)P

standard and the Reference Standard that are specifically cited and that comply with the rules

for those portions as established in both standards.

Conformance to the CAP(AU)P SHALL be measured in three steps:

a. the message produced by the CAP(AU)P-compliant system contains the REQUIRED

elements from both the CAP Reference and the CAP(AU)P standards;

b. the message producer can successfully construct a CAP message that conforms the CAP

Reference and the CAP(AU)P standards; and

c. the message consumer can successfully validate and ingest a conforming CAP message.

3.2.3 Conventions Regarding Case-sensitivity

XML specifications require that all CAP and CAP(AU)P element names MUST be case

sensitive.

3.2.4 Conventions Regarding <valueName>

The following conventions SHALL apply to use of <valueName> in CAP(AU)P:

a. Except where explicitly noted, <valueName> and <value> content are not case

sensitive.

b. Values of „valueName‟ that are acronyms SHOULD be represented in all capital letters

without periods.

c. The <valueName> should uniquely identify the value list being used, whether the value

list is expected to change, and should provide a method to accommodate changes by

identifying each unique revision.

d. The character formatting for Uniform Resource Name (URN) from the IETF‟s RFC

2141 will be followed, including case in-sensitivity, to create CAP(AU)P <valueName>

in order to distinguish it from any future standardised format that does incorporate an

officially registered namespace identifier:

o <type> will be one of “profile” or “layer” or “list”.

o <identifier> is a unique string identifying this value list.


________________________________________________________________________________________



o <specific string> is further information about this value list such as a further

identifying name, sub-segment, or version number.

Example: <valueName>profile:CAP(AU)P:1.0</valueName>

3.2.5 Conventions Regarding Time Zone

The time zone field is required to be inserted in CAP(AU)P within the <sent>, <expires>,

<onset>,and <effective> elements to eliminate misinterpretation of implied times with time

zones. Where there is a need to use local time, a system policy SHOULD be adopted that

time zone information MUST be included as per the location cited in the <area> block,

including the allowance for Daylight Savings when applicable.

Example:

For an alert issued on 13 May 2011 at 1300 hours for an event that is predicted

in the ACT region (UTC+10:00) to start at 1600 hours and finish at 1700 hours:

<alert> … <sent>2011-05-13T13:00:00+10:00</sent> <status>Exercise</status> … <info>

… <effective>2011-05-13T13:00:00+10:00</effective> <onset>2011-05-13T16:00:00+10:00</onset> <expires>2011-05-13T17:00:00+10:00</expires> … <area>

<areaDesc>Entire ACT region</areaDesc> …

</area> </info>

</alert>

3.2.6 Conventions Regarding Automated Translation of Free Form Text

Automated translation is any kind of machine-based translation of free form text or the

assembly of phrases based on pre-set values where a human translator has not been involved.

The purpose of the following conventions is to support advanced distribution decisions

associated with multilingual messages:

a. When automated language translation of free form text content in an <info> block has

taken place, a single instance of this parameter should be used with a value of “yes”.

b. For alert messages with multiple <info> blocks, only the <info> block(s) where this

automated translation has taken place should use the parameter.


________________________________________________________________________________________



c. When issuing an update message for an <info> block that contains free form text

content that has been subsequently reviewed by a human for correct translation,

replacing automated translated content, this parameter should be used with a value of

“no”.

d. Issuers who intend to use <autoTranslated> should supply supporting documentation

indicating which elements are/were auto translated.

e. The values “yes” and “no” are not case sensitive and shall not be translated.

Example:

The instruction was auto generated in English by software interpreting a responseType rather

than the free form sentence generated by a person in Italian. A simple parameter element is

used to flag the auto translation activity of the originator:

<info>

<language>en-AU</language> …

<instruction>Take shelter</instruction>

<parameter>

<valueName>profile:CAP(AU)P:1.0:AutoTranslated</valueName>

<value>Yes</value> </info> <info>

<language>ita</language> …

<responseType>Take shelter</responseType>

<instruction>Mettersi al riparo</instruction>

… </info>

3.2.7 Management of Invalid CAP Messages

Systems receiving invalid CAP messages will not necessarily be expected to act on them;

however, rather than aborting the process, it is RECOMMENDED that the message be

flagged with a “concern” or “error” system element and the originator notified of the reason

for the flag. Recipients of a CAP message that may contain one of these elements should

contact the originator for details.

The following XML namespace declaration indicates that the CAP message should validate to

CAP. In this case CAP is identified by the given URN. Since all CAP(AU)P messages are to

validate to CAP then the following line is still a valid line in all CAP(AU)P message


________________________________________________________________________________________



Example:

For an alert issued on 13 May 2011 at 1300 hours for an event that is predicted

in the ACT region (UTC+10:00) to start at 1600 hours and finish at 1700 hours:

<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2"> …

</alert>

3.2.8 Definitions applying to the CAP(AU)P Element and Sub-elements Tables

The elements tables below represents the requirements and guidelines that are intended to

apply to all CAP(AU)P messages. The following definitions apply to the components shown

in the elements tables:

Element: a CAP-XML element as described in the Reference Standard:

o A bold listed Element name denotes that the element is REQUIRED to be used by

this Profile to assure conformance with the CAP Reference Standard.

o A non-bolded Element name denotes that this Profile and the CAP Reference

Standard will accept that use of the element is OPTIONAL.

Use: a rule outlining the usage specifics of an element. As per the Reference Standard,

one of “REQUIRED”, or “Optional”, and as per CAP(AU)P one of “REQUIRED”,

“CONDITIONAL”, “Recommended” or “Optional”.

Type: a categorisation of “Technical” in relation to format or structure, or “Policy” in

relation to the business of public alerting.

Value: allowable values for an element defined by a rule for the element.

Description: a general description of a rule and its purpose.

Notes: any special notes regarding implementation of a rule.

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

N/A: indicates the component is Not Applicable to the particular element.


________________________________________________________________________________________



3.3. ALERT Elements and Sub-elements

3.3.1 <alert>

CAP(AU)P

Element: <alert> Use: REQUIRED Type: Technical

Value: refer Reference Standard

Description: To determine routing, handling and combined security level identification. The

<alert> block is not specific to any included <info> block, but is to serve as a general

reference to all associated <info> blocks and their content.

Notes:

1) Limit one <info> segment per alert message, except where additional <info> blocks have

a different value for <language>.

Example: refer Reference Standard

3.3.2 <identifier>

CAP(AU)P

Element: <identifier> Use: REQUIRED Type: Technical


Description: refer Reference Standard

Notes:

1) Uniquely identifies each message.

2) SHALL be assigned by the originator of the message.

3) 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.

4) A national database of hazard event identifiers does not yet exist in Australia.



________________________________________________________________________________________



3.3.3 <sender>

CAP(AU)P

Element: <sender> Use: REQUIRED Type: Technical


Description: A descriptive and human readable originator that identify the agency that

assembled the message, or on behalf of another agency that originated the message.

Notes:

1) Must be traceable to an Australian agency name that is publicly recognisable.

2) Must be as unique as possible.

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. Preferably, the original message

<identifier> will be added to the <incidents> element, and a <note> added identifying what

was changed.

Examples:

A) 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 as 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.

<alert>

…

<sender>FESA WA </sender>

…

<info>

…

<senderName>WAPOL</senderName>

</alert>

B) An internet domain name as part of <sender> is considered an acceptable method to

create uniqueness.

3.3.4 <sent>

CAP(AU)P

Element: <sent> Use: REQUIRED Type: Technical



Notes: refer Reference Standard



________________________________________________________________________________________



3.3.5 <status>

CAP(AU)P

Element: <status> Use: REQUIRED Type: Technical



Notes:

1) Some organisations may elect not to transmit certain messages based on <eventcode>

values of the messages.

2) Any CAP(AU)P Event Code may be sent with a <status> element <value> of “Test”, in

which case that alert SHALL not be broadcast as a valid alert, but treated as a log-only event.


3.3.6 <msgType>

CAP(AU)P

Element: <msgType> Use: REQUIRED Type: Technical


Description: Message states, and the transition from one state to another, are implied with the

use of the <msgType> and <references> elements.

For alert messages intended for public distribution, a <msgType> of “Alert”, “Update” or

“Cancel” does affect the message state, and an <info> block is REQUIRED.

For alert messages with a <msgType> of “Ack” or “Error”, an info block is not required, as

these messages are primarily intended for system level purposes and not for distribution to

the public.

Notes:

1) When use of Call Sign(s) of the station(s) on which the alert was broadcast are required,

they should use common terminology that is publicly recognisable to the Australian

community.

2) Processing of “Ack” or “Error” messages is optional, and systems may impose their own

associated rules.


________________________________________________________________________________________



CAP(AU)P

Examples:

A) Weather alert for public distribution:

<alert>

…

<status>Actual</status>

<msgType>Alert</msgType>

<source> Australian Government Bureau of Meteorology New

South Wales</source>

<scope>Public</scope>

…

<code>profile:CAP(AU)P:1.0</code>

…

<info>

…

</info>

</alert>

B) Not for public distribution:

<alert>

…


<msgType>Error</msgType>

<source> Australian Government Bureau of Meteorology New

South Wales</source>


…

<code>profile:CAP(AU)P:1.0</code>*

<note >Invalid eventCode</note>

<references >TEST-1,2011-01-01T12:00:00+10:00</references>

…

<info>

…

</info>

</alert>

3.3.7 <source>

CAP(AU)P

Element: <source> Use: Optional Type: Technical






________________________________________________________________________________________



3.3.8 <scope>

CAP(AU)P

Element: <scope> Use: REQUIRED Type: Technical





3.3.9 <restriction>

CAP(AU)P

Element: <restriction> Use: CONDITIONAL Type: Technical



Notes:

1) Reflect the combined classification of all of the <info> blocks and the handling of the

entire message.

2) Classifications are to be in accordance with national security classifications and non-

national security markings listed in the Australian Government Protective Security

Manual (PSM).

3) When <scope> is “Private”, <restriction> is to be used as a combined confidentiality

marker for all <info> blocks.


3.3.10 <addresses>

CAP(AU)P

Element: <addresses> Use: CONDITIONAL Type: Technical



Notes:

1) Use of AS4590-2006 Interchange of Client Information should be applied where

possible to account for land subdivision, cadastral and property issues commonly found in

Australian state and national territory jurisdictions.



________________________________________________________________________________________



3.3.11 <code>

CAP(AU)P

Element: <code> Use: REQUIRED Type: Policy

Value: profile:CAP(AU)P:1.0

Description: A value used to identify which version(s) of the CAP(AU)P that the alert

message is intended to be compliant with.

Notes:

1) <code> is a multi-use element used by the originator to assure compliance with this

Profile approved for use within the Australian environment.

2) Does not preclude the option of using <code> for other purposes, such as version

referencing, layer identification, system specific functions, user-defined values, flag, special

code, etc.

Example:

A) Multiple version reference

<alert>

…



<code>profile:CAP(AU)P:1.X</code>*

…

</alert>

B) Multiple profile reference

<alert>

…



<code>profile:CAP-CP:0.4</code>*

…

</alert>

3.3.12 <note>

CAP(AU)P

Element: <note> Use: Optional Type: Technical






________________________________________________________________________________________



3.3.13 <references>

CAP(AU)P

Element: <references> Use: Optional Type: Technical


Description: All related messages that have not yet expired MUST be included as a reference

for all “Update” and “Cancel” messages

Notes:

1) To include the entire update trail, and not just the most recent update.

2) To accommodate multiple-event scenarios, an alert message may include a reference to an

alert message previously issued by another authority.

3) In the case of an <info> block that does not have an <expires> time, all further messages

in the chain should include a reference to that message since it does not expire on its own.

4) Referencing all alert messages with <info> blocks 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. If

only a single reference were used, a missed message could result in an alert playing beyond

its intended time.

Example:

A) The first Alert message with a <expires> time of 0001UTC:

<alert>

<identifier>IDS20210</identifier>

<sender>Australian Bureau Of Meteorology, Adelaide</sender>

<sent>2011-05-11T00:35:00+09:30</sent>



…

<info>

…

<expires>2011-05-12T00:01:00+09:30</expires>

…

</info>

</alert>

B) Subsequent UPDATE message with a 3 hour <expires> time:

<alert>



<sent>2011-05-11T02:00:00+09:30</sent>


<msgType>Update</msgType>

…

<references>IDS20210,2011-05-11T00:35:00+09:30</references>

…


________________________________________________________________________________________



CAP(AU)P

<info>

…


…

</info>

</alert>

C) Another subsequent UPDATE message with a 3 hour <expires> time the references the

first two related messages:

<alert>



<sent>2011-05-11T03:00:00+09:30</sent>



…

<references>IDS20210,2011-05-11T00:35:00+09:30

IDS20211,2011-05-11T02:00:00+09:30</references>

…

<info>

…


…

</info>

</alert>

D) A further subsequent UPDATE message with a 3 hour <expires> time referencing the

most recent two as the earliest one has expired and should not be playing anymore for two

reasons – a) it has been superseded, or b) it has expired:

<alert>



<sent>2011-05-11T04:00:00+09:30</sent>



…

<references>IDS20211,2011-05-11T02:00:00+09:30

IDS20212,2011-05-11T03:00:00+09:30</references>

…

<info>

…


…

</info>

</alert>


________________________________________________________________________________________



3.3.14 <incidents>

CAP(AU)P

Element: <incidents> Use: Optional Type: Technical






________________________________________________________________________________________



3.4. INFO Elements and Sub-elements

3.4.1 <info>

CAP(AU)P

Element: <info> Use: REQUIRED Type: Policy


Description: Multiple <info> blocks are permitted per single <alert> message.

except where additional <info> blocks differ from one another in content language and

<language> value.

Notes:

1) This block must be included for all alert messages intended for public distribution.

2) Different <info> blocks can be used in a single <alert> message that uses a single

<identifier> element, in order to support two different <area>s that are under varying levels

of threat, where each <area> requires different urgency/severity/certainty values, providing

the same <event> and <eventcode> is used in both <info> blocks.

3) When the <msgType> is an “Update”, and one but not all <info> blocks are being updated

or added, a <parameter> <valuename> of “Update” with a value of “Same” or “Revised”

SHALL be included.

4) Multilingual messages MUST use separate <info> blocks for each language, with all non

free-form text elements repeated verbatim in each block, but each block must be identical

except for free form text and resource links (i.e. they must have the same eventCode,

urgency, severity, certainty, geocodes).

5) In the case of an <info> block that does not have an <expires> time, all further messages

in the chain should include a reference to that message since it does not expire on its own.

Example:

A) Weather alert for public distribution:

<alert>

…



<source>Australian Government Bureau of Meteorology

Victoria</source>


…

<code>profile:CAP(AU)P:1.0</code>

…

<info>

…

</info>

</alert>


________________________________________________________________________________________



B) One CAP alert message with two <info> blocks supporting two different areas, each

having different urgency/severity/certainty values

• One CAP alert message

• One identifier

• Two <info> blocks supporting two languages

• CAP-CP insists the only difference is the language of the free form text,

resource links

They must have the same eventCode, urgency, severity, certainty, etc.

C) One CAP alert message with two <info> blocks supporting two different areas, each

having different urgency/severity/certainty values

• One identifier

• Two

• CAP-CP insists they both have the same <event> and <eventCode>

• They can have different urgency, certainty and severity values. Ex. Leading

edge of the cyclone, versus a lower risk area on the side of the storm

D) One CAP alert message with two <info> blocks supporting two different areas, each

having different urgency/severity/certainty values, and two languages

• One CAP alert message

• One identifier

• Two <info> blocks supporting two different areas, each having different

urgency/severity/certainty values, and two languages

• CAP-CP insists all of the <info> blocks have the same <event> and

<eventCode>

• The two English and two French <info> blocks may have different

urgency, severity, certainty values, free form text, areas, etc.

• CAP-CP insists that the paired English and French <info> blocks must be

identical except for free form text, resource links

• They must have the same eventCode, urgency, severity, certainty,

geocodes, etc.

3.4.2 <language>

CAP(AU)P

Element: <language> Use: Recommended Type: Technical

Value: blank or “en-AU” or an alternate language that is identified in accordance with

country codes specified in the “Codes for the Representation of Names of Languages (ISO

639.2)”


Notes:

1) Reference Standard assumes that a null value in this element SHALL be considered

equivalent to US English or “en-US”.


________________________________________________________________________________________



2) "en-AU" to be used when the Reference Standard 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).

3) All messages with an <info> block MUST include the <language> element in order to

denote the language of the content of the <info> block.

4) This profile requires that <language> be completed by alert message originators 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>

block 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> blocks (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.

Example:

A) Australian English:

<info>

<language>en-AU</language>

…

</info>

B) Italian:

<info>

<language>ita</language>

…

</info>

3.4.3 <category>

CAP(AU)P

Element: <incidents> Use: Optional Type: Technical





________________________________________________________________________________________




3.4.4 <event>

CAP(AU)P

Element: <event> Use: REQUIRED Type: Policy

Value: MUST be derived from the Tier I or Tier II column of the “AUeventLIST”.

Description: A CAP(AU)P message SHALL include only one event code that is extracted

from either the Tier I or Tier II column of the Australian Event Code List for CAP(AU)P

(AUeventLIST). Using these pre-defined values ensures that all public alert messages are

using common terminology to describe hazard events.

Notes:

1) The Reference Standard allows for the inclusion of none, one, or many <event> elements

in a single alert message, but only one unique message <identifier>. In order to avoid any

potential confusion, or difficulty handling a single alert message containing multiple events,

where an update to the information of any one of the events would appear as an update to the

information of all the other events, CAP(AU)P will constrain each alert message to one

single event reference.

2) Event values will be used for the purpose of filtering, routing, validating, and other needs

within the user community.

3) A practical method of validating this rule is to ensure that all <info> blocks in an alert

message have the same <eventCode> value.

4) 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.

Example:

A) Acceptable

<alert>

…

<info>

…

<event>Thunderstorm</event>

…

<eventCode>*

<valueName>CAP(AU)P:AUeventLIST:1.0</valueName>

<value>thunderstorm</value>

</eventCode>

…

<area>*

<areaDesc>area 1</areaDesc>

…

<geocode>*

<valueName>ASGC</valueName>

<value>XXX</value>


________________________________________________________________________________________



</geocode>

…

</area>

</info>

<info>

…


…

<eventCode>*



</eventCode>

…

<area>*


…

<geocode>…</geocode>

…

</area>

</info>

</alert>

B) Not Acceptable

<alert>

…

<info>

…


…

<eventCode>*



</eventCode>

…

<area>*


…


…

</area>

</info>

<info>

…

<event>Tornado</event>

…

<eventCode>*


<value>tornado</value>

</eventCode>

…


________________________________________________________________________________________



<area>*


…


…

</area>

</info>

</alert>

3.4.5 <responseType>

CAP(AU)P

Element: <responseType> Use: Recommended Type: Technical


Description: It is recommended that alert message issuers 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.


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>

3.4.6 <urgency>

CAP(AU)P

Element: <urgency> Use: REQUIRED Type: Technical



Notes:

1) Australian jurisdictions / organisations will need to tailor the jurisdiction implementation

of CAP(AU)P to the urgency values used within each particular jurisdiction



________________________________________________________________________________________



3.4.7 <severity>

CAP(AU)P

Element: <severity> Use: REQUIRED Type: Technical



Notes:


of CAP(AU)P to the severity values used within each particular jurisdiction


3.4.8 <certainty>

CAP(AU)P

Element: <certainty> Use: REQUIRED Type: Technical



Notes:


of CAP(AU)P to the certainty values used within each particular jurisdiction


3.4.9 <audience>

CAP(AU)P

Element: <audience> Use: Optional Type: Technical



Notes:

1) If used, this element MUST be set to reflect the classification of the information contained

in the <info> block.

2) Classifications are to be set in accordance with national security classifications and non-

national security markings listed in the Australian Government Protective Security

Manual (PSM).



________________________________________________________________________________________



3.4.10 <eventCode>

CAP(AU)P

Element: <eventCode> Use: Optional Type: Technical



Notes:

1) <valueName> MUST reflect the short title of the authorised event code list that is to be

the source for the <event> value.

2) Limit of one <value> per <eventCode> block

3) Conventions regarding Event Codes: All values for CAP(AU)P Event Code SHALL be

passed through by CAP(AU)P-compliant devices, even if the Event Code is not shown in the

AUeventLIST, providing the value does not exceed 12 characters. This acknowledges the

possible existence of non-Australian codes which may appear in other alert messages.

4) The <valueName> version suffix 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.

Examples:

A) For the AUeventLIST:


B) For an updated version of the AUeventLIST where codes may need to be used from the

previous list during transition to the new list:

<valueName>CAP(AU)P:AUeventLIST:1.0</valueName> <valueName>CAP(AU)P:AUeventLIST:2.0</valueName>

C) For the Canadian event code list:

<eventCode>

<valueName>CAP-CP:xxxxxxx:n.n</valueName> <value>SVR</value>

</eventCode>

Where xxxxxxx denotes the short title of the Canadian list; n.n denotes the version

number of the Canadian list; and SVR denotes the actual event code to be used.


________________________________________________________________________________________



3.4.11 <effective>

CAP(AU)P

Element: <effective> Use: REQUIRED Type: Technical



Notes:

1) Alerts SHALL be effective upon issuance

2) The <description> and <instruction> elements may refer to past or future events or

actions.

Example:

A) Correctly formatted <effective> time in Hobart at 0700 AEST:

<alert>

…

<info>

…


…

</info>

</alert>

3.4.12 <onset>

CAP(AU)P

Element: <onset> Use: Optional Type: Technical






________________________________________________________________________________________



3.4.13 <expires>

CAP(AU)P

Element: <expires> Use: REQUIRED Type: Technical


Description: To be completed by alert message originators so that distributors can know how

long the information within an <info> block of an alert message should remain in effect.

Notes:

1) Only correctly formatted date and time values should be used. Do not use a default value

such as “0”, an empty string or a null entry as this would be considered invalid.

Example:

A) Correctly formatted <expires> time in Darwin at 0700UTC:

<alert>

…

<info>

…


…

</info>

</alert>

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)


________________________________________________________________________________________



3.4.14 <senderName>

CAP(AU)P

Element: <senderName> Use: Recommended Type: Technical


Description: It is strongly recommended that this element be populated by alert message

originators as this value is expected to be used for public presentation purposes.

Notes:

1) To be the publicly-recognisable name of the agency issuing the alert, including an The

appropriately translated value for the name in each <info> block of a multilingual alert

message.

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.

Example:

<alert>

…

<sender>FESA WA </sender>

…

<info>

…

<senderName>WAPOL</senderName>

</alert>

3.4.15 <headline>

CAP(AU)P

Element: <headline> Use: Recommended Type: Technical



Notes:

1) Headline SHALL include:

text associated with <event>,

text associated with <geocode> value(s), and

the word “to” followed by value for <expires>.







________________________________________________________________________________________



3.4.16 <description>

CAP(AU)P

Element: <description> Use: Optional Type: Technical



Notes:

1) Address essential information first as content may get truncated during transmission.






3.4.17 <instruction>

CAP(AU)P

Element: <instruction> Use: Recommended Type: Technical



Notes:

1) Should be completed by alert-message originators to improve clarity and provide public

with direction concerning what actions to take in order to stay out of harm‟s way, except in

circumstances where the <instruction> information should only be added by an alternate

authority; consequently, the originator will distribute the initial alert message (without an

<instruction> element included) and the alternate authority will receive that message and add

the <instruction> element then re-distribute the message accordingly.

3) Address essential information first as content may get truncated during transmission.





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.


________________________________________________________________________________________



3.4.18 <web>

CAP(AU)P

Element: <web> Use: Optional Type: Technical





3.4.19 <contact>

CAP(AU)P

Element: <contact> Use: Optional Type: Technical





3.4.20 <parameter>

CAP(AU)P

Element: <parameter> Use: Recommended Type: Technical

Value: A <valueName> of “profile:CAP(AU)P:1.0:MinorChange” and a <value> of “none”,

“text”, “correction”, “resource”, “layer”, or “other”. The values are not case sensitive, and

shall not be translated.

Description: Alert message originators MUST 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.

Notes:

1) This parameter may only be used when the <msgType> is “Update” and the <references>

element is correctly populated.

2) The Authority who is issuing the alert message MUST decide whether any duplication

exists in the proposed content of a CAP message.

3) “AUeventLIST” provides the <valueName> to be used with events.

4) Adding or removing an <info> block relative to the previous message is considered a

substantive change. This element MAY only be used when all <info> blocks 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>

blocks. Both sending and receiving systems are free to impose additional constraints on

what they consider to be non-substantive changes.

6) When an alert message is considered a minor update, all <info> blocks must contain a


________________________________________________________________________________________



“MinorChange” parameter value(s) with an appropriate value setting reflecting the minor

change.

7) When no change has occurred in an <info> block relative to the previous message, the

value of “none” should be used.

8) When a change has occurred between <info> blocks where some free form text content

may have been added or modified, the value of “text” should be used in the <info> block(s)

where applicable.

9) When a correction is made to some of the free form content, perhaps because of an error,

spelling mistake or omission, the value of “correction” should be used in the <info> block(s)

where applicable.

10) When the addition, modification, or removal of a <resource> block and its associated

content takes place relative to the previous message, the value of “resource” should be used

in the <info> block(s) where applicable.

11) 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> block(s) where

applicable.

12) When the content change doesn‟t meet the criteria of the other parameter values, the

value of “other” should be used in the <info> block(s) where applicable. A <note> element

should always be used with “other” changes.

13) A <note> element may be used to further explain the reason for the minor changes in this

update.

14) “Update” is the <valueName> to be used with alert updates when one, but not all <info>

blocks are being updated, as per direction in the <info> element.

15) Electing to process non-substantive content is left up to the sender or receiver.

16) If a receiver chooses to ignore this parameter and value, all update messages should be

considered substantive as per the intent of the Reference Standard.

17) If a transmission error occurs and the receiver does not receive the referenced previous

message to which the non-substantive change applies, the current message should be

considered substantive.

18) CAP extensions must be added using only the <parameter> element.


________________________________________________________________________________________



Example:

<parameter>

<valueName>profile:CAP(AU)P:1.0:MinorChange</valueName>

<value>correction</value>

</parameter>


________________________________________________________________________________________



3.5. RESOURCE Elements and Sub-elements

3.5.1 <resource>

CAP(AU)P

Element: <resource> Use: Optional Type: Technical





3.5.2 <resourceDesc>

CAP(AU)P

Element: <resourceDesc> Use: REQUIRED Type: Technical



Notes:

1) Content is identified by use of the <mimeType> value


3.5.3 <mimeType>

CAP(AU)P

Element: <mimeType> Use: REQUIRED Type: Technical



Notes:

1) Single format be specified for each of these types.

2) Preference should be given to use of open, non-proprietary standards.

3) Address essential information first as broadcast content may get truncated during

transmission depending on length of content.


3.5.4 <size>

CAP(AU)P

Element: <size> Use: Optional Type: Technical






________________________________________________________________________________________



3.5.5 <uri>

CAP(AU)P

Element: <uri> Use: Optional Type: Technical





3.5.6 <derefUri>

CAP(AU)P

Element: <derefUri> Use: Optional Type: Technical





3.5.7 <digest>

CAP(AU)P

Element: <digest> Use: Optional Type: Technical






________________________________________________________________________________________



3.6. AREA Elements and Sub-elements

3.6.1 <area>

CAP(AU)P

Element: <area> Use: REQUIRED Type: Technical



Notes:

1) Must include a minimum of one recognised <geocode> value.

2) To maximise effectiveness to the public, the use, where possible, of one <area> block per

<info> block is encouraged.

3) Where multiple <area> blocks are used, consolidation of <area> blocks into as few <area>

blocks as possible is also encouraged.

4) Area descriptions (like events) will need to be translated by the originator of the message

in cases where the name is not derived from the recognised Location Reference source.

5) In the case of both single and multiple <area> blocks, each <AreaDesc> will have one

value and will be in the language of the <info> block.

6) In cases of multiple <area> blocks, each <area> block will differ by their <AreaDesc>

value and recognised <geocode> value(s), without additional parameterisation, in order to

maintain the integrity of International CAP-XML messages within this Profile.

7) It is recommended that an associated geospatial value for the <polygon> or <circle>

elements be included in the <area> block as well.

Example:

<info>

…

<area>

<areaDesc>Near Bowen, QLD</areaDesc>

…

<circle>-20.085,147.764 10</circle>*

<geocode>*

<valueName>ASGC</valueName>

<value>…</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.

3.6.2 <areaDesc>

CAP(AU)P

Element: <areaDesc> Use: REQUIRED Type: Technical


Description: Textual description of the area defined by the combination of area elements.

Notes:

1) May not necessarily be a name found in the Location Reference document identified under

<geocode>.






3.6.3 <polygon>

CAP(AU)P

Element: <polygon> Use: Optional Type: Technical





3.6.4 <circle>

CAP(AU)P

Element: <circle> Use: Optional Type: Technical





3.6.5 <geocode>

CAP(AU)P

Element: <geocode> Use: Optional Type: Technical

Value: The <valueName>,< value> pair for an associated code from the CAP(AU)P Location

References document.

Description: At least one recognised <geocode> value from the Location References document

SHALL be used for messages that describe areas within the Australian region. Multiple

<geocode> elements MAY be used as necessary to fully cover the alert message target area.

Notes:


________________________________________________________________________________________



1) Geocodes are included so that all distribution systems are capable of distributing alerts, and

for other purposes such as translation. When present in the message, polygons are the preferred

method for defining the alert area.

2) The Location References document is the Australian Standard Geographical Classification

(ASGC), which is maintained by the Australian Bureau of Statistics and is updated annually as

the changes to gazetted Local Government Areas are proclaimed by state and territory

government authorities. The latest version of the ASGC can be sourced from:

http://www.abs.gov.au/websitedbs/D3310114.nsf/home/Australian+Standard+Geographical+Classification+(ASGC)

3) Use of only the highest level, all encompassing area division that fully applies to a message, is

recommended.

4) Other geocodes may also be utilised to suit the hazard situation, including Post Codes with

four (4) decimal characters with no space between characters. More precise means of location

identification, such as geospatial polygons, are encouraged to accurately describe the area to

which the alert pertains.

5) A geocode consisting of six zeros ("000000") shall indicate a message intended for the entire

continent of Australia and its Territories.

6) The <valueName> version suffix will change as new versions of the Location References

document are published. Messages may include <geocode>s from different versions of the

Location References document in order to provide backward compatibility and to ease transition

between list updates.

Examples:

A) For 2) above:

<geocode>

<valueName>ASGC:n.n</valueName>

<value>…</value>

</geocode>

Where: n.n denotes the version of the location reference source being used

B) For 4) above:

<geocode>

<valueName>postCode</valueName>

<value>2600</value>

</geocode>

B) For 5) above:

<geocode>

<value>000000</value>

</geocode>

http://www.abs.gov.au/websitedbs/D3310114.nsf/home/Australian+Standard+Geographical+Classification+(ASGC)


________________________________________________________________________________________



3.6.6 <altitude>

CAP(AU)P

Element: <altitude> Use: Optional Type: Technical





3.6.7 <ceiling>

CAP(AU)P

Element: <ceiling> Use: Optional Type: Technical






________________________________________________________________________________________



3.7. Acknowledgements

"OASIS" is the trademark of the Organisation for the Advancement of Structured Information

Standards, who is an open standards consortium who own and develop the CAP specification.

The Attorney-General‟s Department acknowledges that this document was developed with the

value-adding assistance of the Canadian Association for Public Alerting and Notification

(CAPAN), the OASIS Emergency Management Technical Committee (EM-TC) and the

OASIS CAP Profiles Sub-Committee.

Appendixes:

1. Abbreviations and Acronyms.

2. Structural template - CAP Australia Profile.


_________________________________________________________________________________________

CAP(AU)P:Version:0.2 Page 1-1


APPENDIX 1 TO CAP(AU)P

ABBREVIATIONS AND ACRONYMS

Acronym Meaning

ACDT Australian Central Daylight Time zone (equivalent to UTC +10:30)

ACST Australian Central Standard Time zone (equivalent to UTC +09:30)

AEDT Australian Eastern Daylight Time zone (equivalent to UTC +11:00)

AEST Australian Eastern Standard Time zone (equivalent to UTC +10:00)

AGD Attorney-General‟s Department

AUeventLIST Australian Event Code List for CAP(AU)P

AWST Australian Western Standard Time zone (equivalent to UTC +08:00).

Daylight savings time does not apply in Western Australia at this time.

CAP OASIS Common Alert Protocol (or Reference Standard)

CAP-CP Common Alerting Protocol Canadian Profile

CDC Center for Disease Control

CIV Civil authorities

CMAS Commercial Mobile Alerting System

DAB Digital Audio Broadcast

DBS Direct Broadcast Satellite

DE Distribution Element

DOM Document Object Model

EDXL Emergency Data Exchange Language

EDXL-CAP Emergency Data Exchange Language Common Alert Protocol

EDXL-DE Emergency Data Exchange Language Distribution Element

EOC Emergency Operations Center

IETF Internet Engineering Task Force

ISO International Organisation for Standardization

ISO 8601 Data elements and interchange formats -- Information interchange --

Representation of dates and times

OASIS Organisation for the Advancement of Structured Information Standards

PMO Project Management Office

RFC Request for Comments


_________________________________________________________________________________________



Acronym Meaning

SDARS Satellite Digital Audio Radio System

URL Uniform Resource Locator

XML Extensible Markup Language


APPENDIX 2 TO CAP(AU)P

_________________________________________________________________________________________



STRUCTURAL TEMPLATE - CAP AUSTRALIA PROFILE

The following template illustrates the structure of CAP. The following statements apply to

the information presented below:

A bold listed element name denotes that the element is REQUIRED to be used to assure

conformance with the OASIS CAP standard.

A bolded and italicised element name denotes that the element is REQUIRED to be used

to assure conformance with the CAP(AU)P standard.

A non-bolded element name denotes that use of the element is OPTIONAL under both

CAP and CAP(AU)P.

Asterisks (*) indicate that multiple instances are permitted under the CAP and CAP(AU)P

standards.

An example CAP message using the structure indicated above can be viewed in Appendix A

of the OASI CAPv1.2 standard available at:




_________________________________________________________________________________________



<alert> <identifier></identifier> <sender></sender> <sent></sent> <status></status> <msgType></msgType> <source></source> <scope></scope> <restriction></restriction> <addresses></addresses> <code>profile:CAP(AU)P:1.0</code>* <note></note> <references></references> <incidents></incidents> <info>

<language>en-AU</language>

<category></category>* <event></event> <responseType></responseType>* <urgency></urgency> <severity></severity> <certainty></certainty> <audience></audience> <eventCode>*

<valueName>CAP(AU)P:AUeventLIST:1.0</valueName> <value></value>

</eventCode> <effective></effective> <onset></onset> <expires></expires> <senderName></senderName> <headline></headline>

<description></description> <instruction></instruction> <web></web> <contact></contact> <parameter></parameter>* <resource>*

<resourceDesc></resourceDesc> <mimeType></mimeType> <size></size> <uri></uri> <derefUri></derefUri> <digest></digest>

</resource> <area>*

<areaDesc></areaDesc> <polygon></polygon>*

<circle></circle>* <geocode>*

<valueName>ASGC</valueName> <value> </value>

</geocode> <altitude></altitude> <ceiling></ceiling>

</area> </info>

</alert>