Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify that DID URL dereferencing returns the final resource. #544

Merged
merged 2 commits into from
Jan 24, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -4021,11 +4021,14 @@ <h2>
DID URL Dereferencing
</h2>
<p>
The DID URL dereferencing function dereferences a <a>DID URL</a> into
The <a>DID URL dereferencing</a> function dereferences a <a>DID URL</a> into
a resource with contents depending on the <a>DID URL</a>'s components,
including the <a>DID method</a>, method-specific identifier, path, query,
and fragment. This process depends on <a>DID resolution</a> of the <a>DID</a>
contained in the <a>DID URL</a>.
contained in the <a>DID URL</a>. <a>DID URL dereferencing</a> might involve
multiple steps (e.g., when the DID URL being dereferenced includes a fragment),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any other dereferencing libraries in existence that do this? This might confuse people that are used to their resolution libraries not doing this part of the process for them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nobody is saying that the entire dereferencing process has to be implemented in a single library. As we know, in the case of HTTP URLs, the dereferencing processes involves both server and client components. In the case of DID URLs, those details depend on the method and concrete dereferencer implementation. This PR just clarifies that dereferencing returns the final resource after all the steps (including potential "client"-side fragment dereferencing) are completed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, perhaps we could use a less misleading example then... like: "e.g., when the DID URL being dereferenced requires the resolution process to query a Decentralized Ledger."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Waiting on @peacekeeper to respond to see if he's ok w/ this change before merging.

Copy link
Contributor Author

@peacekeeper peacekeeper Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny the intent of this PR was to address #399, which specifically asked the question whether fragment processing is part of resolving/dereferencing or not. Maybe @iherman could comment if this PR is helpful, or if we can do something else to address his original issue.

and the function is defined to return the final resource after all
steps are completed.
The details of how this process is accomplished are outside the scope of this
specification, but all conformant implementations implement a function
which has the following abstract form:
Expand Down