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

And the query syntax is the one that I need for my use case - so definitely not getting rid of it.

But even the `hl` scheme, as I noted, is also problematic with folks at the IETF who are not inclined to add any new schemes as it would "open the floodgates".   

I am trying to figure out if/when the next (virtual) meetings are and if there is a way to attend and at least pitch our needs...Manu, do you know??

Leonard

On 8/25/20, 10:33 AM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

    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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7C51bdeafaed7b4d1e51c208d84903dddb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637339628242853883&amp;sdata=DCS8AbNx5qltswELwukgrLIwtNVkeAlIHyPf8YfEPoA%3D&amp;reserved=0

    Founder/CEO - Digital Bazaar, Inc.
    blog: Veres One Decentralized Identifier Blockchain Launches
    https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Clrosenth%40adobe.com%7C51bdeafaed7b4d1e51c208d84903dddb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637339628242853883&amp;sdata=e0ufwgcPzOX2mAQpwBvMBRyoCGLVGpLYSIOdx10ITpw%3D&amp;reserved=0

Received on Tuesday, 25 August 2020 17:57:43 UTC