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

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<mailto: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<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<mailto: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<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<mailto: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<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<mailto: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<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<mailto: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<mailto: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<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<mailto: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<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>




--
Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>

Received on Thursday, 9 April 2015 10:35:35 UTC