- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 22 Apr 2020 10:40:29 -0400
- To: alex thompson <pierogitus@hotmail.com>, "public-credentials@w3.org" <public-credentials@w3.org>
On 4/22/20 1:19 AM, alex thompson wrote: > Regarding parameterized URLs > https://tools.ietf.org/html/draft-sporny-hashlink-04#section-3.2 > > Can we generalize that for URL segments instead of just query string > similar to https://tools.ietf.org/html/rfc6920#section-5 > > Examples: ./hl;zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e > ./hw.txt#hl;zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e > > I think there are clear use cases for having it in the path (avoiding > conflicts with windows filesystems not allowing "?") and fragment > (doing client side only validation) Hmm... that's an interesting thought. The Parameterized URL stuff was meant to be a hack to enable the use of hashlinks in legacy URL formats. Allowing them to be embedded in paths and fragments seems like even more of a hack, so the question really is... are we ok with hashlinks being hacked into all these awkward places? I don't have a strong opinion one way or the other, so am happy to add an experimental section stating something to the effect of "Hey, if you want to embed a hashlink in a path or a fragment identifier, here's one way you can do it, and this is experimental and we're looking for feedback on whether or not this is useful to you. Is this the only way you can achieve your use case?". ... and then we wait for feedback. If we get no feedback or negative feedback, we take it out of the spec. If we get positive feedback, we keep it in. Would that work for you, Alex? -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Wednesday, 22 April 2020 14:40:43 UTC