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> Michael's issue on github

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

r/scrurity/security/

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 documents

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 provider/consumer

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

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 section

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?

BIndings

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 involved

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 - http://www.onem2m.org/images/files/deliverables/TS-0009-HTTP_Protocol_Binding-V1_0_1.pdf

Claes: more th escope of the target organization

<Soumya> oneM2M - MQTT protocol binding - http://www.onem2m.org/images/files/deliverables/TS-0010-MQTT_protocol_binding-V1_0_1.pdf

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 specifications

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> Landscape document

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> Michael issue on github about transfer protocol

Johannes: this will appear in the collaborations with other organizations

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

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 deliverables
... 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> TV Control WG charter

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 support

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> 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> 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 implementation.

Johannes: This resource management is not about the CPU/memory management.
... 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 discussion.

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 mapping.
... if several protocols are supported, should the client decides which protocol to use or should the server side decides it.
... 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: https://www.w3.org/WoT/IG/wiki/images/8/88/Communication%26Collaboration_Report_Apr2016.pdf

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> 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 demos

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 pitches

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 Montreal.

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 network.

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 California

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> 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> WoT landing page

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 Michael.

<kaz> github 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 TPAC.

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 support.

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 that

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> WoT IG Charter

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 ideas.

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

Deliverables

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 testing.

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 configuration.

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

logistics

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

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 room

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> 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 America

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> Sunnyvale meeting minutes, fyi

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

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 ]