Meeting minutes
Agenda and schedule
<Ben shows the agenda for today>
Kaz: is the schedule plan in the agenda?
Ben: there is a PR available about this
Minutes
Ben: any objections?
<no>
Ben: minutes are approved
PRs
PR 426
<kaz> PR 426 - Re-work HTTP Webhook Profile - closes #423
<Ben shows the content of the PR in a HTML pre-viewer>
<kaz> section "8. HTTP Webhook Profile" from the preview
<Ben goes through the Example codes, e.g., 48 and 49, referring to the WebSub Recommendation>
Sebastian: if you go back to subscription...
… section 8.2.2.1
… Example 57
… where the Listener came from?
Ben: the URL can be any URL
… it's just intended to be unique
Sebastian: what about the callback URL?
Ben: (shows Example 44)
… no way to describe the payload here
Sebastian: regarding the [[ subprotocol: "webhook" ]]
Ben: we've not invented the term for webhook here
<kaz> TD Issue 2085 - Add a schema for unobserve/observe property
Ben: (describes another issue around schema for unobserve/observe property)
Luca: based on TD1.1 we can not much do
… see this as an interim solution for now
Sebastian: from what the additional annotation come from?
… this is always possible
… Modbus binding may have polling term
… can wait until 2.0 for those terms
Ben: so far this PR has got a support from Luca
… any one to give more positive reviews?
… this is a big PR, so not necessarily get merged today
Sebastian: would suggest wait a bit
… will ping Ege again
… at least what you presented today to us looked nice
Ben: ok. cool
Luca: general consensus around the big PR
… shall we put a deadline, e.g., by the end of your vacation?
Ben: would go for asynchronous reviews
… if we can get more supportive reviews, we can merge this
PR 427
PR 427 - Re-work Links section - closes #255
5.6 Links from the preview
Ben: (goes through the preview)
… basically simplified the table here
Sebastian: I like the idea
… the original content was copied from the TD spec
… my only question is the relationship with the Bindings registry
… maybe should be maintained on the registry side so that the content can be maintained nicely
Ben: that's true
… good way for TD 2.0 and Profile 2.0
… but link information to be clarified for reach profile within the Profile 1.0
Sebastian: would be nicer to have all the related information within one specific document
Luca: for targeting TD 1.1, would agree you have well-defined subset
… given the time constraint, this PR looks good for 1.1 version
Kaz: would agree with you all (Ben, Luca and Sebastian)
… this PR itself is for Profile 1.0 which works with TD 1.1
… so we can merge this PR itself
… but probably it would be nicer to explicitly describe that plan, e.g., within the introduction section
… we don't have to explain our plan within each subsection
Ben: yeah
… please open a new Issue about that
ACTION: kaz to create a new issue about our plan within the Intro section
Issues
Issue 320
Issue 320 - Accesibility assertions are not specific enough
Ben: who can work on this issue?
Kaz: we should aware Profile 1.0 is only a Note and this issue may be postponed for 2.0 REC
Ben: actually, the text here itself is not really good, and need some modification...
Kaz: ah, in that case, we should modify the text :)
Issue 367
Issue 367 - PR #364 introduced a duplicate conflicting assertion
Ben: the current definition about security is confusing
Sebastian: I can create a PR
Issue 373
Issue 373 - Mismatch with MUST clause and examples in default language section
(Ben to work on a PR)
Issue 347
Issue 347 - Clarify OAuth schemes - consider requiring Bearer tokens only
Ben: Bearer tokens may expire quite soon, such as every 10mins. How to handle this?
Sebastian: suggest to talk this with McCool
Kaz: whole WG need to think about which specification really needed to describe what level of security mechanism
Ben: please take some of the open issues and create PRs. I will not be available next week.
<kaz> [adjourned]