Re: Hashlink parameterized URL

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?




On Wed, Apr 22, 2020 at 7:42 AM Manu Sporny <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
>
>