Message-Id: <9310290145.AA04930@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 28 Oct 1993 21:45:32 -0400
In-Reply-To: "Fred Swartz"'s message as of Oct 28, 18:52
To: "Fred Swartz" <fred.swartz@umich.edu>
Subject: Single protocol for UR*?
[ Fred wrote: ]
> > From: Peter Deutsch <peterd@bunyip.com>
> ...
> >Actually, I don't think I'm advocating chaos, or that
> >chaos will result. I'm trying to be realistic and get on
> >with it.
>
> Interesting, I thought _I_ was trying to be realistic and
> get on with it.
Please don't anyone misunderstand my remarks. I believe
we're _all_ trying to get on with it. This is my own
particular way of doing that and I'm merely trying to
persuade others to my point of view. Yeesh, I seem to be
offending everybody this week... :-)
> >Besides, isn't the whole point of the URL work to allow us
> >to create standard access method libraries?
>
> That wasn't my understanding, although it's a good idea.
> Are you saying suggesting that all URN operations must
> be a subset of one or more existing protocols?
I was probably a little too glib, but yes if at all
possible I'd much rather see URNs (and global URLs)
deployed without our having to develop still another
protocol. I don't think we need it and I think the effort
would bog us down for months, if not years.
At the same time, I think the fight involved in selecting
just one existing protocol would also take longer than
agreeing to an architecture that would allow more than
one, with a goal of promoting Darwinian selection to
choose just one. Just one data point up here in the cold
north.
. . .
> >For the record, I'll go along
> >with whatever the community decides, and I believe that
> >the others would to, but to get to the point were the
> >final decision is made and everyone signs off on the final
> >decision would take a lot of wailing and gnashing of teeth
>
> You're right, it will take more work. I don't think anyone
> is looking forward to the work, but the alternative seems
> even worse.
Why? We currently share information via HTTP, Gopher,
Prospero and a a number of other protocols quite
successfully. Each is adapted to a specific "Internet
ecological niche" and each has its strengths and
weaknesses. If we can agree on a standard data format, why
should I care whether you picked up the record via Gopher,
ftp, WHOIS++ or Prospero?
To me there is no one clear leader for this application,
and even if there was we'd have to convince the people
responsible for _all_ URN and URL information to make the
same choice. I just don't see it happening. We might as
well try to convince either a) all Gopher users to convert
to WWW, or b) all WWW users to convert to Gopher.
> >I claim we're looking for the 85 percent solution (that
> >is, if I can answer my questions 85 percent of the time,
> >we have a successful system). To me, getting there quickly
>
> Oh, that's great -- URNs that you have an 85% chance of
> resolving. . . .
Actually, that's my target for the first year. I suspect
that's better than archie does now when you go looking for
something and people seem to think archie is a success. In
a world where you don't control the data I doubt we can do
much better in the short term.
Of course I'd like more, but let's set a first goal...
> . . . Just exactly what do you plan to do with
> the URNs that Rob currently produces? Or those that
> I would produce?
I plan to write my clients such that I'd be able to reach
either of your servers, if possible. I trust that like
most servers of information, you both would want to see
your information actually used and will thus switch to
whatever is the defacto standard, once it starts to emerge
(assuming the standard you're using at the start isn't the
most popular). I'll say right now that I don't see
supporting X.500 in our first release, but if that's the
one that 85 percent of the community are using a year from
now you can be sure I'll add it in, despite how I feel
about that particular protocol.
> . . . I have no problem with using an
> existing protocol (eg, whois++). If you think this
> solves the problem, please suggest a subset of it
> that will do the job. Let's see if there's any real
> opposition -- I don't think there will be.
Actually, the WHOIS++ protocol is, I believe, simple
enough that you don't need a "subset". Any conforming
implementation should be up to the task now.
Still, I'm afraid I'm more pessimistic about resistance
among other parts of the community. I guess we'll see...
> >in today's world means supporting more than one protocol.
. . .
> No thanks, I don't want to support every conceivable
> protocol on my mac; there are too many that could
> be warped into URN service.
I'm not suggesting that we will have to. I'm suggesting
that even if we declare a "single universal protocol" it
wont mean that we'll get my target of 85 percent coverage
(witness the history of X.500). The only way I think this
will work is to let each person us the tools they have or
want to obtain.
> I understand your desire to get on with this. But I think
> freedom to use any protocol one wants will make URNs
> very unreliable -- 85% success on resolution
> is not acceptable.
Realistically, we're not going to do much better in the
startup phase. There will be dead URLs, servers coming and
going frequently, naming authorities that come and go.
Actually, I think that 85 percent reliability is a pretty
good target for the first year or so.
> I'm hoping that a simple protocol proposal can come
> out of IETF -- sorry I won't be there to help (or
> hinder). I'll be happy with any reasonable proposal.
> Maybe it will need some tuning, but I think people
> could get started using it right away.
I do apologize for my earlier misunderstanding. As I
explained to Mitra, I thought such calls were for a _new_
protocol. If all you're asking for is an endorsement of a
single existing protocol I certainly don't object. I just
don't have your confidence that it will be enough to allow
us to get on with in. We'll see.
- peterd
--