Re: An Anchor attribute question:

Michael Mealling (
Thu, 2 Jun 1994 14:57:57 -0400 (EDT)

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>