Topic call on Resolution Contracts — Minutes
Date: 2020-04-21
See also the Agenda and the IRC Log
Attendees
Present: Markus Sabadello, Brent Zundel, Drummond Reed, Tim Cappalli, Dave Longley, Justin Richer, Brett McDowell, Kyle Den Hartog, Daniel Buchner, Dmitri Zagidulin
Regrets:
Guests:
Chair:
Scribe(s): Drummond Reed, Brent Zundel, Manu Sporny
Content:
Brent Zundel: We’re going to start with resolution contracts, go as far as we can be productive with it.
… Then we can talk about metadata
1. Resolution Contracts
Manu Sporny: continuing from this morning, we had a number of resolutions that put much of this in scope.
… it would be good to reiterate the plan moving forward, then we can discuss PRs, test suite, etc. Going over test suite architecture.
… those are some suggestions for how we get started. We need to wait 7 days before those resolutions are official.
… one of the proposals we need to take is is PRs.
… the dereferencing objection throws a bit of a wrench into the works.
Manu Sporny: https://github.com/w3c/did-core/pulls
Manu Sporny: starting with the PRs in did-core
… markus agreed to close his. Justin raised one. I split Justin’s into normative and non-normative bits.
… the normative bits were further split
… do we want to continue working on them in other split form or should they all be one PR?
Justin Richer: I think that a lot of the content is intertwined between these sections. There is a question is some of what Manu pulled into the non-normative changes, should they even be pulled in.
… if we decide it doesn’t go up there, it would belong elsewhere in the document that gets changed by the other pull requests. so it makes sense to me to take them all as one PR.
… they all point ot one another
… we can trick respec into behaving by pointing at empty sections, but it still would be easier to merge them together?
… that said, I understand why they were split, but it will take a lot of coordination to make sure the different pieces come together in the end.
Markus Sabadello: https://github.com/w3c/did-core/pull/247/
Markus Sabadello: I agree with Justin that it doesn’t make sense to only pull in one or two, with the references between them.
… so perhaps we can use the seperate PRs to coordinate the conversations, but merge them at the same time.
… I will also close my PR, but there is a bit more content I want to move to the new PRs.
Markus Sabadello: will be closed soon
Manu Sporny: wanted to address part of the concerns. Keeping everything aligned an d in sync is the editor’s job. So no one should feel like its not possible to do that.
… the biggest argument for splitting it is to focus on the specific subsections and see progress happening as we go.
Brent Zundel: is anyone opposed to moving forward with the separate PRs?
… not hearing any opposition to that.
Manu Sporny: I do want to point out a couple of things with the PRs, maybe the non-normative one first. I also want to point out that Phil is objecting to the way that the resolution spec is being referred to. also we’ll need to talk about the dereferencing section.
… with that in mind, maybe we move on the other non-normative PR.
Justin Richer: It is my intent to keep 253 open until such time as the content and terms and structure and nature of it has been appropriately subsumed y the other pill requests.
… keeping it open as an easy reference.
Justin Richer: https://github.com/w3c/did-core/pull/253/
Markus Sabadello: Just to respond to what Manu said about Phil’s objections. He seems to be against language that references the resolution specification in a normative way, which may have been a shortcoming of my PR, but my impression was that Justin’s PR took care of that.
… I was confused with Phil’s comments, but he’s not here, so we can’t ask him.
Justin Richer: I am not surprised by Phil’s comments because Manu’s editorial changes reverted the things I added to my PR which more precisely described the relationship between the two documents.
… I’ve added comments to the non-normative PR, and to a couple of the others, but I’m not too surprised. They were fixed, but were effectively regressed.
Manu Sporny: https://github.com/w3c/did-core/pull/253/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR2576
Manu Sporny: That language was copied verbatim for much of it. Some were changed. Posting links.
… the bottom line is Phil has concerns. We can address them. He’s okay with referring to it from non-normative sections
Justin Richer: I don’t think that’s the concern. The line you just highlighted: “some considerations for implementer’s is available in another document” is rather diffreent from: “ the details for implementing a DID resolver …”
… the changes to the language brought up Phil’s concerns again.
Manu Sporny: let’s ask Phil for concrete feedback.
Justin Richer: I also have the same problems with it.
Manu Sporny: Let’s get Phil’s opinion on your suggested changes and if you’re both agreed we’ll get those in
Manu Sporny: https://github.com/w3c/did-core/pull/262
Manu Sporny: Let’s go ahead and take 262. Justin you’ve raised some concerns on this one. Could you go through them and we can discuss?
Justin Richer: yes, I’ll share my screen
… a request, is it possible to back out these types of changes form this PR. Format changes I find distracting.
Manu Sporny: it is possible.
Brent Zundel: my next comment here is pending what we decide to do about putting dereferencing out of scope. Which is a new question
Justin Richer: it is confusing to talk about the component and then the process
… In PR 262, Justin discussed the definition of resolver
Markus Sabadello: Agrees with Justin that it’s first important to figure out what goes in the overall architecture in section 3.4 and what goes in section 10.
Drummond Reed: this matters because I’m working on other text for section 3
Markus Sabadello: I understood in the Amsterdam F2F that section 10 would include the “resolution contract” info, and overall architecture was in section 3.
Manu Sporny: When I looked at the resolution section 10, there was quite a few definitions missing necessary to understand the architecture.
… very rarely do architecture sections go into the “how”, but they just describe the components and their overall relationships.
… typically those descriptions are non-normative.
… that was Manu’s rationale.
Justin Richer: That’s what I wanted to resolve RE what goes in which section.
… Next, the definition of a resolver and the resolution process I found lacking.
… what I proposed was defining in terms of the DID as an input and DID document as an output.
… I will continue to through PR 262…
… language at line 642 is language that might be interpreted as a normative reference even though it was not meant to.
… the reference to the DID Resolution specification needs language like, “this is discussed in the DID Resolution”
Manu Sporny: If the reference to DID Resolution is an informative reference, then there cannot be any normative reference to it. That’s the official W3C test.
… others might see something as looking like a normative reference, but it only changes perception, not substance.
Justin Richer: People’s perceptions are the most important result. “Specifications are programs that run on engineers.”
… if we can be careful on our language in describing things, so we don’t give the wrong impression, we should do that.
… so Justin’s question to Manu is if the changes Justin suggests change the meaning Manu intended.
Manu Sporny: I don’t think so.
Justin Richer: Good. Then that’s what I’m after.
… line 1117 is a small change to the term “reference”.
… MIME types section is fine.
… line 2588 has edits to better signal intent.
… Justin prefers the framing as a “function” with “inputs and outputs”.
… line 2607, Justin explained why he used the term, Resolution Metadata. He saw five categories of such metadata.
… this section covers not just resolution metadata, but also document metadata, input metadata, as well as inputs and outputs of data for dereferencing.
Markus Sabadello: Fully agrees with what Justin said about metadata and the different types. So he would like to reuse the same structure.
… it would be good to have the same structure for all of these inputs and outputs.
Justin Richer: It can be hard to see how this proposed structure works with the other related PRs as they work together.
Dave Longley: it seems like the section should explicitly say that the data model is reused in a number of places instead of inferring it from seeing it in multiple places
Manu Sporny: Has read the PR several times, but didn’t understand that it was generalized. +1 to generalizing…
… but the only time this generalized structure that will be needed is for metadata about resolution.
Justin Richer: This structure will be for describing the inputs and outputs to resolution.
Dave Longley: +1 for their own section and forward references
Justin Richer: Justin believes that this metadata should go into its own section, and that should go into its own structure.
Manu Sporny: Finally I understand. “Metadata” means all types of metadata. If the title of this section was narrower, then it would more accurately describe the section.
… there is subject metadata, document metadata, and resolver metadata. What is being described here is the latter two.
Justin Richer: I get the concern, but I would like a better name.
Markus Sabadello: Was not certain what DID subject metadata is.
… in his mind, there is DID subject metadata - that goes into the DID document. Then there is DID document metadata and resolution metadata.
Markus Sabadello: My comment a few weeks ago about 3 buckets: https://github.com/w3c/did-core/issues/65#issuecomment-597030882
Justin Richer: drummond: these three buckets are also what I was thinking
Drummond Reed: I was going to ask the same question. those three categories are what I was thinking. My question is simply: what did Manu mean by did subject metadata?
Manu Sporny: Was just referring to the group’s desire to have three buckets.
… WG members have discussed DID subject metadata as “attributes of the DID subject”.
… Manu does not believe that is semantically clean, but others feel that way.
… Manu would happily go down to just DID document metadata and DID resolution metadata.
… so maybe we need to have that metadata discussion first.
… if we decide on just two buckets, then it’s easier to name sections like this.
… one more point: there is somewhat of an argument of whether this section belongs someplace else. This may end out delaying the metadata section one bit.
Dave Longley: +1 to see if we can agree that there’s “data” (about the subject), and “metadata” which is either about the DID document (which contains the data about the subject) or the DID resolution process
Markus Sabadello: Clarified that by “three buckets”, we didn’t necessarily mean the third bucket was metadata. The DID document itself mostly describes the DID subject.
Justin Richer: Shares Markus and Drummond’s understanding that one of the buckets was the DID document itself, with the two other buckets being DID document metadata and and resolution metadata
Dave Longley: Agrees that we should make those three buckets clear in the spec.
Markus Sabadello: I could imagine moving metadata to a separate section.
… if we have DID document metadata, that can exist separately from resolution metadata.
Dave Longley: I just want to make sure we call out the three buckets first – then there’s no confusion with whatever/wherever we describe metadata later.
Markus Sabadello: in both Markus’ and Justin’s PRs, the form of metadata is not specified. It could be in resolution protocol headers, or even inside the DID document in a special section.
… so currently it’s only in the abstract.
Manu Sporny: We are almost all the way through the PR, without a lot of objections, so then we will be ready to merge.
Justin Richer: Just a couple of small egregious things…
… a lot of the same types of things as above.
… some of them are definitional. Some are refining definitions.
Drummond Reed: did we solve metadata?
Justin Richer: that was the goal!!
Brent Zundel: thanks everyone, good discussion, see you Tuesday