# Belated comments on OCLC's proposal

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: new port for DNS"
- Previous message: Alexander Dupuy: "Re: new port for DNS"
- Next in thread: Keith Moore: "Re: Belated comments on OCLC's proposal"
- Reply: Keith Moore: "Re: Belated comments on OCLC's proposal"
- Maybe reply: weibel@oclc.org: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Mitra: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Paul Hoffman: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Mitra: "Re: Belated comments on OCLC's proposal"

    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

- Next message: Michael Mealling: "Re: new port for DNS"
- Previous message: Alexander Dupuy: "Re: new port for DNS"
- Next in thread: Keith Moore: "Re: Belated comments on OCLC's proposal"
- Reply: Keith Moore: "Re: Belated comments on OCLC's proposal"
- Maybe reply: weibel@oclc.org: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Mitra: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Paul Hoffman: "Re: Belated comments on OCLC's proposal"
- Maybe reply: Mitra: "Re: Belated comments on OCLC's proposal"