Consider whether this makes more sense as a Note [TAG feedback]

[rhiaro]

Having reviewed all of the MUSTs and SHOULDs in the specification, our thought is to break the Security and Privacy sections into a separate, fully normative, Security and Privacy document. Then, to work through the remaining normative statements to see which are strictly necessary (ie. for interop, and testable) and of those which can fit in existing REC-track documents. The remainder of the Architecture document would work well as an informative NOTE, which provides additional background and context without implementers needing to sift through it to find what they actually need to design and build conforming Things.

We recognise that you've only asked us to review the difference between 1.0 and 1.1, and this kind of feedback is coming as a result of me personally not having been involved in the earlier review. However, given comments [1, 2] about how hard this has been to review, we'd say it's never too late (or too early) to make specifications more readable! We would be more than happy to re-review if this change is made.

[1] 2022-05-19 PING minutes

[2] 2019-07-11 previous TAG review comment

(From w3ctag/design-reviews#736)

Related issues (suggest resolving these first):

• Review for unnecessary normative statements [TAG feedback] #817
• Review for redundant normative statements [TAG feedback] #816
• Improve security section to address TAG feedback #811
• Markup normative sections in Chapter 8 #808
• Fix normative references / convert to informative, where applicable #809

[mlagally]

Arch call on Aug 4th:
In this charter period, we decided to update the 1.0 document which is a REC.
Changing the status from REC to Note and other substantial changes at this point is not feasible.

[benfrancis]

For the record, I strongly support the idea that WoT Architecture should be a non-normative Note. Mozilla actually provided that as formal feedback on the Working Group Charter in 2019, but it was not adopted. I have long said that all normative assertions should be moved to the other normative deliverables in order to simplify implementation.

Note that there is also an existing separate Security Best Practices document and privacy and security considerations sections inside each normative specification.

There was an effort during this charter period to move many assertions which impact the Thing Description specification to that specification, which I think was an improvement. I would support going further than that by moving/removing all normative assertions and making this document an introductory informative architectural guide and overview of the various WoT specifications, whether that happens in this charter period or the next.

[mlagally]

@benfrancis:
We discussed the Mozilla comments (which I believe was provided by you, please correct me if I'm wrong) on the TAG feedback back in 2019 and decided as a group to not change the state.

We also discussed the recent TAG feedback in the Arch call on Aug 4th.
The Architecture 1.1 document is just a revision of Architecture 1.0 and lays the basis for the family of WoT specifications.

[mlagally]

Discussion in Arch call on 1. Sept:
We need a place for global assertions, e.g. for security. We could have a normative security document, however this would require significant reworking, which is not feasible in this timeframe. Also it would be beyond the scope of the current charter.
That said, we are open to discussing this further with TAG and W3M.

[mlagally]

Arch call on Sept 8th.:
Discussion about scope and future deliverables of the Architecture TF in the next charter period will be discussed at the upcoming TPAC meeting.