W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

a BOOKMARK tag ??

From: Shel Kaphan <sjk@amazon.com>
Date: Mon, 10 Jul 1995 15:33:44 -0700
Message-Id: <199507102233.PAA04862@bert.amazon.com>
To: ben@hearstnewmedia.com
Cc: www-talk@w3.org
Ben Adida writes:
 > Hi,
 > 
 > 	I am currently working on developing a web site which uses a
 > good bunch of pages generated on the fly. Because of this, a lot of
 > URL's don't work if people return to them later on.....
 > 
 > 	I'm thinking that a useful new tag could be something like :
 > 
 >  <bookmark href="http://foo.bar.com">
 > 
 > 	which would tell the browser to bookmark that URL instead of
 > the one in the actual Document URL box at the top of the
 > screen.... What do you think ??
 > 
 > 
 > 	Ben Adida
 > 	ben@hearstnewmedia.com
 > 	Web Site Developer and System Administrator
 > 

I'd rather see this done using a header defined within HTTP, rather
than something specific to HTML.

There is presently no header that identifies the resource being sent.
(For some purposes, it might be sensible to use the URI header for
this, though the design of the URI header biases it to be useful for
those cases where the resource *isn't* being sent along with the
response).

If there were a standard header specifying the URI of the enclosed resource,
that would enable several different pieces of functionality.  Some
option associated with it could do what you are requesting.  However,
there's a possibility of abuse with this -- do you really want to give
server operators control over your hotlist?

I'd like to see a header for identifying the enclosed resource, for
the purpose of ensuring "cache coherency" in clients.  If several
different request-URIs are sent, each resulting in different server
actions followed by returns of the *same* resource (a practical
scenario I have had to engineer my way out of more than once...), each
copy of the returned resource will be cached separately by the client
(as most clients cache using the request-URI as a key).  For dynamic,
time-varying resources, this leads to the possibility of being able to
view stale copies of the resource if you "follow a link" that returns
an incorrectly cached copy of the resource.

--Shel Kaphan
  sjk@amazon.com
Received on Monday, 10 July 1995 18:39:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT