Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

[Jonathan A Rees <[e-mail]>]

On Tue, Jan 10, 2012 at 4:30 AM, Julian Reschke <[e-mail]> wrote:

> On 2012-01-10 07:22, Juha Hakala wrote:
> I still don't see what this has to do with "location" vs "naming". You can
> start with a locator and overload it as a name, or you can start with a name
> and overload it as locator.
>
> The former has been done a lot with HTTP URIs, the latter is what you seem
> to try to do with URN resolution.
>
> In the end, where's the difference?

As I see it the significant difference between urn: and http: is that
the NID registry is administered by IETF through the RFC process, and
establishes NIDs permanently, while the domain name registries (other
than .arpa, .example, and .invalid) are administered by ICANN (with
delegation to TLDs and so on), and seem to always involve the threats
of expiration and steward corruption.

If the NID namespace were embedded in .arpa we could have a full equivalence:

urn:nid:path  == http://nid.urn.arpa/path

The latter could even be resolvable in the usual HTTP way, if someone
were to set up a network of servers that did URN resolution via DNS
and HTTP. (Obviously just best effort, as some legitimate URNs are
going to be unresolvable.)

>
>> There has also been discussions about persistence (or the lack of it) of
>> domain names, and the need of identifying abstract entities such as
>
> If you don't use domain names, you'll need an alternate system to delegate
> responsibilities. Who's going to run it? Who's going to guarantee
> persistence of *that* system`?

I think persistence and resolvability can and should be decoupled, and
treated as separate responsibilities.

Persistence is relative and to some extent subjective. I would say
that the RFC series is a pretty good bet for persistence, as are the
non-DNS registries such as media type, link relation, message header,
etc. So that is where I would set the bar - are the bindings of the
URIs in question (whether URN or HTTP) as persistent as the binding of
(say) media type name to media type?

To answer the question of responsibility for persistence, URN
persistence devolves to IETF, with the help of IANA, and with
delegation to the NID authorities. Persistence of the NID
registrations is enhanced by the existence of mirrors of the IETF RFC
series. If you trust the NID authorities and their technical
infrastructure and succession plans then URNs are as persistent as the
RFC series. Whether you do trust them or not is sort of up to you.

We don't have a persistence story like this for http: since domain
name registration (outside of .arpa) seems to always be vulnerable to
loss. No matter how much you trust an organization's ability to
maintain the registration over decades, there will always be a nagging
doubt, which is very annoying.

I too find the "naming" vs. "location" dichotomy not very compelling,
but I do find the renewal requirement vs. permanent NID registration
to be hard to gloss over. For me, expiration and corruption risks are
the real hole in the "Cool URIs" story.

Resolvability via DNS is a different story from persistence, and
indeed the business model for the party that would be responsible for
resolution is not clear to me. IETF and IANA absorb the cost for other
registries, but might balk at being asked to provide DNS support for
something like .urn.arpa. This for me is the hole in the "resolvable
persistent URI" idea. But I am not convinced yet that this is
insurmountable. We do have other persistent registries, so the
difficulty has to be one of scale, not of kind.

>> works (which may or may not have manifestations in the Web).
>
>
> "A 303 response to a GET request indicates that the requested resource does
> not have a representation of its own that can be transferred by the server
> over HTTP. The Location URI indicates a resource that is descriptive of the
> target resource, such that the follow-on representation might be useful to
> recipients without implying that it adequately represents the target
> resource. Note that answers to the questions of what can be represented,
> what representations are adequate, and what might be a useful description
> are outside the scope of HTTP and thus entirely determined by the URI
> owner(s)." --
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3.4>

+1

Best
Jonathan

>> ...
>
>
> Best regards, Julian
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn