Meeting minutes
Logistics
no recording
transcription turned on
<mlagally> present ?
remember the TPAC guidelines at https://
Agenda
McCool: we will not do the resolutions today
<kaz> TPAC WoT Agenda
Manu: When could I talk about DID and VC?
McCool: today or wednesday?
Manu: wednesday would also work
McCool: sorry that my computer is slow and that github is slow
charter proposals
McCool: we have left them open as PRs
TD and other WoT specs
<kaz_> PR 1033 - Create new charter items for TD
Ege: started with a number of topics with the CG.
<Zakim> manu, you wanted to ask about where DIDs, VCs fit in?
<kaz> s/acm m//
Ege: : many of these were tabled - looked into a pull request for issue #978.
<Github> https://
Ege: : (discussion)
… : it's a very large topic, not actually covered well in the current charter.
… : another topic, payload driven protocols. Using different protocols defeats interoperability, so it's a difficult subject.
McCool: JSON RPC has come a long way, and some pub/sub protocols are used.
Ege: this protocol topic area is very large.
McCool: charter should probably be adjusted to accomodate.
Ege: "href" we keep putting it TD seems not to be useful. An initial URI is required for MQTT and WebSockets.
Lagally: we should note into the use cases documents some of these new requirements. There is an initial classification
… : where these things would be documented - not a perfect fit, but we should do that soon.
Ege: "timeseries" - sometimes called historical data. Currently no way to model this kind of history data. maybe a new affordance.
… : We are looking for a generic way to do this recording, keeping timestamps, etc.
McCool: re discovery - work with Home Assistant, there are several rules triggered with historical data.
… : e.g., system state may change subsequent output.
Ege: security definitions - inline needs to be simplified.
… : Versioning - this topic is underspecified. M. Lagally suggests Semantic V. but we need to be more specific.
Daniel: re profiling - core TD spec and Profiles relationships aren't well definied, e.g., should a profile be a subset of the TD spec?
<Zakim> dape, you wanted to relation between TD core spec and profiles (sub-set vs. super-set)
Daniel: : we'd like to discuss whether subsetting is the right way to go.
Lagally: I think we need some tweaks to align these, but we should list points of required alignment.
Daniel: question is should >all< profiles be a superset of a TD?
Lagally: I think we need a few new things in TD, new constraints.
McCool: TDs do allow extension vocabularies. I think all these things should be extensions.
… : re behavior, when is it a superset, and when is it a subset. It's a subset if it contrains, and a superset if there's additional knowledge in the contained in the TD that you can't consume.
Ben: I agree with concerns of Profiles going beyond TDs. What we've used profiles for is to define additional requirements for additional protocols.
… : even with sub/super sets, there is still going to need to be some allowance for protocol definitions in the TD.
Kaz: meta question - we are talking about not the TD per se, but relations to other specifications. We should clarify in the next charter.
… : we need a better topic name.
Ege: super/sub set might be the right terminology. I think we should write the protocol specification (in general) before writing any other specification.
<benfrancis> +1 to what Ege said.
McCool: I agree with Kaz and Ege, which is where is the best place too put stuff.
… : we've tried to cram a lot of stuff in profile, and we might want to refactor.
sebasitian: we should have a standard "binding" document which should be referenced as a single point of truth.
… : that relieves some of the friction about where exactly that binding can be used.
<Mizushima> +1 kaz
Ben: important to distinguish between a "protocol binding template" and a "protocol binding". I think we tend to approve. The template is required, but it doesn't replace an actual binding for a specific case.
… : protocol bindings should be in a central registry, and those reference templates.
McCool: we'll leave these PRs open so people can comment.
Binding Templates
Ege: the first issue touches the topic just discussed. Question is do we need multiple rec-track documents?
… : I suggest we try the approach with our existing protocols, and then move on to the new protocols.
… : JSON content protocols will be easiest, and then move to other contents
McCool: binding templates have "sub standards" published as needed, and separately versioned (in profiles).
… : maybe profiles should reference bindings, with a flexible structure.
Lagally: I'm not really clear how these vocabularies would be tested in a plugfest
<sebastian> It was just about the missing OPC UA in the list
<Zakim> ege, you wanted to react to McCool
Kaz: meta - we should start with the whole picture of the specifications for WoT. We are too deep into the specifics.
Ege: we have been working with profiles, more or less successfully, but I understand.
McCool: going back to profile templates, vs. profiles.
Ege: so we could create a language or CoAP to express what's needed in a standard way.
<Zakim> ege, you wanted to react to ege
Ege: : the features are not complex.
<Zakim> McCool, you wanted to react to kaz
McCool: JSON RPC may have different requirements in this regard than CoAP (for instance).
Lagally: it is not sufficient to specify the protocol req/resp, but also "edge" cases where there are failures. Good cases are simple. Errors are hard.
Profile
<kaz> PR 1034 - Update profiles.md
Lagally: I have extended the profile proposal
Profile Spec proposal
Lagally: I have elaborated the two or more profiles. Digital Twin which can model twins
… maybe even an organization as a twin
McCool: I propose to reword will be part to something like may be. This way we are not constrained
Lagally: next one is cloud profile. To control a wide variety of devices
McCool: ben's comment is about what is needed in cloud that is not already in http baseline
Lagally: we would have more guarantees
Lagally: third one is about more profiles about constrained devices and other protocols
Lagally: we should definitely not do vertical profiles
Sebastian: I think the digital twin and cloud profile is not needed
Sebastian: we should work together with other SDOs in these domains
<McCool> ack +
<Zakim> +, you wanted to react to sebastian and to
Sebastian: otherwise we invent another way to do something
<Zakim> mlagally, you wanted to react to sebastian
Lagally: plus 1 to working together with SDOs
Ege: transitioning to profile to application area
… from my viewpoint, this seems to be a guideline
… how to use protocol binding, etc.
Ben: agree with Ege
… new profiles suggested here, e.g., digital twins, is implementation specific
Ben: I agree with Ege, we have http baseline, sse, webhook. These new suggestions are going for a use case or a deployment scenario
Ben: the existing profiles should be extended based on requirements we collect
McCool: It would be nice to have two cloud profile work out of the box
Ben: I disagree with the proposed profiles. We should define profiles to restrict protocols to have interop inside that protocol
<Zakim> benfrancis, you wanted to react to McCool
Lagally: I wanted to respond to ben. We are in the middle of a requirement discussion
… we can defer naming these profiles
<Zakim> mlagally, you wanted to react to McCool
<benfrancis> mlagally: Yep, that makes more sense.
Kaz: I partly agree with sebastian, ben and ege. we should think about the objective
Kaz: what we want to with profile specification should be clarified
<Mizushima> +1 kaz
<Zakim> dezell, you wanted to consider "movable" protocols classes.
David: this issue is something we struggle with at connexxus. the td and basic profile are good ways to do abstraction
… the ability to abstract the interfaces is essential
McCool: I want to resonate with what is Kaz was talking about. The profile spec is the one at most risk
… we have to clarify what is profile for and for me it is out of the box interoperability
… it could be about interop with UI systems or documentation systems
McCool: anything about the proposals? We should move on
McCool: I would like to leave the PRs open. Also, please use the suggestion feature of github
McCool: we should move on to liaison discussions
Deliverable Progress
<kaz> WoT schedule
Discovery
McCool: a review process has started. We aim for resolution next week in post tpac meetings
McCool: our testing needs more work
Kaz: to be strict, we should revisit the deliverable progress markdown document (which I put above). we can revisit it later, though.
TD
Sebastian: first of all, we decided to call for review for CR transition
… thank you for all the reviews and comments
… I have listed the issues here and they are mostly editorial
Sebastian: one is an important change, changing the default for writemultiple operation
… if you change only parts of a resource, it is not a put anymore
Ege: this is a breaking change. I would not do this now. Also, it is not incorrect (in my opinion) that PUT is not corect
Sebastian: also ben said that proxy-to relation is not explained anywhere. so a question to mccool is to what to do with this
McCool: people went for a link types table and put the stuff that made sense
profiles
Lagally: we have a draft now which is targeting to be a profile 1.0 release
… it has 3 profiles, baseline, webhook, sse
… both event profiles are not normative since we lack implementation experience
… I consider the baseline feasible for implementability
… except for async actions
… we want to have a plugfest next week and we are looking for implementors
… and thus have 2 implementations of the baseline profile
… and that is it for the profiles
McCool: plugfest is the week after next
McCool: we should look into our schedule, we are quite tight on time
Sebastian: the pain point was how to implement the asynchronized action, not clear
<McCool> ack +
Lagally: in my understanding is that the spec is stable for a long time already, for 9 months
Lagally: I have implemented async actions in java and it works
Lagally: we need to discuss what is happening and where the problem lies
Kaz: today's session is progress check within 10 mins. So let's not dive into the details but simply record the identified issues. From my viewpoint, the bigger issue mentioned today is need for clarification on the relationship between WoT Profile and the other specs, which is related to the testing issue as well.
architecture
Lagally: we are reasonably stable
Lagally: we need help from implementors to testify about their implementations
… everybody has implemented it anyways since it is the overarching specification
<sebastian> for ML: here is the issue about the async actions https://
McCool: we will check the implementation status in the post tpac meeting
… we will probably do 2 CR transitions
Liaisons
OPC UA
<kaz> PR 1020 - Technical Objectives and Requirements for OPC UA/WoT Binding
Sebastian: we do not have too much to say, there is the PR that explains what we want to achieve
Sebastian: the next step is to have another meeting with the opcf people
… it was difficult to find a slot but we have it on thursday
https://
Ege: I have pasted the OPCUA link at IRC
<McCool> seb can't hear us
<kaz> Technical Requirements for OPC UA/WoT Collaboration
McCool: we need kaz to attend it since it is too early in vancouver timezone
McCool: we should have a regular meeting schedule
Kaz: I agree
ECHONET
Kaz: matsuda-san will present
<kaz> ECHONET Liaison slides
Matsuda: I will speak on behalf of masihira-san
… echonet is about managing smart devices that can be considered part of a smart city
… we have 3 standards
… communication, device commands and device-specific behavior
… there are 7 classes of devices
… more than 100 million compliant devices
… echonet lite web api makes it easier to control devices from anywhere
… it allows connecting multiple industries
… echonet lite web api is similar to w3c wot since it is inspired from an earlier draft
… we have done some activity together with W3C WoT WG
… we have also proposed a use case
… we also gave a presentation in the WoT Japenese CG
… we need to have periodic operation reservation, historical data processing
McCool: we can use the japanese community group slot for discussions
Kaz: we can use those discussions for next deliverables of the WoT WG
… now you have 3 minutes for the next meeting
DID/VC discussion on Wednesday
<kaz> on Wednesday, Sep 14 at 9:30-10:00
<kaz> [adjourned]