Re: Registration request for urn:eris: namespace

[email protected] (Dale R. Worley)
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
(I still want to see a versioning device in the Eris URN, but that's not
what this message is about.)

Peter Saint-Andre <[email protected]> writes:
> Thanks for your comments. Indeed, it's unclear to me why the ERIS system 
> really needs to use URNs - why not use system-specific identifiers of 
> some kind rather than the "persistent, location-independent resource 
> identifiers" (RFC 8141) that URNs provide?

Ah, thank you!  I'd tried to track down text in the RFCs that captured
my intuition, but I'd overlooked the passage in RFC 8141 section 7.1
that you mention:

   URI Scheme Semantics:  The "urn" scheme identifies Uniform Resource
      Names, which are persistent, location-independent resource
      identifiers.

(I keep wanting to read the "U" as meaning "universal", but it means
"uniform".  OTOH, "uniform" includes "uniform across the Internet".)

To restate what I meant in a way that hopefully is clear, what I don't
like about the current proposal is that the identifiers aren't
*location-independent*.  There's no way to use them that is
location-independent, even to the point of being able to examine one to
see if one can use it, other than by simply giving it to the local "Eris
system" and checking whether it returns a resource vs. an error.  In the
end, everything that can be done with them is done using the implicit
context of "the local Eris system".

I foresee this is will become a practical problem as well.  The current
vision seems to be that there will be many "Eris systems", but that any
particular use of Eris URNs will be isolated within exactly one Eris
system.  That design decision is often made in information systems, but
it rarely remains valid; work proceeds to interconnect multiple systems,
and eventually the operational context becomes "all of the Internet".
In the latter situation, every Eris URN usage will have to have attached
to it an identifier of the system within which it is to be used.

I think as a practical matter, this issue can be fixed in a number of
ways.  One would be to presume that each "Eris system" will have a
unique DNS name, and insert that into its URNs.  E.g.

urn:eris:eris.example.com:H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ

For initial/limited/experimental usage, assigning a DNS name might be
awkward, but that can be finessed by e.g. using "localhost" as the
well-known name for "wherever we are now"

urn:eris:localhost:H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ

or even allowing the system name to be null

urn:eris::H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ

(That last is valid URN syntax according to RFC 8141.)  Either of those
forms carries a marking that it's not interoperable with other Eris
systems.

Indeed, it would be reasonable to consider constructing an Eris *URL*
along the lines of

eris://eris.example.com/H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ

but the effort to register that would be a lot higher than registering a
URN namespace.  Also, you'd have to decide what the default protocol for
accessing the server is, and I don't think you've solidified that.

Dale
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.