Meeting minutes
phila: has anyone anything to share?
pchampin: Two things, one of them is about the DID WG, which has some intersection w/ this group.
pchampin: A survey went out for the DID WG participants two days ago, we are polling group participants about the charter. If you haven't provided feedback yet, please do.
pchampin: The second item is that I submitted an implementation report for URDNA2015 in Rust, it's one of the PRs that I added to the Agenda.
pchampin: I'm claiming success on that. :)
Round the room updates
Pull request 101 on privacy considerations
yamdan: this PR is a simple rephrasing of the previous one, which was more complex
… it has been approved by several people already
… I just want to make sure if I can merge this one.
phila: the only reason to delay would be waiting for TallTed's review
<dlongley> +1 to merge PR 101
phila: but OTOH, we need this quickly, and it has been approved by many people already
<Zakim> manu, you wanted to support of the PR.
manu: +1 to merge, and thanks to yamdan for making this proposal quickly
<dlongley> +1 thanks, Dan!
phila: earing no objection, let's merge it
Pull request 100 on identifier mapping
phila: a lot of back and forth about this one; anyone has anything to say?
dlongley: I'm happy with this PR
… yamdan has concerns, about which I made suggestions that gkellogg merged
… yamdam does this address your concern?
yamdam: if we can note the possibility of @@1 I am ok with merging
phila: since you have a condition, could you please add a review in the PR?
dlongley: the link above is the text that is meant to address that concern
… [reads the text]
yamdam: it is almost perfect for me
<dlongley> even the same implementation could do it
<dlongley> +1
yamdam: I just want to add a little something -- will make a suggestion
ivan: the PR itself is fundamental, and contains a lot of things
… I wonder if it would not be better to merge it,
<yamdan> +1
<dlongley> +1 to that... Dan?
ivan: and make a separate PR for yamdam's suggestion
<dlongley> +1 then
+1 to merge
<dlongley> +1 to merge now and update the note subsequently.
phila: ok, so yamdan please merge #100 and make a new PR
<dlongley> +1 to close PR 99 (original privacy considerations PR)
phila: jumping back to the previous topic (sorry)
+1 to close original (pending close) item
<yamdan> +1 to close PR99
phila: since we agreed to merge yamdan's new PR on privacy issue, we can close #99 without merging it
PR 105 w3c/rdf-canon#105
pchampin: This is an implementation in Rust, hadn't run the test suite, but implementation that I just released passes all of the tests... that's one more implementation.
phila: this is uncontentious, then
Issues before wide review https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+label%3AHorizontalReview
phila: we will soon go to CR, with existing complete implementations, this is good
… we need to check the horizontal review
… a11y and i18n are done
… we have done privacy, but not security
ivan: what do you mean by "done"?
<phila> w3c/
phila: for i18n we had feedback from Adisson back in January
… w3c/
… and his response was "you are good to go"
ivan: the process is always changing, I though we need an explicit approval
phila: do you want me to ask Addison for a more formal approval?
ivan: yes, that would be better
<phila> Issue 69 is a11y w3c/
phila: we asked for a11y review in January, I said "we probably don't need anything"
… Janina responded "you are probably right, but let's go through the process"
<phila> Security section https://
phila: but no feedback since. Need to ping them.
phila: privacy done (thanks again yamdan), need to do security
… so that we can request TAG review
… yamdan would you be able in the coming weeks, to turn issue #70 into some text in Section 7 ?
yamdan: I can give it a try; but it might not be sufficient
… I don't have any experience in formal verification
pchampin: I have contacted a few people that I know in the formal verification space. The last feedback I got is that the challenging part of the algorithm is that it recurses. Recursion can't be known a-priori.
pchampin: I have to go back to my email to get more detail.
seabass: I know some people who have done that; from what I understand it is quite expensive
phila: I'm starting to be worried about this
ivan: where does this requirement for formal verification come from?
manu: this came from an earlier discussion in the WG. Someone asked if we had a formal verification of the whole algorithm.
… A lot of programs that many people use everyday don't have a full formal verification. This should not be scaring us excessively.
… Many people have reviewed the algorithm and found no issue.
… Many W3C specs don't have any formal verification.
ivan: so this does not come from the official W3C security review. This is us being very diligent.
… Let's not wake up sleeping dogs, and let's not keep this section saying "incomplete".
<pchampin> +1, this is a nice to have, but not a requirement
dlongley: we should mention that implementers could (and should) have a timeout after which their implementation bails out
ivan: this should indeed be in the security consideration
phila: dlongley, you made that point from the start, and I'm pretty sure there was consensus on that
… so I thought it was already in there
ivan: it is good to document dataset poisoning
pchampin: I think that there *is* a parameter in the algorithm to limit the number of recursions
dlongley: I don't think there is one in the current algorithms. And this is just one of the way of implementing a timeout.
<yamdan> Thank you dlongley for your help!
<Zakim> ivan, you wanted to comment on the tag
ivan: can we move on the TAG's review?
phila: I was waiting for the security section, but apart from that we should be good
ivan: the TAG also asks for an *explainer* (because they have so many things to do)
… Could the explainer that was attached to the proposal be good enough for the TAG?
phila: I hope so
… I'll make sure they have all they need.
… I really would like to go to CR before the northern hemisphere summer holiday.
… We seem to have covered all issues marked as ms:CR
… Does anyone see anything other issue that we should address in priority?
[crickets]
phila: let's walk through them all then.
issue 16 w3c/rdf-canon#16
<ivan> +1 to Dave
dlongley: the input of the algorithm implicitly excludes duplicates
… there are no duplicates in an abstract dataset
… so I'm inclined to close it
+1, agree with dave, feels like duplicates are handled by the processing steps
ivan: ok to close, but we should document the response
<pchampin> +1 agree with dlongley
dlehn: I'm not sure that all parsers reject duplicates; this is an implementation detail
ivan: it is still out of scope, we do not define parsers
<dlongley> +1 to ivan -- it's the same as "is the N-quads input syntactically correct"
ivan: likewise, we do not say "check that the input n-quads is syntactially correct
pchampin: I sympathize with Dave Lehn's points, my implementation also supports multiple occurences of the same quad in the dataset... maybe a note would be useful... on the oher hand, I do agree with the points where this is in our purview.
pchampin: Do we want to say anything in a note?
ivan: We don't need to say anything, do we?
pchampin: But if your implementation can have duplicates, do we need to say anything?
phila: It feels like "garbage in / garbage out" -- feels like there are so many statements like that we could say.
seabass: Where would such a note go?
ivan: Don't know. :)
phila: That's the issue :)
phila: if PA wants this to be a note, he gets to write the PR. :)
<phila> subtopic Issue 54 w3c/
dlongley: I'd like to just answer and say "no"
… we can't add anything to the dataset without changing the hash
<yamdan> +1
seabass: when you create the dataset, you may want to use the c14n algorithm to mint your ids
<dlongley> w3c/
<dlongley> ^writing what seabass said
seabass: should we support that use case?
phila: IIUC, the answer to the question is still no
seabass: obviously, the answer to the question in the title is "no", but I read the issue as asking a slightly different question
ivan: Tobias has long worked on nanopublications
… we could ask him to write a note about how to apply rdf-canon with nanopubs, but no impact on our core work
dlongley: agree with ivan
phila: we closed several issues, making progress, thanks everyone
… markus will be chairing next week