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

On Mon, 2 Jun 2014 08:25:49 +0900
Sangwhan Moon <sangwhan@iki.fi> wrote:

> On Monday, June 2, 2014 at 8:00, Futomi Hatano wrote:
> > On Fri, 30 May 2014 12:20:41 +0900
> > WOOK HYUN <whyun@etri.re.kr (mailto:whyun@etri.re.kr)> wrote:
> > 
> > > The proposed requirements needs to be aligned with "Conformance" section,
> > > if those proposed sentences are for providing requirements.
> > > Hence, I want to propose to modify those requirements as follows;
> > 
> 
> SHOULD is a more common term that is used for the documents that we deal with. 

Certainly.


> > > - The digital signage system is RECOMMENDED to be capable of collaborating
> > > with mobile devices through local area network for exchanging emergency
> > > information, if the local network is still alive.
> > 
> 
> How would the devices connect to the the sign's local network? Normally that is locked
> out from public access on every commercial deployment I have seen so far.

You are right.
Wook and I have the same question too.
I hope Masayuki will share the technical information
of the NTT's field test.
We have to discuss the way to achieve this requirement
technically more.


> And I don't seen the need to restrict it to mobile devices.
> > > - The digital signage system is RECOMMENDED to be capable of uploading of
> > > emergency information from administrative mobile devices, if the connection
> > > with content management system is lost.
> > 
> 
> Ditto for the mobile comment. It's also very likely that the administration console
> is very likely to be a PC of some sort - just to be factually correct, I don't think the
> word "mobile" is needed here.

+1


> > > - The digital signage system is RECOMMENDED to be capable of providing
> > > detailed emergency information to user's devices, and RECOMMENDED to
> > > display a method how to get the information. 
> > 
> 
> "Providing" is pretty vague. Are you implying that the terminal should provide a
> method to digitally copy the information over to a client? That's at least one would
> guess since there is a "user device" in the context - in which case the wording
> of the actions should be made more specific.

Portability of information (digital copy) is useful in disaster situations, I think.
In the situation, most of evacuation centers would be isolated.
Besides they would lost the Internet connections.
But some people would move to other centers.
If they could have digital copies, the information would be
spreaded to many centers.

Though we have to clarify the way to achieve technically,
I agree that this requirement is put into the conformance section
in the doc.

> If so, I think there should be at least one recommended transport method here.

Yes.

> (I don't have any good ideas, NFC is probably one option but the amount of data
> you can transmit over is quite limited, and realistically I don't see people lining up
> to touch their phones on a sign during a emergency situation - but that could be
> just me assuming people don't follow the rules when there is a disaster.)

Yes, many people won't do so.
As I mentioned before, it's OK if a few people can do so.
Though NFC is not sufficient regarding the limitation of size of data,
it is still better than nothing.
Bluetooth is also possibly useful.
For now, I'm not sure which is the best.

Anyway, if we can't find the way, the doc will be finished.
Then the requirement will be dropped eventually.

> While we aren't making a normative document here (although I seriously wish
> we could) making the transport method completely open ended just makes life
> complicated for implementors.

What do you mean "a normative document"?
Legally, BGs can make only group notes. Do you mean this?
If we find lack of APIs, we can make API drafts unofficially.
Then we can propose them to WGs.


Cheers,
Futomi

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Monday, 2 June 2014 00:36:18 UTC