Meeting minutes
Agenda
<Ege> https://
Minutes
(goes through the minutes)
approved
TD
updated WD
Sebastian: Kaz is working on the document check
Kaz: already installed the .htaccess file for v1.1 namespace redirection
… waiting the update by the w3 server
Testfest
Sebastian: Please implement as much as possible new features from TD 1.1 spec
… and join the Plugfest/Testfest next week
Wide review
PR 1382 - Create Security and Privacy Questionnaire Answers for Ver 1.1 CR Process
Sebastian: comments on the security/privacy questionnaire answers
… Lagally also gave comments
… we should not merge this today
… let's revisit this next week
Explainer
Sebastian: generated a rendered version Explainer
(goes through the updated Explainer)
Accessibility
a11y-request Issue 21 - Web of Things (WoT) Thing Description 1.1 2021-01-26 > 2021-03-15
Sebastian: waiting for response
I18N
i18n-request Issue 171 - Web of Things (WoT) Thing Description 1.1 2021-02-02 > 2021-03-30
Sebastian: Ege, have you talked about TD issue 1416?
Issue 1416 - Use of direction heuristic needs work
Kaz: there was discussion on this Issue as well during the prev call
Sebastian: (looks at the prev minutes)
Ege: can look into it
Sebastian: (looks at Issue 1412 as well)
Issue 1416 - Languages of service-doc?
Sebastian: content negotiation?
… wondering how HTML handles it
Ege: there is some tag for that purpose
Kaz: content negotiation itself is handled by the HTTP server like Apache using .htaccess, etc.
Ege: any REC about that?
Kaz: not sure but should be some page by i18n group
Ege: will look into it by the next meeting
TAG
design-reviews Issue 715 - WIP: Web of Things (WoT) Thing Description 1.1 - Security Review
Sebastian: ongoing
PRs
Sebastian: (goes through the PRs quickly)
PR 1402 - WIP: Additional Security and Privacy Considerations
Sebastian: need McCool's participation
PR 1419 - Add auto value for the in field of SecuritySchemes
Sebastian: hold off for a while
… Jan, status?
Jan: creating another PR
related PR 1421 - feat: Add AutoSecurityScheme
Jan: not sure what would be the best solution
Sebastian: for what case, the auto security scheme to be used?
Jan: not actually sure if the use case is already covered by no security
… maybe we can continue more discussion during the Security call
related Issue 1394 - name and in fields for BasicSecurityScheme and DigestSecurityScheme needed?
Sebastian: maybe you can discuss this during the next Security call
Jan: currently the security schemes are HTTP-centric
… probably fine with using it, though
… would discuss this during the next Security call
Kaz: note there will be no Security call on Mar-14
… so probably Mar-21
Sebastian: Philipp is also attending the Security calls. right?
Jan: yes
Sebastian: let's wait a bit more then
… would be better to defer this
<Zakim> dape, you wanted to shall we mark this PR as WIP
dp: make sense to mark it as wip?
Sebastian: (change the status of PR 1421 to "Draft")
… (also adds comments to PR 1419)
PR 1419 - Add auto value for the in field of SecuritySchemes
Sebastian: (then close PR 1419)
… new PR already available
related newer PR 1421 - feat: Add AutoSecurityScheme
Sebastian: (then move ahead)
PR 1331 - fix: move CBOR content types their own table row in section 5.3.2
merged
Issues
Issue 1408 - Actions with cancel and query operations, the meaning of input and output, dynamic href
Sebastian: (shows the Profile spec as well)
wot-profile 6.3.2.1.3 Asynchronous Action Response
Sebastian: need to see if this need is valid
… the example on the Issue itself is not clear enough
Kaz: there was discussion during the Scripting and Profile calls as well
… I strongly suggested we work on concrete use case description including detailed scenario about devices and network setting
… because this feature would require us to consider history management, grouping of multiple devices, session handling, etc.
Sebastian: right
… clarify the need for this feature is needed
… would defer to the next version
… maybe not ready for REC during this Charter period
Ege: if something is implemented but only for one Profile is not enough
… not only about this proposed feature
Kaz: which document do you mean?
… as for TD, we should think about the assertions defined by TD itself
… don't need to refer to the Profile spec
Sebastian: we should clarify some of the features might be available only for some of the specific Profiles
Kaz: we don't need to mention that within the TD spec because TD is generic data model definition
dp: for just looking at TD, the description on 'op' is vague
Kaz: in that case, we should improve the definition within TD itself
Ege: additional information needed for protocol, etc.
… subscribe event as well
… specific protocol binding like MQTT
… maybe it's ok
… but we should add information on invocation of events
… cancel action for payload, etc.
Kaz: I'm also aware of the potential dependency among specs, and that's why I repeatedly asked all the Editors to look into the issues about dependency among specs last year
… and I thought all the issues have been resolved
… however, if we still have any problems with dependency among specs, we should look into the issues again
… but if the problem is about this feature, we should revisit this for TD Ver. 2.0
Sebastian: yeah, would revisit this for TD Ver. 2.0
… maybe we can remove some of the terms (marked as at-risk) listed here within the TD Ver. 1.1
Kaz: yeah
… if we really want, we might be able to start further discussion for 2.0
… but probably we should concentrate on wrapping up 1.1 given we're planning to transition to CR soon
Sebastian: (adds comments)
… so far the query operations are kept in the spec
… additional text as an Editor note to be added that this p values are currently used by the WoT Profile document
… most likely the values will be marked as at-risk
Kaz: the Profile document currently includes some of the implementation guideline in addition to the definition of Profile itself
… maybe we could move that portion from the Profile document to the TD spec at some point
Issue 1417 - Default values of readOnly and writeOnly for non-property affordances
Sebastian shows TD section 5.4 Default Value Definitions
Jan: good solution for issue 10
… can be postponed
Sebastian: but one example already using this
… "writeOnly": true
Temperature Event with subscription and cancellation example including [["writeOnly": true]]
Sebastian: personally think this is an ugly example...
… open to change this itself
Ege: issue with defining default values
Sebastian: ok
… let's work on this
… (assigns it to Sebastian himself)
Content Type for Thing Model (IANA registration needed)
Kaz: if needed, this request should be fine
… but for TD Ver. 1.1, we should mention we already got registered for application/td+json
… and then explain we'd like to register an additional media type for application/tm+json and also extend application/td+json with some more suffixes
Sebastian: ok
Issue 1420 - Restricting the context url in JSON Schema
related resource on JSON Schema
Ege: currently three name spaces are allowed
"https://www.w3.org/2019/wot/td/v1",
"http://www.w3.org/ns/td",
"https://www.w3.org/2022/wot/td/v1.1"
Sebastian: would people use the new namespace for TD Ver. 1.1
… and also we should allow the old namespace too
… not sure how to express it for JSON Schema
… ok with the proposed way
Kaz: for clarification, you mean "http://
Ege: yes
Sebastian: Ege will work on that by Monday for the Testfest
Issue 1407 - Additional composition mechanism for Thing Models
Sebastian: OK to talk about that next time?
Jan: maybe asynchronously on GitHub
Next week
Sebastian: no TD call due to the Plugfest/Testfest
… please join the event instead
[adjourned]