- From: Çö¿í <whyun@etri.re.kr>
- Date: Mon, 6 Jan 2014 14:45:23 +0000
- To: "franck.dupin@innes.fr" <franck.dupin@innes.fr>
- CC: ±è¼ºÇý <shkim@etri.re.kr>, "<public-websignage@w3.org>" <public-websignage@w3.org>, Çã¹Ì¿µ <myhuh@etri.re.kr>, °½Å°¢ <sgkang@etri.re.kr>
- Message-ID: <33CA4FE5-CB42-407E-B191-DACCD097A491@etri.re.kr>
Thank you for your contribution. I¡¯ve added inline comments. :D 2014. 1. 6., ¿ÀÀü 5:42, Franck Dupin <franck.dupin@innes.fr<mailto:franck.dupin@innes.fr>> ÀÛ¼º: Hello and Happy New Year ! Happy new year~! 1/ ¡°Common Alerting Protocol¡± (part of the EDXL - Emergency Data Exchange Language and ITU X1303) seem a good choice for this subject, no ? The most common standard for sharing alerts is the Common Alert Protocol (CAP), which many agencies and countries have adopted. The Common Alerting Protocol (CAP) is a digital format for exchanging emergency alerts that allows a consistent alert message to be disseminated simultaneously over many different communications systems. FEMA worked with the Organization for the Advancement of Structured Information Standards (OASIS) to develop a standardized international technical data profile that defines a specific way of using the standard for the purposes of the Integrated Public Alert and Warning System (IPAWS). Benefits of CAP As more systems are built or upgraded to CAP, a single alert can trigger a wide variety of public warning systems, increasing the likelihood that intended recipients receive the alert by one or more communication pathways. CAP provides the capability to include rich content, such as photographs, maps, streaming video and more as well as the ability to geographically-target alerts to a defined warning area, limited only by the capacity of the delivery system used. Thank you for your information. Yes, right. The CAP is already widely deployed and adapted in many countries, and we are also considering using CAP for delivering emergency information for our implementation as well. BTW, Since the CAP already covers wide range of emergency information and widely used, we don¡¯t aiming at reinvent CAP-like something. So, we just want to focus on making presentation profile for emergency information using web technologies rather than redefining emergency state. As the name implies, this is a profile for player. :D Guidance and Technical Documents * OASIS CAP 1.2 Standard<http://www.fema.gov/redirect?url=http%3A%2F%2Fdocs.oasis-open.org%2Femergency%2Fcap%2Fv1.2%2FCAP-v1.2-os.pdf> * OASIS CAP v1.2 IPAWS Profile Version 1.0<http://www.fema.gov/redirect?url=http%3A%2F%2Fdocs.oasis-open.org%2Femergency%2Fcap%2Fv1.2%2Fipaws-profile%2Fv1.0%2Fcap-v1.2-ipaws-profile-v1.0.pdf> * CAP-EP: EUMETSAT's profile on the Common Alerting Protocol (P<http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&ved=0CEYQFjADOAo&url=http%3A%2F%2Fwww.eumetsat.int%2Fwebsite%2Fwcm%2Fidc%2Fidcplg%3FIdcService%3DGET_FILE%26dDocName%3DPDF_common_alerting_protocol%26RevisionSelectionMethod%3DLatestReleased%26Rendition%3DWeb&ei=Pi_JUvn2EPLK0AXZ2YHwDQ&usg=AFQjCNHwg-CFsJKGhR40Z-xkqXW9WRURoQ&bvm=bv.58187178,d.d2k> * Common Alerting Protocol Profile Requirements (PDF<http://www.fema.gov/redirect?url=http%3A%2F%2Fpreview.fema.net%2Fpdf%2Femergency%2Fipaws%2Foasis.pdf> 698KB, TXT<http://www.fema.gov/redirect?url=http%3A%2F%2Fpreview.fema.net%2Ftxt%2Femergency%2Fipaws%2Foasis.txt> 79KB) * Question 22/2 - Guidelines on the Common Alerting Protocol ... - I<http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CH4QFjAJ&url=http%3A%2F%2Fwww.itu.int%2Fdms_pub%2Fitu-d%2Fopb%2Fstg%2FD-STG-SG02.22-2010-PDF-E.pdf&ei=PivJUr7cK6ep0AX07oGoAQ&usg=AFQjCNFczjBUu-wOrLJYuPh6RUcXZIFEAw&bvm=bv.58187178,d.d2k&cad=rja> * SIP http://tools.ietf.org/search/draft-rosen-sipping-cap-00 * Air Quality feeds : http://feeds.enviroflash.info/ * Google Alert Hub : http://alert-hub.appspot.com/ * EDXL : https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency ¡¦. The IPAWS Open Platform for Emergency Networks (OPEN) is a set of securely hosted Web services that enable the routing of standards-compliant emergency messages between disparate third-party applications, systems, networks and devices. Since the initial version of OPEN (DM-OPEN 1.0) had an established capability to route Common Alerting Protocol (CAP) alerts between organizations and to the public via the National Weather Service¡¯s (NWS) All-Hazards Emergency Message Collection System (HazCollect), OPEN was selected by FEMA to perform message aggregation for IPAWS. It¡¯s quite useful information, and should be studied in this BG. Thank you for your information again!! But, I¡¯m not sure whether this document should be tightly coupled with CAP or not. I think the CAP is one of candidate(but most strong one :D), but not all of them. I also think that signage player profile should be independent of underlying emergency system, like layering concept. BTW, what you have proposed is quite appropriate for the ¡°Introduction¡± section, if it can be generalized. Can you provide texts that describing generic model for emergency messaging with some figures, if available? As an other option, it can be embedded into subsection of introduction as one of reference model. 2/ Classification of Severity Level for display: NWEM Event Codes Event Code Priority Event (Product) Name AVW 1 Avalanche Warning CDW 1 Civil Danger Warning CEM 1 Civil Emergency Message EQW 1 Earthquake Warning EVI 1 Immediate Evacuation Warning FRW 1 Fire Warning HMW 1 Hazardous Materials Warning LEW 1 Law Enforcement Warning NUW 1 Nuclear Power Plant Warning RHW 1 Radiological Hazard Warning SPW 1 Shelter In Place Warning VOW 1 Volcano Warning AVA 2 Avalanche Watch CAE 2 Child Abduction Emergency LAE 2 Local Area Emergency TOE 2 911 Telephone Outage Emergency ADR 3 Administrative Message/Follow up Statement NIC 3 National Information Center DMO Configurable Practice/Demo Warning NPT Configurable National Periodic Test RMT Configurable Routine Monthly Test RWT Configurable Routine Weekly Test NMN Not Currently Disseminated Network Message Notification http://docs.oasis-open.org/emergency/edxl-cap-logo/v1.0/cnd01/CAP-Logos/ <image004.jpg> The ¡°Classification of severity level for presentation¡± is not defining severity level of emergency but presentation/displaying level of information. In other words, this profile guides how to present emergency information using web technology. For example, (these are just examples, not refined) Level 1 : Lowest priority - ticker box with font size, ratio - Scroll text - repeat pattern ¡¦ Level N : Middle priority - Pop-up in the middle of screen - Blinking - repeat pattern ¡¦ Level X : Highest priority - Immediate display with full screen. - Alarming with maximum sound. BTW, I think it will be useful if we can provide mapping table between presentation level and priority of CAP. This can be a separate document or can be attached at the end of document as an appendix. Anyway, for better understanding, I will put those examples into the draft document with some refining. 3/ Reception of emergency information ¡°We are considering WebSocket or HTTP PUSH for this.¡± Why not but have a look at : XEP-0127: Common Alerting Protocol (CAP) Over XMPP : http://xmpp.org/extensions/xep-0127.html PubSubHubbub: ie http://alert-hub.appspot.com/ for http://www.google.org/crisisresponse/ Yeah, right. If signage terminal is capable of XMPP, it can be used. Even thought this profile is for web-based signage, It will be good if we can provide several candidates. 4/ Some remarks : Beyond the outdoor, digital signage in the company (university, etc..) is something to consider. This leads us to think that in a company, the center of interest is local and outside/public ; The company may indeed be alerted by an earthquakebut also a fire in the ground floor of its building¡¦ Web based Signage Player must be considered at least two sources of information (ie two CAP servers). Thank you for your precious commends. We are not assuming outdoor only. But, I¡¯m not sure that what you have pointed can be handled in this document, since this is a player profile. Regarding what you have suggested, there is an ongoing standardization work in ITU-T Q14/SG16, named H.DS-CASF (Common Alerting Service Framework in digital signage system). This draft recommendation is aiming at providing emergency alerting services for digital signage service/systems. It will provide service framework for providing emergency information by use of data that is managed by signage service providers/terminals and alerting information delivered from authorities. Of course, in the latter case, CAP would be used, i think. Sincerely, Wook Hyun
Received on Monday, 6 January 2014 14:45:58 UTC