Thanks for the ping, @wip-abramson. I wasn't around for the theoretical debates that led to the definition in RFC 3986, so I could be misunderstanding what an "access mechanism and the appropriate parameters" are meant to be. (Reading the RFC, my impression is that the authors didn't have a clear understanding themselves.) With my current understanding, I see resolution defined here as

resolve(did, resolutionOptions) →
« didResolutionMetadata, didDocument, didDocumentMetadata »

If this is determining the "access mechanism and appropriate parameters", I would expect to find those in the results. didResolutionMetadata has error information, a content type, and a proof, which doesn't seem like an access mechanism or parameters. The didDocument is one of the possible result types of deferencing, so it seems like more than just the access mechanism or parameters. And the didDocumentMetadata includes fields that describe the document, but things like 'created' don't seem necessary to dereference a URI.

Perhaps more generally, the only output of the DID Resolution algorithm that I see being used as part of DID Dereferencing is the document itself, which for simple DID URLs is passed directly through to the output.

If you do think you're matching an interpretation of the RFC3986 definition that I haven't considered, it would be nice for this note to explain that interpretation and how this use matches it, rather than just asserting that they're consistent.

I haven't checked this with the rest of the TAG, but one possible direction might be to declare that the RFC 3986 definition of resolution simply isn't useful: that determining an access mechanism is hopelessly intertwined with dereferencing the full URL, for basically all schemes. Then, if you feel it's important to have a distinct name for the process of finding the relevant DID Document for a given DID URL, you could use "resolution" as your own term. You could even mark it as a "willful violation" of RFC 3986, to be clear that nobody should bother making my comment in the future.

I don't feel like it's important to have this distinct name. I think it would be clearer to name an algorithm "retrieve the DID Document for a DID URL", and that it's not likely to come up enough in other specs to need a short term for it. But if the WG considers the question and thinks I'm wrong about this, I'm comfortable yielding to your expertise.

One possible way to apply RFC 3986 here:

In order to be able to reference a DID URL, one first needs a DID Document. Therefore, the potential "access mechanisms and appropriate parameters" for a DID URL is at least a DID Document.

The DID document (and in some sense, its content type, which tells you that it's a DID document) provides the parameters necessary to dereference the path of the DID URL (and any hash fragment, etc.) to its referent.

There may also be additional parameters for dereferencing that are included in the metadata about the DID document / DID URL. This might include specific time information the dereferencer will care about and even perhaps the parsed DID method -- which would allow late method-specific behaviors to be performed, but I agree with other's statements that much or all of this is generally an anti-pattern that leads to interop failure. We should try to push most or all of this into the resolution layer, not the dereferencing layer; the application / client (that will do the dereferencing) should not be concerned with it.

The didDocument is one of the possible result types of deferencing, so it seems like more than just the access mechanism or parameters.

Yes, but the didDocument is the ONLY possible result type of resolving. It contains information which is used during the dereferencing process. I agree with @dlongley that "In order to be able to de(?)reference a DID URL, one first needs a DID Document. "

If we add 1-2 sentences to explain this in this PR, maybe that would solve the issue?

@jyasskin wrote:

I don't feel like it's important to have this distinct name. I think it would be clearer to name an algorithm "retrieve the DID Document for a DID URL", and that it's not likely to come up enough in other specs to need a short term for it.

FWIW, strongly agree with the statement above and @dlongley's take as well.

We can't just assert that DID resolution is aligned, because as @jyasskin said, RFC 3986 is fairly vague in its "access mechanism and the appropriate parameters" language.

To be clear, I'm fine w/ this PR, but it doesn't feel like it clears up the core issue that @jyasskin noted in the TAG review.