RCDS

 + emphasis on reliability
node2

LIFN: "fully specific" resource, ala TimBL's PUT constraint
 (also read-only?)

	should be able to compute a LIFN from an artifact
		with high probability that you'll compute
		the same thing as somebody else
		(e.g. MD5)

Can RCDS work with dynamic data? (e.g. computation services?)
Thinking about it:
dynamic data

SONAR: status? WG? whence?
Does RCDS rely on ubiquity of SONAR?
sonar

"In most cases, the resolution process is expected to cost one extra
long-distance round-trip (to an RCDS server), and one extra local
round-trip (to a SONAR server), as compared to the name-to-address
lookup for a URL."


assertions: zoiks! This is PICS!

excerpt
"the server keeps a copy of the last request id and the last result of
any update call from a particular client."

	Yikes! In stable storage? That looks like a BIG database!
	How long does it keep this stuff for? Can it throw
	them away after 4 minutes (or some multiple of the
	maximum lifetime of an IP packet?)

	How are clients identified? What about multiple clients
	going through a shared proxy?

shared secret/MD5 authentication... hmm... probably good enough.

``A states that, as of time , the attribute named N of the resource
named U had value V, and that this value is expected to be valid until
time .''

	space of attribute names? values?


Any concept of "volumes" or "collections"? or must each file
at a mirror be registered individually?


node14
fault tolerance via reduncancy: check. But what about consistency?


I don't grok this:

excerpt
RCDS servers are associated (via the URI resolution process) with a
particular subset of URI-space; it is assumed that the official RCDS
servers for a resource are maintained or authorized by the owner of
that resource. The owner or an authorized party must therefore provide
permission and authentication credentials to a party before it can add
assertions, certificates, or locations to an RCDS database. This
provides a mechanism to ensure that only authorized catalog
information or replicas are listed in the official servers. Nothing
prevents an unauthorized third party from establishing its own RCDS
servers, but (barring attack of the resolution system) those servers
must be explicitly configured by the user - they will not be found by
a normal URI resolution process.


data model
"No particular data model is assumed," not true: it's flat
name-value pairs.


impl
"The RCDS testbed servers are being used to keep track of
widely-mirrored network resources, including the Linux operating
system and related software, the Internet RFC and Internet-Drafts
repositories, the netlib software repository, and others. This
provides a means to test the use of RCDS with resources that have
large numbers of replicas."

Cool!

===================
framework

The NAPTR key mechanism: a NID doesn't stand so much for
a "naming authority" in the institutional sense as
a "naming convention" in the syntactic sense: it's a
REGEXP rule for translating arbitrary names into
domain names. Cool!


*** on the netscape urn: hack.

===================
trivial http

2.0 General Approach:
=====================

The general approach used to encode resolution service requests in THTTP
is quite simple: 

    GET /uri-res/?  HTTP/1.0

For example, if we have the URN "urn:foo:12345-54321" and want a URL,
we would send the request:

    GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0

3.5  N2C (URN to URC):
----------------------

URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself.
The description might be a bibliographic citation, a digital signature,
a revision history, etc. This draft does not specify the content of
any response to a URC request. That content is expected to vary from
one resolver to another.

The format of any response to a N2C request MUST be communicated using the
ContentType header, as is standard HTTP practice. The Accept: header
SHOULD be honored.

excerpt
Sample Query 

(For more complex queries and responses, see Appendix B.) 

Imagine a rating service, identified by the URL
http://www.labels.org/Ratings, which decides to run a label bureau to
dispense (at least) its own labels for documents. The following sample
request, made to the HTTP server www.labels.org, is illustrative (line
breaks are inserted for presentation purposes only):

GET /Ratings?opt=generic&
             u="http%3A%2F%2Fwww.questionable.org%2Fimages"&
             s="http%3A%2F%2Fwww.gcf.org%2Fv2.5"
             HTTP/1.0

============
URN syntax

on case insensitivity: rather, specify the canonical
case, and deprecate the other.


===============
URI data model:
	mailto: stuff

interface Resource{ /* Anchor? WebSpacePoint? */
	static Object parse(String uri, Interface if)
};

resource interfaces:

interface Value{
	/* aka immediate resources: all information is in the identifer
	(the data: URL)
	100% guaranteed quality of service for GET (0% for PUT/POST/etc.)
	this sort of resource is like the value returned from
		the lisp/scheme (quote) special form (it's typed) */

	/* no methods in this interface: the result of
	binding is the same as the result of GET */

	static Object get(URI i);
}


interface Artifact{
: functional relationship between i and GET(i)
	immutable. LIFNs, cid:
	theoretically, any answer to GET(i) is good
	operationally: consistency problem: what to do if different servers
		report different answers?
		(if there are lots of good replicas, forgery is
		easy to detect: just check against one or a few
		other replicas)

local storage: GET(i) is a function of the state of the local computation
	"local" refers to the trust/consistency boundary
	e.g. about:

remote procedure: GET(i) is a function of the state of a (possibly) remote
			computation
	file:, ftp:, http:
	cgi scripts

remote storage: 
	ala database "entity"
	(CSP?)

synchronized storage: GET(i) is a function of a globally synchronized clock
	adds Last-Modified, If-Modified-Since semantics

-----
analogies to:
	C *p and func()
	lisp SYMBOL, eval SYMBOL, call (func),
		(let) and ?x=2&y=3
	scheme procedures
	smalltalk/C++/objective C/java object
	COM monikers, binding, streams, storage, persistance
		QueryInterface
	CORBA naming, binding, persistance
	files (open/read/write/seek/close)
	database records ("entities" from the literature)
	"firstness", transaction semantics
	publish/subscribe (apple, UNSENET, castanet?)
	knowledge base query

	poetry: influence of receiver context on message