- From: Dale R. Worley <worley@ariadne.com>
- Date: Sun, 11 Jan 2026 22:21:41 -0500
- To: Graham Klyne <GK-bulk@ninebynine.org>
- Cc: ted.ietf@gmail.com, duerst@it.aoyama.ac.jp, melvincarvalho@gmail.com, urn@ietf.org, uri@w3.org
Graham Klyne <GK-bulk@ninebynine.org> writes:
> Agreeing with the other responses, I note that there exists a URI scheme that
> has local(ish) semantics, viz file:.
> [...]
> A file URL takes the form:
>
> file://<host>/<path>
>
> where <host> is the fully qualified domain name of the system on
> which the <path> is accessible, and <path> is a hierarchical
> directory path of the form <directory>/<directory>/.../<name>.
> [...]
> (and similar in https://datatracker.ietf.org/doc/html/rfc8089#section-2)
IIUC, this mean that the minter of a "local identifier" needs to be (or
coordinate with) the owner of a domain name, preferably one that is not
assigned to an existing host. Then they can create file: URIs using
that domain name as a host name, and whatever path parts they want (that
conform to the syntax).
I would seem best if the domain name isn't the name of a host, so that
it cannot be misunderstood to identify a file. So I might create URIs
like
file://unique-1234.local.ariadne.com/resource/1
since I own ariadne.com and there will never be a host
"unique-1234.local.ariadne.com".
Though the semantics are somewhat deviant, in that presumably I am using
the URI to identify *something*, that something isn't a file.
At this point, I don't think that file: URIs provide any more
convenience than cid: URIs but the deviation from the pre-existing
semantics is greater than for cid: URIs.
Dale
Received on Monday, 12 January 2026 03:21:54 UTC