- From: 田中 清 <tanaka.kiyoshi@lab.ntt.co.jp>
- Date: Thu, 4 Feb 2016 10:01:05 +0900
- To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
- Cc: Futomi Hatano <futomi.hatano@newphoria.co.jp>, "public-websignage@w3.org" <public-websignage@w3.org>, "Fuhrhop, Christian" <christian.fuhrhop@fokus.fraunhofer.de>, "Steglich, Stephan" <stephan.steglich@fokus.fraunhofer.de>
Dear Louay, >> Do you have some special issue for interactive service of signage? > let´s take as example prompting dialogs again: In case of interactive services this may be allowed. Ah, though the terminal providing interactive services could show a dialog, but the audience does not have responsibility to decide OK/NG especially for a system matter. On the other hand, the operator side is still under unmanned operation. So, the automatic answer for a dialog might be good. Of course, the system critical case may need alert for the operator. I want to hear a requirement from business operators. Best regards, Kiyoshi --- Kiyoshi Tanaka, Ph.D. NTT Service Evolution Laboratories mailto:tanaka.kiyoshi@lab.ntt.co.jp On 2016/02/03 20:12, Bassbouss, Louay wrote: > Hi Kiyoshi, > >> On 03 Feb 2016, at 11:06, Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp> wrote: >> >> Dear Louay, >> >>> I meant the Lifecycle of the Terminal User Agent (Or more precise the privilege service running in the background). For example what are the possible states of the User Agent like “Turned Off”, “Rebooting”, “Connected”, “Disconnected”, “Reconnecting”, etc. What happens when a user Agent is rebooted: it shows the last page before rebooting or a default page, etc. I am not sure if this is important for the draft. What do you think? >> >> I understand. Your "lifecycle" seems to be one of contextual information. Whether UA needs such complicated operation might depend on the service that the signage provides. And, such discussion would be done in a use-case study. >> So, regarding the draft charter, I think it is already included in "use-case study" word. >> >>> Yes I think it better to address this point in the charter and the decision about potential solutions will be done later in the WG. >> >> Thank you for your clarification! >> >>> Just another question: The group is also addressing interactive Digital Signage (like those in shopping malls with touch screen)? >> >> Do you have some special issue for interactive service of signage? > let´s take as example prompting dialogs again: In case of interactive services this may be allowed. >> >> Though I'm not sure whether there was clear discussion in BG before, >> I think the WG does not exclude the interactive issue. >> However, it is difficult for a new group to study many things, so the WG charter should include only basic deliverables at this moment, I think. >> >> Best regards, >> Kiyoshi >> --- >> Kiyoshi Tanaka, Ph.D. >> NTT Service Evolution Laboratories >> mailto:tanaka.kiyoshi@lab.ntt.co.jp > > Thx > Louay >> >> >> On 2016/02/03 17:52, Bassbouss, Louay wrote: >>> Dear Kiyoshi, Futomi, >>> >>> Please find my comments inline. >>> >>> Thx, >>> Louay >>>> On 03 Feb 2016, at 04:00, Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp> wrote: >>>> >>>> Dear Louay, >>>> >>>> Thank you for your explanation. >>>> >>>>> 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. >>>> >>>> As I said, this would be a good discussion point. >>>> I'll update the draft charter including the data format issue. >>>> >>>> For the clarification, could you please give us the explanation of "lifecycle"? (as Futomi requested) >>> I meant the Lifecycle of the Terminal User Agent (Or more precise the privilege service running in the background). For example what are the possible states of the User Agent like “Turned Off”, “Rebooting”, “Connected”, “Disconnected”, “Reconnecting”, etc. What happens when a user Agent is rebooted: it shows the last page before rebooting or a default page, etc. I am not sure if this is important for the draft. What do you think? >>>> >>>>>>>> Remote Prompting >>>> [...] >>>>> 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. >>>> >>>> OK. I think this function is still interesting but not mature enough. >>>> So, I want to leave it for further discussion. Is it alright? > all >>> Yes I think it better to address this point in the charter and the decision about potential solutions will be done later in the WG. >>>> >>>> If you have any additional/new comment, please tell me! >>> Just another question: The group is also addressing interactive Digital Signage (like those in shopping malls with touch screen)? >>>> >>>> Best regards, >>>> Kiyoshi >>>> --- >>>> Kiyoshi Tanaka, Ph.D. >>>> NTT Service Evolution Laboratories >>>> mailto:tanaka.kiyoshi@lab.ntt.co.jp >>>> >>>> >>>> On 2016/02/02 20:08, Bassbouss, Louay wrote: >>>>> 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/
Received on Thursday, 4 February 2016 01:02:57 UTC