- From: Helena RODRIGUEZ <helena.rodriguez@shopedia.fr>
- Date: Mon, 22 Feb 2016 15:22:54 +0100
- To: public-websignage@w3.org
Thank you for your comment! On 2016/02/09 16:22, Kazuyuki Ashimura wrote: > 2.1 Section 3.1 > ---------------- > > Given the possible relationship with the MMI WG as mentioned above, > I'd suggest we add the MMI WG to the section "3.1 Liaisons" of the draft > Charter. I will add MMI WG to liaisons, but I'm not sure how MMI architecture or EMMA data format match the signage's. We must consider in detail what protocol is good in the further discussion. > 2.2 Section 3.2 > ---------------- > > Regarding the section "3.2 External Groups", I have the following two > comments: > > 1. "ITU-T Q14/16" should be "ITU-T SG16 Q14/16". Yes, I'll change. > 2. There are only ITU-T and DSC listed as related external groups, but > maybe there should be some more related SDOs (esp. international > ones), shouldn't there? I'm not sure which SDO the WG must/want to concern with, besides. Could you tell me such an SDO if you know? > members Best regards, Kiyoshi --- Kiyoshi Tanaka, Ph.D. NTT Service Evolution Laboratories mailto:tanaka.kiyoshi@lab.ntt.co.jp On 2016/02/09 16:22, Kazuyuki Ashimura wrote: > Hi Louay and Kiyoshi, > CCing Debbie, Helena and Raj from the MMI WG > > Thanks a lot for updating the draft Charter, Kiyoshi! > And thanks a lot for your thoughtful comments, Louay! > > I have some comments to you as follows :) > > ---------------------- > 1. Comments for Louay > ---------------------- > > Louay, it seems you're interested in: > - how to handle the lifecycle of the user agent (UA) > - how to manage the state transition of the UA > - common data format/vocabulary for data exchange > > So I wanted to mention that there is some work by the MMI WG [1] related to > the above topics including: > - MMI Architecture, esp. its application lifecycle events [2] > - EMMA data format [3] and its JSON serialization > > I'm CCing this message to Debbie Dahl, the MMI WG Chair, and Helena and > Raj, the two most active MMI participants, so that they can provide some > more > details on those points. > > [1] https://www.w3.org/2013/10/mmi-charter.html > [2] https://www.w3.org/TR/mmi-arch/#LifeCycleEvents > [3] https://www.w3.org/TR/emma20/ > > ------------------------ > 2. Comments for Kiyoshi > ------------------------ > > 2.1 Section 3.1 > ---------------- > > Given the possible relationship with the MMI WG as mentioned above, > I'd suggest we add the MMI WG to the section "3.1 Liaisons" of the draft > Charter. > > 2.2 Section 3.2 > ---------------- > > Regarding the section "3.2 External Groups", I have the following two > comments: > > 1. "ITU-T Q14/16" should be "ITU-T SG16 Q14/16". > > 2. There are only ITU-T and DSC listed as related external groups, but > maybe there should be some more related SDOs (esp. international > ones), shouldn't there? > > Thanks, > > Kazuyuki > > > *************************************************************************************************************************************** MMI WG Comments (HELENA) *************************************************************************************************************************************** Following this discussion it seems you are interested on the state management and the lifecycle of the terminals. The MMI Architecture addresses this issues using the Modality abstraction and proposing specific event exchanges for the system's handling of services in devices. The state management and its transitions is our method to exchange contextual information in multi-device configurations. The MMI Working Group is working on Discovery and Registration of modality components as well, so please refer to the Discovery and Registration Draft: http://www.w3.org/TR/mmi-mc-discovery/ Also, for your information, we are currently working on a high level vocabulary about the services running in the background of a multimodal system. This vocabulary can be helpful for the description of these services at load-time, in order to register the user agent states. *************************************************************************************************************************************** *************************************************************************************************************************************** > On Wed, Feb 3, 2016 at 8:12 PM, Bassbouss, Louay > <louay.bassbouss@fokus.fraunhofer.de > <mailto:louay.bassbouss@fokus.fraunhofer.de>> wrote: > > Hi Kiyoshi, > > > On 03 Feb 2016, at 11:06, Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp <mailto: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 <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 <mailto: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 > <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> > >>>>> <mailto: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> > >>>>> <mailto: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 > <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 > <mailto: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> > >>>>>>> <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 > <mailto: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 > <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 > <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 > <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 > <mailto:tanaka.kiyoshi@lab.ntt.co.jp> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> 株式会社ニューフォリア > >>>>> 取締役 最高技術責任者 > >>>>> 羽田野 太巳 （はたの ふとみ） > >>>>> futomi.hatano@newphoria.co.jp > <mailto:futomi.hatano@newphoria.co.jp> > <mailto:futomi.hatano@newphoria.co.jp > <mailto:futomi.hatano@newphoria.co.jp>> > >>>>> http://www.newphoria.co.jp/ > >>>> > >>> > >>> > >>> > >> > > > > > > > > > > > -- > Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo > Tel: +81 3 3516 2504 > Received on Tuesday, 9 February 2016 10:27:50 UTC This message: [ Message body ] Next message: Bassbouss, Louay: "Re: Proposal of new requirements for the Web-based signage toward W3C standard" Previous message: Kazuyuki Ashimura: "Re: Proposal of new requirements for the Web-based signage toward W3C standard" In reply to: Kazuyuki Ashimura: "Re: Proposal of new requirements for the Web-based signage toward W3C standard" Next in thread: Bassbouss, Louay: "Re: Proposal of new requirements for the Web-based signage toward W3C standard" Mail actions: [ respond to this message ] [ mail a new topic ] Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] Help: [ How to use the archives ] [ Search in the archives ] This archive was generated by hypermail 2.3.1 : Tuesday, 9 February 2016 10:27:51 UTC
Received on Monday, 22 February 2016 23:49:24 UTC