# Re: Belated comments on OCLC's proposal

weibel@oclc.org
Fri, 16 Jun 1995 17:19:42 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Martijn Koster: "Criticism of Kidcode (was Re: KidCode: Next steps )"
- Previous message: Jorge Paulo Ferreira Simao: "WWW Security Survey (other URL)"
- Maybe in reply to: Mitra: "Belated comments on OCLC's proposal"
- Next in thread: Mitra: "Re: Belated comments on OCLC's proposal"

    From: weibel@oclc.org

    Date: Fri, 16 Jun 1995 17:19:42 -0400

    Message-Id: <199506162119.RAA00836@ws02-00.rsch.oclc.org>

    To: uri@bunyip.com

    Subject: Re: Belated comments on OCLC's proposal

Mitra writes:

> 1.0 I: services desired
>
> I believe the service desired is a part of the client functionality, or a
> request of the user, not something that should be specified by the Author,
> i.e. as a User I know whether I want to get a list of URL's to pick from, a
> single one to retrieve, or a list of URC's so I can compare costs.

Yes, the Client will do the service selection in the majority of
cases. Users may know that they want to pick from a list of URLs, but
for most, the behavior of a Client is a black box... we do not want to
force the User to decide what they want, but we *should* allow it if
they want to do something other than the default.

In some cases, an Author *needs* to be able to specify what is to be
retrieved:

eg. 1: A paper about one's own work on networked services with dynamic
examples of URI service requests,
eg. 2: A journal article with a callout to a figure, dynamic data object,
or applet: nothing but the specific object is appropriate.
The author or vendor must be able to "cast" the object type to suit
the context of the document or service.

>
> 1.0 IV: Naming authority flat space scales ....
>
> I disagree entirely with this, the number of sites at the second level of
> DNS is already stretching things, what will happen when every college
> student is going to have to register as a naming authority (unregistered
> NA's aren't persistant). Currently these are handled very well by a
> hierarchical DNS that works effectively in the .edu domains.

We're not sure exactly whether your objection here is about name space
or persistence.

As for scaling, we believe that the registered NA space will be smaller
by several orders of magnitude than the DNS space. Paul's suggestion
of reserving a character to promote future hierarchy will be in our
next revision.

URN persistence is, of course, desirable, though it is not a
characteristic that can be assured by any URN scheme. It is probably
true that unregistered NAs can be presumed to be less persistent than
registered NAs. However, allowing people to assign URNs without
registering as a naming authority will let them take advantage of the
same resolution mechanisms of more formal resources without the
constraints (or implied costs) associated with formal registration.
Many such objects need not persist for decades, but will live for a
short time (days to a few years) in a local store. Others will be
promoted to a more formal, registered existence by being transferred to
a formal repository managed by a Registered NA. There is no need to
preclude the use of the same URN syntax for these objects, and several
reasons to allow it.

> 2.0: unique object (not content)
>
> This contradicts previous decisions, and the paper doesn't describe how a
> holder of a URN would obtain a list of, for example, more recent versions,
> or different formats, of the same content.
>

Specifying relationships between related objects is inherently
complex... version, formats, editions... these are very hard problems
in the paper world and are likely to be harder in the electronic
world. URNs are names, and the name of a postscript object needs to be
different than the name of an SGML file with the "same" intellectual
content. So too, the name of version 1.5 of FOO needs to be different
than version 1.6.

Related works may be tied together by URCs, not by the URNs, though I
think it is worth discussing whether some simple versioning or format
semantics should be included in the opague string components of URNs.
There seem to be good arguments on both sides.

> 3.1 "can be resolved by *a* name authority ID resolver"
>
> If this is really "a" resolver, then how does the client determine which
> one to use, if it should be worded "any" then we have to have a fully (not
> partially) replicated Naming Authority Service.

We are in agreement with the Handle folks that there needs to be a global
naming authority registry, so that a client can find out that:

N2L://OCLC/12345

can be resolved by a machine named, say, urn.oclc.org:nnnn

Again, we expect there to be many fewer NAs than DNS hosts, so such
mappings will be widely cached, and the global resolution service will
be invoked primarily to refresh caches.

>
> 3.2 persistance and unregistered names
>
> unregistered NA's impede persistance, since a URN registered that way
> cannot easily be converted to a persistant URN, or at least if it is then
> we lose the comparability case.

It is true that unregistered NAs are probably less persistent, and they
will presumably be used in cases where persistence is not a serious
issue. They might be thought of as lightweight URNs. Many will be
subsequently promoted to formal URNs. If it were judged necessary to
support unregistered ones, they could be registered in an N2N service
(which service will be necessary in any case, to deal with maintenance of
URNs... resolving duplicates, for example).

Why should we support unregistered NAs at all? Because some
individuals and organizations will not want to register their objects
with a formal naming authority for reasons of cost or convenience or
philosophy, but still want to take advangtage of URN resolution
syntax.

>
> 5.0 Resolution Paths
>
> This seems totally bogus for a system with Global Scope, either its
> required for the URN (in which case it should be part of it), or it isn't
> in which case it could be misleading.

This is the issue that Paul at first lauded and subsequently raised an
important objection to. We acknowledge Paul's argument that it may
give rise to invalid or malicious resolution possibilities, but if you
allow ANYONE except a monolithic global resolution service to resolve
URNs, then this problem arises. This problem must be balanced against
the desire/need for organizations to exercise local control over
resolution. Keep in mind that the persistent name of the object is not
modified; the RP modifies the SERVICE requested, not the URN.

The general question we feel is addressed by optional RPs is as follows:

Is is ever desirable to have a URN resolve to different objects of the
same type by a given service (different URLs, for example, or different
versions of a URC)? If the answer is yes, then it is useful to be able to
specify an optional resolution path, in order to specify a resolver that
is:
- closer
- faster
- cheaper
- under local administrative, political, or budgetary control

Again, we emphasize that the URN is not changed, and can presumably always
be resolved by the Naming Authority specified in the URN. The Optional RP
supports mirroring at both the *retrieval* level and at the *resolution*
level.

It may be that allowing configuration of resolution paths in the Client
satisfies this requirement, but it is still reasonable to suggest that
authors should be able to specify the path for a service that is
unknown to the naming authority. That is, the author wants a
persistent name for an object that includes a service that is novel and
unregistered.

Two examples requiring optional RP Arguments:

eg. 1 You need to show, in a document, that different places resolve
the same URN differently (a very plausible event in, for example,
a CERT advisory). This can only be done by specifying
different resolution paths for identical URNs.

eg. 2 The RP modifies the Service, not the URN. If the service is
not known to the Name Authority Registry (even if the Name
Authority ID is) then the browser would not know how to resolve
the request. Eric realizes that scholars are lazy louts who will
pay $0.25 for every URN to be converted into the Chicago Manual
of Style citation format, and provides a service to do this.

CMoS://OCLC/0001 won't work, however, because Eric's new service
(CMoS:) isn't registered with the naming authority (OCLC)

If CMoS is not a registered resolution service under OCLC then
the browser has no way of resolving it, so he provides a path
that will accomplish this:

CMoS:/eric.gets-rich.com:555/OCLC/0001

If CMoS is not a registered resolution service under OCLC then
the browser can send the request to eric.gets-rich.com:555.
Since the browser would use the author specified RP after the
dynamic RP from the Name Authority Resolver, the author specified
RP will be ignored once CMOS is a registered service under OCLC.

>
> 5.0 3 Naming Authority from URN
>
> An important step is missing from this section (but given in the Examples),
> that of contacting the Naming Authority Resolver to determine the
> Resolution Host, how the Naming Authority Resolver is found needs
> determining, as does the protocol used between the client and hte Naming
> Authority Resolver.
>
> 5.0 "should be sent to the Resolution Host"
>
> How? This is not of any use without specifying what protocol to use to talk
> to the Resolution Host. This has been the major point of contention between
> some of the existing schemes.

This I-D does not describe specific protocols, but rather, focuses
on the specification of the resolution requests. We will add further
information on protocols in the next revision. HTTP seems a natural
candidate.

>
> 5.3.1 "The resolution request should be sent to the resolution host"
>
> How - see comment above on (5.0 3)
>
> 5.3.1 "It is further assumed that this information can be mirrored by
> *various* servers".
>
> If the client can contact "any" Naming Resolution Server, then this needs
> to read "mirrored by ALL servers" which gives us a scaling problem.
>
> Otherwise how does the client know which Naming Resolution Server to
> contact to get this information.
>
> 6.0 Fulfillment of Requirements
>
> Persistance: NO - see comment on 3.2

Persistence is promoted by the use of Registered URNs. The usefulness of
having an informal path using the same syntax in no way impedes
persistence, and in fact, may result in a URN space marginally less
cluttered with ephemera that do not need persistent naming.

>
> Scalability: NO - see comment on 1.0 IV

There will be many fewer NAs than domain names... probably by several
orders of magnitude. The Name Authority Registry can be widely cached,
providing fast, local lookup for resolution services. We adopt Paul's
suggestion of a reserved character (#) to provide for expansion of the
hierarchy in the future if necessary.

The OCLC URI team

Keith Shafer shafer@oclc.org
Eric Miller emiller@oclc.org
Vince Tkac tkac@oclc.org
Stu Weibel weibel@oclc.org

- Next message: Martijn Koster: "Criticism of Kidcode (was Re: KidCode: Next steps )"
- Previous message: Jorge Paulo Ferreira Simao: "WWW Security Survey (other URL)"
- Maybe in reply to: Mitra: "Belated comments on OCLC's proposal"
- Next in thread: Mitra: "Re: Belated comments on OCLC's proposal"