Re: [URN] I-D ACTION:draft-ietf-urn-naptr-04.txt

[Dan Connolly <[e-mail]>]

[e-mail] wrote:
>        Title     : Resolution of Uniform Resource Identifiers using the
>                    Domain Name System
>        Author(s) : R. Daniel, M. Mealling
>        Filename  : draft-ietf-urn-naptr-04.txt
>        Pages     : 14
>        Date      : 03/21/1997

This NAPTR stuff is cool: it's an interesting point in
the design space between the old path: scheme and MX
records.

A few comments:

>In conjunction
>with a long TTL for *.urn.net records, the average number of probes to
>DNS for resolving DUNS URNs would approach one.

I would very much like to see the full argument behind that
sentence -- it appeals to my intuition, but I want to
study the details. Are they available somewhere?

>      sprintf(key, "%s.urn.net", extractNS(URN));

er... where's the specificaiton of extractNS? That seems
absolutely critical to the whole thing, and yet I don't
see it specified anywhere except the three examples
(which I assume are non-normative, per standards tradition).

Based on the examples, the algorithm seems to be
"grab the stuff before the :; if it's urn:,
grab everything up to the _next_ :."

Why the special case for the urn: prefix? I seem to
be asking that a lot. But I'm just applying occam's
razor: unless there's a darn good reason for special-casing urn:,
we should not.

Hmm... whoever administers urn.net seems to be able
to introduce new URL schemes at will. That should
certainly be discussed in the URL process document!

I thought I
saw a document specifying the policies for urn.net,
but I can't seem to find it now.



-- 
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21