Re: Hashlink parameterized URL

On 23/04/2020 10:57, Kim Hamilton wrote:
> This has caused a series of questions, but then I realized the 
> behavior around hashlink requests/responses may be out of scope of the 
> spec (I don't see this on a scan).
>
> Nevertheless, here are some naive questions I'm curious for your 
> reaction to.
> - What is the expected behavior from the server if the hashlink 
> doesn't match? Is it valid for a server to have indexed past versions 
> by their content integrity hash, and serve that up? Or is a mismatch a 
> failure
> - Could we envision a hashlink as something that's up to the caller to 
> parse and handle? I.e. caller extracts url (doesn't send hl) and then 
> confirms content received matches?
The caller must be the entity that performs the hash and confirms the 
content. Otherwise an untrustworthy server can serve any old content and 
says that it matches the hash. Not good!
>
>
>
>
> On Wed, Apr 22, 2020 at 7:42 AM Manu Sporny <msporny@digitalbazaar.com 
> <mailto:msporny@digitalbazaar.com>> wrote:
>
>     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 23:12:41 UTC