-
Notifications
You must be signed in to change notification settings - Fork 17
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
User component of a URL #69
Comments
Plain text user and password are not supported. It is very unlikely that support will materialize. |
If that's the intention, be clear about it in the doc. (I agree on the password part, but the user part could be convenient for some authenticated use cases.) |
@jernst - I agree, the spec should state explicitly that user component of the URL is not supported. If you have a moment, a PR would be welcome! :) |
I could do that, but I've been thinking ... and have come to disagree. The value of this spec diminishes very rapidly the more restrictions are being made on which URLs are supported. Instead I believe that the spec should support every possible URL, regardless if how strange or unlikely or misguided. |
Is that true? How do you know / why do you think so? It may be important to especially consider the cases you provide in the next sentence:
What value is lost if a "misguided URL" is not supported? What about a "strange URL" or "unlikely URL"? Is the value of the spec "diminished very rapidly" in any these cases -- if so, how and why do you think so? |
The value that's lost is that I have to think, and write special-purpose code, and potentially workarounds, instead of having a 100% complete mapping. I know because I tried to use the spec for something I'm developing and that has turned out to be a bad idea for these reasons. P.S. It occurs to me now that perhaps this spec should not exist, and instead a spec should exist that explains how to discover a DID document from any valid http or https URL. Not clear what value is created by mapping (a subset! of) the https URL namespace into something that starts with |
Consider
https://foo:[email protected]
. How is that supposed to be mapped?If the user component is not permitted, document that explicitly. Alternatively make an example that shows how this is mapped.
The text was updated successfully, but these errors were encountered: