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

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…


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/ <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 <mailto:ivan@w3.org>>
> Date: Sunday, August 23, 2020 at 11:47 AM
> To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
> Cc: Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>>, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org <mailto: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 <mailto: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 <mailto:gregg@greggkellogg.net>> wrote:
>> 
>> 
>>> On Aug 21, 2020, at 8:35 AM, Manu Sporny <msporny@digitalbazaar.com <mailto: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