# Re: OCLC's URN Services Proposal

Paul Hoffman (ietf-lists@proper.com)
Wed, 7 Jun 1995 15:01:21 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Reinier Post: "Re: URLs Containing "#""
- Previous message: Paul Hoffman: "A new URL-related I-D"
- Maybe in reply to: weibel@oclc.org: "OCLC's URN Services Proposal"
- Next in thread: Erik Jul: "Re: OCLC's URN Services Proposal"

    Message-Id: <v02120c0fabfb9959928b@[165.227.40.38]>

    Date: Wed, 7 Jun 1995 15:01:21 -0700

    To: uri@bunyip.com

    From: ietf-lists@proper.com (Paul Hoffman)

    Subject: Re: OCLC's URN Services Proposal

This proposal brings up some interesting issues which the WG will have to
hash out. It has some interesting ideas in it that I like very much, but it
also has some central parts that I think will unnecessarily limit users who
are resolving URNs.

>I. In the simplest case, a URN should be resolvable to a URL.

Agreed.

>In
>other cases, a URN may need to be resolved to a list of URLS [URC0] or
>a complete URC.

The URC0 proposal describes "complete" URCs: they're just pretty simple
(or, as we say in the title, trivial). A URC0-style URC is more than just a
list of URLs: each URL also has optional unstructured metainformation. Ron
and I fully expect that there will be different, more structured URC styles
in the future.

>To support this, one cannot merely say that a URN
>resolution request in a document is specified as URN:NA/OS. Instead,
>one should explicitly state the service desired.

I agree as long as the "one" in the second sentence is the user resolving
the URN, not the author publishing the URN. Unfortunately, later parts of
the proposal only talk about the resolution requests with the desired
service as part of the request. If you agree that it is the user (through
default settings in her/his client software) who decides what level of
response they way, I'd like to see more discussion of this here and in
section 5. I'm a bit worried by the examples in section 5.3, because they
show requests in angle brackets, making them look like things you might see
in free text.

>IV. This scheme requires a Naming Authority Registry. Since
>information from this Name Authority Registry will be easily cached, we
>assume a flat name authority space.

I think that a flat name space is probably sufficient in the short run,
particularly because the registered name space is augmented by the DNS.
However, I think that the name space should be allowed to become
hierarchical if needed in the future. If you agree, a simple fix would be
to have the name space be flat initially, reserve a character such as "#"
for future use, and if the namespace needs to become hierarchical later,
use that character for the hierarchy (for example, "ISSN#OCLC",
"CHRIS#OCLC", and so on). You can turn hierarchy on later by extending the
proposal then.

>The name authority part of a URN is not necessarily a name authority
>ID. It can also be a resolution host -- a fully qualified domain name
>(FQDN) and port to a resolution service. Any name authority with a
>"." in it is assumed to be a resolution host.

I love this, I really do. It gets away from the DNS, which I only
reluctantly used in the x-dns-2 scheme Ron and I proposed. I'm very much
against mandating a single central registry for URN servers, even with the
advantages given in your proposal and in some of the other URN proposals. I
think you've hit a real winner here with how to have the best of both
worlds: optional central registry and trivial unregistered hierarchy at the
same time, and the names are easily distinguishable.

>4.0 Resolution Services

Service names

I'm not comfortable with the request *demanding* a single kind of service
because it is very likely that clients can handle more than one. This is
why Ron and I used the HTTP Accept header: it lets the server know the
variety of services the client can handle and which kind of services the
client prefers in one simple mechanism.

With the spec here, if I specify N2C0 but the server can only do N2L, I'll
get a negative response back instead of one I could use. You could modify
the proposal to make the service field a semicolon-separated list of
services, such as "N2L:;N2C0://OCLC/ISBN1234".

Also, although you don't specify it in section 4.1, I take it from your
examples that "N2Cx" is actually "N2C0" or "N2C1" or "N2CC", but not a
combination of them. You should make this more explicit in section 4.1.
Then again, I think this is a bad idea too for the same reason: the server
should be able to find out what a client can accept and what the client
prefers, and go from there.

RPs

I like this idea very much. Assuming that the RPs are generated by the
client software resolving a registered NA and seeing which of the hosts it
prefers, this has many big advantages over our DNS-only scheme. More kudos
for this.

However, I think you need talk a bit about how RPs are handled when the NA
is a FQDN. For example, consider the following valid requests:
N2C0:/foo.com/bar.com/abcd
N2C0:/foo.com:1234/foo.com/abcd
N2C0:/foo.com:1234/foo.com:5678/abcd

Also, I think it's too restrictive to insist that an RP be a FQDN: I think
that an IP address is also appropriate if the NA is a FQDN. Here, the
client could resolve the FQDN through a standard DNS lookup, get back a
list of IP addresses, and pick the IP addresses prefered from the list.
Thus, I'd like to allow a valid request in your format to be:
N2C0:/165.227.249.2;165.227.25.1/proper.com/abcd
This is useful if the client knows the network IP prefixes for local
networks, or the prefix or full IP address of preferred resolvers.

>4.5 URL to URN (L2N)
>4.6 URL to URC (L2Cx)

I think that these are out of place in this proposal unless you describe it
in much more detail. What does this have to do with resolving URNs? How
will a user decide which URN resolver to ask for a particular URL? What is
the significance of a list of URNs or a list of URCs without
metainformation about them, such as who chose them and how?

>5.1 Resolution Service (Resolver)

This needs much more information. First off, you didn't describe the
transmission protocol or default ports. Even more significant, you don't
describe the format of the results. These are both very important.

Overall: What URNs resolve to

Throughout the document, you talk about URNs resolving to URLs, and I think
that's wrong. Specifically, you say "URNs are meant to be resolved to
URLs." I strongly disagree. In my mind, URNs do not resolve just to URLs:
they resolve to URCs. A URC could be as single URL, one or more URLs with
unstructured metatext for each (that is, a URC0), or a more structured URC.

In linking URNs to just the URLs, you gloss over the desirability of the
metatext for users. A good example is a URN such as
"URN:ISBN/0-7821-1719-8". I may not care where that book is stored on the
Internet, but I might want to know who the author is or when it was
published. In this case, the URL is unimportant to me, but the metatext is
very important.

Summary

I think you've got some ideas that Ron and I may want to include in our
proposals. I very much like the method you use for mixing registered and
DNS names, and I like how requests can have prioritized RPs. I hope we can
come to an understanding on the other issues.

--Paul Hoffman
--Proper Publishing

- Next message: Reinier Post: "Re: URLs Containing "#""
- Previous message: Paul Hoffman: "A new URL-related I-D"
- Maybe in reply to: weibel@oclc.org: "OCLC's URN Services Proposal"
- Next in thread: Erik Jul: "Re: OCLC's URN Services Proposal"