Date: Mon, 28 Nov 1994 13:50:34 -0500
Message-Id: <199411281850.NAA15558@lysithea.lcs.mit.edu>
From: "Karen R. Sollins" <sollins@lcs.mit.edu>
To: uri@bunyip.com
Subject: going too far? (longish diatribe)
<<Ignore the previous version of this - I sent it out unintentionally
incomplete. This is not intended to be directed at any individual but
all of us - me included - as food for thought.>>
I am concerned. We need to walk a fine line. In fact, by looking at
one aspect we have not stepped over it and with respect to another
aspect we are way over; we need to understand better where the
boundary is. The problem is actually 2 problems. First there is the
question of how much background material needs to be in a document
vs. how much the author can assume readers will either know or learn
if they feel the need or interest. (For that we provide references in
our documents.) Second, there is the problem of availability of the
documents.. Consider each problem separately.
About how much should be in a document. For at least some audience
probably larger than 1 but not the whole world, or even the whole IETF
membership, in general one should not need to read references to
understand the gist of a paper (internet draft). But there may be
cases even there where one does.. For esoteric details of the frutzel
transport protocol I will certainly need to read the spec if I want to
know them - I simply don't know them all, off-hand. I might also
trust certain people in the community to represent the fruzel prototol
fairly to me, but even so, I expect them to give me hints as to why
they might take a particular position on how to caste frutzel
addresses into URLs. For someone coming new to the working group or a
student of mine who wants to join this fray, there will be perhaps
more background reading in order to fully understand the documents
being circulated in our group. So, the question of how much
background material to include is a difficult one in some cases; it
isn't always clearcut, but generally we all have a pretty good
understanding of it.
Now, comes the question of where to find the description I need to
understand the frutzel transport protocol. By providing URLs we are
now doing something that is different from what we have traditionally
provided for readers. Traditionally, references provided an
identifier that allowed the reader to resolve it in some local,
context sensitive way, but provided an identifier that was extremely
long-lived (think about URNs here:-). We now see a move toward
providing location information in potentially long-lived documents (eg
published in journals and magazines and probably books, but especially
online documents). We of all people ought to understand that that is
a bad idea. We should *NEVER* be putting URLs into documents. We are
misusing URLs in ways that having for the last year at least been
causing people outside our community to believe that we don't
understand why they shouldn't be used as long-lived identifiers. Not
infrequently people come up to me declaring that the people in the
IETF doing URLs are really a bunch of idiots because they are solving
the wrong problem. With some explanation it isn't hard often to
convince them otherwise, but we aren't there yet. We must work
extremely hard to eradicate that behavior first in ourselves, and
hopefully in the community at large.
For the present we don't have some widely accepted way to provide
locators (ie translation services, URC storage and provision services,
whatever you want to call it - the things that translate long-lived
identifiers, URNs, into locations, URLs). Thus we have a dilemna. We
see an immediate need for both URLs and URNs, but we only really have
URLs. Unfortunately, if we use URLs for URNs we may be hosing our
credibility, so we should be extremely careful about this, and make
absolutely clear what we are doing.
Diatribe over...
Karen
___________________________________________________________________
Karen R. Sollins sollins@lcs.mit.edu
Research Scientist Phone: 617/253-6006
M.I.T. Laboratory for Computer Science Fax: 617/253-2673
545 Technology Square
Cambridge, MA 02139