Re: URL-Reference / "empty URL" question

Larry Masinter <> Wed, 14 May 1997 16:13 UTC

Received: from cnri by id aa29324; 14 May 97 12:13 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11685; 14 May 97 12:13 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id LAA00224 for uri-out; Wed, 14 May 1997 11:50:03 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id LAA00212 for <>; Wed, 14 May 1997 11:49:59 -0400 (EDT)
Received: from (alpha.Xerox.COM []) by (8.8.5/8.8.5) with SMTP id LAA04381 for <>; Wed, 14 May 1997 11:49:41 -0400 (EDT)
Received: from ([]) by with SMTP id <17933(2)>; Wed, 14 May 1997 08:48:39 PDT
Message-ID: <>
Date: Wed, 14 May 1997 08:48:35 -0700
From: Larry Masinter <>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: Foteos Macrides <>
Subject: Re: URL-Reference / "empty URL" question
References: <01IIUUP7CVEE00A3D1@SCI.WFBR.EDU>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk

The way I think of it myself is that when you interact with
a resource on the network ("")
or even a local file ("file:///c|/downloaded/blah") and
recieve some content from that resource and are viewing
it, the viewer has another implicit resource:

  "the copy of the content that is being viewed now"

Let's give it its own URL scheme
where the scheme-specific part of "this:" is
empty. Then what we want to assert is that URL references
of the form "#xxxx" are *not* relative
to the BASE at all, they're always relative to
to "this:". That is,

    <A HREF="#blarg">...</A>

is equivalent to

    <A HREF="this:#blarg">...</A>

and different from

    <A HREF="file://localhost/download/blah#blarg">...</A>

even when the buffer was read from "file://localhost/download/blah"
in that following a "file:" link might well re-fetch the
data in the case where the file has actually changed.

I know many browsers have built-in URLs for some operations
("about:", "globalhistory:") and vaguely remember some
reference to "back:" and "forward:" somewhere; but what
we need to explain "#blarg" is "this:".