Re: Proposal of new requirements for the Web-based signage toward W3C standard

Hi Futomi, Kiyoshi,

Please find my comments inline.

Thx,
Louay
On 02 Feb 2016, at 07:37, Futomi Hatano <futomi.hatano@newphoria.co.jp<mailto:futomi.hatano@newphoria.co.jp>> wrote:

On Tue, 2 Feb 2016 14:48:19 +0900
Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp<mailto:tanaka.kiyoshi@lab.ntt.co.jp>> wrote:

Dear Louay, Christian,

Thank you for your check and comment!
I'll check your revisions and reflect them in the draft charter.

Another question from our side which is not mentioned in the document is
about protocols: Do you think we need a signalling or control protocol
(can be on top of existing communication protocols like WS or WebRTC) to
control the User Agent on the digital signage from a Management Backend.

I guess there are some implementations using WebSocket.
However, the protocol on the WS is assumed different on each system.
So, I think it would be a good point to be discussed in the WG.
# How do you think? > BG Members

+1
For now, JS Players are very much tied to CMS.
If the protocol (to be precise, it's data format) is standardized,
JS Players can be developped independently.

JSON-RPC can be a major candidate, though I don't support it strongly.
We need only define vocabulary.
Exactly this is what I meant. It is good to have a common data format and vocabularies for interaction between Terminal and Management backend. JSON (or JSON-RPC) is a good candidate for data format. Vocabulary needs to be defined on top (Name of events, actions, properties, values, etc.). I think also lifecycle is important to discuss.

Futomi


---
Followings are my replies for your comments picked up from the draft.

I've tried to make the roles clearer and more consistent thoughout
the document. Originally there were users, owners and operators, with
users being application users as well as users near the controlled
device. So I reduced that to operators and viewers for simplicity and
clarity.

Thank you for your clarification! It sounds good by simplifying.
Moreover, it might be better to change "viewer" to "audience".

Shutting down the OS or turning off the device opens up a whole can
of worms regarding how to get the device started again. We better
just assume that we will just reboort things and that they will be
running again automatically a bit later.

Good clarification for the power management function!

After shutting down, the system could boot up with the other trigger,
e.g. timer, WoL (which needs another device :-). These are only examples
of the system configuration. Since we must meet the requirement
for maintenance, the items to be defined are expected to be discussed
in the WG.

I'm not sure about the information flow here and whether the device
should get the time or an external function should set it. I think it
more likely that it will be set by an external application. But both
cases would make sense. (After a reboot, the signage device will know
that it might need to get the current time, so a 'get' would be
useful. But in other cases, for example for daylight saving time, it
makes more sense for an external device to set the time instead of
the signage device repeatedly checking the time.)

Boot-up time and time-shifting time are typical good examples.

The original idea of clock management function is for getting
a precise time.
As you know, most systems can adjust their clock using NTP
or the other mechanism. However, the interval of adjustment
depends on OS. I heard that as some OS could perform it once a day,
time of such OS is likely to slip largely.
So, it will be useful if there is a function which enables to get
a precise time even in such a situation.

Remote Prompting

This can probably already be covered by APIs from other WGs, but it
should at least be mentioned here as one of the things that the WG
needs to specify (at least by reference) to cover the needs of the
operator, mentioned in one of the earlier bullet points.

It might be an interesting idea.
Could you tell me whether it has been discussed in the other group
such as WebScreen, if you know?

In the signage case, when the signage server provides its contents,
there is no operator, because a setting is done prior.
So, if the prompt is shown on the remote console,
there might be nobody to operate.
Thus, this function is not enough for the signage case and it should
be considered including a no prompt case.

Could you contribute more for this function?
From my point of view, I don’t think that these prompting functions are needed. The idea of Christian is to address these functions in the spec to make clear what happens when a page uses one of these functions. For example the spec could state that calling these functions will silently fail without showing any dialog. Even if prompting the dialog on other systems (like Operator backend) is possible, technically will raise some issues because all prompting functions are synchronous.

More comments are welcomed!

Thank you in advance!

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
  NTT Service Evolution Laboratories
  mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2016/02/01 21:55, Bassbouss, Louay wrote:
Dear Kiyoshi,

Thank you for making progress on the charter. We (Group of Future
Applications and Media at Fraunhofer FOKUS
<https://www.fokus.fraunhofer.de/fame>) revised the charter and made
comments (see comments of my Colleague Christian Fuhrhop in the Google
document). Please let us know if you have questions.
Another question from our side which is not mentioned in the document is
about protocols: Do you think we need a signalling or control protocol
(can be on top of existing communication protocols like WS or WebRTC) to
control the User Agent on the digital signage from a Management Backend.
Imagine the Operator wants to manage digital signage terminals running
different User Agents using the same management backend. We think that
signalling information exchanged between the different entities need to
be specified somewhere e.g. IETF.
Please let us know if you have additional questions.

Best regards,
| Dipl.-Ing. Louay Bassbouss
| Project Manager
| Future Applications and Media
|
| Fraunhofer Institute for Open Communication Systems
| Kaiserin-Augusta-Allee 31 | 10589 Berlin | Germany
| Phone 49 30 - 3463 - 7275
| louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.fraunhofer.de>
<mailto:louay.bassbouss@fokus.fraunhofer.de>
| www.fokus.fraunhofer.de<http://www.fokus.fraunhofer.de> <http://www.fokus.fraunhofer.de>


On 26 Jan 2016, at 09:53, Kiyoshi Tanaka (田中 清)
<tanaka.kiyoshi@lab.ntt.co.jp<mailto:tanaka.kiyoshi@lab.ntt.co.jp> <mailto:tanaka.kiyoshi@lab.ntt.co.jp>>
wrote:

Dear,

I've continued the chartering work with supporters.

I've discussed with some cooperative people, and revised the charter
draft of the proposed Web-based signage WG.

You can find it with revision marks on http://bit.ly/1kKj0RU (same URL
as we used).

Main revisions include
- Scope added the description of security model treated by this WG
- API name produced by this WG (Remote Management API)
- Deliverables arranged to 3 functions (Power Management, Clock
Management, and Other Contextual Information)
- Dependencies limited to the close WGs

How do you think this draft charter?
I expect your feedback!

I want to go to next step in order to establish the new WG, soon.

You can also find the clean-up version from:
https://docs.google.com/document/d/11DZ4L1ZxFz6JNRWULph09ClwoiMFHiJiXQpG1gn1zTA/edit?usp=sharing


If you need a MS-Word file, please contact me!

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
NTT Service Evolution Laboratories
mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2015/12/18 22:59, Ryoichi "Roy" Kawada wrote:
Hi Kiyoshi,

Yes, we can list CG's as well.
For example, Web & TV IG lists CG's in its charter.
http://www.w3.org/2012/11/webTVIGcharter.html#coordination


Cheers,
Roy
Ryoichi Kawada, KDDI

On 2015/12/18 15:20, Kiyoshi Tanaka (田中 清) wrote:
Kawada-san,

Thank you for your comment.

I want to take care of Multi-device timing CG,
but I'm not sure whether CG may be listed.
Could you check?

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
  NTT Service Evolution Laboratories
  mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2015/12/18 14:02, Ryoichi "Roy" Kawada wrote:
Hi Kiyoshi,

Thank you for drafting the charter.

As for 3.1 Liaisons, how about adding Multi-device Timing CG (we saw
their demo in Sapporo) ?
Or is this section supposed to contain only WG / BG /IG ? If that
is the
case, ignore my proposal above.

Cheers,
Roy
Ryoichi Kawada, KDDI


On 2015/12/17 20:02, Kiyoshi Tanaka (田中 清) wrote:
Dear,

After the TPAC discussion, I revised the charter draft.
You can find it on http://bit.ly/1kKj0RU .

Do we restart a discussion?
Your feedback will be helpful.

Thank you in advance!

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
    NTT Service Evolution Laboratories
    mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2015/10/23 21:38, "Kiyoshi Tanaka (田中 清)" wrote:
Dear,

We'd like to draft a charter before TPAC through this discussion
in order to proceed to establishment of WG in the f2f at TPAC.'

As my colleague Fujimura-san said, we've drafted a charter
document of proposed WG,
so we want to share it. Please find attached!
We want to ask you to review the draft charter in BG F2F.

Moreover, we plan a breakouts session.
You can find the idea in SessionIdeas Wiki.
We'd like to propose standardization ideas,
and we expect to get feedback from a variety of participant
in order to improve the draft.
Please come the session and give us a comment!

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D. @ NTT Service Evolution Laboratories
    mailto:tanaka.kiyoshi@lab.ntt.co.jp




--
株式会社ニューフォリア
取締役 最高技術責任者
羽田野 太巳 （はたの ふとみ）
futomi.hatano@newphoria.co.jp<mailto:futomi.hatano@newphoria.co.jp>
http://www.newphoria.co.jp/