Message-Id: <9310152342.AA14648@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 15 Oct 1993 19:42:48 -0400
In-Reply-To: Tim Berners-Lee's message as of Oct 15, 17:41
To: timbl@nxoc01.cern.ch
Subject: Re: The URN: wrapper and URLs...
Kevin Gamiel <kgamiel@vinca.cnidr.org>,
[ You wrote: ]
> >From: Peter Deutsch <peterd@bunyip.com>
> >Date: Thu, 14 Oct 1993 19:03:51 -0400
>
> >absurdity of requiring that a line start with a TAB, but
> >decided that his established user based was now too large
> >to require them all to change their existing makefiles. At
> >the time there were 16 users. The rest of us have been
>
> When we had 16 users we made quite a lot of changes :-)
But that's my point - proportionally we are at the
equivalent of "16 users" with the current installed base
of users, compared to what's about to happen in the next
two years. If we continue doubling at this rate, we're
talking maybe 15 million more people minimum in the next
year, perhaps 40 million or more in the next two.
Despite how my comments may be perceived, I'm not arguing
change for the sake of change. In fact, whenever possible
we'll support whatever the standard says for a particular
protocol, since our objective is to be useful to our
customers. I am just a little disturbed by the argument
that the current installed base rules out change even
though the IETF working group as a whole endorses the
change. The gopher gang committed to supporting whatever
the standard is, once it's chosen and frozen. The archie
gang committed to supporting it, once it's chosen and
frozen. I'd like to hear a similar unequivocal statement
from the WWW community and I'm not hearing it. Maybe it's
just personality conflicts, maybe there's a communications
gap.
>
> >Put another way, just because one or two systems currently
> >use a non-conformant version of these things should _not_
> >preclude us continuing our efforts to get them right.
> >There are lots more systems coming and if we insist on
> >preserving all prior art then our efforts on UR*s will
> >simply be ignored by future developers.
>
> I agree. But I also believe that if it ain't broken
> you don't fix it just because you didn't invent it.
I agree one hundred percent, but I suspect this is an
issue of interpretation. The WWW community doesn't seem to
perceive a problem with the current format yet at
least some people in the working group do. After all, I
got involved in this thread only because I posted a "me
too" message.
Personally, I'm not particularly concerned about the
specifics of any of these proposals, provided I get
something which I think is: a) buildable, b) usable, and
c) will have some halflife not measured in months. To give
me c), I'd prefer something in which I have some faith
that the design process address everyone's concerns,
produced something that has a certain sense of "artistic
balance" and seems to work. Right now, I'm a little
nervous. I can live with things, but I'm nervous.
Right now we're working to see if the current spec
allows us to do the things we need (such as embed WAIS
ids in Gopher or WWW, as one example we've already
encountered). To be fair, so far we haven't found
something we can't do. I'm just nervous about the process
that got us to where we are and have said so.
I _do_ feel some concern at the reaction of the WWW
community to calls for change. This is not the WWW URL
doc. It is the IETF URI Working Group URL doc and if the
community as a whole agree that a particular item is
needed (yes, modulo rough consensus and working code) I'd
like to see that reflected in the doc.
I'm afraid that calls for a more othogonal design (eg.
having URL: etc in front of each identifier) are being
shunted aside on the basis of installed code base. I just
don't see the problem with accepting the cleaner design,
and grandfathering the established code, since as others
have pointed out the change is just not that big a deal.
More importantly, accepting it shows some respect for the
process (although I accept that the process can't call for
arbitrary change, the wishs of other communities should be
considered).
>
> >There are lots more systems coming that will be using
> >these things. For example, Bunyip will be announcing a new
> >information service in the next few weeks (okay, maybe
> >after Houston) that will have both Gopher and WWW front
> >ends and that will support UR*s whereever possible.
>
> Which is what all the WWW clients do. There are around 16
> products, perhaps twice as many if you look at code under wraps.
But if the group as a whole decided that a change was
needed, would you be willing to incorporate it into the
doc and change your code? The Gopher guys have said yes,
we've said yes, and so on. I'd like to think you'd say
yes, too. Of course, whoever pushes for a particular
change should be willing to defend the cost/benefit
tradeoff but at the end of the day are you willing to go
with the crowd or do you feel that if the group asks for
something you don't agree with you'd refuse to put it into
the document? That's my only real concern here.
>
> > I know
> >of several "real" publishing companies now working on their
> >own online publishing systems that are candidates for
> >these things. There are several companies I know working
> >on commercial clients for the Internet. I admire what's
> >been done to date but I also think there are some kludges
> >and bogosities and we should be willing to not freeze
> >things too early on this.
>
> Fine, but you have yet to come up with something as serious
> as a kludge.
I think you misunderstand my position. I'm not an advocate
for a particular proposal here. I've added my vote to a
proposal that others have endorsed (having a leading
"URN:") but this was not _my_ proposal. I do react
(perhaps overreact) when I see what I perceive to be
intransigence but essentially I have no axe to grind here.
I don't have a competing proposal but I do have concerns
about process.
>
> >Let's not fool ourselves that we're anywhere near done
> >with all of this or that the current nice first efforts
> >define a standard that must be followed by everyone from
> >now on.
>
> This is a little like arguing about reinventing unix
> because now we want to add graphics. We ought to be
> able to leave URLs behind us as a base on which we
> have built. If we keep arguing about punctuation
> we will only delay the advance. Is that what you want
> to do?
I would like to think that URLs will serve us for some
time to come. It may be that we need enough operational
experience with the first generation of this stuff to be
able to define the second, but I do think we should have
something that is a little more orthogonal to start off
with. I also think (as I posted and and argued at the last
IETF) we never ended up with a nice clear set of design
goals and thus are trying to have these things satisfy
conflicting goals without a map.
I can live with the result, but I suspect they wont age
well. I would have thought that a year ago (when I argued
against the double slash, for example as redundent) it
could have been dropped. After refusing to entertain the
notion for a year, you now tell me we've been arguing for
a year, there's an established user base and time's
passing so it's too late to change. That raises concerns
about the WWW community's willingness to participate fully
in the process and makes me somewhat nervous about how
flexible the WWW community is willing to be here.
> There is enough code code which needs writing, products which
> need developing, for everyone to take a share, I hope.
Again, I suspect you misunderstand my motives. I _want_
this stuff done, so our tools can support them. I don't
care about punctuation, as long as they do what we want.
But I also want them to continue to do what we want over
time and thus was disappointed with both the design
process and the result. I fully accept I may be wrong, but
just don't ask me to state I was convinced that the
current format really is the best we could have done.
>
>
> > God forbid that we should preserve that ridiculous and
> > unnecessary double-/ syntax in the URNs as well! I don't
> > object to making it optional to avoid breaking previous
> > code, but it's such a blatant hack that it really offends
> > my sense of artistic balance no end... :-(
>
> This from the guy who introduced the double, triple and
> quadruple colons, balanced by the string "URN" ???!!
Actually, I didn't propose that syntax, Chris did. I
understand he's going to be responding separately, so I'll
let this one pass.
- peterd
--