# Re: URN functional spec

Dave Brennan (brennan@hal.com)
Thu, 10 Feb 94 16:55:29 CST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "caching"
- Previous message: Dave Brennan: "Re: URN functional spec"
- Maybe in reply to: Karen R. Sollins: "URN functional spec"
- Next in thread: Bruce Speyer: "Re: URN functional spec"

    Date: Thu, 10 Feb 94 16:55:29 CST

    From: brennan@hal.com (Dave Brennan)

    Message-Id: <9402102255.AA13240@hysteria.hal.com>

    To: uri@bunyip.com

    Subject: Re: URN functional spec

Ok, enough of my comments on the comments.
Here's my comments on the draft.

Overall it looks good. As you can see most of my comments have to
do mainly with organization and exact semantics. In addition, there
are several comments on some areas that could use clearing up.

* The introductory paragraph is too long and quickly jumps into a
sort-of justification of naming schemes that, while useful, is
best placed later in the document.

* The beginning of the draft makes several references to the "resource
discovery" problem, but this topic seems beyond the scope of the draft.
UR* identifiers are what you get when you go looking for information,
but how you initially obtain your potentially interesting URNs is
entirely different matter (and working group :-).

> The purpose or function of a URN is to provide a globally unique,
> persistent identifier used both for recognition and often for
> access to characteristics of or access to the resource.

Perhaps this statement more clearly indicate that "access" is not
direct from the URN itself.

> There are two kinds of requirements on URNs: requirement on the
> functional capabilities of URNs, and requirements on the encoding of
> URNs.

Does "encoding" in this context refer to both the ways in which a
URN is composed by the naming authority and the allowable characters?
These are two separate "requirements," although the encoding in terms
of allowable characters is only one that must be strictly specified.
In either case, the exact meaning of encoding in this context should
be made more clear.

> * Sameness: There exists a mechanism for asking whether two resources
> are the same, based on their URNs without going to the naming
> authority. This is a simple equality test on the URNs, which
> requires a canonicalization of the strings.

Does "asking" mean comparing? It implies I have to go somewhere else
to ask the question. Maybe this should say "...there exists an algorithm
for determining whether two URNs refer to the same resource..." Or,
even better just specify that a string compare is that algorithm.

Also, I'm not sure what "canonicalization" is referring to in this
context. Is there something I have to do to the URNs before comparing
them. If so it should be specified. If not, there's no need to mention
this.

> * Scalability: URNs can be assigned to any resource that might
> conceivably be available on the network, for hundreds of years.

If scalability is mentioned, I think that it needs to be defined in
more concrete terms. I think that there's been a discussion of two
different scalabilities. Scalability of URNs in general, and scalability
of a class of URNs generated by a specific naming authority. These two
cases need to be clearly distinguished (or maybe not if you take Tim's
viewpoint).

> * Extensibility: Any scheme for URNs must permit future extensions to
> the scheme.

This is a good requirement. In practical (or implementation) terms I'm
interested in how it is reflected in the form of a URN.

> * Caching: Any scheme for which caching is appropriate should not
> impede caching of resources named by it.

Oh, no, not caching again! Just kidding...
Does this refer to caching in the URN->URL lookup, or object caching
based on a URN. In the latter case, it seems that caching is not a
problem when the "sameness" requirement is satisfied.

> * Resolution: A URN will not impede resolution (translation into a
> URL, q.v.). To be more specific, for URNs that have corresponding
> URLs, there must be some feasible mechanism to translate a URN to a
> URL.

I get the feeling that this can somehow be related to caching.

> * Transport friendliness: A URN can be transported unmodified in
> the common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc.,
> as well as printed paper.

Don't forget the good 'ole bar napkin :-)

> The name of the naming authorities themselves are persistent and
> globally unique, by means of a central registry.

Is it worth mentioning that some kind of naming authority id will be
part of a URN as a means of insuring uniqueness at the "root" level?

> * The naming authority should be discouraged from but is permitted to
> design a naming scheme which is not scalable.

nit:
This would be better worded as "are discouraged" instead of "should be"
so that it is clear that the authors of this document are the ones who
are doing the discouraging. "Should be" just leaves it up to someone else.

> * Naming authorities should guarantee that somewhere, somehow, there
> is a mapping (or the potential for a mapping) to one or more URLs.
> The naming authority itself need not provide the mapping from URN
> to URL.

Is there any requirement that a URL derived from a URN be valid?
What if I decide that I want to trash an object for which URNs exist?
I could just remove the mapping, or maybe change the mapping so that
the URN maps to an empty URL to indicate that the object is no longer
available as opposed to just "no mapping exists." The former is more
definite than the latter.

That's it for now...

Cheers,

Dave Brennan HaL Computer Systems
brennan@hal.com Austin, TX, USA

- Next message: Karen R. Sollins: "caching"
- Previous message: Dave Brennan: "Re: URN functional spec"
- Maybe in reply to: Karen R. Sollins: "URN functional spec"
- Next in thread: Bruce Speyer: "Re: URN functional spec"