Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

The discussion of Naming Authorities with or without a scheme implies a
decision whether we want to register one name only (NA) or two: a NA + a
scheme.
This implies again two registers (or a two tiered register).
NA may in itself contain implicitly some information on resolution
mechanisms or syntactic or semantic structure of the rest of the URN.

Could one define something like
NA:[scheme]:<opaque identifier>
?
I am not sure whether the double colon is an appropriate syntax. But the
idea is to have both a naming authority + optionally a scheme. To be useful
to the client, he has to know about the scheme (at least in his
environment). This needs some publicity for the scheme. While the publicity
of the scheme may be initially better than that of a naming authority, the
long term development is not clear.

It comes to the problem whether one believes the naming authorities to be a
better choice for a persistent name space, or a (published) scheme.
Logically one may invert their role. If one is on top it is wise to be
restrictive in registering top authorities (or top schemes).

If there is only one kind of top level registries (administrating both: NAs
and schemes) the problem is most likely not extremely important.

Probably the role of NA and scheme-name are somewhat interchangable. But
one could postulate the NA should be 'more' of the type of a social
institution/organisation while the scheme would provide some information on
a) the syntax
b) the semantics of the <opaque name>
(both or one of them)

If both names characterise the namespace uniquely they are redundant (but
may still be advisable for some organisations).
If they are jointly necessary to characterise the resource they may still
provide two different paths to resolution

(1. the representative of the NA informs about the scheme
    [provides e.g a helper application] versus
 2. the name of the scheme may give a hint about which - e.g. local-
institution to contact before employing a global resolution service. The
scheme may be even a guide to resolution - as long as clients and their
environment support it).

This may be true even if the scheme defines just the next branch in a tree
structure.

*****
Relative URNs may exist, but they will be restricted to specific Naming
Authorities (and/or schemes). They should not be a part of a generic
definition.
---------------------
At 04:35 h 1995.11.29, Keith Moore wrote:
>> > I don't know how I can make this any clearer:
>If we give the client a way to differentiate between URN "schemes",
>on one hand,
>
>  + we can make potentially make resolution more efficient, because
>    the client can customize its search path on a per-scheme basis.
>    (If the client doesn't know the "scheme", it's not a matter of
>    not being able to resolve the URN, it's a matter of having to look
>    in potentially more places before it finds it.)
>  + it makes it easy for people to understand how other naming schemes
>    are incorporated into URN-space
>  + we make some unhappy people happier, which may bring us closer to
>    agreement.  (I'm not being facetious here; it's often better to
>    have a standard with some "imperfections" than no standard at all.)
>  + to the extent that it's useful for a client to know the
>    syntax and semantics of a URN (for reasons other than resolution),
>    having the "scheme" name be visible makes that possible.
>
>    (however, I'm not sure whether what you call "semantics" of a URN
>    was included in the Knoxville URN at all; we had agreed that
>    things like service requests were not part of the URN but
>    that there was a need to be able to specify those things in
>    a standard manner along with a URN)
>
>on the other hand,
>
>  - it increases the probability of client configuration error
>  - if schemes tend to imply particular resolution protocols,
>    they decrease persistence of URNs
>  - schemes increase the probability that the client cannot resolve
>    a URN because it doesn't know about the "scheme", which in turn
>    reduces interoperability
>  - they make it less likely that URNs have global scope in practice
>    (since the interpretation of a URN is up to the client, and it
>    tempts clients to make special interpretation based on the "scheme")
>
>I don't know of any way to objectively decide whether the benefits
>of having a "scheme" outweigh the disadvantages.  My experience with
>multiprotocol email leads me to believe that having one "scheme"
>that is flexible enough to subsume all others, and putting the
>details of how to resolve names in a network-accessible database,
>is far preferable to expecting each client to know the details
>of each "scheme".
>
...
>I could personally live with having a "name space identifier" (NSI)
>in the URN as long as (a) it's not strictly tied to a protocol or
>registry, (b) the resolution of the URN doesn't depend on the client
>knowing details of the NSI portion of the URN, (c) a registry can
>delegate resolution of URNs on at least a per-(NSI+NA) basis (and
>ideally, to smaller sub-ranges of that space).
.....
>> A scheme defines the syntax and
>> semantics associated with the remainder of the identifier.  It does not
>> define the resolution protocol; some identifiers have a scheme name which
>> matches a protocol name because that is the most meaningful name to
>> associate with a locator for which the ultimate resolution process defaults
>> to using that protocol.  In other words, the Knoxville proposal is using
>> the scheme "URN".
>
...
>> And how does the client get "configured to consult one of the registries"?
>
>By default, it's shipped to point to whatever registry is in vogue when
>the client was built; the site or user can customize it based on local
>needs and practice but IT WORKS OUT OF THE BOX for most users in
>most environments.
>
>> The WWW mechanism for doing this depends on the existence of scheme names.
>
>Yes, but that mechanism makes it very difficult to deploy new "schemes".
>(and a URL "scheme" isn't the same thing as a URN "scheme", at least,
>not to everybody)
>
********
>> Relative URL parsing depends on the existence of scheme names.
>
>We're talking about URNs, not URLs.  And if you have URNs you don't need
>relative URLs.  There are enough potential problems with extending Relative
>URLs to the URN world that I am very dubious of requiring "relative URNs" in
>URN space.
...
>> > Nothing about our proposal requires the client to use the URN registries.
>> > But if we were to design a scheme such that a client NEEDS "to define,
>> > without reference to any network, how identifiers are to be resolved",
>> > THAT would be undesirable.
>> >
>> > As for being able to "resolve" a URN without being connected to the
>>network...
>> > I don't know what this means.  Either the client has access to the
>>external
>> > services it needs to make use of a URN, or it doesn't.  If the client
>>doesn't
>> > have access to those services, the URN isn't very useful to the client
>> > except for comparison with other URNs.
...
>
>Keith


PeterPaul.Sint@oeaw.ac.at
Research Unit for Socio-Economics, Austrian Academy of Sciences
Kegelgasse 27, A-1030 Wien, Austria.
Phone:(+431) 712 21 40 - 36   Fax: (+431) 712 21 40 - 34

Received on Wednesday, 29 November 1995 22:46:24 UTC