Re: tvapi-ACTION-26: Contact sean and add emergency alert requirements to the spec

Hi Paul,

I still don’t believe we can overload the severityLevel in this way.

The same content is broadcast to all receivers and the transport stream
contains alert events for all regions where the broadcast could be
received. I, living in North Fulton county, Georgia USA and watching the
regional TV channel do not want severe storm warning alerts for the coastal
parts of the state (some 300 miles away) interrupting my viewing.

It looks there might be some differences between our expectations about how
the emergency alert system works. The following is my high-level theory and
hope it would make us on the same page. (Please correct it if I'm wrong.)

* For a given emergency situation, the authority may only broadcast alerts
with different levels to affected regions. So if a hurricane is about to
hit NYC, an alert of hurricane warning may be broadcasted to NYC and its
neighboring areas; whereas another alert with lower threat level, like
watch or information, would be broadcasted to farther and less affected
areas. And for other places where no effect is expected, such as Chicago,
no alert is sent there at all.

* The regional service provider, such as Comcast or Time Warner, may also
help only forward the alerts to the right places because they appear to
have more accurate geographical knowledge about where their service
endpoints are.

* Furthermore, even if it the alert signal really happens to reach the
endpoint not in the target area (assuming the signal carries some info
which can be used to identify the target area), it may be more reasonable
to the underlying platform (TV stack, OS, etc.) to filter out those alerts,
instead of exposing it to web contents and relying on their ability to
gracefully handle it with their own geographical data collected via some
other way.

* Besides, the description is expected to be human readable info, which may
also mention some general region info about this alert. For example, it
might look like "Hurricane XXX will be coming this Thursday and affect the
following areas: YYY county, ZZZ county, ...". So there still seems some
ways not to confuse end users.

Overall, the key point is: as long as the platform fires an event of
emergency alert to the web content, we believe the alert is supposed to be
there. In the case you mentioned, it's less likely a severe storm warning
for areas in 300 miles away would be sent to your place if it's not in the
target area of the alert. (Would a regional alert really consume the
nationwide emergency channel to broadcast?) And if the alert source really
broadcasts them outside the target area, there seems more ways to stop
propagating it in the middle (service provider, platform, etc) before
eventually exposing it to the web content. So in these cases, I'm still not
convinced extra attributes for regional info need to be added to our event.

Thoughts?!

Sean


On Wed, Apr 8, 2015 at 6:42 PM, Paul Higgs <paul.higgs@ericsson.com> wrote:

>  HI Sean
>
>
>
> I still don’t believe we can overload the severityLevel in this way.
>
> The same content is broadcast to all receivers and the transport stream
> contains alert events for all regions where the broadcast could be
> received. I, living in North Fulton county, Georgia USA and watching the
> regional TV channel do not want severe storm warning alerts for the coastal
> parts of the state (some 300 miles away) interrupting my viewing.
>
>
>
> Paul
>
>
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Wednesday, April 08, 2015 5:38 AM
>
> *To:* Paul Higgs
> *Cc:* TV Control API Community Group
> *Subject:* Re: tvapi-ACTION-26: Contact sean and add emergency alert
> requirements to the spec
>
>
>
> Hi Paul,
>
>
>
> I believe regional information is quite important and certainly a
> requirement in the US (there may be different storm warning/alert levels
> for neighboring counties/regions)
>
>
>
> I believe attribute severityLevel can cover this. For alerts sent to
> different regions, they could be in different severity levels even when
> associated with the same event. The idea of this attribute was originated
> from [1], which also touches similar scenarios.
>
>
>
> PH> I don’t think it can. severityLevel could be “test”, “information”,
> “watch”, “warning”, “threat”… while location would be a geographic area.
> Quite often in the US you will see a “Tornado warning” issued for a few
> neighboring counties and “Tornado watch” issued for those neighboring them.
>
>
>
> SL> In this case I believe we may utilize "severity level" and the new
> attribute "type of emergency" we plan to add. "Type" may help identify the
> nature of the emergency like Tornado, Earthquake, etc; and "severity level"
> is used to distinguish the different threat levels across multiple regions.
>
>
>
> Thoughts?!
>
>
>
> Sean
>
>
>
>
>
> On Tue, Apr 7, 2015 at 8:36 PM, Paul Higgs <paul.higgs@ericsson.com>
> wrote:
>
> Hi Sean
>
>
>
> I believe regional information is quite important and certainly a
> requirement in the US (there may be different storm warning/alert levels
> for neighboring counties/regions)
>
>
>
> I believe attribute severityLevel can cover this. For alerts sent to
> different regions, they could be in different severity levels even when
> associated with the same event. The idea of this attribute was originated
> from [1], which also touches similar scenarios.
>
>
>
> PH> I don’t think it can. severityLevel could be “test”, “information”,
> “watch”, “warning”, “threat”… while location would be a geographic area.
> Quite often in the US you will see a “Tornado warning” issued for a few
> neighboring counties and “Tornado watch” issued for those neighboring them.
>
>
>
> Paul
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Tuesday, April 07, 2015 5:56 AM
>
>
> *To:* Paul Higgs
> *Cc:* TV Control API Community Group
> *Subject:* Re: tvapi-ACTION-26: Contact sean and add emergency alert
> requirements to the spec
>
>
>
> Hi Paul,
>
>
>
> I am not sure what to do with the Description if it is provided in an
> event with an application URL. Perhaps that behavior is implementation
> specific?
>
>
>
> Yup, it could be. :)
>
>
>
> I believe regional information is quite important and certainly a
> requirement in the US (there may be different storm warning/alert levels
> for neighboring counties/regions)
>
>
>
> I believe attribute severityLevel can cover this. For alerts sent to
> different regions, they could be in different severity levels even when
> associated with the same event. The idea of this attribute was originated
> from [1], which also touches similar scenarios.
>
>
>
> Thanks,
>
> Sean
>
>
>
> [1]
> http://www.w3.org/community/websignage/wiki/Web-based_Signage_Player_Emergency_Profile#Classification_of_severity_level_for_presentation
>
>
>
>
>
> On Mon, Apr 6, 2015 at 7:44 PM, Paul Higgs <paul.higgs@ericsson.com>
> wrote:
>
> Hi Sean
>
>
>
> On type of emergency – great
>
>
>
> I am not sure what to do with the Description if it is provided in an
> event with an application URL. Perhaps that behavior is implementation
> specific?
>
>
>
> I believe regional information is quite important and certainly a
> requirement in the US (there may be different storm warning/alert levels
> for neighboring counties/regions)
>
>
>
> Paul
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Thursday, April 02, 2015 6:02 AM
> *To:* Paul Higgs
>
>
> *Subject:* Re: tvapi-ACTION-26: Contact sean and add emergency alert
> requirements to the spec
>
>
>
> Hi Paul,
>
>
>
> Thanks for the feedback. Please see the comment inline.
>
>
>
> ·         DOMString? severityLevel – I agree with the “localized
> definition” of this, but don’t we also need some attribute that describes
> the nature of the emergency, i.e. “Earthquake”, “Child Adbuction”
>
> Yeah, we may add this.
>
> ·         DOMString? Description – is this intended to be human readable?
> What is the code that receives this event supposed to do with this
> message/information.
>
> It's intended to be human readable, and may be directly used as the
> displayable message.
>
> ·         Do we need some information on where the alert applies to, or
> do we only expect it to be only delivered in-band or out-of-band to
> affected regions?
>
> So far our emergency alert requirements haven't addressed this. Do we have
> a use case which really needs this? Or we may consider to leave it for now
> and open for enhancement if necessary.
>
> Any thoughts?!
>
> Sean
>
>
>
> On Mon, Mar 30, 2015 at 9:16 PM, Paul Higgs <paul.higgs@ericsson.com>
> wrote:
>
> Hi Sean
>
>
>
> Thanks, the changes you provide are a good start to having a well defined
> “emergency alert” interface, but I think some more details are required.
>
>
>
> ·         DOMString? severityLevel – I agree with the “localized
> definition” of this, but don’t we also need some attribute that describes
> the nature of the emergency, i.e. “Earthquake”, “Child Adbuction”
>
> ·         DOMString? Description – is this intended to be human readable?
> What is the code that receives this event supposed to do with this
> message/information.
>
> ·         Do we need some information on where the alert applies to, or
> do we only expect it to be only delivered in-band or out-of-band to
> affected regions?
>
>
>
> I would suggest that, if possible, people read the ATIS-0800010 “Emergency
> Alert Provisioning Specification” [1] which covers North American
> requirements and ATIS-0800012 “IPTV Emergency Alert Metadata Specification”
> [2] which covers the implementation of those requirements.
>
>
>
> Some other reading would be
>
> [3] EB Docket 04-296, First Report and Order and Further Notice of
> Proposed Rulemaking, Review of the Emergency Alert System, FCC 05-191,
> November 10, 2005.
>
> [4] Code of Federal Regulations (CFR) Title 47 Part 11--Emergency Alert
> System, October 1, 2005.
>
> [5] EB Docket 04-296, Second Report and Order and Further Notice of
> Proposed Rulemaking, Review of the Emergency Alert System, FCC 07-109;
> Released July 12, 2007.
>
> [6] Federal Information Processing Standards Publication 6-4, Counties and
> Equivalent Entities of the United States, Its Possessions, and Associated
> Areas, 31 August 1990, with editorial corrections January 2005.
>
> [7] OASIS Standard CAP-V1.1, Common Alerting Protocol (CAP), October 2005.
> Copyright © OASIS Open 2003. All Rights Reserved. Based in part on prior
> work contributed by the Common Alerting Protocol Working Group, copyright
> 2002-2003 Art Botterell for the Common Alerting Protocol Working Group.
>
> [8] SCTE 18 2013, Emergency Alert Messaging for Cable.
>
>
>
> Paul
>
>
>
> [1] https://www.atis.org/docstore/product.aspx?id=22927
>
> [2] https://www.atis.org/docstore/product.aspx?id=22946
>
> [3] available from the Federal Communications Commission. <
> http://hraunfoss.fcc.gov/edocs_public/ >
>
> [4] available from the Electronic Code of Federal Regulations. <
> http://ecfr.gpoaccess.gov/ >
>
> [5] available from the Electronic Code of Federal Regulations. <
> http://ecfr.gpoaccess.gov/ >
>
> [6] available from the Information Technology Laboratory. <
> http://www.itl.nist.gov/fipspubs/fip6-4.htm >
>
> [7] available from the Organization for the Advancement of Structured
> Information Standards (OASIS). < http://www.oasis-open.org/ >
>
> [8] available from the Society for Cable Telecommunications Engineers
> (SCTE). < http://www.scte.org/FileDownload.aspx?A=3512 >
>
>
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Friday, March 27, 2015 6:09 AM
> *To:* Paul Higgs
> *Cc:* TV Control API Community Group
>
>
> *Subject:* Re: tvapi-ACTION-26: Contact sean and add emergency alert
> requirements to the spec
>
>
>
> Hi,
>
>
>
> I've reflected the adjustments to our spec [1] for now. Please feel free
> to share concerns if you find something uncovered.
>
>
>
> Thanks,
>
> Sean
>
>
>
> [1] http://w3c.github.io/tvapi/spec/#tvemergencyalertedevent-interface
>
>
>
>
>
> On Wed, Mar 11, 2015 at 5:39 PM, Sean Lin <selin@mozilla.com> wrote:
>
> Hi Paul,
>
>
>
> Thanks for the feedback. I'm thinking to adjust the event as below.
>
>
>
> 1.       What event/parameters do we signal to inform that the emergency
> announcement is over?
>
> It appears the attribute 'severityLevel' could be nullable. So it implies
> the emergency is over when the attribute is null.
>
>
>
> 2.       The event only signals a channel could be switched to, however,
> it could also be possible that the alert information is available at a URL
> (textual “storm warning” etc). The requirements for all national bodies
> should be investigated to ensure global applicability of this API.
>
> We may add an extra nullable attribute 'url' for now to provide this
> flexibility. Yet as you mentioned, we'll need to ensure global
> applicability someday.
>
>
>
> Thoughts?!
>
>
>
> Sean
>
>
>
>
>
> On Tue, Mar 3, 2015 at 8:46 PM, Paul Higgs <paul.higgs@ericsson.com>
> wrote:
>
> Hi Sean
>
>
>
> This event based approach for signaling of an emergency probably the right
> direction to proceed, just a couple of items to consider
>
> 1.       What event/parameters do we signal to inform that the emergency
> announcement is over?
>
> 2.       The event only signals a channel could be switched to, however,
> it could also be possible that the alert information is available at a URL
> (textual “storm warning” etc). The requirements for all national bodies
> should be investigated to ensure global applicability of this API.
>
>
>
>
>
> Paul
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Thursday, February 26, 2015 3:27 AM
> *To:* TV Control API Community Group
> *Subject:* Re: tvapi-ACTION-26: Contact sean and add emergency alert
> requirements to the spec
>
>
>
> Hi all,
>
>
>
> I slightly revised the spec and added emergency alert to it. Please feel
> free to share any comments on it.
>
>
>
> Thanks and best regards,
>
> Sean
>
>
>
>
>
> On Tue, Feb 17, 2015 at 10:47 PM, TV Control API Community Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
>
> tvapi-ACTION-26: Contact sean and add emergency alert requirements to the
> spec
>
> http://www.w3.org/community/tvapi/track/actions/26
>
> Assigned to: Bin Hu
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>
>
>
>
>
> --
>
> Sean Lin
>
> Mozilla Taiwan
>
> selin@mozilla.com
>
>
>



-- 
Sean Lin
Mozilla Taiwan
selin@mozilla.com