Re: Contribution for "Proposed initial draft of "Architecture and Requirements for Web-based Signage Player - Emergency Information Profile"

Hello everyone

I am Masayuki Ihara, working for NTT research lab in Japan.

I am not sure this discussion is still on-going or not.

My research group has developed and evaluated in a field test
the web-based signage and mobile device collaboration technologies
for disaster situation.

I would like to propose to add one new section and some statements
about requrements obtained from the evaluation test to the draft
of emergency profile at 
http://www.w3.org/community/websignage/wiki/Web-based_Signage_Player_Emergency_Profile 
..

[Section to be added]

Sharing emergency information with users' devices

[Statements to be added]

In disaster situation, the Internet disconnection may cause ineffective 
performance of a networked signage system. One of the solutions to solve 
this problem is device collaboration to share emergency information with 
users' mobile devices. The followings are required functions for the 
collaboration:

- the collaboration between a signage system and a users' mobile devices 
using a local area network that is expected to be still alive under 
disaster situation such as LAN side of access point of public Wi-Fi
- the emergency information upload from an administrative mobile device 
under situation where the content management system via the Internet 
connection is disabled
- the emergency information delivery by a distinction between 
categorized abstract contents for a signage display such as "public 
transportation" or "evacuation center" and detailed contents of each 
category for users' mobile devices



If you have any question, please reply to this email.
Hope you to accept this proposal.

Best regards,
Masayuki

> On Tue, 7 Jan 2014 13:50:36 +0900
> Sangwhan Moon <sangwhan@iki.fi> wrote:
>
>> Putting aside the question of "who is this document for"... (e.g. is it for UA implementors, web developers, or a document for the sake of having a document? - I'll send a follow up mail on this, the draft mail I wrote needs some serious diplomatic sandpaper)
>
> It's an important question.
> We haven't discussed that point.
> I look forward your follow up mail!
>
>
>> On Tuesday, January 7, 2014 at 12:35 PM, Futomi Hatano wrote:
>>>>> 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>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.
>>>
>>>
>>>
>>> Currently, the popular browsers support only HTTP/HTTPS (XHR/Server-Sent Events)
>>> and WebSocket protocol.
>>> If we use XMPP, we have to use it on HTTP/HTTPS or WebSocket.
>>> That is, CAP over XMPP over WebSocket, for example.
>>> In fact, WebRTC adopt this approach for signaling.
>>>
>>> If we provide XMPP or PubSubHubbub in the doc,
>>> we should mention the difference of the communication layers.
>>
>> Although there is no standard defining a XMPP API within a browser context - there is [1] this which can be used to build a polyfill of some sort. I'm not entirely convinced about XMPP, since the fault tolerance in disaster scenarios is quite likely very low without support for something like XEP-0174. (Sadly, I have seen one implementation of XEP-0174 - not the most widely adapted standard…)
>>
>> (Additionally, XMPP is a pretty heavy protocol - but that's my subjective point of view)
>>
>> One thing I would like to note is that there have been a lot of discussion about emergency announcements from a TV / digital billboard which IMHO is missing one very important point - transport under infrastructure instability.
>>
>> Most of the proposals I've seen in the last couple years have been dismissing this little point, assuming the network (or a central server) is available - which is probably not always the case.
>
> Right.
> That's because telecommunication is not tolerant to disasters
> regardless of whether it's wired or wireless (WiFi, 3G, LTE, etc.).
> We should not assume telecommunication can cover all disaster situations.
> Telecommunication is completely helpless especially at devastated areas after a disaster.
> But telecommunication is available until just before a disaster even at devastated areas.
> Besides it can provide area-specific information, unlike broadcasting such as TV and radio.
> So it's helpful for disaster prevention or damage limitation.
>
> Diversity of the ways to provide emergency information is important .
> Telecommunication is just one of them.
> So I think we may assume the network is available when we discuss the Emergency Information Profile.
>
>
>> One idea would be to use a mixture of NSD and WebRTC's RTCDataChannel to make a serverless peer to peer network - which could be a bit more fault tolerant, but until it's prototyped and proven to work I wouldn't really put people's life at stake on this approach.
>
> I don't know NSD. What is it?
> I'm not sure a serverless P2P network is helplul at a disaster situation,
> because the fact remains that it is telecommunication.
> I think P2P is helpful for smartphones rather than signs.
>
>> I've been personally experimenting with a old school FM transmitter/Web Audio/FSK modulation for fun as a "networkless one way browser to browser data transmission mechanism" feasibility experiment (even when everything fails - analog radio still works!), but this obviously needs bigger forces to sign off to be of any use. (Think of [2] this, but with higher complexity)
>>
>> Sangwhan
>>
>> [1] http://strophe.im/strophejs/
>> [2] http://www.youtube.com/watch?v=w6lRq5spQmc
>
> Interesting. [2]
> It's possibly useful for sending information in a personal device to a sign.
>
> Cheers,
> Futomi
>
> --
> Newphoria Corporation
> Chief Technology Officer
> Futomi Hatano
> --
> futomi.hatano@newphoria.co.jp
> http://www.newphoria.co.jp/
>
>
>

-- 
Masayuki IHARA
Service Harmonization Project,
NTT Service Evolution Laboratories
1-1, Hikarinooka, Yokosuka, Kanagawa 2390847, Japan
phone: +81 46 859 5018, fax: +81 46 859 5560
email: ihara.masayuki@lab.ntt.co.jp or ihara@acm.org

Received on Monday, 19 May 2014 03:46:07 UTC