- From: 田中 清 <tanaka.kiyoshi@lab.ntt.co.jp>
- Date: Wed, 3 Feb 2016 12:00:27 +0900
- To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, Futomi Hatano <futomi.hatano@newphoria.co.jp>
- Cc: "public-websignage@w3.org" <public-websignage@w3.org>, "Fuhrhop, Christian" <christian.fuhrhop@fokus.fraunhofer.de>, "Steglich, Stephan" <stephan.steglich@fokus.fraunhofer.de>
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) >>>> 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 If you have any additional/new comment, please tell me! 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 Wednesday, 3 February 2016 03:03:13 UTC