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

Hi Paul,

Alright. If you still insist, we may add the following method to the event.

  sequence<DOMString> getRegions();

But the returned array is not guaranteed to be non-empty because not all
emergency warning systems would expose sufficient geographical info about
the alert to the endpoint.

Sean


On Thu, Apr 9, 2015 at 6:35 PM, Paul Higgs <paul.higgs@ericsson.com> wrote:

>  Hi Sean
>
>
>
> If that is how you expect **all** emergency warning systems to operate,
> then your proposal is appropriate.
>
> I do not, however, believe your high-level theory is correct
>
>
>
> Paul
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Thursday, April 09, 2015 12:16 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 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
>
>
>



-- 
Sean Lin
Mozilla Taiwan
selin@mozilla.com