emergency message

Subject: [OASIS Issue Tracker] (EMERGENCY-139) Comments from Frank Bell

From: OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>
To: emergency@lists.oasis-open.org
Date: Fri, 20 Jul 2018 16:27:00 +0000 (UTC)

Elysa Jones created EMERGENCY-139:
-------------------------------------

Summary: Comments from Frank Bell
Key: EMERGENCY-139
URL: https://issues.oasis-open.org/browse/EMERGENCY-139
Project: OASIS Emergency Management TC
Issue Type: Improvement
Components: EDXL-CAP
Environment: CAP Event Terms List
Reporter: Elysa Jones
Assignee: Jacob Westfall

{color:#000000}A revised events list is provided in the CAP Docs at [https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/63468/CAP_Full%20Event%20Terms%20List%20-%20Draft%2001-FB5.xlsx] . {color}

{color:#000000}While some events are duplicates, one may be directly selected while the other may be selected via the major term first then minor term. This lets users and software developers find what method is most appropriate to them in their circumstances. There are three columns added at the right to address multiple details of event usage. The Use notes are after number 365. Numbering assigned in the previous draft is expanded upon, and the format adopted.{color}

{color:#000000}Also 10 languages are added to the English and extended French lists. They are, with the exception of Japanese, languages that are official in more than one country. Checking of the translation has bee made for some as noted on the row at the bottom below arbitrary item 365, Some more are work in progress. Russian and Arabic are not currently begun as there is no-one found yet that is a native speaker that is capable of doing that work and is reasonably trustworthy.{color}

{color:#000000}Any recommendations for improvement are welcome. I SHOULD incorporate them into the translation checking work that is currently ongoing. The translations could be checked more than once, and the count incremented. The latest additions were two terms for Norway Meteorology.{color}

{color:#000000}It is assumed that various countries would regulate which terms are used there, but as their neighbors may use a different language and terms list, the international list would provide translation. Also, the international cooperation capability of TSOs could be adopted in addition to the transmission of such messages. Advanced Emergency Alerting (AEA) is providing a means for receivers to determine whether an alert is selecting theÂ TV receiver by location or other means. If the receiver is not selected, regular program would continue. This capability could be extended to radio broadcast. One goal is to make one definition thatÂ can be implemented in consumer receivers that would be able to process the messages from any nation transmitting the data. Some codes are not expected to be used in CAP, but are included so that they are assigned to something else. A number of terms that are more localized are included. These are often opt-in selection instead of opt-out selection.{color}

{color:#000000}Additional questions asked: Â{color}

{color:#000000}1) Is this a revised CAP Canada Profile that is there? It has no French for example. I assume that ITU would like such terminologies in major languages. I could add the French from the CAP Canada profile I currently have, assuming it is up to date.{color}

{color:#000000}2) A color scheme has been used, but the file contains no apparent explanation of that. This would probably be helpful.{color}

{color:#000000}3) Some rows have dual SAME codes. The SAME codes differ in various ways e.g. a --S is a statement e,g, an "All Clear", or a --A is a Watch or an Advisory. I could add some explanation of these usages.{color}

{color:#000000}4) Alerting using broadcast radio or TV using the current EAS is problematic, but there is now significant digital broadcasting that can make a better implementation. Also automation systems are widely used an the current EAS definition makes no provision for interaction between an EAS Encoder/Decoder as a playout device and the automation. So I have added a default priority scheme for the automation to process the Alert with a timeout before the Encoder/Decoder proceeded to override the program in normal mode. The highest priority is 1 which is immediate override. 9 is lowest, with 0 for local station only usage e.g. School Weather Closing which is not currently handled by EAS in the U.S. In addition, this provides an option for the audience to select their alerting sensitivity level, with 1 being always {color}[active.in|http://active.in/]{color:#000000} consumer receivers.{color}

{color:#000000}5) Some alerts, which may be less life threatening, have been added in my schema that are "Digital Only" and are not Program Override, but are opt-in if the receiver has the capability and the criteria are met. One criterion is the selectivity capability which is not provided for in current "legacy" receivers. This provides for polygon, audienceType and other forms of selectivity.{color}

{color:#000000}6) Experience has shown that there are many special situations with different eveCodes. A significant list of notes is in addition to the Event Codes table.{color}

{color:#000000}7) While ATSC 3.0 has the bandwidth and anticipated receiver processor capability to process CAP messages, and is expected to transmit such messages as appropriate, this is not the case for simpler design of TVs and radios. An 8 bit processor may be all that is available. The data transmission rate may be quite low e.g. 1k b/s on analog HD Radio and 4 k b/s on FM HD Radio. Therefore the reduction of bits is quite important. This means that an improved EAS protocol may be applicable, but CAP is likely to not deliver the message in a timely manner e.g. before a transmission error occurs.{color}

{color:#000000}8) Different eveCodes may be authorized by different categories of originators e.g. EAN being White House, Pentagon or NORAD which is now before Congress. This used to the the MIL code, but in 2002 the FCC dropped the usage of ORG codes. Maybe this gets revisited, and maybe other countries would like to use such a coding capability to check message authorization.{color}

--
This message was sent by Atlassian JIRA
(v7.7.2#77003)