Day 1

<dsr> see: https://www.w3.org/Team/wiki/TPAC/2015#Group_meetings_needing_remote_participation.2FWebEx

<dsr> scribenick: dsr

Joerg introduces the meeting and provides some background about the WoT IG for the observers present in the room

Many application domains

The goal is to overcome the silos and enable cross domain applications

There is a need for standardised IoT building blocks

We started with looking at a variety of use cases and analysing them to identify some atomic use cases

i.e. smaller pieces of functionality that re-occur across use cases

We then worked on a survey of the technology landscape and most recently prepared for a plugfest for this meeting in Sapporo

Earlier this week, we have a joint meeting with the Automotive group.

Joerg explains how our work has proceeded relative to our face to face meetings, starting with Munich, then Sunnyvale and now Sapporo.

Joerg pauses to email the slides he is presenting

The WoT building blocks are intended to map to existing IoT platforms and protocols

This allows for integration of “things” in today’s Web by enabling web apps to integrate “things”.

It further allows for integraton of app domains via the Web

Things are modelled in terms of their properties, actions and events, their data and metadata

We have looked at scripting APIs and protocol bindings

Joerg introduces the term “servient” as a name for a software agent that can act as both a server and a client

These can use Web protocols such as HTTP. They can also use IoT specific communications technologies and protocols, e.g. ZigBee

Joerg introduces the task forces tha the WoT IG has set up following the Munich face to face

These are: Thing descriptions, Thing APIs and protocol bindings, Thing discovery and provisioning, Thing security, privacy and reslience

The links are as follows:

https://www.w3.org/WoT/IG/wiki/Thing_Description

https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF

https://www.w3.org/WoT/IG/wiki/Discovery_TF

https://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience

The status for each of these task forces will be reviewed today

In respect to security, we also need to address safety and compliance

<AxelPolleres> Question… Will the slides at https://www.w3.org/WoT/IG/wiki/images/b/b9/TF-AP_status_TPAC15.pdf be updated? (linked from the agenda but seems to be an older version, yes?)

<AxelPolleres> … sorry that are already the slides for the different task forces.

<AxelPolleres> … but it would be ncie to have a link to these introduction slides (maybe I missed it, because I joined the IRC a bit too late)

<AxelPolleres> dsr, thanks!

Joerg runs through the details of the agenda, see https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-30_October_2015,_Sapporo,_Japan#Agenda

This morning we will review the status of the task forces, and look at what is needed to finalise the first version of the technology landscape.

After lunch, we will discuss work on generic sensor API, and ideas for WebGPIO, Web I2C etc.

This will be followed by the plugfest and a group dinner for those who want

Tomorrow, we will have a report from the plugfest and plans for the next one. We then will have breakouts.

After lunch we will have a report back from the break outs, followed by a joint discussion on the work plan and upcoming face to face meetings.

We will then look at the preparation of a charter for a working group and the plan for a communications task force. Finally, we will have a discussion in preparation for the joint meeting with the Internet Research Task Force Thing to Thing Research Group over the weekend in Yokohama

any questions? [no]

Status and outlook for the Thing Description Task Force

Johannes presents his slides, see https://www.w3.org/WoT/IG/wiki/images/b/b9/TF-AP_status_TPAC15.pdf

How can a web page interact with a “thing”? We’ve worked on an object/agent based solution

There is binding between a client API and a resource model, along with protocol bindings, as we are fully aware that there will be different protocols according to the context

Johannes: we’re working on deliverables for the use cases and requirements, and a technology landscape survey

The latter will cover the model for things, protocol mappings, resource models, and scripting APIs and low level APIs for controller interfaces

… which can be used to access the hardware for sensors and actuators

Johannes distinguishes between a server API and a client API

We would like to make it easy to run scripts on different platforms though shared APIs

any questions?

[no questions]

Joerg: please tell us about the break out session for tomorrow?

Johannes: we recognise that there will be different scripting languages, so we will need to discuss the use of abstract interface definitions.

For the plugfest, people have had to create their own APIs, so we will look at what these are and how they relate to each other

Arnaud Le Hors (IBM): how far do you intend to go down that route and how much is this in scope of the charter?

Johannes: we are using a model as a basis for comparing different solutions. We’re not trying to define a spec (since this is an Interest Group not a Working Group). We do however, want to achieve rough consensus and running code!

Joerg thanks Johannes.

Topic Discovery and provisioning Task force status and outlook

Soumya introduces himself as the lead for this task force.

He explains the need for discovery

… and explains how the task force has proceeded. We started with looking at the purpose and scope, ideas for simplifying discovery and a survey of existing approaches.

We have evaluated approaches in six categories,

<yingying> https://github.com/w3c/wot/blob/master/TF-DI/Interactions.md

These are:

1. finding things around me

2. finding things on my network

3. searching in directories

4. via accessing thing metadata (i.e. things that are dependent on other things)

5. searching across peers

We are looking for volunteers to help us refine the landscape survey with more details

We want to look at a uniform, technology independent abstract discovery API, and also authorisation (i.e. who is allowed to see what)

We are also planning on work on provisioning of devices and services

We welcome input on this

For the break out session, we would like to address provisioning, and the relationship to secuity and privacy.

We would like to look at how provisioning relates to the APIs and protocols task force

I want to thank Anic and others for their help

questions?

Dave: Note that we are looking at discovery based upon the semantics of things, and also based upon relationships between people, places and things.

No further questions

Joerg: in respect to the break out, the discovery task force is in a good shape. You’ve set the goal for the first draft report for the end of 2015. How do you plan the next 2 months

Soumya: we want to complete the landscape analysis

<Sebastian_Kaebisch> should we involve discovery based on TD for the next plugfest?

Soumya: yes we do

Thing description task force status and outlook

<yingying> slides:https://www.w3.org/WoT/IG/wiki/images/8/82/Td_overview_sapporo.pdf

Sebastian introduces the motivation for thing descriptions

what kind of a thing is it? What kinds of data do you have? How can these be accessed?

We’ve looked at a range of existing approaches in our landscape survey

For more details, see https://www.w3.org/WoT/IG/wiki/Thing_Description

The thing description framework should be scalable. Devices may be very constrained, so the descriptions should processable on resource constrained microcontrollers

<yingying> about TD models: https://github.com/w3c/wot/blob/master/TF-TD/Tutorial.md

Sebastian: metadata may include information that may not be needed at run-time

Thing properties may be stable or dynamic. We’re looking at how to represent how stable a property is

We also need metadata that indicates how a thing can be accessed on a given server, e.g. the protocols, data formats and encodings that server supports

The approach is founded on the W3C Resource Description Format (RDF). We’re looking at easy to process serialisations such as JSON-LD

He presents an example

Recently, we’ve looked at how to define a default JSON-LD context for common vocabulary terms. JSON-LD provides contexts as a means to bind names to RDF node URIs

We’ve also been looking at protocol bindings, e.g. to HTTP and CoAP

where we are using JSON based messages, but we recognised that XML may also be of interest, e.g. in combination with EXI as a means to provide efficient message encodings

<yingying> samples of TD: https://github.com/w3c/wot/tree/master/TF-TD/TD%20Samples

Sebastian reviews the plans for today’s plugfest

He adds that he has approached the W3C Efficient XML Interchange (EXI) Working Group to see if they may be willing to take on a work item for efficient interchange of JSON based messages

We also want to look at the processing models for thing descriptions, and the relationship to domain specific metadata

We had a joint session with the SDW WG who plan to standardise the semantic sensor network (SSN) ontology

<yingying> SDW breakout session minutes->http://www.w3.org/2015/10/28-swot-minutes.html

SDW = spatial data working group

We plan to complete the landscape survey and analysis by the next face to face early next year.

We want to enrich the plugfest for the next face to face, e.g. with security and discovery

questions?

Joerg asks about the approach being taken by the task force

Sebastian: so far we haven’t found anything that encompasses the range of requirements we’ve identified

Joerg welcomes everyone back from the break

He asks Oliver to present the report for the security task force

<yingying> slides: https://www.w3.org/WoT/IG/wiki/images/f/f8/Security%26Privacy_Report_Sapporo_F2F.pptx

Security, privacy and resilience task force status and outlook

Slides: https://www.w3.org/WoT/IG/wiki/images/d/d7/Security%26Privacy_Report_Sapporo_F2F.pdf

<Raj> Would you mind sharing the slides on webex for the benefit of remote participants? Thanks

Oliver introduces the scope of the task force and the plans for its work

The objective is to identify the security and privacy requirments for the use cases collected by the IG

<Raj> Thanks, since the webex is showing camera view and audio is not very clear, unable to figure which slide the peaker is on, sorry for the trouble

We’ve been working on the landscape study in the wiki

We’re looking at both design time and run time mechanisms

For the break out, I want to focus on the landscape study

The task force wiki page: https://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience

Security is also relevant to controlling discovery - who can see what

We’re collaborating with the other task forces, e.g. the discovery task force

We have yet to start our study of resilience for IoT services

We want the next plugfest (early next year) to address security and privacy

The Industrial Internet Consortium is about to publish their work on security, and we plan to review that as part of our collaboration agreement with the IIC.

questions?

Soumya: I would like to join security breakout, but as the breakouts are all in parallel how do make that possible?

Joerg: we don’t have a lot of time, but cross task force sessions should be feasible and up to the task force leads to arrange

Dave: we should think about looking at safety and compliance as future areas of study

Oliver: I would be happy to look at this later on

We would follow a similar process ...

Joerg: we had a joint session with the automotive group to understand their use cases and requirements

… they also have strong security requirements

progressing the landscape reports

Joerg: different task forces are at different stages of maturity in their work on the landscape study

It took some time to arrive at a set of criteria for evaluating the landscape in some of the task forces

The wiki isn’t very clear for the status of the work for each task force. We’re also moving towards the deadline for publishing the reports by the next face to face (late january 2016)

What is the best way to progress?

Dave: other groups have found Github as a good way for collaborative work on reports. I suggest we take the materials incubated in the wiki and move them into draft reports on Github allowing people to review, raise issues and collaboratively edit.

<Soumya> Soumya: +1 on GitHub

Joerg: what about collaborative editing tools?

Dave: Google Docs has been used occasionally, but not everyone can access it

Github seems to be best practice right now

Joerg displays a draft document which is essentially just a skeleton right now.

see http://w3c.github.io/wot/landscape.html

Joerg asks the task force leaders for their estimates for the time frame for work on the Github doc

Soumya: we could start on this for the discovery TF from next week

Joerg: we need a second editor for the discovery work

any volunteers?

Joerg will talk to people during lunch :-)

Johannes: for the API and protocols Task Force, we aren’t quite ready to transfer to GitHub.

We first need to collect content in the wiki until the end of this year and then transfer to GitHub and the issue tracking process.

Dave: if people find pull requests difficult, we could enable direct editing of markdown in the browser

Johannes asks if people are willing to use GitHub issue tracker even though the content is still on the wiki?

Sebastian: we could do with a tutorial of the process and tooling

We should do this at an upcoming teleconference

In respect to the thing description task force, it should be straightforward to transfer content to GitHub, and I too am looking for volunteers to help.

Oliver: it will be straighforward to transfer the security materials and would like to do so in 4 or 5 weeks from now

The wiki content would then become historical

Joerg: we very much need additional help for the security work, do you have any suggestions for who to ask? Can we get help from outside of this group?

Oliver: yes, let’s follow that up later

Soumya: OneM2M are very active on the security topic, and I know the chairs. Dave and I will be at the M2M workshop in December and could ask for help.

Joerg encourages Oliver to get in touch with David Rogers over lunch

<drogersuk> As mentioned, the IoT Security Foundation is here: https://iotsecurityfoundation.org/

<drogersuk> I think it would be good to liaise both ways and it will be good for exposing the work here to a wider audience / recruiting support

Joerg: please talk with the task force leaders over lunch how you could support the work. It will be a very focused activity over the next 10 weeks. Let’s break for lunch now and do a quick check back after lunch

Soumya invites people to visit his demo table in the lunch hall!

we break for lunch and will resume at 13:15 (time in Japan)

we resume from lunch. Joerg describe the plan for a group dinner at 19:30 at the Sapporo Beer Garden.

We will now go over several contributions.

Generic Sensor API, Tobi Langel

<tobie> https://w3c.github.io/sensors/

<yingying> scribe: yingying

Tobie introduces the Generic Sensor API

Tobie: goal to create a generic API for most sensors locally or on web platform.
... generic sensor does not describe specifically any sensor.
... example 3: geolocation sensor, very simple API. advantage is the API the same despite what language is used.

<tobie> https://gist.github.com/tobie/11cf06b819544f71fe36

Tobie: show example written in web IDL.
... in automotive group, how to use the API to listen to the sensor event and so on.

<tobie> https://gist.github.com/tobie/4e438781ebf8d7980af9

Tobie shows another example: thing is a remote light bulb. How to use the generic sensor API.

Johanas: the example is very related to the scripting API of WoT.
... in WoT we separate properties, event, action. How would you put data?

Tobie: it's clearly not the scope of generic sensor API.
... but I like to know the use cases of combinations of sensors.

Dave: simple case would be the temperature LED light. There are also plenty of complicated use cases.

Joerg: upper layer like geolocation, low layer like streaming, GPIO. Put the in the context of interaction of things, would you do it in the low level or higher level.

Tobie: one good example is orientation. SHould we use gyroscape sensor or high level configuration?
... some use cases are very sensor specific. There is also security consideration.
... good to give a lower level access. A trade off is needed concerning the data security and the time limitation to access the data.
... in some cases, developers want to use a higher level API for easy provision.

Joerg: we could continue the discussion on the access of high or low level API.

Tobie: will work on generic and @@1 API at the same time.
... understand use cases at lower level, e.g. bluetooth, GPIO, etc...

<dsr> extensible web manifesto: https://extensiblewebmanifesto.org

Low Level APIs for Browsers - kotakagi

<naokis> https://www.w3.org/WoT/IG/wiki/File:IntroductionOfWebI2CGPIO.pdf

Joerg: go ahead with another discussion topic on WebI2O and GPIO by kotakagi from MozillaFactory.

<naokis> https://www.w3.org/WoT/IG/wiki/images/1/13/IntroductionOfWebI2CGPIO.pdf

kotakagi: introduce the slides.
... introduces motivation of developing these APIs.
... maker movements are all around the world.

<dsr> Chris Anderson “Makers: the new industrial revolution” see https://en.wikipedia.org/wiki/Makers:_The_New_Industrial_Revolution

kotakagi: we want to encourage maker movement by web as the open digital tech.

<naokis> Mozilla Factory factory http://en.mozillafactory.org/

kotakagi: the vision is pervasive browser.

<kudo> There are so many devices with display, we want to replace those display with browser based.(pervasive browser)

kotakagi: kotakagi shows browsers run in various devices.
... in the near future browser can work on micro controllers.

kotakagi shows the framework in WoT context.

kotakagi gives the link of the two APIs: WebGPIO and WebI2C.

kotakagi: we expect many devices need these APIs.
... the APIs were done in the Browser and Robotics CG.

Dave: is there possibility of flexibility to develop on such a large range of devices?
... for a simple vs effficient API?

kotakagi: @@2

@@2: flexibility of large number of devices.

@@3: how about the browser vendors support of these API.

kotakagi: not known yet.

Dave: more about the story of security and privacy consideration?

@@2: security consideration is there and will be more.

Tobie: for security story, something similiar as Bluetooth. Downround??

Rigo: privacy can be addressed with sticky policies that accompany the data as it is moved across the Web

<dsr> different microcontrollers vary considerably in the details on their hardware which makes it hard to create a common API for all of them.

Joerg: next presentation How WoT may benefit from a generic discovery/communication API in line with Presentation API model by Louay Bassbouss, Fraunhofer FOKUS

Thing API Proposal - Louay Bassbouss, Fraunhofer FOKUS

Louay: similar to generic sensor API but in WoT context.
... API will benefit thing discovery. Security and Privacy are taken into account.
... should consider TD.
... Presentation API was made in the W3C Second Screen Presentation CG.

<kotakagi> slide for WebI2C,GPIO--> https://www.w3.org/WoT/IG/wiki/images/1/13/IntroductionOfWebI2CGPIO.pdf

Louay: WG was created and FFWD was in August 2015.

Louay introduces the Presentation API.

Louay: introduces the proposal of Thing API.

<dsr> This API abstracts away from the underlying discovery mechanisms of which there are many

<dsr> We have an implementation as a Cordova app for iOS and Android

Louay shows a live demo.

Louay: the underlying is BTLE but it doesn't matter for the API.

Jonathan Jeon: there is similarity of other context, e.g input devices like wireless keyboard.

scribe: is there any consideration of the scripting API supporting usage without thing description model?

Louay: The thing is not for the browser. There are lot of mechnism to access the thing.

Tobie: if we could find various use cases that have the common generic requirements, we could work in the generic sensor scope to benefit a lot of scenarios.

Carsten: first question: security consideration for a thing locally or in the cloud side. Second question: when authentication things, is there any guidance how to?

Joerg: server side and client side consideration need to take. Not much browser orientation consideration, might need to take into consideration the user interaction.

Tobie: similar permission issues in the WebBluetooth CG. You might want to liaise with them.

Johanas: how about the consideration of remote vs local things?

Louay: presentation API is only for local thing. For remote access, maybe unreachable but if reachable, it should be the same API.

s/Joerg: next topic: Things Web - Internet Service Script and Protocol Bindings Installable Web of Things Framework including a demo by KiChul Park, Samsung//

Discovery, configuration and working of Lemonbeat-Devices - Frank Reusch, Daniel Lux, RWE

Frank: introduces the Lemonbeat smart Device Language.

<dsr> aka “LSDL” which includes support for state machines

Frank: will present several topics: device discovery and inclusion, examples of traffic light devices, configuration values and services for a device, runtime
... introduces the functionality of state machines
... in the LsDL
... state changes trigger some corresponding actions, and so on.

Frank shows the example of device discovery.

Frank: introduces the device description.
... communicate with the device to get the value description of a device.

Daniel shows demos to change the configuration of device.

Daniel: msg can be broadcast, devices can be grouped.
... action can be triggerred ( yellow light blink) when the state changes to the yellow light.

Dave: Manufacturing support?

Daniel: we need to make the language very generic. We need to separate the concerns between devices.

Dave: LSDL is one of a family of languages for state machines. These include W3C’s SCXML, and the Grafcet languages for programmable logic controllers in manufacturing. The WoT IG should perhaps survey these as an alternative to using scripting languages.

Suomya: which language do you use for device? JSON-LD?

Daniel: xml and EXI

Suomya: which mechnism do you use to discover device?

Daniel: broadcasting message.

Things Web - Internet Service Script and Protocol Bindings Installable Web of Things Framework including a demo - KiChul Park, Samsung

KiChul: introduce the slides.
... use cases are categorized to two: IoT control with browser and Web sevice extended with IoT.
... go through the work flows.
... shows some demos.

Johanas: in the architture, you showed that you could download scripting to register things on gateway level. Would it be possible also to download in the device level?

<kaz> join #websigns

<kaz> s|join #websigns//

KiChul: for the small device, it may be no capability to install.

Johanas: purpose of the plugfest is to make sure for different implementations to interact with each other.

plugfest

Sebastian: demo of traffic light with NodeMCU
... challenge is to apply the things description on the micro controller

nagano: demo to show the thing property like speed.

Suomya: introduces his demo

@louay: introduces the demo of Fraunhofer FOKUS

Nimura: introduce the demo of Fujitsu on a WoT Servient implementation

Jonathan: introduce the demo of ETRI

Darko: introduces the demo from Siemens

Johannes: introduce the demo of thingweb

Dave: introduces the demo of Web of Things on the Arduino Uno and Ethernet Shield

Naoki: introduces the demo of WoT servient implimentation by web browser

<JonathanJ> https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0107.html

---

Day 2

Plugfest report

<inserted> scribenick: soumya

<joerg> volunteer for minutes for first 30min?

I can take it

scrbenick: Soumya

<joerg> thanks!

Johannes presents a report on plugfest yesterday

problems on network side

<kaz> Meeting: WoT IG f2f meeting in Sapporo - Day 2

concept that we are pursuing is working out for some implementations

<kaz> Chair: Joerg

johannes would like to collect the info

and collect the implementation and slides

the plugfest wiki could serve as a good place for other organizations and show we are actively pursuing implementations also

dissemination - collect all files from implementors and note what works, what needs to be changed

johannes wraps up plugfest report and thanks everyone who participated

questions?

joerg asks for suggestions from implementors

joerg mentions issues related to network

we might need a local network setup - could be a topic for future plugfests

johannes points out of giving fixed address for the thing descriptions

sebastian mentions about taking more time for the preparation of future plugfests

proposal - plan one day for dedicated prep. of plugfest

Dave suggests using the Internet for global testing

Darko points out the problem of proxy

<dsr> We can use servers on the public Internet as a way to connect our devices across the Internet, and use webex or skype for a side channel

Darko suggests that to go for thing to thing interaction where one thing can interact with another using thing description and also the API binding point

Johannes asks if the group would like another plugfest - (i) over Internet and (ii) what points could be improved (like automated T2T interaction, interoperability, security)

Darko suggests to include plugfest as a agenda for telcos

Johannes proposes to wrap up the topic

Joerg asks about the format of future plugfest

Joerg asks Carsten

Carsten: people come together, have a introduction talk on the problem, they also discuss that in the mailing list, secret - *better preparation*

Carsten further mentions a EU project in relation to the plugfest discussion

Joerg summarizes the main points from the discussion

<JonathanJ> I think we need to clarify the policy, procedure and goal of our plugfest. Chapter 12 of this document would be referencable - http://nfc-forum.org/wp-content/uploads/2014/10/NFC-Forum-Rules-of-Procedure.pdf

Joerg: proposes a initial set of aspects to look at next time. So far looked at TD and protocol (HTTP, CoAP), scripting.
... can we come up with the descriptions for both and propose it as an agenda for next three months

<cabo> The project I mentioned is called F-Interop and starts on Monday next week. So we may be in a good position to help them set their agenda.

Joerg: Three items - (i) how can an initial generic script API be setup, (ii) what is a pragmatic initial setup for security and (iii) sketch out the setup for remote preparation in a dedicated webconf call
... concludes the session

breakout preparation for the morning

Minutes from breakouts:
- TF-AP
- TF-TD
- TF-SP
- TF-DI

Joerg: show of hands for the organization of the TF breakouts

<stakagi> presnet+ daisuke

<inserted> scribenick: kaz

* NOTE on the IRC Channel *
please join the following IRC channels:
- #wot-ap for TF-AP
- #wot-td for TF-TD
- #wot-sp for TF-S&P
- #wot-di for TF-DI

<Raj_> Could someone post the webex url on irc? Thanks

<kaoru> TF-SP discussions in #wot-sp

<Raj__> Good morning everybody, I am Raj from Openstream and am participating from Multimodal Interaction WG today

<Raj__> Dave May I request the screen-share on webex, the camera view is not clear enough to read thanks

<yingying> Joerg: the afternoon session agenda.

<yingying> ... let have the reports of morning breakout session.

<yingying> Chair: Joerg Heuer

<yingying> scribe: yingying

Johannes: 1st topic is Ari's RESTful presentation.

2st: the technology landscape mapping will be done by some volunteers by this year. Thanks for the volunteers.

3rd: we will have a temporary freeze to wiki and move to Github. We discussed which documents should be actively maintained and which ones should be archived.

4th: Implementer's experiences and feedback

Suomya: Helena made a presentation on Discovery and registration of multimodal components distributed on the Web of Things .
... discussion on provisioning: which kind of devices could be supported.

Joerg: how to proceed on the landscape document?

Suomya: @@@@@1

<Soumya> Soumya: Proposes to take it up in the next webex call

Sebastian: reported the discussion on the TD breakout session.
... Feadback of the Plugfest.
... now we have only RESTful supported TD.

Joerg: simple kind of interaction is proposed, not the same TD.

Dave: Did you put the minutes to wiki?

Sebastian: yes. but not finished.
... some discussion is about how we are able to make the TD to be machine readable.
... another topic we need to consider is that thing can be changed over time.

Security breakout report.

James: we took a look at the existing tech to see if they work on the WoT. If not, what we need to do.
... next step, to work with other TFs to fresh out the details.
... considering to do the demostration on next plugfest.

Oliver: give examples of white spots.

<Oliver> A to Q "what are open points": First don't have a complete list of that by now. Solutions for "Managing the Authorization to Authorize" is kind of open/not addressed. This reflects the "Change of Ownership" use case which tends to have no or naive solutions in the digital world. Next open point is "Things Discovery Authorization". Many existing authorization approaches demand a priori knowledge of the actors that can be handled. Next is APIs for security-enabling

review the Diliverables of the charter

Dave: plenty of work to do already, keep the requirements for open markets grey in the deliverables.

(some discussions on the security / provisioning documentation)

Jeorg: appreciate suggestions on the title of "End to End Security for the End of Things"

work setup in TFs

Joerg: fix time slots. comments?

next F2Fmeetings

1. Jan 26-28, Fance, Eurecom?

2. Apr 12-14, US(MIT?)?

3.July 12-14, Asia?

4. 2016 TPAC Sept 19-23. Lisbon

Joerg: please comment by end of November.

joint meeting IRTF T2T

Karsten: with T2T RG, plugfest might be in scope.

Joerg: need response from T2T side.

Karsten: potential joint meeting July 16/17th in Berlin before IETF96

(some discussion on the time slots of TF meetings)

Joerg: TF meeting restarts on Wed 11th Nov with TD, Thur 12 Nov with S&P

WG Work Item under discussion

Joerg shows the slides of WG Work Item under discussion.

WG work items

2 categories: Thing Description and Scripting API and protocol mapping.

Dave: WG is not a good place to do research. We would pick up some items which are mature enough to do the standardization.

<inserted> subscribenick: kaz

<inserted> scribenick: kaz

kerry: there is already some work on Semantic Sensor Network

tahar: IG charter or WG charter?
... current charter doesn't really mention the semantic side

dsr: the proposal (on the screen) is rather on vocabulary
... IG works on use cases, etc.
... WG does standards
... January meeting will be the one of IG

tahar: nice to have a draft of the WG charter by that time?

joerg: we need not only bullet points but concrete descriptions for a Charter
... important to address issues of you
... when we describe individual topics, great to have volunteers for clarification
... and 3-4 people for reviewers

jonathan: we should consider which companies would implement the expected spec(s)

joerg: those companies who are interested in contribution are candidates?

dsr: we could put ideas on a wiki or a github repo?

joerg: before putting our ideas, should see people's supports

dsr: could ask interested people to sign on a wiki

tahar: starting with a list on wiki would be good
... candidates of companies of possible contribution as well?
... starting with a blank sheet

joerg: as soon as more companies supporting the idea

(WG Work Items)

Grouping of Work Items

* Grouping proposed to verify the contribution to WoT BB

Editing of Work Items Drafts

* Based on GitHub to allow for commenting

* Pick up work items for drafting with 3-4 volunteers

* add a categorie "Supporters" in the WoT WG wiki

* if sufficient support is given by companies also new items are discussed

* deadline dec. 4 for support indication

joerg: we also got agreement on outreach presentation
... happy to share that
... and we need to speed up with communicate with people
... how to interact with external consortia and companies
... present reports in a consistent way
... TF on Communication
... meeting once a month
... how to put as an action?
... communication within an organization
... would see volunteers

dsr: following the success of the Communication TF from the Payments group
... help for talking with external organizations
... can do blogging, tweeting, etc.
... we W3C staff (Dave, Yingying, Kaz) work with you
... maybe we could volunteers for, e.g., messages in Japanese
... doesn't have too engineers
... please see who would fit for this TF within your companies

ari: outreach?

dsr: there is a log list of organizations

ah, it seems there is some problem with RRSAgent

joerg: would make sense to have regular meetings once a month to follow up

soumya: we're active in the semantics area
... could liaise with organizations
... ETSI will have a workshop
... could establish official relationship
... IEEE could be another possibility

dsr: not only international organizations but also domestic organizations are ok

joerg: please ask Dave about this
... would put an agenda item for the next f2f meeting
... pretty much end of the agenda now
... actions for WG perspective
... tx for the W3C Team

(Coralie joins for the Comm TF)

koalie: interested in the Comm TF work
... Karen and I are working on messaging by the W3C Comm Team
... would help your TF
... keep in touch regularly
... we'd attempt to see if it would work

joerg: had been talking about the TF
... we were rather concentrating on the technology side
... but IoT scenario is active outside W3C as well
... there was a proposal to create a TF for communication purposes
... regular calls once a month
... your participation is welcome

koalie: sounds reasonable
... same timezone (France and Germany)
... thanks!

[ adjourned ]