Message-Id: <9305261634.AA06053@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Wed, 26 May 1993 12:34:43 -0400
In-Reply-To: Larry Masinter's message as of May 25, 22:55
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: URLs, URIs, and references
[ You wrote: ]
> Are you going to post these to the uri list? I think I'd like to see
> other people's. Forward this if you think it is appropriate.
I strongly encourage anyone who responds to my posting to
do so to the list.
> Mainly: URLs are to be primarily useful for what we use them for now:
> giving a pointer to data that is mechanically processable (rather than
> some recipe like 'ftp foo.com, cd baz, binary, get source.tar.Z,
> uncompress it and treat it as a tar file'.
Yeah, I'd forgotten about scripting. Actually, this is a
capability I wouldn't mind seeing in the long run,
although I can certainly do without it for now. Still, the
ability to add such extensions easily will serve as a
valuable test of what we've done.
> ================================================================
> 1) URLs are for machines. But try not to make them ugly for people.
> (like postscript).
>
> 2) URLs are to be easily transmitted through existing infrastructure.
> (yes, mail 'em! yes, include them in .html documents, etc.)
> URLs are to be easily transcribed without error (by humans)
> URLs are to be easily readible by humans
> (by 'read' you mean 'interpret'? Being able to trascribe is more important.)
Actually, from what people have said in the past, I assume
this means "pleasing to the eye" in the sense that
"ftp myfile from foobar.edu"
is more palatable than:
"#21-%64yfile-foobar%2eedu"
Note that there is a one to one mapping from the second to
the first, but humans will prefer to see the first.
> URLs must fit within the confines of a napkin
> (Make 'em as short as possible consistent with other goals).
>
> Function, in order:
> URLs are to be easily manipulated by machine.
> (original motivation)
> URLs are to be easily transcribable without error (by machines)
> (careful with 'easily')
I was thinking of this as a code for "machine readible
checksums" or even <shudder> error correcting codes.
> URLs must be easily extensible to new systems
> (that's the point)
> URLs should provide strong typing information.
> (I don't know what 'strong' means here. I think URLs should provide
> enough information to be able to decide what to do with the data
> it references once you get it. The information's there in the current
> URL spec for the most part, but hidden. This doens't trade off
> with most of the other goals, except with 'fitting onto a cocktail
> napkin.')
> URLs should provide hints to the system about when they may or may
> not have gone out of date.
> (The proposal is to 'allow a reference to give a date.')
>
> Creation and Ownership:
> * URLs should be derivable from first principles by anyone who needs them.
> (actually not. URLs should be 'followable' by anyone who wants to get
> the R that they L, but derivable?)
>
> * URLs should be issued only by a specific server.
> (aw, no, URLs point at too many kinds of things for this to be the
> case)
>
> * It should be possible, starting with a URL, to identify the
> appropriate URN and associated meta-information.
> (certainly not! depends on what you mean by meta-information, since
> I'd say YES to type, and NO to things like author, title, filename,
> etc. because i don't think 'type' is meta-information.)
>
>
>
>-- End of excerpt from Larry Masinter
--
------------------------------------------------------------------------------
Peter Deutsch, (514) 875-8611 (phone)
Bunyip Information Systems Inc. (514) 875-8134 (fax)
<peterd@bunyip.com>
"Charging for information is not a crime, any more than charging for food is
a crime. On the other hand, I agree that letting people _starve_ is a crime."
------------------------------------------------------------------------------