Technical Advisory Note
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
Public Safety Canada, Centre for Security Sciences (CSS)
Emergency Management Systems and Interoperability
Objective and Source
In January 2012 Public Safety Canada (PS) requested the
Centre for Security Science (CSS) research file size limits
defined for “public” alerts using the Common Alerting Protocol
(CAP) standard [1] and, if limits were deemed to be
necessary for technical reasons, to recommend specific limits.
This Technical Advisory Note (TAN) provides a summary of
study findings addressing this question and also offers related
recommendations on best practices for CAP file attachments.
Emergency Management Systems and Interoperability is a
mission area of CSS. CSS provides scientific and technical
support to public safety stakeholders at all levels of
government in Canada. CSS operates under a Memorandum
of Understanding between Public Safety Canada and
Defence R&D Canada within the Department of National
Defence, Government of Canada.
Background, Study Method and Participants
On December 30 2011 the Pelmorex National Alert
Aggregation
and
Dissemination
System
(NAADS)
Governance Council relaxed a one megabyte (MB) CAP file
size limitation that was regarded as too restrictive for some
stakeholders. The Council also encouraged a more formal
study of the matter be conducted with the aim of identifying
and reviewing CAP file size constraints imposed in other CAP
systems around the world.
The study concerned public alerting specifically, addressing
only the dissemination of alert information after a decision is
made to warn the public. Such public dissemination involves a
complex mix of systems, business processes and
technologies, with alerts ultimately reaching the public
through last mile distributors (LMDs). The study focused on
how dissemination is affected by the size of the alert
information, and some low bandwidth and latency issues that
require attention. Related constraint and best practice issues
were included for future study and consideration.
As noted above, PS requested CSS conduct the study.
Fortunately, CSS had a number of the world’s leading CAP
experts under contract at the time, including Elysa Jones,
chair of the OASIS Emergency Management Technical
Committee that oversees CAP. She was named the project
lead, and received support from experts and stakeholders
(identified below), including Eliot Christian, recently retired of
the World Meteorological Organization (WMO), where he
hosted worldwide CAP Implementation Workshops.
The study team was charged to collect information from
stakeholders on the alerting implications of file size limits.
Based on this information, and on their expert judgement and
knowledge of business processes and technology (including
hardware, software, and reformatting capacities), inferences
July 28, 2017
would be drawn and recommendations were to be provided.
These were to consider the impact of various file size limits on
alert originators and alert receivers/distributors, and on the
quality and type of alerting content.
An Interview Form including background information on the
issue of CAP file size constraints was developed and emailed
to over 100 experts and stakeholders (copy of that form is an
Attachment here). Most of the 37 respondents were then
interviewed via telephone. A summary of the compiled
responses was used as the basis for this TAN.
The following organizations responded to the Interview Form:
Alberta
Emergency
Management
Agency,
Anguilla
Department of Disaster Management, CAPAN, CSS MultiAgency Situational Awareness System (MASAS), Cellcast UK
Limited, ComLabs, Earth Networks, Emergency Management
British Columbia, Environment Canada, EUMETSAT, German
Weather Service, Google, Intelligence for Environment &
Security, International Telecommunication Union, MITRE, My
State USA, Nordic Geospatial, the OASIS Emergency
Management Technical Committee, Pelmorex Media
Incorporated, Sage Alerting Systems, Saskatchewan
Emergency Management Organization, Swan Island
Networks, TFT Incorporated, UK MetOffice, US Geological
Survey, US Integrated Public Alert and Warning System, US
National Weather Service, Washington State, Videotron, and
the World Meteorological Organization. Three independent
experts also responded to the Interview Form.
General Observations
The Role of CAP - Increasingly, public alert information is
being represented in CAP, which standardizes the format of
alert information. Use of the CAP format simplifies automated
routing and enables other processing of alert information. For
instance, a CAP alert typically includes coded information
about: the type of an event; the urgency, severity, and
certainty; the affected area; and the onset time and duration.
These coded values are useful for automated decisions on
whether and where to distribute the alert. However, CAP is
not yet a commonly supported format among consumer
devices such as phones, radios, and television sets.
Accordingly, a last mile distributor receiving alert information
in CAP format would typically convert it for presentation to the
public. For example, a television station's CAP equipment
may be setup to insert "crawl text" that is seen by its viewers;
a radio station would need to convert text to audio (if not
already included as attachment) so as to broadcast audio to
get the message out to its listeners; a cellular phone service
may choose to send a short text message to its users; other
distributors turn the alert information into pager messages, email notes, or Fax messages; and still others may process the
alert information to trigger sirens.
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
Interactive and Non-Interactive Media - A fundamental
distinction between two types of media is necessary when
considering file size constraints in the distribution of public
alert messages. With "interactive media", message recipients
are able to access referenced information sources external to
the message. With "non-interactive media", message
recipients have very limited or no ability to access referenced
information sources that are external to the message.
Traditional radio, television, and Fax transmissions are typical
of non-interactive media, while e-mail and Internet
transmissions are typical of interactive media.
Audio for Non-interactive Media - The provision of audio
alert messages over non-interactive media entails particular
challenges for distributors because audio is vastly larger than
its corresponding text. An EAS audio alert message cannot
be longer than two minutes, and this long-standing constraint
is built into the existing hardware as well as relevant
standards. This audio alert message must be of a quality to
assure intelligibility. Even with compression, such audio files
can be megabytes in size, which is likely the largest files a
typical alert distributor needs to handle. Accordingly, audio
files ought to be transmitted only to those distributors who
must have them. Also, when alerts are in multiple languages
the audio files should be packaged so that distributors get
only those audio files they actually need to broadcast.
Several Factors Determine Size - In addition to the
packaging of multiple languages in a single alert message,
the message file size can be affected by other factors. For
instance, geographic coordinates can add to the size. Also,
packaging multiple warning areas into a single message
would multiply the alert message size. This is a key file size
constraint for complex multi-area weather alerts for example.
Effects of Size Vary by Distributor - Last mile distributors
can have very different characteristics with regard to the
telecommunications resources available and the variety of
communications paths (depending on infrastructure) that are
likely to reach the local populace. Remote areas are typically
underserved in these respects, as are areas that may be
economically challenged.
Other Types of Constraints - Although this TAN focuses on
the size of alert messages, other types of constraints come
into play as well. For instance, there may be policy constraints
on linking to particular external sites or "streaming" resources.
There may be practical constraints that no unusual formats
are used and that the processing time of any single alert be
seconds or less. Some systems may have constraints as to
the versions of standards supported, and may also constrain
certain alert message elements (e.g., number of polygons,
polygon points, geographic codes, "info blocks", linked
resources). Another practical constraint may be that certain
distributors are not equipped or staffed to deal with unusual
methods of distributing messages.
EAS Crawl Text Constraint - SCTE 18, the Emergency Alert
Messaging standard [2], is published by the Society of Cable
Telecommunications Engineers (SCTE). This standard, and
SCTE DVS-168 for TCIP/IP implementations, defines how
cable TV systems signal emergencies to digital receiving
devices such as digital Set-top Boxes, digital TV receivers
and digital video recorders. In accord with SCTE 18, the
Emergency Alert System (EAS) "crawl text" for public alert
messages should not exceed 1800 characters (~2 KB). Within
this limit must be accounted any delay of the message display
and having the message in multiple languages.
Cellular Mobile Alerting Constraint - A Cellular Mobile Alert
Message (a term used in the U.S. EAS context) is limited to
90 characters due to current, second generation technology
constraints. However, third and fourth generation mobile
multicast technology will be able to send multi-media
(including video) and will leverage IPv6 capabilities so this
restriction may change in the future.
File Size Findings and Recommendations
The following table summarizes various size constraints
reported by study respondents.
Respondent
Alberta
Anguilla
Bell
CellCast
ComLabs
EUMETSAT
(guidance)
EUMETSAT
(limit)
Italy
ITU H.323
standard
MASAS
MITRE
Nordic
Geospatial
Pelmorex
NAADS
Rogers
Sage
Alerting
Systems
UK
MetOffice
US, FEMA,
IPAWS
WMO GTS
(guidance)
WMO GTS
(limit)
Size Constraint
6 MB
500 KB
2 MB
90 characters
2 MB
100 KB
Notes
NTE two minutes at 50
KB per second
embedded audio
cell broadcast
telecom link constraint
two minutes transmit
time
100 MB
100 KB
63 KB
10 MB
2 MB
1 MB
5 MB
200 KB text
800 KB audio
2 minutes /
1800 characters
1 MB
not defined
15 KB
500 KB
fire fighters
multimedia over IP
can be easily increased
testing guidance
cost of satellite uplink
time
was one MB (800 KB
attachments and
200 KB otherwise)
interface of television
Set-top Box
audio limit /
"crawl text" limit
practical constraints of
e-mail attachments
90 characters per
Cellular Mobile Alert
Message
100 polygon points per
CMAS
transmitting warnings
over slow telecom
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
a. File Size Effects
a. 1. Finding - Size Impacts Delivery - Strict restrictions on
file size could impede the objective to properly inform, given
that many service providers would reject outright any public
alert message that is oversize. Some involved in alert delivery
are concerned that larger file sizes for public alert messages
could impact the prompt delivery of alerts. A specific assertion
is that they could not provide efficient or effective service if
alerts were to contain text in excess of 1800 characters
(~2 KB) or audio in excess of two minutes.
a. 2. Finding - File Size and WMO GTS - Some connections
within the widely-used WMO Global Telecommunication
System (GTS) operate at only 16 Kbps, which implies that
about 200 KB could be sent in two minutes. However, GTS
regulations impose a limit of 15 KB. GTS regulations are legal
requirements as part of the WMO Technical Regulations, a
treaty-level international agreement among the 183 Member
nations of the WMO. This means that only warnings up to 15
KB can be exchanged between the WMO GTS and Canadian
alerting systems.
a. 3. Finding - File Size and H.323 - ITU-T Recommendation
H.323, Packet-based Multimedia Communications Systems,
is a multimedia conferencing protocol for voice, video, and
data
conferencing
over
packet-switched
networks
("multimedia over IP"). With H.323, users can work side by
side on a document using voice, video, text, and application
sharing technologies. CAP messages up to about 63K can be
carried inside of an H.323 message. However, actually
deployed H.323 routing elements such as Gatekeepers may
further limit the size of messages.
a. 4. Finding - File Size and SIP - Session Initiation Protocol
(SIP), defined by IETF RFC 3261, can be used for voice,
video, instant messaging, gaming, etc. SIP is an applicationlayer control protocol for creating, modifying and terminating
sessions with one or more participants within a
telecommunications network. SIP requests can carry CAP
content, but only if it is smaller than 256 KB.
a. 5. Finding - File Size and XMPP - There is practically no
limit to the size of CAP messages in eXtensible Markup
Language (XML) accessible to instant messaging users via
the Extensible Messaging and Presence Protocol (XMPP).
XMPP is an open technology for real-time applications
including instant messaging, presence, multi-party chat, voice
and video calls, collaboration, lightweight middleware, content
syndication, and generalized routing of XML data.
a. 6. Finding - Upload Constraints - The bandwidth
available for uploading of alert messages intended for public
distribution can impose a file size constraint, given that the
sending process cannot be prolonged. For instance, to upload
a CAP alert via a common satellite uplink in two minutes
implies that the message not exceed 100 KB.
a. 7. Finding - Downstream Constraints - Small messages
(perhaps up to a few KB) are often necessary in systems that
disseminate alerts to many thousands of users. In a typical
design, clients poll alerting servers for alerts and deliver a
small header message giving just the essential information,
with subsequent download of the full message available when
called upon. This aligns with cellular Short Message Service,
iPhone, Blackberry, and other distribution networks
emphasizing small message sizes.
a. 8. Finding - File Size and Polygon Points - The number
of polygon points in an alert message can greatly impact the
file size constraint. The US Commercial Mobile Alert System
(CMAS) imposes a limitation of 100 polygon points. It is well
understood that this is an issue in Canada and efforts are
underway to reduce CAP Canadian Profile (CAP-CP) location
reference polygon sizes. It is also understood that a single
polygon for a CAP alert info block representing an area of
multiple polygons could also be used to reduce the file size.
a. 9. Recommendation - Warn Originator of Oversize
Message - The originator of an alert should be advised if the
intended distribution has a constraint on the message size,
especially so that a life-critical message would not be blocked
or truncated for exceeding the size constraint. This warning
could be part of a form fill-in or similar process that accepts
alert messages from an originator.
b. Multiple Languages
b. 1. Finding - Multiple Language Constraints - Having
alert messages in multiple languages is a legal requirement in
some places. This further constrains the alerting methods and
file size. For instance, some current EAS technology only
looks at the first "info block" of a CAP message, although a
second info block might have English/French alternate
language text.
b. 2. Recommendation - Guidance for Multiple Languages
- When implementing CAP-CP support for multiple languages,
distribution should be configured so that end points receive
only the one or two languages they need.
c. Audio Length and Quality
c. 1. Finding - Audio File Size and Quality - For some
transmitters, the transmit time forces a practical constraint on
the size of audio files. This is in tension with policy objectives
such as prompt delivery to those who need to take action and
assurance that the audio is of adequate quality to be
intelligible. One stakeholder asserted that two minutes of
audio at radio and television broadcast quality cannot be
much smaller than 1.5 MB. Optimizing the size of an audio file
is complicated as it depends on recording parameters and
format. The size of a two minute audio file could range from
100 KB to 20 MB, where the smallest sizes use "speech
encoding", an audio data compression technique for speech
quality audio (as distinct from music quality audio). It is noted
that current EAS systems will only accept industry-standard
formats such as WAV and MP3, and methods to compress
files must be easily employed by non-technical persons.
c. 2. Finding - Text-to-Speech - Alerting equipment and
software should be able to generate a quality audio message
by picking out relevant text in the CAP alert using text-tospeech processing. However, because different text-tospeech processors produce audio of uneven quality, the US
national EAS employs text-to-speech at message origination
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
rather than closer to the last mile. Once the text-to-speech
quality issues are solved, text-to-speech will be a very
important technique to minimize the sizes of alert messages.
c. 3. Recommendation - Guidance for Audio Quality and
Length - In accord with common practice and technology,
audio for public alert messages should be at least voice
quality for broadcast and should not exceed two minutes,
including the tone advice of the message. Technical guidance
should be developed on the size of such an audio file, as
determined by optimal recording parameters and format.
d. Disclosure of Constraints
d. 1. Finding - Constraint Disclosure Necessary - The
rapid pace of technological change and the advantages of
unfettered innovation argue against setting file size limits
except where there is a compelling need. On the other hand,
effective alerting does depend on awareness of major
constraints of alert originators, transmitters, and receivers.
This includes size constraints or time-outs that may be
entailed by email, cellular messaging, particular managed
networks, and other last mile distributors. Also,
telecommunications capacity in the alerting area can be
constraining, especially as it may be degraded by outages
and/or increased demand associated with an emergency. For
instance, after a recent earthquake the available lines were
limited to 56 Kbps dial-up.
d. 2. Finding - Delivery Time Constraints - The policy of
Earth Networks, a private sector alerting service, is to deliver
severe weather warnings within one minute, because of their
sometimes life-critical nature. Italian fire fighters also have a
strict rule that CAP alerts must be delivered within one
minute. On the WMO GTS, warnings must be delivered within
two minutes to GTS receivers anywhere in the world. [3]
d. 3. Finding - Adherence to Guidance - Size guidance is
often regarded as a best practice among voluntary
co-operators, with only routine monitoring that flags recurrent
instances of oversize messages. Cost can enforce a file size
constraints in a pragmatic sense, as when the expense of
satellite uplink time is such that files rarely exceed one MB.
d. 4. Recommendation - Consider Disclosure Policy Given that the efficient and fair use of utility
telecommunication services can be a factor in the effective
delivery of public alerts, managers of alerting infrastructures
should provide guidance on how the size of a public alert
message might affect its prompt delivery. This disclosure is
necessary for users of the alerting infrastructure to
accommodate the characteristics of the infrastructure,
including its upstream and downstream interfaces.
e. Clarification of Roles
e. 1. Finding - File Size and Television Equipment - Most
EAS implementations follow the SCTE 18 standard.
Equipment conformant with SCTE 18 or SCTE DVS168 may
be unable to handle information other than text and audio up
to a specific size. This is largely due to older Set-top Boxes
which have only eight MB of memory for all services,
including the operating system. Also, certain television Set-
top Boxes and other broadcast equipment limit CAP or nonCAP messages to 1-2 MB to assure that messages are not
truncated by arrival of a following message. One EncoderDecoder provider has a 30-second transmit time constraint, at
which the connection is terminated and the incomplete
message is not broadcast.
e. 2. Finding - Text and Audio Size Constraints of
Television - Due to an interface of television Set-top Boxes,
text (not CAP XML) is limited to 200 KB (exclusive of
attachments) and audio is limited to 800 KB. The US EAS
sets an alert text limit of 1800 characters in the CAP-to-EAS
Implementation Guide, section 3.6: "Constructing Alert Text
from CAP V1.2 IPAWS v1.0 Profile for EAS Activations" [4]
e. 3. Finding - File Size Guidance in Canada - Effective
December 30 2011, NAADS, developed by Pelmorex Media
Incorporated, provided a new Policy/Rule [5]: "There are no
specific restrictions as to the size of Alert Messages and/or
Attachments that the Pelmorex NAAD System is designed to
support. However in recognition that certain Broadcast
Distribution Undertakings such as cable and satellite TV
systems have legacy equipment that may not support large
Alert Message files, the Pelmorex Alerting Governance
Council has adopted the following file size restrictions so as to
enable the broadest possible distribution of its Alert
Messages. 1. The cumulative size of all file Attachments in
any single Alert Message must not exceed 800 Kbytes prior to
conversion to base 64. 2. The size of any single Alert
Message, including all file attachments must not exceed 5
MBytes prior to conversion to base 64. (This study notes: As
the message without attachments would typically be less than
one MB, the limit of attachments together should be four MB.)
e. 4. Recommendation - Clarify Authorities to Modify
Alerts - Responsibilities and procedures should be fully
agreed with regard to unusual contingencies in the
origination, transmission, and reception of public alert
messages. This should include whether a transmitter or
receiver is empowered to compress or otherwise adjust an
oversize alert message, particularly if changes might affect
the authenticity or quality of the message.
e. 5. Recommendation - Agree Optimal Roles in the
Dissemination of Alert Messages - Consensus should be
developed as to which originators, transmitters, and receivers
are able and willing to serve particular roles in the
dissemination of alerts. This consensus should fully address
the roles and responsibilities of last mile distributors,
especially those dealing with non-interactive media.
Other Findings and Recommendations
f. 1. Finding - Externally Referenced Content - Particularly
in the case of interactive media, it is useful to differentiate
between content actually within the message and content
referenced to external sources. This differentiation allows the
size of the message to be kept small while the referenced
files can be much larger (and might even be streaming
products). As one message can have multiple referenced
files, the receiver can then consider the size in choosing
whether to fetch each file. Such referenced files need not
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
travel via the same route as the message itself, and copies
may be available from network caches. These characteristics
enable more intelligent traffic shaping across networks. Also,
when authentication is applied to a message package with
embedded content, it is impossible to reduce the package
size while preserving its authenticity.
f. 2. Recommendation - Embed Essential Information for
Alerts over Non-interactive Media - When public alert
distribution entails any non-interactive media, all information
essential to the intelligibility of the message should be
included along with the message in its concise textual form.
For instance, an ancillary audio file would be essential for a
public alert message distributed via radio broadcast media
without text-to-speech processing.
f. 3. Recommendation - Essential Message in CAP Text Policy should state that the text of the CAP message is to be
regarded as an alert that is complete in its essence. Policy
should also state that the delivery of associated content
(embedded, attached or referenced files) is to be regarded as
optional, except in the case of non-interactive media that
cannot deliver text (e.g., audio over radio).
f. 4. Recommendation - Avoid File Embedding - Except
when it is necessary to embed essential Information for alerts
over non-interactive media, files should be referenced from a
public alert message rather than being embedded in the
message itself. This practice not only serves the efficiency of
distribution, it also avoids having an unnecessary distraction
for a recipient who may need to take immediate action.
f. 5. Recommendation - Leverage File Referencing - It
would be useful to have hosting sites with high levels of
performance, security, and reliability where content
referenced from alert messages could be accessed broadly.
Also, common message content could be pre-staged and
ready for referencing in particular alert messages.
f. 6. Recommendation - File Abstraction - Originators of
public alert messages should be encouraged to provide for
large files an abstract, summary, or "thumbnail" version
initially, with a corresponding link in the same or a follow-on
message pointing to the full version of the file.
f. 7. Recommendation - Compression and Encoding Originators of public alert messages and others involved in
alerting infrastructures should be provided with official
technical guidance concerning how best to compress files,
particularly audio. Technical guidance would also be useful
concerning how to mitigate the overhead of default encoding
methods (e.g., base64) and Web services (e.g., SOAP).
f. 7. Recommendation - CAP Feeds - The total message
size should be added as metadata to CAP feeds in order to
help users make judgements about which CAP alert
messages and associated files to retrieve.
Summary and Conclusion
This study took a broad perspective of potential constraints on
public alerting, including the latest interactive systems as well
as long-standing systems such as television and radio. The
study encompassed a broad range of telecommunication
speeds, from slow links found in remote or disaster-affected
areas up to high-speed networks capable of streaming video.
Common factors affecting message size were considered,
such as including audio, packaging multiple alerts in one
event message, and providing detailed location information.
Summary/Conclusion: This study found that changing the
file size limitation from one MB to five MB was responsive to
the concerns of some public alerting stakeholders. However,
it concludes there is no file size that could assure alert
messages would be distributable throughout Canada. Even
one MB was too large for certain distributors, as some need
messages to be less than 15 KB. Small alert messages can
be distributed throughout Canada, but they can carry only text
and coded values and so would lack the audio that some
distributors need. Larger messages can carry progressively
more information, including bilingual audio, multiple alerts,
and location information. But, the larger a message, the less it
is distributable throughout Canada.
This study also offers specific recommendations to clarify
responsibilities, to share best practices, and to provide
technical guidance, in audio parameters and formats, for
instance. However, there can be no recommendation
concerning one file size that satisfies all constraints. Rather, it
seems necessary to distinguish distribution chains with
varying constraints. With flexible distribution for distinct
chains, public alerting throughout Canada could be achieved.
NOTE: The Centre for Security Science warrants that this
advisory note was prepared in a professional manner
conforming to generally accepted practices for scientific
research and analysis. This advisory note provides technical
advice and therefore is not a statement of endorsement of
Public Safety Canada, Department of National Defence, or
the Government of Canada.
Lead Authors: CAP Expert Consultants under contract to
CSS: Elysa Jones, and Eliot Christian (USGS retired),.
Acknowledgements:
Kirsten Wells and Paul Temple
(Pelmorex), Doug Allport (Under contract to CSS)
Scientific Authorities: J. Pagotto (CSS)
Approval for Release: A. Vallerand (CSS)
References
1 OASIS CAP Standard http://docs.oasis-open.org/
emergency/cap/v1.2/CAP-v1.2-os.pdf
2 SCTE 18 Emergency Alert Messaging http://www.scte.org/
documents/pdf/standards/ANSI_SCTE%2018%202007.pdf
3 Manual on WMO Information System, WMO No. 1060,
http://www.wmo.int/pages/prog/www/WIS/documents/
Manual-on-WIS-en.pdf
4 CAP-to--EAS Implementation Guide http://www.eascap.org/ECIG-CAP-to-EAS_Implementation_Guide-V1-0.pdf
5 Alert Message & Attachment Size Restrictions updated by
Pelmorex NAADS (Feb. 15, 2012), http://alerts.pelmorex.com/
global/php/downloadfiles.php?filelocation=doc&filename=Alert
_Message_Attachment_Size_Restrictions_v1.0.pdf
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
Attachment: Interview Form Used for the Study
Interview Question, supporting the Canada Center for Security Science:
What should be the file size limit, if any, for a public alert message?
From a practical perspective, with facilities and agreements in place currently, managers of alerting infrastructures are seeking
guidance for enacting policies that limit the size of files that can be embedded or otherwise associated with public alert messages
carried over the telecommunications links it manages. That is the objective of this question.
Background
The Canadian National Alert Aggregation and Dissemination System (NAADS) - Pelmorex Governance Council recently met to revisit
a previously established Common Alerting Protocol (CAP) file size limitation that had proven to be too restrictive. The council relaxed
the restriction and committed to a more formal study of the matter.
This study, funded by the Canadian Centre for Security Science, aims to identify any known CAP file size constraints imposed
elsewhere, review the findings, and then make a technical recommendation for CAP file size constraints in February 2012. The scope
of this study is limited to the origination, transmission, and receiving of CAP messages sent to the public across electronic networks.
Public alert messages carried over telecommunications links are often composed of text only. These text files are fairly compact in
size, often averaging less than 100 KB per message. However, an alert message could incorporate one or more embedded or
otherwise associated files, or considerable amounts of geographic information. These associated files have the potential to be much
larger, especially where video, audio, and/or high resolution pictures are being provided. If public alert messages with associated
large files were to average 10 MB in size, they could be problematic in emergencies where telecommunications capacity is highly
constrained (due to degraded capacity and/or increased demand, low bandwidth). [1]
Unfortunately, managers of alerting infrastructures do not have agreement on certain aspects that could be relevant to incorporation
of files in alert messages. For example, many embedded or associated files in public alert messages would be judged as merely
informative whereas other files would be judged as essential to the message. Without an agreed method for distinguishing essential
from non-essential files, all embedded or associated files must be received for the alert message to be considered complete.
Another relevant aspect is seen in alert message formats such as the Common Alerting Protocol (CAP, ITU-T Recommendation
X.1303) that allow for a file to be either embedded within the message itself or to be referenced to an external source though an
Internet Uniform Resource Identifier (URI). Indeed, the mechanisms are flexible in that an intermediary could choose to "dereference"
a URI and so embed that file content into the alert message. This flexibility could be useful for telecommunications management,
particularly where facilities are differentiated between those which carry the actual alert message (e.g., a government-run
"emergency channel") and those which could be used for accessing a file referenced within the alert message (e.g., "public Internet").
Definitions of Terms
In the context of this question, there are three relevant actors with regard to public alert messages being originated, carried, and
received via telecommunications facilities:
originator - An alert message originator has control of the message content with regard to whether the message incorporates
embedded or associated files, the amount of geographic information included, and how much text is used in the alert.
transmitter - An alert message transmitter moves a message between the originator and the receiver, without control over the
choice of embedded or associated files.
receiver - An alert message receiver receives an alert message from the transmitter, and that message is considered complete only
when incorporated files are received.
1 Although not addressed here, there are practical issues involving large alert messages that are purely textual, aside from the matter of embedded
or referenced files. For instance, when alert messages specify an area using a polygon, that polygon specification may have thousands of coordinate
values. The practical issue is stated in the FEMA, IPAWS-OPEN CAP Content Guide (April 2011): "While there is no stated maximum, developers
should be warned that there are practical maximums in the sense of excessive message length and the difficulty in decoding long strings of points."
(see http://www.fema.gov/pdf/emergency/ipaws/ipaws_cap_mg.pdf )
Preliminary analysis of file size constraints for Common
Alerting Protocol (CAP) public alert messages in Canada
Other Notes
1.
Although the question is stated in terms of a file size limit, constraints on delivery time constitute an effective file size limit in
cases of limited telecommunications service. An entire alert message may be discarded if it cannot be transmitted within the
designated time constraint. For instance, if the available telecommunications service is only 256 Kbps, a requirement to transmit
a public alert within two minutes implies that a 2 MB file might not be sent.
2.
The size of an "associated file" will be difficult to quantify in those cases where the associated content is dynamic and/or is itself
composed of multiple files. For instance, many alert messages today include a hyperlink reference to a Web site. A receiver who
follows that hyperlink would typically download a set of many files that together comprise the Web page as it would be fully
rendered in the browser. Accordingly, a limit on the size of associated files should be defined in terms of the fully rendered Web
page rather than merely the size of the initially loaded HTML.
Interview Points
1.
Please note any known technology constraints (hardware, software, telecom services) on file sizes for alert messages. For
example, Web form file upload freeware that limits uploaded files to 10 MB might be incorporated in other software.
Response:
2.
Is there any technical reason to differentiate a size limit between what is contained in the body of a public alert message versus
what is contained in one or more referenced files/attachments?
Response:
3.
Please note any known policy and/or technology complications that can be anticipated in applying a file size constraint. For
instance: a legal requirement to carry a complete alert message might override a technical requirement to conserve bandwidth; a
file size constraint may be exceeded when a sender automatically inserts an extra file to meet a legal requirement to provide
multiple languages or a text-to-speech service.
Response:
4.
Please comment on any known or anticipated techniques that could mitigate the need to limit file sizes of alert messages. This
could include: re-sampling of pictures, video, or audio; auto-summarization of Web page contents, etc.
Response:
5.
Please identify any originators, transmitters, or receivers that already specify file size or transmit time in policy guidance for
public alert messages.
For each one identified:
5.1. What is the file size guidance?
Response:
5.2. What is the transmit time guidance?
Response:
5.3. What mechanism is intended to enforce the guidance?
Response:
5.4. Is the guidance enforced continuously or only under particular circumstances?
Response:
5.5. If CAP is being used, which versions are supported and is a CAP profile in use?
Response:
5.6. If possible, please provide a link to the guidance online, or a point of contact.
Response: