Meeting minutes
Minutes
Lagally: (goes through the minutes)
… have the discussion done by the Security TF?
McCool: not yet
… will add it to the agenda for the next week now
<mlagally> https://
<mlagally> https://
https://
https://
McCool: btw, mandating HTTPS might be difficult
… we're looking at several things
… but can't mandate HTTPS, e.g., for local networks
Lagally: what we could do is demanding something different
McCool: it's a complicated object
… requiring TLS for home devices would get push back
… it's under discussion by TD as well
… the problem is that the other approaches also have problems
… note that we need to add an additional section on Security and Privacy too
Issue 182 - New section: Security considerations
<McCool_> https://
McCool: just added the discussion to the next agenda for the Security TF
… OK with the minutes themselves
Lagally: ok
approved
Publication
McCool: does that mean we've not got consensus?
Lagally: not for all
… also some of the issues can be deferred
Issue 190
Issue 190 - Consider splitting Use Cases & Requirements out into a separate document
Lagally: (removes "blocks publication" label from issue 190)
Issue 158
Issue 158 - Define a protocol binding for readmultipleproperties?
McCool: not a blocker but an improvement
Lagally: ok
… (removes the label)
Issue 151
Issue 151 - Consolidate Error responses
McCool: we don't need to list all the detailed error responses there
… also should we handle error 3xx ?
Lagally: (shows the HTTP error codes)
McCool: not all the browsers handle the error code properly
Kaz: we should be consistent with the other SDOs' error codes
… so some survey would be useful
McCool: should be consistent with browsers too
Daniel: not sure how to deal with the details here
<benfrancis> Sorry I'm not able to join the call as I'm out of the office today, but lurking in IRC.
Daniel: the details on error handling subject to change
McCool: two possibilities there
… one extreme which is consistent
… and the other is consistent with the current browsers
Kaz: btw, the error codes themselves usually will be returned from the Web server
… so we need to see the Web servers' behavior (as well). right?
McCool: yeah, browser behavior and the codes
… standard codes as errors
Ege: this is about the profile for HTTP. right?
Lagally: yes
Ege: I myself don't handle 3xx codes within my implementations
… we should not block the client based on the errors
McCool: the consumers should handle it
Ege: 301 should be an error for WoT, though
Lagally: let's do some quick assessment
… should be handled as errors?
… 300: no
… 301: no
… 302: no
Daniel: probably "no" for all?
McCool: Consumer may consider a 3xx code as an error
Kaz: probably we should look into concrete scenarios a bit more
<McCool_> https://
Kaz: we don't need to describe it using the ordinary use case template
… but should clarify the situation and scenario with the WoT components
… i.e., Consumer - intermediary - Thing
McCool: we could look into some blogs on 3xx errors as well
Ege: what about proxy setting?
Kaz: would suggest we think about several possible settings including that
Ege: would ask Ben also for opinions
Kaz: we should see what should be done for those who have been participating in Plugfests
… e.g., WebThing, ECHONET, OPC-UA, ...
Lagally: can we ask people about this during the Plugfest call?
McCool: let me add that to the agenda
PRs
<benfrancis> Note that for a 401 Unauthorized error code there's a discussion about how a consumer should react to that as part of WoT Discovery https://
<benfrancis> If WoT Discovery solves that, then we may want to refer to that text. See https://
PR 192
PR 192 - WIP: Webhook HTTP profile
Lagally: please review the PR
McCool: should have 2 sections
… 1. describes what Web hook is like
… 2. how to use that
… real question is identifier and payload
PR 193
McCool: just created a draft Explainer for Profile
Lagally: let's merge this (as a starting point)
merged
Lagally: we 13 open PRs now
… let's continue the discussion next week
PR 182
PR 181 - Implementation Report and Assertion Markup Fixes
Kaz: need to move to the main call
… so let's discuss it next week
[adjourned]