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

On Mon, 24 Aug 2020 at 16:52, Ivan Herman <ivan@w3.org> wrote:

> Thanks Leonard,
>
> scanning through RFC7320 I can understand where the IETF problem is: what
> the hashlink proposal does is to define a universal query parameter (and
> accompanying semantics) which seems to be a no-no (for example because it
> may clash with existing deployments/URLs using, accidentally, the same
> query). I am not sure how to get out from this issue, to be honest.
>
> Sigh…
>

Well, the parameter-based solution is a non-recommended fallback, so as I
understand, it is not core to the Hashlink RFC.

Do RFC have the equivalent of non-normative sections? Would turning that
feature to "non-normative" make it more acceptable?

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

  pa


>
> Ivan
>
> On 24 Aug 2020, at 15:48, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> Sorry – Ivan – good catch.
>
> I meant query parameter (?hl).   (was thinking about another URL extension
> that I am working with that uses fragments)
>
> It has been pointed out to me that RFC7320 (BCP 190) prohibits the use of
> a specific query parameter for this purpose (there is even an example of
> using a `sig` query parameter).  Additionally, there seems to be a huge
> amount of animosity towards creating new schemes (eg. `hl`) as well.
>
> As I am currently using hashlink in a standard I am building (
> https://contentauthenticity.org/) – I have a **HUGE** amount of interest
> in getting this resolved (or coming up with a new solution that will fly)
>
> Leonard
>
> *From: *Ivan Herman <ivan@w3.org>
> *Date: *Sunday, August 23, 2020 at 11:47 AM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Gregg Kellogg <gregg@greggkellogg.net>, Manu Sporny <
> msporny@digitalbazaar.com>, W3C JSON-LD Working Group <
> public-json-ld-wg@w3.org>
> *Subject: *Re: The new charter is now in place
>
>
>
>
> On 23 Aug 2020, at 12:59, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> And all of which also depends on Manu and I figuring out how to get
> hashlinks through the standards process.   There are definitely going to be
> problems at the IETF, as there are those who feel strongly that the current
> proposal isn't compatible with the underlying URL specification and how
> fragments are supposed to work.
>
>
> Can you explain this? The IETF proposal[1] doesn't seem to use fragment
> ids...
>
> [1] https://tools.ietf.org/html/draft-sporny-hashlink-05
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-sporny-hashlink-05&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341190117&sdata=YvN0O8l3xr9JDEEDzjT40rct6QdvtxiCI014AAIp6lA%3D&reserved=0>
>
>
> I wonder if we could do it via W3C - but are we going to cause more of a
> rift between the two by doing so...(we know how they felt about the HTML
> folks taking over the URL spec....)
>
>
> Yep, I think getting this through W3C would have very little chance. This
> is IETF land…
>
> Ivan
>
>
>
> Leonard
>
> On 8/21/20, 4:52 PM, "Gregg Kellogg" <gregg@greggkellogg.net> wrote:
>
>
> On Aug 21, 2020, at 8:35 AM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> On 8/20/20 4:58 PM, Gregg Kellogg wrote:
>
> Perhaps we can describe mechanism for creating
> versioned/cached/optimized contexts, with a default managed by the
> group, along with a way to validate and update context versions. It
> should allow others to create their own context set, and how to achieve
> and measure the resulting compaction.
>
>
> This mechanism exists in the current CBOR-LD implementation:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fcborld%2Fblob%2Fmain%2Flib%2Fcodecs%2FContextCodec.js%23L9-L11&amp;data=02%7C01%7Clrosenth%40adobe.com%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759466031&amp;sdata=5CgueW292h%2BtoqZqD9Nr0TeGgMSYpLzACeHKn1pNo5k%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fcborld%2Fblob%2Fmain%2Flib%2Fcodecs%2FContextCodec.js%23L9-L11&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341190117&sdata=g5kwMZjD%2FheV2a0Dv8EcAHQVI9C9wKrNijkOlKzqKwA%3D&reserved=0>
>
> The way it works today is that JSON-LD Contexts that are guaranteed to
> not change (for some externally known reason, such as they're a part of
> a W3C specification that locks the contexts in at particular releases
> with a SHA-256 hash, for example). There can be 32,768 of these sorts of
> contexts that are managed by the specification registry for "contexts
> that won't change and are thus safe to use with CBOR-LD".
>
>
>    I’m not sure what contexts would be guaranteed not to change. Several
> have been changed, where those changes are deemed to have not invalidated
> anything that was there before (e.g., prefix definitions).
>
>    Previously, these issues were stalled because of the lack of a good
> mechanism to guarantee the context integrity. Hashlink seemed like the best
> solution to me, so maybe if such a spec were limited to contexts served up
> via hashlink, or similar.
>
>    Some specs have decided to create versioned contexts to guarantee that
> a given version remains unchanged, but this is often (usually?) not the
> case.
>
>
> There is also another namespace consisting of 32,768 entries that are
> application-defined. If an organization doesn't want to register their
> frozen context globally, then they can just publish an
> application-specific specification that specifies values from
> 32,769-65,535. There can be 32,768 of these sorts of contexts for
> "application-specified contexts that won't change and are thus safe to
> use with CBOR-LD".
>
>
>    Sounds like another managed registry of immutable data, which might be
> reasonable, but groups would need an incentive to  use this as well as to
> mandate the use of specific versioned context URIs.
>
>
> What we don't do today for CBOR-LD is throw an error if one of these
> types of contexts are NOT used. We can put that into the
> specification... but remember, we don't throw in this case for JSON-LD
> today either... so it would be a strange requirement to put on CBOR-LD
> since we don't do that today for JSON-LD.
>
> Contexts can change... that's been known for a very long time with
> JSON-LD, and there are a variety of mitigations against that that are
> deployed today (ship with frozen contexts and only use those, use
> hashlinks or some other form of content-addressed identifier, use known
> frozen URLs, etc.)
>
>
>    Yes, as I suggested above. It seems like a W3C-wide mandate, though,
> which is a high barrier to achieve.
>
>    Gregg
>
>
> -- 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%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759476024&amp;sdata=AdwslSAoI0PNK6TEJr4Hw4G6w1WAsynh8DzlzKbV9TE%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341200113&sdata=WamhtZH8DQR%2BQdHVhNg0Rli1xujwgyYP0JH642WN9NE%3D&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%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759476024&amp;sdata=dXzhb1HIbT4CVzu%2B2UHxbSFh1%2F1gBzFJZhL%2F0ealmZA%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341200113&sdata=siItCzd97s7LFgUsbvY47LuZ1VF6P1T5PiVWf0rQAsc%3D&reserved=0>
>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341210105&sdata=EsX%2B8svLAOurumwZh%2B%2BDXBq8WGLCULMQ8TbNIP2flws%3D&reserved=0>
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341210105&sdata=iS7%2F0GUl9Oq%2BubfprEA5bLmNFE7ceGz%2Bg8Gz5d2yOmA%3D&reserved=0>
>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704
>
>