W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: Hashlink parameterized URL

From: alex thompson <pierogitus@hotmail.com>
Date: Wed, 22 Apr 2020 23:45:18 +0000
To: Kim Hamilton <kimdhamilton@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>
CC: "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <BY5PR20MB289846F1B41649C99A8DF30DD2D20@BY5PR20MB2898.namprd20.prod.outlook.com>
> 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.

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

Received on Wednesday, 22 April 2020 23:45:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC