[dispatch] Re: Request for DISPATCH consideration: draft-linkgenetic-linkid-uri

[Eric Rescorla <[e-mail]>]

On Sat, Oct 24, 2026 at 9:14 AM Christian Nyffenegger <
[e-mail]> wrote:

> Dear Eric, dear John,
>
>
>
> The central issue behind LinkID is the distinction between a resource’s
> identity and its current location.
>
>
>
> A published reference can remain in documents, bookmarks, citations, and
> software long after its destination has moved. When that reference contains
> the destination address directly, a change at the destination can break
> references distributed across systems that the resource owner cannot update.
>

Yes, I'm aware of this point. However, it's not clear to me how big a
problem this really is, as opposed to resources simply disappearing. I'm
aware it's an issue in certain contexts, hence DOIs, etc., but that's not
the same as it being a general problem.




> Eric, your concerns about mapping authority, integrity, and resolver
> discovery address how that model must be specified securely and operated at
> scale. The draft needs explicit mechanisms for those requirements. They are
> distinct from the practical value of keeping a published reference stable
> while its destination changes.
>

I think they are relevant to the question of whether we should work on
this. As noted in both my message and yours, there are existing systems
that address this problem (e.g., DOI) and do so seamlessly from the
user's perspective,
without any new standards, so what's the need for a new standard?

One might argue that systems like DOI have technical deficiencies which we
could address, potentially by modifying the client. However, before undertaking
this work, we would need some evidence that (1) these issues were
practically soluble and (2) there was a critical mass of implementations that
would be interested in adopting such a standard. Do you have more to offer
for either point?

-Ekr


>
>
> That is the distinction we want the discussion to address: a persistent
> reference whose destination can be maintained without changing the
> reference already in use.
>
>
>
> Best regards,
>
> Christian
>
>
>
> Link Genetic — Permanent Digital Identity for Links Built to Endure
> <https://linkgenetic.com/>
>
> Link Genetic - YouTube <https://www.youtube.com/@LinkGenetic>
>
>
>
> -----Original Message-----
>
> From: John C Klensin <[e-mail]>
>
> Sent: Sonntag, 18. Oktober 2026 03:57
>
> To: Eric Rescorla <[e-mail]>; Christian Nyffenegger <
> [e-mail]>
>
> Cc: [e-mail]; [e-mail]
>
> Subject: Re: [dispatch] Re: Request for DISPATCH consideration:
> draft-linkgenetic-linkid-uri
>
>
>
> Just to add one comment to Ekr's list, with which I largely agree. The
> function of a URI containing an ID which then is processed to yield a
> specific resource object, or an instance of one, is what URNs (or at least
> most URNs) are about.  So, in addition to the other concerns, the obvious
> question is what value this would bring that a URN for the specific type of
> UUID or link object would not.
>
>
>
>    john
>
>
>
>
>
> --On Saturday, 17 October, 2026 12:45 -0700 Eric Rescorla <
> [e-mail]> wrote:
>
>
>
> > Review of draft-linkgenetic-linkid-uri-01.txt
>
> >
>
> > TL;DR. I don't think this is a good idea and the IETF should not adopt
>
> > this work.
>
> >
>
> > This document introduces the idea of a link-id URL, which is is URL
>
> > that carries a UUID. A client dereferences it by contacting a resolver
>
> > which maps it to an actual resource.
>
> >
>
> > I have a number of concerns with this document. First, it's poorly
>
> > motivated. Something kind of like this already exists in the form of
>
> > DOIs and it's not clear why this is materially better.
>
> >
>
> > Second, there are obvious problems with this idea at scale, as each
>
> > resolver has to effectively be able to resolve every single LinkID
>
> > URL. The Internet as a whole contains a huge number of URLs, and
>
> > having a single resolver host them all is obviously problematic; even
>
> > having it handle all the registrations seems tricky.
>
> >
>
> > Third, as designed, this system seesm to have a number of security
>
> > problems, including:
>
> >
>
> > * No cryptographic protection for the UUID -> URL mapping
>
> >   which requires trusting the resolver.
>
> >
>
> > * No mechanism for preventing A from registering B's UUID
>
> >   URL or verifying that an entity which updates the URL
>
> >   is the same.
>
> >
>
> > Appendix B is only a partial list of the problems here; it's
>
> > potentially possible to solve all these, but without a much stronger
>
> > motivation, I doubt it's worth trying.
>
> >
>
> > -Ekr
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > On Mon, Sep 28, 2026 at 8:01 AM Christian Nyffenegger
>
> > <Christian.Nyffenegger=[e-mail]> wrote:
>
> >
>
> >> Dear DISPATCH Chairs,
>
> >>
>
> >> I would like to request DISPATCH consideration and guidance regarding
>
> >> my Internet-Draft:
>
> >>
>
> >> *The LinkID URI Scheme and Resolution Model*
>
> >> draft-linkgenetic-linkid-uri-00
>
> >> https://datatracker.ietf.org/doc/draft-linkgenetic-linkid-uri/
>
> >>
>
> >> The document specifies the linkid: URI scheme and a resolution model
>
> >> for persistent, location-independent identifiers. The objective is to
>
> >> provide a stable identifier for a resource that remains independent
>
> >> of changes to its current network location and can be resolved to a
>
> >> current actionable URI.
>
> >>
>
> >> The linkid URI scheme is already provisionally registered with IANA.
>
> >>
>
> >> iana.org/assignments/uri-schemes/prov/linkid
>
> >> <https://www.iana.org/assignments/uri-schemes/prov/linkid>
>
> >>
>
> >> Following guidance from Ted Hardie on the URI Review mailing list, I
>
> >> am contacting DISPATCH to seek community guidance on the appropriate
>
> >> IETF path for progressing this work.
>
> >>
>
> >> My objective is to mature the specification through the appropriate
>
> >> standards process and, ultimately, to support permanent registration
>
> >> of the linkid URI scheme. I am open to the path that the IETF
>
> >> community considers most appropriate for this work.
>
> >>
>
> >> I would therefore appreciate the opportunity to discuss the proposal
>
> >> with DISPATCH and, if appropriate, present the draft at an upcoming
>
> >> DISPATCH meeting.
>
> >>
>
> >> I am also happy to revise the Internet-Draft based on community
>
> >> feedback. In particular, I will address the interoperability
>
> >> considerations raised during URI review regarding existing uses of
>
> >> the term "LinkId" within URI constructions.
>
> >>
>
> >> Please let me know what you recommend as the next step and whether
>
> >> you would like any additional material from me in advance.
>
> >>
>
> >> Best regards,
>
> >>
>
> >> Christian Nyffenegger
>
> >> Founder & CEO
>
> >>
>
> >> ---
>
> >>
>
> >>
>
> >>
>
> >> Link Genetic GmbH (CH)
>
> >>
>
> >> Christian Nyffenegger
>
> >>
>
> >> Leugrueb 21
> <https://www.google.com/maps/search/Leugrueb+21?entry=gmail&source=g>
>
> >> <https://www.google.com/maps/search/Leugrueb+21+%0D%0A+%0D%0A
>
> >> +8126+Zumikon+%0D%0A+%0D%0A+Switzerland?entry=gmail&source=g>
>
> >>
>
> >> 8126 Zumikon
>
> >> <https://www.google.com/maps/search/Leugrueb+21+%0D%0A+%0D%0A
>
> >> +8126+Zumikon+%0D%0A+%0D%0A+Switzerland?entry=gmail&source=g>
>
> >>
>
> >> Switzerland
>
> >>
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >> Company Phone CH: [phone] <+41%2058%20717%2070%2000>
> <+41%2058%20717%2070%2000>
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >> Link Genetic Inc.(US)
>
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> >> 26 Broadway
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> >> Suite 934
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> >> New York, NY 10004
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> >> USA
> <https://www.google.com/maps/search/26+Broadway+%0D%0A+%0D%0A+Suite+934+%0D%0A+%0D%0A+New+York,+NY+10004+%0D%0A+%0D%0A+USA?entry=gmail&source=g>
>
> >>
>
> >> Company Phone US: [phone] <(332)%20233-8231>
> <(332)%20233-8231>
>
> >>
>
> >>
>
> >>
>
> >> E-Mail: [e-mail]
>
> >>
>
> >> Internet: www.linkgenetic.com
>
> >>
>
> >> Book us: https://calendly.com/linkgenetic
>
> >>
>
> >>
>
> >>
>
> >> This message (including any attachments) is confidential, for the
>
> >> exclusive use of the intended recipient and may contain privileged
>
> >> information. If you are not the intended recipient, retention,
>
> >> dissemination, distribution, copying or otherwise making use of this
>
> >> message is strictly prohibited.
>
> >> Please be kind enough to notify the sender immediately by e-mail if
>
> >> you have received this message by mistake, and delete it from your
>
> >> system. Thank you.
>
> >>
>
> >>
>
> >> _______________________________________________
>
> >> dispatch mailing list -- [e-mail] To unsubscribe send an
>
> >> email to [e-mail]
>
> >>
>
>
>
>
>
>
>
>
>