Subject: novel use of URL space

From: George Michaelson <[email-masked]>
Date: Fri, 28 Jul 2000 13:31:45 +1000

I found this via the tasty bits site:

	http://rfc2826.x42.com/ (try for any rfcXXXX)

The idea certainly isn't copyright, and it has a compelling simplicity
which makes me think the IETF could consider adopting it when it
promotes 'canonical' URLs for accessing the standards.

Its probably not such a good idea for the drafts mind you!

comments?

	-George
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Jul 2000 20:58:22 -0700

> http://rfc2826.x42.com/ (try for any rfcXXXX)

operationally, useably, ... how is this more useful than putting the rfc
after the slash, e.g.

  http://x42.com/rfc2826

what's it get me, other than less dns hits?

ramdu

---

From: George Michaelson <[email-masked]>
Date: Fri, 28 Jul 2000 14:17:57 +1000

http://x42.com/rfc2826

you can do a rfc-centric  implementation of further functionality so that
its document/context or document/markup or document/cross-ref.

sure, you can do all that via a cgi, but this way, its document-centric
ie all the sub-features if you do them, hang from the name of the document.

Its not *that* neat an idea, but it had some attraction to me. Actually
the wider idea of embedding information in DNS like that also seems to be
either evil or sweet, depending on how you look at it.
  
costs heaps of overhead for sure!

-george

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 01:51:17 -0400

> operationally, useably, ... how is this more useful than putting the rfc

you can set up different sets of mirrors for each RFC.
(with different maintainers and/or different TTLs for each set)
you can delegate each RFC to a different DNS zone
(not so useful for RFCs but might be useful for other kinds of documents)

so for instance you can replicate a document to several mirrors
(each represented by an A record) and have the A records for 
that document get updated each time a new replica is created.  
(or each time a replica is destroyed). that way, you have a 
high probability that the mirror server you go to to fetch a
particular document will actually have the document you want.

yes, you can more-or-less do that with HTTP also, using redirects,
but the lookup overhead is higher with HTTP, and DNS has better
support for replication between servers.    so it's probably 
more robust to us DNS

Keith

p.s. otoh, there are subtle differences in the way that relative URLs work 
between the two cases.  if a document is referenced as

http://rfcXXXX.x42.com/ 

then a relative URL of the form "rfcYYYY" presumably won't 
work right (absent the server for XXXX generating a redirect) 

but if you reference it as

http://x42.com/rfcXXXX

then "rfcYYYY" presumably will work if the server mirrors all 
of the RFCs.

so putting the document ID within the DNS name sort of defeats
relative addressing.  whether this is a bug or a feature depends
on your point of view.

---

From: John Stracke <[email-masked]>
Date: Fri, 28 Jul 2000 11:59:10 -0400

> ie all the sub-features if you do them, hang from the name of the document.

You can do that with CGI, too.  If you request
http://example.com/foo.cgi/bar/baz, foo.cgi gets run with PATH_INFO set to
"/bar/baz".

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |We must be devious, cunning, inventive... too|
[email-masked]|bad we're us.                                |
\==============================================================/