Message-Id: <199409222135.RAA11487@postman.osf.org>
To: Larry Masinter <masinter@parc.xerox.com>, uri@bunyip.com
Subject: Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational
In-Reply-To: Your message of "Thu, 22 Sep 1994 00:12:05 PDT."
<94Sep22.001212pdt.2760@golden.parc.xerox.com>
Date: Thu, 22 Sep 1994 17:35:37 -0400
From: "Norbert Leser - OSF DCE: (617)621-8715" <nl@osf.org>
> Larry Masinter writes:
> "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.
All that might very well be true. But if the URN publication as RFC does
not have any enforcing value whatsoever, why bothering at all.
My understanding is that the outlined requirements in the URN document
are to be the basis for forthcoming URN specifications. Therefore,
an Informational RFC has a certain value. And, I want to say it again,
I view the URN requirements document as important and want it to become
an RFC - but only after some obvious deficiencies are being addressed.
> 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?
See, the point here is that I'm confused, at least. You suggest that the
URN document does not stand alone. What I've heard from Karen, however,
says that there's no dependency on RFC 1630.
Either way, whatever is the case, we have a problem here:
If there is a dependency than the encoding rules outlined
in 1630, that are suited for URLs, are not the appropriate ones for URNs
(let alone the discrepancies between 1630 and the URL spec).
If there is no dependency, than the URN spec needs to be reworded to
not mislead.
> ...
> 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.
Fine, that's your interpretation. But what if interprete it the other way
round? For me, the global scope requirement or the case insensivity has
lower priority. Of what use are the entire requirements than?
> 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.
Again, it's exactly the other way round. You claim in your spec that
grandfathering and legacy support is a requirement.
[BTW, XFN is well suited to process URN names. But what I primarily want to
tackle here is handling names of an xfn scheme in URNs.]
Norbert