# Re: URLs, URIs, and references

Peter Deutsch (peterd@bunyip.com)
Wed, 26 May 1993 12:34:43 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Re: URLs, URIs, and references"
- Previous message: Michael Mealling: "nice article Ed!"
- Maybe in reply to: Larry Masinter: "URLs, URIs, and references"
- Next in thread: Dirk Herr-Hoyman: "Re: URLs, URIs, and references"

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

- Next message: Mitra: "Re: URLs, URIs, and references"
- Previous message: Michael Mealling: "nice article Ed!"
- Maybe in reply to: Larry Masinter: "URLs, URIs, and references"
- Next in thread: Dirk Herr-Hoyman: "Re: URLs, URIs, and references"