sponsor - oasis€¦ · web viewas noted above, ps requested css conduct the study. fortunately,...

Technical Advisory Note

Preliminary analysis of file size constraints for Common Alerting Protocol (CAP) public alert messages in CanadaPublic Safety Canada, Centre for Security Sciences (CSS)Emergency Management Systems and Interoperability May 10, 2023Objective and SourceIn 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 ParticipantsOn 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 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 Multi-Agency 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 ObservationsThe 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, e-mail notes, or Fax messages; and still others may process the alert information to trigger sirens.

Interactive and Non-Interactive Media - A fundamental distinction between two types of media is necessary when

Preliminary analysis of file size constraints for Common Alerting Protocol (CAP) public alert messages in Canada

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 RecommendationsThe following table summarizes various size constraints reported by study respondents.

Respondent Size Constraint Notes

Alberta 6 MB NTE two minutes at 50 KB per second

Anguilla 500 KBBell 2 MB embedded audioCellCast 90 characters cell broadcastComLabs 2 MB telecom link constraintEUMETSAT (guidance)

100 KB two minutes transmit time

EUMETSAT (limit)

100 MB

Italy 100 KB fire fightersITU H.323 standard

63 KB multimedia over IP

MASAS 10 MB can be easily increasedMITRE 2 MB testing guidanceNordic Geospatial

1 MB cost of satellite uplink time

Pelmorex NAADS

5 MB was one MB (800 KB attachments and 200 KB otherwise)

Rogers 200 KB text800 KB audio

interface of television Set-top Box

Sage Alerting Systems

2 minutes /1800 characters

audio limit / "crawl text" limit

UK MetOffice

1 MB practical constraints of e-mail attachments

US, FEMA, IPAWS

not defined 90 characters per Cellular Mobile Alert Message100 polygon points per CMAS

WMO GTS (guidance)

15 KB transmitting warnings over slow telecom

WMO GTS (limit)

500 KB


a. File Size Effectsa. 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 application-layer 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 Languagesb. 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 Qualityc. 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-to-speech processing. However, because different text-to-speech processors produce audio of uneven quality, the US national EAS employs text-to-speech at message origination


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 Constraintsd. 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 Rolese. 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 non-CAP messages to 1-2 MB to assure that messages are not truncated by arrival of a following message. One Encoder-Decoder 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 Recommendationsf. 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


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 ConclusionThis 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)


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.

BackgroundThe 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 TermsIn 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 )


Other Notes1. 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 Points1. 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:

1References OASIS CAP Standard http://docs.oasis-open.org/ emergency/cap/v1.2/CAP-v1.2-os.pdf2 SCTE 18 Emergency Alert Messaging http://www.scte.org/ documents/pdf/standards/ANSI_SCTE%2018%202007.pdf3 Manual on WMO Information System, WMO No. 1060, http://www.wmo.int/pages/prog/www/WIS/documents/ Manual-on-WIS-en.pdf4 CAP-to--EAS Implementation Guide http://www.eas-cap.org/ECIG-CAP-to-EAS_Implementation_Guide-V1-0.pdf5 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

sponsor - oasis€¦ · web viewas noted above, ps requested css conduct the study. fortunately,...

Documents