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"