ACTION-23: Look into what the right practice is if we use urns.

Look into what the right practice is if we use urns.

Adam Roach
Due on:
August 4, 2016
Created on:
July 28, 2016
Related emails:
No related emails

Related notes:

The executive summary is that we should be just fine, as long as we're willing to do a little bit of work in the IETF and agree on measures to assure uniqueness within a namespace.

In many ways, sing URNs turns out to be simpler than I originally anticipated. The general process [1] is to publish an RFC through the IETF to reserve the namespace. The IETF does not manage sub-namespaces: that's the responsibility of the registrant or some third party they identify. Among other more mundane things, the registering RFC has to identify a specific authority responsible for the namespace as well as a description of how uniqueness and persistence of identifiers is achieved.

The OID URN space is a reasonably good example, as its registration document [3] is short, and provides a clear delegation model.

The trick for us would be describing the exact mechanism we plan to use to maintain uniqueness. I know the W3C has historically been wary of setting up a formal registration function, and I doubt we're going to change that for the payments effort [4]. One approach for allowing the W3C to be an authority over a unique namespace (which I believe would be valid, although others have disagreed in the past) would be to state that uniqueness of URNs is enforced by a requirement that URN-identified payment methods are only valid when they appear in W3C-published documents. I'll note that this is, for example, how the uniqueness of property and method names on "window" is enforced at the moment, and that appears to be working just fine.



[2] Technically, there are three different kinds of URNs with different processes involved: formal, informal, and experimental. In practice, the only one that makes even a little bit of sense for what we're trying to do is a formal namespace.

[4] To be clear, I believe such a registration function would be ideal for this and myriad other cases. If Ian has some notion that running this flag up the hill once more isn't likely to be completely fruitless, I'd recommend trying it again.

Adam Roach, 10 Aug 2016, 13:18:53

Closed - housekeeping

Nick Telford-Reed, 9 Oct 2019, 10:42:21

Display change log.

Adrian Hope-Bailie <>, Nick Telford-Reed <>, Chairs, Ian Jacobs <>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 23.html,v 1.1 2019/11/12 14:32:07 carcone Exp $