Re: Hashlink parameterized URL

Also found this other draft that overlaps with hashlink
https://tools.ietf.org/html/draft-hallambaker-mesh-udf-09

The interesting thing for this discussion is in section 1.3 they use double dash "--" for the delimiter so it would work in DNS as well as path, query, fragment and hl-- might have less chance of collision with unrelated things in the URL.

________________________________
From: Kim Hamilton <kimdhamilton@gmail.com>
Sent: Wednesday, April 22, 2020 5:00 PM
To: alex thompson <pierogitus@hotmail.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Hashlink parameterized URL

> I think the approach taken in RFC6920 is more appropriate. Basically a disclaimer that acknowledges the ambiguity but still gives solid guidance that covers all the scenarios. Also since hashlink kind of supersedes RFC6920 I think it makes sense to have parity in this area.

looking into RFC6920; I see what you are saying. implementation options/purpose are clearer to me.

On Wed, Apr 22, 2020 at 4:50 PM Kim Hamilton <kimdhamilton@gmail.com<mailto:kimdhamilton@gmail.com>> wrote:
what's interesting is that this introduces some tooling on the caller side I hadn't thought about til now. This is presented as a query parameter, yet callers are simply stripping this off before sending* and checking the response hash.

*for a range of concerns: we don't trust the response, and also what if "hl" collides with an existing parameter or fails because it doesn't recognize.

It's weird that we express it as a query parameter and then not use it that way. Not complaining, just surprised.

On Wed, Apr 22, 2020 at 4:45 PM alex thompson <pierogitus@hotmail.com<mailto:pierogitus@hotmail.com>> wrote:
Manu,
> 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?".

I think the approach taken in RFC6920 is more appropriate. Basically a disclaimer that acknowledges the ambiguity but still gives solid guidance that covers all the scenarios. Also since hashlink kind of supersedes RFC6920 I think it makes sense to have parity in this area.

Kim,
> - 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?

Yes that's the use case for fragment so you can add an integrity value to a URL you don't control even if you can't support the hl: scheme