# Proposed solution to url: prefix problem

Bob Deen (RGD059@ipl.jpl.nasa.gov)
Fri, 22 Oct 1993 10:49:41 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Re: URN definition -- a way out?"
- Previous message: Dirk Herr-Hoyman: "Re: Revision of Chris & Peter's URN paper"
- Next in thread: Jon Knight: "Re: Proposed solution to url: prefix problem"
- Maybe reply: Jon Knight: "Re: Proposed solution to url: prefix problem"

    Date:    Fri, 22 Oct 1993 10:49:41 -0700 (PDT)

    From: RGD059@ipl.jpl.nasa.gov (Bob Deen)

    Message-Id: <931022104941.21c00298@MIPL3.JPL.NASA.GOV>

    Subject: Proposed solution to url: prefix problem

    To: uri@bunyip.com

This was alluded to in recent messages from Erik Ostrom <eostrom@gac.edu>
and Jock Williams <JWilliams.SBD-E@rx.xerox.com> but I thought I'd make it
more explicit.

I think we can solve the problems the WWW community has with the URL: prefix
and still allow the URL: prefix by adopting the following three rules for
ALL URI's:

1) Define all UR*'s in basic form without a UR*: prefix.

2) If it is obvious in context *to a computer* what the prefix should be, the
UR*: prefix is not required, although it may optionally be used.

3) If it is not obvious, the UR*: prefix is required.

Places where it is obvious in context might be internal to a program, inside
an SGML tag like "<urn>ISBN:...</urn>", or within an HREF tag in an HTML anchor,
like "<A href="http:...">stuff</a>". The HREF tag must be defined to only
contain a URL, therefore it is unambiguous, and we don't break WWW clients,
or more importantly, existing documents.

Places where it is not obvious include most other uses. For plaintext, you
obviously need the UR*: prefix (as well as the <> wrapper but I don't want to
get into THAT argument!). Within a URT or whatever, you need the UR*: prefix
because it could contain any of the types. As a response to a URN->URL lookup,
the UR*: prefix is required because the response might be another URN or might
include UR{C|M}s. We could restrict and codify the "obvious in context"
choices if desired as well. I think most uses would need the prefix.

This means another tag is needed in the HTML Anchor, which can be used for any
URI. The contents of tag would obviously need the UR*: prefix, since it could
contain any type. So, you would have "<A uri="url:http:...">stuff</a>" or
"<A uri="urn:isbn:...">stuff</a>".

The advantages of this are:

1) Existing WWW documents and clients don't break (clients need updating to
handle URN's anyway no matter what we do, so the addition of the URI tag
is no big deal).

2) Each and every occurrence of a URI anywhere is unambiguously identified
as to its UR* status.

3) It is orthogonal, because URLs, URNs, URCs, URMs, ... are all treated the
same.

An additional advantage to WWW is that a document could have *both* a URI
tag and a relative HREF tag. The URI would first resolve to a set of URLs
(from which one is chosen somehow), then the HREF tag is applied relative to
it. This way, the existing pseudo-URL syntax already in HREFs for relative
pathnames and hypertext anchors is available immediately without having to
put fragments or other things in the URN or wait (seemingly forever) for the
URC. (My desire here is to have a URN point at the top of a directory tree
where all subdirectories and files are part of the same document, and be able
to reference a specific file and anchor within the file). Obviously, not all
resources pointed to will make sense with a relative HREF tag, but for those
that do, this is a big win.

What do you think?

-Bob Deen @ NASA-JPL Multimission Image Processing Lab
rgd059@ipl.jpl.nasa.gov span: mipl3::rgd059

- Next message: Mitra: "Re: URN definition -- a way out?"
- Previous message: Dirk Herr-Hoyman: "Re: Revision of Chris & Peter's URN paper"
- Next in thread: Jon Knight: "Re: Proposed solution to url: prefix problem"
- Maybe reply: Jon Knight: "Re: Proposed solution to url: prefix problem"