- From: Kiyoshi Tanaka(田中 清) <tanaka.kiyoshi@lab.ntt.co.jp>
- Date: Sat, 7 Oct 2017 23:34:43 +0900
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: 会社清 <tanaka.kiyoshi@lab.ntt.co.jp>, W3C Devices and Sensors WG <public-device-apis@w3.org>, "public-websignage@w3.org" <public-websignage@w3.org>
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:35:22 UTC