Re: Proposal of new requirements for the Web-based signage toward W3C standard

Dear,

I updated the draft charter with the following discussion.
Please find here!
https://docs.google.com/document/d/11DZ4L1ZxFz6JNRWULph09ClwoiMFHiJiXQpG1gn1zTA/edit?usp=sharing

# The original link is complicated for showing this revision,
# so I recommend the new link.

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
   NTT Service Evolution Laboratories
   mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2016/02/04 10:01, Kiyoshi Tanaka (田中 清) wrote:
> 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 Monday, 8 February 2016 00:51:05 UTC