13:58:04 <RRSAgent> RRSAgent has joined #rch
13:58:08 <RRSAgent> logging to https://www.w3.org/2023/05/24-rch-irc
13:58:09 <Zakim> Zakim has joined #rch
13:58:25 <phila> meeting: RCH Weekly
13:58:31 <phila> agenda: https://www.w3.org/events/meetings/7b261df9-b2aa-4247-a57e-3d61dfc5b176/20230524T100000#agenda
13:58:31 <agendabot> clear agenda
13:58:31 <agendabot> agenda+ Scribe (most recent first) Manu, PhilA, Gregg, seabass, markus_sabadello, DLongley, pchampin, Ahmad, TallTed
13:58:31 <agendabot> agenda+ All minutes online available via  -> https://www.w3.org/services/meeting-minutes?channel=rch&num=200 https://www.w3.org/services/meeting-minutes?channel=rch&num=200
13:58:32 <agendabot> agenda+ Round the room updates
13:58:33 <agendabot> agenda+  -> Pull request 101 https://github.com/w3c/rdf-canon/pull/101  on privacy considerations
13:58:36 <agendabot> agenda+  -> Pull request 100 https://github.com/w3c/rdf-canon/pull/100  on identifier mapping
13:58:39 <agendabot> agenda+  -> Pull request 105 https://github.com/w3c/rdf-canon/pull/105  Create rust-sophia-urdna2015.ttl
13:58:42 <agendabot> agenda+ Issue bashing, focused on those that need to be closed  -> before we can seek wide review https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+label%3AHorizontalReview
13:58:45 <agendabot> agenda+ Issue bashing, focused on those that need to be closed  -> before we can go to CR https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+label%3Ams%3ACR
13:58:49 <agendabot> agenda+ Topic call needed Friday?
13:58:49 <phila> chair: phila
14:01:35 <pchampin> present+
14:02:01 <dlongley> present+
14:03:12 <ivan> ivan has joined #rch
14:03:21 <yamdan> yamdan has joined #rch
14:03:45 <phila> present+
14:04:02 <yamdan> present+
14:05:53 <pchampin> scribe+
14:05:53 <ivan> present+
14:05:53 <dlehn> present+
14:05:53 <pchampin> phila: has anyone anything to share?
14:05:53 <pchampin> q+
14:05:57 <manu> scribe+
14:06:13 <manu> pchampin: Two things, one of them is about the DID WG, which has some intersection w/ this group.
14:06:43 <manu> 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.
14:07:13 <manu> 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.
14:07:20 <manu> pchampin: I'm claiming success on that. :)
14:07:49 <pchampin> zakim, open item 3
14:07:50 <Zakim> agendum 3 -- Round the room updates -- taken up [from agendabot]
14:07:56 <pchampin> zakim, open item 4
14:07:56 <Zakim> agendum 4 -- -> Pull request 101 https://github.com/w3c/rdf-canon/pull/101  on privacy considerations -- taken up [from agendabot]
14:07:58 <yamdan> q+
14:08:02 <pchampin> q-
14:08:41 <pchampin> yamdan: this PR is a simple rephrasing of the previous one, which was more complex
14:08:53 <pchampin> ... it has been approved by several people already
14:09:06 <pchampin> ... I just want to make sure if I can merge this one.
14:09:11 <manu> q+ in support of the PR.
14:09:16 <manu> q+ to support of the PR.
14:09:29 <pchampin> phila: the only reason to delay would be waiting for TallTed's review
14:09:42 <dlongley> +1 to merge PR 101
14:09:57 <phila> q?
14:09:58 <pchampin> ... but OTOH, we need this quickly, and it has been approved by many people already
14:10:04 <phila> ack manu
14:10:04 <Zakim> manu, you wanted to support of the PR.
14:10:15 <pchampin> manu: +1 to merge, and thanks to yamdan for making this proposal quickly
14:10:18 <phila> ack yamdan
14:10:39 <dlongley> +1 thanks, Dan!
14:10:49 <pchampin> phila: earing no objection, let's merge it
14:11:06 <pchampin> zakim, open item 5
14:11:07 <Zakim> agendum 5 -- -> Pull request 100 https://github.com/w3c/rdf-canon/pull/100  on identifier mapping -- taken up [from agendabot]
14:11:14 <phila> q?
14:11:22 <dlongley> q+
14:11:23 <yamdan> q+
14:11:29 <pchampin> phila: a lot of back and forth about this one; anyone has anything to say?
14:11:49 <phila> ack dlongley
14:12:09 <pchampin> dlongley: I'm happy with this PR
14:12:19 <pchampin> ... yamdan has concerns, about which I made suggestions that gkellogg merged
14:12:34 <pchampin> ... yamdam does this address your concern?
14:12:53 <phila> ack yamdan
14:13:39 <pchampin> yamdam: if we can note the possibility of @@1 I am ok with merging
14:13:55 <dlongley> https://github.com/w3c/rdf-canon/pull/100/commits/61eecaf862a925a8ae629091c6df10a4b1f339e2#diff-97efdc0e30285fae4d5cb7cc4a510dbaa7c33f4e56d4216dcde109ad2cdef15fR1319-R1325
14:13:56 <pchampin> phila: since you have a condition, could you please add a review in the PR?
14:13:57 <dlongley> q+
14:14:02 <phila> ack dlongley
14:14:25 <pchampin> dlongley: the link above is the text that is meant to address that concern
14:14:35 <pchampin> ... [reads the text]
14:14:41 <yamdan> q+
14:14:45 <phila> ack yamdan
14:14:58 <pchampin> yamdam: it is almost perfect for me
14:15:03 <dlongley> even the same implementation could do it
14:15:04 <dlongley> +1
14:15:11 <seabass> seabass has joined #rch
14:15:25 <seabass> present+
14:15:28 <pchampin> ... I just want to add a little something -- will make a suggestion
14:16:11 <ivan> q+
14:16:21 <phila> ack ivan
14:16:54 <pchampin> ivan: the PR itself is fundamental, and contains a lot of things
14:17:08 <pchampin> ... I wonder if it would not be better to merge it,
14:17:12 <yamdan> +1
14:17:13 <dlongley> +1 to that... Dan?
14:17:17 <pchampin> ... and make a separate PR for yamdam's suggestion
14:17:18 <dlongley> +1 then
14:17:51 <manu> +1 to merge
14:17:58 <dlongley> +1 to merge now and update the note subsequently.
14:18:02 <pchampin> phila: ok, so yamdan please merge #100 and make a new PR
14:18:35 <dlongley> +1 to close PR 99 (original privacy considerations PR)
14:18:37 <pchampin> phila: jumping back to the previous topic (sorry)
14:18:42 <manu> +1 to close original (pending close) item
14:18:42 <yamdan> +1 to close PR99
14:19:00 <pchampin> ... since we agreed to merge yamdan's new PR on privacy issue, we can close #99 without merging it
14:19:17 <phila> Topic: PR 105 https://github.com/w3c/rdf-canon/pull/105
14:19:41 <manu> 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.
14:20:33 <pchampin> phila: this is uncontentious, then
14:21:01 <phila> Topic: Issues before wide review https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+label%3AHorizontalReview
14:21:25 <pchampin> phila: we will soon go to CR, with existing complete implementations, this is good
14:21:34 <pchampin> ... we need to check the horizontal review
14:21:43 <ivan> q+
14:21:53 <pchampin> ... a11y and i18n are done
14:22:17 <pchampin> ... we have done privacy, but not security
14:22:27 <phila> ack ivan
14:22:59 <pchampin> ivan: what do you mean by "done"?
14:23:16 <phila> https://github.com/w3c/rdf-canon/issues/68#issuecomment-1407450253
14:23:43 <pchampin> phila: for i18n we had feedback from Adisson back in January
14:23:52 <pchampin> ... https://github.com/w3c/rdf-canon/issues/68
14:24:10 <pchampin> ... and his response was "you are good to go"
14:24:52 <pchampin> ivan: the process is always changing, I though we need an explicit approval
14:25:11 <pchampin> phila: do you want me to ask Addison for a more formal approval?
14:25:40 <pchampin> ivan: yes, that would be better
14:25:59 <phila> Issue 69 is a11y https://github.com/w3c/rdf-canon/issues/69
14:26:36 <pchampin> phila: we asked for a11y review in January, I said "we probably don't need anything"
14:26:45 <pchampin> ... Janina responded "you are probably right, but let's go through the process"
14:26:52 <phila> Sectiry section https://www.w3.org/TR/rdf-canon/#security-considerations
14:26:59 <pchampin> ... but no feedback since. Need to ping them.
14:27:21 <pchampin> s/Sectiry/Security/
14:27:43 <pchampin> phila: privacy done (thanks again yamdan), need to do security
14:27:48 <pchampin> ... so that we can request TAG review
14:28:18 <yamdan> q+
14:28:23 <pchampin> ... yamdan would you be able in the coming weeks, to turn issue #70 into some text in Section 7 ?
14:28:23 <phila> ack yamdan
14:28:46 <pchampin> yamdan: I can give it a try; but it might not be sufficient
14:29:10 <pchampin> q+
14:29:25 <pchampin> ... I don't have any experience in formal verification
14:30:01 <phila> ack pchampin
14:30:31 <ivan> q+
14:30:34 <manu> 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.
14:30:42 <manu> pchampin: I have to go back to my email to get more detail.
14:30:51 <pchampin> seabass: I know some people who have done that; from what I understand it is quite expensive
14:31:12 <manu> q+
14:31:23 <phila> ack ivan
14:31:27 <pchampin> phila: I'm starting to be worried about this
14:31:28 <phila> ack manu
14:31:40 <pchampin> ivan: where does this requirement for formal verification come from?
14:32:06 <pchampin> manu: this came from an earlier discussion in the WG. Someone asked if we had a formal verification of the whole algorithm.
14:32:48 <pchampin> ... A lot of programs that many people use everyday don't have a full formal verification. This should not be scaring us excessively.
14:33:06 <pchampin> ... Many people have reviewed the algorithm and found no issue.
14:33:23 <pchampin> ... Many W3C specs don't have any formal verification.
14:33:44 <pchampin> ivan: so this does not come from the official W3C security review. This is us being very diligent.
14:33:56 <dlongley> q+
14:34:07 <pchampin> ... Let's not wake up sleeping dogs, and let's not keep this section saying "incomplete".
14:34:23 <pchampin> <pchampin> +1, this is a nice to have, but not a requirement
14:35:03 <phila> ack dlongley
14:36:12 <pchampin> dlongley: we should mention that implementers could (and should) have a timeout after which their implementation bails out
14:36:31 <pchampin> ivan: this should indeed be in the security consideration
14:36:55 <pchampin> phila: dlongley, you made that point from the start, and I'm pretty sure there was consensus on that
14:37:05 <pchampin> ... so I thought it was already in there
14:37:10 <pchampin> q+
14:37:16 <phila> ack pchampin
14:37:31 <pchampin> ivan: it is good to document dataset poisoning
14:38:09 <dlongley> q+
14:38:13 <phila> ack dlongley
14:39:15 <pchampin> pchampin: I think that there *is* a parameter in the algorithm to limit the number of recursions
14:39:46 <pchampin> dlongley: I don't think there is one in the current algorithms. And this is just one of the way of implementing a timeout.
14:39:54 <yamdan> Thank you dlongley for your help!
14:39:56 <ivan> q+ on the tag
14:40:08 <phila> ack ivan
14:40:08 <Zakim> ivan, you wanted to comment on the tag
14:40:24 <pchampin> ivan: can we move on the TAG's review?
14:40:59 <pchampin> phila: I was waiting for the security section, but apart from that we should be good
14:41:18 <pchampin> ivan: the TAG also asks for an *explainer* (because they have so many things to do)
14:41:31 <pchampin> ... Could the explainer that was attached to the proposal be good enough for the TAG?
14:41:34 <pchampin> phila: I hope so
14:42:07 <pchampin> ... I'll make sure they have all they need.
14:42:45 <pchampin> ... I really would like to go to CR before the northern hemisphere summer holiday.
14:43:08 <pchampin> ... We seem to have covered all issues marked as ms:CR
14:43:29 <pchampin> ... Does anyone see anything other issue that we should address in priority?
14:43:46 <pchampin> q?
14:43:51 <pchampin> [crickets]
14:44:08 <pchampin> phila: let's walk through them all then.
14:44:21 <phila> Subtoipic: issue 16 https://github.com/w3c/rdf-canon/issues/16
14:44:41 <ivan> s/Subtoipic/Subtopic/
14:44:44 <dlongley> q+
14:45:04 <phila> ack dlongley
14:45:31 <ivan> +1 to Dave
14:45:32 <pchampin> dlongley: the input of the algorithm implicitly excludes duplicates
14:45:42 <pchampin> ... there are no duplicates in an abstract dataset
14:45:44 <ivan> q+
14:45:47 <phila> ack ivan
14:45:50 <pchampin> ... so I'm inclined to close it
14:45:50 <manu> +1, agree with dave, feels like duplicates are handled by the processing steps
14:45:52 <dlehn> q+
14:46:02 <pchampin> ivan: ok to close, but we should document the response
14:46:09 <phila> ack dlehn
14:46:16 <pchampin> <pchampin> +1 agree with dlongley
14:46:29 <ivan> q+
14:46:35 <phila> ack ivan
14:46:44 <pchampin> dlehn: I'm not sure that all parsers reject duplicates; this is an implementation detail
14:46:54 <pchampin> ivan: it is still out of scope, we do not define parsers
14:47:15 <pchampin> q+
14:47:39 <dlongley> +1 to ivan -- it's the same as "is the N-quads input syntactically correct"
14:47:48 <phila> ack pchampin
14:47:52 <pchampin> ivan: likewise, we do not say "check that the input n-quads is syntactially correct
14:48:44 <manu> 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.
14:49:22 <manu> pchampin: Do we want to say anything in a note?
14:49:32 <manu> ivan: We don't need to say anything, do we?
14:49:44 <manu> pchampin: But if your implementation can have duplicates, do we need to say anything?
14:50:06 <manu> phila: It feels like "garbage in / garbage out" -- feels like there are so many statements like that we could say.
14:50:11 <manu> seabass: Where would such a note go?
14:50:17 <manu> ivan: Don't know. :)
14:50:22 <manu> phila: That's the issue :)
14:50:36 <manu> phila: if PA wants this to be a note, he gets to write the PR. :)
14:51:21 <phila> subtopic Issue 54 https://github.com/w3c/rdf-canon/issues/54
14:51:36 <dlongley> q+
14:51:57 <phila> ack dlongley
14:52:08 <pchampin> dlongley: I'd like to just answer and say "no"
14:52:42 <pchampin> ... we can't add anything to the dataset without changing the hash
14:52:46 <yamdan> +1
14:53:23 <pchampin> seabass: when you create the dataset, you may want to use the c14n algorithm to mint your ids
14:53:46 <dlongley> https://github.com/w3c/rdf-canon/issues/54#issuecomment-1561312205
14:53:53 <dlongley> ^writing what seabass said
14:54:15 <ivan> q+
14:54:15 <dlongley> q+
14:54:23 <pchampin> ... should we support that use case?
14:55:26 <pchampin> phila: IIUC, the answer to the question is still no
14:55:39 <phila> ack ivan
14:56:19 <pchampin> seabass: obviously, the answer to the question in the title is "no", but I read the issue as asking a slightly different question
14:56:35 <phila> ack dlongley
14:56:42 <pchampin> ivan: Tobias has long worked on nanopublications
14:57:16 <pchampin> ... we could ask him to write a note about how to apply rdf-canon with nanopubs, but no impact on our core work
14:57:28 <pchampin> dlongley: agree with ivan
14:58:03 <pchampin> phila: we closed several issues, making progress, thanks everyone
14:58:10 <pchampin> ... markus will be chairing next week
14:58:14 <phila> RRSAgent, make logs public
14:58:15 <pchampin> RRSAgent, make minutes
14:58:46 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/24-rch-minutes.html pchampin
14:58:53 <phila> zakim, end meeting
14:58:53 <Zakim> As of this point the attendees have been pchampin, dlongley, phila, yamdan, ivan, dlehn, seabass
14:58:53 <Zakim> RRSAgent, please draft minutes
14:58:54 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/24-rch-minutes.html Zakim
14:58:59 <Zakim> I am happy to have been of service, phila; please remember to excuse RRSAgent.  Goodbye
14:58:59 <Zakim> Zakim has left #rch
14:59:34 <phila> RRSAgent, please excuse us
14:59:34 <RRSAgent> I see no action items