From: "Ron Daniel Jr." <firstname.lastname@example.org> Message-Id: <9506231052.ZM833322@macrdan.acl.lanl.gov> Date: Fri, 23 Jun 1995 10:52:48 -0600 To: email@example.com Subject: FWD: SGML URC spec comments (1/4) Offline, Brian Behlendorf and I talked about URCs, KidCode, and related topics. He had some comments and questions about the SGML URC spec. In order to spur discussion of that draft, I asked him if I could send that material to this list, and he graciously agreed. Here is his message, please excuse the bits that do not seem directly relevant to this list. A couple of generations of replies will follow. Ron --- Forwarded mail from Brian Behlendorf <firstname.lastname@example.org> Date: Tue, 20 Jun 1995 21:01:31 -0700 (PDT) From: Brian Behlendorf <email@example.com> Subject: Re: Agent-mediated access (was Re: Criticism of Kidcode...) To: "Ronald E. Daniel" <firstname.lastname@example.org> On Tue, 20 Jun 1995, Ronald E. Daniel wrote: > I took a look at your "community content control" page. The approach > of school putting their browsers behind a firewall so that all accesses > can be filtered is pretty strong, and fits well with future URC > mechanisms. Thanks! I like being forwards-compatible :) More importantly it doesn't break the fundamental OO philosophies behind the WWW link model. > BTW, your reply to Peter Deutsch's message indicated a strong interest > in URCs. I would be very interested in your evaluation of the current > draft of the URC spec: <URL:http://www.acl.lanl.gov/URI/URCspec/>. Looking at it now... for some reason I must have dropped off email@example.com a while ago, because I didn't see any notice of this nor much discussion about URI's. It's a little bewildering, as I'm sure some of the questions I have might have been answered by having been on uri@bunyip (are there archives anywhere?) so I'm not sure where to start. A few short notes: section 6.1 says > The N2 and L2 operations are sent as HTTP GET requests. The C2C > operation is sent as an HTTP POST request since it is likely to be > quite large. Well, in the object-oriented model, "POST" is not just a way to send more information up the pipe in the request. "POST" is defined to be an action which modifies a resource or creates a new resource; thus, the request and the response is never cached automatically. Meanwhile, "GET" is defined to be idempotent - it doesn't change anything, and thus it can be cached and is considered "safer". Now, you and I know that there are scripts out there that violate this - I've built several myself. However, the object-oriented model is something we should try and keep sacrosanct, in specification at least. Where does "x-dns-2" come from? I like the "Server: Apache 2.7" header :):) > Synchronization: Synchronizing the content of multiple URC servers is > outside the scope of this specification. This is bad - I didn't see anything (on first glance) that deals with expiration or redundancy. DNS works only because of this. Or maybe this is just for a different spec? Hmm. I see URC's as analogous to DNS's SOA records, so I don't think it would be inappropriate here. Some things I didn't see, and please let me know if they are elsewhere: 1) some mention of or a pointer to or a description of a methodology for "common objects". This is not at all important to the document world, but for VRML it's crucial. VRML scenes can be composed of many small highly cacheable standard objects - for example, I'd like to be able to build a kitchen by referencing a "teapot", indicating I don't really care much abut the teapot except that it's the most local copy around and is scaled to fit in a particular bounding box. 2) Using URC's to contain non-publisher-supplied metadata, particularly comments and "global annotations". In other words, I think URC's would be the perfect vehicle for allowing the WWW to become writeable - so that any page I visit I could attach commentary to (or more precisely, create a child document, host it on a server *somewhere*, and have the URC contain a child that points to it). Perhaps this is also out of the scope of this document, and is a particular and specific application of a new attribute set. I would like to see it made part of the default, though, if only because it seems rather significant to me. The right to attach these comments should *not* be controlled by the author - the author should also not have to supply the mechanism by which these are attached. In some ways, this is something like a massively decentralized USENET, where *every* URN is a newsgroup. Other than that, the concept of named attribute sets defined by SGML DTD's (with a default for speed) is solid, and the specification looks professional. It is a lot to swallow all at once... it would be nice if there were some implementation scheme which had a tiered incremental approach so that it's not so abrupt that people ignore it. Compelling applications! That's all you need, history tells us :) Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- firstname.lastname@example.org email@example.com http://www.[hyperreal,organic].com/ --- End of forwarded mail from Brian Behlendorf <firstname.lastname@example.org> -- Ron Daniel Jr. email: email@example.com Advanced Computing Lab voice: (505) 665 0597 MS B287 fax: (505) 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM 87545 tautology:"Conformity is very popular"