Re: An Anchor attribute question: (Michael Mealling)
Date: Thu, 2 Jun 1994 21:04:25 +0200
Message-id: <>
Precedence: bulk
From: (Michael Mealling)
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
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
Daniel W. Connolly said this:
> In message <>, Michael Mealling writes:
> >Ok, I've added a couple of lines to HTParse.c that fix this and a few
> >other things that the current URL spec breaks:
> ACK! You changed HTParse.c to grok IETF URLs rather than WWW URI's?!?!
> I don't think that's a very good idea. Now you've got a piece of
> code that doesn't match the URI spec any more!

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. 

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

> >in scan() I added these two lines just before the line 
> >after_access = name;:
> >
> >    if(!strncmp(name,"URL:",4))
> >        name=name+4;
> >
> >This takes care of the current URL spec that requires URL: in front of
> >a URL. Normal WWW URLs still work normally.
> 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.

> >This fixes the apparent small bug that causes URN:bla:bla: to get fouled up.
> 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.

I know of no URL that will break if that small change is made. I know that
in itself not a good enough reason to do it but if it makes WWW and the
current IETF proposals compliant then it buys us something, right?

> Change the URN syntax, not the HTParse() code.

I'm trying to make sure that it won't matter either way.


<HR><A HREF="">
<ADDRESS>Michael Mealling</ADDRESS>