Albert Lunde (
Fri, 2 Jun 95 22:07:36 EDT

> I missed the info vs. std distinction ... sorry ... but our standard
> will use a term which is defined in an informational RFC and while
> I acknowledge that this can be made right by defining URI in the HTML
> std, this will be confusing if you can't match RFC 1630 and yet
> include it as an information reference. I don't yet understand
> how the words and BNF on page 24 RFC 1630 can be interpreted to
> not mean that the URI would include url: as a prefix as my
> original post cited below shows.
> > >A URL is one kind of scheme of a URI. Hence,
> > >
> > >URI: url:
> > >and URL:
> If a URL is not distinct from a URI having two terms which mean the
> same thing is confusing at best and frankly makes me seem like a
> real non-expert when I try and tell clients that we have two
> terms for the same thing. All the VENN diagram suggested to me
> was that we had some url methods someone was to lazy to register
> so we don't have name space uniqueness.
> Common practice is to call these things URLs. Let RFC 1630
> simply be informational defining what is now a deprecated term
> and go with URL as the term.

URI is not a deprecated term: it seems to me that it is a generalization
of URLs intented to cover URNs and othe stuff. By using it in the
standard we are leaving ourselves open to extensions via the work of the
URI working group.

I think, however the use of the prefix url: in front of URLs was
prefered for a while in the URI working group, but sufficently
unpopular it was dropped from later sepecifications, except in the
context of the "wrapper" <URI: > for marking them in plain text.

I haven't followed this closely, so I may be wrong about the details.

I have a printout of a draft of a "Uniform Resources Locators"
document dated Mar 21 94 which says in section 1.1.1:

To be a Uniform Resource Locator as currently defined by the URI working
group, the whole string must start with a constant prefix "URL:". [...]

This seems to have disappeared from RFC 1738, so the production

prefixedurl u r l : url

in RFC 1630 may be read as a historical footnote.

I'm not sure this is an inconsistency we can iron out at this time.

The URI working group is going to keep redefining things. I'd guess
the reason for referencing RFC1630 is that it generally reflected
current practice better and includes some details that are more
web specific like fragement-id and relative URLs.

    Albert Lunde