# Re: Internet Draft on URNs

Dave Brennan (brennan@hal.com)
Sun, 16 May 93 21:58:42 CDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: Internet Draft on URNs"
- Previous message: Dave Brennan: "Re: Internet Draft on URNs"
- Maybe in reply to: Chris Weider: "Internet Draft on URNs"
- Next in thread: John Curran: "Re: Internet Draft on URNs"

    Date: Sun, 16 May 93 21:58:42 CDT

    From: brennan@hal.com (Dave Brennan)

    Message-Id: <9305170258.AA24491@hysteria.hal.com>

    To: uri@bunyip.com

    Subject: Re: Internet Draft on URNs

Comment #1

Is case insensitive really only a guideline? Am I free to assign case
sensitive URNs? What if I have no interest in supporting "very old systems"
that can't deal with lower case.

Comment #2

Why does the wrapper have to use repeated colons? What's wrong with:

URN:Naming_Authority_identifier:opaque_string:

I know it's only three extra bytes, but they don't seem necessary.

Comment #3

The term "resource location service" needs to be defined somewhere.
We know what it means, but Joe "Clueless" Reader may not.

Comment #4

> It is also intended to provide some detection of duplicates
> in responses to queries of various resource location services.

This meaning of this sentence (from section 3.1) is not clear to me.
It raises the following questions:

- What kind of duplicates are trying to be detected? URNs? URLs?
Documents?

- Do you really mean "responses from queries?" The term "responses to
queries" implies something different.

If the duplicate detection comes from comparing URNs (which I thought
was possible) what does a query have to do with it?

Actually, this raises a few other points:

Should it be suggested that it's a Bad Idea to assign more than one
URN to a particular resource? If this is done I can have two different
URNs that resolve to two different URLs that finally resolve to the
same document. It shouldn't have to go that far for me know that I'm
dealing with a duplicate. This is still kind of a problem when
a particular document has several different formats but is really
(as far as humans are concerned) the same document.

The Draft starts to address this problem, but leaves the solution
open-ended. I agree that URNs should not be human readable (more
on this in my next message) but perhaps they should contain and
additional field for type information. The format would be totally
up to the authority assigning the URN. Then the equality of the
information content could be ascertained by comparing everything but
the type field.

It probably makes sense to allow the registration of types so that
a program could pose an intelligent question to the user regarding
documents, like "Do you want the ASCII or PostScript version?"
Information on types would have to be available dynamically via a
lookup service, so that programs can dynamically deal with new types.

Please note that type information is distinctly different from
information about WHAT a resource contains, which I don't think
belongs in a URN. Once again, type information would make it
possible to determine equality of the information content of
document independent of the format of the information. I think
this is an important capability.

(More comments to follow...)

    --
    Dave Brennan                                      HaL Computer Systems
    brennan@hal.com                                         (512) 794-2855

- Next message: Michael Mealling: "Re: Internet Draft on URNs"
- Previous message: Dave Brennan: "Re: Internet Draft on URNs"
- Maybe in reply to: Chris Weider: "Internet Draft on URNs"
- Next in thread: John Curran: "Re: Internet Draft on URNs"