Re: XML catalog draft

Jon wrote:
| [Peter Murray-Rust:]
| | I am not familiar with the URN process in detail - am I right in
| | assuming that it based on DNS?
|
| Yes. See
|    draft-ietf-urn-naptr-01.txt
|    draft-ietf-urn-http-conv-00.txt
| I don't understand the URN proposal completely, but it seems to be
| attempting vastly more than what we need.

Not Yes, No.  NAPTR is only one proposed URN resolution mechanism.  URNs 
don't depend on NAPTR or DNS, or any one resolution mechanism.  In the 
abstract, you'd have local URN resolution, local instructions to your URN
resolution engine, and the ability to link up to larger-scale
engines and locally coordinate the results therefrom.  NAPTR can
address Lee's fear that URNs will not be resolvable, however,
and it is reasonable to think that some relevant entity such as 
(cough) SGML Open or GCA, would see advantage in offering URN 
resolution for the FPI name space.

As for scope, see below.

| Let's postulate the existence of some organization whose function is
| to provide such a service and make just enough to pay for itself and
| the salaries of the people it employs.  ...

Those would be good salaries with job tenure?  Ah, for the Fifties!  

Anyway, someone else already pointed out the denial-of-service 
problems that can result from so direct a mechanism.  
Neither publisher nor user should rely on eternal resolution through 
a single source.  NAPTR does avoid at least most of this 
problem.  If you could manage to get on the wrong side of Internic, 
watch out, but they don't seem to have a wrong side yet.

As a user, if your usual URN resolution setup fails, you want
to try something else rather than believing some.org that the
URN is no longer resolvable.  The hard truth is that some things
named by URNs will become unresolvable even though they still 
exist, just like misshelved books in library.

Re scope, the URN effort encompasses no less than what we all
need for generalized and indirect persistent naming.  Jon doesn't
need so much to meet his immediate publishing requirements, because
his information has a relatively short shelf life, he can
rely on a legal department to help him prevent or mitigate
deliberate denial of service, and if some.org cut him off anyway
he could make new resolution arrangements known to his audience,
because Sun is both big and public and, more importantly, around
to tend to matters.


Regards, 

    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Sunday, 9 February 1997 21:06:11 UTC