Re: Hashlink parameterized URL

yes, that totally makes sense, but, isn't the expectation of this caller
behavior quite unique as far as URLs go?

It's easier for me thinking about hashlinks as an abstraction for
immutable, content-addressable storage, where the response with simply be:
you get the data or you don't.

This opens up many implementation questions.

On Wed, Apr 22, 2020 at 4:14 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

>
> 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
> >
>
>