Re: Replacing Link trailers

["H. Peter Anvin" <hpa@zytor.com>]

On 2025-10-13 12:07, H. Peter Anvin wrote:
> 
> Oh my.
> 
> Irony.
> 
> This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience. The compromise was to have an URL schema that:
> 
> a) fully encodes the message ID, so that the death of any specific archive doesn't mean irreversible information loss;
> 
> b) is encoded under the kernel.org domain name, so it is under our direct control. 
> 
> In IETF terms, we want an identifier that is both a URL and a URN (senso lato.)
>

Another way to look at it is whether to put the bulk of the burden on the
sender or receiver. There are arguments both ways, however, I think Linus does
have a point for a couple of reasons:

1. Move burden away from the maintainer/reviewer.
2. The number of tools used for *reading* usually vastly outnumber the tool
   used for *writing*.
3. A resource name provides no hint whatsoever as to how to locate and
   retrieve said resource. git is used for many projects, and so it isn't
   reasonable to automatically assume any one mailing list or other
   collection, such as LKML. Thus, the Message-ID: alone is insufficient.

There are a few downsides:

a. It implies a default user experience; visiting an alternative archive or a
   local archive requires decoding the link back to its original.
b. Mis-encoding at the source or not using an approved schema violates the
   constraint that the resource name is recoverable, and it may not be
   immediately obvious (early on we saw a lot of Link:s to lkml.org, which
   did not encode the message-ID in any meaningful form.)
c. It makes it at least somewhat harder to deal with links to embargoed
   discussions which will become public, as it is unlikely the embargoed
   discussion will be archived as the same URL as when it becomes public.

Personally, for me, item 3 is the one that really clinches it. Since
Message-ID alone is insufficient, I don't believe it is possible to trust the
user to encode all the appropriate information in a way that is generic across
projects (the original proposal was for an ad hoc LKML tag containing the
Message-ID). The Link: tag provides at least that much of a general solution
to this problem, and it can also link to genuine web resources for the kinds
of projects where this kind of information is not processed via email.

As far as the downsides, all of them can all be handled with tooling in the
form of an URL pattern rewriter. This is very easy when a link is invoked by
executing a browser; when it is internal to the browser and/or invoked via
some kind of IPC API then it gets more difficult, needing a browser-specific
plugin or using a proxy.

As far as Patchwork is concerned, that should be a rather obvious feature
(encode Message-ID as a Link tag) to add to Patchwork. There are several other
features Patchwork really needs, one of the main ones being a way to supercede
an individual patch in a series.

	-hpa