Re: Hashlinks (was Re: The new charter is now in place)

On 8/25/20 9:21 AM, Pierre-Antoine Champin wrote:
> Well, the parameter-based solution is a non-recommended fallback, so as
> I understand, it is not core to the Hashlink RFC.

Yes, this is exactly correct... it's an application layer thing that
applications can choose to do (this is stated in the spec). It's in the
spec because there were a number of applications that wanted to do this
and so we provide guidance in those cases.

> Do RFC have the equivalent of non-normative sections? 

Yes, they do...

> Would turning that
> feature to "non-normative" make it more acceptable?

It's already non-normative... I'll quote the text from the I-D:

1.1.  Multiple Encodings

A hashlink can be encoded in two different ways, the RECOMMENDED way to
express a hashlink is:

   hl:<resource-hash>:<optional-metadata>

To enable existing applications utilizing historical URL schemes to
provide content integrity protection, hashlinks may also be encoded
using URL parameters:

   <url>?hl=<resource-hash>

Implementers should take note that the URL parameter-based encoding
mechanism is application specific and SHOULD NOT be used unless the URL
resolver for the application cannot be upgraded to support the
RECOMMENDED encoding.

> If not, could it be simply moved from the RFC to something more informal?

I'd rather not move it from the document... application developers have
found it useful... and it was a recurring question until I added that
section into the spec.

I'm suggesting that this concern is turning a mole hill into a
mountain... there is no issue from a URI perspective. It is
non-normative application layer guidance, nothing more.

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

Received on Tuesday, 25 August 2020 14:33:56 UTC