See also: IRC log
<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_
<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 ]
<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
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
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
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
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 ]