# Re: going too far? (longish diatribe)

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Tue, 29 Nov 1994 00:34:30 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman, Gopher/Web maintainer: "Re: going too far?"
- Previous message: John A. Kunze: "Re: draft-ietf-uri-irl-fun-req-01.txt IESG comments"
- In reply to: Karen R. Sollins: "going too far? (longish diatribe)"
- Next in thread: Ronald E. Daniel: "Re: going too far? (longish diatribe)"

    To: "Karen R. Sollins" <sollins@lcs.mit.edu>

    Subject: Re: going too far? (longish diatribe)

    In-Reply-To: Your message of "Mon, 28 Nov 1994 13:50:34 EST."

                 <199411281850.NAA15558@lysithea.lcs.mit.edu>

    Date: Tue, 29 Nov 1994 00:34:30 -0800

    From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>

    Message-Id:  <9411290034.aa06242@paris.ics.uci.edu>

Karen R. Sollins writes:

> 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 protocol
> 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.

The amount of detail necessary is, of course, a function of the purpose
for which the document is intended. In the case of something like a
specification for a particular URL scheme, the detail needed is comparable
to that required for the definition of Internet media types (MIME
content-types). The purpose and example use of the URL scheme should
be provided. The syntax should be fully specified, including a BNF and any
context-sensitive parsing rules. All special terms should be briefly
explained and, where necessary, a pointer given to a longer definition.
Finally, reference(s) to the complete definition of the protocol used
by the access scheme should be provided.

> 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.

Different only in that we are providing *more* information than before.

> 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).

As long as the traditional references are also present, why is that a problem?

> We of all people ought to understand that that is
> a bad idea.

On the contrary, we of all people should know how useful a URL can be
(even when that URL is broken). A URL is a very potent piece of information.
When a reasonably stable URL is available, not providing that URL is
doing a great disservice to the reader. For documents that have URNs,
a URN would be better, but there are no such documents and thus there
is no point in following that line of reasoning.

> 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.

I completely disagree. We should *ALWAYS* be putting URLs in Internet-Drafts.
*SOMETIMES* they are also appropriate in completed RFCs, but that depends
on the individual reference. Anyone who believes URLs cannot be used as
identifiers should be instructed on why they can -- their ignorance is no
reason for us to stop using them as identifiers, nor should we ever be
ashamed of providing the best identifier available at the moment.

Yes, people often complain to me about how fragile a URL can be.
However, it only takes a few minutes to dissuade them of that notion
(at least for http URLs). In fact, if I take the time to explain the
usage of a tool like MOMspider, they sometimes become URL-evangelists.

......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

- Next message: Paul Hoffman, Gopher/Web maintainer: "Re: going too far?"
- Previous message: John A. Kunze: "Re: draft-ietf-uri-irl-fun-req-01.txt IESG comments"
- In reply to: Karen R. Sollins: "going too far? (longish diatribe)"
- Next in thread: Ronald E. Daniel: "Re: going too far? (longish diatribe)"