<kaz> 1. Lagally
<kaz> 2. Farshid
<kaz> 3. Kaz
<inserted> scribenick: mlagally
McCool walks through the agenda, some small tweaks for gathering, breaks
<McCool> agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
McCool: let's use the IRC channel for chat, not the WebEx chat
McCool: any guests?
... any non W3C members?
<kaz> Dmitrij Lagutin from Aarto University is a guest for today
McCool: please respect W3C patent policy
<kaz> W3C PP
McCool: Dmitrij Lagutin is a guest, his University is a member
<kaz> Nikos Fotiou from AUEB as well
McCool: all, to simplify management,
please give full names when you join WebEx on future
calls
... Logistics: There's a github site with all
presentations
... please put your presentation material to it
<McCool> presentations: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
<inserted> scribenick: kaz
Lagally: use cases questionnaire ongoing
<McCool> use case priority questionnaire
Lagally: there are 15 questions in the
questionnaire
... options on "not interested", "useful, but not business
relevant", "business relevant", "business critical"
... last one (q18: category 17) is proposal for a new possible
use case
... if you have any other ideas for which WoT to be applied,
please put them
... in terms of the deadline, we'll discuss the results on
Thursday during the vF2F
... so please respond by then
<inserted> mm: note that Kaz reported a bug with the TD Recommendation, but the detail to be discussed during the TD session.
scribenick: mlagally
McCool: we'll talk about Discovery later
today after the break
... There was related work in "Lifecycle" and "Use cases"
... DID's will be discussed in depth in discovery
... OAuth2 work is still in progress
... Lfieycle has been discussed extensively, identifier
management is an important topic there
... in architecture there were discussions about agents and
stakeholders, we also used certain terms in security, need to
move over to architecture
... not all use cases have security and privacy considerations
yet, please make sure to include these when creating a new use
case
... "none" is a possible answer, if no security
requirements
McCool: consider a compromised
directory service that has malicious links
... harvests password, e.g. for basic auth
... TLS credentials could help, however changed URLs could
still be used
... need to prevent modifications of TDs, e.g. prevent adding a
proxy
... need to enforce integrity
... ID could contain a hash on the contents of the TD
... alternative way: adding a proof section
... in 1st case a TD change modifies the id
... in 2nd case a proof needs to be regenerated on every
change
<inserted> scribenick: kaz
Lagally: in general, many use cases
assume TDs are static
... some kind of proof section may be useful
McCool: we'll have to calculate the proof again if the TD is regenerated
Lagally: actual signature should be
validated
... don't see how that kind of validation would fit for dynamic
TDs
McCool: directory should be aware of changes of TDs
<inserted> scribenick: mlagally
McCool: updating TDs is complicated,
implications on caching, ...
... this has implicatinos and TDs and architecture
Daniel: in other standards they define canonical XMLs, identifying what can/cannot be changed
McCool: good point, e.g. a directory could add semantic annotations
Ben: there seem some assumptions
in this requirement
... 2 use cases, device or gateway serves TDs
... in these cases signing is not required, since you use
TLS
... This seems to be tied to a directory
McCool: the issue arises if you
redestribute somebody elses TD
... federated directories (e.g. campus use case) and
redistribution use cases
... also comes up for sleeping devices
Kaz: suggest we think about
dedicated use cases for further discussion
... multimodal integration use cases, IP addresses and ids
could be integrated, need to define a scenario
McCool: we should create issues in the use case session, let's discuss on Thursday
McCool: 3 key applications:DIDs as
IDs for TDs
... use DID document as one way for discovery
... we need to formalize types for DIDs, e.g. for discovery
... 3. Key distribution: public keys with referenceable URLs
Lagally: additional stakeholders need to be considered in architecture for this approach
McCool: there's good material in the
DID draft document
... DIDs are not done yet, we need to discuss some aspects
McCool: we had several flows but
removed some of them, only code flow remained
... which Oauth2 flows are required in terms of use cases. Do
we want to include all flows?
... scopes are pretty useful for smart cities, i.e. having a
separate credential system
... Oauth2 depens on Bearer Tokens, in theory all Oauth2 flows
would be supported
... There's also a device flow, we may want to include it. We
need to clarify the "user agent" can also be a simple button on
a device, or a redirect
Ege: user agent could be important
McCool: human interaction is not required, could be machine to machine
Farshid: multiple flow support is important, it is not clear who is involved
McCool: different interactions can
have different security schemes
... need to see which flow to use depends on the context
... code flow is not appropriate for some
Christiano: code flow is
constrained not only to user agent but also resource
owner
... primarily human users
... critical is to know who is the resource owner
McCool: need to define stakeholders,
differentiate between humans and others
... it is easy to add all of Oauth2 to the TD
... since we are descriptive we should not be constraining what
we can describe
scribenick: kaz
Lagally: concur with your view
... it is important to crate user agent for generic purposes, and that reminded me of the TD profile discussion
... what is needed for wide interoperability
... further discussion later this week during the profile session
scribenick: mlagally
McCool: OpenAPI includes all Oauth2 flows, we need to be able to answer why we exlude some.
McCool: New text in Security and
Prvacy guidelines around E2E security
... E2E concept is very vague, i.e. who is the end
consumer
... need to specify the endpoints in the requirements and use
cases
... this leads to various issues with "bridges" in the
architecture
... how to ensure the bridge is trusted
... may need to unpack/modify TDs, perhaps this is permitted
but no payload manipulation
<FarshidT> I will take over as scribe after this presentation.
oliver: need to consider more details about who is the "end" component
McCool: Review Conexxus Security and
Privacy model, they have a threat model we want to
consider/align with. Waiting for a document for review.
... Security review of lifecycle, need to review the final
lifecycle modle
<kaz> [break till 15mins past the hour]
scribenick: FarshidT
McCool: will talk about requirements, design decisions, two-phase arch., key issues. More details about some topics will be covered in Farshid's presentation
McCool: support for remote discovery is necessary
... semantic querying should be supported minimally at least, since we have linked data
... support large repos of things, and p2p (self-identying) discovery
... privacy is a big requirements. Need to ensure user privacy. Distribute TDs only to authenticated and authorized users.
... allow change of IDs
... Align with existing standards to avoid reinventing the wheel
... also, align with WoT scripting API
... link to file collecting requirements: https://github.com/w3c/wot-discovery/blob/master/requirements.md
<inserted> Design document
McCool: only one resolution, i.e. on two-phase architecture
... introduction phase to identify exploration services, exploration phase to get descriptions
... technologies for introduction, DHCP, DNS-SD, DID Documents, QR codes, etc
... exploration: well known location. URL may point at the Thing, the TD, or the directory service
... introduction should be open so it can be consumed with no or limited access controls
... lightweight to not waste computational and networking resources
... resist to DDoS
... exploration meta data should be returned only to authorized users
McCool: two-phase approach not sufficient in all contexts
... depends on the design of API
... need to hide data that can be use to infer personal info
Lagally: need to know if the well-known is also a trusted URL
McCool: DNS may be used for spatial discovery
Lagally: need to generalize. UPnP may be used as an introduction mechanism
... how to know if a TD is for a directory?
McCool: can add some annotation. Directory is not a physical thing, but adding a TD is useful to describe and have a uniform way of interacting similar to other WoT things
Ben: supports describing a directory with a TD
... if directory is a gateway, the gateway is actually a physical thing
McCool: a gateway can support a collection of services
Lagally: do we wanna standardize the directory API?
McCool: we need to formalize the introduction phase. And also the exploration.
Lagally: so we define actions with specific specs for directories?
McCool: agrees
McCool: auth is required
... well known location to get the TD
... light query language to have parameter based filtering
... medium like jsonpath and xpath
... advanced like sparql, graphql
McCool: form of query, support for semantic queries
... describe directory with a TD
... TCP/HTTP baseline protocol
... partial and fragment TDs, implications for JSON-LD
... pagination
... out-of-band data such as system-generated IDs
... notifications for changes to TDs
... links to other open issues on github
Kaz: need to look into concrete use cases for those issues
<kaz> scribenick: kaz
Farshid: what are done so far
... (shows outline)
... current status, naming, jsonpath/xpath, drectory meta info,
paginatio, ns-sd, tds, dircory td
... [current status]
... cataloging
... DNS-SD registration
... RESTful API
... OpenAPI, TD CRUD, catalog, valiation
... [Naming]
... Thing Directory (not to be shorten as "TD" :)
... how to call it to avoid the confusion with "Thing
Description"?
... please consider it
... [JSONPath / XPath]
... filtering and attribution
<zkis> Note to self: to align with Scripting API on names
Farshid: JSON-LD response
... array of TD with original context
... value/object selection
... don't need to use huge query
... but just query on the consumer side
... JSON fragment response as an array
... pros and cons
... pros: short and expressive, passed as URL query parameters,
value selection saves both client and server resources
... cons: fragmented response are not JSON-LD compliant, schema
can get messy, no formal spec (yet)
McCool: injection attack?
... json schema round bracket means arbitrary expression
... potentially run arbitrary code
... but that's not intended here
Farshid: right
McCool: this is a prototype directory
at the moment
... we should discuss what kind of query language to be
used
Farshid: rith
... [directory meta attributes]
... TTL: the validity of TD, the lifetime of TD inside the
directory after registration/update/observation
... approach #1
... add "ttl" attribute to TD specs or extend the context
... read-only meta" in responses, only when requested
... digital proof insde TD based on LD-proofs
... approach #2
... add "ttl" attribute to TD
... define a second resource type
... approach #3
... new resource type for out-of-band information
... LinkSmart's choice is #1
... single resource type
... "ttl inside the TD
... if no "ttl", directory may keep forever or reect
... proof and prof chain based on LD-Proofs draft
... related issue here
... wot-discovery/issues/18, 24 and wot-security/issues/166
Ben: be cautious
... expiry for resources would be complicated
... can see in this example, different TDs have different
resources
Farshid: could see the next
slide
... [pagination]
... if some TD is static, could be very long
... on the other hand, if some TDs are dynamic, could be
smaller and frequent
McCool: push update for dynamic
TDs
... originally TDs are expected as static
... here issue on dynamic TDs as well
Sebastian: handshake issue as well
... something similar to CoAP transfer
... how many/how big data to be transferred?
Farshid: limit comes from the server's
capability
... possible to narrow it down
McCool: technically TDs are
unbound
... one transaction vs unbound ones
... complication to break syntax of LD
Ben: a directory itself has a TD
McCool: you could have a
notification
... also garbage collection
Ben: it's a trade-off
McCool: a person could register a
huge TD
... probably need some mechanism for flood
Zoltan: what about streaming?
Kaz: yeah, we should think about
several concrete points caused by this topic
... e..g, streaming, big data, fragments, sessions, ...
Sebastian: you already implemented pagination?
Farshid: yes
McCool: Hitachi's nodegen approach is one possible use case
Farshid: [DNS-SD type]
... LinkSmart uses _wot._tcp type
... _directory subtype
... TXT record of "version=<api-version>" "td=/td"
... version and API endpoint
McCool: we have to annotate the type using another record
Farshid: yeah
... [TD without ID]
... with TDs with ID
... PUT /td/urn:example:1234
... but with TDs without ID
... POST /td
... response location header:
urn:uuid:0ff82c68-a9dd-4342-91a9-a326b8e2d50
McCool: globally unique ID to be used
here
... query for database
... matches some ID
... we can have difference between globally unique ID and
directory-wide one
Kaz: so "uuid:0ff82c68-a9dd-4342-91a9-a326b8e2d50" is generated by the directory
Farshid: right
Kaz: not globally unique but system-wide?
Farshid: could be globally
unique
... [Directory TD]
... (example TD)
... look at the scope
... OpenID approach as well
McCool: particular OAuth flow should
be also considered
... should create an issue about that
... what you put into the TD and what you get from the
query
Farshid: ok. note the consumer is the
resource owner
... and then go into the actios here
... then tried to validate it
... is TD meant to replace the OpenAPI specs?
... possible issues
... can't define multiple different responses based on HTTP
status codes
... few ways to define the operations: HTTP methods,
interaction affordance subclasses, propertyaffordance
(readonly/writeonly)
McCool: OpenAPIs vs Thing APIs
... do we stick with the directory with Things?
... personally think using TDs would be beneficial for
recursive purposes
Sebastian: we can't replace with
OpenAPI
... that's not our purpose
... TD is independent from any protocols
... another aspect is collaborative discussion with the IRTF
T2TRG
Farshid: understood
... if it's not the intention, that's fine
Ege: we use devices but many of cloud services as well
Ben: there are a lot of
cases
... any kind of affordances to be used
... many cases with TDs
McCool: 2 issues
... 1. we should have discussion on the relationship with
OpenAPI
<Ege> https://github.com/w3c/wot-marketing/issues/66
McCool: 2. also we should have discussion on error codes
Zoltan: we discuss this error mapping
issue during thttps://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-DID-VC-Fotiou.pdfhe scripting calls
... agree with Ben
... we should describe error codes within the TD spec
... need some generic mechanism for error handling
... we need some work with several TFs
McCool: (time check)
... we should move forward to the DID discussion
... and continue this discussion during the TD session
Ege: note that I've submitted some idea to the OpenAPI conf
McCool: let's take a look at that tomorrow
Nikos: (about SOFIE)
... an EU project which enables interoperability among existing
IoT platforms
... [VC in a nutshell]
... verifiable credential is a standard way to express
credentials on the Web
... vc-data-model is a W3C REC
... [VC Structure]
... context: issuer ID, Credential (type, subject id, claims),
Proof
... digitally signed by the issuer
... [The "Sofie Credential"]
... (example VC data)
... @context has "https://mm.aueb.gr/contexts/access_control/v1"
... issuer: did:nacl:E390... as a public key
... actual credentialSubject
... id: did:nacl:A49...
... [WoT device configuration]
... hints for the enduser
... also provides information on the WoT implementation
... @context has "https://mm.aueb.gr/contexts/access_control/v1"
... securityDefinitions has
... @type: ["VerifiableCredential", "AllowedURLs"]
... [SOFIE's Identity, Authentication, and Authorization
Component]
... access control based on the VC
... HTTP request from client
... then response from the device
... and then the use has to generate the proof
... if the proof can be verified, the user can access the
device
... [SOFIE]
... links for resources
McCool: tx
... you're presenting the security scheme based on VC and
DID
... replace with other security mechanism?
... don't we need other mechanisms like OAuth?
Nikos: that's possible
McCool: probably we would extend TD
for this purpose
... do you looked at XPath as well?
Nikos: yes
McCool: similar issues/considerations
to be applied
... how to deal with selection of devices?
... filter-based metadata in the VC would raise issue with
privacy
... possibly a PII information?
Nikos: the user can hide information if want
McCool: relationship between DID and
discovery
... wondering about the DID for discovery of credential
information
Nikos: DID uses public key
... DID is included in the credential
Kaz: this example is too simple
but the point is that VC is not PII itself but a data model to
provide necessary information for each application
... and DID is the actual identifier but that is also split
from the PII
McCool: regarding the data, VC can be embedded in the DID document?
Nikos: those are separate
McCool: tomorrow, we'll discuss PoCs, Scripting, PlugFest reports, Binding Templates
Ben: tx for all your
presentations
... interested in DNS-SD, etc.
... Mozilla also has some mechanisms for discovery
... DNS-SD, Bluetooth and Gateway
... may have a better way based on today's discussion
... could write some proposal myself
McCool: we'll continue the discussion
in 2 weeks (no call next week)
... your input would be welcome
Zoltan: regarding the order of the
topics for tomorrow
... maybe better to have PoCs, PlugFest and then Scripting
McCool: will tweak the agenda
... Niko and Farshid, please send your (update) slides to me so
that we can upload them on the GitHub repo
[Day 1 adjourned]
<McCool> agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
<kaz> 1. Sebastian
<kaz> 2. Ege
<kaz> 3. Daniel
<kaz> scribenick: sebastian
McCool: shows the agenda
<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
Jennifer: summary Smart City use
case
... apply SPOTON in that scenario
... use of AI and thermal cameras for health monitoring
... pandemic management
... it is a first use case for introduction
... there are also plans for mapping and robots usage
... we want to start small
McCool: we should update the health
monitoring use case
... we want a PoC on geolocation, right?
Jennifer: not using it yet
... maybe later
McCool: we should revisite PoC plannings
Jennifer: we will add that to the use cases
McCool: Retail
... there two different busniss groups
... and collaborations such as Conexxus, Intel,...
... retail scenario: buying ice cream
... we want to demonstrate visible sensors and analytics by
EdgeX
... demonstrator shall show how simple applications can be
build
... applying WoT for metadata and using WoT API/node-wot
sebastian: where is WoT applied exactly?
McCool: device description and analytics
Kaz: is there some digital twin aspects?
McCool: edgeX tries to predict maintenance of the devices.
Lagally: some comments for digital twins:
state of the device and historian
... and you discover the behavoir of the devices
Jennifer: for what are you using digital twin?
McCool: its more a semantic
simulation
... Intel has some investment in predicting maintenance
... are there other PoCs?
(no responses)
McCool: full week virtual plugfest via
VPN, one hour day sync meeting
... what we accomplished is to create issue tracker
MM shows slide about its home scenario setup
McCool: the VPN instance is still online?
Kaz: yes
Sebastian: how long will be the VPN available?
McCool: so far, ongoing
sebastian: cool thing to have vpn and
things always online for testing
... people can go there and test its implementation
McCool: it would be cool to have a dashboard which things are online
Kaz: so our intention is using the AWS instance not just "for a while" but "for some years". right?
McCool: yes, at least till the end of the
charter
... shows an overview of the Things that were used in the
PlugFest
... there were things within VPN and some outside (in the internet)
such as Thing Directory
<inserted> Plugfest+Outcome PlugFest Outcome issues
McCool: outcomes and issues are
provided
... balabce vlaudation and experimentation, usefulness of VPN,
Xpath useful for discovery, get validation and reporting tools
ready before the plugfest, IDs needed for primary keys
Ege: we spend a lot of time about VPN, but who is depending on that?
McCool: we should log who used the VPN
Ege: Actually I don't need that,
except if there is a device in vpn then I have to use it
... how do I know when I have to use the VPN?
support keeping VPN such as for prototypes of planned commercial devices
scribe: supporting the idea of an dashboard
McCool: more comments about the PlugFest?
<kaz> [5min break]
<McCool> https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
<McCool> please put presentations at the above directory - I will move the scripting pres later
scribenick: Ege
Zoltan: we had busy time since March
... in ConsumedThing you can specify the form ... index
... we discussed on how to handle contentType and DataSchema
... and we added most of the algorithms
<kaz> PR 207
<kaz> PR 203
Zoltan: we have improved the error mapping
<kaz> PR 209
Zoltan: so how to map errors to protocols and back
<kaz> PR 218
<kaz> PR 221
<inserted> scribenick: kaz
Ege: status message also should be
handled
... by the ConsumedThing
Zoltan: how to map the protocol-specific errors with JS errors is the question
Ege: script should understand protocol specific features
Zoltan: developer could make mapping
<inserted> scribenick: Ege
Zoltan: so the mappings are more straightforward
Lagally: we discussed something similar
with Sebastian and Matthias a couple years ago
... the errors in the API should be abstracted from the
protocols
Zoltan: so we need two mappings, one in the bindings document that maps protocol errors to a unified error list
... and another one that maps those unified error list to JavaScript errors
<sebastian> https://github.com/w3c/wot-thing-description/issues/303
Sebastian: So the issue that ml described, I
have pasted the link in the IRC
... TD issue number 303
... so we can continue discussion in there
Kaz: You can share the link in IRC as well
<Ege> @mmccool, could you merge this PR: https://github.com/w3c/wot/pull/922
<McCool> ok
<kaz> Scripting.pdf fyi scripting slides (tentatively)
<kaz> [slide 3: WoT Scripting API specification updates]
Zoltan: we worked on observe and subscribe handlers
<McCool> btw I'll rename slides later to clean things up, don't worry too much about it for now
<kaz> InteractionInput and InteractionOutput, support streams
Zoltan: and also getting values from the
interaction outputs
... now we can parse to different media types
... also streams are possible
... this was a big change
Ege: handling observe and subscribe is needed if you want to build a proxy with Scripting API so that you can dynamically listen to observe requests from Consumers and relay it to the actual Thing
<kaz> [slide : Opens]
<kaz> Error handling (related to PR 221)
<kaz> Issue 219
Zoltan: We have open issues, regarding readmultipleproperties
<kaz> issue 912
Zoltan: also contentType or DataSchema
but mixing them (raised by Cristiano)
... we need to sync with the Discovery TF for the discovery API
<kaz> Issue 910
<kaz> Issue 913
<kaz> Issue 206
Zoltan: We have the discovery API but it
is very unspecific
... but there are already proposals like ThingFilter
McCool: so we need to generalize the ThingFilter to payloads or URI content since both can be inputs for discovery
Daniel: the reason to not let consume() method accept a URI is to avoid having to support multiple protocols while fetching the TD
McCool: yes, so the consume method works without network access
Zoltan: there is also the semantic api proposal by Michael Koster but we didn't have to explore it yet
<kaz> Issue 204 - Semantic API
<kaz> [slide 5: Deployment scenarios]
Zoltan: we are also discussing on how to deploy scripts
<inserted> [slide 7: Status node-wot]
Daniel: Here are some updates on
node-wot
... we support HTTP, CoAP, MQTT, OPCUA, Netconf and Modbus being
planned
McCool: what about CBOR?
Daniel: We don't have support for it but
they can be very easily plugged
... you can do everything in the browser as well
... then the hands-on material was improved
McCool: I find the test thing having data types as names a bit confusing
Daniel: we have videos for using
node-wot
... Cristiano is working on OAuth2 in server side
... we have also improved the logging mechanism
... also, the new Scripting API is not yet in the master branch
Jennifer: nice to see OAuth2 and the tutorials improved
McCool: it would be nice to get some input on needed OAuth flows
Daniel: you can also see that we have many PRs by contributors and we are making good progress
<McCool> https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf
<kaz> scribenick: kaz
<inserted> Browsified node-wot
Kaz: Daniel, are you planning to use the webui version of node-wot for the upcoming PlugFest in the future
Daniel: already using it
Kaz: would be great to have some
document as well
... good starting point. thanks a lot!
[5min break]
scribenick: dape
<Ege> Google Docs version
Ege: [slide 2] - Protocol
Vocabularies
... we have turtle files for CoAP and MQTT
... thanks to Victor
... [slide 3]
... links to rendered version
... [slide 4]
... improvements about vocabularies still needed
... [slide 5] - Interest Check
... so far we have HTTP, CoAP, MQTT.. done
... no interest on oneM2M, OCF so far
McCool: w.r.t. OCF, implementantions 1.0
<kaz> Issue 1
McCool: need to look at more recent versions, and security
<kaz> Issue 92
<Ege> https://github.com/w3c/wot-binding-templates/issues/92
Ege: please comment on issue https://github.com/w3c/wot-binding-templates/issues/92 to identify new ones
McCool: suggest zeroMQ, will add it to issue
<kaz> ZeroMQ
McCool: [slide 6, 7] - Robotic Operating System (ROS)
Ege: ROS is middleware
... communicates with protocols of robot over lower level
protocols
... programming is abstract
... [slide 8]
... ROS has similar goals to the WoT
McCool: ROS has security problems
... work on ROS2 is in progress
Ege: Agree, it is 10 years old
... lot of devices out with ROS "1"
McCool: ROS2 has more industrial strength
Ege: [slide 9]
... ROS: Mixed broker and P2P communication
<kaz> ROS
Ege: can store TD
... consume them
McCool: Payload issue? Serialized with YAML?
Ege: contentType has to be specific contentType
Ege: [slide 10]
... 3rd July call, proposal shown in Binding call
McCool: Did have issues with node.js implementation
Ege: Implementation improved
... [slide 10] - Subprotocols
... [slide 11] - Server Sent Events
... serves pushes events to client/consumer
... PR for node-wot
... used in OpenHAB
... plan to look into subprotocols
... [slide 12] - bridging protocols
... MQTT over WS
... clients can used WS to talk with MQTT device
... there is also CoAP over WS
McCool: CoAP over WS mentioned by
Mozilla also
... should look at there use-cases also
McCool: OpenHAB is very
interesting
... PoC for OpenHAB is very valuable
Sebastian: Student of mine works on openHAB topic
McCool: OK, great. can talks about that in Plugfest call
Kaz: Question: if we want to use MQTT over WS... web browser as possible client?
Ege: Yes. correct
Kaz: NHK uses web browser in TV
set
... could be part of the future PlugFest as well
McCool: TD describable enough ?
Ege: Yes, interesting topic. will come
to it later
... [slide 13]
... [slide 14] Paho in Python, reference implementation
... different to node.js implementation
... TD consumption step needs some assumption
... not sure how to describe it in href
McCool: Standardized URLs for MQTT?
Ege: There isn't
... broker URL and topic
... see issue 255 in node-wot
... assumption / best practice
<Ege> https://github.com/w3c/wot-thing-description/issues/878
Ege: also issue 878 in TD repo
Farshid: some pure MQTT implementation use
TCP and SSL
... no mentioning of WS but TCP, SSL
... no standardized scheme
<FarshidT> https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
<Ege> Some implementations may also support the 'tcp' and 'ssl' scheme names.
McCool: similar issue with JSON schema.. not having a standard reference
Sebastian: we have to check MQTT
standard
... many implementation out that are not following standard
<McCool> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v3.1.1-csprd01.html
Sebastian: MQTT 3.1 is weak w.r.t.
security
... --> different security solutions implemented but not
standardized
McCool: OASIS connection points?
... impacts our work
Ege: MQTT vocabulary needs to describe broker URI, security etc
McCool: look at *all* possible
ways
... figure out how to deal with them
... maximizes interoperability
Ege: [slide 15] - Next work item
... improve protocol vocabularies
... error mapping
... node-wot has OPC-UA, NETCONF and Modbus, should they be in
binding templates
Cristiano: can help with Modbus
<McCool_> network glitch, my audio just broke :(
Cristiano: have PR on node-wot with
Christian
... OPC-UA and NETCONF was done by Luca
... can ask Luca
<McCool_> (audio/irc back... network hiccup)
Sebastian: OPC-UA work should be done with
OPC foundation
... possibility to have OPC-UA expert
... vocabularies should be maintaned by *owner* of protocol
Kaz: OPC-UA contact?
Sebastian: Yes
... but so far in internal process
Kaz: How many bindings templates
should be added?
... can I assume OPC-UA. Modbus being added as example
Ege: Could be examples or more assertive within tables
Kaz: Echonet or Hybdridcast could be added to binding templates also
McCool: vocabulary should be
normative
... how do we get there?
... other groups are in charge
... need to work with other organizations
Kaz: agree
... can publish group note first and then transfer if needed
McCool: Yes, reach out to other organizations a well
Ege: node-wot examples could be added ...
McCool: Yes, but putting note saying it is prototype
Ege: will add to issue 92 ... OPC-UA, NETCONF and Modbus
<kaz> Issue 92
Ege: New protocol interest, please let me know
Kaz: will you update the slides on the GitHub repo with the "next steps" page?
Ege: yes
McCool: 2 missing protocols: Zigbee and
zwave
... not sure if feasible
Ege: Not sure if we can support
them
... would open up to USB, Bluetoothm ....
McCool: Agree
Cristiano: w.r.t. ROS. I did some experiments. Difficult to understand initial setup, topics, et cetera
Ege: Correct. WoT can help here
... direct XML RPC is possible also
... lots of extra communication is done and rather messy
McCool: ROS has formal documents
... in YAML files
... Comments/input?
McCool: shall we discuss logistics for
tomorrow
... Wednesday, 3 hours sessions by M. Lagally
... please upload presentation to github repo
... will do a clean-up step later
Jennifer: client application connecting to WoT. Recommendation to use HTTP or MQTT ?
McCool: TD is independent
... >discussion how to wrap node.js code in other
languages<
Kaz: most of PF participant have been using HTTP and other protocols are of interest
McCool: It is also a discussion about implementation language. node.js... C++ et cetera
Kaz:there is a python implementation for WoT, WoTPy, as put on the WoT REC press release
<kaz> WoTPy
McCool: maybe we can reach out and have 1-to-1 discussion
Ege: my contact person was not interested ;-)
<cris> https://pypyjs.org/
McCool: will create issue about "how to support Python"
<McCool_> https://github.com/w3c/wot-testing/issues/37
<kaz> [Day 2 adjourned]
scribenick: kaz
McCool: (goes through the agenda)
... profiles and lifecycle for today
... use cases, requirements tomorrow
... TD, marketing on Friday
<kaz> ... note the use case call will be held tomorrow on June 25 one hour earlier than this vF2F call
<McCool> https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/
<inserted> scribenick: jenlin
mlagally: Collected 15 use cases
so far
... Can people respond by the end of the day today for the Use
Case questionnaire?
<zkis> scribenick:zkis
Lagally: please fill it
<mlagally__> https://github.com/w3c/wot-profile
Lagally: we hat a github repo
... and handle this in the Architecture task force
... presents slides
... motivation for profiles: we need out of the box interoperability
... the TD spec it is quite elaborate and generic
... TD is very flexible and has few constraints
... we got feedback (e.g. from the W3C TAG) about
interoperability concerns
... generic TD consumer cannot be implemented, because device
implementers can pick TD features arbitrarily
... we have seen during plugfests that there are a core feature
set that works fine together
Ege: agree it's difficult to
implement a generic client, but don't think it cannot be
implemented
... there some cases indeed node-wot could not implement
McCool: for instance there could be some protocols missing
Ege: still, implementable
McCool: the point is that a given client needs to implement a compatible protocol
Lagally: for every generic client I could create a TD that would break the client
McCool: clients could be updated with time, and the profiles would explain the differences
Ege: (missed)
Lagally: you don't even need to go down to the protocol
Koster: there are 2 approaches:
client adapts to protocol
... and to constrain the protocol choices
... it's a huge tradeoff
... we need to be careful
... everyone wants their special profile
McCool: we just want out of the box interop
Koster: tricky term
McCool: if two devices implement a profile, they should work together
Koster: we restricted already the protocol choices
McCool: we can decide that
Lagally: we are in the middle of the
profile discussion, perhaps finish the slides first
... there are a number of ideas
... there are 2 angles to interoperability: specification
(normative guarantees)
... covering all corner cases
... this is difficult
... which is why we do reference implementation
... considering profiles to compartmentalize concerns
... second angle: reference implementation
... third angle: test suites with guaranteed coverage
... certification program
... how other specs solve this?
... selecting a target specific subset of features
... additional constraints and clarifications
... there is a common core profile
... in DVB-GEM
... it is possible to combine profiles
Zoltan: this is similar to W3C conformance classes
Lagally: will look into that
... profiles also might select various codecs etc
Koster: there could be different levels of expectations on what interop means
Lagally: will address that later
... there are also other features a profile could select for
interop
... other example, filename requirements
... other example: clarification of behaviour
... if the API is not fully specified on that behaviour
... so it's clarification of corner cases
... Scenarios and use cases
... before buying, making sure a device would work in my
environment
... as developer, wants TDs to be simple as possible (e.g. in
constrained devices)
... as a developer, being able to validate compatibility with
consumers
Koster: let's go to the other direction: there is a whole spectrum here, e.g. dismissing Forms
McCool: we want to limit complexity
Koster: we could probably allow more complex data structures more easily than new protocols
McCool: most important is to make
sure the devices will work
... then, secondarily it's important that I can sell a given
device for a given use case
... 2 viewpoints: end user and developer
... both need to figure out how to interop
Zoltan: were there practical hard limits on interop with the current generic TD spec?
McCool: there may be gaps in coverage
Lagally: it is possible to implement incompatible systems
Ege: I would disagree with that
McCool: other way to do it is testing
features and post compatibility on a public site
... a consumer could figure out what works
Koster: in general, the Web doesn't have profiles
Ben: any browser can render any web page
Koster: I agree
... not every system needs to support every protocol
... where is the boundary
... for instance FTP support in browsers is not universally
needed, but might be
McCool: implementations could have
extensions
... we should be able to check for features
Koster: we could allow more feature
rich and less feature rich endpoints without breaking
things
... we also need to create one spec
... not like 15 specs
Ben: ad-hoc interop is impossible
Koster: in general I agree
Sebastian: ad-hoc is irrealistic
... we also need to take security in account, then there is no ad-hoc
Lagally: if we cannot ensure out of the box interop, without writing code, what is the purpose of the spec
Koster: yes, 2 different factors: we
do make a unifying spec
... it is not the same to enable magical interop
... WoT is doing exactly the work of agreeing in a working
"profile"
Lagally: it is not "either, or"
Koster: just saying there is a lot of benefit in doing the standard even without explicit profiles
Lagally: implementing own client is not a good requirement
Zoltan: (fill in later)
Lagally: what do we do if actions go wrong?
Zoltan: need to describe an error
<mjk> https://xkcd.com/927/
Kaz: if we need additional
mechanisms, we should indeed add them
... but we should look into exact use cases first
Lagally: there is a certain methodology on this in the presentation
Ben: the profiles are
needed
... without them the TD spec is open ended
... currently the TD spec does not guarantee interop
... so agree in adding profiles to add ad-hoc interop
McCool: we can't prevent people doing
silly things
... but could achieve a reasonable compatibility
... we should support green field devices
... security is another aspect
... one effect of profiles is to add guaranteed support for
things
... especially regarding security
Lagally: agree that we need to limit and constrain security options
McCool: working "well" also means "not hackable"
Koster: we're going towards
interoperability
... this is a separate thread of development in the IG to
gather interested parties
Sebastian: the goal of profiles is
good
... but we dismiss the legacy, and that is a real problem
today
... when new devices are developed, then we can require profile
compatibility
... but we need to be careful with legacy systems
... otherwise the standard might not be accepted
... we might have too many profiles as well
... and the end is again a mess
... we should avoid that
... I think we are good about the TD and not sure profiles
solve the real problem
Lagally: agree to not create a mess of
profiles
... we want to limit the number of profiles
... about brown-field devices
... if we define profiles so that 80% of legacy features are
supported, it should be good enough
... that would be enough for spec adoption
Dave: I like the points brought
for profiles (working features)
... the actual technical requirements don't require a very wide
support for things
... for instance image formats in the web are just a few
<dsr_> Profiles are also important for discovery - client apps need to limit discovery to things they can actually interoperate with
Kaz: repeating the point of
looking into the existing scenarios
... also work together with the other standardization bodies and
align with their views
... if there is actual need of extensions for the TD that
require profiles, we should go for it
Lagally: yes, we started doing
that
... with ITU-T and OCF for instance
... please respond to the questionnaire and specify what is
needed
Sebastian: still don't get the real
issue here
... one thing is what do we miss in the TD spec
... then, what is the client doing with profiles?
... let's compare with web pages
... the question is what the client is doing with the page
source
... it will do what it supports
Lagally: let's move on with explaining the proposal and then will tackle that
<mjk> my comment to the irc: profiles already exist. There is a profile for OCF, a profile for OMA LWM2M, etc. that are candidates for a standard profile
Lagally: profiles are widely used
elsewhere as well, with similar motivation
... continuing with use cases for profiles
... digital twins
... with tens and hundreds of device types
... we want to have a model of these devices
... just a TD would not be enough to cover implementation
environment constraints
... if additional code is required, then it's not going to be
used
... TDs should be consistent and complete
... then, interop between multiple vendors and protocols
... there might be differences in content format
... there could be many restrictions
... consumers should be aware of these restrictions
... imposed by the protocols
Kaz: we should see the difference
between the requirements for profiles and the ones for Binding
Templates
... so we should clarify the requirements for the profiles
here
Lagally: to give more context on
proposed requirements
... would defer that discussion until the next Architecture
call
... profiles should have a finite set of features and
capabilities to be implemented by the consumer
... Check out the current Profile draft
<kaz> strawman draft for WoT Profile
Lagally: profiles should not define
new features, just constrain and clarify existing ones
... how to describe a profile: we need a generic profile mechanism
... we need a core profile, coming from plugfest
experiences
... the intention is to formalize these experiences
... to document what has been working and what not
... profiling mechanism
... constraints on: TD vocabulary, mandatory terms, limit
cardinality
... constraints on values, data schemas, security
Zoltan: what is missing from the current TD spec to express all these constraints?
Lagally: we can see a couple of
examples
... for instance when TDs don't actually define those
constraints
... will show examples later
McCool: we agree a profile is a set
of constraints
... the question is how to organize these
... we need to gather the constraints that are necessary and
optional
Ben: agree that these activities
should be focused
... e.g. infinite nested objects are a problem
... constraining the protocols would be most important
... because that is not easy to handle from the client
Kaz: these constraints might be
valid for the Binding Templates as well
... we need to think on how to deal with these requirements
<McCool> (I also agree with ben that protocols should be on this list of contraints - I assumed it was just an oversight when the slide was built, though, since I beleive those constraints are in the strawman)
Lagally: agree
<McCool> (also content formats, eg. for data payloads, probably also need to be constrained)
Sebastian: this reminds me of what Escher IoT are doing
<mjk> The Azure thing is Digital Twin Description Language (DTDL)
Ben: indeed there is overlap between profiles, templates, ...
Lagally: in templates we don't talk
about protocols, only about the data model
... on devices that implement the same templates, the model is
the same, but there could be different protocol bindings
Koster: a lot of open-ended
discussion, but got a good picture on what needs to be
constrained
... OCF has a similar mechanism and MQTT as well
... the set of constraints are pretty well defined in the
protocols
Lagally: presenting core profile
... constraint on the protocol binding is that default binding
is HTTPS
... predefined mapping of HTTP verbs to WoT interactions
... only a single Form per interaction
... constrained set of data types (e.g. no arrays of
arrays)
... profile status: last year a strawman proposal was
made
... architecture TF focused on lifecycle
McCool: want to open a discussion
about logistics
... how exactly should we proceed with profiles
Lagally: let's finish the presentation first
McCool: do we start with a strawman and improve later, or do we want more preparation
Ben: there is a list of proposed
and accepted requirements
... need to agree on the accepted requirements
Lagally: certainly, please participate
in that discussion
... presenting the profiles github repository
... and the strawman proposal
<kaz> strawman draft for WoT Profile
McCool: the structure is
reasonable
... there are some issues
... we need to create better requirements and then modify it
with a set of PRs
... and document things in issues
Ben: will try to write a draft
for requirements on what's needed
... one is what operations to define by default
... TD spec, Bindings and Profile spec tries to do this as
well
... so where should this live
Lagally: good point
... the Profile spec is not to define things, just to reference
them
Ben: a client really needs to know what ops and details they have
Koster: both LwM2M and OCF have
profile-like constraints
... it should be checked
Lagally: we could discuss that in an upcoming Architecture call
Koster: OCF could be easy to map to HTTP - given security details are sorted out
McCool: we can figure out later if
profiles vs bindings need to address constraints
... the question is figuring out the next steps
... is it in the architecture calls?
Lagally: yes, the next Architecture
calls
... please take a look at the profile issues
... create new issues
<benfrancis> Clarification for the minutes: The requirements document I mentioned writing was for the Web Thing Protocol Community Group, not WoT profiles as I want to make sure all the WoT specifications do not conflict with each other.
<benfrancis> The comment about ops was that defining default HTTP methods for operations is only part of what is needed by a client - also need to define headers, payloads, response codes, error conditions etc. Perhaps the Profile could go further than the TD and Protocol Bindings specification in defining those, or constrain TDs to a particular sub-protocol
<benfrancis> which defines them.
Lagally: review the strawman proposal
<kaz> wot-profile issues
McCool: we have 2 architecture calls, needs some alignment
Lagally: we can have that conversation later
McCool: break time
<kaz> [resume in 6 mins]
<kaz> scribenick: jenlin
Michael_Lagally: Presenting WoT Lifecycle
Lagally: Goals: Describe the
operational lifecycle model across different standards, Align
terminiology, Identify impact and requirements
... Mentions Zoltan did a lot of work on tStatus for
lifecycle
... Draft of Layered lifecycle diagram
... Lifecycle Specification draft
McCool: One thing we used in
security documents is to define the scope in our scecurity
documents
... Since we have two operational substates
... We also have maintenance states like discovery and
registration
... Each spec writer needs to make sure each spec says what it
needs to say for lifecycle
... Device lifecycle
Lagally: System lifecycle mentioned
too
... Thing lifecycle
... Onboarding and offboarding of device lifecycle to
consumers
McCool: Things should be cover in
discovery lifecycle like time to live
... The point is discovery can go both directions -- discover a
directory and register
Zoltan: Want to specify similar
things for smart group -- we're putting together a lot of
things in the beginning that should probably be separate
... Discovery for onboarding
different from discovery in operational mode
... There are protocol things specific to take into account for
lifecycle, so it's difficult to standardize behavior and may
require different network equipment
... What do we want to represent in lifecycle?
... We want to represent state and transitions and operational
mode and onboarding discovery
... This is tricky, the
lifecycle discussion, since it's all about specifics
Lagally: I agree, but we're going to look at high level architecture with consumer and intermediaries
Kaz: Two comments: We should
think about the relationship between application and session
lifecycle
... Also should think about lifecycle in an abstract layer for error
handling -- for example, if some state transition like onboarding has failed, that could be an error for all the possible protocols used by the connected devices
... Concrete errors for each potocol could be mapped with that abstract error
Lagally: Runtime layer on top of devices where we don't have to look into the state machines of protocols but have an abstract layer on top
Kaz: We don't have to think about the detail of the hardware layer or the network layer, but can concentrate on the application layer, though
McCool: Wonder if lifecycle is
what we should define it as first
... There's additional components we may need like a separate
service that runs a component
... Take our patterns and think of them as components
... Then we can think about lifecycle and onboarding
Lagally: One new component is the directory and discovery service
McCool: OCF is an onboarding
service that discovers devices and onboards them
... Does what it needs to do to find devices then registers
it
Lagally: I'm wondering if these
bridges or gateways are intermediaries
... Let's call it protocol gateway at the moment
McCool: Second category is a
bridge
... Whatever, we need two different words
Lagally: Gateway is just a 1-1 protocol translator/convertor
McCool: First category is a
servient
... Second category is not
<Zakim> zkis, you wanted to explain system lifecycle
Zoltan: In architecture we need to specify what nodes we have
... When we have a thing directory, how a consumer knows it's a TD, it has to know its URL
... Should be able to define a TD in wot interactions
McCool: Having a lifecycle for
TDs is very interesting
... Since we need to know when it is updated
... Lots of questions of TD lifecycle
<McCool> my previous points: maybe we should think about the TD lifecycle
<McCool> so I think there are use cases where TDs need to be updated, if not very frequently, even without "dynamic" hypermedia/resources creation
<McCool> e.g., IDs can be rotated, IPs can change...
scribenick: kaz
Lagally: (shows system state diagram)
... let's use the next architecture call in 2 weeks for the following discussion
McCool: we'll discuss use cases and requirements tomorrow
... also there will be the use cases call tomorrow one hour earlier
Lagally: will create an issue, and we'll continue the discussion on lifecycle during the architecture call in 2 weeks
[Day 3 adjourned]
<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
<kaz> 1. Jennifer
<kaz> 2. Daniel
<kaz> 3. Farshid
<kaz> Presentations area
<inserted> scribenick: jenlin
McCool: Double-check the name of your presentation
Slides on Use Cases and Requirements
Lagally: Cancelled earlier Use Case
call due to low attendance, merging with this call
... Almost 2 hours for Use Case results
... More of a discussion today rather than presentation on the
Architecture Use Cases & Requirements
... Questionnaire results
... Use cases ~ 20 proposed in the architecture group
... Mentions active contributors of Use Cases
... Also target domains
... Work split: Architecture and Use Case Task Force
... Capture new use cases, open to all IG members, community, and
guests
... All use case related issues moved over to new repo
<kaz> wot-usecases repo
<kaz> old USE-CASES area from the wot-architecture repo
Lagally: folder called Contributions for new use cases
<kaz> use case template
McCool: Subdirectory is old use case template, top level is new
Lagally: Will fix after call
<kaz> initial use case draft
McCool: This is an informative document (use cases) and there will be no royalty commitment required
Lagally: There is an "Issues" tab and structure things separate
<kaz> wot-usecases issues transferred from wot-architecture repo
Lagally: Architecture Discussion
Process diagram
... Use Case Shortlisting
... Want to make sure Use Cases coming from different sources have
business interests
... And real market needs
... Want to make sure to focus on the important/priority use
cases
McCool: 40% of use cases involves
orchestration of devices from market
... how do you account economic activity?
Koster: owe you a use case based from market need
McCool: agree with basic point to need to figure out advantage
Koster: Capabilities model
Lagally: will have another use case meeting, ask mk to join
Koster: dog upset by fireworks
Lagally: Questionnaire results
Koster: Will try to make regular call
Kaz: what about inviting Koster to the architecture call?
Lagally: good idea
<kaz> architecture calls are 11pm and 8am in PDT
Slides on Use Cases and Requirements
Lagally: Put together the results as of
25.6 @ noon
... have not received responses on all the use cases
... business relevant responses are higher than business
critical
<kaz> questionnaire results (member-only)
Lagally: anyone not a W3C member?
Josh: part of the W3C Team
Lagally: Ogiso-san a W3C member?
Kaz: yes.
Lagally: Lots of written feedback to look into
McCool: This questionnaire is very
flat.
... I marked a lot of things as business critical
... What's missing is to rank the use cases
... Need to do trade-offs between use cases
Lagally: Right. Will get to it in the
second half of the call. Will assign rank.
... Need to do weighted results, inventing a formula.
... Weighted Results, e.g., business critical=6; business
relevant=3; useful=1
... This is not final
... What people are interested in the most
... representing the members of the group
McCool: This metric ranks things higher
even though there are other things that are business critical
... While this is helpful, a more direct question about ranking
will be helpful
Kaz: Similar to McCool. The result of direct question might be the same as the results of this formula, but if some use case is very important for a company, it should be handled and included in the final proposal
... probably, we can categorize all the proposed use cases into 3
categories, critical, relevant and useful, and then which use cases
would be handled by whom
Lagally: identify what needs to happen if
we dig deeper in requirements
... identify people who say this is important enough for me that
would be willing to contribute their expertise and anaylsis in the
existing spec
... look at examples as well
... who would be willing to do something here
... using numbers for trends
... And stakeholders
Josh: Weighting accessibility of the
current model/business -- I don't think this reflects the
importants of accessibility in all the use cases
... be careful about drawing conclusions based on these
numbers
... it's hard to find business cases for accessiblity in WoT
... demonstrate lack of tangable cases of accessibility in this
business space
Lagally: thank you, taking notes
McCool: accessibility and other horizontal things might confuse the picture
<Joshue108> +1 to MMcCool
McCool: should look at the importantance
of difference technologies over horizontals
... categorize and sort into buckets
... accessibilty should be in the same category of security and
privacy
<Joshue108> +1 to MMcCool again
McCool: considered for every use
case
... some of these are tricky, like audio/video
... vendor/system integration is also a horizontal
... 10 are verticals, 6 are horizontals
Lagally: let's capture this as a first
finding
... prioritize horizontals
McCool: not all verticals need all the
horizontals
... not all veriticals will need OAuth2 for example
... need a matrix to show this
Kaz: remember we already talked about horizontal vs vertical in last architecture call
McCool: charter requirement
<Joshue108> +1 to Kaz :-)
Lagally: Horizontal Use Cases
... Accessibility, Privacy, Security, l18n
(Internationalization)
McCool: Other vertical groups we should
be reviewing with
... Different overlaps we need to review with verticals
Lagally: Vertical Use Cases
McCool: We should coordinate with these vertical groups
<kaz> horizontal use cases should include: accessibility, privacy, security, i18n
<kaz> vertical should include: DAS (geolocation), Automotive, ME
McCool: We need to draft the use case
document and reach out to the groups
... Ask for reviews and input right away when we have a reasonable
design document
... when we have a first document we have consensus on
<inserted> scribenick: kaz
Jennifer: one possible addition for the
vertical use cases is medical one
... need to define what a "medical device", though
... various viewpoints like certified devices
<inserted> scribenick: jenlin
Lagally: There are different standards for
military and fitness trackers, etc
... Do we need to classify different things?
<Joshue108> https://www.w3.org/WAI/APA/
Josh: happy to be point of contact for accessibility reviews
<Joshue108> https://www.w3.org/WAI/APA/wiki/Wot_usecases
Josh: we have a wiki for use cases
and added use cases to it
... done a lot of work in user needs and requirements for real
times communications
... just a head's up for some of the work our group has done
<Joshue108> Accessible Platform Architectures (APA)
Josh: the purpose of APA is to make sure W3C specifications support accessibility
Lagally: do we have any previous experiernce in end to end (machine to machine communication) sensor/robot interaction?
Kaz: suggest the results from the questionnaire as a basis for peoples' interest in the categorized use cases here and provide further contributions
<kaz> scribenick: dape
Kaz: ask for further contributions
McCool: Issue of health: regulation
... expensive to get certification
... similar issues: Automotive, Smart grid and smart building
... wrt. use cases: is it a given industry?
... people avoid health... due to the afore mentioned issues
Lagally: implications of requirements
work
... does it help if we know is it regulated?
McCool: Yes. Question whether we need expert.
JENNIFER: Certification is important since some people will refuse to use it if certification is missing
Lagally: Is there a analogy to HTML ?
McCool: HTML is expection
... e.g. had documentation requirements like XML
... hard to know when you need certification
Lagally: Would be good to know when certification is needed
McCool: WoT TD might need
certification
... archived for long time storage
Lagally: Some use-cases still
under-represented?
... 5 minute break
<kaz> [5min break]
Lagally: please speak up if someone feels issue under-represented
<inserted> Requirements area
Lagally: We have requirements in wot-architecture
<McCool> sure, I can let others go first ;)
Lagally: 2 req documents created
... one on thing templates
... similar: geolocation support document,
https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md
... mentioning requirements, related standards, othe references,
comments
McCool: are some use cases
requirements?
... e.g., OAuh2
Lagally: Was thinking along the same lines
McCool: Yes, should remove OAuth2 from use-cases
Lagally: Will do
... Some UCs have 1:1 mapping to requirements, other may have
multiple reqs
McCool: let's single out technologies to
requirements
... sometimes still fuzzy
Lagally: Several new use cases
... from Cristiano, Ben and McCool
Cristiano: Open field smart agriculture and
smart managament came from one project
... comes from IOT-based platform
... uses Fiware at the moment with LORA (devices that can go to
sleep)
... w.r.t. "Building structural health monitoring", Italien project
on platform for bulding, bridges, ..
... multiple sensors taking high frequency samplings
... can create use-case document
Lagally: Thanks, very helpful
Cristiano: Smart water managements use case is about managing network of channels
Lagally: related to Fujitsu use-case
... Ben provided use case. Not in the call right now
... Interactive digital signage
Kaz: there is business group on
digital signage
... will try to reach out
Lagally: McCool has 3 new use cases
McCool: AI Services, Edge Computing, IoT
Orchestration
... Edge Computing: presentation about leveraging WoT
discovery
... AI Services: like face detection. pre-defined service, retail
use-case contains it for example
... is somewhat horizontal
... IoT Orchestration: landing zone for scripting
Lagally: Kind of mash-up?
McCool: IoT Orchestration is idea of
representing result as new thing
... new TD
Lagally: reminds me about "links between things"
Kaz: w.r.t. new ideas, we could have another category between horizontal and vertical, e.g., middleware, if needed
Lagally: I am not opposed to 3 categories... if it helps us
<McCool> McCool: I think we should stick to 2 categories for now... simpler
<McCool> ... middleware should probably be horizontal
<kaz> Kaz: that's also fine since middlewares tend to get into the horizontal platform in the end :)
Cristiano: Besides project of monitoring we
are evaluating policies of WoT services
... services discovering other services
... dynamic service migration
McCool: Web worker migration seems
related
... virtual things: in retail use-case we use partly virtual and
not physical things
Lagally: comes close to digital twin use case
McCool: Motivation: support for virtual things
<McCool> ... much easier to substitute virtual devices (eg a camera and AI instead of a real door sensor) if both are "Things"
Lagally: More new use cases/ideas?
... hearing none
... Summary
... looked into business critical vs. business relevant
... talked about weighted results
... horizontal vs vertical use-cases
... requirements: like OAuth2
... new use-case proposals
... after break we take a look at the points from requirements perspective
... re-start in 7 minutes, 5 past the hour
<kaz> [7min break]
<kaz> scribenick: FarshidT
Slides on Use Cases and Requirements
link to repo directory: https://github.com/w3c/wot-architecture/tree/master/REQUIREMENTS
Lagally: there is no risk of adding patents into use cases
McCool: the contributions should
actually be royalty free. We have to warn people about that.
... the normative specs cannot include non royalty-free
materials
Kaz: normative portion within the final W3C Recommendation must be royalty-free, but examples and informative sections don't require royalty-free commitments
Lagally: more interested into application domains
Requirements for Thing Templates
Lagally: if a use case requires
standardized system component, it can be included in
requirements
... template if good to formulate ideas.
... related standards can point to what other task forces have been
doing to give a good starting point, also not to reinvent and have
overlaps.
McCool: should each use case have a corresponding requirements document?
Lagally: no, we extract requirement from
all use cases. One requirement may apply to multiple use
cases.
... the goal is to have atomic requirements, i.e.
non-overlapping
McCool: also precise and satisfiable
Lagally: acceptance criteria for
satisfiability
... we need to have stakeholders for use cases
McCool: we can capture requirements in the PoC meeting. Let's add this to the agenda.
Lagally: retail and smart city use cases have priority for Intel.
McCool: manufacturing and smart building may be a priority for Siemens. Need to confirm.
Kaz: Audio/Video is important for NHK. With help from Kaz. Chris Needham?
Lagally: for agriculture, there are
requirements for greenhouse, stakeholders are Matsukura-san an
Christiano.
... smart city: Michael McCool and Jennifer will work on
requirements
McCool: health is theoretically important, but we don't have anyone suitable to work on it
Lagally: manufacturing: Sebastian?
... multi-vendor system integration: Oracle has a lot of interest.
M. Lagally.
... multimedia system integration: Intel has interest but no time,
maybe Josh can look into it? Kaz would like to volunteer.
... accessibility: Josh?
... automotive: no expertise
Kaz: can ask about the interest of Access for automotive use case
Lagally: energy/smart grid: Christian G.
from Siemens worked on the use case. Maybe he can work on it.
... smart building: Farshid, and Andrea C. (UPM)?
... transportation: the use case in very broad, and high level.
Needs additional work.
... Can Zoltan work on transportation?
... shared devices and resources: Ege?
Ege: will continue working on the details
McCool: willing to help Ege regarding this use case.
Lagally: oauth flows use case
McCool: need to look into flows and decide which ones make more sense. Will be the point of contact.
Lagally: device life cycle: In good hands. Zoltan and M. Lagally will continue to work on it.
Kaz: got a response from Josh, he will rejoin the call to discuss accessibility.
Lagally: need to prioritize which use
cases to cover in the next arch. calls (July 7th and then
14th)
... welcomes and briefs Josh
<Joshue108> I can bring these back to Accessibility Platforms Architecture working group for feedback
Josh: agrees with assignments i.e. multimodal system integration, accessibility
McCool: first pass needs Josh's expertise
Josh: functional requirements can come from user needs
<Joshue108> +1 to Michael L
Lagally: add a section in requirements section for user needs?
Josh: agrees
Lagally: use case shortlist for next two
arch. calls: retail, agriculture, smart city, multi-vendor system
integration, multimodal system integration, smart building, shared
devices and resources, oauh2 flows, device lifecycle
... have names and owners for all use cases
... need confirmation from some stakeholders
... will check the status in two weeks
... wrap up session tomorrow?
McCool: yes and thing descriptions
Lagally: can get the confirmation from others tomorrow
Farshid: will check with Andrea C.
Lagally: thanking all, closing
<kaz> [Day 4 adjourned]
<kaz> Presentations area
<kaz> 2 for TD, 1 for marketing
<kaz> 1. Ben
<kaz> 2. Taki
<kaz> 3. Cristiano
<kaz> scribenick: benfrancis
Sebastian: Welcomes the group to
Friday session of F2F, Thing Description discussion
... Known TD spec bugs, under-specified features,
new features for TD 1.1, Status of Templates, hypermedia,
discovery & security
... Discovery & Security will recap discussion
from Monday
Sebastian: Want to improve the Thing Description and make it more powerful. We have found bugs, e.g. in Example 17.
Example 17 has a stray comma which prevents parsing as valid JSON
Pull request to remove the comma. Question: Should we update the main Thing Description specification as well?
Kaz: The latest policy is, as long as a fix is editorial, can fix recommendation itself.
McCool: Should create Errata page so people know what has changed.
Kaz: Should file two issues, one for recommendation and one for latest Editor's Draft
McCool: Could label issues that need to be landed in Recommendation.
<kaz> PR 914
Kaz: Can define a simple
procedure so we can fix the current draft on GitHub using PRs,
but create additional issue for Recommendation. Consolidate
editorial issues and ask webmaster to reflect these in the
published specification.
... BTW, there was another issue pointed out regarding table syntax. #919
<kaz> https://github.com/w3c/wot-thing-description/issues/919
RESOLUTION: Pull request to remove comma to be merged into latest Editor's Draft. The comma is banished. Should create Errata document to note bug fixes. Daniel will create separate issue to remove comma in Recommendation, with a label to note editorial change.
Sebastian: Issue 915 https://github.com/w3c/wot-thing-description/issues/915
Validates as valid Thing Description, but if using JSON Schema(?) validator does not correctly recognise terms in securityDefinitions collection.
McCool: Schema has definitions for things that have been removed, needs a cleanup
Sebastian: For people who want to use semantic tools, will have issues with security members
McCool: Can we update the file as is or publish a new version?
If it's a bug fix, updating the current version makes sense
Should delete extra schemes that are not in the spec to bring it inline with the specification
How did we miss this? Do our testing tools like include JSON-LD tests?
Sebastian: We are not doing enough semantic testing in our PlugFests
McCool: We did do testing, but treated as optional elements so did not trip the test case. Or similar.
Ege: Should have thrown an error. Perhaps JSON-LD version in playground is old.
McCool: Should fix the testing so it does trip on this, and fix context file. Investigate if fixing in place with bug fix is reasonable.
Sebastian: Context file not directly in the specification. Is it OK to just change it? The specification is correct, but the model file has a mistake.
Kaz: Should think about impact for implementations if we fix the bug in the context file. Will implementations be impacted, what would need to be changed. Should carefully consider.
McCool: Notify people in advance that the context file will change in place, set a date for that change, archive old version with new URL (e.g. v1_obsolete)
Need to consider this a bug fix.
Kaz: Can bring this to project
manager and ask if OK to reflect the change.
... If change impacts implementation then need to discuss
further.
<McCool> to capture what else I said: I'd like to suggest we establish a minor version, and let "v1" pick up the latest minor version
McCool: Thanks, I lost track of that part.
<McCool> then if people really want older versions, they can use a more specific minor version, eg. v1-0, v1-1, etc.
Sebastian: Implementors may wonder why they do not see securityDefinitions
Kaz: Should assess potential impact
Taki: Can ask bug filer how it impacted their implementation
Sebastian: Bug filer has a workaround.
Dape: Have previously been asked to file issues for Errata items, this seems similar. I think it would be good to not just do change in an issue but list as an Errata item.
Kaz: Already provide a template for Errata entries. This issue might be problematic for implementations should carefully look into this.
McCool: Different to modifying the specification (human readable), this is machine readable and would impact implementations. Bug fix in minor versions.
Figure out how to do bug fix as code, not just editorial change in spec.
Kaz: Should clarify what our intention was. If this was intended specification this is fine, but need to fix bug on specification itself for next version.
<kaz> Errata file
McCool: Not an errata issue in spec, bug in file, spec is fine
Kaz: If implementations are impacted, that would be a problem.
Lagally: Support idea of Errata document. So implementors know what to do to be interoperable, and understand if there is a delta from what has been published.
Sebastian: Is this Errata document linked in the recommendation document?
Kaz: Yes, there is a link in the top section.
Sebastian: Resolution: I will
respond to issuer to say we can approve this bug and will fix
this in the Errata process.
... These were the two topics we need to address very soon.
<kaz> thinks it's actually a good proof of the fact that people have started to use the TD spec :)
<benfrancis> kaz++
Sebastian: Specification looks like we should use uriVariables, except action input field. Criticized in some issues. Should clarify when we should use uriVariables.
McCool: So using uri query paramaters is considered bad practice in API design?
Sebastian: Yes and no. Can use uriVariables in properties etc. But for actions we have inputs, so why are we showing an example of uriVariables for actions when we also have input?
uriVariables should probably be avoided if possible for new systems.
McCool: Two issues. Did we introduce uriVariables as a good example.
<kaz> Issue 910
uriVariables are actually bad practice in actions. For actions you do have paramterized actions. The use case that comes up is if input is binary data like an image.
Inconvenient to have to create a body that has some JSON. There are use cases for this, need to explain.
Sebastian: We should be more clear about usage?
Dape: Disagree. Using uriVariables for properties is bad design. In case of actions when you POST something considered good practice if convey data in body. For properties there is no outcome so considered back practice.
McCool: Question is what you use the query data for. Might want to put data parameters in POST query. Binary vs. ASCII data.
Need a best practices document that explains these tradeoffs. The spec just says what the spec can do. Examples should be reasonable and not contradict best practices.
Sebastian: Example 21 uses uriVariables in a property. Passed in URL in form. Looks good to me, should maybe provide clarification.
McCool: I do agree this is a
reasonable use. Constraining the type of data you're getting
back. More like a query/database query.
... I can see it being justified.
Dape: This is a good example of a running instance that works.
Sebastian: But is it really running?
<sebastian> https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02
<sebastian> PR on updating example 21: https://github.com/w3c/wot-thing-description/pull/911
Sebastian: Should we merge this PR? Update example? More reasonable, not as confusing.
<Ege> https://openweathermap.org/current
FarshidT: Root of the problem is really the HTTP method. GET request should not change state.
Sebastian: Action comes from
Matthias. Comes from Nabaztag (Wi-Fi rabbit). Has a REST API.
Designed a Thing Description for this. Uses GET method with
parameters. So it's the rabbit's fault.
... The Thing Description should show best practice.
I may have paraphrased...
RESOLUTION: We will merge this PR.
Sebastian: Should we also close this issue?
https://github.com/w3c/wot-thing-description/issues/913
Keep open, but clean up later.
<inserted> Issue 848
Lots of discussion about readmultipleproperties
Very fussy and strange that it was adopted by specification since there is an expectation we have implementations.
Ege: There are no
implementations.
... There are TDs produced, but implementation wasn't doing it
properly.
... Report says there are two implementations, but I can only
find examples from node-wot
<inserted> scribenick: taki
McCool: It was the last minute change.
<McCool> to be clear, implementation report was totally data-driven, but this extra implementation might have been based on a manual assertion rather than a TD
<McCool> we will have to look at the archives in more detail
Sebastian: It cannot disappear
now. I should investigate more such as use cases in CoAP PATCH
and OPC-UA.
... also it may be common in cloud systems.
Lagally: Network overhead is
significant.
... We do read-all in our implementation.
... It is useful in practice.
Koster: Digital twin systems,
common interaction through incremental changes.
... It looks like an interaction model issue.
... It is a model issue.
Ege: It is not clear why we need
to supply an array.
... It is different in pub/sub case.
... If it is using URI variable, how can we do this?
Sebastian: It is not well explained in spec.
Daniel: We have both methods for
retrieving multiple and all.
... From scripting perspective, it is not really necessary to
have both.
... I can do real-all. If it is only 2 or three, we can use promise.
Koster: read-all satisfies the requirements.
Zoltan: Are there anyone who absolutely need read-multiple?
Sebastian: CoAP-PATCH? We need to investigate.
Koster: CoAP-PATCH is for patterns. OPC-UA, there is a bulk-load. Cloud systems usually does not need read multiple.
Zoltan: I have never seen use cases that need read multiple.
Koster: Some people may see read-multiple as optimization.
Zoltan: I can group them in an object in TD.
Koster: There are design patterns. But we do not have concrete use cases.
Ben: It is safe to remove read-multiple. We can make it as a feature at risk in the coming version.
Sebastian: One possibility is to remove it in the next version. At the same time, we could investigate more. For now, it seems that removing it makes more sense.
Zoltan: We can add it later.
Daniel: You can mark a feature so if nobody finds it useful, is there procedure in W3C?
<inserted> Issue 913
Zoltan: multiple parameter case is not very clear in spec right now.
Sebastian: Those are the issues
that I wanted to have discussed today.
... new features next.
<Ege> brb
Sebastian: minLength, maxLength and multipleOf in Data Schema, see PR #896.
<inserted> PR 896
Sebastian: Have not merged yet
because there is a problem in rendering script now.
... Victor is not available today. He works on rendering
script.
Sebastian shows JSON Schema ontology HTML.
Ben: Mozilla implementation already has multipleOf because there is a use case.
McCool: Are there any JSON schema features that we do NOT want?
Sebastian: the set we have now was all experimented in plugfests.
McCool: developer expectation is that it is JSON-Schema.
Koster: We have not seen many
payload examples.
... Let's make a bigger useful subset for common payloads.
McCool: We should talk to people experienced in IoT payloads.
Sebastian: We say in spec that we support all keywords.
McCool: $ref, for example, does
it break validation?
... we should base our decision on community experience.
Ben: Mozilla implementation is basically using the set specified in W3C recommendation.
Sebastian: next, definition and
$ref. This is new as well.
... Define data model constructs once, and use it in multiple
places by reference.
<benfrancis> The Mozilla implementation so far uses enum, readOnly, minimum, maximum and multipleOf. And unit, but I think that was added for WoT.
Sebastian shows Issue #307.
<kaz> Daniel's example for Issue 307
Sebastian: It was originally suggested by Toru Kawaguchi.
Koster: "definition" is convention in JSON schema.
Ege: Yes
Koster: we can use JSON pointer, and JSON validator work on that.
Sebastian: JSON validator does not understand action, property, etc.
<cris> https://github.com/w3c/wot-thing-description/issues/912
Cristiano: I have issue with Content-type in schema. We can discuss in next TD call.
Lagally: Design question. Do we
need to parse TD once or twice to resolve references?
... This is important for constraint systems.
Ege: I posted a link.
Koster: there are also recursive and circular references.
Lagally: We should discuss to
limit references to backward references, for example.
... can you use variable before you declare it?
Daniel: With JSON, object members
are shuffled around.
... there is no way to define order in JSON.
Lagally: We have TD
serialization, and we can specify.
... This is an issue with small devices.
Sebastian: client may not use all
dependencies.
... It is up to the use case.
Koster: constrained devices
cannot buffer much in memory, is that the point?
... security thing is the same.
<McCool> sequence is not technically required by the spec... but maybe could be required by the profile
Daniel: complexity raises. You can point anywhere in the document with JSON-schema.
Lagally: We should keep this issue in mind, and specify how to limit if necessary.
Farshid: Default security, for
example. We no longer need it.
... If we copy it to elsewhere, the links will break.
Daniel: We do not intend new dependency.
Farshid: It is only for data definition.
Koster: can we reference definitions outside of the document?
Ege: $ref depends on
implementation.
... It is underspecified in JSON-schema spec
intentionally.
... AJV, for example, does not have TD scope.
Ege: You have to copy definition into actions before handing to AJB.
Daniel: You can copy the entire
definition to next to $ref/
... i.e. within the same scope.
Ege: $ref, all depends on implementation.
Sebastian: $ref processing depends on validation tools?
Ege: there is common practice
among implementations.
... But it is not specified in JSON schema.
Sebastian: We can specify in TD
spec then.
... We can also use JSON pointer.
Kaz: I am skeptical about this
proposal.
... for example, there is a possibility of using Verifiable
Credentials and DID for user credentials, so we should look into
some more use cases to see the actual need for "$ref and
definitions".
... We should look at more use cases.
McCool: We can have "processed"
version of TD.
... external definition should be disallowed.
... DID is new spec at this point.
... $ref makes more sense to me.
Sebastian: We discussed this in TD call, and we agreed we need this feature.
Kaz: If the main purpose is defining address separately and referring to it once, do we really need this feature?
McCool: We wanted to reduce
redundancy.
... We should start describing use cases.
... redundancy invites error.
... We should describe use cases.
Ben: parsing algorithm's point view, it introduces complexity. We can make it preprocesing in the server.
Sebastian: Complexity vs. redundancy is a recurrent issue.
Ben: This is also an issue TDT.
<cris> taki I can take over the notes, or at least I try :)
Sebastian: We have only one hour
left.
... We should take a break.
<benfrancis> I also think securityDefinitions should be simplified so that security can be used on its own for simple examples (https://github.com/w3c/wot-thing-description/issues/300)
<benfrancis> https://github.com/mozilla-iot/wiki/wiki/Mozilla-W3C-Differences
Ben: I started to document the difference between Mozilla implementation and W3C specification in the hopes that they will converge.
<cris> ben: starts to document the differences between mozzilla'TD and W3C TD. Trying to convege
Sebastian: Thank you very much,
it is a great work.
... People expect the two are the same.
Ben: there are many minor differences. The bigger one is architecture changes including protocol binding.
McCool: Profile can help.
<inserted> scribenick: cris
McCool: 10 minutes break
<kaz> [10min break; resume at 15mins past the hour]
McCool: sharing the agenda
McCool: sebastian review of activities, discussion of the next steps
Sebastian: quick update, showing
a patchwork of different articles where wot were
mentioned
... sharing links to these articles
... please add more if have seen other sources mention
wot
... showing the new logo
... please use the new one
... we are working with webcastor which already worked for
W3C
... we are going to create a video, Siemens will sponsor
it
... and Intel
... sponsor positions are open
... a style of video was decided
McCool: two kinds of sponsorship: money or logos
Lagally: is there some of document which explain the content of the video
Sebastian: there are some slides
about it, cannot show them now
... topic twitter account
... go to @W3C_WoT
<kaz> @W3C_WoT
Sebastian: there is a draft of a new wot web landing page
<dape> https://github.com/w3c/wot-marketing/issues/65
Sebastian: was made by Studio 24, daniel has more details about it
Daniel: provides a link with next
steps
... studio24 will provide updates in that issue
<kaz> timeline
Daniel: studio24 plans to work openly
Kaz: they are working with the basic template HTML+CSS like a CMS so that people can easily maintain the Web pages
Daniel: it might be complicated to handle users
Kaz: mentioned to them the possible difficulty with working on the W3C content which consists of multiple mechanisms
Sebastian: new page on wikipedia about WoT
... it was outdated and not reflected what W3C was doing
... someone made some changes but violated some copyright rules
... we need to discuss how can we improve it
... like describing the different blocks in the W3C WoT architecture
Ege: we need to provide more references
Sebastian: how can we improve it ?
McCool: create a draft were we
can work together with other parties
... also can we trigger an re-evaluation of the page
content?
Ege: need to explicitly ask for an re-evaluation
McCool: in the marketing repo we have a md page that needs to be kept in sync
Kaz: ege, do you know some external collaborator who can help us with the wiki?
Ege: we can tweet about this
<kaz> WoT welcome page
Lagally: What's the plan with the public WoT landing page?
Daniel: the current one has nothing to do with what studio24 is doing
<McCool> timecheck: now way over the 10m allocated...
Daniel: we mean to substitute it with the new one
Lagally: when is the best time to provide feedback about the new landing page?
Kaz: we can talk about this during the next marketing call
Sebastian: Michael, you can comment anytime
Lagally: it is quite confusing because we have two versions running in parallel
Kaz: the W3C WoT Landing page was made/maintened by the W3C Team, while the new WoT Welcome page is made/maintained by the WoT Marking TF.
... On the other hand, we (=Daniel, etc.) were asked for input from Studio24 who is now working on the redesign of the global W3C pages (except the group pages like the WoT Welcome page)
Lagally: just let us know if something is ready for review
Kaz: Studio24 is working on the
global W3C pages except the group pages
... So we have to make a resolution on how/when to review the WoT group pages including the WoT Welcome page
Lagally: so this group page is ready for review?
Sebastian: yes
McCool: time check 18 minutes
left
... handle kaz presentation to next slot
... we should now discuss about the next steps
Sebastian: the next steps were
already included in the previous slides
... there is a broken link in the global W3C page
Ege: the point is that we do not have access to this page, even if we are the most interested by its content
Kaz: there are two kinds of Web pages, 1. those maintained by the W3C Team and 2. those maintained by the WoT WG ourselves. So I wanted to explain what's ongoing on the W3C Team side, but let's talk about the details during the next Marketing call
<inserted> W3C Project Management Updates
<McCool> at the very least I think we need to streamline change requests, eg with direct access to an issue tracker
Sebastian: topic upcoming
conferences
... Ege has applied to a ASC 2020 conference
Ege: if anyone has input about my submission is there still time for editing
McCool: we could also have a
session were we review your slides, maybe in the Marketing
calls
... the conference it will be a good chance to talk with
experts from other technologies (i.e. openAPI)
Sebastian: there is a video about node-wot in action
McCool: there is also a template for slides to keep a consistent look&feel
Ege: include some photos from plugfest as additional material to include in presentations
McCool: we need to get a consent by people on these pictures
Ege: but they are already pubblic
McCool: we still need to get their consent
Ege: another thing in addition to a template we can put material which will be used inside the presentations
McCool: any other comments?
... let's agree on the template and start to use it
Kaz: the template is nice, thank you
McCool: topic closing
session
... topic followup activities
... profiles in 2 weeks, call for TDT in 2 weeks (TD webex),
hypermedia calls in 3 weeks...
... try to cancel as many calls as we can to break after
F2F
... let's cancell all the TF meetings but if you have an
exception please report it in the mailing list
<kaz> Project management updates for Marketing
Kaz: should we move also the discussion about Marketing tools in the next marketing call?
McCool: yes let's move it in 2
weeks
... when will the minutes be ready?
<inserted> from now, i.e., July 8
McCool: let's put fix a deadline:
2 weeks from now
... if there are any other follow up activities please email me
Lagally: I need to allocate someone to the requirements of manufacturing
Sebastian: you can put me and Christian and also to the smart building requirements
McCool: who's is going to post
about F2F on twitter?
... assigns sebastian to this task
Kaz: please take a look at my slides before the next marketing call
<kaz> Project management updates for Marketing
McCool: we should keep an eye on
Ege slides for the next conference
... is any followup action that I miss?
... ok none, please if you have any additional items send me an
email
... please also update your presentations with a PR
... ok we are done
Kaz: thanks McCool and Sebastian
<kaz> also all the scribes!
Sebastian: thank you also from my side
[vF2F adjourned]