Meeting minutes
markus_sabadello: Let's get started, short agenda today
markus_sabadello: Let's start with general updates.
General Updates
No updates, moving on to issues
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.
manu: There's a presentation out there we shared on a previous call.
manu: The next step is to document exactly what the algorithmic process is there and put that in as a PR in the VCWG.
manu: Detail it in prose so people understand the interplay between the RCH WG and the Data Integrity specs in the VCWG.
manu: Hopefully at that point hopefully we can do another presentation in this group about all the details there and how it works.
manu: We're definitely looking for a second implementer of the ECDSA-SD stuff to confirm the design and approach we took is correct.
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.
manu: No ETA on when that will happen, we will try to get to it sooner than later.
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.
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.
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.
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?
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.
<markus_sabadello> w3c/
markus_sabadello: We talked about this last time a bit. We might want to add a note that says they're almost the same...
dlehn: I think that exists
gkellogg_: There is an appendix, and it says it's basically the same with a couple of things noted by the NQuads serialization.
<dlongley> -1 to support both, they should be considered equivalent
dlehn: Should we support both? Digital Bazaar has URDNA2015 deployed, what's the best approach there?
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.
dlehn: It does make older implementations break.
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.
<dlongley> +1 to gregg
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.
<dlongley> +1 to gregg
markus_sabadello: Does that answer your question?
dlehn: Yes, I just wanted to make sure that this was taken into account.
<markus_sabadello> multiformats/
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.
markus_sabadello: This has been updated in multicodec group
manu: I had made a comment there about just using the `-1` vs. `-1.0` in there.
markus_sabadello: In the multicodec group they have a rule that doesn't allow a dot, so I had it say `-1-0`.
<gkellogg_> In tests, we use "rdfc10"
manu: Did we discuss needing the `.0` vs. just not having one?
markus_sabadello: No, we didn't discuss that so I just did that on my own in the PR.
gkellogg_: In tests it can be difficult to use dots, so '10'
gkellogg_: That fits with what other systems do sometimes.
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.
markus_sabadello: Yes, it's still open, so someone can suggest changes.
dlongley: This seems fine, it seems informative -- "-1" should cover "1.1" and "1.2" in this particular case.
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.
manu: I don't think it's too strong of an opinion one way or another, so let's move on.
markus_sabadello: Ok, yes, let's discuss on that PR and move on with issues.
<markus_sabadello> https://
<markus_sabadello> w3c/
w3c/rdf-canon#7
markus_sabadello: This is marked proposed closing, Gregg you commented here... Andy opened it originally, should we close this?
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.
manu: +1 sounds like work we want to avoid doing, no concrete upside.
markus_sabadello: Do we want to say something about this int he spec?
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.
phila: I marked this as proposed closing because we haven't commented on this in a while.
<dlongley> +1 Phil, +1 to close
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.
<phila> Proposed resolution: WG will not support generalized RDF. Close issue 7
<dlongley> +1
<gkellogg_> +1
<phila> +1
manu: +1
<markus_sabadello> +1
<yamdan> +1
<pchampin> +1
RESOLUTION: WG will not support generalized RDF. Close issue 7
w3c/rdf-canon#11
<TallTed> +1
<dlongley> +1 to close
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?
manu: +1 to close
markus_sabadello: Maybe we add comment and ask Andy to re-open if he disagrees.
phila: Naming has been discussed, no further discussion, closing.
markus_sabadello: We have 17 other open issues, does anyone have any other issue they want to discuss specifically?
gkellogg_: It's useful to have group response to issue 111.
gkellogg_: Remarks that were sent in last week.
w3c/rdf-canon#111
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.
markus_sabadello: Don't know if everyone has had a chance to look at this. Summary?
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.
<TallTed> ghurlbot, status
<ghurlbot> TallTed, the delay is 15, issues are on, names are on; and no repositories are specified.
<TallTed> ghurlbot, repo: w3c/rdf-canon
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.
<TallTed> ghurlbot, ignore RRSAgent
gkellogg_: We haven't noted difference between "canonicalization" vs. "normalization" -- other uses of "normalize" that we might want to clean up.
gkellogg_: Rather than being faced w/ silence, it would be good for the group to respond to the input.
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?
<TallTed> ghurlbot, status?
<ghurlbot> TallTed, the delay is 15, issues are on, names are on, commands are ignored from RRSAgent; and the repository is w3c/
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.
<dlongley> +1 to gregg ... all looks like editorial stuff as well
markus_sabadello: We could respond by saying we're grateful for the input, will create new issues where appropriate.
gkellogg_: Yes, we could add issues for his input, might not apply all of points, but do appreciate the input.
markus_sabadello: You could do that?
gkellogg_: I'll make sure we have issues for all of the points he makes.
gkellogg_: I can create issues today
markus_sabadello: Once you do that, let Phil and I know, and then we can post a comment on this issue.
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.
gkellogg_: We need an example for datasets, we could take suitable test case and reproduce that.
markus_sabadello: Update examples and update description of algorithm logging to show map from input identifiers to output identifiers.
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.
<phila> gkellogg_: is referring to Issue 109 w3c/
<markus_sabadello> https://
w3c/rdf-canon#10
<gkellogg_> Also relates to #6. w3c/
<ghurlbot> Issue 6 Compare the two algorithms, and decide on basis for our work (peacekeeper) documentation
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
here, we're pretty settled at this point.
markus_sabadello: We're probably not going to use a different algorithm at this point.
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.
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.
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.
markus_sabadello: We have spent several calls and email threads considering different algorithms and the WG has arrived at the current state.
phila: propose close vs. closing?
markus_sabadello: yes, has been a significant topic, let's give it a bit of time to avoid any sort of rush.
gkellogg_: There is a hole in the spec, no technical review will change because of it.
phila: I think that history is important, backs up what's gone into this, and polite-ness. Can Manu still do this?
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.
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.
manu: I don't have the cycles right now.
phila: This is documentation and editorial, we could add it during CR.
markus_sabadello: There are still 17 open issues, please go over the issues and let's continue next week.