# Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational

Jon P. Knight (J.P.Knight@lut.ac.uk)
Sat, 24 Sep 1994 14:53:01 +0100 (BST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Larry Masinter: "Re: AGENDA ITEMS for December IETF meeting"
- Previous message: Gary Adams - Sun Microsystems Labs BOS: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- In reply to: Norbert Leser - OSF DCE:: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- Next in thread: Larry Masinter: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"

    Date: Sat, 24 Sep 1994 14:53:01 +0100 (BST)

    From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>

    Subject: Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational

    To: "Norbert Leser - OSF DCE: (617)621-8715" <nl@osf.org>

    In-Reply-To: <199409231814.OAA13582@postman.osf.org>

    Message-Id: <Pine.3.05.9409241400.A18949-d100000@suna>

On Fri, 23 Sep 1994, Norbert Leser - OSF DCE: (617)621-8715 wrote:
> 2. The scalability requirement for URNs and the requirement that names are
> persistent "forever" seems to be superficial. How do you want to enforce
> this? Isn't this clearly the property of the underlying naming systems?
> 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"?

``Forever'' persistence will probably be very popular with the library
community where they like their archives to last hundreds of years.
Scalability is, I would have thought, an obvious requirement. If the URN
scheme doesn't scale beyond 10,000,000 unique objects then its broken for
example. We're talking a about naming on a scale thats not really been
approached before, so I think these two requirements are highly desirable.
We might find with implementation experience that they are not achievable
but they're damn good goals to strive for. As for supporting legacy
systems, my opinion is that it will be tremendous if we can embed things
like ISBNs, ISSNs, etc, but that we shouldn't compromise the other
requirements of the URNs purely to handle this. There's too much at stake.

> .../C=US/O=SUN; L=Palo Alto/arch.dev/_fs/D:\games\bonk.exe
>
> would translate to:
>
> //.../C%3DUS/O%3DSUN%3B%20L%3DPalo%20Alto/dev/arch/_fs/D%3A%5cgames%5cb
> onk.exe
>
> I cannot imagine that anybody would defend the proposed syntax
> as being practical.

Well, I will for one. Its much safer to have certain characters encoded
so that you can spot the difference between symbols denoting structure in the
UR* and symbols which should be passed straight to the underlying
software. See the URI WG archives for discussion of the FTP URL to see
where this comes into its own. Also see below on the topic of whitespace.

> Despite the fact that such names can very well be computed, how ever do
> you want to support 'cut and paste' through GUIs and how do you
> think a human being can parse such cryptic sequences of characters?

How does having %20 instead of ` ' prevent cut'n'paste in GUIs? If it
screws your GUI up, I think its time you invested in a new user interface.
:-) Most humans won't parse the UR*; they'll just type them in or
cut'n'paste, etc. Those of us that want to parse them can (its not
exactly rocket science and I do it all the time in the WWW).

> Simple mechanisms such as quoting or wrappers could take care of
> potential problems.

You must have missed the past few weeks discussion about the ``simple''
mechanism of wrappers... :-)

> Also, the ever lasting discussion on why white
> spaces are prohibited and always need to be encoded doesn't give a
> sound reason.

Ok, here's a sound reason (IMHO): say your resource name appeared in print
(in the citations in a journal article for example). It has some sort of
wrapper round it to delimit it (say <URN:....> :-) ) but it has a single
unprotected whitespace in it. Many typesetting and wordprocessing
packages will use that space as an opportunity to break what it sees as a
sentence. Then you no longer know if you had one, two or two hundred
spaces there in some circumstances. As UR* are supposed to be able to
appear in printed documents and still be fairly easily transcribable, this
could pose a bit of problem. Luckily %20 doesn't have similar nasties
associated with it.

> Another issue is the imposed left-to-right hierarchical ordering.
> Besides that other scalable naming systems aren't necessaryly purely
> hierarchical (such as the attribute based X.500 with multiple
> attribute-value assertions), ironically enough, the Internet own DNS uses
> a right-to-left delineation of names.

Is it me, or is this just a bogus argument? I was writing little bits of
code to reverse lists when I was a teenager. Email has had the
``problem'' for years with the Internet world order versus the old JANET
order (which now thankfully dying out) and it yet it still works.
Machines have big endian and little endian words. So what? Every
manufacturer worth her salt provides a library to convert into the
arbitrarily defined network order. All this problem needs is an interface
between the URI WG's ``World Domination Order'' and the particular order
of the naming scheme in use. Or have I missed something?

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *

- Next message: Larry Masinter: "Re: AGENDA ITEMS for December IETF meeting"
- Previous message: Gary Adams - Sun Microsystems Labs BOS: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- In reply to: Norbert Leser - OSF DCE:: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- Next in thread: Larry Masinter: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"