07:24:15 RRSAgent has joined #rch 07:24:19 logging to https://www.w3.org/2023/09/11-rch-irc 07:25:09 manu has joined #rch 07:25:37 present+ 07:26:26 dezell has joined #rch 07:26:26 present+ 07:26:54 phila has joined #rch 07:27:24 phila has joined #rch 07:27:30 present+ 07:27:38 present+ 07:29:23 present+ 07:32:38 meeting: RCH meeting at TPAC 2023 07:32:42 agenda: https://www.w3.org/events/meetings/53dcaf56-3f94-4f68-a1c0-41fe6c25d71a/ 07:32:42 clear agenda 07:32:42 agenda+ Review agenda and welcome guests 07:32:42 agenda+ Scribe allocations 07:32:42 agenda+ Explainer doc 07:32:42 agenda+ Status of TAG review (ideally with Amy and Hadley) 07:32:44 agenda+ Process briefing (Pierre-Antoine) 07:32:47 agenda+ Status of test suites etc. 07:32:49 agenda+ Agree CR Exit Criteria 07:32:52 agenda+ Seek resolution to send Canon doc to CR 07:32:54 agenda+ Plan afternoon's joint meeting with WoT, JSON-LD etc. 07:32:56 present+ 07:32:57 agenda+ Possibilities for future exploitation, development, promotion, extension to RDF 1.2? 07:33:01 chair: markus_sabadello 07:33:13 RRSAgent, draft minutes 07:33:14 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html phila 07:33:40 RRSAgent, make logs public 07:33:45 RRSAgent, draft minutes 07:33:46 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html phila 07:34:58 Dominik_T has joined #rch 07:35:40 scribe+ phila 07:35:52 markus_sabadello: Calls meeting to order 07:36:03 yamdan has joined #rch 07:36:24 markus_sabadello: Welcomes everyone in the room and online 07:36:36 present+ 07:36:40 present+ 07:36:40 present+ 07:36:48 present+ brentz 07:36:58 zakim, who is here? 07:36:58 Present: TallTed, manu, gkellogg, phila, ivan, markus_sabadello, pchampin, yamdan, brentz 07:36:59 Topic: agenda review 07:37:01 On IRC I see yamdan, Dominik_T, phila, dezell, manu, RRSAgent, Zakim, markus_sabadello, ivan, TallTed, gkellogg, dlehn, gb, seabass, Tpt, agendabot, dlongley, pchampin 07:37:04 present+ 07:37:13 markus_sabadello: Goes through agenda 07:37:45 scribe+ 07:38:23 markus_sabadello: Welcome to everyone, Monday morning at W3C TPAC 07:39:19 markus_sabadello: First time slot, it's been a great group and interesting useful work that we're doing. I sometimes feel like this is not the most glamourous group compared to DIDs and VCs, but let's not underestimate how important this is. This is not just a prerequisite for VCs, but it's really a mechanism for adding integrity/verifiability to any sort of data on the Web. 07:40:43 markus_sabadello: This is not just a short term prerequisite for VCs, this is a mechanism for a more trusted Web wrt. verifiability -- any sort of data, not a small thing. Thanks to everyone for their contributions so far to get to this point. 07:41:42 markus_sabadello: Any introductions? 07:42:16 present+ Calvin Cheung 07:42:35 Calvin_Cheng: Singapore government technology agency introducing themselves, interested in VCs, observing now. 07:42:47 Calvin: representing Singapore Govt 07:43:18 present+ 07:43:48 RDFSTAR: Hello ?? here from RDF Star WG, interested in the work here. 07:44:22 s/RDFSTAR/Doerthe Ardnt 07:44:52 q+ 07:44:55 s/Ardnt/Arndt 07:45:01 dezell: Hello David Ezell, from Conexxus representing them and National Association of Convenience Stores and I think we have one of the real ongoing tests of VCs meeting with a good bit of success in retail space, not security expert, not my space, but have followed it avidily since the beginning. 07:45:17 ack me 07:45:19 markus_sabadello: Welcome, all the things we do here matter more when they're deployed in production. 07:45:51 phila: I know motiviation for this group comes from VCs, but also when I was on W3C Team, people were talking about canonicalization of RDF since far before VCs, but in RDF community it's been happening for many many years. 07:45:52 s/??/Doerthe Ardnt/ 07:46:36 iherman: There was an XML Canonicalization WG, but it was a very different thing. 07:47:10 markus_sabadello: This work also comes up in the data spaces community. 07:47:25 present+ naomi 07:47:32 present+ JeanYves 07:47:42 topic: Explainer Document 07:48:43 phila: The reason for putting this on the agenda, this is something that was Amy Guy and Hadley Beeman reviewing main document for the TAG highlighted the explainer document and thought things should go into explainer document that isn't. I had to update explainer document 07:49:04 q+ 07:49:55 phila: Needed to turn it into mini document and get it into group. Amy noted a few things that should be in the explainer that is not. Ted did a good pass on the document/text. There are four PRs that are pretty straightforward... looking for, maybe Gregg, if those PRs went in do we think it answers Amy's questions. Does explainer document answer what Amy is asking? 07:50:32 phila: On the TAG review -- triples and adding graph name once, this is the sort of thing we expect to see in an explainer. Gregg put some notes in -- does this address this? 07:51:02 gkellogg: I think I answered Amy in that TAG issue and you asked me to do updates to text and I needed to clarify that PR 5 is an update to your PR rather than base document. 07:51:12 https://github.com/w3c/rch-explainer/pull/4 07:51:13 https://github.com/w3c/rch-explainer/pull/5 07:51:45 gkellogg: It touched some non-overlapping areas, didn't make sense to update 4 -- in essence, the combination of those two answers what Amy was asking for. I think we need to get them merged together to verify for ourselves. 07:52:09 -> https://pr-preview.s3.amazonaws.com/w3c/rch-explainer/pull/5.html 07:52:18 phila: Ok, I'll get that reviewed and merged. 07:53:04 phila: Main thing it does is change language on charter/work -- thanks to Ted and Gregg to working on that. Turned it into a NOTE. A lot of the content is exactly as it was... explains problem space, use cases, etc. 07:53:21 phila: we spent a long time thinking about what output is going to be -- detail is in spec, not in this document. 07:54:13 phila: Doesn't change much, use cases not changed, that's the document as it is. Given how recently it's been done, we can't consider publishing as a NOTE immediately, will try to get PRs sorted out, by end of meeting it'll be there, Amy and TAG will be provided the document. 07:54:43 markus_sabadello: Should we tell TAG about this sooner than later? 07:54:49 phila: Yes, as soon as I merge the changes down. 07:55:18 markus_sabadello: Ok, next steps are to merge this and inform tag and us review the document. 07:55:19 q+ 07:55:30 ack gkellogg 07:55:35 scribe+ 07:55:36 ack manu 07:56:00 calvin_ has joined #rch 07:56:24 manu: there is overlap with RDF-star; RDF Surfaces were also brought forward in the VC group. 07:56:38 q+ 07:56:47 ... I don't know where this item fits in the agenda, but we may want to discuss this. 07:57:15 ... If only to state in the explainer "this is was not in our charter, we are not supporting it (yet)". 07:57:16 calvin___ has joined #rch 07:57:23 q- 07:57:27 scribe- 07:57:33 q+ to note potential use of base direction 07:58:12 ack gkellogg 07:58:13 gkellogg, you wanted to note potential use of base direction 07:59:23 gkellogg: To follow up on what Manu was saying wrt. potential futures -- one of the things in RDF 1.2 is support for base direction of literals -- as much as VCs are based on JSON-LD and as much as JSON-LD supports base direction... RDF interpretation is non-normative... that's something we should consider, base direction property -- make sure to clarify how that is serialized to RDF so it's done consistently 07:59:25 q+ 07:59:29 scribe+ 07:59:31 ack manu 07:59:37 jyrossi has joined #rch 07:59:45 manu: this has come up recently in the i18n review of VC 08:00:27 ... Suggestion of the group is to support language and base direction in VCs, but I don't remember how we decided to encode it. 08:01:00 q+ 08:01:04 q+ 08:01:12 ... The VC spec will need to pick one of the two options in JSON-LD to serialize base direction, so that everyone serialize it the same way. 08:01:22 ack phila 08:01:31 scribe- 08:01:40 q+ 08:01:56 scribe+ 08:02:08 phila: I thought we had covered that already? Didn't we talk about literals? 08:02:23 manu: this issue is specifically about base direction 08:02:56 gkellogg: in JSON-LD, one option to encode base direction is the i18n family of datatypes. 08:03:27 q? 08:03:39 ... This was required to fit into the RDF 1.1 model. RDF 1.2 will support base direction natively. 08:03:44 ack ivan 08:04:06 q- 08:04:50 ivan: This is not this groups problem, we should not diverted, this is an issue of the canonical quad serialization which his group does not define. For quads, that is done in another group -- in explainer, we depend on canonicalization of NQuads and RDF 1.2 finalizes it's work on canonical NQuads, our algorithm automatically works. 08:05:23 +1 for keeping concerns separate 08:05:26 ivan: I don't want to minimize the importance of the problem, but this is not for this WG. We should clearly separate these concerns... what happens in VC is how we serialize things in JSON-LD, irrelevant for this WG. 08:05:29 -> https://github.com/w3c/rch-explainer/issues/6 08:06:31 markus_sabadello: Is this related to wha we said about canonical form of N-Quads? 08:08:39 gkellogg: This is taken from RDF 1.2 version in NQuads/Triples -- v1.1 doesn't have such a section, still has some ambiguities... group decided to adopt the language from RDF 1.2 and been going back/forth a bit -- in terms of language, this supports NQuads/Datatypes... one area we've discussed, BCP 47 expression in RDF. Commonly BCP 47 is case insensitive, there are preferences for how its encoded... allows lowercase normalization, what if 08:08:39 triples/quads differ in case used? Express the same value, might not be considered the same term, added language in c14n to strongly encourage implementers to use lowercase version of language tags so we don't run into these problems. 08:09:17 gkellogg: This appendix says how we serialize the result, language tags in algorithm, serialize something in different form... this is something that I don't think RDF 1.2 is done w/ either. Not something we can depend upon in this group. 08:09:39 markus_sabadello: The conclusion is that we have do anything. 08:09:48 gkellogg: I think we've already addressed this. 08:09:54 markus_sabadello: Maybe explainer document can cover this. 08:10:14 s/The conclusion is that we have do anything/The conclusion is that we don't have to do anything 08:10:53 gkellogg: datatype IRIs are not transformed, maybe language tags should be normalized, datatype IRIs are not and i18n does not and namespace depends on those IRIs. 08:11:00 q+ 08:11:09 ack phila 08:11:15 phila: I've heard from Amy, Amy will be here after the break. 08:11:36 q? 08:12:05 ivan: There is one thing not on the agenda, put in an issue that may lead to normative changes in document, nothing big/problematic -- we might use the time to look at the issue. 08:12:24 markus_sabadello: Issue #169? Sounds good to me. 08:12:27 https://github.com/w3c/rdf-canon/issues/169 08:12:39 subtopic: https://github.com/w3c/rdf-canon/issues/169 08:12:48 Topic: Issue #169 08:13:48 ivan: There have been negative remarks from some in the VCWG about us using SHA-256, some think it's not good enough and so entire algorithm is not ok -- text in spec has a few places says that implementations can allow changing hash function to something else... one remark in terminology section and that's it. 08:14:05 s/Topic: Issue #169// 08:15:06 q+ 08:15:08 ivan: In parallel, important to be able to change hash functions, two additional tests to test suite, which includes requirement to change hash to SHA-384. That is part of official test suite, we already have 3 implementations that implement that. We should be stronger in the test and we should make it a SHOULD statement, wouldn't be shocked if we say it MUST -- user of algorithm SHOULD/MUST be able to change hash function to SHA-384, or if SHA-384 is 08:15:08 enough to cover things 08:15:09 q+ 08:15:26 Related: https://github.com/w3c/rdf-canon/pull/159, https://github.com/w3c/rdf-canon/pull/161 08:15:27 q+ 08:15:34 ivan: We should make language stronger, leave how to the editors, we should discuss the principle first. 08:15:46 q? 08:15:47 markus_sabadello: The TAG review also covers this. 08:15:53 -> https://github.com/w3c/rdf-canon/issues/160 08:15:58 ack phila 08:16:04 phila: I think we covered this, closed issue 160... 08:16:08 scribe+ 08:16:31 manu: we definitely discuss this. To be sure that everyone is on the same page: 08:17:02 ... the hashing function we are talking about here is the *internal* hashing function that we use in the algorithm. 08:17:40 ... We are *not* talking about the hashing function used on the output of the canonicalization algorithm. 08:18:08 ... @@ is considering moving from SHA-2 to SHA-3. We must be open to this kind of change. 08:19:02 ivan: To be precise, text in issue -- two things 1) algorithm must allow caller to change hash function, 2) if this is done, SHA-384 should be supported. 08:19:05 q? 08:19:12 ack manu 08:19:14 ack gkellogg 08:19:14 s/@@/some national governments/ 08:20:43 gkellogg: In the definition of the hash algorithm... default is SHA-256, implementations can be written to parameterize -- I agree that statement should be made stronger... implementations MUST allow algorithm to be specified, whether we get into enumerating other acceptable algorithms, that's shortsighted, as soon as we do 384, then we move to sha-3, or something completely different... takes input, generates an output... test was added to test suite 08:20:44 to show that if different hash function is used, you get different results. 08:20:46 +1 to not enumerating hash algorithms, other than the default. Leave it open to future changes. 08:21:03 gkellogg: Example specified, SHA-384 specifically, SHA-3, probably want to make that informative. 08:21:07 q+ to agree with gregg 08:21:13 q+ 08:21:20 ack manu 08:21:20 manu, you wanted to agree with gregg 08:21:48 manu: +1 to what gkellogg said. They are many hash functions. 08:22:33 ... I'm on the fence on saying MUST for sha-256 and SHOULD for sha-384, and not go beyond that. Different organizations have different requirements. 08:22:37 ack ivan 08:22:43 ... Leaving it open is more future-proof. 08:22:52 ivan: I think we have an agreement that language should be more firm -- on that, we can move on. 08:23:15 q+ 08:24:29 q+ 08:24:34 ivan: Whether spec refers to SHA-3 or SHA-384, only problem w/ not doing that, how do we test if we don't have a reference... current test has built in SHA-384, thorough test suite, at minimum SHA-384 -- language into issue reflects that... if we leave it open, nothing else in spec, how do we write a test to test that w/o specifying specific hash functions. How do we test this, that's the problem? 08:24:55 q? 08:24:55 ivan: Implementations should implement SHA-256 or SHA-384. 08:25:02 ack gkellogg 08:26:01 gkellogg: One of the other things that we discussed, and provision for in the spec, other specs could be derived from this could specify hash function, would support our strength of language to support at least SHA-256 SHA-384 without enumerating others... we're getting into actual/future hash algorithm probably right way to do that is create a new spec that highlights that new item 08:26:02 q- 08:26:14 q+ to note a spec that only defines hash function is a bit heavyweight? 08:26:24 ack manu 08:26:24 manu, you wanted to note a spec that only defines hash function is a bit heavyweight? 08:27:20 manu: we don't want to later define a new spec that would only change the hash function 08:27:29 draft proposal: The spec text be amended to say implementations MUST support HSA-256, SHOULD also support SHA-384 and invite use of other hash functions in future. 08:27:39 ... other specs should be able to say: "use rdf-canon with the hash function XYZ" 08:28:47 q+ 08:28:53 gkellogg: Perhaps a registry, naming schemes... rdfc-1.0-sha256 or similar things that would allow it to be more explicit, but to your point, we do not need an entire spec to replace the hash function -- too heavyweight -- but doing it in another algorithm that specifies that is ok. 08:29:25 ack ivan 08:29:25 gkellogg: As an implementer, I have libraries that have hash functions available to them, but can't necessarily do that if a call is made. 08:29:40 ivan: Let's not overcomplicate things, what phil put in as a draft proposal covers the situation we have today. 08:29:50 s/HSA/SHA/ 08:30:28 ivan: Let's run the proposal Phil suggested. 08:30:30 s/HSA-256/SHA-256 08:30:39 Proposal: The spec text be amended to say implementations MUST support SHA-256, SHOULD also support SHA-384 and invite use of other hash functions in future. 08:30:44 +1 08:30:49 manu: +1 08:30:52 +1 08:30:52 +1 08:30:56 +1 08:31:01 +1 08:31:45 markus_sabadello: This implies that it must be able to be parameterized in the first place -- MUST be able to parameterized. 08:31:59 gkellogg: can we say MUST support SHA-256 and SHA-384 08:32:09 phila: What about MUST support other hash functions? 08:32:45 gkellogg: Text says you MUST be able to specify parameters. 08:32:53 phila: Let's try to get this written down in a proposal. 08:33:30 Draft: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options 08:33:31 "Implementations must allow the hash algorithm to be specified by parameter without any other changes." 08:34:00 PROPOSED: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options 08:34:03 +1 08:34:03 +1 08:34:06 manu: +1 08:34:07 +1 08:34:10 +1 08:34:10 +1 08:34:12 +1 08:34:15 +1 08:34:22 RESOLVED: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options 08:34:27 Q+ 08:34:43 ack phila 08:35:46 phila: This is a small change, but normative, conscious that we have a TAG review -- does this hold us up? Any resolution to go to CR will include things discussed today. 08:36:30 https://github.com/w3c/rdf-canon/pull/167 08:36:41 subtopic: https://github.com/w3c/rdf-canon/pull/167 08:39:07 gkellogg: This is a bit of a back and forth w/ PFPS. 08:39:34 phila: This sounds like this is a known problem, but not our problem to fix... been this way for 20 years. There isn't any controversy about this PR? 08:39:41 phila: Yes, sounds like we can go ahead 08:39:49 gkellogg: Ok, merging it now, then. 08:40:26 subtopic: https://github.com/w3c/rdf-canon/pull/171 08:40:53 q? 08:40:58 markus_sabadello: This just adds funders, if there are no objections, we can merge. 08:41:08 ivan: We can merge 08:41:14 gkellogg: I'll merge now. 08:41:28 gkellogg: We just need a PR for the resolution we have and we're done. 08:41:40 RRSAgent, draft minutes 08:41:42 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html phila 08:42:20 manu: This covers all of the issues that PFPS raised? 08:42:51 gkellogg: Yes, seems like it does. 08:43:55 q? 08:45:24 gkellogg: We might want to clean up issue markers in the spec -- should we leave issue marker in the spec. 08:45:52 ivan: We should remove it from the text 08:46:12 dezell has joined #rch 08:46:15 gkellogg: Issue for 98 should be removed -- as part of update for specification, issue markers for closed issues shouldn't stay in the document. 08:47:55 gkellogg: Privacy considerations, might reveal information... we do have issue markers in it... we have asked for review... we have text. 08:48:49 manu: does our section about Security and Privacy mention selective disclosure? It should. 08:49:03 ... [after looking at it] Yes it does. 08:49:20 ivan: The reference should include a link to the Data Integrity specification. 08:49:34 manu: Yes, looks like this text covers that issue. 08:49:41 phila: Is the Data Integrity spec in TR? 08:49:46 manu: Yes, it is. 08:50:02 markus_sabadello: It sounds like we should be able to close issue #70. 08:50:21 Is this the reference to be used on selective disclosure? https://www.w3.org/TR/vc-data-integrity/#selective-disclosure 08:50:29 Need to add reference to [vc-data-integrity] from Section 6 08:52:01 phila: For privacy considerations section -- can we add a reference? 08:52:05 gkellogg: I can add a separate PR 08:52:14 gkellogg: We have use cases section w/ issue marker. 08:52:14 q+ 08:52:25 q- 08:52:43 phila: That should point to the explainer document. 08:53:50 markus_sabadello: There is also some text about Editors notes about c14n details. 08:53:57 markus_sabadello: So, close issue #70? 08:54:39 RRSAgent, draft minutes 08:54:40 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html phila 08:54:47 markus_sabadello: Ok, five minutes to coffee break -- think we did all issues and PRs. 08:55:43 Topic: Process Briefing 08:57:11 pchampin: The only thing that is keeping us from going to CR is TAG review... 08:57:14 ivan: and then we have to do transition request... then approval, if we had documents, then has to be published on TR manually, automatic publishing needs to be switched off for a while -- done in old school way. 08:57:30 q+ 08:57:54 ivan: As part of CR transition, what's the earliest date to move to PR -- has to be part of transition request, limit for that, at least 28 days. 08:58:29 phila: The aim today is not to get into CR, we need to go through process -- if group agrees we're ready, have we got everything ready to go through that process. 08:58:30 q- 08:59:16 phila: After coffee, we'll run the request to transition. 08:59:33 [Coffee break] 08:59:33 markus_sabadello: Thanks everyone, we have a half hour break now. 09:00:43 rrsagent, draft minutes 09:00:44 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html gkellogg 09:29:55 phila has joined #rch 09:34:06 nick_lansley has joined #rch 09:34:51 manu has joined #rch 09:38:31 ivan has joined #rch 09:40:12 rhiaro has joined #rch 09:40:17 present+ 09:40:33 scribe+ 09:41:13 phila: Michiel can you say hello 09:41:30 Michiel de Jong: I followed manu's work 09:42:51 Jean-Yves Rossy: I joined W3C through Web Payments. I'm currently preparing a PhD about Semantic Web. I have a connection with Pierre-Antoine 09:43:03 s/Rossy/Rossi/ 09:43:04 phila: We appreciate Amy being here 09:43:13 phila: We asked for a TAG review 09:43:23 https://github.com/w3ctag/design-reviews/issues/855#issuecomment-1664350113 09:44:09 phila: We actually went through the Security and Privacy Questionnaire. We answers the questions that apply to us. 09:44:09 phila: We also answered questions about the explainer document. 09:44:09 phila: The use cases document has been updated. 09:44:11 phila: I hope we answered your questions. 09:44:26 dezell has joined #rch 09:44:53 rhiaro: We don't have any further worries. 09:45:12 phila: Can you give us an estimation 09:45:20 rhiaro: I need to sync up with Hadley, but it should happen soon 09:46:20 phila: This morning, we looked at explainer, talked about process. 09:46:28 phila: We should now look at test suites, and talk about CR exit criteria 09:46:39 Test suites: https://w3c.github.io/rdf-canon/tests/ 09:47:25 ivan: From my experience, the test suite is fine. There may even be some tests that should not be there, e.g. ones about NQuad serialization rather than Canonicalization 09:47:32 ivan: The test harness works 09:47:52 ivan: There are several implementations that went through the test suite 09:47:59 https://w3c.github.io/rdf-canon/reports/ 09:48:06 jyrossi_ has joined #rch 09:48:39 gkellogg: Tests are good, but I think we need to approve them. 09:49:16 phila: Do we need to review before we approve them? 09:49:20 ivan: I don't think so 09:49:39 ivan: For CR transition, we only need to say that we have a way to test. And we do have that. 09:49:47 ivan: I think we are fine for CR transition 09:50:06 phila: But it feels like a simple step to "approve" them 09:50:17 PROPOSED: Change status of tests documented at https://w3c.github.io/rdf-canon/tests/ to 'approved' 09:50:24 +1 09:50:35 https://w3c.github.io/rdf-canon/reports/ 09:51:20 scribe- 09:51:20 +1 09:51:20 gkellogg: The report shows 4 implementations, one has partial compliance 09:51:32 gkellogg: We're also still expecting more reports 09:52:18 https://github.com/w3c/rdf-canon/wiki/List-of-available-implementations 09:52:54 phila: Do we have a sense how complete the implementations are? 09:53:08 phila: Are any of these implementations affected by the resolution we made this morning about alternative hash algorithms? 09:53:12 ivan: No, they all pass this 09:53:26 gkellogg: Some of the tests are against SHA-384 09:53:36 gkellogg: There's a test property to specify the algorithm to use 09:53:59 PROPOSED: Change status of tests documented at https://w3c.github.io/rdf-canon/tests/ to 'approved' 09:54:01 +1 09:54:02 +1 09:54:03 phila: Let's finish voting on the resolution please 09:54:04 +1 09:54:05 +1 09:54:07 +1 09:54:08 +1 09:54:13 RESOLVED: Change status of tests documented at https://w3c.github.io/rdf-canon/tests/ to 'approved' 09:54:31 phila: We can now turn the test status to approved 09:54:45 phila: We have an impressive list of implementations, by different people, in different languages 09:54:54 ivan: manu your group is doing the Python one? 09:54:55 manu: Yes 09:55:15 ivan: We have TypeScript, Ruby, Rust.. We also need Java, Python 09:55:24 ivan: They exist but have not submitted reports 09:55:39 manu: We have Java implementations which are passing VC Data Integrity 09:55:54 ivan: We should have independent reports from Java, Python 09:56:45 i/RESOLVED: Change status/+1 09:57:27 ivan: I think all four have regularly contributed to the specification, which is a good thing 09:57:48 phila: We have a test suite, multiple implementations, that's good 09:57:57 phila: Horizontal reviews are okay 09:58:24 https://github.com/w3c/rdf-canon/issues/2 will be mentioned in the explainer document 09:58:40 phila: We have talked about all issues 09:58:54 gkellogg: There are 2 pull requests 09:58:57 phila: Let's look at them 09:59:10 https://github.com/w3c/rdf-canon/pull/172 10:00:40 gkellogg: I added a suggestion to maintain the readability of the source 10:00:48 s/gkellogg/TallTed/ 10:01:00 gkellogg: Merged 10:01:15 https://github.com/w3c/rdf-canon/pull/173 10:01:31 This one addresses the earlier resolution about parameterizing the hashing function 10:01:39 gkellogg: Accepted TallTed 'd suggestion 10:01:49 s/'d/'s/ 10:02:03 phila: Looks clear 10:02:09 gkellogg: This also removes an issue marker 10:02:42 manu: Minor knit about language.. The last bit that says "SHOULD".. 10:03:02 manu: Maybe this should be changed to "SHOULD support the ABILITY to add other ..." 10:03:45 manu: .. the ABILITY to SPECIFY other hash algorithms 10:04:42 phila: We can go to the issues and point to the PR which takes care of it 10:04:49 gkellogg: When we merge it, the issue will be closed 10:05:39 phila: Three approvals 10:05:44 phila: Let's merge 10:05:56 gkellogg: Done 10:06:54 rrsagent, draft minutes 10:06:55 I have made the request to generate https://www.w3.org/2023/09/11-rch-minutes.html gkellogg 10:07:49 New text appears in https://w3c.github.io/rdf-canon/spec/#dfn-hash-algorithm 10:08:59 phila: Currently open issues.. We talked about use cases, history, TAG review 10:09:08 phila: We have test suites and implementations 10:09:18 phila: We need to define CR exit criteria 10:09:39 phila: Usually 2 independent implementations of each feature, which we already have 10:09:58 ivan: Since we are talking about a security-relevant spec, we could make 2 changes. 10:10:22 ivan: We should say we have 2 implementations which pass ALL the tests. This is stronger than usual. 10:10:51 ivan: We could potentially say 3 instead of 2. 10:12:43 phila: We're setting the bar higher than what W3C requires, which is a good thing 10:13:28 phila: On Horizontal Review, should we just say they are completed, or should we go into details 10:13:42 phila: The Accessibility group agrees this is not an issue for us 10:14:20 ivan: In the submission request, you don't have to go into details, but you have to give clear pointers to the discussions (Github issues, email, etc.) 10:14:49 phila: We have acted on them 10:15:26 manu: There's a template for the transition request, which makes it easier 10:15:54 phila: Here's the document we're suggesting is ready for CR: https://w3c.github.io/rdf-canon/spec/ 10:16:03 phila: Should we mention implementations in the document? 10:16:13 gkellogg: We can reference the test report 10:16:31 phila: The test suite is referenced 10:16:35 phila: All issue markers gone? 10:16:42 gkellogg: There is still an issue marker for use cases. 10:16:50 phila: We know this is editorial, not normative 10:17:02