Re: Proposal from Web-based Signage BG

Dear Anssi,

Thank you for your comment on our proposal!
And, I’m sorry not to reply until your conference call time.

We, Web-based Signage BG, must consider your comment before answering your question.
We want to start the discussion regarding your comment.
# Let’s discuss how to proceed our proposed API study > Web-based Signage BG members!

Please wait for a while!

Best Regards,
Kiyoshi


> 2017/10/03 21:52、Kostiainen, Anssi <anssi.kostiainen@intel.com>のメール:
> 
> Hi Tanaka-san, Web-based Signage BG members,
> 
> Thank you for your proposal.
> 
> I'd ask you to kindly provide us further information by responding to a couple of questions that were raised in initial discussions with DAS WG participants.
> 
> First, we observe your charter proposes two normative deliverables [1], and we focus on them, namely:
> 
> Power Status Management
> Contextual Information
> 
> 
> # General comments
> 
> We are not clear whether the proposed APIs are signage-specific. It seems they are not meant to be implemented in a typical user agent, that is a web browser running on a mobile device or desktop.
> 
> The DAS WG Charter [2] states that:
> 
> [[
> 
> APIs that cannot be demonstrated to be implementable securely within the default browser context will not be released.
> 
> ]]
> 
> That suggests the proposed APIs might be out of scope for DAS WG given its current charter.
> 
> 
> # Power Status Management
> 
> There is no input draft for the Power Status Management deliverable. The DAS charter explicitly states [2]:
> 
> [[
> 
> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase.
> 
> ]]
> 
> We would prefer to see incubated drafts for any deliverables considered to be added to the DAS WG Charter.
> 
> We encourage you to review the Battery Status API [3] and evaluate whether it satisfies your requirements with respect to Power Status Management. You could also propose extensions to the said specification if they are not signage-specific, that is address a generic requirement that is not signage-specific. Feel free to open such feature requests directly on the specification's GitHub repo.
> 
> 
> # Contextual Information
> 
> [Comments based on the input draft [4] linked to from the charter proposal.]
> 
> We have a concern that the proposed API exposes a fingerprinting vector (see [5]) and feel the use case [6] would be better addressed using a different mechanism. We would like to hear what are your plans to mitigate the fingerprinting issue.
> 
> We also observe the spec targets a class of devices called "web-runtime" [7] distinct from a web browser. As noted earlier, the DAS WG is scoped to develop APIs implementable in web browsers.
> 
> # Follow-up
> 
> DAS WG will discuss your proposal on its next bi-weekly teleconference 7 October 9am ET / 2pm GMT / 4pm EST (agenda to be sent shortly to public-device-apis). Since the timing of the call may not be friendly for Japan-based participants, I'd suggest we have another call to discuss your proposal based on your preference.
> 
> Thanks,
> 
> -Anssi (Device and Sensors WG Chair)
> 
> [1] https://w3c.github.io/charter-drafts/web-based-signage-2016.html#normative
> [2] https://www.w3.org/2016/03/device-sensors-wg-charter.html
> [3] https://w3c.github.io/battery/
> [4] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html
> [5] https://www.w3.org/TR/fingerprinting-guidance/
> [6] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#use-cases
> [7] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#term-web-runtime
> 
> 
>> On 1 Oct 2017, at 16.01, Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp> wrote:
>> 
>> Dear Device and Sensors WG members,
>> (Cc: Web-based Signage BG members)
>> 
>> I'm one of co-chairs of Web-based Signage BG [1].
>> I have a proposal to add new items (APIs) to your charter.
>> 
>> The proposal is following.
>> Please let me know your questions or comments on this topic!
>> 
>> ---
>> Web-based Signage BG has discussed about Web-based Signage Player (JavaScript) not only for playing contents on the signage terminal but also for controlling the signage terminal device [2-4].
>> 
>> Web-based Signage BG has considered new APIs for getting the terminal device information and controlling the terminal device via a user agent,
>> and created a draft charter [5] for a new WG to study these APIs.
>> 
>> However, the proposed APIs seem to have a high affinity with Device and Sensors WG, so Web-based signage BG decided to propose to ask Device and Sensors WG to add the proposed API to the deliverable of Device and Sensors WG [6].
>> 
>> Since the initial idea of one of the proposed API (Signage Operational Information) [6] includes the security description, so please refer this, too.
>> 
>> I want to ask you to consider this proposal and to discuss how two groups collaborate on this issue with us.
>> 
>> Thank you in advance for your cooperation!
>> 
>> [1] https://www.w3.org/community/websignage/
>> [2] https://www.w3.org/2016/websigns/core/
>> [3] https://www.w3.org/2016/websigns/basic-media/
>> [4] https://www.w3.org/2016/websigns/storage/
>> [5] http://w3c.github.io/charter-drafts/web-based-signage-2016.html
>> [6] https://www.w3.org/2017/06/22-websignage-minutes.html
>> [7] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html
>> 
>> Best regards,
>> Kiyoshi
>> ---
>> Kiyoshi Tanaka, Ph.D.
>> NTT Service Evolution Laboratories
>> mailto: tanaka.kiyoshi@lab.ntt.co.jp
>> 
>> 
>> 
> 
>

Received on Saturday, 7 October 2017 14:40:26 UTC