# Re: date in URN

Karen R. Sollins (sollins@lcs.mit.edu)
Mon, 26 Jun 1995 12:40:49 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman: "Re: Re SGML URC spec comments"
- Previous message: Terry Allen: "Re: Simple comparison of URNs"
- In reply to: Peter Deutsch: "Re: date in URN"
- Next in thread: Peter Deutsch: "Re: date in URN"

    Date: Mon, 26 Jun 1995 12:40:49 -0400

    Message-Id: <199506261640.MAA08135@lysithea.lcs.mit.edu>

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

    To: peterd@bunyip.com

    In-Reply-To: <9506251602.AA16599@expresso.bunyip.com> (message from Peter Deutsch on Sun, 25 Jun 1995 12:02:38 -0400)

    Subject: Re: date in URN

Hi Peter,

From: Peter Deutsch <peterd@bunyip.com>
Date: Sun, 25 Jun 1995 12:02:38 -0400
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
Cc: uri@bunyip.com
Sender: owner-uri@bunyip.com
Precedence: bulk

Hi Karen!

[ You wrote: ]

} Peter,
}
} We've been through some of these arguments about the degree of
} user-friendliness before (I'm sure you were there - didn't we do some
} of this in Houston?)

<sigh> Yup...

} . . . I believe that
} we've perpetuated a slight mistake in the URI WG by calling these
} things URNs ("names") because too people assume that a name has to be
} human friendly. These things should be as human unfriendly as we can
} get away with, to discourage their direct use by humans. They are
} serving a different purpose at a different level of abstraction than
} human friendly names.

I agree, we're definitely talking about two sets of
functionality here, although I'm not yet convinced there's
something wrong with calling these things "names". We just
need to be careful about what we think we can do with
them. For me, the requirements for comparision and
dereferencing remain the defining elements.

I agree. The reason I shy away from the term "name" is that I hate
having arguments with people about terminology. Too many people have
seen "name" in 'URN" and not read carefully enough to realize that
these things may not match exactly all their previous assumptions
about what a "name" is or is not. Then they proceed to have long,
pointless arguments with me about something they think I said that I
didn't say. I'm just a little gunshy at this point. Anyway, it's too
late now.

Depending upon how we do it, I think dereferencing does
mean we need a human friendly part for when humans must
select these things. For dereferencing, we obviously want
to focus on the mechanical processing capabilities and
might be willing to sacrifice readibility here if it makes
it work.

But more to the point, comparison and dereferencing are indeed the
important issues. If we have some other human friendly scheme(s) for
giving things nmemonic names, then why should people need to see URNs
if they get involved in dereferencing? Maybe I'm misunderstanding
something here. If there is other information about particular
instances that the human needs in order to help in dereferencing a
URN, that information should come from the URC not the URN. It is
meta-information, and I would like very much to see us stay away from
putting meta-information into the URN.

Taken together this probably means that a URN probably
needs two components, and that we need to be able to
process/handle the two separately. Still, I think they
also need to remain bound together as in gopher menu
items. So, perhaps this means a URN should look like:

<naming authority>:[<optional human readible string]>:<unique ID>

AARRGGHH!! Remember the discussions about putting mutable information
about a resource into the name? I still think we shouldn't do that.
So far, other than a content free identifier, the only other fact I
found so far that is intended not to change across the board for
resources is the fact that they are immutable, if they are immutable.
(A mutable resource might become immutable, but the intention is that
this won't happen the other way around.) But I don't think that's
enough semantics to make interesting human readable names.

Note! I'm not proposing a syntax, I'm proposing a set of
components here...

Yeah, I know, but that's not the issue...(see my comments above)

- peterd

Someone also pointed out that I was contradicting the requirements doc
for URNs by suggesting that URNs should not be human friendly.
Unfortunately, we had lengthy (measured in years) arguments on such
topics. The intention was that "human transcribable" not be the same
as "human friendly". "Human transcribable" was supposed to capture
the idea that if you really needed to, you could type it on your
keyboard; more likely you might cut and paste it. It was not intended
to suggest that you ought to WANT to do these things. In fact, rather
the opposite. (Just as an example, in our project, the ids we've been
generating use only 16 letters, none of them vowels. You can type them,
but you probably won't get a lot of meaning out of them.)

Just as a piece of history, there were very similar discussions as the
DNS was being designed. Although the hierarchy was to exist, early on
it was intended first that those names would NOT be the user friendly
names, but that there would be another scheme on top. Second, people
became attached to places in the DNS hierarchy. It is important that
as a company you have a top level domain under .com or co.uk or
whatever. If your company had some name 4 or 5 levels down, it (or
rather the people running it) would probably be pretty annoyed. Given
that a namespace was used to which people could attach meaning, they
did and they never got beyond that and its consequences. Are we
following the same path?

Karen

- Next message: Paul Hoffman: "Re: Re SGML URC spec comments"
- Previous message: Terry Allen: "Re: Simple comparison of URNs"
- In reply to: Peter Deutsch: "Re: date in URN"
- Next in thread: Peter Deutsch: "Re: date in URN"