To: nl@osf.org
In-Reply-To: nl@osf.org's message of Fri, 23 Sep 1994 13:57:01 -0700 <94Sep23.135709pdt.2764@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: <94Sep23.164207pdt.2763@golden.parc.xerox.com>
Date: Fri, 23 Sep 1994 16:42:04 PDT
(I removed the 'iesg' list from the discussion as I don't think the
technical details are of specific concern to that group. I'm hoping
that in future, enough of the concerned 'fn-arch' list will have
joined uri@bunyip.com to make it unnecessary to copy that list on the
discussion).
Norbert,
Let me address some of the other points you've raised:
1. Global scope
While there might be some use for local or relative scope names as
well as global ones, they might have a different set of requirements
than global ones. Global names that don't refer to objects that
contain pointers to other objects, for example, don't need relative
names. In general, the URI group has wanted to separate out the
requirements for global pointers, and that's what we've intended to do
here.
> Lets just consider an example where an organization changes its
> underlying naming server technology and wants to maintain the old
> documents by the new servers. In this case, not only the access
> protocols and the associated addresses (URLs) change but also the
> global context might change. It's obviously not a good idea to
> require an update of any instance of URN references within a
> document.
It is exactly this kind of scenario that led us to the requirement
that names be persistent, and have a lifetime longer than any
organization. The names should persist outside of the mechanism used
to do name -> location resolution.
> 2. The scalability requirement for URNs and the requirement that
> names are persistent "forever" seems to be superficial.
I'm not sure what you mean by superficial. We weren't joking, and
really mean it.
> How do you want to enforce this?
There are several ways of insuring that this happens. For example,
names that contain timestamps as well as components that are
guaranteed to be unique at any given time have that property; LIFNs
that are tied to the MD5 signature of the object named have this
property, as do several other hierarchical naming schemes that are
built on a presumption that parts of the heirarchy don't get
reassigned over time. That we've not settled on a single enforcement
mechanism doesn't mean that it isn't enforcable.
> Isn't this clearly the property of the underlying naming systems?
It is; the requirements document asserts that it is a requirement of
whatever underlying naming systems are chosen.
> If a naming system has a flat namespace, it might not be as scalable
> as a hierarchical system, etc. But if we require certain properties, how
> does that go along with the other requirement of "legacy support"?
Being able to encompass some legacy systems doesn't mean that we rely
on legacy systems to meet all of the scalability requirements.
> 3. In section 3 (URN encoding), a "single" and "well specified" algorithm
> is required for "simple comparison". Yes, taking the qualifier "simple"
> it might work and it's goodness to have such algorithms (actually,
> we have similar comparison operations for equality of names in XFN).
> However, it needs to be pointed out that failing a comparison doesn't
> necessarily mean that names are not equal (i.e., naming the same object).
> Things like different character encodings (I18N issue), multiple AVAs
> (X.500 property), different case matching rules, and support of
> approximate matches (also X.500) cannot easily be supported by a
> "single" and "well specified" algorithm.
You've confounded two things that we tried hard to separate out,
namely: two names being the same, vs. two different names naming the
same thing. In general, though, those systems that don't support this
requirement are not really candidates for 'legacy' support. In
particular, we definitely want to avoid the issues of approximate
matches, searching a la X.500. I know those systems believe they are
handling the "naming" problem, but we indeed intended to narrow the
scope to disallow such things.
> 4. Also in section 3, the requirement that comparison "is case insensitive"
> and "probably (insensitive to) white space and some punctuation marks"
> appears to conflict with the previous requirement of legacy support.
> There is a number of naming systems that assume case exactness, use
> white spaces, etc.
I'm sure you realize there are ways to embed case-exact systems in
case insensitive ones, using a suitable encoding. Insofar as that is
palitable and the naming system otherwise suitable, they can be
embedded, but our goal is really to have something that's simpler for
humans to deal with.
> 5. If I understand the URI specification (RFC 1630) and the current URN
> proposal right, you want to support any number of naming systems with
> your format ("legacy support" and "grandfathering").
I'm hoping we'll get group confirmation that we didn't intend for
"legacy support" and "grandfathering" to take precedence over the
other requirements we listed.
Although I agree that the translation of:
.../C=US/O=SUN; L=Palo Alto/arch.dev/_fs/D:\games\bonk.exe
to:
//.../C%3DUS/O%3DSUN%3B%20L%3DPalo%20Alto/dev/arch/_fs/D%3A%5cgames%5cbonk.exe
results in something unpalatable, I think the conclusion I draw is
different: we shouldn't try to embed X.500 'names' into URNs, because
the syntactic translation would be ugly.
The main reason why we want to encode white space, for example, is so
that URNs can get printed in newspapers reliably.
Let me characterize what I think the primary difference in perspective
might be: The URI working group is primarily concerned with
constructing a useful naming system that will be viable for a large
number of applications; while dealing with 'legacy' systems was a
requirement, other usability constraints had higher requirements.