Common Alert Protocol: UK Profile Discussion Document
Page 1 / March 2015
Preface
This document draws heavily upon the work undertaken by the Organisation for the Advancement of Structured Information Standards (OASIS) in developing the Common Alert Protocol (CAP). The United Kingdom is grateful to OASIS for agreeing to work together on this matter.
Acknowledgement
"OASIS" is the trademark of the Organisation for the Advancement of Structured Information Standards, who are an open standards consortium where the CAP v1.2 specification is owned and developed.
Contents
1.Introduction
1.1Purpose
1.2Scope
1.3United Kingdom Emergency Management Context
1.4Document Structure
2.CAP-UK Description
2.1CAP-UK Scope
2.2CAP-UK Description (Source)
2.3CAP-UK Structure Requirements
3.CAP-UK Methodology & Requirements
3.1CAP-UK Elements
ANNEX A: CAP-UK USE CASES
No notice incidents
No notice incident at a hazardous site:
A flood alert
Rising tide events
National Disaster
ANNEX B: ABBREVIATIONS AND ACRONYMS
ANNEX C: UK EVENT LIST
Common Alert Protocol: UK Profile Discussion DocumentPage 1 / March 2015
1.Introduction
The UK is committed to make better use of open standards and this is a key part of the UK’s Technology Strategy. Overseen by the Open Standards Board[1], a transparent process exists to identify and agree open standards that might suit the needs of the United Kingdom. Once agreed, all central Government departments are expected to have regard to that standard when developing new technology services. The Open Standards Board has agreed that the Common Alert Protocol[2](CAP) meets the challenge of a Public Emergency Alert Message[3] - on the proviso that a UK Profile is developed.
Working with OASIS, Her Majesty’s Government looks forward to developing a common standard for the dissemination of alert and warning messages during an emergency. Throughout this document, the words “warning,” “alert,” and “message” will be used interchangeably.
1.1Purpose
This document: “The Common Alerting Protocol –UK Profile Discussion Document” provides interested stakeholders with the initial views of the United Kingdom on the content of a UK-profile.
Because public warnings can be encoded various ways in CAP, a standardised guideline is desired across all equipment manufacturers and warning practitioners. The Cabinet Office (CO) and the UK CAP stakeholder community have developed this document to pose questions to the CAP community. The answers to these will enable the UK to better understand the rationale and logic behind the CAP standard and guide the UK with its decisions.
1.2Scope
CAP-UK will initially design the capability to pass CAP v1.2 alerts and warnings through UKalerting systems. The primary use case supported by CAP-UK requires an originator to create andsend a message that complies with the CAP-UK structure. Annex A highlights a number of scenarios where an alert message might be issued.
The aim is that an alert message can be disseminated tomultiple target systems or exchange partners.
1.3United Kingdom Emergency Management Context
The United Kingdom operates a localised approach to emergency management. The legislative framework for the UK is set by the Civil Contingencies Act 2004 (CCA), which outlines the activities that need to be undertaken and by whom. This includes a statutory duty on category 1 responders[4] to maintain arrangements to warn and inform the public of emergencies alongside other core tasks such as identifying risks, developing emergency plans and maintaining business continuity arrangements. This can include agreeing that a nominated category 1 responder undertake this function on behalf of another. This is clarified by the statutory guidance accompanying the act.
Should an emergency occur within Scotland, Northern Ireland or Wales; the relevant government may provide additional support and coordination mechanisms.
1.4Document Structure
In addition to this introductory section, there are two further sections:
- Profile Requirements: Presented in the form of requirements and guidelines that any subsequent UK profile will need to address. It is important to note that CAP-UK isnot intended to become new a messaging standard, but it is only a constrained version of theexisting CAP v1.2 standard.
- Technical Questions: Presented in the form of a table identifying the CAP elements and questions or comments that the UK would be grateful for views from the CAP community on.
2.CAP-UK Description
CAP-UK has been established to meet the UK’s ambition to improve end-to-end incident communications between agencies and the public.The goal for CAP-UK is to provide the vehicle by which alerts and warnings can be sent to the greatest number of people, including those with disabilities and those who do not have English as their primary language. CAP-UK shall be required to disseminate messages over as many platforms as possible to ensure the widest dissemination.
2.1CAP-UK Scope
The scope of CAP-UK has two dimensions. The first is to become the end-to-end system ofmessage dissemination. CAP-UK provides the United Kingdom with the capacity for immediatecommunication to the general public at the national, regional and local levels during periods of emergency. The Profile will be available for use by Ministers, Commanders from the emergency services, utility providers and other public and private sector entities dependent on the situation.
The second dimension is as an alert and warning medium. The three basic componentsof any communication are the message, the medium, and the audience. CAP-UK forms part of the medium by providing a structure for the way that messages are issued. Itneither influences the message nor the audience; although, all three components interrelate. It providesa capacity to transmit simultaneous translations of messages into one or more languages for all users,and it is the means for disseminating alerts and warnings at all the levels of an incident.
Within the domain of a message, there are differing roles and responsibilities:
- There is anindividual who sends the message (for example a Minister, or Police Gold Commander, Public Health Official etc).
- There is an organisation that may be involved in this message (e.g. the Environment Agency or the Police service).
- The audience forthat message is made up of organisations (partner agencies, government departments, Devolved governments, local governments, andthe private sector) and individuals (people).
CAP-UK is the means and the mechanism for a message to reach its audience. The mode can bebroadcast (television, radio, internet) or targeted (telephone contact or Internet), but the means does notinfluence who provides the message, what the message says, or the intended audience. It is solely themanner through which the message is conveyed. CAP-UK provides communications andinteroperability capabilities that transcend the life cycle of a disaster or hazard event as alluded to by theUK Risk Register of Civil Emergencies[5]. The Civil Contingencies Act 2004 and its accompanying guidance advise what emergency responders are expected to do, with each emergency responder determining the level and scale of notification. CAP-UK offers the following benefits to the United Kingdom:
- Provide an endorsed Government standard to jurisdictions and government Agencies that willguide future implementations of CAP during upgrades to alert and warning system technologies;
- Establishes a requirement upon future users of CAP-UK to implement a consistentstandard of CAP terminology and message structure; and
- Provides a common standard and interoperability matrix that all organisations can use when interoperating with neighbouring or partner organisations.
2.2CAP-UK Description (Source)
By starting with the complete CAP v1.2 specification, together with other profiles that have been developed internationally we can map the needs of the CAP-UK. To follow UK policy and the direction provided by its Open Standards Board, the reference CAP specification is constrained and may define <parameter> tags for any unique needs of the United Kingdom that do not correspond to existing OASIS CAP elements. Requirements in followingsections define the “source Profile” by tailoring and constraining CAP v1.2.
In particular, consideration will be given to likely dissemination technologies and their operating constraints to maximise the value of any given alert or warning message.
2.3CAP-UK Structure Requirements
Any message that is compliant with the Profile must validate against the originalXML Schema as well as the resulting XML Schema of the Profile.
CAP v1.2 is an XML message standard that also contains an XML Schema, which is to be used forvalidation of the CAP v1.2 message. The CAP-UKmust result in a constrained XML messageadhering to the following requirements.
Table 1: CAP-UK Criteria and Miscellaneous Requirements
CAP-UK Criteria and Miscellaneous RequirementsNumber / Requirement
1. / A developed and agreed-to CAP-UKSchema must adhere to the requirements contained herein.
2. / Unless otherwise stated within this “CAP-UK Requirements” table, all OASIS CAP v1.2 elements SHALL be adhered to exactly as specified in the OASIS CAP v1.2 Standard.
3. / The CAP-UK MUST not become a new or additional messaging “standard” (i.e. another Alertsand Warnings standard or another CAP v1.2 “version”). It is simply a more constrainedversion of an existing messaging standard.
4. / The CAP-UK message MUST comply with the CAP v1.2 standard.
a)A CAP-UK message MUST always validate against the CAP v1.2 standard Schema.
b)Definition and Development of the CAP-UK message may result in a morerestrictive Schema.
c)A CAP-UK message MUST validate within the CAP v1.2 standard namespace with nochanges to root elements.
d)A CAP-UK message MUST use all elements defined as mandatory within CAP v1.2
e)A CAP-UK message MUST not change attributes for mandatory fields.
5. / A CAP-UK MUST be capable of using an existing CAP v1.2 standard service (i.e. software designed to apply the standard) to receive and understand a CAP-UK message.
6. / A CAP-UK message MUST NOT be of a Proprietary Format.
7. / A CAP-UK message MAY further constrain the CAP standard.*
(* may be thought of as a “constraint Schema” against the standard)
8. / A CAP-UK message MAY add to required element definitions.*
(*only to extend or clarify interpretation of the definition)
9. / A CAP-UK message MAY limit the size of required elements.
10. / A CAP-UK message MAY exclude optional elements.
11. / A CAP-UK message MAY define elements in a specific, agreed-upon way – as defined and adjudicated for the Profile
12. / A CAP-UK will adhere to broader UK policies and principles set out by the UK Open Standards Board.
13. / The inclusion of MIME extensions shall be prohibited.
14. / Any digital signatures used shall adhere to guidance from CESG as the UK’s National Technical Authority.
3.CAP-UK Methodology & Requirements
In line with CAP v1.2, the <alert> block of the CAP v1.2 message will be utilised by CAP-UK todetermine routing and handling. The <alert> block is notspecific to any included <info> block, but a general reference to all associated <info> blocks and theircontent. No specific information about any particular <info> block will be included in the <alert>block, unless it will not impact any subsequent <info> blocks. The <alert> block is designed for CAP-UKgeneral use. Each <info> block is designed to meet the needs of individual message exchangepartners.
The methodology applied while proceeding through the CAP v1.2 elements list gives preference to CAP-UK for each element interrogated. CAP extensions must be added using the <parameter> element, which may duplicate the intent of some of the <alert> elements.
Unless otherwise stated within these tables, all OASIS CAP v1.2 elements SHALL be adhered to exactly as specified in the OASIS CAP v1.2 Standard. Terminology within these tables SHALL be interpreted in accordance with 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 no impact applies.
3.1CAP-UK Elements
The elements table below identifies the elements present in a CAP version 1.2 message. In some cases questions are posed against these to better understand the rationale behind choices and inform the UK’s position on these matters. These questions are informed by consideration of other national profiles developed.
The following statements apply to the information presented in the table below:
a)An emboldened Element Name denotes that the element is REQUIRED to be used by this Profile toassure conformance with the OASIS™ CAPv1.2 standard.
b)A plain element name denotes that this Profile will accept that use of the element isOPTIONAL as per the OASIS™ CAPv1.2 standard.
c)Conformance with this Profile can be assured through implementation of the requirements thatmodify existing OASIS™ CAP v1.2 requirements are denoted against a particular element name inthe column titled “CAP-UK Requirements”, unless otherwise stated in the table.
Version0.1 - DRAFT
March 2015
Common Alert Protocol: UK Profile Discussion DocumentPage 1 / March 2015
Element Name / CAP-UK Requirements / Discussion questions
“alert” Element and Sub-elements
1 / alert / (1)Limit one <info> segment per alert, except where additional <info> segments have a different value for <language>. / It’s noted that several other profiles have revised this to limit one alert to one info black.
- It is assumed that this to minimise the length of an individual CAP message –is this correct?
- What are the disadvantages to this?
2 / identifier / (1)A unique number assigned to each message. / The UK’s initial thoughts are that this is a combination of an identifier for each organisation and then its own message ID – assume this is satisfactory?
3 / sender / (1)Must be traceable to an UK agency that is publicly recognisable.
(2)To be based on the organisation’s domain name.
4 / sent / As per OASIS™ CAP v1.2 requirements / What are the implications of following CAP time rather than ISO 8601? These differ on that the time at UTC is referred to -00:00 for CAP rather than +00:00 for ISO 8601?
5 / status / As per OASIS™ CAP v1.2
6 / msgType / As per OASIS™ CAP v1.2
7 / source / As per OASIS™ CAP v1.2 requirements, in addition:
(1)The Role of the individual authorising the message should be entered here.
(2)If the alert message is being processed on behalf of another organisation, details of the requesting agency must be entered here. / How should we reference the Source for audit purposes?
8 / scope / As per OASIS™ CAP v1.2 requirements, values of public, restricted or private on;y. / Either public, restricted, or private.
9 / restriction / As per OASIS™ CAP v1.2 requirements
10 / addresses / (1)? / Our current thoughts are that this will be to a designated email address – are there any problems foreseen with this?
11 / Code / (1)REQUIRED
(2)Value SHALL include the string “CAP-UK v1.0” to indicate originator assures compliance with this Profile approved for use within the UK environment / It has been assumed that including this is necessary Would this be flagged in message header in any case?
12 / note / As per OASIS™ CAP v1.2 requirements
13 / references / (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)All related messages that have not yet expired MUST be included as areference for all “Update” and “Cancel” messages / Linked to “identifier” above
Placing a conditional requirement seems sensible? I.e. if mesg = Update / Cancel then this is mandatory?
14 / incidents / As per OASIS™ CAP v1.2 requirements / How have others solved this problem which for example may arise through having many alerts referring to the same incident. Super storm Sandy for example.
“info” Element and sub-elements
15 / info / (1)Limit of one <info> per <alert>, except where additional <info> segments differ from one another in content language and <language> value.
(2)When the <msgType> is an “Update”, and one but not all <info> segments are being updated or added, a <parameter> <valuename> of “Update” with a value of “Same” or “Revised” SHALL be included.
Note: <info> blocks will be specifically tagged with <parameter>
information as to identify which exchange partner is applicable to that block. The order in which the exchange partner <info> blocks appear in the <alert> is not constrained. / It would be interesting to understand the rationale why others have followed this path of constraining 1:1
16 / language / (1)REQUIRED
(2)If not present, an implicit default value of "en-GB" SHALL be assumed.
(3)A null value in this element SHALL be considered equivalent to “en-GB”
(4)The profile requires that <language> be completed by alert message originators to ensure an appropriate value is used.
Note: The language value is important for message distributors / The UK would make this mandatory to default the language to en-GB.
17 / category / As per OASIS™ CAP v1.2 requirements
18 / event / (1) / The UK notes that Aus, Can, US have developed a list of events for this. What is the benefit of doing so?
19 / responseType / As per OASIS™ CAP v1.2 requirements
20 / urgency / As per OASIS™ CAP v1.2 requirements. Code values are Immediate, Expected, Future, Past, Unknown / The UK notes these values We need to map CAP values vs UK terms.
CAP values: Immediate, Expected, Future, Past, Unknown
21 / severity / As per OASIS™ CAP v1.2 requirements. Code values are: Extreme, Severe, Moderate, Minor, Unknown. / The UK will need to map its existing terms against these values.
22 / certainty / As per OASIS™ CAP v1.2 requirements. Code values are Observed, Likely (p>~50%), Possible (p<=50%), unlikely (p~0), unknown / The UK will need to map its existing terms against these values.
23 / audience / As per CAP v1.2
24 / eventCode / As per OASIS™ CAP v1.2 requirements / The UK notes that Aus, Can, US have developed a list of events for this. What is the benefit of doing so?
25 / effective / As per OASIS™ CAP v1.2 requirements / The UK will look to make this field mandatory – are there any views on this?
26 / onset / As per OASIS™ CAP v1.2 requirements
27 / expires / (1)REQUIRED / The UK will look to make this field mandatory – are there any views on this?
28 / senderName / (1)STRONGLY RECOMMENDED
(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. / Why not require?
Plain text version of “sender”
29 / Headline / (1)REQUIRED / For Twitter purposes could we constrain this to 140 characters?
The UK will look to make this field mandatory – are there any views on this?
30 / description / As per CAP v1.2
31 / instruction / (1)STRONGLY RECOMMENDED
(2)<instruction> 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
(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. / Again, detail on content to be informed by work to validate Alert Message content. The UK will look to make this field mandatory – are there any views on this?
32 / web / As per OASIS™ CAP v1.2 requirements
33 / contact / As per OASIS™ CAP v1.2 requirements
34 / parameter / The UK are considering adding an additional parameter for “Risk Rating”. For example, the Met Office issue weather warnings which are a product of its likelihood and impact. (See for more information)
Is a problem foreseen with this?
“resource” Element and sub-Element
35 / resource / As per OASIS™ CAP v1.2 requirements / The UK is considering prohibiting use of this Element in the profile due to concerns that linked to files might contain malicious content.
What are the views on this?
36 / resourceDesc / (1)Content is identified by use of the <mimeType> value
37 / mimeType / (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
38 / size / As per OASIS™ CAP v1.2 requirements
39 / uri / As per OASIS™ CAP v1.2 requirements
40 / derefUri / As per OASIS™ CAP v1.2 requirements
41 / digest / As per OASIS™ CAP v1.2 requirements
“area” Element and sub-Element
42 / area / (1)REQUIRED
(2)Must include a recognised <geocode> value.
(3)To maximise effectiveness to the public, the use, where possible, of one <area> block per <info> block is encouraged.
(4)Additionally, where multiple <area> blocks are used, consolidation of <area> blocks into as few <area> blocks as possible is also encouraged.
(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. / The UK is considering following the precedent set in other profiles where one area block is constrained to each info block.
What might the risks of doing this be?
43 / areaDesc / (1)As per OASIS™ CAP v1.2 requirements / We may provide guidance on here. Where possible this should be recognisable to the local community.
44 / Polygon / As per OASIS™ CAP v1.2 requirements / Do we need to consider how the polygon is drawn?
Point-to-point line drawing of polygons butts against current ways of working with the Met Office in particular using splines. The Environment Agency get around this by using many many points but this complicates the message somewhat.
45 / circle / As per OASIS™ CAP v1.2 requirements
46 / geocode / (1)At least one nationally recognised <geocode> value is REQUIRED.
(2)Other geo-codes may also be included, including Post Codes with 4 decimal character, with no space between characters:
geocode
valueNameGB National Grif Reference<valueName
<value>TQ299804</value>
</geocode
(3)A location code consisting of six zeros ("000000") shall indicate a message intended for the entire United Kingdom. / The UK is considering using GB National Grid Reference or Irish Grid Reference.
Can we cross reference polygons defined elsewhere? This may be “Flood Warning Area AFW10342”, boundaries of public agencies, postcodes or regions. Many of these are already publically available at
Are there any views on these points?
47 / altitude / As per OASIS™ CAP v1.2 requirements
48 / ceiling / As per OASIS™ CAP v1.2 requirements / The internationally accepted measurement for this is metres, yet CAP uses feet – why was this?
Version0.1 - DRAFT