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