When I read this I thought 'of course'.
And then a few minutes later, 'standards are created through use, if people are using it, better it be documented.'.
We seem to have a commitment problem with our work. RFC stands for 'Request For Comments'. The Drafts series was created because people were taking the requests for comments as standards instead of commenting on them.
One of my most widely used pieces of work is the W3C Log File format which I put together in a couple of hours to support another project, got some comments on it from Brian Belhendorf and published it as an Internet Draft. It only became a W3C note because the servers implemented it and the draft had expired.
There are many pieces of similarly situated work. When IETF decides not to form a working group, it is not deciding the work isn't going to be done, it is deciding it isn't going to be done in IETF process. And that is sometimes the right choice. By the time folk came along and said we should do a working group to fix problems with the log file format, it was too late because the existing spec was good enough.
The problem comes with things like Markdown where there was a specification but it wasn't very easy to find and so many, many different variants have grown up. If there had been a draft, we might have had less unnecessary divergence. And if people had extended the spec because they needed to, we might have started from a solid foundation.
So my focus is on getting things nailed down and published. Any documentation is better than none.
Now if folk want an alternative to IDs, well they could use the ni: URI scheme (RFC6920). But naming things with hashes means ending up with a hash.
I am not the only person suggesting creating a new registry at this point. If I can get someone to deploy enough of my Callsign registry tech, I can build what I really want which is a mechanism that allows me to publish a 'friendly name' handle for a document named by a hash. So if Alice has the callsign @aliceexample, she can publish documents under her handle with a unique resolution:
dh:aliceexample.0:my_document.0
This can be resolved in two different ways. If Alice's account is being serviced by a Mesh Service provider offering handle resolution, the callsign lookaside DNS points to a web service that provides resolution and all a resolver needs to do is map the URI onto the https equivalent:
Otherwise, the resolver will have to go to Alice's public published documents Merkle log, find the first entry for 'my_document', validate the signature on it, extract the hash and see if anyone has archived content matching that hash.
This scheme isn't perfect but the identifiers are reasonably pleasant (more so than DOIs) and the process of publication creates a public declaration, 'this is something that I think worth keeping'. which distinguishes it from the mass of Web content not worth keeping.
And if you really want, you could even do the thing I do with EARLs and stick a decryption key on the end of the identifier, now it becomes a bearer token. Anyone can find the ciphertext but you need the handle to read it.
dh:aliceexample.0:my__encrypted_document.0:EBVO-EJPF-3N7D-RI4K-5EQG-XC2X-JA
Now having given an outline of a scheme that solves what has been considered a 'white whale' problem in the field before first cup of coffee, what is better, that I leave the proposal here in a mailing list where some people will remember it but have to spend time looking or publishing it in a note where stuff is published that wants to be found?
On Mon, Dec 9, 2024 at 10:21 AM Eliot Lear <lear@xxxxxxx> wrote:
What I care about is this:
The IETF community (and those generating IRTF and independent submissions) need a way to signal to the community that draft means just that: it's draft work, and not intended for broad deployment. Otherwise, we end up with all of the support issues I mentioned earlier.
Eliot
