Re: How to proceed? (Re: BG conference call (Re: TPAC2017))

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 Thursday, 7 December 2017 01:38:31 UTC