- From: 田中 清 <tanaka.kiyoshi@lab.ntt.co.jp>
- Date: Wed, 24 Jan 2018 19:12:53 +0900
- To: public-websignage@w3.org
Dear, Sorry for my late reply. I think the most important debatable point is the target browser. We've been considering the browser for the signage, but not limited to. However, the security model will be different from that we think about if the target is even extended to include the general browser. And, the APIs might be not realized as we want. # The service of the digital signage does not allow the confirmation of user (audience). So, I think the target browser could be extend to other than the signage but limited to the machine use. In such case, I want to know whether the W3C standardization allows the target browser except uses by human being. If possible, we could consider the APIs for the browser that is not supposed to be used by human. Does anyone know the policy? The DAS-WG has pointed out that their target is the default browser (same as the general browser?). Best regards, Kiyoshi --- Kiyoshi Tanaka, Ph.D. NTT Service Evolution Laboratories mailto:tanaka.kiyoshi@lab.ntt.co.jp On 2017/12/07 20:12, Kiyoshi Tanaka (田中 清) wrote: > Dear Futomi, Mr. Hyun, > > Thank you for your reply. > I understand your opinion and suggestion, and I want to hear more opinion from the other people. > > I'll conclude after hearing more voices. > > Best regards, > Kiyoshi > --- > Kiyoshi Tanaka, Ph.D. > NTT Service Evolution Laboratories > mailto:tanaka.kiyoshi@lab.ntt.co.jp > > > On 2017/12/07 10:43, 현욱 wrote:> >> Sorry for late response, and thank you for your hard work. >> >> I think it will be enough to limit our specifications to signage-specific browser rather than extending to other embedded system at this time. If we find that the specifications is usable to other embedded system, we can split or reproduce them for general purpose in the future. >> >> Regarding power management issues, >> The requirements of power management of signage devices are somewhat differ from battery status API. We are focusing on controlling of power on/off of the signage terminals and displays, and most of those terminals may not have batteries. Of course, it will be great to cooperate with DAS-WG. As pointed out from DAS-WG, it is needed to make our own mature draft for being reviewed by the experts of DAS-WG. >> >> Thanks. >> >> BR, >> W.Hyun. > > > On 2017/12/07 10:37, Futomi Hatano wrote: >> On Tue, 5 Dec 2017 18:32:13 +0900 >> "Kiyoshi Tanaka (田中 清)" <tanaka.kiyoshi@lab.ntt.co.jp> wrote: >> >>> Dear all members, >>> >>> Though I've tried to fix the slot of the conference call, I've not been able to find the good slot, yet. >>> I want to continue to seek the conference call slot, however, it must be proceeded the discussion. >>> >>> So, I want to start the discussion in this ML. >>> The starting point was the e-mail[1] from DAS-WG replied to my proposal. >>> >>> We should answer to the DAS-WG regarding the following points. >> >> My answers for their questions are as follows: >> >>> 1) Whether APIs are implemented securely within the default browser context. >> >> My understanding is that we are not focusing on the default >> browsers but the web-runtime on embedded devices. >> >>> 2) The draft creation of Power Status Management, compared with the Battery Status API. >> >> The Battery Status API just exposes APIs for getting >> the status of the battery such as battery level, charging >> time, etc. >> >> On the other hand, the Power Status Management exposes >> APIs for changing the power mode. For example, change the >> mode to stand-by. >> >> I think the title of the spec should be changed. >> How about "Power Mode Management"? >> >>> 3) The Context Information's draft (device information) clarified such as on the fingerprinting issue and web-runtime. >> >> The fingerprinting issue is not (does not need to be) >> considered because this API is not for the default browser >> context. >> >>> Before making a response, I want to know your opinion in the next following points. >>> >>> a) Our APIs are limited to the signage or extended to the embedded system including the signage. >> >> I think that we should extend the scope. >> Power Status Management and Device Information can be used >> for other types of embedded devices. >> >> Unfortunately, there are few members who are interested in >> digital signage In W3C. >> Extending the scope to embedded devices might attract other >> W3C members. >> >> Besides, APIs for wide range of devices are more valuable >> than ones limited to digital signage. >> >>> b) The browser that the APIs are implemented is the general browser or the specific browser such as for the signage. >> >> As mentioned above, we should focus on the specific browsers >> (runtimes). >> >>> c) We continue to ask DAS-WG the standardization or not. >> >> I'm wondering if they accept standardizing APIs for specific >> browsers in embedded devices. >> >>> In addition, the architecture and the security model should be considered more. So, let me hear regarding these issues. >> >> Before that, we have to decide whether we focus on the general >> browsers or the specific browsers (embedded devices). >> The security model is completely defferent depends on >> the targeted browsers. >> >> Cheers, >> Futomi >> >> >>> Anyway, please let us know how do you think about these points. >>> Your opinion for even one point is also welcomed. >>> >>> [1] https://lists.w3.org/Archives/Public/public-websignage/2017Oct/0001.html >>> >>> Best regards, >>> Kiyoshi >>> --- >>> Kiyoshi Tanaka, Ph.D. >>> NTT Service Evolution Laboratories >>> mailto: tanaka.kiyoshi@lab.ntt.co.jp
Received on Wednesday, 24 January 2018 10:13:30 UTC