-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web of Things (WoT) Thing Description 1.1: TAG and Security Review #715
Comments
Ready for review. |
Hi, I have a clarification question: does this specification aim to work only for the IoT devices that have an IP address? |
Hi @maxpassion :
We have looked at your question at the TD call of 20.04. There can be two parts to this question:
If you would like more information, we can schedule a joint call or you can join our main call (https://www.w3.org/events/meetings/18c35c2a-47d6-44fe-b198-e438256544f3/20220427T080000) |
Hi folks - we discussed in today's TAG call. We're largely happy with this. We'll keep this open until we get the review requests for the other WoT items - particularly the architecture - so we can do a more thorough pass. |
Hi @mmccool! Thanks for this. We've reviewed it in our W3C TAG meetings this week. Apologies for the delay; we wanted to look at this in parallel with (our review of Web of Things (WoT) Architecture 1.1. It looks fine to us, and we are happy to see the strengthened security and privacy work. We also note that your issue 791 from our previous review, should be clearer about where the definition of the HTTP Protocol Binding is, is still open. Can you tell us a bit about your thoughts/plans for this? It looks like you're choosing to defer it — we are curious to hear if it's causing you trouble or why deferring it made sense for the group. Many thanks! |
Thank you for the positive comments! Regarding the HTTP Binding Issue: Until somewhat recently, the binding templates document was a monolith with everything put together. Now, each protocol has its own document that can be clearly referenced. However, with TD 1.1 we want to stay backwards compatible and we cannot remove such an important part. With TD 2.0, this will be possible and it would make more sense that way. |
Thanks, @egekorkan — that's helpful. We'll close this then, and put the bulk of our feedback on Web of Things under our TAG design review for Architecture 1.1. |
Braw mornin' TAG!
I'm requesting a TAG review of the Web of Things (WoT) Thing Description 1.1.
In the WoT Architecture, a Thing is defined as an abstraction of a physical IoT device such as a sensor (temperature, CO2, ...), an actuator (lamp, motor, ...), or a virtual entity (e.g., composition of one or more Things, a weather service). The Thing Description (TD) provides descriptive metadata for a Thing's network interface.
Further details:
You should also know that...
In the Thing Description 1.1 specification, text and table entries highlighted with a yellow background will indicate a feature associated with an at-risk assertion for which insufficient implementation experience exists. When an entire section is at-risk the words "This section is at risk." will be placed at the start of the section and highlighted with a yellow background.
There are also some related informative documents:
During the TAG review period, we plan to update the test results in the implementation report to reduce the number of at-risk assertions as much as possible before CR submission. The link above refers to the master branch of the repository, not the TAG-review branch.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
WIP! Will delete below only once this issue is complete and the referenced documents are ready for review.
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
The text was updated successfully, but these errors were encountered: