Re: URL-Reference / "empty URL" question

Larry Masinter <masinter@parc.xerox.com> Wed, 14 May 1997 16:13 UTC

Received: from cnri by ietf.org 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 services.bunyip.com (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 (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA00212 for <uri@services.bunyip.com>; Wed, 14 May 1997 11:49:59 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id LAA04381 for <uri@bunyip.com>; Wed, 14 May 1997 11:49:41 -0400 (EDT)
Received: from bronze-208.parc.xerox.com ([13.0.209.122]) by alpha.xerox.com with SMTP id <17933(2)>; Wed, 14 May 1997 08:48:39 PDT
Message-ID: <3379DED3.424F@parc.xerox.com>
Date: Wed, 14 May 1997 08:48:35 PDT
From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
CC: kweide@tezcat.com, uri@bunyip.com
Subject: Re: URL-Reference / "empty URL" question
References: <01IIUUP7CVEE00A3D1@SCI.WFBR.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

The way I think of it myself is that when you interact with
a resource on the network ("http://whatever.com/blah")
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
   "this:"
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:".

Regards,

Larry