Re: URL-Reference / "empty URL" question

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

Received: from cnri by ietf.org id aa07594; 13 May 97 1:16 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa02289; 13 May 97 1:16 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA08790 for uri-out; Tue, 13 May 1997 01:02:10 -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 BAA08784 for <uri@services.bunyip.com>; Tue, 13 May 1997 01:02:06 -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 BAA18218 for <uri@bunyip.com>; Tue, 13 May 1997 01:02:03 -0400 (EDT)
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <18090(2)>; Mon, 12 May 1997 22:01:29 PDT
Received: from bronze-208.parc.xerox.com ([13.0.209.122]) by casablanca.parc.xerox.com with SMTP id <71928>; Mon, 12 May 1997 22:01:10 PDT
Message-ID: <3377F594.1FB5@parc.xerox.com>
Date: Mon, 12 May 1997 22:01:08 PDT
From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: Klaus Weide <kweide@tezcat.com>
CC: fielding@ics.uci.edu, uri@bunyip.com
Subject: Re: URL-Reference / "empty URL" question
References: <Pine.SUN.3.95.970512144020.17794C-100000@huitzilo.tezcat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

>  <A NAME="top">Top<A>
>  ....
>  <A NAME=link-1" HREF="http://a.host/a.file.html"    >link one   </A>
>  <A NAME=link-2" HREF="http://a.host/a.file.html#top">link two   </A>
>  <A NAME=link-3" HREF="#top"                         >link three </A>
> 

> (At least with the Lynx code currently under development,) activating
> ("following") link-1 will result in a new network request.  Activating
> link-3 will not, but will just change the view of the current document,

> The question is, what happens with link-2 - should following it result
> in a new request, as for link-1, or just repositioning within the
> already loaded document as for link-3?

We actually discussed this at length, and came to the design that
we intended to write, where (as you assert) link-2 is similar to
link-1 and not link-3, and should cause a new "dereference".

The way I think of this, link 3 doesn't
doesn't refer to "the resource at the URL of this document" but really
"my local copy in this here buffer, file://localhost/blah/".

I haven't figured out how to make this any clearer in the draft, though.

> My reading of the draft is that they do not resolve to the same thing,
> and that implementing things this way (first "resolve" a given
> URL-Reference into a "full" URL-Reference with a non-empty absolute
> URL, then do all further processing with that) actually contradicts
> the draft - although it probably is used by a lot of implementations.

Are you sure? I suppose we need to survey interoperable implementations
to see.

Larry