Meeting minutes
Issues around Architecture
<kaz> Issue 15 - Architecture Brainstorming
<kaz> Issue 16 - Architecture Restructuring
<kaz> PR 82 - Add Architecture as a normative deliverable
<kaz> Ben's comments on TLS
McCool: Ben's remark regarding TLS
… some assertion in the TD document should be moved in a separate document
Lagally: we do not have other descriptions: such as how to describe consumers
… , servients, ...
… TD is not enough
<kaz> Lagally's comments for PR 82
McCool: We have assertions in the wrong documents and we should refactor them
… another question is: security aside do we have other assertions that should be refactored
… it is not obvious which are the assertions without going through many pages
Kaz: My feeling about this long discussion is that it that this discussion is not fully related to the charter discussion
… We should focus on the Architecture specification itself rather than diving into the assertions and testability of runtimes.
Luca: would agree with Kaz :)
… would try to summarize my points as well
<Mizushima> +1 kaz
Luca: is WoT "glue" or "full stack"?
McCool: agree there are multiple points mixed up here
McCool: We have statements about WoT as whole
… is WoT about Thing Description or how to implement a full stack about connected devices
… (summarising as a comment in https://
… do we need to do normative statements regarding WoT as whole?
Kaz: It seems to me that people have started to work on detailed analysis of assertions one by one based on their own views, but we should rather see the whole structure of the Architecture specification starting with the sections first, and then subsections if needed.
McCool: I'm open to suggestion on the procedure
This issue focuses Architecture. But this issue is not only Architecture. We should think what is normative and what is informative in all of documents. Then We should decide to add Architecture as a normative.
McCool: The Charter requires us to mark the document as Rec or Note first
Lagally: I think we need to introduce all the components of WoT into the Architecture in a non-ambiguous way.
McCool: if our ambition is having a full stack, we need a central place to store it
Ege: it is a good question and I agree our ambition is being a full stack but we are far from there
… I would say we need to all agree if we have a stack of components you must use all or a set of components you can mix and match
Luca: If we want to address the full stack ambition and not use Architecture, the activity on Profiles is a way to bind together parts that should work together. The problems are different from for legacy systems.
McCool: Talk a lot on the greenfield vs brownfield
… but we do not separate the discussion clearly
… we maybe need to make it clear the big picture on greenfield in the architecture
McCool: I think I we want to make normative statements regarding WoT as whole, we should put them in Architecture
<mlagally> +1
Ege: Assuming we go for full stack, we need more confermance effort
… we to make sure the assertions must be read by implementors
… implementors my miss them if they are embedded deep in architecture
… the two problems are: if they can be implemented and if they can be found
Luca: the best way would be elaborate the Profile
… HTTP Basic Profile should have links to testable assertions
Kaz: The discussion we're holding now itself is useful. However, for the charter discussion we should focus on the content of the Architecture specification and should not dive into the details of testability of the assertions. If we really need to think about the testability of all the assertions from the Architecture spec, we need to see the other specs as well. However, that's too much for Charter discussion now. So my suggestion is simply skimming the Architecture spec section by section first to see which sections and contents to be normatively defined.
McCool: We can avoid conformance testing as it is done in the web as alternative
… conformance testing can be through profiles
… but is not required for wot as whole
McCool: My preference is to clean up the document instead of a full overhaul
… we keep architecture normative, but we rework the document to improve the visibility
Ege: I have not big objections, but
… if we refactor the document and architecture does not have assertion can we demote it to Note ?
McCool: it is easier to demote a Rec to Note that the other way round
Ege: We can add a security Rec document to make room for it
McCool: A Rec Security document feels premature
… we can consolidate Architecture and split in the next charter
… better to make sure the documents aren't too short first
Kaz: As already mentioned, people have started their own partly detailed review of the Architecture spec again within this PR 82. However, if we really need to review the Architecture spec again, we need more detailed and well-organized reviews.
… I suggested we try that one year ago, but we failed to finalize that reorganization of the spec in the end.
… If some specification, e.g., WoT Architecture, does not have any normative text, which will be extracted as a normative assertion, that specification will be automatically an informative one.
McCool: there are assertion in architecture so it is premature to mark it as informative now
Kaz: Right. For example, Fundamental Concepts in addition to security portions.
Lagally: I prepared some PRs that should be helpful
McCool: I'd try to group PR and Issues and label the ones that apply to the Charter
McCool: We need to find a reasonable compromise that meets the targets
<kaz> [adjourned]