Meeting minutes
Sebastian: next week we will have Joel Bender from ASHRAE for BACnet binding discussion
Agenda
minutes
<kaz> Feb-9
Sebastian: any objections to the minutes of last week
<kaz> approved
publication plans
Sebastian: tag is very busy so it is good that we are starting
Sebastian: I would like to go over the issue mmccool has opened. Issue 1382
<kaz> PR 1382 - Create Security and Privacy Questionnaire Answers for Ver 1.1 CR Process
Sebastian: about the explainer, we talked also in the main call. Let's simply take the explainer in the web page
https://
Ege: the issue linked above is from marketing. the explainer lacks the discovery and profile
Kaz: there is a template for the explainer
Sebastian: if there is one, we should follow it but I don't think that we have used one last time. The previous explainer looks like a markdown document
<kaz> TAG review form for TD 1.1
Kaz: there is a specific form for the TAG review as above, and we need to generate an updated version of the TD Explainer for that form. probably we can look into several recent review forms and Explainers for the other specs as examples.
Sebastian: let's look at an example
Ege: this is more like guidelines
Ege: do we write one document or one for each tf
Sebastian: it would be better if each tf writes their own
Kaz: I suggested somebody (probably McCool :) generate an initial document and each TF Editor generate their own document based on the initial one as a kind of template.
… and McCool mentioned his status during the main call, so we should ask McCool about the progress
Ege: I think it would be nicer to write a common intro and reuse
Cristiano: what do we do about maintaining these explainers?
Sebastian: security privacy is being handled by the security TF
Sebastian: (writes a comment in issue 1396, please check that in review)
<kaz> Issue 1396 - Complete TAG/Security Wide Review Request
Sebastian: title and description has some security implications
Daniel: so it is indeed correct that an implementation should take carethat no code execution happens
Kaz: we should look into the other JSON-LD based specification like VC and DID, but I personally think we should have a SHOULD assertion that the producer should not put executable content in there
<kaz>
If implementers feel they must use HTML, or other markup languages capable of containing executable scripts, to address a specific use case, they are advised to analyze how an attacker would use the markup to mount injection attacks against a consumer of the markup and then deploy mitigations against the identified attacks.
<kaz> Verifiable Credentials Data Model 1.1
Sebastian: we have already some sentences about this
Cristiano: it is difficult to actually check if a string is code and we are saying that the title can be used for UI (without any checks)
PR 1391
<kaz> PR 1391 - delete ext-td-json-schema-validation.json
Sebastian: this was redundant and old
Sebastian: let's merge
PR 1331
<kaz> PR 1331 - fix: move CBOR content types their own table row in section 5.3.2
Jan: json and cbor has different encodings so they should be separated
Sebastian: I have a past with these binary xml representations
Jan: this is a good compromise
Daniel: yes I think so too
Sebastian: so you want to have JSON/Cbor and XML/EXI?
Jan: yes I will update the pr
PR 1341
<kaz> PR 1341 - schema term in expected response
<kaz> sk: should be discussed for TD 2.0
PR 1342
<kaz> PR 1342 - reorganize how to use uri schemes
Ege: benfrancis did not like full flexibility of the uri scheme. michael lagally and benfrancis did not like referencing to the binding templates
<kaz> diff - 8.3 Protocol Bindings
Sebastian: node-wot has more protocol than what is allowed here. we should be flexible
Kaz: we can use the registry document track or modify the binding document to specify this
Kaz: we can also make some parts of the document a registry format
Cristiano: I think the long term solution would be registry
Ege: I think we should close the PR, continue discussion in the issue so that we can link to the binding spec
… we need to decide what to do with the binding templates
PR 1331
<kaz> PR 1331 - fix: move CBOR content types their own table row in section 5.3.2
Sebastian: you can do the edit and merge
Issue 1394
<kaz> Issue 1394 - name and in fields for BasicSecurityScheme and DigestSecurityScheme needed?
Daniel: we should be careful removing stuff due to backwards compatibility issues
Registry Note (revisited)
<Zakim> kaz, you wanted to mention a better example of registry spec: https://
Issue 1399
<kaz> Issue 1399 - ThingModel Placeholder limited to simple types
Sebastian: thomas is not here though
Cristiano: I think it is clear though
Cristiano: for him it was not clear that the value can be objects since the example does not contain
@JKRhb here is an example
Cristiano: To me it was clear but for him it is not for him I think
Sebastian: there is this npm tool but we cannot reference to a tool from the spec
Sebastian: (the comment he is writing summarizes the discussion)
Issue 1390
<kaz> Issue 1390 - PropertyAffordance section is missing type specific in "vocabulary terms" table
Ege: so property aff inherits data schema and number schema inherits data schema but there is no relationship between number schema and property affordance
adjourned