Meeting minutes
Agenda
<ottomorac> transcriber-bot, resume
Otto Mora: Um, review the… continue the presentation on that, uh...
… Uh, high-level algorithm that, um
<ottomorac> https://
Otto Mora: Will had prepared, and so… that would be… that would be the main topic, unless somebody else wants to… Uh
… Discuss any other agenda item, or
… Yep. Yeah, let's go ahead, uh… well, let's
Will Abramson: Yeah, well, I mean, I can talk about where we're at, or where I think we're at, um...
… So I… I got in a PR and merged it that fixes the formatting, so at least now, hopefully, we have a formatted spec we can work on, so changes won't. FPS students
Status and High Level Algorithm
Will Abramson: you know, some of the PRs before doing big format changes. Hopefully fix that
<Wip> w3c/
Will Abramson: Um, and then, yeah, I put in this PR331
… Which, I don't know if anyone's had a chance to look at it, probably not, I only got it in… Yesterday, I think
… Uh, and I know in the discussion on that, PR, that. I think there are still some things that
… We haven't finalized. I have put in that PR just a spec text. People could review and then provide comments
… on things that we might still need to discuss. I think, in particular, from
… last week's call, we didn't really get a chance to properly discuss Step 5, use the resource. I know, Manny, you mentioned that
… That's probably the bit that you would argue about, so we should definitely get to that today. Um
… Yeah, and then I also note, like, Marcus is kind of pushing back about this, did URL, did
… issue, which I expected, but I kind of hoped that the way I wrote the PR is… it's
… Just not trying to address that issue head on, and maybe that's a mistake, or
… I just wanted to get this scaffold in so we can move forward, and then we can have a discussion about did versus did URL
… Um, and make a decision about that, but I didn't think that was this decision that we're trying to make here
… So, maybe I'll pause there, and if anyone has any… if they've had a chance to review the PR, great. If not, then… I mean, we can go back into the, um
… slides as well, I'm happy to do that, if that's more helpful. Right
Otto Mora: Mm-hmm. Adam?...
Manu Sporny: Uh, just a general plus 1 to PR331. That is exactly what I was hoping we would be able to. Um...
… put into the spec. It's… it's short and sweet, and talks about each step, and
… that's exactly what we need, I think, um, to move forward
… So, my guess is, uh, we should all review, you know, over the next week, and then merge
… Um… how long… yeah, we should merge after a week before the next
… Special topic call, if there are no objections, of course
… And then the expectation is that we would then, uh
… Specify the algorithm
… for each one of those as separate PRs
Otto Mora: Hmm. Well...
Will Abramson: Yeah, I think that's exactly right. Um, I mean, I'm hoping that on this call today, uh, we can...
… kind of review it, or, like, talk about some of the bits that I was less confident that we had a consensus on
… and at least in the group who's here today, get through that, because I'm hoping tomorrow, I haven't managed to do this yet, but we can always start talking about step 3. The retrieving of the resource
… Oh, no, determining the retrieval strategy, so that when we do merge this PR, we've already made some headway on, like, the most. contentious piece
… I think step one and two
… I don't think we need to discuss today, unless people feel like we want to go deeper and unpack that
… Uh, so maybe we can, like, revisit, um
… Step 4 and 5, just talk about that, because that's kind of where we were at toward the end of last call. We were kind of running out of time
… Uh, so step 4 is, um
… Retrieve the resource, and
… Um… now, there was some discussion last time about whether we should retrieve the resource at all, right? Whether it's
… not the responsibility of the QRL dereferencing algorithm
… to do this retrieval. I mean, currently, in the
… spec, we don't do the retrieval, we just create the URL, and then
… Append a fragment to it, if there is a fragment, and return that
… I don't expect somebody else to fetch the URL, but that does expect or depend that the. thing that is returned is a URL. Um
… So
… But I don't know if anyone's on the queue
Otto Mora: Um, no, we don't have anyone...
Will Abramson: So I think, I mean, my personal opinion is I think we should be retrieving the resource, um...
… and I think I agree with what Dimitri was saying, like, it's not that did your LD referencing specs
… Role to define how to retrieve the results
… it is… so I tried to capture that. Maybe I can read out what I wrote for retrieve the resource. I wrote, the next step is to retrieve the resource identified by the DID URL using the determined retrieval strategy
… Retrieval strategies may be defined in external specifications
… It is up to the client to determine if they are able to retrieve the resource. Using the specified strategy
Otto Mora: Okay...
Manu Sporny: Yeah, that sounds fine to me at a high level. My only, the only nitpick there is, you know, there would be information. Extra information probably needed...
… By the retrieval strategy, um
<dmitriz> so, that sounds a bit better. but then why are we even mentioning it. (the retrieval strategy, retrieving it)
Manu Sporny: you know, to pass to the client. Um, and here, it's not clear if the client is dereferencing. It's like… it's like there are two clients here, right? Like, one of them is the… the
… dereferencing client, and the other one is the retrieval strategy client. Um
… Uh, for lack of a better, you know, words to put it into. And so that's a little confusing, um, I mean, not… overly confusing
… Um, and plus one for saying, like, we don't specify how to do this. Um
… there may be an exception to that, where we're like, hey, if it's HTTPS, then use HTTPS to retrieve it. Like, the retrieval strategy… if a retrieval strategy is HTTPS, then
… follow, you know, the HTTP spec to do the retrieval. Um
… I'm not sure where Pat's service fits in
… here, I'm guessing it's determined the retrieval strategy. So, those are the open questions that I have, right? I mean
… I would like to avoid defining things in detail, but I think that's what you already have set up
… Uh, and we should be able to hand off to external specifications. That's it
<Zakim> JoeAndrieu, you wanted to ask about multiple clients? there is only one client
Otto Mora: This is… So...
Joe Andrieu: Um, yeah, Manu, I'd appreciate if you could unpack why you think there are two clients, because there's just one client...
… And it is doing dereferencing, which includes… Um, calling Resolve
… So, I didn't follow why you think there are two here. Um, but also, I think PathService is not
… Uh, included here, because this is not changing the spec in that way yet. That's a different conversation
Otto Mora: It will...
Will Abramson: Uh, yeah, I promised I wanted to queue also to talk a little bit about the path service piece. Like, I think, to me, that is...
… The, like, outputs from step 3 retrieve the resource, and, like, what goes into step 4, use the resource, is the most
… uh… unknown for me in this sort of flow, like, what does it mean
… To… what is the outcome of determining the retrieval strategy?
… that then helps Step 4 know how to retrieve the resource. I think it still feels a bit underspecified, but I think one of those retrieval strategies. Would be path service
… And I guess the question is
… is it path service, or is determining the retrieval strategy actually already interpreting past service and constructing the URL? So it's just passed to the retriever resource
… My sense is that the retrieval strategy is path service, and then step forward compiles the URL and retrieves, but
<dmitriz> it is not up to the DID Resolution/Dereferencing client to determine the retrieval strategy
<dmitriz> that's mixing way too many layers
Will Abramson: Um, as I said, that's the most unknown to me, and I think that'll come clear when we unpack Step 3 in more detail
<Zakim> manu, you wanted to note "two clients"
Otto Mora: Okay, uh, Manu...
Manu Sporny: Yeah, to, uh, Joe, to an attempt to, uh, answer your question, um...
… There's determine the retrieval strategy and retrieve the resource. And
… I am… it could be all bundled into one client, and we could say, like, this is… this is… the client is capable of doing all of these things. That's one approach, and I think that might be what you're suggesting
… Uh, the other approach is, well, you know, there's, like, subroutines that you could potentially call to determine the retrieval strategy and collect all the information
… needed by the retrieval strategy, and then to retrieve the resource. Like, there's a… for example, there is a
… difference between an HTTP client retrieving the resource and a, like
… on-blockchain mechanism to retrieve the resource, right? Those are two different clients. There's an HTTP client and a blockchain client, and the logic between both of them is, like, not really shared when you're retrieving the
… the resource, and both of them may need different information, like the HTTP client probably only needs an HTTP
… uh, URL, um, but it may also need, like, a media type. Um
… Whereas the retrieval strategy for a blockchain thing, you know, might need, uh, you know, a number of different addresses and beacons and whatever, so that retrieving the resource, you know, can be performed. So that's why I'm thinking, like
… Is that a part of
… the dereferencing client, or is that, you know, code that the dereferencing client can call, and do we need to make the distinction?
… Those are kind of open questions in my mind. Um, I don't have a strong preference for one over the other
… Um, other than, you know, we… over the couple… past couple of months, it's been… Very clear that, like
… The retrieval strategies matter here, meaning they use… some of them use totally different information to get, uh, to retrieve the resource
<Zakim> JoeAndrieu, you wanted to yes, we are only defining a single client doing dereferencing. the additional implementation details are not what we are standardizing
Otto Mora: Mm-hmm. So...
Joe Andrieu: Um, yes, I do think that all we are standardizing here is what the client of a resolver needs to do before...
… during and after resolution. I think it is the additional complexity of how you might break any bit of this software into different components
… that has, I believe, anchored the confusion in the current spec. Like, you might use a JSON parsing library. We're not going to break that out and specify that you might do that
… Um, I just don't think it's the right level of detail. Um, but to the point about an HTTP URL is sufficient for you to understand the strategy, that is unfortunately not accurate, and I've
… I feel like I've said this many times, and it's a little bit frustrating. When you have a data integrity anchored URL, like you have with, um
… linked resources and did link resources, the URL fundamentally is not sufficient to know if you have the resource
… Um, so we cannot reduce the output there and say, hey, you've got an HTTP URL, now you know what to do
… The whole point is the DID architecture allows you to access data that may not be anchored. to URLs other than did
… So, the notion is that whoever's resolving this needs to be able to interpret the did URL, and interpret the did document, and make enough sense out of it
… in order to perform whatever the retrieval requires. And in some cases, it might mean talking to Bitcoin, in other cases, it might mean applying an algorithm after you get what you think might be the resource
Otto Mora: Doing well...
Will Abramson: Uh, I just wanted to say, like, I think...
… Definitely, there's going to be work in this spec to define, like, what we mean by a retrieval strategy, and, like, what
… Like, what's the minimum required for somebody to define such a thing?
… So that the referencer can know, oh, this is a retrieval strategy
… And, you know, I do these steps to retrieve the result. And those steps might just be
… executing, like, HTTP GET on the URL, but it might be all sorts of other things, and, like, I think the ways that
… we've explored that that is possible, is through a type, right? Like, the type… it might be a type of service, or it might be a type of
… Like, extension, um, like, linked resource, or it might be
… I mean, I don't know if the metadata, like, did link resources has the type, but there's different ways in which you can add retrieval strategies to
… your DID document, or your DID resolution result. And we just need to have some common way
… That those retrieval strategies can signal to a client, or like a
… Performing dereferencing, that they are retrieval strategies, and they should be considered. Um
… I think that's all just work that we need to do. And we can talk about that tomorrow, uh
… But assuming we have that, I mean, maybe I can just read out as well, um, step 3. My language?
… because I do want some good, you know, feedback on this, and if these are fine, like, I think they are trying to be quite high level and not controversial, you know, I'm not trying to get into all these details
… Uh, but just flagging that we will have to get into them at some point. So, step 3 is called Determine Retrieval Strategy
… Uh, it says, after successfully resolving the did document and accompanying metadata
… The next step is to determine the appropriate strategy for retrieving the resource. identified by the DID URL
… This involves analyzing the content of the did resolution result
… Including the DID document and its metadata, along with the path and query
… components of the URL to determine the method for retrieving the result
Otto Mora: Well, might it help if we just screen share the text?...
Will Abramson: Sure, yeah, I can do that...
Otto Mora: Maybe just...
Will Abramson: Oh, yeah, I only have one screen today, though, so it's not… Too crazy...
Otto Mora: I'll keep tabs on… on the hands. No worries...
Will Abramson: Yeah, actually, I don't think I can easily do that...
… I mean, everyone could bring it up, right? Like, it's 331… I can drop it in the minutes again
Otto Mora: Yeah, I'll… let me try, hopefully...
<Wip> PR is here: https://
Otto Mora: Mm-hmm. Here
… So yeah, so from… from step 3, right, do I just highlight it?
… Determined retrieval strategy here, right? This one?
Will Abramson: Yep...
… Yeah, I mean, I just wanted to get a sense of that that's the text we have, or… I mean, I think Manny was on the queue
<Zakim> manu, you wanted to note, do we have issues w/ the current PR?
Otto Mora: Go ahead...
Manu Sporny: Uh, yeah, I guess the question is, do we have issues with this PR? I'm like...
… I think it reflects in general. I mean, there are details we can add to it, but like… Would anyone object if we merged this thing?
… And if so, what are the objections, and what can we change, and that sort of thing
Will Abramson: Yeah, I...
… The main thing that I wanted to talk to you, really, about, Manu, is, like, step 5, and
… And… is that the right name? I mean, I know that's something that you had some concerns over, like. Right
Manu Sporny: I'm not gonna block the PR, like, you know, like, we can figure that out later. Like, if people don't want to implement that step, they won't implement it, right? And so...
Will Abramson: Mm-hmm...
Manu Sporny: I think it's much, much more important to get the first couple of things that we agree to, and get the algorithms in there, and then, you know, we can… we can, uh...
… once we get that foundation in there, like, it becomes much, much easier to… like, if we're arguing about item 5, like, that's where we spend, you know, most of our time, and the other ones are in the spec, and we've got them sorted, we're in great shape
Will Abramson: Mm-hmm, mhm...
Manu Sporny: Right? So… so we can talk about it later, I guess. I don't really...
… you know, it's fine. Like, if we're going to retrieve the resource, if we as a group decide, like, that is something we're going to define in the spec, then that's… that's fine. I'm not gonna, you know
Will Abramson: Hmm...
Manu Sporny: block the group from wanting… you know, if we have consensus to do that, that's great. So I don't think we need to talk about that today. I'm more concerned about, like...
… Can we get the base layer in there now, and then start getting into the details?
Otto Mora: Dimitri...
Dmitri Zagidulin: So I, uh… just like Manu, uh, I would not… I'm not going to formally object or block the PR, but I do want to go on the record...
… That I think this is absolutely the wrong architecture and the wrong direction to go. We should not be
… Like, look at what we're saying. Use the resource, or retrieve the resource. This is absolutely not the point of the domain of the dereferencer. Whether or not
… the client wants to use the research afterwards is up to them. It is not up to us in our spec to say it
… Uh, this… this feels… this feels redundant, and
… overly prescriptive. Uh, same thing, we should not be retrieving it in the spec. Client can retrieve or not retrieve as they see fit
… I think, uh, I think the spec should end at returning the URL
Otto Mora: Well...
Will Abramson: It does, interesting. And it seems like your moral perspective, like, the… or, like, at least the general district as it is today...
… But, to me, I mean, when you just Google about dereferencing and stuff, like, the point of dereferencing is to get the result, isn't it? Like, that's my understanding of dereferencing
Dmitri Zagidulin: Yes, but notice that no dereferencing spec says use the resource afterwards...
Will Abramson: Yeah, well, but, like, all that's happening there, or, like, one of the reasons that you have that step, if you ignore the name, is it's about handling the fragment, so, like, finding the secondary result in the resource that you've retrieved...
Dmitri Zagidulin: Also, notice that's not in the...
… In the, uh, resolution, uh, or order referencing specs, like
… That's optional and up to the client afterwards, whether to do the fragment resolution
Otto Mora: Is it just an… is it just a name, though? Like, maybe...
… I wonder, like, is it just a optionally process
… Post-processing, something like that, optional post-processing, or just… I don't know if… yeah, maybe
Dmitri Zagidulin: My point is, where does this stop? Do we put in the spec, then go on with the rest of your program, or then go on with whatever you were intending? Like, why do we need to say that? They're gonna do it anyways...
Otto Mora: Yes...
… Let's… That is
Manu Sporny: Um...
… The way I'm interpreting this, Dimitri, is not a prescriptive thing. So, so, uh, one thing you said I think is not correct, which is
Dmitri Zagidulin: Yes...
Manu Sporny: Um, when you define a media type, you have to define what the fragment means in fragment processing. So, so that is definitely in specs that are out there...
Dmitri Zagidulin: I'm...
Manu Sporny: Um, and in some cases, it's pretty prescriptive. I'm not saying we should...
Dmitri Zagidulin: Hold on, hold on. Hold on. But that's in the media type spec, not the resolution spec...
Manu Sporny: Sure. Yeah, yeah, yeah. So, so, what I'm saying is that there are specs that define that, and this spec… this spec is more akin to the… let's look at HTTP, you know, dereferencing...
… That spec says media type matters, and if you want to know about fragment processing, go over here and do it, but it does talk about, like, if fragments exist
… Right? And you should process them. And I think that's the… that… I think that's as far as
… we're suggesting anyone should go in this spec. It is not going to be a prescriptive description of, like, this is exactly how you do fragment processing. It's… my hope is that we're going to basically say, hey, fragments exist, and this is where you process them
… uh, you will, you know, have to… you know, how you process that fragment is highly dependent on the media type and yadda yadda. So we do the exact same thing that the HTTP
… specs do today, which is… which is, uh, establish that, yes, it exists, and there is a part of this process that you do fragment processing, and all of the details. Or elsewhere
Dmitri Zagidulin: Yes, it does, it does. And if your concern is to remind people that fragments exist, maybe we can just do that. Maybe we can, instead of saying...
… Retrieve it, and then use it. We can just say, hey, fragments exist, don't forget to process it
Otto Mora: Okay, Joe?...
Joe Andrieu: Um, yeah, I'm surprised how strongly you're opposing this. I think I understand that your sense is, hey, we've got this resolution endpoint, that's what we're talking about, talk to it...
… What you do with your results is your business, and I can appreciate that, um, except for two things. Um, one is, I don't think people know what to do with that resource
… Uh, at that level, because they don't yet have guidance about how to deal with all the different things that they might need to do to actually get the resource
… So we've created an insanely complicated system that has multiple different layers at which you might use different information to go get the actual resource
… And so I do think we need to explain that. Um, but the other thing is, looking at 3986, it absolutely explains about secondary resources and what a client needs to do to finish, uh, dereferencing
… And so, to say that fragments aren't discussed in the base definition of URLs, and the fact that you might go from a primary resource to go get a secondary resource
… the fact and how they talk about it is really how we're trying to talk about this. Like, it says things like
… Um, uh, just because there is a fragment doesn't mean the retrieval's gonna happen. Like, the spec absolutely, 3986 talks about retrieval
… Um, and they're trying to give guidance for when someone is using this weird thing called a fragment, which is different
… from how do you apply that fragment in the processing of that URL?
<JoeAndrieu> https://
Joe Andrieu: That's it
<Zakim> JoeAndrieu, you wanted to clarify what 3986 actually says
Otto Mora: Mm-hmm. Okay, uh, balance?...
Manu Sporny: Yes, plus one to what Joe said. That's why I'm kind of like, eh, no, it really does talk about fragments. And it does matter that, you know, there's… there are details there that are in other specs, but I think as Joe said...
… we're just trying to give people a framework to think about the tail end of this. That's my personal opinion, is that's probably where we're gonna end up. Like, the first couple of steps are very concrete. Like, this is, you know, these are the inputs, these are the outputs, you're gonna get
… you know, you're gonna pass in options, you're gonna get a DID document out, you're gonna use the URL, and we're gonna be very prescriptive
… In the beginning. Um, but towards the end, I think around determine the retrieval strategy and retrieve the resource
… We may not… we are probably not going to be able to get very detailed there, because those are
… Potentially did, you know, um, uh, did method-specific things
… Um, and so we may keep those at a fairly high level. I… and the details matter here, and I think we'll get into the details later
… But all that to say, I think these steps are the framework in which someone should think through
… How, you know, you get to the thing you were originally wanting to get to in the… in the beginning
Otto Mora: Mm-hmm. Well...
Will Abramson: Yeah, I think that's right. I mean, step 5, use the resource. I don't imagine there is going to be any details there, right? Like, it probably… maybe the paragraph needs to be tweaked, but if you have a look at. like, Joe's initial attempt at this...
… it… there is no steps, or… I mean, there is a step, but it's just, like, describing this at a high level. You know, it's basically saying
… You've now, like, dereferencing is now complete, you've got this resource, you know, apply the fragment, use it in your context
… Uh, it's not saying how to use the resource
… But just that, you know, you've done. And I guess it's like, I mean, without putting words into Joe's mouth, it's like saying, like. Maybe this doesn't return
… But, you know, it is ended, I think, right? Like, this is the final step
… You might have to apply a fragment, but then you've got this thing, and you can do with it what you want
… Uh, then the other thing I was going to say is, like, I think absolutely some people might end at step 4, or, like, for example, if we want to support. Marcus is, um
… You know, this function signature, uh, as, like, a
… optional thing that, you know, people might implement. Um
… that people could even bind to, right? Like, that really is ending at step 4. Um
… just naturally. I mean, that's what happens today in the spec, even though the function's called dereferencing, it really. It's only about dereferencing the resource
… and then you get the results back, and then you use the resource, right? You apply the fragment, and you do stuff with it. But that's… uh… Anyway, I don't know if that helps at all
Otto Mora: Mm-hmm. Um...
Will Abramson: Yeah, so...
Otto Mora: Don't have anybody on the queue. I don't know, Dimitri. Go ahead...
Will Abramson: I can keep going. I mean, um...
… So, I mean, it's just good, I'm not hearing, like
… I think we're generally in agreement. I mean, Dimitri, I think I'm hearing the most pushback from you, which is fine, um… But not enough to block this. Um… yeah
… So that's great. I mean, obviously the PR will be open, and we'll try and merge it before Wednesday
… Uh, but please, in the meantime, do read all the text and have comments on it. Like, I also
… um, put some sort of text, you know, like, when I created the PR, like, I did my review of, like, status of it, and raised some. questions, um
… One of the questions I have, which may be more general and doesn't need to go into this PR, um
… but is about, like, error handling. I mean, this was from my slide deck, actually, but we didn't get to it
<dmitriz> section 3.5 of the url spec explicitly says "As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place." <- that's the opposite of our instruction saying "retrieve it"
Will Abramson: I think because in the current spec, it has this function signature, we have very explicit, defined errors. That are raised, um
… You know, with specific types and all that, and that's because, in part, so that the function signature can return
… in, like, a structured way, what errors occur from it. I think in this new approach, when you're imagining that it's the client doing dereferencing
… we perhaps wouldn't specify in as rigid a way, like, which types of, like, the exact structure of the errors. Like, I don't know, I would be interested in what people think about how we
… Humble errors, and, you know, thinking about what happens in the current spec today
… Um, whether we should keep that or change it
Otto Mora: Bottom...
Manu Sporny: I'm saying this without, you know, refreshing what happens in the current spec today, but in the VC data model and BCOM specs, we have algorithms, and we basically say...
… Or raise an error of this type, and we have a section that talks about the types of errors, the common errors that could happen
… Um, so, you know, and it's unified across, um, BC
<manu> https://
Manu Sporny: data model, data integrity, and VCOM. Uh, it works fairly well, I think. Um, so let me link to some sections here
… This is the section on error handling. Um
… And, uh, we use problem details objects, which is an ITF, you know, RFC to do it, RFC 9457
… Um, and then, uh, we, uh, also… let me try and find
<manu> https://
Manu Sporny: um… VC data model
… We've got, you know, problem details objects here, um, and then… parsing
… Uh… well, let's
<manu> https://
Manu Sporny: let me… let me try and find an algorithm where I think it's in, like, data integrity. Um
… Here are the processing errors and data integrity
… And then, uh, proof generation
<manu> https://
Manu Sporny: And in these high-level algorithms, um, which some of what we do in did resolution might be higher resolution, or, you know, might be, um
… uh, kind of abstract algorithms, um, we say an error must be raised and should convey an error type of, and then we specify the error type, and we link to the appendix, so
… I suggest that's how we do it, because it works fairly well, and we may already be doing that in the. Did resolution spec
Otto Mora: Well...
Will Abramson: Great, yeah, no, that is...
<Wip> https://
Will Abramson: I mean, very much how we are doing it in the data resolution spec, if you see here
… I think the difference is, currently, in the dereferencing algorithm, when in the resolution, we say we return an error in a specific, like, metadata structure
… Whereas, I think there, you're just saying you raised an error. Um… Um
… And then if the function that we might wrap around, it wants to return it, then it can figure out how to do that later on, right?
… I think that makes sense to me, to be maximum
Markus Sabadello: Uh, yeah, yeah, exactly. I mean, we… we have had...
… Error always as one of the properties in the metadata that's returned, and we have had that both in
… in the data resolution algorithm and in the DTO dereferencing algorithm, right? So both can… can return errors
… Resolution algorithm… oh, sorry, both can return metadata, right? The resolution algorithm
… returns the resolution metadata, and the DTRL dereferencing algorithm returns DTRL dereferencing metadata, and both of them have
… A property called error, and in the current specification, the algorithm
… says which error to return in certain situations, right? Are we
… Are we discussing changing that, or I
… Sorry I changed late, but I don't really understand why
… Um, if what we want to change about the error handling
Otto Mora: Madam?...
Manu Sporny: Um… I, I somewhat have the same question, um, Will, you might be… So...
… either we are very strict about the data structure that's returned, like, you know, there's a function signature, and there's a return type, and we're very, very strict about the return type that's returned. That's one way that we could do it, and I think that's the way the current spec is written
… Or, if we want to loosen it up a bit, we can say an error is returned and not specify how that error is returned. But we definitely say the error has these properties, and yadda yadda. And I think the only difference between the two
… is, you know, saying, you know, either it goes in the metadata structure, and this is where it goes in the metadata structure, and this is the field name, um
… Or, we say, an error is returned, and we're kind of like
… you know, we don't… we don't specify in detail. Either way can work, Will, so I'm kind of wondering
… Does that answer your question, Will? Like, I think we have a path forward, whichever direction we decide to take
Otto Mora: Yes...
Pierre-Antoine Champin: uh, one data point, maybe, uh, in the RDF Insparker Working Group, I think we, uh...
… We are using the term signal an error. Uh, the idea is
… That, uh… it's actually even more flexible, because the idea is that it does not necessarily impact the
… flow of the algorithm. It doesn't necessarily exit. Of course, we could say signal an error and exit
… Uh, but that gives us that flexibility. Um
… to Marcus's question, and maybe also Manu's point, uh, I think the concern that was raised about the
… Prescribing the metadata as a return value is that some implementation may
… May not be used as a service by a caller, but the client may decide to implement this algorithm directly in the application logic
… And they may not need the metadata, therefore they may not even produce the metadata, and that would make them non-compliant. And I think it's a valid use case
… Uh, I think the current text makes a good job of explaining that the way those different outputs, the
… data and the metadata are returned, quote unquote, is up to the implementer, so
… For me, that means that the metadata could come as a raised exception, not necessarily as a written value, or maybe it is written somewhere else, and that's okay
… Uh, likewise, the data that is quote-unquote returned could be, like, just wrote in a mutable variable, and that would be… that would be compliant. The problem is, if I don't need the metadata, and I don't care about it, then
… I can hardly claim to be compliant, and that could be an issue. So maybe just explain that the metadata is an optional output, but if you need some metadata, it must comply with this description, and that's how it should be. Maybe that would solve the problem
Will Abramson: Yeah, I think I agree with what Jay just said. I mean, it does raise questions… I mean, I guess one of the questions as a result of this is, like, what now is this, like, did URL dereferencing result?...
… as an object that we have in our spec. I mean, currently, in this V factor, I haven't, sort of
… Talks about, like, the overall algorithms, inputs and outputs, yeah, like, that's not there. I've just broken down these, like, high-level stats
… Uh, maybe that's, like, dodging the more difficult bit. Um
… But, yes, because my understanding was, like, this metadata, while it does capture the errors, like, the primary
… sort of reason for having it being, like, flowing through the did URL dereferencing function signature is so
… The metadata from resolution can flow through to the caller of this function signature
… But if the core of this function is just the client, then they are
… gonna get the metadata from the resolve function, and then they can choose what to do with it
… we… I don't think we need to… to describe them
… I'm still happy to have it as, like, an optional thing, an optional output, if we want
… Um, I mean, since Marcus, you are here, like, I wondered if you could give us your sense of this refactor PR, you know
… Not talking about this did versus did URL question, I do want to have a chat on the agenda sometime in a call that you can definitely make, and we can just talk about it and make a decision
… But, like, independent of that, is this high… these high-level steps okay? I know in the past you said you didn't like retrieval strategy as a name
… Um, I don't know if you've had a chance to properly review the text or anything, but I'd love to hear your thoughts
Otto Mora: Mm-hmm...
… Go ahead, Marcus
Markus Sabadello: Yeah, I like… I like the concept of these retrieval strategies, you're right, I don't like the term very much, but I also...
… don't… I don't hate it either, I
… I like it as a… I like the concept as a way of making
… The dereferencing more modular and more extensible, right? Because there are so many
… different ideas what to do with the URLs. We have the existing parameters, like service and relative rev, we have the linked resources, we have the path service, and we have other things that. people are doing with these URLs, and I think
… Uh, in the current specification, there's this step-by-step if-then-else kind of
… Branching algorithm, and to replace that with
… With retrieval strategies that are somehow triggered, depending on
… what's in the Tit URL and what's in the Tit document. I think that's a… that's a good idea in general. I haven't
… Uh, I have not reviewed your pull request in detail yet
Will Abramson: Great, well, that's positive...
… Uh, what else is it worth talking about? Uh, right, yeah, there is one other thing that we could talk about from this PR that I kind of put at the end, but I don't have
… I haven't put in yet, but in… in 326, in Joe's PR, he defined some new terms
… uh… or proposed some new terms that we should add to the terminology. Like, I did URL client was one of them. Like, currently in the spec text that I wrote, I just used client
… But I think the URL client is a bit more clear, so that could be a term that we… we
… to the terminology section, and then don't also use base URL
… And base Dig URL is the digurl without the fragment
… Um… so
… I guess I'd like to hear if people think those terms are good, and if the names of those terms are what we want
… to use, and I've had some people not like some of them. So
Otto Mora: This is...
… No opinions. I figured yes. Marcus, yeah
Markus Sabadello: Um, having… having a term for the TTRL without the fragment is a really good idea, I think...
… I'm not sure if base TTRL is the right one, but why not? It's definitely useful to have a term. For this
… And, uh, yeah, regarding the client, that's… that's still a
… a difficult topic, I think, in the current specification
… I've always been using the term client in a way that's maybe not very intuitive, right? To me, the client has always been something that
… Invokes the resolution or dereferencing algorithms, and
… It doesn't imply any kind of network architecture or remote service or
… anything like that, so the way how I've been using the term is that if you have a local application that resolves a DID and dereferences a DID URL entirely. In a local process
… then… from a logical perspective, I also see a client and a resolver, but I know that's not very intuitive, so if there are better
… Better ideas on maybe using the term caller instead of client
… I don't know, but I think that's still a bigger question
Otto Mora: Mm-hmm. Thank you, Marcus...
… I don't see any strong reactions from anybody, no one on the queue
… Regarding those two terms
… Uh-huh
Manu Sporny: I've been quiet because I'm trying to track down what the base URL actually means. Um...
… Uh, there is a concrete definition for document-based URL
… in the HTML5 spec, in the URL definition
… I'm trying to see if it includes or does not include the fragment. Um
… I would suggest, like, whoever takes this on, like, it goes and makes absolutely sure that it does not include the fragment, otherwise we're going to be defining a base URL
… definition that deviates from base URL is used
… you know, in HTML, HTTP. Um
… There's a lot of complexity to determining a base URL for a document
Otto Mora: Mm-hmm...
… Oh, were you fetching a link there, Mattel, or shall we?
… Okay
Manu Sporny: It's, I mean, there, there are like 12 different links that you need to read up on to understand what the base URL is, so here's, here's one of them, and you can go backwards...
… from there… I think it's fine, I just, you know
Otto Mora: Mm-hmm...
<markus_sabadello> The current spec says: If present, separate the DID fragment from the input DID URL and continue with the adjusted input DID URL.
Manu Sporny: Whoever, you know...
… Not part of the query component. There, there isn't… so, so RFC3986 does not have a name for this thing
… Um, they have, you know, the authority section, the query section, but they don't have anything in the BNF that talks about
… The scheme authority and, um
… uh… a path and query together. Like, that's what we're talking about, right? Um
Joe Andrieu: That's not quite right, but I'm on the queue to talk about it...
Otto Mora: Go ahead, Josh...
Joe Andrieu: Um, there's a section in 4.3 that starts to talk about it. I think it's… it's almost the same...
… And I appreciate Manu's, um, rigor in trying to figure out, are we breaking it?
… Um, the base in an HTML file
… Um, is not what we're talking about, because you end up… you strip out the, um, the last part
… Um, to determine the base of a HTML, if you were getting that base from the URL
… Um, however, it does say, quite specifically in 4.3, section 4.3 in RFC 3986
… that defining a base URL for later use by relative reference calls
… is stripping off the fragment. Um
… Uh, I don't necessarily know if there's a better way to thread that needle
… Um, but that is why it made sense to me, because I had been reading through the fragment processing, and then the fragment processing, the base in the 3986 algorithm, is what you pass into
… The 39… into that, um, sub-algorithm, or whatever that's specified there
… Um, so I'm… I'd be happy if we can find a better term, but that was how I ended up with base did URL. Um, and I guess related, I was also just looking for did URL clients, um, something to distinguish amongst the different kinds of clients
… Because, uh, there's a dereferencer client and a resolver client in the current spec, as it's laid out, and I was trying to
… figure out how do I talk about the person who has a did URL, and they need to dereference it. That's the DID URL client, and I have no investment in that particular term, um, so I would be okay with other
… other terms, I don't… I don't think it's all that important, but when I was doing the threat modeling, it wasn't clear which of these is which
… Um, because we had multiple different service endpoints and possibly multiple different clients
Otto Mora: Thanks. Thank you. Madam?...
Manu Sporny: Yeah, good catch, Joe. I'm looking at 4.3 now...
… Uh, but it's a little confusing, because they do specify
… uh, BNF for an absolute URI which does not include a fragment. And then they talk about base URI. Which is confusing
… I'm trying to read it carefully, but it… it… so, there is a BNF, uh, for the thing we're talking about, and it's, I think, absolute URI
… Uh, in base URI, establishment might be a process that results in an absolute URI, which does not include a. fragment portion. Um… So, scheme, hierarchy
Joe Andrieu: So...
Manu Sporny: and query is what it includes. So section 4.3 is basically what we're looking at. So it's either absolute URI or base URI, I don't know which one it is just yet...
Joe Andrieu: Um, I'm… if I might interrupt, and in Section 3, there is...
… A, B, and F, that includes fragment. So… I'm
… what the section you're looking at right now is specifically saying, this is the base URI, which doesn't have a fragment
… Um, which is sort of what inspired me to use that term
Manu Sporny: Joe, you said Section 3, I'm looking at 4-3, I'm trying to look at section 3 now. Um… I gotcha...
Joe Andrieu: Yeah, syntax components, it just breaks down where the fragment is...
Manu Sporny: Um...
Joe Andrieu: Two more up here at 3, 2, 3. It's literally just at the top of 3...
Otto Mora: This part, or further up?...
Joe Andrieu: No, 3. Like, you're at 323, go all the way up to 3 dot...
Otto Mora: Oh, just, just 3, 3… okay, 3...
… Authorities camp
Joe Andrieu: There you go...
Otto Mora: Intex, okay. Yeah, here we go. Mm...
Manu Sporny: Yeah, so noted on that, Joe, but that's a definition for URI. It is not a definition for absolute URI. If you go to the definition for absolute URI...
… I think it has the thing we want. So, section 4.3
… So this thing that we're looking at right now, it requires fragment to be in there. It's possible for it to be in there, but for absolute URI in section 4.3 auto, so you gotta go down to section 4.3. It, it is specific about
… um, the absolute URI syntax, which does not include a fragment right here. So this is the thing I was looking at, Joe, where I was like, I don't know, it talks about base URI, and then it's like, here's the definition for absolute URI. I'm kind of like, okay, what… you know
Joe Andrieu: if I might, um, I think they're talking about a specific instance that they have in that first sentence there in 4-3. That some protocols...
… Only allow an absolute form without a fragment identifier
… And so they're talking about some scheme specifications to find their own syntax
… So I think this is specifically saying sometimes the scheme of the URL does weird things. I think that's what that section is saying
Manu Sporny: Yeah, I...
Joe Andrieu: And they're talking about when it doesn't have a fragment, or fragments don't apply...
Manu Sporny: Right, which is that… that… there… like, the BNF, I'm just looking at the BNF, the BNF definition for absolute URI is exactly that thing we're looking at. It's not defined as anything else anywhere in the specification, is what I'm saying. Like, if we wanted to be specific, and this is, like...
… Super pedantic, but, like, if we wanted to be very specific about what we mean
… we would say the, you know, A, B, and F syntax for absolute URI is the thing that, you know, doesn't have the fragment in there. I'm searching the document to see
… Base URI must conform to the absolute URI syntax rule
… Absolute URI… yeah, I mean, there… if you look in Appendix A, the Absolute URI syntax does not have a fragment
Joe Andrieu: I see...
… So… so this is maybe a better name, even though it feels really confusing
Manu Sporny: That's correct. It's… I think it's the technically accurate name, and if we use base URI, BaseURI pulls in a whole bunch of other logic that I'm concerned might. Confuse people that are, like...
… closely reading the HTML5 spec, or whatever
Otto Mora: Okay, so absolute URI it is...
… Uh, yep, here
Pierre-Antoine Champin: I'm very conscious that we are at the top of the hour, but, uh...
… Absolute URI is confusing. Many people think of Absolute URI as a
… That's a different thing. Um
… I think the problem comes from the fact that Bayes URI is a
… is a role. It's not… it's not the kind of URI, it's the role that a URI plays in the
… Uh, URI resolution and, uh, process
… I might suggest a primary URI, which resonates with the fact that it's the URI of the primary resource, rather than the secondary resource identified by the fragment
… It's not used anywhere else, so maybe less confusing, and again, absolute
<KevinDean> -1 to primary URI. Base URI is analogous to base URL, which is well understood.
Pierre-Antoine Champin: Usually, usually sends people in the wrong direction, in my experience
Otto Mora: Okay, well, I don't know, I guess we can follow it up, but I guess, uh, for, yeah, for tomorrow, let's try to...
… have some, uh, just reactions to the… to the PR, hopefully trying to
… Have final decisions on whether we can merge it as it is, or we adjust it a bit
… Uh, with the generic algorithm. Yep
Will Abramson: Cool, thanks...
Joe Andrieu: Uh, could I add one last thing? Um...
Otto Mora: Mm-hmm...
Joe Andrieu: Which is just the, uh… it may be useful to align base URI...
… Um, uh, with whatever path service is going to use for the base for calculating
… Um… so that's just another wrinkle, like
… Because that has a base, and so that may be a reason just not to use base
… Um, so just… one more thing to consider
Otto Mora: Mm-hmm...
… Okay. Sounds good
… Thank you. Appreciate it
<ottomorac> transcriber-bot, pause