14:02:52 RRSAgent has joined #rch 14:02:56 logging to https://www.w3.org/2023/06/13-rch-irc 14:02:56 Zakim has joined #rch 14:03:19 yamdan has joined #rch 14:03:34 present+ 14:03:40 present+ 14:03:42 present+ 14:04:09 Meeting: RCH Working Group Telecon for 2023-06-13 14:04:20 Chair: Markus 14:05:36 scribe+ 14:06:11 markus_sabadello: Let's get started, short agenda today 14:06:20 markus_sabadello: Let's start with general updates. 14:06:25 zakim, next agendum 14:06:25 I see nothing on the agenda 14:06:32 Topic: General Updates 14:07:09 present+ 14:07:11 Agenda: https://www.w3.org/events/meetings/493561b0-3a22-467f-8531-3c93ee3512f5/20230613T100000 14:07:12 clear agenda 14:07:12 agenda+ Scribe (most recent first) kazue, Manu, PhilA, Gregg, seabass, markus_sabadello, DLongley, pchampin, Ahmad, TallTed 14:07:12 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 14:07:13 agenda+ Round the room updates 14:07:14 agenda+ Issue processing: -> https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen 14:07:32 zakim, close item 1 14:07:32 agendum 1, Scribe (most recent first) kazue, Manu, PhilA, Gregg, seabass, markus_sabadello, DLongley, pchampin, Ahmad, TallTed, closed 14:07:34 I see 3 items remaining on the agenda; the next one is 14:07:34 2. 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 [from 14:07:34 ... agendabot] 14:07:39 zakim, close item 2 14:07:39 agendum 2, 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, 14:07:42 ... closed 14:07:42 I see 2 items remaining on the agenda; the next one is 14:07:42 3. Round the room updates [from agendabot] 14:07:57 zakim, close item 3 14:07:57 agendum 3, Round the room updates, closed 14:07:58 I see 1 item remaining on the agenda: 14:07:58 4. Issue processing: -> https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen [from agendabot] 14:08:01 No updates, moving on to issues 14:08:20 q+ 14:08:28 scribe+ 14:08:28 ack manu 14:08:57 manu: Somewhat of a topic update I guess. We had announced the ECDSA-SD (Data Integrity selective disclosure using NIST crypto) approach. It's aligned with the current specification. 14:09:06 manu: There's a presentation out there we shared on a previous call. 14:09:22 manu: The next step is to document exactly what the algorithmic process is there and put that in as a PR in the VCWG. 14:09:41 manu: Detail it in prose so people understand the interplay between the RCH WG and the Data Integrity specs in the VCWG. 14:09:54 manu: Hopefully at that point hopefully we can do another presentation in this group about all the details there and how it works. 14:10:10 manu: We're definitely looking for a second implementer of the ECDSA-SD stuff to confirm the design and approach we took is correct. 14:10:42 manu: As a general announcement, the high-level slide deck is out there on the CCG mailing list. We will detail the algorithm at depth and do a PR in the VCWG. Then maybe we'll try and update the slide deck to add a little more detail on that stuff. 14:10:53 manu: No ETA on when that will happen, we will try to get to it sooner than later. 14:11:08 manu: The other thing to mention, if you want to share that news with people feel free to, we're looking for input on ECDSA,SD. 14:11:15 s/ECDSA,SD/ECDSA-SD/ 14:11:19 scribe- 14:11:49 markus_sabadello: Yes, thanks for the update. It makes good use of the work we're doing in this group and how you can plug into the canonicalization algorithm and use it. What's being done w/ ecdsa-sd builds on top of that nicely. 14:12:21 q+ 14:12:26 markus_sabadello: My personal opinion is that this is valuable in the community. Sometimes there is a perception that Data Integrity requires fancy cryptography like BBS and CL Signatures, but this new ECDSA-SD cryptosuite seems to fill a gap. 14:12:29 ack dlehn 14:13:10 dlehn: Slightly different topic, with recent algorithm name change, how do we support all the code using the previous name? It might be mentioned in the previous specs... the test suite is being removed, what's the guidance for implementations to deal with that issue? 14:13:19 gkellogg_ has joined #rch 14:13:31 phila has joined #rch 14:13:33 dlehn: Are we expecting URDNA2015 to be equivalent? Are we supposed to worry about this in any serious way, or assume they're equivalent when going forward. 14:13:37 https://github.com/w3c/rdf-canon/pull/116 14:13:41 present+ 14:13:47 present+ 14:14:02 q+ 14:14:07 markus_sabadello: We talked about this last time a bit. We might want to add a note that says they're almost the same... 14:14:10 ack gkellogg_ 14:14:11 dlehn: I think that exists 14:14:33 gkellogg_: There is an appendix, and it says it's basically the same with a couple of things noted by the NQuads serialization. 14:14:44 -1 to support both, they should be considered equivalent 14:14:47 q+ 14:14:56 dlehn: Should we support both? Digital Bazaar has URDNA2015 deployed, what's the best approach there? 14:14:58 ack dlongley 14:15:12 present+ 14:15:47 dlongley: Don't support both -- if there happens to be some use case that an implementation might need to support both, it could do that, but the differences are not significant enough to have impacted anyone at all. Having both might confuse the marketplace. Treat them as the same, more than likely that's not going to result in real problems anywhere. 14:16:07 dlehn: It does make older implementations break. 14:16:34 gkellogg_: top level manifest points to different manifests... if you follow what the manifests say to do, you really don't need to do anything. 14:17:14 +1 to gregg 14:17:20 gkellogg_: I did that update in about 5 minutes. If I were to provide backwards compatability to allow URDNA2015 to be specified, I would not try to do a different c14n implementation to support it. It would probably be a different implementation w/ a deprecation notice. 14:17:28 +1 to gregg 14:17:32 markus_sabadello: Does that answer your question? 14:17:41 q+ 14:17:50 dlehn: Yes, I just wanted to make sure that this was taken into account. 14:17:52 ack markus_sabadello 14:18:02 https://github.com/multiformats/multicodec/pull/328 14:18:37 markus_sabadello: That reminds me, one update I have is that I raised a PR on multicodec repo that already got merged to also rename it... I think we also discussed that and had issue in our repo. Hope I didn't do anything I wasn't supposed to do w/o decision of WG. 14:18:47 markus_sabadello: This has been updated in multicodec group 14:18:48 q+ 14:18:52 scribe+ 14:19:18 manu: I had made a comment there about just using the `-1` vs. `-1.0` in there. 14:19:38 markus_sabadello: In the multicodec group they have a rule that doesn't allow a dot, so I had it say `-1-0`. 14:19:38 ack manu 14:19:40 In tests, we use "rdfc10" 14:19:53 manu: Did we discuss needing the `.0` vs. just not having one? 14:20:02 markus_sabadello: No, we didn't discuss that so I just did that on my own in the PR. 14:20:20 q+ 14:20:46 gkellogg_: In tests it can be difficult to use dots, so '10' 14:21:02 scribe- 14:21:17 gkellogg_: That fits with what other systems do sometimes. 14:21:18 ack dlongley 14:21:44 dlongley: That PR has not been merged yet, if we wanted to make changes, that could be done. If we wanted to agree what we want the value to be, you could just make a quick change and it would go in before being merged. 14:21:56 present+ phila 14:22:02 present+ pchampin 14:22:06 present+ yamdan 14:22:43 markus_sabadello: Yes, it's still open, so someone can suggest changes. 14:22:53 q+ 14:23:30 dlongley: This seems fine, it seems informative -- "-1" should cover "1.1" and "1.2" in this particular case. 14:23:36 scribe+ 14:23:36 ack manu 14:24:05 manu: That was my thinking as well. I'm not trying to derail -- apologies. It is used as input into code to do the selection in some of the multicodec libraries so that's why it's important. 14:24:15 manu: I don't think it's too strong of an opinion one way or another, so let's move on. 14:24:29 markus_sabadello: Ok, yes, let's discuss on that PR and move on with issues. 14:24:32 scribe- 14:24:35 https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22 14:24:53 https://github.com/w3c/rdf-canon/issues/7 14:25:09 subtopic: https://github.com/w3c/rdf-canon/issues/7 14:25:26 markus_sabadello: This is marked proposed closing, Gregg you commented here... Andy opened it originally, should we close this? 14:26:35 gkellogg_: I think we decided that the algorithms couldn't handle a blank node predicate, but just about anything else would work. For example, literal subjects, I think we just decided we're not going to do that. I don't think there is some form of entailment regime that would deal w/ this. Do we want to update the algorithm to support blank nodes in any position, substantial work, and not particularly useful. 14:26:47 q+ 14:26:51 manu: +1 sounds like work we want to avoid doing, no concrete upside. 14:27:05 markus_sabadello: Do we want to say something about this int he spec? 14:27:30 ack phila 14:27:33 gkellogg_: Generalized RDF is something we support, we don't want to say we support these extensions... no end to things that we don't support, so no need to call this one out specifically. 14:27:44 phila: I marked this as proposed closing because we haven't commented on this in a while. 14:28:00 +1 Phil, +1 to close 14:28:09 TallTed has joined #rch 14:28:33 phila: We talked about this at TPAC, haven't really done anything since, does not seem like there is support to do anything about this. 14:28:55 Proposed resolution: WG will not support generalized RDF. Close issue 7 14:29:09 +1 14:29:10 +1 14:29:12 +1 14:29:13 manu: +1 14:29:21 +1 14:29:26 +1 14:29:55 +1 14:30:06 Resolution: WG will not support generalized RDF. Close issue 7 14:30:23 RRSAgent, draft minutes 14:30:25 I have made the request to generate https://www.w3.org/2023/06/13-rch-minutes.html phila 14:30:36 subtopc: https://github.com/w3c/rdf-canon/issues/11 14:30:43 RRSAgent, make logs public 14:30:44 s/subtopc/subtopic/ 14:30:47 RRSAgent, draft minutes 14:30:48 I have made the request to generate https://www.w3.org/2023/06/13-rch-minutes.html phila 14:31:06 present+ 14:31:08 +1 14:31:10 ghurlbot has joined #rch 14:31:39 +1 to close 14:31:43 markus_sabadello: This one was opened by Andy, some comments from Dave about which choices are made in generating hash and using algorithm. Dave noted it's the responsibility of the container format and noted dependency on issue regarding naming, which we just addressed, something we can close, any comments on this one? 14:31:49 manu: +1 to close 14:32:51 markus_sabadello: Maybe we add comment and ask Andy to re-open if he disagrees. 14:33:54 phila: Naming has been discussed, no further discussion, closing. 14:34:21 markus_sabadello: We have 17 other open issues, does anyone have any other issue they want to discuss specifically? 14:34:29 gkellogg_: It's useful to have group response to issue 111. 14:34:37 gkellogg_: Remarks that were sent in last week. 14:34:43 subtopic: https://github.com/w3c/rdf-canon/issues/111 14:34:55 gkellogg_: There are some good points in there, don't know if we're going to follow them all, but might want to provide some rationale. 14:35:17 markus_sabadello: Don't know if everyone has had a chance to look at this. Summary? 14:36:46 gkellogg_: It's feedback from Lars, graph theorist, and notes some of our use of terminology. We say "it's believed to be an indeterminate problem" and suggests some renaming to make it more acceptable. He discusses definition of a gossip path. We don't mention isomorphism and clearly there is a relationship between canonicalization and graph isomorphism. 14:37:11 ghurlbot, status 14:37:11 TallTed, the delay is 15, issues are on, names are on; and no repositories are specified. 14:37:38 ghurlbot, repo: w3c/rdf-canon 14:37:38 TallTed, OK. 14:38:36 gkellogg_: There is an issue on me to update our wording to rationale... use of word "degree" is wrong, implies "quads one step away from another quad" he believes that's the wrong term. I don't know about renaming all that at this point. Describing use of degree -- degrees of relationship between different nodes/quads, and there are some other issues. Dataset example, in examples section. 14:38:54 ghurlbot, ignore RRSAgent 14:38:54 TallTed, OK 14:38:59 gkellogg_: We haven't noted difference between "canonicalization" vs. "normalization" -- other uses of "normalize" that we might want to clean up. 14:39:15 ivan has joined #rch 14:39:17 gkellogg_: Rather than being faced w/ silence, it would be good for the group to respond to the input. 14:39:44 markus_sabadello: It sound substantial, multiple issues inside a single issue. What should we do? Would he be willing to address some of that w/ PRs? Or do we have to go through each one of these? 14:39:55 ghurlbot, status? 14:39:55 TallTed, the delay is 15, issues are on, names are on, commands are ignored from RRSAgent; and the repository is https://github.com/w3c/rdf-canon 14:40:46 gkellogg_: The thing to do is to reference issues based upon points he makes and create issues that might not already exist. I can do that, a formal input like this, wide review -- requires a response from the group. Can reference issues it's been dissected into... but perhaps a Chair response on how we're taking that input is preferably warranted. 14:40:52 +1 to gregg ... all looks like editorial stuff as well 14:41:02 markus_sabadello: We could respond by saying we're grateful for the input, will create new issues where appropriate. 14:41:32 gkellogg_: Yes, we could add issues for his input, might not apply all of points, but do appreciate the input. 14:41:39 markus_sabadello: You could do that? 14:41:50 gkellogg_: I'll make sure we have issues for all of the points he makes. 14:42:17 gkellogg_: I can create issues today 14:42:28 markus_sabadello: Once you do that, let Phil and I know, and then we can post a comment on this issue. 14:43:13 gkellogg_: A couple of other things we could do -- step 6, include map from original blank nodes from canonical blank nodes... steps should be updated to show map. 14:43:21 gkellogg_: We need an example for datasets, we could take suitable test case and reproduce that. 14:44:02 markus_sabadello: Update examples and update description of algorithm logging to show map from input identifiers to output identifiers. 14:44:29 gkellogg_: I think there is an issue where Ivan had suggested changing the description of the normalized dataset to use the canonical issuer or the map portion from that. 14:44:55 gkellogg_: is re3ferring to Issue 109 https://github.com/w3c/rdf-canon/issues/109 14:45:15 s/re3f/ref 14:45:46 https://github.com/w3c/rdf-canon/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 14:46:15 subtopic: https://github.com/w3c/rdf-canon/issues/10 14:47:57 Also relates to #6. https://github.com/w3c/rdf-canon/issues/6 14:47:58 https://github.com/w3c/rdf-canon/issues/6 -> Issue 6 Compare the two algorithms, and decide on basis for our work (peacekeeper) documentation 14:47:58 phila: When we started and we were open to doing things differently... the reality is that we've been working w/ URDNA2015... but issue 10 is when we were more seriously considering the potential toward aiden's ideas. The dynamic of the group is such that it didn't happen (no great surprise), but the group is zero-ing and finalizing the document that the group has been working on. The question related to whether or not we're making the right choice 14:47:59 here, we're pretty settled at this point. 14:48:31 markus_sabadello: We're probably not going to use a different algorithm at this point. 14:49:04 q+ 14:49:35 ack gkellogg_ 14:49:36 markus_sabadello: We've had several calls about different algorithms, discussed criteria, ultimately it is the WG that works on certain things or not. We could mark it as pending close, describe current state of work, and then close at some point. 14:50:20 gkellogg_: Also relates to issue 19... add history for c14n work... parallel development of Aiden/Dave's algorithms. Manu had signed up a while ago to summarize, but maybe we should say both algorithms were basically isomorphic. 14:51:12 markus_sabadello: Issue 19, maybe 10 and 6 can be marked as proposed close with a pointer to 19 saying that we are interested in adding some history and background, but it's highly unlikely to change the algorithm at this point based on all of the previous discussions. 14:51:58 markus_sabadello: We have spent several calls and email threads considering different algorithms and the WG has arrived at the current state. 14:53:00 phila: propose close vs. closing? 14:53:17 markus_sabadello: yes, has been a significant topic, let's give it a bit of time to avoid any sort of rush. 14:54:03 gkellogg_: There is a hole in the spec, no technical review will change because of it. 14:54:06 q+ 14:54:35 phila: I think that history is important, backs up what's gone into this, and polite-ness. Can Manu still do this? 14:54:44 scribe+ 14:54:47 ack manu 14:55:22 manu: I agree with everything you said, Phil. It's important that we note it, it goes further back than Aidan's stuff. It goes back to Jeremy Carroll's work and so on. I think it's important to write it but I'm so underwater right now I don't know when I could do it. 14:55:45 manu: I'm totally slammed with everything going on with the VCWG, etc. I'd say let's keep it open as it's something we can add later even after / during CR. 14:55:52 manu: I don't have the cycles right now. 14:56:22 phila: This is documentation and editorial, we could add it during CR. 14:56:27 scribe- 14:57:02 markus_sabadello: There are still 17 open issues, please go over the issues and let's continue next week. 14:57:10 rrsagent, draft minutes 14:57:11 I have made the request to generate https://www.w3.org/2023/06/13-rch-minutes.html manu 14:57:25 zakim, close meeting 14:57:25 I don't understand 'close meeting', phila 14:57:33 zakim, end meeting 14:57:33 As of this point the attendees have been markus_sabadello, yamdan, manu, dlehn, phila, gkellogg_, pchampin, TallTed 14:57:35 RRSAgent, please draft minutes 14:57:36 I have made the request to generate https://www.w3.org/2023/06/13-rch-minutes.html Zakim 14:57:41 I am happy to have been of service, phila; please remember to excuse RRSAgent. Goodbye 14:57:42 Zakim has left #rch 14:57:49 RRSAgent, please excuse us 14:57:49 I see no action items