To: nl@osf.org
In-Reply-To: nl@osf.org's message of Wed, 21 Sep 1994 22:21:27 -0700 <94Sep21.222132pdt.2760@golden.parc.xerox.com>
Subject: Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Sep22.001212pdt.2760@golden.parc.xerox.com>
Date: Thu, 22 Sep 1994 00:12:05 PDT
While I'm sympathetic to your concerns, and eager to achieve some
resolution and compatibility between IETF resource names and the work
in X/Open, I think some of the reservations you have expressed are
misplaced.
Re your point 1:
"Requirements for Uniform Resource Names" is being proposed as an
informational RFC to describe the intent of the URI working group:
what problem are we working on. The fact that your organization has a
specification which may (or may not) satisfy the requirements that
we've identified shouldn't be a reason to hold up the publication of
the requirements.
If we were proposing to publish a Draft Standard at this time, and
there was another design which might meet our requirements and have
other advantages of compatibility, the situation would be considerably
different.
As it stands, though, publishing this RFC at this time would seem (at
least to me) not to impede any future convergence of the technical
elements. For example, you might wish to propose the XFN specification
or some subset of it as a possible model for URNs to the URI working
group.
Re your point 2:
You point out that RFC1630 and the proposed requirements cross
reference each other. I'm not sure if you consider this a problem, or,
if you do, what the nature of the problem is. You say that the URN
requirements document needs to be modified to make it clear what
dependencies it has on RFC 1630, but I'm not sure why you think it is
important that we achieve that precision; i.e., in what way does the
document not stand alone?
Re your point 3:
I believe that your primary objection is that the requirement that
URNs encompass legacy naming systems is not mutually satisfiable with
some of the other requirements:
a) the syntactic rules are too stringent for expressing
the wide variety of 'names' you might get in X.500, etc.
b) some legacy naming systems don't have global scope.
c) some legacy naming systems use names that are case sensitive.
I think the simple answer to your objection is that "support for
legacy systems" takes lower priority than the other objections.
Insofar as a naming system requires case sensitive names, awkward
parsing rules or expression using special characters, or the names
within them are not of global scope, they are not reasonable "legacy"
candidates to be considered for URNs.
That the requirements are too stringient to support all possible
"legacy naming systems" is hardly a 'deficiency'; surely, there are
many naming systems that require support for multiple character sets,
or for which the names are neither global nor persistent, which will
not be considered for encapsulation in a URN system.
I might suspect, from your message, that the X/Open Federated Naming
specification is of a form that it doesn't satisfy the requirements we
listed for URNs. If that's the case, and *IT* isn't flexible enough to
allow migration or subsetting, that's hardly a good reason for the
delay of publication of the proposed informational RFC.