Meeting minutes
Minutes
Lagally: review of minutes from Feb 8, 2023
<mlagally> Feb-8
McCool: did create the wide review issues
Lagally: any objections to publishing?
… none, will publish
Wide Review and Explainer
<kaz> wot-profile issue 358 - Wide review
McCool: note that I generally set March 20 as deadline for review
Lagally: suggest a reminder on March 15 or so
McCool: suggest adding that to the agenda for the Profile call that week
Lagally: ok, that will be March 15
McCool: also explainer looks ok
<mlagally> w3c/
Lagally: I did merge the editorial fix for the explainer - PR 362
McCool: ok, I reviewed and was ok with it
PRs
PR 365
<mlagally> https://
Lagally: another explainer fix, removing some duplicate text
McCool: concur with merging
Lagally: (merges)
PR 364
Lagally: http security
McCool: (explains the discussion during the Security call)
McCool: so we discussed this in security and had a set of action items, Luca volunteered to make a PR
… but there were some feedback from Ben we needed to address
Lagally: (shows section "5.4 Security" from the diff)
<kaz> diff - 5.4 Security
Lagally: let's keep this open, and try another PR for simpler fix
… Luca, if you can add necessary change to this PR, we can merge this PR as well
Ege: what about Webhook?
… currently, security is a common restriction. right?
McCool: Security TF proposed we move the security portion under the HTTP Core Profile
… but Ben objected
… so we're putting it back
conclusion: Luca will make necessary changes to PR 364 so that we can merge the PR
PR 334
Lagally: Sebastian is not here, so skip it
PR 330
PR 330 - Cloud Events Message Format
Lagally: (shows section "11. Cloud Events Message Format")
diff - 11. Cloud Events Message Format
McCool: there was pretty good resource on Webhook security on the Web
… so the Security TF wanted to follow that
… looked at several resources
… on possibility is adopting to that kind of definition
Lagally: (shows related issue 224)
Lagally: (shows the cloudevents repo)
HTTP 1.1 Web Hooks for Event Delivery - Version 1.0.2
McCool: would add an Editor's Note
Ege: multiple comments
… why do we need to use time for informative part of the spec?
… think normative sections should be more important like sync/async
… not sure if this would be a good format for green-field Things
Lagally: we're working not only for green-field Things
... need this kind of clarification since there is no normative binding templates spec yet
Ege: cloudevents is putting metadata in the payload which is redundant in WoT since we have TDs. It mandates putting contentType, resource, cloudevents spec version in the payload which can be all in the TD and not in the payload
... also cloudevents is in the incubation phase of cloud native foundation at https://
Kaz: sounds like we all are not on the same page
Kaz: so would suggest we once go back to what we want to do for what kind of use case using which mechanism
… then revisit how to describe that within our spec like WoT Profile after that
<Ege> I am not objecting webhooks btw
<Ege> also if we are now discussing about supporting brownfield, we are breaking the entire design of profiles...
McCool: from my viewpoint, this is needed for compatibility with existing mechanisms
… Ben's alternative proposal is worth considering
Lagally: (shows one of Ben's comments including a table)
Ben's proposal with a table of Member/Type/Mandatory/Comment
Luca: two issues, one is web hooks, widely different approaches
… other is payload, not that closely bound to the pattern
… so could do payload separately, e.g. profile that does webhook+cloud events, and another one that is webhook+ben's proposal
… we don't have to make a decision of one or the other
Lagally: agree, I think we can have multiple profiles, and that is way out
Ege: not necessarily profiles in that request
… and if we allow combinations, they could multiply, if we have a lot of profiles, will lose interop
… and then it's not clear to a developer what they should use
… an don't really want to be recommending and inefficient approach
… that also raises implementation burden
Lagally: this profile is specifically for integration with cloud systems that use cloud events
Ege: still makes consumer very complicated, consumer has to support everything given in a TD
Lagally: we are still increasing interoperability with existing systems
Ege: not necessarily; if have two proposals, consumer needs to support both
Lagally: from implementation perspective, still just parsing JSON object, can ignore things they don't care about, not that hard
… would like to ask that we get some alternative PRs
McCool: in summary, agree with Lagally
… two proposals here
… let's move on and see the other issues
Kaz: my viewpoint, seems this topic is bigger than one section within profiles, and probably needs more analysis and discussion within whole working group
… ok with handling this as part of bindings, but then we need to discuss it there; it may also impact other specifications
McCool: also note that event mechanisms not in next charter
<kaz> [adjourned]