Re: Hashlink parameterized URL

no disagreement there; my response to Alex demonstrates what I'm really
interested in.

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

>
> On 23/04/2020 11:24, Kim Hamilton wrote:
> > 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.
>
> But that is not the model that the majority of web servers use, and if
> even if they did, the untrustworthy ones would not.
>
> So you cannot place any expectations on an untrustworthy web server.
>
> >
> > This opens up many implementation questions.
> >
> > On Wed, Apr 22, 2020 at 4:14 PM David Chadwick
> > <D.W.Chadwick@kent.ac.uk <mailto: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>
> >     > <mailto: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
> >     >
> >
>