Day 1

<inserted> scribenick: sebastian

Workshop Summary

Spreadsheet including 200 suggestions and meta-categories

Jeff: we should clarify what we do the prioritization for

McCool: we sould figure out based on the categories
... <shows the excel sheet>
... there is a speaker, topic, priority/interest, and category column
... present the topics of Dom's talk: smart product, web id, tracking and tracing, bridge things

Sebastian: for me belongs to the category passiv things since there was other talks

McCool: seamless IT integration is about IT integration

Sebastian: <hard to take minutes; please see the spreadsheet>

Taki: we missed a topic about the data format
... such as CSV, ASN.1

there we some discussion about the Xiaowei presentation

it should be evaluated if there is some liaison possible

McCool: proposal to move the charter discussion to the afternoon
... we should finish day 2 list and assign the categories

WG Charter

Spreadsheet including 200 suggestions and meta-categories

<kaz> maintenance work and new spec work

Jeff and McCool have some discussion about the process to setup the new charter

Jeff: wondering about the issues with Mozilla and how is this involved in the charter

Matthias: gives some ideas what have to be extended in the Thing Descriptions
... e.g., include more default values

McCool: prefer to have seperate spec with a guidance

Jeff: whould also the other requirements be fulfilled such as from BMW

talking now about the length of the charter

there is the plan to have charter running 2 years

Jeff: typically it is 2 years, however, can be also longer
... talks about stakeholders which just see topics that are addressed in the IG

Kaz made a proposal to sort topics in a table with a maintain and new column

scribe: and incubation

<kaz and Michael McCool add the topics in the table on the whiteboard>

there is some discussion about the TD spec. version

there are some discussion about proxy usage. Some implementations (e.g., from Panasonic) uses proxys

Taki: the architecture should be also updated regarding use cases.

there is also need to have Architecture 1.1

there was some short discussion about complex things

this is actually already addressed by the current TD spec

however, we need more explaination about it

Michael McCoo brings up the topic about marketing

<Zakim> dape, you wanted to split up scripting API

Daniel: my take away from yesterday discussion is about splitting up the scription API

there are some discussion to catch up more member via the community group

the table on the whiteboard is still quite fuzzy (picture will be shared).

However, we will provide the results in a slide to make the topics and their assignments more clear (e.g., which topics belongs to TD 1.1, 1.1+, Architecture 1.1 etc)

there are some discussions about the profile approache

talking now about marketing

Michael McCool writes down three columns: Visibility, user outreache, vendor outreach

<taki1> scribe: TK

<inserted> scribenick: taki1

McCool: documents for customers and developers
... Getting started for developers
... and advanced use cases for devlopers
... exts and hypermedia use cases

Matthias: Tutorials and so on. Who will do those?

Jeff: This is IG matter.
... WG leaders need to reach out architects.
... IG people need to reach out people in companies.

Matthias: Getting started documents are necessary for open source developers

McCool: Who? Marketing CG / TF in IG
... Recruiting. Why is this group so small? WHat is the problem?

Jeff: Other groups started top-down.
... Executive-to-Executive contacts
... Executives from WoT WG (Panasonic, Hitachi, Fujitsu, etc.) can get together.
... each member can talk to executive and tell that it is time for WoT initiative.

McCool: next, customer outreach and vendor outreach.
... should we schedule meeting with vendors? How does that happen?

Jeff: need to decide on main targets

McCool: need to recruit BDs internally
... We need one pager collateral.
... collateral for customer and collateral for developers
... customers documemt organization should be easy to understand

Jeff: POC is part of plan?

McCool: yes, as part of developer outreach.
... there are both PoC at scale and small POCs.
... We need a group to coordinate marketing.
... we will find what we need, and then tell you Jeff.

Back to spreadsheet work on topics categorization

Spreadsheet including 200 suggestions and meta-categories

McCool: done.
... We categorized topics.
... and sorted.
... we are going to priotize.

<kaz> [lunch till 13:30]

McCool: read all properties test fails.
... need to discuss scope.
... I updated test results
... I paste a rendered version.

<McCool_> latest test report: https://cdn.statically.io/gh/mmccool/wot-thing-description/master/testing/report.html?env=dev

McCool: We should take a look at it to see if there are any suspicious ones.
... based on categories, let's boil down.
... number of mentions is informative.

Matthias: identify what each category is.

McCool: and priority of categories

Matthias: we may lost small important ones.

McCool: data, data format, ...
... data/semantics is two things.
... market/BZ is a sub-category.
... data format is about extra-format. data schema is about a way to describe data.

Matthias: they are different.
... data model is semantics and structure.

McCool: semantics include ontologies.
... "data" is too vague
... "data model" is better.
... ingestion is a use case.
... use case is a superclass.
... "/" is super-sub class.
... we need "use case/smart cities" etc.
... likewise we need "semantics/behaviour", etc.
... any susggestions?

Matthias: we got good overview in our head.
... we should distill further.
... considering timeline. 1.1, 2.0, etc.

McCool: Digital Twin was not discussed in 1.1, 2.0 discussion. We should identify those.
... "arcitecture" is a super category.

Matthias: "discovery" can be a meta category.

Ege: What is not architecture?

McCool: components
... customer engagement
... Human Factor is a meta category.
... Lagally talked about human-readable meta-data
... hypermedia is related action/event description

Matthias: complex interaction. hypermedia may solve it. We need to show this to Mozilla.

McCool: Business dev, customer engagement, etc. are marketing
... data* (e.g. data format) are in Data meta category.
... we need to delete data/semantics
... Digital Twin is more like cloud service.

Matthias: platform product.
... can be architecture.

McCool: component in architecture.

Matthias: with Digital Twin, easy to on board a device.
... relation of Digital Twin to Thing?

McCool: it includes simulation of behaviour.

Matthias: we need to understand use cases.

McCool: category use cases, smart city is different from digital twin.

Matthias: I propose to also add Architecture/Digital Twin.

McCool: let's put it in two categories.
... similarly gateway.
... it can be architecture and use case.
... identification.
... privacy/id, passive objects were discussed for identification.

Matthias: identification and management relates.

McCool: identity is security.
... next implementation.

Matthias: it is a top category.

McCool: it is a meta category.

Matthias: related also to marketing.

McCool: let's have super class "marketing"

Matthias: IT integration is architecture

McCool: Liaison next
... like connexus at workshop this time.
... Location next.
... We don't have this feature. Desirable to have.
... How about to have tag for location.
... location is use case for now
... management next

Matthias: management/directory. directory can also belong to discovery at the same time.

McCool: Passive thing next
... this is a use case.
... Privacy next. is a security.
... Profiles. this is Mozilla thing.
... is Plug&Play category.
... property graph next is data.
... Protocols next, is itself super category? Or, liaison?
... Reliability next. In IIC, they call it trustworthy's part.
... We can mention safety too.

Matthias: redundancy can be mentioned too.

McCool: related to privacy and security

Matthias: we need use case.

McCool: there are Industrial use cases.
... scripting API next, is for building applications.
... manageability is also about building applications.
... behaviour can be super class.
... packaging belongs to behaviour.

Sebastian: victor's presentation was about semantics of scripts.

McCool: behaviour is a super class. packaging belongs to it.
... scripting API is also behavious

Matthias: management was a meta-category.

McCool: ok. packaging, etc. are management, then.

Ege: semantics relates to many things.

McCool: synchronization, next. is it architecture?
... packaging is management.

Matthias: scripting API, should be top-level.

McCool: semantics can be top-level category.
... synchronization. is it use case?

Matthias: monolythic synchronization, TD update, etc.

McCool: synchronization then is management,
... Validation next.
... validation of data. so it is data.

Kaz: there are 14 top-categories in all.

Matthias: we can discuss what those top-categories are.
... architecture, for example. Gateway, for example, has use cases.
... architecture can be discussed with use cases.

McCool: we can treat architecture as priority 0
... security is also priority 0
... architecture and security are MUST HAVE. all agree?
... Data and management, I give it 1.
... smaller number has lower priority
... data is 10
... complex interaction is of high priority.
... discovery 5.
... human factors. we need to address accessibility issues.
... lower than discovery. higher than management.
... liaison is for getting other SDOs on board.

Matthias: 8.

McCool: Complex interaction, give it 11.
... Plug and Play. is for getting mozilla on board. 12.
... Protocols. 6.
... Scripting API. we incubate first.

Matthias: we have reference implementation. 4

McCool: semantics is about extension.

Matthias: it takes time.

McCool: low priority given timeline consideration.
... demote human factor to 2
... use case. 9.
... marketing. 7.
... let's sort now.
... timeline. incubate, immediate, soon. we can have those three

Ege: use case depends on marketing

McCool: timeline - incubation, 1.1 and 1.2
... Plug&Play and Complex interaction are for 1.1

Matthias is showing charter discussion slide...

Matthias: WG charter. maintenance, alignment topics such as Plug&Play, and 2.0.
... for maintenance, security OAuth needs to be defined.
... link relation types is also maintenance
... extension point is already available.

McCool: default values is for maintenance.

Matthias: refactoring is also for maintenance.
... Arch use cases should be updated for new stuff.
... 1.1 new topics. Profile for Plug&Play.
... Implementation view spec. This is for "Web Thing API"-like.

McCool: P&P is about gateway.
... it is about Limit TD for out-of-box onboarding.

Matthias: 1.1 only includes things we already know exactly what to do.
... I have some idea babout complex interactions. similar to HATEAOS.
... Observe defaults?
... you need two forms. therefore you cannot use defaults.

Matthias adds "method" and "subprotocol" to observe defaults...

Matthias: Protocol vocabulary for CoAP and MQTT is in 1.1.

Sebastian: MQTT is OASIS spec.

McCool: We need to get in touch with them.

Matthias: we can work in parallel on 1.1 and 2.0.

McCool: MQTT can be moved to 2.0 spec.

Matthias: Incubation items are for IG.

McCool: industrial protocols can be in 2.0 spec.
... we need modest goals.
... we can recharter if necessary.

Matthias: Thing template is in 2.0 list since Oracle is pushing for it.

McCool talks about how to identify profiles...

Toru: 2.0 spec is subject to incubation.

Matthias: exploration items are first done in IG, then hand over to WG.

McCool: can we add deliverables in charter later?

Kaz: normative, then recharter.

Toru: we should describe what will be deliverable in WG charter.

McCool: we need to cover XML, CBOR, etc. in CG.
... define and maintain data schema. where does it belong to?
... can we get JSON Schema community get onboard?
... it does not have to have it in our charter. There is a risk of diversion.
... Liaisons for 1.0/1.1 incubation in IG. add JSON schema dependency.

Matthias: CoAP is RFC.

McCool: we need to define vocabulary.

Matthias added OASIS for MQTT...

Matthias: marketing items are independent of versions.
... rockstars for events, this is new.

McCool: we need budget.

Matthias: testbeds are marketing platform.

McCool: proof of concepts is important.
... we need "documentation" under outreach.

Matthias: industrial protocols incubation. (OPC UA, modbus, etc.)
... Gateway?

McCool: it is smart home.

Matsukura: gateway is a big issue for IT vendors.
... high cost involved.
... existing devices are old.
... gateways are important in initial phase.
... gateway includes Plug and play.

Matthias: is it use case?

Matsukura: Gateway is entrance to WoT.
... for example, econet.
... in agriculture is Gateway is a necessary entity.
... existing system has management capability.
... IoT management is separate.
... virtual device is converted in gateway.
... gateway is the boundary.

Matthias: gateway is a solution for you in your use case.
... what is management? what is requirement? should be discussed.

McCool: we should discuss the requirements for gateway.

Matthias: gateways belongs to use cases.

McCool: smart cities and gateway are different in nature.

Matthias: TD modularization?

Sebastian: is it not about templates?

McCool: Scripting API split into consumer and thing. This is for 1.0/1.1 incubation.

Matthias: 2.0 exploration.
... Web Thing Protocol. Single connection. We can evaluate it.

McCool: we should move to testing discussion now.

Testing

<kaz> Testing issues

<inserted> scribenick: Hassib

McCool lets go through the validation results

McCool: we need to get rid of all the red boxes, yellow ones at at risk
... : at risk items can be dropped, but non at risk items MUST be completed.
... : Some of these issues might need to be retired after Ege updated the tests

Matthias: can we go through the table to see if something needs work and what the approach should be

McCool: I have added information to a github issue about uriVariables

Ege: there 2 issues related to this, but my test say both pass

McCool: I will comment to say that this is done
... : this is not an issue, moving on.
... : td-schema-schema is a broad superclass
... : updating the comment for dataSchema features issue
... : intel will generate examples for this

next issue: data-schema-format

mcCool: we have only one example apparently
... need an example from another source than siemens (siemens already has one)

Sebastian K. : I will take care of this

next issue: maxItems

Ege: there is a bug that doesnt show up and there is implementation missing
... : it shows 0, but it should show 1. but we still need the second

McCool: Adds comment about this on github issue

<McCool_> https://cdn.statically.io/gh/mmccool/wot-thing-description/master/testing/report.html?env=dev

next issue: td-data-schema type

McCool: some one made a mistake here, we need to fix it

next-issue: td-data-schema unit

Ege: one second. I found out the failure and its in code by intel

McCool: ok, meanwhile. sebastian, is Siemens using unit ?

Sebastian: yes

Matthias: Could you check if there is a mistake there ?

McCool: Ok now that this is done, lets move to td-default-http defaults
... : The issue is that if you dont include something it should be assumed as the default. these tests should be manual and not appear here
... : I will move them out

next issue down in the automatic assertions table: td-event-names

McCool: we have only one implementation in here, need one more.

td-event description: one is missing here to.

McCool: similar problem for titles

Sebastian: Assign this to siemens

Ege: if you have titles or descriptions (lang.) all of them have to have same set of tags

Matthias: about td-event-names uriVariables, I think this might not belong here

McCool: make an issue for this

Ege: uriVariables are also in some other places. but in events there is an implementation by panasonic.

McCool: creates new issue on github to add a way to supress output lines in implementation report
... is the issue for titles and descriptions also the same for interactions ?

Ege: No sebastian took care of this

next issue

Matthias: ye should add a test; are you using your json parser or the recommended one?

next issue: td-property-names_const

Ege: there is on that passes this. its from siemens

next issue: td-property-names_format

Ege: all these test are done anyway in other places.

McCool: we can remove this and we still know it passes as it is part of json schema

Matthias: these seems like extra lines that can be supressed since the test is already done somewhere else

McCool: I will supress this. ill add it to an existing issue supression

next issue: td-security-bearer-format-extentions

McCool: my opinion is that an exemple would be enough here. no need to implement because its for the future.
... : an example that passes validation should be enough

Matthias: Could you assign Viktor to do this example ?

McCool: the example can be really simple, no need for a complex one

<kaz> ACTION: kaz to talk with Ralph about how to handle the assertion for "Other formats and algorithms for bearer tokens MAY be specified in vocabulary extensions."

<trackbot> Created ACTION-175 - Talk with ralph about how to handle the assertion for "other formats and algorithms for bearer tokens may be specified in vocabulary extensions." [on Kazuyuki Ashimura - due 2019-06-13].

Sebastian: I will talk with viktor about this to explain more

next issue: td-security-oauth2

this can not be implemented in the time frame

McCool: the problem is, some of the things described in the td are needed and some are not. So we can reduce this feature / section by removing some not mandatory stuff
... we should change flow to a string with the possibility of extension

next issue: td-titles-descriptions

McCool: this might be a testing error. I remember having TDs that pass this, so it cant be zero

Ege: I remember some siemens implementations failing this

McCool: Ege, could you check if this a testing problem ?

Ege: its probably a testing issue. I will create a github issue

next issue: td-vocab-anchor--Link

Matthias: I will do one implementation for this, maybe intel can do the other one ?

McCool: alright, i'll do one

next issue: td-vocab-contentCoding--Form

Matthias: this is a may right ?

McCool: I will update the highlighting. Assign an issue to me an i will fix it.

next issue: td-vocab-format--dataSchema

Sebastian: I already updated this and it should be fine

<inserted> scribenick: kaz

next BearerSecurityScheme

panasonic will add implementation for bearer token

intel will work on digest

Matthias: edits issue 750

Issue 750

next td-vocab-op--***

McCool: we need one more implementation
... I can do it

Ege: there is unobserveproperty as well

McCool: Sebastian, you implemented unobserveproperty for node-wot?

Sebastian: I have another implementation than node-wot
... JavaScript-based implementation for eventing
... need to look into it
... we have not implemented unsubscribe for MQTT with node-wot yet

McCool: updates issue 747

Issue 747

McCool: assign Issue 747 to Matthias

<McCool_> td-vocab-op--Form_writemultipleproperties

<McCool_> td-vocab-op--Form_readmultipleproperties

<McCool_> td-vocab-op--Form_writeallproperties

McCool: next proxy features
... let's create a TD and check it using node-wot
... let me assign Daniel?

Sebastian: also Christian
... also myself

McCool: what about non-node-wot producer?
... can do that myself
... next QoP
... doesn't matter
... next OAuth2
... what abotu scopes?
... if Panasonic could handle this, would be enough
... up to you :)
... next
... just one implementation for null
... updates issue 718

Issue 718

McCool: next manual assertions

Matthias: talked with the guys from Bologna Univ.
... maybe could provide an implementation

McCool: goes through other issues
... next language issues

Matthias: node-red runs on web browser

Toumura: could handle language negotiation

McCool: also would get help from Hassib on Arabic language
... wondering about how node-wot handles it
... shows an example
... tests/2019-05/inputs/intel/intel-camera.jsonld

Kaz: even web browsers need to use CSS Writing Modes extension to handle this correctly

Matthias: how do you feel about node-red, Toumura-san?
... you can prepend/append additional HTML codes

McCool: next
... HTTP method

Matthias: manual tests on default values

McCool: in the worst case, would work on four values
... goes through other default values

Matthias: maybe we could ask Victor as well

McCool: next
... byte order things
... next
... language negotiation
... end of the issues :)

Day 2

<taki> Scribe: TK

<taki> scribenick: taki

Testing (continued)

McCool: missing quote caused crash
... I fixed that
... results is much better
... still lots of manual items
... noticed smartthings uses semantic annotation.

McCool shows implementation report...

McCool: still have "scopes" at risk
... event name is an issue.

McCool is editing supression list...

McCool adding event/action names to supression list...

Matthias: action/event name urivariables items should also be suppressed

McCool: no semantic tags for security scheme.
... I will do it myself.

Matthias: at risk items. if we remove them, do they still show up in implementation report?

Kaz: good question
... we can keep them for transition request, and can remove them later if needed

McCool: we are clean except for a couple of issues.
... OAuth stuff, we still need implenentation.

Matthias and McCool discuss bearer token aasertion...

McCool: Manual assertions next.
... issue #751. implemented, and closed.

<inserted> Issue 737

McCool: #737. manual validation for IANA requirements.

<inserted> Issue 751

McCool: still need to manually validate.
... #737. we need volunteers.
... Daniel and Toumura-san volunteered.
... language direction stuff.

<inserted> Issue 741

McCool: #741

<inserted> Issue 743

Ege: #743 is about automated test.
... they are done.
... bearer format extension and oauth are also auto tested.

<inserted> Issue 738

McCool: #738. text direction assertions. needs update.
... one implementation is working. which implementation, I do not know.

Matthias: we should not close issues when it does not show up in the result.

McCool: first strong rule based on scripts.

Toumura: I used "auto", not "LTR".
... I commented in #738

McCool: good.
... if there is @language, we can use that to guess direction.
... three language database is enough.
... if the language can be written in more than one directions, language must contain script subtag.
... I could not find this in modern language.

<kaz> fyi, IANA Language Subtag Registry

McCool: I can assert manually.

Matthias explains algorithms for this...

McCool: I can take care of the last one in #738.
... Toumura-san to implement inference by language in Node-Red.
... still need implementation for the first two.
... Intel to update proxy to render HTML landing page in a way to satisfy two assertions.

Kaz: How can Node-Red know this?
... from input in TD?

Matthias: TD contains language tag.

McCool: we need a database.

Kaz: we should talk with Richard Ishida.

McCool: I still need to implement inference.

Kaz: browser usually css writing mode capability.

McCool: Node-Red does not have support that.
... if we inference correctly, we are done.

<kaz> ACTION: kaz to talk with r12a about the language tag issue

<trackbot> Created ACTION-176 - Talk with r12a about the language tag issue [on Kazuyuki Ashimura - due 2019-06-14].

<inserted> Issue 719

McCool: #719. HTTP method defaults.
... we need second implementation.
... this assertion is for consumers.

Toumura: I handle this in Node-Red.

Yamada: I will add my manual results.

Matthias: I will check that node-wot support them.
... it is in there.

<mkovatsc> for node-wot HTTP defaults see https://github.com/eclipse/thingweb.node-wot/blob/master/packages/binding-http/src/http-client.ts

McCool ediiting siemens-node-wot.csv

<kaz> siemens-node-wot.csv

McCool: td default in basic, td default in digest. Toumura-san, please assert those.

Toumura: already supported those.

<kaz> hitachi.csv

McCool: It is just not showing up right in the report.

McCool is investigating this...

McCool: based on code check, those should be marked "pass".
... digest still need confirmation.

McCool editing siemens-node-wot.csv...

McCool: node-wot implments defaults for apikey, bearer and basic.

<inserted> Issue 742

McCool: #742. manual Security assertions.
... content-negotiaion needs two implementatons. I will make one.
... but need one more implementation.

<inserted> Issue 741

McCool editing comment in #741...

McCool: who else implement content-negotiation?

Matthias: I supported on server-side.
... in node-wot.

Toumura: Is this about client side?

McCool: client-server pair would be good.

Toumura: I can add "accept-language" header in requests.

Matthias: It is about negiation behaviour.

McCool: proxy can make both client and server implementations.

McCool assigns to toumura-san and daniel...

McCool: we will come back to this after lunch.
... next topic.

WG Charter (continued)

<inserted> scribenick: ege

Spreadsheet including 200 suggestions and meta-categories

Matthias' slides on Charter topics (member-only)

Matthias: meta categories
... (showing the presentation about the charter)

Matthias: jeff said that a longer charter is better

McCool: some short term but more for the long term charter

Matthias: timelines, IG and WG
... let's start with IG and CG
... long discussion with marketing
... how to make it manageable
... discussed for some new plans
... middle part is more interesting
... new products will bring new requirements
... liaisons are in a shortened form here
... JSON Schema and MQTT with OASIS
... use cases to push into verticals
... there is interest from automotive wg
... several industrial use cases as well
... every member takes this into the field and gains experience
... industrial protocols are mentioned and modularization from bmw
... also scripting api, splitting server/client

Lagally: other languages, python java for scripting?

McCool: difficult case

Matthias: CG for public participation
... Web Thing protocol to have a single connection
... there isn't a protocol who can do it at the moment but maybe coap over ws
... directory for discovery but also peer to peer directory

McCool: IETF liaison

Matthias: it is already in IG Charter
... management is also talked frequently
... managing identities
... but also tracking offline things
... profiles was mentioned but not many profiles that would bring the siloes back
... we need to explore thing templates more and discover the mechanism

Ben: what about server/client discovery

Matthias: this would fall under peer to peer

McCool: what about calling p2p decentralized

Ben: I would like to see industrial protocols and scripting api out of the charter

Matthias: but other members want it
... so now let's see the WG charter
... maintenance is about security schemes, link relation types at IANA, we might need more default values needed, and refactoring
... now about 1.1 New Topics
... we start with Plug&Play as a use case
... so restricting the TD possibilities
... how to start with Web of Things, how to build from scratch

McCool: also what is the recommended security mechanism

Matthias: also error handling
... so new implementations would send the same error messages

Lagally: what about maintenance of node-wot

Matthias: this is an implementation, you can contribute to the Eclipse Thingweb project to contribute to it

McCool: it would be good to have node-wot since it is a strong reference implementation

Kaz: let's change maintenance to specification maintenance to be clear that it is not about implementation maintenance

Matthias: now complex interactions
... how to cancel actions
... also how to specifing default values for observe

Ben: also reading the past events

Ege: but that is about complex interactions

McCool: we want to not remove the open versions

Ben: yes that is what I meant in the email

Lagally: what about the other profiles?

McCool: we want to limit in 1.1 to plug&play

Lagally: another problem is complex interactions, maybe interaction model fits more
... or action model

Ege: but it is also events

Lagally: then let's add events

Zoltan: what about streaming

Matthias: events already provide time series

<benfrancis> ege: (thanks for scribing). Just for the meeting minutes, it is "non-web protocols", not "industrial protocols" that I suggested should be out of scope.

Matthias: we can't fix the deterministic networking
... you can have best effort streaming

Ben: we have actually implemented it

Kaz: NHK is also interested, they have just joined the IG

McCool: also discovery should be same in IG and WG

Lagally: we need templates right away

McCool: there is already a note in the spec

Lagally: for oracle templates is a high priority

Matthias: can you find another member to work on template

Lagally: then yes I will ask individual members

Matthias: I think the priority for many members is the plug&play
... also make sure that templates follow the spec
... also observeproperty can be in 2.0

McCool: I find it important
... we need to decide which features go into it

Ben: does the charter require this "tightness", can it be more flexible

McCool: some can be in flexible but deliverables are documents

Kaz: maybe we should say short term and long term more clearly instead of 1.1 and 2.0

Matthias: some of these will influence the TD document

Lagally: splitting the documents?

McCool: I don't know if it helps

Matthias: now I don't know if I am satisfied with the 2.0 cut from 1.1
... all of the topics in 2.0 are wished asap by some people, none are really clearly 2.0

McCool: 2.0 are things that are not blocking

Lagally: taking a step back to see the timeline
... there are items that depend on each other

Matthias: complex interactions is endless

Kaz: let's check that the list is ok for everybody

Zoltan: where is scripting

Matthias: in IG

RESOLUTION: Everyone is OK with the topics for the new WG Charter

Matthias: ideally we would like to see Mozilla on WG
... probably you will need the document before going throuhgh

Ben: yes

TPAC

McCool: what do we want to have in TPAC?
... hotel is super expensive, so watch out
... maybe another location for plugfest/hackathon

Ege: hackathon is for people without much experience and plugfest is for ones with experience

McCool: timeline - would be good to have 1.1 from the charter
... we can add 1.5 and remove it if we need to

Lagally: let's not add complexity

(now we are making a timeline on the whiteboard. I will try to write it here but in the end we will take a picture of it and communicate it)

(now writing dependencies between work items in order to put a priority)

Matthias: implementation view means writing how one should implement a Thing. This results in having a profile since that implementation will be "fixed" and create a profile

Ben: just for info, amazon has a rest api and also mqtt and also mqtt over ws

Matthias: rest assumptions are valid for coap or if you transfer it over websockets

McCool: we will need a liaison for mqtt and coap

Matthias: for coap we dont

Lagally: what happened to csv data type?

McCool: it belongs to data schema

(dependency list is done but there is discussion on it)

(plug and play seems to be running for the first position)

Implementation report

<kaz> scribenick: kawaguch

McCool: Please download implementation report locally.
... Everything is up-to-date
... on GitHub
... Make a quick scan on IR.
... (Scanning implementation report at risk portion)
... Need to discuss ambiguity on title and titles

<benfrancis> kaz: OK, thanks

McCool: Unimplemented ops have plan on issue tracker, but need one more implementation each
... PSK only has one implementation
... Dataschema null is also at risk
... Manual testing
... Language negotiation need some work.
... Please do homework, and update issue tracker.
... Complete by ideally mid of next week, end of the week at latest.
... Publication deadline is 19th, but we need resolution before then.

Taki: What happened to penetration test?

McCool: Ideally, but not yet.
... We have a plan to merge to Security guideline.
... We need security expert to read our report and give feedback.
... We are trying to get feedback for normative documents.

McCool: Possible solution is put texts on security consideration document.

Sebastian: Homework assignment?

McCool: Issue tracker has assignments.

Matthias: Some have nobody assigned.

McCool: qop, proxy need some assignments.
... #734 is actually done.
... PSK, Oauth is also at risk.
... Smartthing has psk implemented.
... Assign Daniel to check PSK on Node-WoT.
... See #733
... Proxy authentication next highest priority.
... We have zero implementation for now.
... But Node-WoT implements reverse proxy.
... Intel would implement forward proxy.
... Oauth2
... Intel will create text limiting to code flow.
... Then Panasonic will implement.

Lagally: Priority on issues?

McCool: At the moment no.

???: What can security extension can do?

McCool: Assign extra name space and give prefix.
... In 1.1 these prefix can be removed.
... Another fix is to remove redundancy.

Other issues on documentation.

McCool: Architecture Spec has "by PR transition" Tag on GitHub issues.

Lagally: Please make PR for them.

McCool: When can we merge PRs?

Lagally: By Wednesday.

<kaz> TD Issues

McCool: How about security review?

<kaz> Architecture Issues

Matthias: What are the different aspect of Web of Things?

<inserted> Issue 207|

McCool: #207 is assigned to Michael Lagally
... #350 Post CR editorial fixes is also assigned to Michael.
... For Thing Description, Sebastian would check.
... For Security consideration I will check.

[Photo session]

TPAC

McCool: Plugfest on Monday and Tuesday?
... Hotel at venue is expensive.

Matthias: Takeshi could provide logistic info.

Sebastian: We would not need plugfest this time.

<kaz> TPAC page

<kaz> registration reminder (member-only)

Sebastian: Maybe we would have demo on Wednesday.

Matthias: Short preparation for Wednesday demo should be okay.
... We are starting over on new topics.

McCool: We can have a small booth with poster and small set of things demo.
... Take Monday and Tuesday small demo team.

Ege: How about having one hour hands on session?

McCool: Monday night we have developers' meeting.

<kaz> TPAC Schedule

McCool: Not sure hackerthon setup works.
... Main deliverable is clear poster.

Kaz: So far we have not secured any room on Monday and Tuesday.

McCool: One table should be enough.

Matthias: In Lyon we had a table to demonstrate.

Kaz: This time venue is a hotel so situation is different.

McCool: How about using a guest room of the hotel?

<kaz> ACTION: kaz to talk with Naomi about demo prep on Mon/Tue

<trackbot> Created ACTION-177 - Talk with naomi about demo prep on mon/tue [on Kazuyuki Ashimura - due 2019-06-14].

Sebastian: Having at Panasonic?

Taki: Not so close to the venue.

McCool: Anyway we agree to have a small demo rather than Plugfest.

Kaz: Will check with Naomi whether we have a space at the venue or not.
... The end of early bird of TPAC registration is approaching.
... So please get registered.

McCool: Would be nice to have another hotel recommendation so we can move together.

Sebastian: joint meeting with automotive?

<inserted> kaz: it seems automotive wg will not meet during tpac...

McCool: Yes, and json-ld, iotschema.org, etc.
... Spacial data WG also.
... One another liaison topic is accessibility.
... Came up at Workshop.

Kaz: We can list up for all possible candidate liaisons.

Matthias: I can go to meet with internationalization.

Kaz: Media and Entertainment WG on Monday.
... If we do demo preparation on Monday and Tuesday you have to pay registration fee for those days.
... De-centralized Identifier WG will also meet on Thursday afternoon.

McCool: Clarifying HTTPS local use case is also important.

Kaz: AC meeting will be held
... on Tuesday and Thursday afternoon.

McCool: We have 4 chair candidates.
... for IG and WG with overwrapping chairs.

Matthias: IG and WG chairs don't need to be the same.

McCool: We could still have other nomination.

Sebastian: How about Japanese company?

McCool: IG need earlier decision, WG could be more later.

Comments from Michael Lagally

Lagally: A good stuff made in Germany!

McCool: Finished.