W3C

– DRAFT –
WoT Profile

09 March 2022

Attendees

Present
Ben_Francis, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura, Michael_Lagally, Ryuichi_Matsukura, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
dape

Meeting minutes

Agenda

<benfrancis> https://github.com/w3c/wot-profile/issues/107#issuecomment-1062850204

<kaz> agenda for today

Ben: above proposal to be added for the Event Model discussion

previous minutes

<kaz> Mar-2

Lagally: <walks through minutes>
… any objections
… none -> minutes approved

Event Model

Lagally: circling around a lot
… we do have event affordance
… on protocol bindings we have a reference to server sent events (SSE)
… for the HTML living standard
… we also have the op's
… and text to identify SSE et cetera
… for example 24, https://w3c.github.io/wot-profile/#example-24

Ben: w.r.t. reference ... there is a redirect in place

Kaz: living standard... does not necessarily mean it is not stable. so we should refer to it (HTML Living Standard) directly.

Lagally: That means we need to specify a non-normative section in a living document
… not ideal

Ben: Only introduction is non-normative

Lagally: w.r.t. to Event discussions
… different opinions
… implement all event models?
… consumer that does not need event stream .. does not need to implement certain parts
… in PlugFest many devices do not support events
… SSE may not be very scalable
… SSE is the only way would mean excluding other use-cases
… limit deployment scenarios
… got concern ... interoperability
… e.g., WebHook ... not able to open server port

Lagally: Kind of stuck now

Ege: for me the main problem is the use-cases are not compatible
… due to this we get stuck
… different profiles? .. let people compose them
… goal of profile is to "miss" some use-cases .. but have interop across the others

Lagally: Interesting statement

Lagally: limiting the profile .. is not what we should be doing

Lagally: I listed 4 alternatives with pros and cons
… there might be more
… 1. non consensus -> remove events out of profile
… 2. define 3 variants core+XX for SEE, longpoll and webhook
… 3. include 3 events mechanisms
… event support is optional
… 4. mandate single event model

Lagally: proposal from ben

https://github.com/w3c/wot-profile/issues/107#issuecomment-1062850204

Ege: another option is having different profiles .. not just about events
… discussion client vs. server

Lagally: I don't see that point

Ege: Webhook is server to client
… in MQTT it is even client to client

Lagally: Not relevant since we focus on HTTP

Lagally: I don't see Server to Client
… I see Servient to Servient .. for webhook

Ege: if we are to use webhook .. it is Servient to Servient .. if we don't use it is server to client

Lagally: Servient to Server is missing

Ege: things pushing data to cloud... use-case not in core profile
… things are not pro-active

Lagally: core profile is silent about that

Ege: I don't think so
… client is to use HTTP GET

Lagally: it can be more than a client
… no hard differentiation
… profile does not prescribe what and how it needs to be implemented

Ege: profile constraints consumers

Kaz: WoT in general defines software application layer
… between servients
… so I don't think we should discuss the detail on data transfer with various concrete protocols and network device settings for that, e.g., client/server, client/broker, server/servient ... it should be discussed in the Binding Templates

Lagally: current profile picks TD spec
… describing protocol binding (HTTP)

Ben: On Kaz's point. Core profile does not use protocol binding template.
… profile defines consumer is HTTP client, producer is HTTP server

Lagally: Does anyone see other alternatives to the 4 I mentioned

Lagally: back to Ben's proposal

https://github.com/w3c/wot-profile/issues/107#issuecomment-1062850204

Ben: the only option I see is #4
… single event model per profile
… core profile requires to be server&client
… each profile should only use a single protocol binding
… I propose separate profile ... for webhooks
… that profile can be composed with other profiles .. like core profile
… suggest also to rename core profile to http-json profile

Ege: +1

Lagally: implication, http-json has mandatory event model ?

Ben: yes, otherwise there is no interop

Lagally: just event mechanisms part of profile is probably not sufficient

Ben: mechanism setting property and event as client is difficult

Lagally: TD only for events does not make sense
… why exclude other interactions

Ben: high complexity having all devices being server&client

Lagally: use addon mechanism for event core+XX
… common baseline for actions and properties
… many use-cases don't need eventing

Ege: do not like "variants"
… variants.. what would mean core+webhook? servient to servient?
… conflicts with implementation complexity requirement

Lagally: SSE on cloud is not realistic
… it is not scaling

Ben: observing properties has same problem

Lagally: Correct
… device needs to send updated property notifications
… kills battery-driven devices
… to keep connection open

Ben: it might be that this profile does not fit this use-case

<Ege> +1

Ben: maybe it needs own profile

Lagally: It seems we don't find *one* profile
… suggest 2 profiles
… core+webhook
… core+sse
… not sure about longpoll

Ben: I don't this is the right way
… to go

Ben: 2 profiles
… core+webhook is wrong to think about
… 1. profile client vs server
… 2. profile client vs client

Lagally: We have different models in our mind.. I think
… all things cause implementation overhead
… easy way would be go on without any eventing

Ben: observing properties out also?

Lagally: Yes

Ben: Observation: If we remove events
… in TD cancelaction and queryaction is on risk also
… in profile not that much left
… core profile would be pointless

Ege: not completely useless
… constraining TD

Lagally: I think we have additional things that are causing problems
… e.g. oneOf values

Ben: for the WebThing project it looses attraction

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).