FWD: SGML URC spec comments (3/4)

Ronald E. Daniel (rdaniel@acl.lanl.gov)
Fri, 23 Jun 1995 12:52:16 -0600

From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Message-Id: <9506231252.ZM5744@idaknow.acl.lanl.gov>
Date: Fri, 23 Jun 1995 12:52:16 -0600
To: uri@bunyip.com
Subject: FWD: SGML URC spec comments (3/4)

This is Brian's reply to my reply.

--- Forwarded mail from Brian Behlendorf <brian@organic.com>

Date: Fri, 23 Jun 1995 01:39:51 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
Subject: Re: Agent-mediated access (was Re: Criticism of Kidcode...)
To: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>

On Wed, 21 Jun 1995, Ron Daniel Jr. wrote:
> Thanks for the quick turnaround on your comments. May I have your permission
> to forward your message to the URI list?

Um, sure, if it doesn't expose my ignorance too much :)

> > 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.
>
> Yeah, GET would be the clean choice, I just recall having argument length
> problems with it. I haven't tested any of the new servers for such problems.
> Do you know what the limits are for Apache?

There's a new version being tested that does away almost completely with
static memory allocation, meaning it could be as long as needed, I
think... but there's still limits in caches and proxy servers that need
to be considered. Ugh.

> Hmmm. I don't see URCs as analogous to SOAs, at least as far as I know about
> SOAs. An SOA implies authoritative information. I don't regard URCs as
> authoritative. Which is more authoritative - the publisher's URC for a
> resource, the Library of Congress' (which will be prepared to a higher
> standard), or any of the other URCs that can exist for a resource. This is
> related to a later question of yours about non-publisher supplied metadata.

This is true, however I need a way to tell if a URC I find is a recent
copy, is still "fresh", yes? I guess that's not much different than
asking a proxy asking a server if a given HTML document is fresh (by
sending an if-modified-since request)....

> This issue keeps coming up, so I am not doing a good job explaining that
> anyone who wants to can establish a URC for a resource. It is just a question
> of how to find it.

Aaah, okay. Now the SOAP solution becomes clear.

> The publisher's URC is the "default" URC for a resource
> since under most URN models, the publisher's name is used in the resolution
> process. However, I could have a browser that talks to a particular
> URC resolver by default, such as the one at the schools firewall that
> snarfs the PTA's URCs nightly. I could use a URL to connect to OCLC's
> URC server, give it a URN, and get their URC for the resource.

Okay, that all makes sense.

> If the VRML folks define a naming scheme, and basic URCs for common
> objects, VRML developers could use those names, provide URLs for their
> own objects, and away you go.

It's the naming scheme that I'm unclear on, but I need to read more URN
stuff I suppose. For the time being we'll be setting up an object
hierarchy under http://www.vrml.org/objects/ or some such, with the hope
that this resource will be replicated to large servers elsewhere.
i'm supposing from a quick glance that a generic teapot might be
something like:

<URN:vrml:www.vrml.org:teaport>

?

> Have you seen the PRDM work out of Stanford? Take a look at <URL:http://
> www-diglib.stanford.edu/rmr/TR/TR.html> if not. This is the sort of
> annotation system that I have in mind.

I've had a lot of conversations with Christian Mogensen about stuff like
this. I definitely think this is the right direction. In fact, I hope
they're writing a Java front end to handle the extra GUI for these
functionalities. While at HotWired I tried to wrestle with this for HW's
conferencing system, and even came up with a cool design using a LINK
HTTP method, but obviously the inability to change or influence client
extensions to support this made it imposible for that situation.
However, with Java...

> > Compelling applications! That's all you need, history tells us :)
>
> True, quite true.

I'll do my bit to get this into web sites we build, as long as the
clients are built by someone!

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

---End of forwarded mail from Brian Behlendorf <brian@organic.com>

-- 
Ron Daniel Jr.                email: rdaniel@acl.lanl.gov
Advanced Computing Lab        voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011      fax: (505) 665-4939
Los Alamos National Lab        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    tautology: "Conformity is very popular"