– DRAFT –
WoT Profile

agenda

<kaz> agenda for today

minutes review

<kaz> Aug-3

spec structure and next steps

Lagally's slides

Lagally: I have prepared a presentation

Lagally: we seem to agree on baseline and most of the common constraints

McCool: we need testing to proceed to REC

Ege: I think that actions was never tested

McCool: actions are at risk and we do not seem to have agreement on common constraints

Sebastian: async actions are not done, sync is easier

Ege: even sync actions are not done since they need a payload format

Lagally: we have implementations in the oracle and in webthings

Kaz: sorry but a bit confused because we've started talking about which features of TD are possible, not the http baseline shown as Lagally's slides

Kaz: if we want to revisit the implementation status of the TD features as the basis of the discussion on the Baseline Profile, we can do so. However, we should see the implementation status of all the related specifications, i.e., TD, Architecture, Discovery, Binding Templates and Scripting API to see which features are "Basic".

McCool: we can make normative sections we do not agree on informative

Lagally: we have webhook and see but each have only 1 implementation

Lagally: alternatives

Ege: we can also publish a document that is about an HTTP protocol

Lagally: that would sacrifice a lot of work

McCool: we do not have time for major restructuring

Sebastian: I am ok with C if we have a succesful plugfest

<kaz> [[

<kaz> Option C. Publihs the Profile 1.0 as a REC, make event mechanisms non-normative

<kaz> make normative in Profile 1.1 after sufficient plugfests

<kaz> ]]

Sebastian: if we cannot have a succesful plugfest and testfest, we can publish it as a note

Kaz: what is the discussion here exactly? rescoping of the WoT Profile spec document or timing of the publication?

Lagally: it is not a scoping discussion

<McCool> (comment about scoping - profiles are basically an ongoing project, so this will always be a problem...)

Kaz: if the question is re-scoping the WoT Profile specification, if we want to think about an update schedule for the WoT Profile specification for a REC, we need to clarify all the remaining problems. If the remaining problem is only about the event mechanism, option C here would make sense, but is that true?

Kaz: I can wait until the end of the slides before getting the answer, though.

Ege: me too

Lagally: we have discussion on payload formats

Ege: implementing in scripting and node-wot not straightforward; we also have not really done end-to-end testing of profiles (eg consumers)

Sebastian: talked to daniel about baseline profile in node-wot; was concerned that no defn in scripting API on how to handle action cancellation, for example
… but needs to evaluate the effort needed

Ege: I do not think that it is easy to implement in node-wot
... but seems to not be that straightforward

Lagally: what we could do is mark these sections at risk
... want to make life easier, not harder

Ege: also, I am not aware of any consumer implementation so far, which is more important than thing implementations in my opinion

Sebastian: if some things are hard to implement, need to understand why

Ben: going back to the options, C and D do not provide much value
… default http binding of the TD is enough for that
… only new thing would be async actions

Ben: I prefer option A, do it earlier in the next charter, i.e. not take 2 years

Ben: we lack a lot of implementation experience for the consumer

Ben: we have 3 consumer implementation plans for webthing

<kaz> [[

<kaz> A. Dont' publish Profile REC within this Charter, defer to nxt Charter

<kaz> B. Publish the Profifil as a WG Note in this Charter period

<kaz> C. Publish the Profile 1.0 as a REC ,make event mechanisms non-norative

<kaz> D. Publish Profile 1.0 as a REC with "HTTP Baseline" only

<kaz> ]]

McCool: adding to kaz's comment. it is not unexpected that the work is not done

McCool: I agree with ben on option C

McCool: we have to explain the difference between protocol binding and profiles

Kaz: I am ok with all options but B
… before choosing an option, we need to clarify the current status a bit more

<McCool> (time check: only 5m left in mtg)

Kaz: which issues need to be adressed here

McCool to Ege: the thing is, there are constraints on metadata that don't have anything to do with a (sub)protocol, so...

McCool to Ege: but for the specific things about webhooks, etc. sure, that might make sense

Kaz: when I mentioned "remaining issues", I meant not only the event mechanism issue listed in this slide but also all the remaining GitHub issues and also possible additional issues from the implementers viewpoint like Ege and Sebastian mentioned. After clarifying all the remaining issues, we should clarify which issues to be handled when (e.g., during this Charter period or next). And then we can tell when to publish the WoT Profile spec in which shape automatically.

Lagally: issue filers should organize their issues

Ege: I find it weird that non editors do issue organization work

McCool: we do not have time left but we should work on the document

[adjourned]