Re: An Anchor attribute question:

"Daniel W. Connolly" <>
Date: Thu, 2 Jun 1994 21:27:01 +0200
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: An Anchor attribute question: 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
In message <>, Michael Mealling writes:
>A WWW URI will work exactly as before. It doesn't change anything except for
>testing to see if it's a URL with the required 'URL:' pre-prefix. 

Ok, so this is a small issue. In effect, you've stolen URL: from
the scheme namespace. Aside from the fact that there's not reason
to do this, it's pretty harmless.

>Is there ever to be a reconciliation between WWW URIs and IETF URIs?

Neither has an architecture that is compelling just by its
elegance and simplicity, but WWW has an installed base of
about 2million, last I heard. I have seen _no_ motivation
for many of the syntactic features in the IETF URI papers.

Two things convince me: (1) a formal argument, or (2) time.
The WWW stuff has some time behind it. The URL: noise
has neither.

Why do you need to distinguish between URLs, URNs, LIFNs, etc?
Why not just use the one big happy address space that's
currently deployed? When you discover new ways to resolve
addresses (be they protocol-independent, location independent,
or whatever), you just make up a new scheme, and away you go!

>> Blech. Hack. Barf. Who writes HREF="URL:..."? Why?
>According to the current IETF URL draft a URL should be prefixed by
>a 4 characters identifier so you know you have a URL as opposed to a 
>URN or LIFN or whatever.

My question remains unanswered.

>> Why is this a bug? That code is written to the URI spec, and per
>> the URI spec, URN:blah:blah: is garbage.
>Why is URN:bla:bla:bla garbage?

> It fits the WWW definition of 
>scheme:path just fine. The only small problem is that, according to the
>BNF, _path_ is an xpalpha which cannot include ':' since ':' is part of
>reserved. ':' is also the only element of reserved that is not used 
>anywhere else. I _could_ escape the other colons but I would rather not.

In a WWW URI, hierarchical names are separated by /. This is a
convention with about 4 years behind it.  If you're going
to use the WWW architecture to deploy URNs, why not stick with that
convention and write

>> Change the URN syntax, not the HTParse() code.
>I'm trying to make sure that it won't matter either way.

I believe you're unnecessarily complicating matters. If this
URN:blah:blah syntax is deployed, folks will have to deal with two
syntaxes for the same features. It's not the end of the world,
but it's a pain in the ass for no reason.