+ 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