[urn] Re: Registration for the TEI: URN identifier

> On 12 Mar 2026, at 16:41, Dale R. Worley <[email protected]> wrote:
> 
> Further thoughts on TEI.  This message rambles, so don't take any part
> of it as my definitive opinion.
> 
> I was chair of the working group that defined the "alert" URNs to be
> used to carry "distinctive ringing" instructions to/from telephones.  The
> definition allowed telcos and equipment manufacturers to create custom
> alert URNs that incorporate their domain names.
> 
> As the specification was approaching completion, Alfred Hoenes (IIRC)
> raised the objection that domain names do not have permanent owners.
> This was immediately before an IETF meeting, so at the meeting I checked
> with the ADs and they agreed that this was a significant problem.  After
> looking into various solutions, we eventually defined a special registry
> in which enterprises could register their names for constructing custom
> alert URNs.
> https://www.iana.org/assignments/alert-urns/alert-urns.xhtml#providers
> Currently it contains only the entry "example".
> 
> So in that case we did "create a new global company registry".
> 
> In the case of TEI, I think we can move forward without creating a new
> registry using this argument:  TEIs are going to have a considerably
> different usage pattern that alert URNs.
> 
> In particular, the knowledge of alert URNs is built into telephones and
> telephone networks and those systems are likely to remain unchanged for
> years or even decades.  So it is important that the permanence of the
> meaning of alert URNs is enforce quite strictly.  On the other hand,
> looking at
> https://github.com/CycloneDX/transparency-exchange-api/tree/main/discovery
> it is clear that the usefulness of a TEI URN is tightly coupled to
> accessing the HTTPS server at the <domain-name> in the URN.
> 
> The consequence of that is that if the ownership of a domain name
> changes and the new owner does not intend to continue to support the
> existing set of TEI URNs by maintaining the HTTPS server (and the servers
> that its /.well-known/tea document points to), the existing TEI URNs
> become meaningless *in practice*, although in theory their meanings are
> fixed for all time.
> 
> It seems to me that this is an adequate response to the problem of "What
> if the ownership of a domain name changes?"  We would likely want to put
> some information about resolution in the registration to justify not
> worrying about this.
> 
> However, looking this over, it seems to me that in reality, TEIs aren't
> so much *names* as *locators*; nobody really cares about the TEI for an
> object if the corresponding servers aren't accessible (at least in the
> future).  That suggests that TEI be promoted from a URN namespace to its
> own scheme and stated to be a URL.  So instead of
> 
>    urn:tei:<type>:<domain-name>:<unique-identifier>
> 
> write
> 
>    tei://<domain-name>/<type>/<unique-identifier>
> 
> That would eliminate all of the philosophical problems.  The scheme
> "tei" hasn't been registered.  The procesdures for registering a scheme
> name are in sec. 7.2 of RFC 7595 and don't look much more onerous than
> registering a URN namespace.

Let’s put domain ownershop aside. We went through the long route and
tried various resolutions using DNS records but there was no support in libraries
and even CURL refused to implement the needed records. If a TEI: scheme instead
of a URN name space makes more sense we can certainly do that. The reason
to select URN when we started was that this was supposed to be an identifier
separated from the location, but I guess we had to move ourself towards
location…

Tecnichally where we are, maybe a URL scheme makes more sense.

I’ll bring this discussion to the group.

Thank you for all your feedback!

/O
_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]