W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Draft Minutes of HTTP Working Group, 33rd IETF Meeting, Stockholm

From: Martin Hamilton <martin@mrrl.lut.ac.uk>
Date: Fri, 11 Aug 1995 10:10:28 +0100
Message-Id: <199508110910.KAA08963@gizmo.lut.ac.uk>
To: Ted Hardie <hardie@merlot.arc.nasa.gov>
Cc: jg@w3.org, paulle@microsoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, janssen@parc.xerox.com, blampson@microsoft.com

Ted Hardie writes:

| the Internet is over a very slow link.  While the URN to URL resolution
| proposals provide a useful model for long-term work, some very simple
| solutions could work for mirrorinng non-interactive pages even in the
| short term.  A Mirrors: header, for example, could provide a simple list
| of alternate URLS where the same data could be found (much like the lists
| some ftp servers provide when user limits have been reached); the client

Another approach which I've seen suggested would be to have multiple 
HREFs in an HTML anchor.  This would be nice, in the sense that it 
would drop straight through the HTTP layer...  Would it be kosher 
SGML, though ?

Are there any plans to further develop the existing HTML & HTTP 
"HEAD" mechanisms for passing meta-information ?  Methinks it would 
be good to have something along the lines of the "Dublin Core" 
element set [1] in there.  Who knows, this approach might just make 
URCs redundant! :-)

| could then analyze the list and choose mirrors which are closer.  While
| it may be difficult to determine what is "close" and what is "distant"
| in network terms, there are some rules which could be built into the
| clients.  (Actually, a clever server could do the same thing with 
| redirects--read the client's network and domain from its headers and
| issue a redirect to a closer mirror).

The client could ping the servers and choose the one with the shortest round-trip-time ?



[1] <URL:http://www.oclc.org:5046/conferences/metadata/>
Received on Friday, 11 August 1995 12:13:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC