W3C home > Mailing lists > Public > public-wot-ig@w3.org > April 2016

[wot-f2f] minutes from Day 2 - 13 April 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 15 Apr 2016 01:03:25 +0900
Message-ID: <CAJ8iq9XkAYPOiN-dguKFaoiVCdOJcB47zqTubdi0sFTLzXoipw@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
available at:

also as text below.

Thanks a lot for taking notes, Michael, Yingying and Dave!



      [1] http://www.w3.org/

                               - DRAFT -

                            WoT-IG f2f Day 2

13 Apr 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/04/13-wot-irc


          Joerg_Heuer(Siemens), Dave_Raggett(W3C),
          Kaz_Ashimura(W3C), Michael_Koster(Samsung,
          _SmartThings), Soumya_Kanti_Datta(Eurecom),
          Matthias_Kovatsch(Siemens), Taki_Kamiya(Fujitsu),
          Toru_Kawaguchi(Panasonic), Frank_Reusch(RWE/Lemonbeat),
          Kazuo_Kajimoto(Panasonic), Claes_Nilsson(Sony),
          Yoshiaki_Ohsumi(Panasonic), Katsuyoshi_Naka(Panasonic),
          Ryuichi_Matsukura(Fujitsu), Kazuaki_Nimura(Fujitsu),
          Daniel_Peinter(Siemens), Sebastian_Kaebisch(Siemens),
          Johaness_Hund(Siemens), Yingying_Chen(W3C),
          Jeff_Jaffe(W3C), Alan_Bird(W3C)


          mivhael, yingying_, dsr


     * [3]Topics
         1. [4]WG Charter
         2. [5]Contribution of Fujitsu on Architecture@PK1140
         3. [6]W3C "Web of Things" Logistics
         4. [7]Working Group Charter
         5. [8]Rechartering the Interest Group
         6. [9]Deliverables
         7. [10]logistics
     * [11]Summary of Action Items
     * [12]Summary of Resolutions

WG Charter

   <inserted> scribenick: mivhael

   Dave introduces the topic of charter review

   Interest group has been an incubator of ideas, other working
   groups forming e.g. security

   Charter typically 2 years

   Chair will be needed

   Process of initial draft + refinement

   3 years is not a long time

   Joerg: continue discussion from yesterday re inter-platform
   over web

   Claes: what is the network effect?

   Dave: value increases as the number of participants in a
   service increases
   ... face to face meetings
   ... introduce the web landscape in the document and limits the
   scope so organizations can determine IPR concerns
   ... the WoT is based on web architecture
   ... introduce diagram and ask Claes to comment

   Claes: important that scripting API is for both exposing and
   interacting with things
   ... also important to specify other scripting environments
   besides js
   ... Table, what is the relation between this table and what we
   are going to standardize ?

   DAve: we could annotate this with the information about what we
   are going to do

   Sebastian: the document should set out early to define what we
   are going to do

   Dave: not a spec for what you do in a browser, otherwise we
   need browser architects

   Joerg: figure vs. range of architectures but the figure only
   shows one scenario for architecture
   ... it needs to convey what we are working on, and can we
   communicate the range of scenarios and architectures
   ... most people are visual, can we show some of a range of
   target architectures
   ... also, what about discovery and other aspects of the system

   Dave: it needs to be small and we need to be careful about what
   we express

   <kaz> [13]Michael's issue on github

     [13] https://github.com/w3c/charter-drafts/issues/52

   Joerg: what are the problems we are looking at, and our
   understanding of the approach

   Johannes: THe image should convey 3 good messages
   ... about what we're doing

   Dave: what is WoT as opposed to IoT should be addresses witj
   specific intention
   ... sec. 1.1 describes what we want to do
   ... starting with TC as vocabulary rather than ontology; more
   developer friendly
   ... security data model not discussed
   ... concerned that srcurity is not at the same level of
   maturity; is trust assertion too ambitious and be dropped


   Kaz: Is this scoping?

   Dave: what should we do?

   Kaz: should this be shorter? the explanation is overkill, we
   should express the key essence

   Dave: shorter description would broaden the scope
   ... will drop the security one

   Kaz: should be the few points that express what the whole group
   agrees with

   Dave: trying to set expectations without too much detail
   ... we know we need these elements

   Daniel: second bullet is concrete, others are too abstract
   ... should be balances in level

   Joerg: make it more focused and make references to other

   Sebastian: Doubts that we have worked out how security is done
   with linked data

   Dave: Oliver wanted to make sure security is mentioned
   ... we could cite external sources instead of adding content
   ... and detail
   ... get review of companies before review

   Joerg: ask Oliver for more information about what we should do

   Dave: get feedback on the approach and what security people
   would like to see
   ... srcipting section - Johannes invited to present this part

   Johannes: Text based on github collection
   ... why do we need a scripting API and what functions are
   needed based on some use case descriptions
   ... looking at both server side and client side, but it looks
   like it is not in the document; it should be in there

   Joerg: it is in the first bullet but not clear

   Johannes: stronger explanation of the server side scripting

   Dave: it's not clear what we mean by server

   Johannes: Message we want to convey is that we are scripting
   for both access and for exposing, providing

   Matthias: server defines a specific interaction pattern
   ... are we locked into protocols that are client-server, should
   there be an abstract interaction model for who initiates and
   who provides

   Dave: client-server is also misleading

   Matthias: assigning server roles to a browser is confusing

   Johannes: client interacts, server exposes

   Kaz: there are some diagrams we could include

   Joerg: we should not assume too much about the audience, get
   feedback from reviewers

   Johannes: when we have a better way, we can update it but for
   now as is

   Dave: collect feedback

   Johannes: could we have 2 bullet points to illustrate

   Dave: points need to stand alone without relying on a lot of

   Joerg: security is a question to expect here
   ... we should explain that we are aware of the security issue

   Claes: should not use "servient" here

   Dave: get tech writers to help
   ... this will be reviewed by technical people

   Joerg: the first section should be more introductory and
   complete for a first evaluation
   ... get outside reviewers to look
   ... let's be clear about what our message is in the first

   Johannes: can we get a pull request from Louay?
   ... describes discovery on one bullet, needs some work?
   ... description of thing life cycle, want to add something like
   creating a thing as a mirror for another thing as an example
   ... try to explain how different languages are supported in a
   consistent way independent of the lenguage

   Dave: design pattern

   Soumya: provisioning as part of the life cycle

   Johannes: does it belong with discovery?

   Louay: could define a setup phase in the life cycle

   Johannes: not part of the runtime

   Louay: has high requirement for security

   Soumya: registering could be like provisioning for some cases

   Joerg: we need to explain why this appears in the document here

   Kajimoto: How do we define state transitions in the life life
   cycle model? What are the APIs? examples?

   <kaz> kajimoto: mentions the need for managing the transition
   of state/phase to handle lifecycle

   Matthias: we need metadata that describes life cycle
   transitions and states

   TD has a life cycle also

   Sebastian: we are discussing

   Daniel: should there be a separate security section

   Johannes: it's good to have security statements in the
   descriptions of how we do things also?

   Dave: in the intro also?


   Johannes: this is to explain to developers how to adapt
   protocols to the WoT environment
   ... each protocol has some important features that need
   consideration in the binding, the protocol experts should be

   Soumya: oneM2M has a protocol binding system

   Dave: other groups also have protocol bindings

   Johannes: bindings to protocols or frameworks, the scope of it
   is bigger
   ... there may be some confusion around this

   Claes: not sure how this impacts our scope, could it be huge?

   <Soumya> oneM2M - HTTP protocol binding -


   Claes: more th escope of the target organization

   <Soumya> oneM2M - MQTT protocol binding -


   Dave: the 2 have to work together somehow, from both sides,
   leave it open to joint determination with each organization

   Johannes: the main output should be how you create a binding to
   a protocol or a framework

   Dave: we could have informative docs as well to help with this

   Matthias: specifically, we want to coordinate and give guidance
   but not make the documents

   Dave: we should collaborate on the framework-specific documents

   Soumya: we could review the oneM2M bindings in TF-AP

   Johannes: we could work one level up from this

   Dave: bindings to platforms and protocols, orgs we work with

   Claes: What about e.g. websockets, who will make the bindings?

   Dave: we could charter another activity if needed
   ... IETF, OASIS, etc. could get involved and help

   Johannes: it could be a huge space to try to write binding

   Johannes, we could statr the work informatively and ask SDOs to
   pick up the normative work

   Louay: could use uri-beacon for pointing to a TD, and provide
   some basic mapping

   Matthias: some protocols can be mapped, some protocols need to
   be modified or have a shim layer added which is out of scope
   for W3C

   Johannes: this is about who writes the normative text. It's
   much better if the SDOs do this
   ... we need to make it very clear what is needed to be done to
   bind a protocol or platform to WoT

   Dave: as a matter of scope, we need to be precise about what we
   are going to do. For example, we could decide to work with SDOs
   to identify changes

   Joerg: do this in the context od collaboration

   Kaz: we have identified target platforms in the landscape
   documents, can we mention these in the document

   <inserted> [16]Landscape document

     [16] https://w3c.github.io/wot/landscape.html

   Joerg: worried about making a list, what message does it sent
   to orgs that aren't on the list?

   Dave: we should be able to refer to some examples

   Matthias: should id be a scope issue vs. a logo collection
   ... transfer vs. transport

   <kaz> [17]Michael issue on github about transfer protocol

     [17] https://github.com/w3c/charter-drafts/issues/51

   Johannes: this will appear in the collaborations with other

   Dave: if important protocols or platforms need changes, we
   would need to take action, what is the action as scope

   Joerg: what is in scope, out of scope, for example a shim layer
   is between scope

   all agree we don't do protocols

   Dave: the charter is expected to provide limited detail on the
   ... and timelines, e.g. first public draft

   Joerg: should the deliverables tie back to the scope, and be
   consistent with what is there

   Dave: what is the new W3C charter template?

   Joerg: is it about completion ?

   Dave: more toward first WG draft as a milestone

   <kaz> [18]TV Control WG charter

     [18] https://w3c.github.io/charter-drafts/tvcontrol-2015.html

   Dave: non-normative deliveraables also

   Joerg: add scenarios for cross-platform

   Matthias: add architecture document as informative reference

   Dave: could be kept as IG document
   ... binding examples?
   ... requirements could be IG document

   Joerg: normative vs. official/unofficial

   Matthias: IG can publish an official informative documants

   Dave: IG can do the informative work
   ... maybe bindings should be a WG product

   Joerg: also the primer could be a WG deliverable

   Matthias: the intention is to cover a broad range in TD without
   needing a lot of other logic

   Joerg: specify the relationship of the WG to the IG

   <scribe> Done with Charter review

   Joerg: At some point the comment phase is done when the number
   of comments is reduced and we have more confidence
   ... We should repeat the run-through as needed
   ... set a reasonable time frame, have a webconf run-through

   Dave: hard to do this in one week

   Joerg: 3 weeks?
   ... ask for input, incorporate comments, have the ren-through

   Claes: email is not usually effective

   Joerg: github issues

   all agree on using github issues

   Johannes: send email when you post an issue

   Dave: members of IG get feedback from their
   company/org/community to insure there is a broad level of

   Joerg: both company internal, and outreach to the community
   ... can we get an indication from everyone on whether your
   company would join the WG

   <kaz> [19]Day2 agenda


   Joerg: how should we proceed with the meeting today?
   ... focus on topics for the rest of the day
   ... rest of the contribution from Fujitsu
   ... BLE mapping
   ... start on the bindings scenario document
   ... those 3 items, are there others?
   ... should we split into 3 groups next?

   <kaz> [ Room assignment will be put on the wiki ]

   <kaz> [ morning break ]

   <yingying_> scribe: yingying_

Contribution of Fujitsu on Architecture@PK1140

   <kaz> [20]Fujitsu's slides


   <inserted> Matsukura: page 12

   Matsukura: : Maybe many protocols can be converted to this
   Legacy Device API.

   Johannes: The procotol mapping would be the same? The
   difference is in the adaptation to legacy device?
   ... common APIs would be on top of the protocol mapping.
   Examples would be helpful.

   Claes: I don't have strong opinion on it. I am wondering the
   purpose of the diagram.

   Johannes: Where is the line to map the legacy protocol to
   protocol mapping layer.

   Claes: do we need to have the resource manager layer? it's the

   Johannes: This resource management is not about the CPU/memory
   ... I'm not very sure where the TD is pointed. It could be here
   in the diagram or one or two layer higher.

   <inserted> Matsukura: page 13

   Matsukura: This slide shows the resource management.
   ... the meta data instance is for device.

   <inserted> kaz: TD metadata part specifies the basic device
   capability whle the TD instance part specifies the information
   to identify concrete devices installed at some place, e.g., the
   user and the location

   <inserted> Matsukura: p14

   Matsukura: next slide for protocol mapping.
   ... we can implement the Device interface.

   <inserted> Matsukura: p15

   Matsukura: this slide shows the App script provider. App script
   calls the script provider and the script provider will use the
   information in TD to call the protocol mapping interfaces and
   then communication protocol APIs.
   ... p16 shows the communication protocol layer.
   ... p17 is the summary.

   Joerg: if you are on your local thing, does the local thing
   have the resource management.
   ... is there anything that you don't know how to find the
   resource. It is expected to be internal.

   Johannes: what should we standardize between resource
   management and protocol mapping.
   ... the red line of API should be between resource management
   and protocol mapping.

   [some discussions on balance what is in TD and what is in
   protocol mapping]

   Joerg: now we need to visualize this two ways instead of just

   Kaz: maybe we can create a github issue of the architecture
   document for this.

   Johannes: we should really write down this question whether the
   app script should know the protocol mapping. For my
   implementation, the app script does not know the protocol
   ... if several protocols are supported, should the client
   decides which protocol to use or should the server side decides
   ... for these kind of questions, it would be good that we could
   visualize them.
   ... it is confusing to me what the legacy device API refers to.
   Is it the protocol to talk to the device API?

   Kaz: given that the upper layer on top of legacy device API and
   WoT API is communication protocol, it is confusing that they
   are called APIs.
   ... maybe we can just simply say legacy protocol and WoT
   protocol instead of legacy device API and WoT API.
   ... we should think about the concrete APIs between resource
   management and protocol mapping.

   Johannes: we should also consider the northbound API and
   southbound API.
   ... for the next step, could we have ppt version as the ground?
   In next call, we could discuss on it further.

   [ Lunch ]

W3C "Web of Things" Logistics

   <dsr> scribenick: dsr

   Joerg shows the topics for this afternoon’s session.

   - report from the communications & collaboration task force

   - draft WoT WG charter and WoT IG charter

   - IG perspective

   - deliverables/documents

   - plugfest preparation

   - meeting logistics

   Joerg invites Yingying to talk about the communications and
   collaboration task force.

   slides at:


   The task force was set up to strengthen awareness of the
   technical and business benefits of the Web of Things.

   Joerg runs through the resposibilities of the task force.

   The talk on behalf of the eclipse foundation relates to our
   goal to reach out to the open source and maker communities.

   The W3C Business Development team need help with outreach and
   recruitment - which will bring fresh resources to the work we
   are doing.

   Please help the task force in its aims

   Since the last F2F, we prioritized and supported events
   relevant to the W3C web of things.

   Yingying has added testimonials to the WoT landing page, we
   plan improvements in their presentation.

   This F2F in Montreal is the first time we’ve been hosted by an
   external group.

   We need to work to prepare for our next F2F in July in Beijing

   We’ve had liaisons with alliances and SDOs, e.g. OCF and OPC

   Some pointers and more detail are in the slides

   We’ve been collecting testimonials from IG members and are now
   also seeking to get testimonials from SDOs and alliances

   Joerg turns to the topic of the Beijing F2F in July

   This will have 2 days of open meetings followed by 2 days for
   the IG internal discussions.

   Yingying explains that CETC hosts the China IoT alliance and we
   expect to have talks from key people along with demos and talks
   from IG members.

   <kaz> [22]July f2f wiki


   Joerg talks about pros and cons for having the senior/business
   people on either the first or the second day.

   Yingying: we need to finalise this soon.

   Jeff_Jaffe: I like the idea of exposing people to the plugfest

   This is also an opportunity to introduce industry people in
   China to the work we’re doing.

   Yingying: we need a good estimate for the number of people who
   will attend from the IG

   <Sebastian> thanks kaz for the information

   Joerg: the number of F2F participants has depended on the
   location, travel restrictions and conflicting events.

   We need to clarify the expectations of the local people as to
   the ordering and nature of the open days.

   Johannes: the way we’ve had our plugfests isn’t so good for
   non-technical people

   Joerg: perhaps we can set it up so that the visitors can be
   given a guided explanation as they move between demos

   Jeff: we need to be sensitive to making ourselves easy to
   understand, e.g. speak slow and simple and give clear elevator

   Dave: perhaps we could provide some written descriptions of the
   plugfest demos prior to the event?

   This could help with making our work easier to understand

   Joerg: we need a contact person for the plugfest. This
   especially important for the network issues we’ve had, e.g. in

   Yingying: if you can provide us with the requirements we can
   take that on.

   Dave: this is likely to involve testing the site network and
   negotiating arrangements for us to set up an effective demo

   Joerg: we’ve had problems here at UQAM with the network
   blocking our gateway.

   Yingying: the July F2F wiki page is still very rough and will
   change considerably

   Joerg displays a slide on liaisons.

   Matthias summarises the joint OCF/W3C/T2TRG meeting in

   OCF for instance currently use RAML for describing their APIs
   and we have a good chat about the extra value that thing
   descriptions can offer.

   <kaz> dsr: provides some more supplementary information

   Dave summarises the IAB workshop on semantic interoperability

   There were some good discussions about the technical challenges
   for both semantic interoperability and end to end security

   We will be able to build upon this, e.g. in the joint white
   paper on semantic interoperability, and another on trust
   assumptions in relation to end to end security

   The IAB set up a mailing list, and wiki on GitHub to continue
   the dialogue

   <mkovatsc> [23]https://github.com/iotsi

     [23] https://github.com/iotsi

   Joerg: we need to clarify what we need to do next

   Both in respect to recuiting people to the WoT activity, and
   also in respect to open source projects and the maker community
   events relating to th web of things.

   Joerg: if you participate in the plugfest, you should aim to
   provide open source implementation and documentation.

   We want to encourage multiple independent implementations

   The next teleconference for the communications and
   collaboration task force will be on 18 May at 0600 EDT, 12:00
   EU, 1800 China and 1900 Japan

   Joerg encourages more people to join the communications and
   collaboration task force

   Joerg asks for how many IG companies have provided testimonials
   so far?

   Yingying: 6

   <kaz> [24]WoT landing page

     [24] https://www.w3.org/WoT/

Working Group Charter

   We had 2 commenting rounds from the last F2F, and a very
   productive discussion this morning.

   Joerg summarises the outcome of those discussions.

   We need to use github issues to track the issues raised today,
   starting with the points from today’s minutes as written by

   <kaz> [25]github issues

     [25] https://github.com/w3c/charter-drafts/issues

   A revised draft of the charter by May 4

   Telecon to discuss the draft on May 11

   Finalised draft WG charter by May 18 for discussion outside of
   the IG

   Jeff: when will the charter be ready for AC Review?

   Joerg: Summer?

   Jeff: it would be good to aim to have a WG meeting at TPAC

   AC Review is itself 4 weeks, but may take longer depending on
   the comments received

   The July F2F will be an opportunity for any final adjustments
   to the WG charter.

   Dave: we are tentatively planning for a joint IG/WG meeting at

   Dave cites the experience of the Web Payments IG spawning a WG
   as illustrative of what we’re going through

   Jeff provides details of the Web Payments IG/WG story

   Jeff: working back from a deadline can help to force the pace.

   Dave: we need to work in sync on outreach, open source and
   liaisons, in order to get the broad support for the WG in place
   before the AC Review

   Jeff is supportive of the idea of a joint meeting at TPAC even
   if the WG hasn’t yet been formally launched. It would be a good
   opportunity to gather a broad set of stakeholders and build

   Johannes asks Dave about the schedule for the open source work
   and what needs to be done

   Dave: we need complete implementations, documentation and demos
   ready along with outreach to the relevant communities. The July
   F2F open days provide a good target to drive that work towards.

   <kaz> kaz: It would make sense to have rough expected schedule
   till TPAC 2016 in September.

   Joerg: adds one line on our expected schedule for TPAC 2016

   Joerg: we’ve already chatted about the idea of starter kits for
   the web of things

Rechartering the Interest Group

   Joerg: displays a screen shot of the charter which ran out on
   March 31

   Joerg explains the value of continuing the IG in parallel with
   the WG

   We need to clarify the respective roles of the IG and WG

   <kaz> dsr: summarizes the background

   <kaz> michael: we can continue plugfest, etc., using the IG?

   <kaz> dsr: yes

   Dave gives a short rationale - the IG would work on open scope
   topics including the plugfests, technical stuff that is not yet
   mature enough to standardise, and outreach to external groups.
   The IG would have a very narrow focus on driving a few specs
   along the REC track

   Johannes: I’m worried that we won’t have enough manpower to do
   both groups

   Dave: this is why we’re working on convincing companies to get
   involved and grow the manpower available

   Jeff: if companies feel this is important and if they are doing
   implementation work they presumably will, then they can be
   expected to provide additional manpower

   Joerg: building strong relationships with industry alliances
   and SDOs is critical, and very important role for the IG. The
   IG also can look at the work that needs more study.

   We can look at the range of topics we’ve already raised and
   identify those the IG should plan for.

   Jeff: six weeks ago I presented a keynote at the Industry of
   Things World conference in San Diego.

   There was strong support for W3C’s role in enabling
   interoperability across platforms

   During the recent Advisory Committee meeting, we asked Members
   to name the next big things.

   Web Security was the highest followed by th Web of Things. This
   work is essential, so I want to push back on the notion that
   this is a fringe activity

   Joerg: we need to clarify the next steps.

   Jeff: today at the opening of the WWW2016 conference, Tim
   Berners-Lee provided the opening keynote and covered the web of
   things. So yet more support!

   Joerg: we need to brainstorm on formulating the relationship
   between the IG and WG

   Matthias: it would make sense to co-locate the IG and WG
   meetings and it would be worth thinking about the logistics for

   Kaz: precedent set by automotive Business Group and the Working
   Group it spawned. They co-locate with consecutive meetings.

   Matthias: perhaps we can focus more on decision making at the
   meetings and do more work remotely

   Jeff: in practice there will be different people in an IG and
   WG with just a few in both.

   I don’t think we can extend the charter duration for the IG
   unless we have a strong plan in place for rechartering within a
   few months and planning for a charter of at least a year and
   perhaps longer

   <kaz> [26]WoT IG Charter

     [26] https://www.w3.org/2014/12/wot-ig-charter.html

   Dave: we have the precedent of the web payments and automative
   groups to guide us in drafting a revised IG charter

   Jeff reads from the existing charter. This already envisions
   the IG launching work into existing or new WGs

   Joerg summarises

   Dave notes the need to start planning for dialog with other W3C
   groups, e.g. on security

   The IG charter should cover this

   Kaz also suggests the IG should think about what to be done by
   the IG side in addition to what to be done by the WG, and
   mentions there is a possibility the CG could be used instead of
   the IG if there is something to do but not for the IG after
   launching the WG

   Dave: the broadly scope CG hasn’t got any traction. Narrowly
   scoped CGs could be a future option for incubating specific

   Joerg wraps up the discussion. We will set deadlines in
   upcoming telecons

   <kaz> Jeff suggests we think about the manpower for the
   leadership for the WG/IG as well


   Joerg reviews the work items we’re doing

   These include the use case document, tech landscape document,
   architecture document and current practice document.

   We’ve agreed to June 10 for freezing the current practice
   document for the July plugfest.

   Joerg reviews plans for the plugfest. Three topics for
   discussion included client interface for discovery, datatypes
   and formulation of the protocol binding

   Matthias summarises the work on thing description support for
   protocol bindings

   Joerg looks at the practical logistics. For example, a
   developer how-to, participation info, network setup and prior

   We need some pre-testing to reduce the time we otherwise have
   to spend during the meeting

   We would like to define a specific configuration that people
   can test against before travelling to the F2F.

   Daniel: we need to have someone responsible for defining the

   Joerg looks for a volunteer [the room falls silent]

   Soumya: perhaps the people who are involved in IETF meetings
   could provide advice

   Dave: likewise, I could ask the W3C systems team who have
   considerable experience with preparations for TPAC. However, we
   need someone to take responsibiity within the IG

   Michael agrees to look after the router set up config file.

   Daniel agrees to look after the network requirements

   Yingying will look after the local support for the networking
   and other logistics

   Joerg: we need the local team in Beijing to conduct some tests
   in advance of the meeting.

   We want things online by end of May.

   Joerg: finally we need to review how we work between face to
   face meetings


   Joerg: we may want to reconsider the slots for the regular

   We may switch from task forces to a topic oriented assignment
   of call slots

   With the agenda announced a week in advance

   Joerg suggests we have our next call on Wednesday April 20 at
   2PM CET

   What are the proposed agenda items?

   Sebastian suggests we need more time and should start the call
   the following week

   Joerg says we will have the call on April 20, but *not* on
   Thursday April 21

   The next F2F is 11-14 July 2016 in Beijing, and the following
   one in Lisbon on 22-23 September as part of TPAC.

   Some of us may meet up during the IETF 96 in Berlin on 16 July.

   Matthias: could we look into the logistics for a joint meeting
   with the T2TRG on Saturday 24-25.

   Dave & Kaz should ask Coralie about the possible availability
   of rooms

   This should also include the idea of a plugfest preparation

   The plugfest would be on the 22nd

   Dave: there is an opportunity for demos on the plenary day (Wed
   21 Sep)

   Joerg: let’s keep that open for now; the basic requirement is
   having a preparation room on 21st.

   <mkovatsc> [27]https://summit.riot-os.org/

     [27] https://summit.riot-os.org/

   Matthias the IETF 96 meeting will be combined with a RIOT OS
   summit on July 16

   Dave: we could perhaps plan for distributed demonstrations!

   Joerg: we should consider planning the follow on F2F in North

   Jeff: we should consider who are the biggest US companies we
   want to get involved in the WoT activity

   for instance Cisco, General Electric, browser companies, etc.

   Joerg: Intel would be another possibility

   <kaz> [28]Sunnyvale meeting minutes, fyi

     [28] https://www.w3.org/2015/07/29-30-31-wot-minutes.html

   Joerg: this is something we can take forward as a pending

   Michael: I will look into this on behalf of Samsung

   Dave: Google could be interesting, we have a standing
   invitation for them to present their work on Brillo/Weave when
   it is fully public.

   Michael: a joint meeting with schema.org is another possibility

   Joerg: we now done - thanks for coming to this meeting and talk
   to you next week!

   Kaz: one last point, we did talk about switching to a US based
   time slot rather than Europe based slot

   This only effects the two weeks twice a year when North America
   and Europe are out of sync

   Kaz: China, Japan and Korea don’t change their clocks, i.e.
   fixed relative to UTC

   Dave: we could fix to UTC then?

   RESOLUTION: Fixing to North America would reduce risk of
   clashes with other meetings during the 4 weeks a year when the
   clocks are out of sync

   Joerg brings the meeting to an end

   [ Meeting adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [29]scribe.perl version
    1.144 ([30]CVS log)
    $Date: 2016/04/14 12:26:40 $

     [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [30] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 14 April 2016 16:04:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:58 UTC