# Re: Yet more URI/URC

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Apr 1994 22:25:59 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Previous message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Maybe in reply to: Terry Allen: "Yet more URI/URC"
- Next in thread: pays@faugeres.inria.fr: "Re: Yet more URI/URC"

    Message-Id: <9404300226.AA13939@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Apr 1994 22:25:59 -0400

    In-Reply-To: Larry Masinter's message as of Apr 26,  9:38

    To: Larry Masinter <masinter@parc.xerox.com>, hoymand@gate.net

    Subject: Re: Yet more URI/URC

Hi Larry,

[ You wrote: ]
. . .
> I think this is a useful discussion. Some protocols (http in
> particular) provide a mechanism to find information about size,
> format, cost, and language when you have located the resource.

As does Prospero, gopher+ and WHOIS++. This seems to be a
general need for such metainfo that each group has
rediscovered independently.

In fact, as I look at what is happening with Gopher+ and
HTTP, there does seem to be convergence of protocol
functionality going on. In fact, once everyone realizes
then importance of separating out the browsing protocol
from the display/markup language, I think the present
debate about the relative merits of gopher and WWW will
end. There are other, better contenders for markup
languages than HTML that will be arriving soon (such as
Acrobat's PDF) and I don't see much difference between
HTTP and gopher+ as browsing protocols.

> Other protocols (ftp in particular) have no such mechanism currently
> (although IAFA information might provide it).

The static anonFTP model will be with us for a while, but
the trend here seems to be towards a browsing model
(gopher/WWW) and so this problem is fading.

> I want to consider the position that we abandon any requirement for an
> independent service that provides meta-data that isn't associated with
> a particular location of a resource.
>
> In principle, it would be nice to have such a beast, but in practice,
> it is impractical and not implementable, which is why we're going
> around in circles.

I'd have to disagree with you on this one. I think what we
need to do is agree upon the tasks we're trying to solve
to allow us to discuss specifics (which is why I like
functional specs and concrete examples) but I see no
reason to think that a general Internet publishing agent
can't be built. Such an agent would be under the control of
an individual author and would serve a variety of info
about the things that person publishes. It could be
queried for URL info, citation info and so on. Anyone with
a copy of Patrik's WHOIS++ server and the will could build
one of these today. Maintenance is still an issue, since
to do it right would seem to imply some environmental
support for registering and maintaining info, but that's
implementation, not architecture.

We're currently working on a project that includes just
such a beast as one component and should be able to report
more specific results in a few more months. In the
meantime, we're proceeding on the assumption that it will
work when we're done and see nothing in the current URN
discussions that scares me off here...

- peterd

    --
    -----------------------------------------------------------------------------
       "What do thay got, a whole lot of sand? We got a hot crustacean band!
            Each little clam here, know how to jam here! Under the Sea!"
    -----------------------------------------------------------------------------

- Next message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Previous message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Maybe in reply to: Terry Allen: "Yet more URI/URC"
- Next in thread: pays@faugeres.inria.fr: "Re: Yet more URI/URC"