Message-Id: <9310250306.AA21496@mocha.bunyip.com>
To: Mitra <mitra@path.net>
Subject: Re: URN definition -- a way out?
In-Reply-To: Your message of Sat, 23 Oct 1993 14:54:53 -0800.
<9310231454.aa16638@pandora.sf.ca.us>
Date: Sun, 24 Oct 1993 23:06:24 -0400
From: John Curran <jcurran@nic.near.net>
--------
] From: Mitra <mitra@path.net>
] Subject: Re: URN definition -- a way out?
] Date: Sat, 23 Oct 1993 14:54:53 PST
]
] Dirk,
]
] I would expect some ideas to come out of Houston on URN->URC resolution,
] Rob's done one, I've done done, I'm sure others have - its a trivial
] exercise to build a simple one, its a much harder exercise to build
] a scalable infrastructure, and without such an infrastructure
] none of us can risk using URN's in our applications.
I agree... we've avoided the URN resolution issue in the past,
and yet recognize that without the ability to obtain a valid URL
from a URN, the URN has little practical value.
I am going to briefly outline _one_ manner in which URN's might be
used; I am sure that there are many other models, and encourage folks
to compare their favorite against my scribbling below. I have not
created any additional URx elements in the process, although I'm sure
we could without much effort. :-)
Presuming that a client program has a URN, and wishes to obtain
the resource so named, it will be necessary for the client to
obtain one or more) valid URL's for the actual instances of the
resource.
Presume that the client has certain contraints about the URLs
that it may handle (for example, "gopher, ftp, html") and
furthermore that the client has preferences about the data types
that it may handle (e.g. "text/plain, text/richtext, image/gif").
One possible model for URN resolution would have the client connect
to the URN resolver service, and receive list of all known URLs for
the presented URN. In order to make use of such a list, it would
be necessary to know certain URL-specific information for each URL
returned, such as the access method, data type, size, cost, etc.
Ideally, this _instance-specific_ information would be returned with
each URL provided. The client could sort through the resulting list
and discard or prioritize each URL based on its attributes. For
extremely profilic resources, it might be preferable to provide an
attribute filter to the resolver service, so that you only get the
137 locations of the free ftp text-format instances of RFCXXXX,
rather than the complete 4912 known locations (including the US
$39.95, image/mpeg, binhexed instance, now available via BITNET NJE).
In this model, it will be very important to be able to represent
"instance attributes" in an extensible manner. I would recommend
colaboration between the various URN resolution prototypers to find
any common ground that is possible in this area.
/John
p.s. Note that I have not referenced any traditional bibliographic
attributes (such as author, subject, title). It is quite possible
that these elements also need to be present, but as elements paired
to a given URN, not URL.