Meeting minutes
Agenda Review, Introductions (5 min)
Debrief from TPAC (5 min)
ottomorac: any impression from TPAC, for those who were there?
<ottomorac> Here are TPAC meeting minutes: https://
manu: we processed a lot of issues
… we had a lot of things ready for PR
… which means that now we need people to write those PRs
… we identified that we need to raise PR at a faster rate than what we have been doing
… Not much discussion on the DID core specification.
… I think we were supposed to publish a CR in November, but nothing published yet.
… For DID Resolution, we went through a lot of issues, nothing really blocking.
ottomorac: I know swcurran has been preparing some things about DID Path discussion
… my understanding is that Wil will allocate some time next Thursday for that topic
DID Resolution PR Processing \[1\] (15 min)
w3c/did-resolution#242
ottomorac: just some clean up, approval from swcurran
… it would be good to have more approval, it seems straightforwad
w3c/did-resolution#206
ottomorac: this one is about self-attested DID document metadata
… also approved by swcurran, some changes by manu
… it would be good to have Markus for this one
JoeAndrieu: some text close to the PR, but not changed by the PR, is incorrect
… I can raise this as an issue
swcurran: [proposes alternative text, that JoeAndrieu is happy about]
w3c/did-resolution#215
ottomorac: this one has no review yet
<JoeAndrieu> Alternative language from "the metadata ... or from the did method" to something about "from the did resolver, as defined by the did method"
ottomorac: probably one for Markus, but maybe others have feeedback?
<swcurran> swcurran: The DID Method defines the metadata, and JoeAndrieu noted that the DID Resolver implements and could be compromised.
w3c/did-resolution#217
<ottomorac> Prefer UTF-8 for DID Parameters #217
ottomorac: related to an issue raised by Addison Philips as part of the i18n review
<ottomorac> Also appreciate reviews on 219, 248, 253
Unclear definition of ""Read"" operation for DID methods #230 \[2\] (7 min)
<ottomorac> w3c/
<ottomorac> There is one additional clarification that Will requested on this issue regarding the Resolve vs. Read Operation and how we are managing that in DID Core. Markus has provided his perspective, and Will would like Manu to weigh in here as well.
ottomorac: this issue had some conversation in the past day
… Markus would like Manu's take on this, as it may also impact DID core.
manu: I think I agree with what Markus is saying in this issue
… I need to look in more depth on how it impacts DID core
… Markus says that there is a difference between read and resolve
… "read" just instructs the resolver to perform the resolution
… "resolve" is the process applied by the resolver
… we could transfer this issue to DID core, I believe it is editorial, so we could make it in CR
JoeAndrieu: I do think we need this nuance, but I'm not sure I would put it exactly as manu did.
<manu> +1 that there is nuance to tease out
JoeAndrieu: for me "read" is what the resolver is doing, "resolve" is what the method defines
<KevinDean> "Resolve" is a function within "Read".
JoeAndrieu: we can discuss on proposed text
<swcurran> Wow...Joe, I think the reverse.
swcurran: I think the only reason the term "read" is here is because the acronym CRUD is used.
… if DID core dropped "CRUD", resolve would be enough
<manu> We'd have Create, Resolve, Update, and Deactivate :)
swcurran: but +1 to tease it out in a PR
DID-Resolution issues
w3c/did-resolution#234
ottomorac: this one is pretty much ready for PR
… Will has added some elements
<ottomorac1> q>
<Zakim> JoeAndrieu, you wanted to comment on #217
JoeAndrieu: the resolution was about the accept headers in HTTP
ottomorac: which of the two statements would be correct?
JoeAndrieu: I think that it reads akwardly more than it is wrong
ottomorac: do you think you could propose a better wording?
JoeAndrieu: maybe. I think Will has an idea about how to resolve this.
w3c/did-resolution#217
JoeAndrieu: I just added a comment. The language that removed the percent-encoding bit that caught my eye.
… I don't think that we can remove it, because if we use UTF-8 in a URL, it will get percent-encoded.
pchampin: is percent-encoding our responsibility?
JoeAndrieu: as we are defining URL parameter, they are defined as being part of a URL, so they need to be percent-encoded
manu: there are 3 different things here
… I agree with JoeAndrieu that things will need to be percent-encoded; we should not re-define it, but refer to the RFC
<ottomorac1> Addison talked about RFC3987: w3c/
manu: another point is: are we talking about the the value space, which need to support UTF-8, or the lexical space, where percent-encoding is required
<Zakim> TallTed, you wanted to check whether we're staying with RFC 3986/7 or moving to WHAT WG's URL spec
TallTed: RCF3986 and RFC3987 travel together, they don't really make sense without each other
… another question is: are we sticking to these RFCs, or moving to the WHATWG's definition of URL
<ottomorac1> w3c/
TallTed: (mostly the same, but slightly different)
<Zakim> JoeAndrieu, you wanted to say I see the fix
JoeAndrieu: my concerns have actually been addressed
… there is a global statement stating that everything must be serialized
… I got distracted by the title of the issue; with TallTed's clarification, the text seems fine
… I think we should talk about the issue raised by TallTed; the VC WG has moved to the WHATWG's definition of URL
manu: now reading Addison's commentary, it is aligned with what I said.
… He calls it "logical" vs "serialized", what I called "value space" vs "lexical space"
… He says we don't make the distinction and we should make it.
… He says "don't constraint systems to be ASCII only", talking about the value space
… There are two encoding algorithms, we need to be carefuly which one we refer to.
… We need to be sure this change does not impact also DID core, looking at it right now.
ottomorac: Will pointed out that DID parameters were dropped from DID core 1.1 .
manu: if that right?
JoeAndrieu: if that's right, it feels weird to me.
manu: DID URLs define parameters, it talks mostly about the lexical space
… we should be good.
… I agree with JoeAndrieu that it would have been wrong to completely remove them.
… This now raises the question of DID Resolution re-stating something that DID core states more cleanly.
JoeAndrieu: looking at the differences between RFC3986 and RFC3987. They are not many, but they may be significant.
… RFC3987 aims to support international characters that are not supported by RFC3986.
… We could switch to RFC3987. There are questions about similarly-looking characters, but I don't think that's our issue.
manu: going back to the PR. I think it is fine as is.
… I don't think we need to change anything.
… JoeAndrieu would you agree?
JoeAndrieu: it addresses my concern with percent-encoding.
… But there is a shift about international characters.
… The shift to RFC3987 would allow characters that were not allowed before.
… We need to think whether it would break implementations?
… Allowing international characters is a good thing as long as we don't introduce security or privacy problems.
manu: trying to get closure on this. §3.1 in RFC3987 describes how to map an IRI to a URI.
JoeAndrieu: I was looking to the ABNF, §2.2. 'ucschar' is a class of new characters
manu: ucschar is not UTF-8, but can be converted to UTF-8.
… I think we are fine with the PR as is.
JoeAndrieu: +1
w3c/did-resolution#232
<ottomorac1> Can we avoid term definition duplication across DID specs? #232
ottomorac1: we have some guidance from manu, now we need a willing participant to implement the changes
… I could try this on
… I may require some help, but I can make an initial proposal.
w3c/did-resolution#228
<ottomorac1> Fix bug in implementer overview description #228
ottomorac1: we discuss that on a previous call, but manu was not here
… did it get discussed at TPAC?
JoeAndrieu: this is about the fact that we define DID resolution as only using the DID
… but that's not exactly how it works.
<swcurran> +1 to Joe's description
JoeAndrieu: we start with a DID URL with parameters; we extract the DID and the parameters, and use the parameters to configure the resolution
<manu> +1 to Joe
ottomorac1: I think this is an issue for Markus
manu: we talked about this at TPAC and came to a resolution. This is marked "ready for PR". What JoeAndrieu said should be addressed.
w3c/did-resolution#225
manu: it is editorial
… I'm wondering: should we spend call-time discussing issues that are marked "ready for PR".
… All those issues need is someone taking them on.
… We processed these at TPAC, let's not re-process them.
… Some discussions brought clarifications, but this one does not need any.
… At this point, I think the chairs should appoint people; asking nicely for volunteers will not work.
… This is just a suggestion, though.
next meeting
ottomorac1: next week we will allocate time to discuss path
swcurran: yes, I think we need to align on that
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/