Re: new port for DNS

I wrote:
>>All of the DNS-based URN proposals now on the table use DNS merely to locate a
>>URN resolver; the final step is done using another protocol (e.g. HTTP).
>>Therefore, you only need an in with the system admins if you want your URNs to
>>use funky names based on OIDs or the like.  Ordinary people can just run a URN
>>resolver on their home machine, and use the DNS name of that machine in their
>>URNs.

Michael Mealling replied: 
> But using the DNS name of their machine in the URN is not persistant. If
> we do that we might as well be using URLs. DNS hostnames as persistant names
> has already been shown to be non-presistant beyond the very top levels. 
> 
> Its not the ones that can hire the sysadmins that concern me. Its documents
> generated by regular people that are valuable to historians that people
> like the library community want to preserve in some way. The names
> need to be able to support that in a way that doesn't invalidate the
> name.

This is a good point in favor of a separate URN top-level domain, which I have
previously felt to be unnecessary.  Actually, after seeing this argument, I
would now favor a separate URN top-level domain to be used for locating all
URN resolvers, in order to keep the regular DNS names (which do tend to change
over time) out of URNs.

I also wrote:
>>3. Users behind firewalls that want to resolve URNs will be screwed until such
>>time as firewalls provide proxy service for the URN-DNS port.  Given the
>>increasing popularity of firewalls, not just at commercial sites, but even
>>Universities (e.g. Brown) this seems like a significant barrier to the
>>acceptance of URNs.  If users behind firewalls can use URLs, but can't resolve
>>URNs, I think URNs will go nowhere fast.

Michael Mealling replied: 
> This is one of the more valid points you have. This point alone could
> be a show stopper. Would an alternative based on named being modified to 
> allow a port argument to an NS record be acceptable?

This has serious problems in terms of deployment.  If it only required
modifying the nameservers which would serve URN domains, it wouldn't be a big
problem (we may need a new version of named that understands URN RRs in any
case).  [If we use DNS TXT records to indicate the location of URN resolvers,
as was suggested by myself, and others, well over a year ago, we don't even
need modifications to named.]

But since the iterative chaining through NS records is usually done by the DNS
server which the client resolver contacts, all the installed DNS servers which
serve clients (as opposed to just serving other servers) would need to be
updated.  This is impractical (especially now that Microsoft is developing
their own DNS server which is not based on BIND).  In addition, it might
require that the client contact a DNS server on or outside the firewall;
otherwise the DNS server might not be able to resolve via alternate ports.

On balance, I think that the best solution is a separate top-level URN domain
using the existing DNS ports and protocols, with subdomains of URN based on
long-lived identifiers (OIDs or whatever).

This architecture allows several levels of URN allocation, suitable for
publishers ranging from individuals to organizations like LoC:

0. Authors can publish documents through electronic publishers (at level 3 or
   5) by sending them a document and having them make it available through
   their own URN and URL services.  This is roughly the equivalent of the
   "vanity press".  The URLs and URNs would be assigned by the publisher and
   sent to the author.  An annual fee might be associated with the maintenance
   of the URL.  Ideally, the URN would be maintained "forever".  No ongoing
   computer access is required of the author.  Initial access might just be
   conversion of the document into electronic form.

1. Authors can publish documents on a one-off basis by sending an electronic
   publisher (at any level from 2 to 5) a valid URL and having the publisher
   allocate a single URN which will be mapped to that URL by the publisher's
   own URN service.  This is roughly the equivalent of getting a LoC number
   for a self-published document.  A fee might be charged initially, and each
   time the URN->URL mapping needed to be updated.  Again, ideally, the URN
   would be maintained "forever".  The author must have sufficient ongoing
   computer access (files on FTP or HTTP server) to keep the URLs valid.

2. Authors can publish series by sending an electronic publishing authority
   (at level 4 or 5) the URL (address, port, resolution protocol) of a URN->URL
   resolver service and having the authority allocate a URN namespace for them
   and register the URN resolver for this namespace in their URN DNS zone.
   This is the equivalent of getting an ISBN publisher number.  A fee might be
   charged initially, and each time the location(s) of the URN->URL resolvers
   in the DNS information needed to be updated.  The author must have
   sufficient ongoing computer access to run a URN->URL resolver - this
   doesn't require special privileges on the machine.  The author need not
   actually have resources to serve the URL, if the only URNs published are
   for existing URLs provided by others.

3. This is just a combination of levels 1 and 2, where the author provides
   both URN and URL resolution.

4. Authors who publish sufficiently large numbers of documents that they wish
   to split their URN namespaces among several URN->URL resolvers can do so by
   getting an electronic publishing authority (at level 4 or 5) to both
   allocate a URN namespace to them, and delegate the corresponding DNS domain
   for that namespace.  If we grandfather in things like ISBNs, authors with
   ISBN publisher numbers might only need the DNS domain delegation.  A fee
   might be charged initially; once the domain has been delegated, all updates
   (including the locations of the DNS servers for the delegated domain) are
   managed by the author, so no recurring fees would be necessary.  The author
   must have sufficient ongoing computer access to run a DNS server and
   URN->URL resolver - this will typically require special privileges on the
   machine which runs the DNS server.

5. This is just a combination of levels 1 and 4, where the author provides
   both URN and URL resolution.

@alex
--
inet: dupuy@smarts.com
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net
GCS d?@ H s++: !g p? !au a w v US+++$ C++$ P+ 3 L E++ N+(!N) K- W M V- po- Y+
     t+ !5 j R G? tv-- b++ !D B- e>* u+(**)@ h--- f+ r++ n+ y+*

Received on Wednesday, 21 June 1995 18:45:49 UTC