Belated comments on OCLC's proposal

Mitra (mitra@regis.prod.kaworlds.com)
Fri, 16 Jun 1995 09:27:42 -0700


Date: Fri, 16 Jun 1995 09:27:42 -0700
Message-Id: <ac0622b8000210043039@[204.118.158.98]>
To: uri@bunyip.com
From: mitra@regis.prod.kaworlds.com (Mitra)
Subject: Belated comments on OCLC's proposal

Sorry for the tardiness, my work takes me to other areas, and to be honest
I've given up on a consensus ever being reached on URN's. Sorry if these
questions have been asked (and answered) elsewhere.

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.

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.

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.

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.

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.

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.

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.

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

Scalability: NO - see comment on 1.0 IV

Resolution: This cannot be answered since it isn't fully specified, in
particular even if we assume all Naming Resolution Servers have all the
information, and they are accessed by TCP, then we have two DNS plus two
TCP queries to resolve a URN. If those assumptions are not made, then we
potentially have an even slower process of trying to find the Resolution
Server.

- Mitra

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