<kaz> scribenick: kaz

<scribe> scribe: kaz

yonging: checking the agenda items
... WG Charter status, F2F logistics, OCF liaison
... OCF data modeling next week
... TD and Security

WG Charter status

mm: sent this updated draft Charter PDF to the group

-> https://lists.w3.org/Archives/Public/public-wot-ig/2016Nov/att-0056/wot-wg-2016.pdf Michael's compiled updated draft Charter

mm: updated the Charter according to the AC Comments
... based on the pull requests

-> https://github.com/w3c/wot/pulls pull requests

mm: if you have comments we can include them as well
... (going through the Charter)
... changed the introduction
... "emerging standards"
... (go to "2. Scope")
... put out "triples" from the sentence in 2.1
... added explicit sentence on how TD works

[[
The Working Group will develop solutions to describe Things through metadata and declarations of their capabilities (e.g., possible interactions). This work includes the definition of different machine­understandable vocabulary sets as well as serialization formats of such a Thing Description. The Thing Description will be aimed at enabling scalable and automated tooling, including but not limited to search, automated bridging, service composition, validation, and development abstractions.While enabling the use of powerful tooling, the Thing Description will be designed in such a way that even constrained devices can use it. In particular, for basic usages there will not be an explicit dependence on RDF and it will not be necessary for constrained systems to perform explicit semantic processing. However, to enable more complex usages, the Thing Description will include extension points to allow the use of semantic vocabularies and tools (e.g., Linked Open Data, Schema.org, Resource Description Framework (RDF), semantic reasoners, etc.).
]]

mm: updated the text in right above "2.2 Scripting API" by removing redundant text
... changed the title of "Protocol Binding" to "Binding Templates"
... for section 2.3
... and "2.4 Security and Privacy"
... modified the text
... (going to "3.2 Informative Specifications"
... )
... WoT Binding Templates now informative

kaz: Scripting API is normative and Binding Template is informative. right?

mm: yes

yz: when will we publish this Charter?

mm: this is a draft Charter
... think it's would be OK

kaz: right. we don't need to specify concrete date here in this draft
... after getting the final conclusion, we can put the date later
... our expectation is finalizing the procedure by the end of the year

F2F Logistics

mm: would input from Ryan and Koster
... the estimated cost is 13,000 USD

<rrware> $13,500

mm: to rent a hotel, e.g., Crowne Praza

rw: any feedback, McCool?

mm: not yet

rw: please poke them again

mm: when is the deadline?

rw: within next couple of weeks
... can you ping them?

mm: will do
... Koster, any response from Samsung?

mk: not yet
... let me try another inquiry

yz: the venue is not fixed?

mm: we have issues on security to hold the meeting at our own facilities
... the venue should be a hotel
... let me ask withing Intel
... will send an email back

OCF Liaison

<rrware> https://github.com/ware/wot/blob/security-tf-docs/TF-Security/Charter.md Security TF Charter

mm: thinking about it
... would call for volunteers
... me, Michael Koster, Yongjing
... so far
... would have a meeting

Security

rw: One question
... relationship between the security tf and the IG/WG
... report back to both of the groups?

yz: my understanding is TFs should report back to the group

kaz: probably the security tf should be the joint tf of the IG and the WG
... but you could start the TF as a sub group of the IG first
... and report back to this main IG call like TD and Scripting

rw: ok. that makes sense
... (shows github page)

rw: the scope
... Review of WoT related specifications for specific security relevant properties.
... review of use cases
... security test plans
... suggested test plans for implementations

mm: implementations match standards
... want W3C do that
... recommending test plans rather than implementing them

rw: agree

mm: the WG should recommend test plans

rw: pull request on scope
... lifecycle, e.g., shipping
... questions?

mm: use cases everywhere in the lifecycle
... need security consideration

yz: wondering what "the tf would provide some test plan" means?
... interoperable tests? conformance tests?

rw: types of tests
... validate the spec is robust against attacks

yz: define some test cases?

rw: yes

kaz: the TF will help the WG generate test suites for the CR stage

rw: right

mm: regarding the "Deliverables", the TF generates recommendation for test suites
... conformance tests goes into test suite

rw: not produce WG deliverables themselves but (help) generate test suite
... and review test suite
... "Relationships to External Gorups"
... W3C Security Activity
... WoT WG, IG
... CG
... Automotive WG
... Web Security IG
... Web Application Security WG

mm: listing groups but those are just examples

ari: external groups should include IETF?

rw: having liaison?

kaz: we should make this section into (1) W3C groups and (2) external groups
... and could include IETF into #2
... and we should include Device and Sensors WG into #1

rw: ok
... next "Participation"
... "Additionally, ..." will be changed to "Additionally, recognized security experts..."
... next "Communication"

mm: a typo here

(teleconfrences->teleconferences)

rw: btw, we should have a patent policy section

mm: for this security work or the WG in general?

rw: for this security tf

kaz: regarding the patent policy, there is a W3C Patent Policy
... and we can refer to that
... that is related to W3C WG deliverables
... IG can generate just IG Notes

dsr: given there could be people who would join only IG and not WG, we should clarify the TF would work on informative work

kaz: the scope and the deliverables of this TF is generating (informative) test suite and reviewing test suite, probably there would be no problem

TD Restructure update

<kaz> TD minutes

sk: held a call today
... talked about pull requests for the draft WG Charter
... and then discussed streaming and compound values proposal by Dave
... server-sent events of HTML5
... and then discussion on representation format
... should stuck with JSON-LD or not
... more restricted version?
... and then the status of the Current Practices document
... would update the document by the end of Nov.
... Daniel's pull request on Media Type
... the next meeting will be held next Wednesday at 8pm CET

yz: question on JSON-LD discussion
... any conclusion?

sk: not yet
... invited the JSON-LD expert as well
... talked about the next version of the spec
... maybe it would not match our WoT work if wait for the Ver. 2 version
... we should consider other serialization including C language
... standardize TD should be independent from specific technologies
... we could have our own light-weight JSON-LD
... which would better fit with developers' need
... need to think about what would be the right direction
... based on the preference of the group

mm: sorry couldn't join the call
... ideally should be subset of RDF technology and semantic web
... we should r
... leverage existing technologies

sk: the group should set up based on RDF modeling
... challenging task
... JSON-LD is a good compromise
... you have some JSON-like format and can convert it to RDF

mm: changing the way?

yz: not good enough

mm: JSON-LD is a Recommendation
... but there is some restriction
... some blocking point
... could make certain features option and make it compatible with JSON

dsr: pros and cons
... trying to thinking in general is good
... but need simpler way for small devices
... if you want, I can show a demo of translator

mm: maybe next week?

sk: good topic for the next TD call

yz: people may choose the better format based on their need

sk: please join the next TD call :)
... many dependencies on this topic
... will add this to the agenda

Scripting update

<yingying> Scripting minutes

dape: we need to think about constrained devices
... so Johannes invited Ben for Web Assembly discussion
... they want to use a certain API

<kaz> Be's slides

dape: many supports by browsers
... Mozilla, Chrome, etc.
... after that I talked about EXI
... looking at what we can achieve
... EXI for JS can generate efficient data
... would involve Samsung people as well

mm: subset of the functionalities for small devices?

dape: general discussion on what "Small Devices" mean
... we want to look into it

yz: we're looking into several different options?

dape: we're currently working on WebIDL
... in theory could be mapped to any languages
... we need to identify what we should achieve

yz: WebIDl is the basis?

dape: think so
... but WebIDL itself is a generic IDL mechanism

dsr: question for the WG about the language
... second question is what kind of small devices should be handled?
... I think the WoT group should consider very small devices which GWs can't talk with as well

dape: need to define what "small devices" are

dsr: we could have APIs for scripting but interesting to talk with application platforms

mm: good example is beacon and temp sensor
... always those devices are too small to have runtime

dsr: could have some groups of devices
... having some way to talk with small devices would be good

mm: subset of features for small devices would make sense

ari: constrained devices
... there is definition of classes of devices within IETF

mm: know about that
... but need to clarify what could be done by which devices
... devices can change classes

ari: ok. we can do detailed discussion later
... how much functionality should be done by the end point

uday: how we could address class of devices?
... they would need to talk with the GW
... we should keep in mind that "device" could be anything

mm: when/where should we have this discussion?

yz: within the TF call?

mm: would add this to the Scripting agenda
... architecture for restricted devices

[ adjourned ]