Meeting minutes
Agenda
McCool: Koster can't join us today, he has a conflict
Minutes
McCool: minutes looks good
… there's just a minor formatting issue
<kaz> Apr-19
Kaz: if we want I can change the style
McCool: that's fine
… any other concerns?
… ok minutes will be published
topic quick updates
McCool: we should talk about a test plan before the publication
… we are close to first publication check the current branch
PRs
McCool: we have 6 PRs
<kaz> PRs
McCool: two from Farshid and 4 from Ben
… however Ben is not here, we might need to wait
Farshid: Ben already knows the issues about his PRs, I suggest to create a branch and merge the pr there
McCool: are all Refactoring PRs?
Farshid: yes
PR 161
<kaz> PR 161 - Rename DirectoryDescription to ThingDirectory
<kaz> (McCool adds a comment)
<kaz> McCool's comment
PR 163
<kaz> PR 163 - Add pagination references and improve anonymous TD definition
Farshid: we don't have a query parameter to ask for un-enrich TDs in queries
… I discussed with Andrea about the format of enriched data
… we are thinking about flatting everything to have consistent look
McCool: I am worried about canonization and signing
… enriched metadata would brake signing
… maybe we could define an original option that force the directory to serve the original string
Farshid: it's a good option
McCool: with original we don't force a particular storage option, if the directory is confident that it can reproduce the exact same document it can even chose to store the TD in other formats
… the PR is not ready to merge, there are some issues still left
Farshid: actually the issues was already present and PR improve the current situation
<kaz> Preview diff - 6.2.1 Information Model
McCool: Yeah I've just noticed that statement that I was worrying about was previously added.
… ok then we can merge this and create an issue with follow up actions
… any other comments?
… ok I'll create related issues
McCool: maybe enriched contains sensible information like the creation time. So it might be a problem to make it the default
… issue created
Issue 165 - Add Ability to Retrieve Original TD
McCool: merging PR 163
PR 162
<kaz> PR 162 - Expiry date for registered TDs
McCool: I was not sure about the format of the embedded graph. I would use a not a proprietary format
… we need to export it to an svg file
Farshid: btw is not used in the spec, just file that is there
McCool: I see that you added the expires field as a date time
… I saw a few issues: what happens if the directory has policies more restrictive than the date requested?
Farshid: this negotiation is hard
McCool: I imagining a negotiation with errors, simply saying that the expiration date is too far in the future
Farshid: so should we had an assertion that the directory could implement this policy
McCool: yeah
Farshid: I can add it
McCool: let's keep this PR and include this proposal in the current PR
… about expire time do we want a Date or a Period?
Farshid: TTL is hard cause proxies may cause delays so the period will be elongated
… plus there are also problems for caching
McCool: I agree the delays might be a problem.
Farshid: HTTP has both mechanisms they have different meanings do we want to support both
McCool: For registration I think we need both but in the DB we might choose one
Cristiano: how the delays are useful?
McCool: not sure, but at least we can think about cases where devices does not have a RTC clock
… so that they can't really provide a specific date
Farshid: I feel that putting time of retrival in a TD is not the right place
… what about the remaining life time?
McCool: it is another option
Farshid: could we try to define applications that really needs about this feature?
McCool: ok so we conclude to make few updates and then merge
testing
McCool: what do you guys currently have as test cases
… if we have automated testing systems
… we can apply it to multiple implementations
… the other option is to let the implementers assert a particular function
Farshid: we have a test suite
… I could turn it as a github action
McCool: we could have a repo
… it would be optimal to have a csv file that reports if an assertion pass or fail
Farshid: I can format it
<kaz> [adjourned]