# Re: Belated comments on OCLC's proposal

Mitra (mitra@regis.prod.kaworlds.com)
Mon, 19 Jun 1995 11:13:06 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: weibel@oclc.org: "UR* issues for Stockholm: New WGs?"
- Previous message: Darren New: "Re: Criticism of Kidcode (was Re: KidCode: Next steps )"
- Maybe in reply to: Mitra: "Belated comments on OCLC's proposal"
- Next in thread: Vincent Tkac: "Re: Belated comments on OCLC's proposal"
- Reply: Vincent Tkac: "Re: Belated comments on OCLC's proposal"

    Date: Mon, 19 Jun 1995 11:13:06 -0700

    Message-Id: <ac0b065b0402100416ae@[192.190.111.98]>

    To: weibel@oclc.org, uri@bunyip.com

    From: mitra@regis.prod.kaworlds.com (Mitra)

    Subject: Re: Belated comments on OCLC's proposal

At 9:19 PM 6/16/95, weibel@oclc.org wrote:
> Mitra wrote

> > 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.

My objection is that this scheme requires a choice between persistence and
name space, i.e. if objects I produce are to have persistence then I need
to register in the FLAT name-space. A hierarchical name-space, as used in
our scheme (and others) allows us to have both.

>As for scaling, we believe that the registered NA space will be smaller
>by several orders of magnitude than the DNS space.

I believe the NA space will be of the same order as email addresses.

> > 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.

This all depends on your assumptions about the size of the NA space. Please
correct the document to make it clear that you are dependant on a single
replicated Naming Authority Service. I believe this is enough to make this
proposal unscalable.

> > 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).

So now, the algorithm in the clients has to search a hierarchy of N2N
services (it would be too many for one service) in order to take a
non-persistant URN and turn it into a persistant one.

>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.

This problem is an artifact of a flat NA service, with a hierarchical
service, there is no problem registering your NA, and URN-resolution
servers will be widely available. With a single Naming Authority Service
there is inevitably a cost because it has to replicated in a few very fast
servers.

> > 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.

You are equating global with monolithic, DNS is global, its not monolithic.
Its distributed, so there is no worry about centralised control.

>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

This is what caching is all about, and removes the need for RP's.

>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.

A CERN advisory such as this is a textual document describing a breakdown in
a system, since (under normal usage) URN's should be resolved the same way
no matter where you start the process, then showing a URN resolving
differently is purely an artifact of how you right your document. E.g.
"CERT Advisory - the URN resolution cache at xyz.com is misresolving URNs
to point to trojan.horses.com instead of their real home". I can't think of
a real example where this is required.

> 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)

But in this example, you are modifying a service not a URN. In this case
you have specified a service and expected the client to know what protocols
to use to talk to it. If I see the above identifier, I'm not going to know
what protocol to talk to this service. If it is a new HTTP service which
turns URN's into citations it would be better expressed as a URL for the
search service, where the URN was a paramater of the search.
>
> >
> > 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.

In which case, analysis of this scheme really has to wait until it can be
seen whether the protocols will scale, and be resolvable in a short enough
time.

> > 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.

Of course it impedes it, these unregistered URNs are not persistent, and
without having them name a substantial portion of documents the URN service
won't scale. Its almost the same as saying we have a URN service which will
only work if its only used for a small fraction of the total documents
created.

> > 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.

I just don't believe this premise, every student at some time produces a
document that is worthy of a persistant pointer.

- Mitra

=======================================================================
Mitra mitra@kaworlds.com
Worlds Inc (415)281-1308
<http://earth.path.net/mitra> fax (415)284-9483

- Next message: weibel@oclc.org: "UR* issues for Stockholm: New WGs?"
- Previous message: Darren New: "Re: Criticism of Kidcode (was Re: KidCode: Next steps )"
- Maybe in reply to: Mitra: "Belated comments on OCLC's proposal"
- Next in thread: Vincent Tkac: "Re: Belated comments on OCLC's proposal"
- Reply: Vincent Tkac: "Re: Belated comments on OCLC's proposal"