# Re: A couple of comments for the list...

Peter Deutsch (peterd@bunyip.com)
Thu, 24 Feb 1994 20:59:33 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Larry Masinter: "Re: URN to URC scenario"
- Previous message: Masataka Ohta: "Re: Selecting Languages"
- Maybe in reply to: Peter Deutsch: "A couple of comments for the list..."

    Message-Id: <9402250159.AA13243@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Thu, 24 Feb 1994 20:59:33 -0500

    In-Reply-To: Mitra's message as of Feb 24, 16:22

    To: Mitra <mitra@pandora.sf.ca.us>

    Subject: Re: A couple of comments for the list...

Hi Mitra,

[ You wrote: ]

> Peter
>
> I have to disagree on a lot of what you said.

Well, I knew _somebody_ would! :-)

> I think people didnt sign on to URL's because they were not frozen EARLY
> enough, we know that was the case with Gopher, and WAIS and Prospero
> would probably have used real URL's instead of their own if they had been
> frozen. By waiting we ensure that the "U" in URL is meaningless and end
> up with competing - incompatible schemes.

Actually, all of the systems you named were initially
developed _before_ the work on URLs began at the IETF (and
you can add archie to that list, too) so it's not really
fair to blame their failure to use a standardized URL on
the slow pace on the URL doc. History actually happened in
a different order there.

In fact, I think just about all of the developers of the
systems you named were active in the early meetings to
standardize URLs (in particular, those held at the San
Diego and Boston IETFs) and as far as I know all of the
principals have pledged to integrate the URL work into
their systems once the draft is frozen. It's just that all
of us have waited for the final draft before changing our
own systems and that draft has had the gestational period
of several elephants.

The issue to me seems not to be whether we should have
persuaded all of these groups to use a standard URL, they
all have said they will. The question is why did that
draft take so long to produce and if there was a problem
with the process will we repeat the mistakes the second
time around? (Note, I'm assuming that we could have done
the URL doc faster if we'd taken a different approach. I'm
happy to admit that this may have in fact been something
that, like child-birth, will take the same amount of time
no matter how many implementors are assigned to the task...)

I think it fair to say that everyone at the first couple
of URL-related meetings (the Living Docs BOF in San Diego,
the first URL meeting in Boston, etc) were in full
agreement on the utility of URLs, and everyone wanted
agreement fast since we all wanted to start using them in
our systems as quickly as possible. Where _I_ think we
got into difficuly was that we attempted to jump a step by
adopting an existing document (Tim's description of WWW
URLs) as the basis for the working group's draft rather
than write one from scratch because none of the other
groups had actually gone through a burn-in period
themselves and did not have their own distinct proposals
to offer, only some perceived needs and desired traits.

This had several unforseen consequences, not the least of
which was that as the rest of us firmed up some of our
requirements, modifying the existing scheme proved
difficult since it didn't exist as a consensus of the IETF
working group, but rather of the WWW developer community
and thus many of the underlying assumptions were already
frozen.

I may of course be wrong on this, but I think if we'd had
started with a blank slate and worked consciously on
building the amalgam of Prospero's needs, Gopher's needs,
archie's needs, WWW's needs, WAIS's needs and so on,
consensus might have come faster. Instead, I perceive that
there was certainly amount of "but that's how the WWW
community does it", assuming that their experience was
directly transferable to the work of others in all cases.
I suspect that there was thus somewhat less of an ability
to make changes to this document for the rest of the
working group than we might have needed or wanted.

Note, this is _not_ intended as a personal attack on Tim.
Something similar might have happened if _anyone_ else's
document had served as the starting point, although we'll
never know. The point is, by not having a burn-in period
where each group tried out a different approach we found
ourselves arguing theoretical vs applied and "installed
user base" vs "what we think we'll need in two years".

At the same time we here at archie Central certainly felt
constrained not to deploy a competing scheme since it
would violate the consensus already reached at such cost
in blood, sweat and tears. I'm sorry now we didn't try our
own format two years ago to see what would have really
mattered to us and what we'd have learned. We'd have been
on firmer ground in the ensuing debate.

This is one reason I'm trying not to jump up and say "Use
WHOIS++ for URN dereferencing and be done with it!". I'm
just not sure that we know enough about the task at this
point to claim in fact that WHOIS++ is the answer. I
_think_ it will do everything I can forsee needing in this
application (I certainly had the application in mind while
I worked on my part of it) but I'd rather not have
everyone agree with me just yet.

There's also the whole resource discovery question of how
to find the appropriate URN->URL server, which is being
addressed now on this list. Is anyone willing to go on
record as declaring the DNS TXT record approach as the
most suitable for the general case for now and every more?
That seems premature to me.

To me, the issue is whether we really know enough about
what URNs are supposed to look like, do, etc to fully
specify them correctly at this point. Perhaps it didn't
matter as much with URLs as there was already some
experience with a variety of browsing systems, indexing
and info serving systems, etc, even if noone except the
WWW people had their own specific format to suggest at the
start. Even so, in that case it's taken two years to get
close to rough consensus, and there's still some rough
edges to file off.

In the case of URNs we now have a fair amount of theory
but precious little implementation experience and I'm thus
concerned that we don't freeze again too soon by choosing
the first system to get to the starting gate. I'm
personally convinced that's what we did with URLs and that
it hurt us.

> On the question of multiple access protocols, again I couldnt disagree
> more - I dont care nearly as much whether its DNS, Whos++, or HTTP as I
> care that there is one and only one protocol used to resolve URN->URC's.
> No way am I going to implement all three, I guess other client writers
> will do one of two things, either a) implement nothing until its settled,
> or b) implement their own protocol, for use only within their own system,
> and ignore the IETF.

I think we agree on the need for one and only solution in
the long run (although I seem to have less of a problem
with living in a multiple protocol world than you right
now). The issue seems to be how we get there from here.

I'm suggesting that we ask a few hardy pioneers to choose
their path and explore it for a little while. In doing so
we have to make it absolutely clear that the pioneers are
merely working their way across the prairie and over the
mountains to scout out a road for the rest of us. We are
_not_ automatically saying that whatever path they follow
will become the route for the new Interstate highway that
will follow in their wake.

I really don't think we want or need to end up with a
system with multiple protocols in the long run (well, not
for URN->URL dereferencing. I'm happy to have multiple
ways to find a URN server). I _am_ suggesting that we
should encourage a bit of experimentation before, not
after we've frozen the spec this time.

After all, I did hear people argue against making changes
to the URL document because of the impact it would have on
the installed user base of WWW, which I had big problems
with. I'd rather short-circuit that process with a clearly
defined period of experimentation where anything goes,
then start to build consensus once we've tried things for
a few months. I think in the long run, we'll save time
and get a better result.

> The IETF - as I see it - is supposed to be in the business of putting
> together protocols and standards, so that implementers can build
> interoperable applications - we dont need another three years of waffling
> while we argue between marginally different versions of the same thing.

We're certainly in agreement here. My claim is that by
initiating and encouraging a period of experimentation in
which it's made clear what the ground rules are we can
shorten, not lengthen, this period. After all, there is a
fine IETF tradition of using competing "technology teams"
to arrive at a single solution (witness SNMP, IPng, et.al.).

The way I see it, we're somewhat more fortunate than the
IPng guys in that we wont have to ask every single user
and system to convert every time we want to change the
experiment. Thus, in my mind there's nothing wrong with
putting up a couple of attempts, say a WHOIS++ based
service and one or two more for URN->URL conversion, with
perhaps one set of servers found using the DNS/TXT
method, another with a central indexed archie-like
approach, and so on.

We can certainly look at trying a centralized index
approach at resource discovery as we've now got multiple
information collection capability working in archie, with
an interal WAIS search engine capable of doing the
attribute searching and the pieces needed to gather IAFA
scripts in prototype form. We've been tied up getting an
index of gopherspace up and running for the next upgrade
but that's now almost ready for full deployment and we can
look at the next step, which will be a serious push for
building IAFA-based collections for general use. In
addition, we've also seen several different WHOIS++
implementations reach pilot stage, in particular Rickard's
version seems to have a lot of effort put into it, so the
tools for experimentation seem to be at hand.

I'm now suggesting that we specifically task the group to
try things out, with a conscious realization that we're
experimenting, not standarding here. I'm asking for an
active period of experimentation with a view of gaining
some real world experience in a variety of applications
before trying to make any final decisions. This may be
happening anyways, and if so I'd like to hear some
comments about the lessons people are learning. I've been
so busy with other things that my own experimentation has
been minimal for the past few months and we have an IETF
coming up soon.

At the same time, now that the URL saga seems to be mostly
behind us it seems like a good time to do a reprise and
try to learn some lessons from the experience. In my usual
long-winded fashion, that's all I'm asking for...

- peterd

    --
    ---------------------------------------------------------------------------
       "The future belongs to neither the conduit or content players, but
        those who control the filtering, searching and sense-making tools
        we will rely on to navigate through the expanses of cyberspace."
                                        - Paul Saffo, (_Wired_: March,1994)
    ---------------------------------------------------------------------------

- Next message: Larry Masinter: "Re: URN to URC scenario"
- Previous message: Masataka Ohta: "Re: Selecting Languages"
- Maybe in reply to: Peter Deutsch: "A couple of comments for the list..."