Subject: re [URN] #fragment as :name
From: Terry Allen <[email-masked]>
To: [email-masked]
Date: Sat, 28 Feb 1998 10:55:22 -0800

Al Gilman wrote:
| If one adopts a namespace mindset, the existing use of #fragment
| is "Interpret 'fragment' by the [y'know...] customary usage for
| the [type of] the object found under the preceeding URI."

The existing use of #fragment addressing is in HTML,
which defines the presentation semantics of links that use
such addressing.  XML imposes no such constraint, and the
presentation (and other) semantics of #fragment addressing
may well vary according to the linking elements used within
a single XML DTD.  It's just addressing, it isn't anything
about interpretation.

| In this usage, the object is free to define its own interior 
| namespace.  This total independence of the name scheme used at
| this level from any schemes used in exterior contexts is what
| the URN community may not be anticipating.

An XML document can contain ID attributes, yes.  I'm certainly 
anticipating it.  And I can link to elements containing
ID attribute values or any other attribute values using various 
kinds of addressing.  And to lots of other things, including 
single characters.

| In the schemes that the URN community is contemplating, this is
| probably not true.  Once one enters a namespace discipline, one
| may not expect interior namespaces to be randomly declared by
| the values found for exterior names.

A document may have some attribute
values in it, and those may be considered to be from its name
space (although they might well be drawn from or share other name 
spaces).  If I want to give such a document a URN, I might also
wish to assign URNs to some or all of its ID attribute values.
I might want to construct my name space so that these ID
attribute values are assigned according to its rules (as ID
attribute values are supposed to be unique, most folks I know use
a nonrandom method of generating them, so I I don't know what
the force of "randomly declared" is).

What's the point?

Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html

From: Al Gilman <[email-masked]>
Subject: [URN] #fragment as :name
To: [email-masked], [email-masked]
Date: Sat, 28 Feb 1998 11:40:08 -0500 (EST)
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

This is an observation, not a proposal.

It appears to me that the established uses of #fragment with HTML
documents, and the proposed extensions with XML documents (which
are designed to be compatible with the HTML-driven uses) are all
cases where what follows the # character is a name reference.

It is a reference to a name defined in a namespace which is in
turn defined by the object identified in the preceding name.
It is a "classic case of namespace descent."  The spelling might
as easing be scheme:stuff:fragment where stuff comprises the
<site> and <path> parts in conventional URL usage.

It is the fact that ID and NAME are both attribute designators
from a common namespace that lets Lynx treat IDs in HTML in a
manner "homologous to #name" and extend the scope of #name to
include #[name | id] with no damage whatsoever.

If one adopts a namespace mindset, the existing use of #fragment
is "Interpret 'fragment' by the [y'know...] customary usage for
the [type of] the object found under the preceeding URI."

In this usage, the object is free to define its own interior 
namespace.  This total independence of the name scheme used at
this level from any schemes used in exterior contexts is what
the URN community may not be anticipating.

In the schemes that the URN community is contemplating, this is
probably not true.  Once one enters a namespace discipline, one
may not expect interior namespaces to be randomly declared by
the values found for exterior names.

Al Gilman

From: "Sam X. Sun" <[email-masked]>
To: "Archie" <[email-masked]>, "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
Date: Sat, 28 Feb 1998 02:01:53 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

Archie wrote:
>...
>So, what happens to name resolution times when we get something like 10**N
>(pick your favorite stressful value of N) documents in the system?
>

Sorry I didn't quite understand your question.  And I guess that you are
asking the total number of round trips required to resolve 10**N (10 to the
power N) number of handles.

The answer to this will depend on how these handles are related. In one
extreme case, if all these handles are registered under the same naming
authority, then the total number of round trips could be 10**N + 1. Another
extreme case could be that all these handles are from different naming
authority, and none of those naming authorities have ever been visited by
the client, then we are talking about a total of 2 * 10**N number of round
trips.

On the other hand, if all these documents are deems to be used together
again and again, the provider could probably create a handle as a reference
to a HTML document, where the HTML document contains all the references (say
URLs) of those documents. The HTML document can be generated
_programmatically_ by resolving handles of these documents. If this is the
case, the client could potentially need only one round trip to get the
information of all those documents.

Regards,
Sam
[email-masked]

From: "Sam X. Sun" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Scalability of Handle Resolution (was Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS)
Date: Sat, 28 Feb 1998 01:25:59 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

>Sam Sun writes:
> > ... (It is worth noting that although
> > the namespace is heirarchical, the resolution protocol is not, so as to
> > achieve minimum number of round trips, and to ensure global uniqueness.)
>

Daniel LaLiberte wrote:
>...
>First, we can dispense with the argument based on global uniqueness.
>Global uniquenss of the assignment of identifiers is not involved here,
>so you must be talking about global uniqueness of the resolution
>process......

Yes. What I meant is global uniqueness of the resolution. Thanks for
clearing this out.

Daniel LaLiberte wrote:
>...
>Second, I'll agree that flat (near constant time) resolution can be
>achieved and this is good for scalability, but it is important to
>examine how this is achieved and to consider the consequences.
> scheme...
>
>All that is fine from a computational standpoint, if we can assume that
>the hashing scheme doesn't have to change too frequently, but there is
>an important political/administrative control problem combined with a
>geographic distribution problem.  To be scalable, the resolution of a
>request should be processed as near to the client as possible, both to
>minimize load on remote servers and to minimize traffic on the
>intervening network.  So we must assume that we can have a copy of the
>whole global name database with servers to run it on distributed to all
>parts of the globe that need it.
>......

This was the case in the earlier versions of the Handle System. The current
version of Handle System has addressed this issue via the addition of local
handle services.

In the current Handle System implementation, the global handle service
primarily serves as the referral service to direct the handle resolution to
the responsible local handle service based on the handle's naming authority.
The local handle service, which could be homed in any individual
organization from any country, is responsible for the handles registered
under its registered naming authority.

For example, to resolve a handle “hdl_na/hdl_namestring” (where "hdl_na" is
the naming authority of the handle) from any client, normally it will
involve at most 2 round trips:

1. Query the global handle service to obtain the "service information" for
the naming authority “hdl_na”.

2. Query the local handle service specified in the "service information"
obtained from step 1, to get the handle data for "hdl_na/hdl_namestring".

Some notes about the above procedure:

a) Result of step 1 can be cached by the client so that subsequent query
under the same naming authority may need only one round trip.

b) The global handle service can be duplicated many places in the world to
make the step 1 more efficient.

c) A handle system caching server can be installed on behalf of an
organization to handle the caching on an organizational basis.

Strictly speaking, handle resolution is "hierarchical", but in a limited
fashion. That is, the number of round trips for any resolution is always
less than 3. This is different from the DNS resolution where the number of
round trips could be as many as the number of <subdomain>s in the DNS name.

On the other hand, caching "service information" allows subsequent handle
resolution to be performed in a single step. But the "service information"
has to be obtained from the global handle service to guarantee global
resolution uniqueness. This is different from DNS resolution, which
essentially does a local lookup first, and there is no global coordination
if the name is found in the local database (imagine the situation where the
local administrator decides to add a <subdomain> and not bothering to
register it with the upper domain).

Regards,
Sam
[email-masked]

Date: Fri, 27 Feb 1998 16:04:39 -0500
From: <[email-masked]>
To: "Sam Sun" <[email-masked]>
Cc: [email-masked]
Subject: [URN] Scalability of Handle Resolution (was Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS)
Sender: [email-masked]
Reply-To: <[email-masked]>

Sam Sun writes:
 > ... (It is worth noting that although
 > the namespace is heirarchical, the resolution protocol is not, so as to
 > achieve minimum number of round trips, and to ensure global uniqueness.)

This has been a long-standing concern of mine.  I was happy when the
handle system began to support hierarchical name spaces, due in large
part to the influence of Bill Arms, I believe, but the flat resolution
mechanism is a problem.   

First, we can dispense with the argument based on global uniqueness.
Global uniquenss of the assignment of identifiers is not involved here,
so you must be talking about global uniqueness of the resolution
process, such that everyone gets the same piece of information when
resolving an identifier.  Doing resolution in a globally unique manner
is not a problem if you don't have to worry about scalability.  But if
we combine the requirement for scalable resolution with the requirement
for globally unique resolution, we have something to worry about.

Second, I'll agree that flat (near constant time) resolution can be
achieved and this is good for scalability, but it is important to
examine how this is achieved and to consider the consequences.  My
understanding is that the handle system achieves flat resolution by
using an identifier essentially as a hash key where the buckets are a
set of global servers known to clients.  If the hash scheme changes, due
to growth of the name space (or other causes), then the old hash keys
will continue to work because the servers will continue to map the old
hashes into the new hashes and provide clients with the new hash scheme.

All that is fine from a computational standpoint, if we can assume that
the hashing scheme doesn't have to change too frequently, but there is
an important political/administrative control problem combined with a
geographic distribution problem.  To be scalable, the resolution of a
request should be processed as near to the client as possible, both to
minimize load on remote servers and to minimize traffic on the
intervening network.  So we must assume that we can have a copy of the
whole global name database with servers to run it on distributed to all
parts of the globe that need it.  It is, after all, a global name space
so everyone on the globe should have the same access to it.

Now the political problem may become apparent.  Why should Iran be
required to host servers for all the satanic U.S. names, and vice versa?
Furthermore, the number of replicas of this global database grows as a
product of the number of clients and the number of names.  Now we can
avoid both these problems by not making complete replicas of the global
database, but only caching pieces of the resolution (e.g. what URL a URN
resolves to) in nearby databases.  And if the local cache does not have
what we need, we then can ask nearby caches, etc, until we get to the
either the one global cache that has what we want, or we get to a server
closer to the origin of the data.  

But note that what we have done is we turned a single-step hash lookup
resolution into a multi-step resolution, of necessity, to avoid the
scalability problems.  Furthermore, the resolution of one
identifier does not help us resolve any other identifiers since they are
each completely independent of the others in how they are hashed and
where we might end up resolving them.  In other words, we cannot take
advantage of locality-of-reference where users typically will request
many identifiers associated with the same location.

Now a hierarchical resolution mechanism can provide the same scalable
resolution from the outset, and also take advantage of
locality-of-reference.

Consider that the scalable DNS resolution mechanism is very
hierarchical, and where it falls short is the same place it has not
taken advantage of the hierarchy: the .com domain.

--
Daniel LaLiberte
 [email-masked]  (was: [email-masked])
 [email-masked]

From: "Archie" <[email-masked]>
To: "Sam Sun" <[email-masked]>, "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [URN] Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
Date: Fri, 27 Feb 1998 15:59:03 -0500
Sender: [email-masked]
Reply-To: "Archie" <[email-masked]>

>The DOI namespace, a sub-namespace of Handle System name space, _is_
>heirarchical.  In terms of DOI, this hierarchy is reflected in the DOI
>"Prefix", and the way it is assigned or used. The DOI "Prefix" is
equivalent

Thanks.  That clears up one issue.

>define its own sub-namespace, and so on. (It is worth noting that although
>the namespace is heirarchical, the resolution protocol is not, so as to
>achieve minimum number of round trips, and to ensure global uniqueness.)

So, what happens to name resolution times when we get something like 10**N
(pick your favorite stressful value of N) documents in the system?

Archie

-- Archie Warnock                           Internet:  [email-masked]
-- A/WWW Enterprises                        Phone/FAX: 301-854-2987
--         http://www.clark.net/pub/warnock/awww.html
--       As a matter of fact, I _do_ speak for my employer.

From: "Sam Sun" <[email-masked]>
To: "Archie" <[email-masked]>, "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [URN] Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
Date: Fri, 27 Feb 1998 14:30:49 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

DOI is an application of the Handle System (http://www.handle.net), which is
a global name service. Every DOI is a Handle in the Handle System, and DOIs
are registered and resolved using Handle System Resolution and
Administration protocols.

The DOI namespace, a sub-namespace of Handle System name space, _is_
heirarchical.  In terms of DOI, this hierarchy is reflected in the DOI
"Prefix", and the way it is assigned or used. The DOI "Prefix" is equivalent
to the Naming Authority in the Handle System, which serves as an
administrative unit for a sub-namespace, and the sub-namespace could in term
define its own sub-namespace, and so on. (It is worth noting that although
the namespace is heirarchical, the resolution protocol is not, so as to
achieve minimum number of round trips, and to ensure global uniqueness.)

Regards,
Sam
[email-masked]

-----Original Message-----
From: Archie <[email-masked]>
To: John C. Mallery <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, February 26, 1998 6:09 PM
Subject: Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS

>>AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
>>The Association of American Publishers, in conjunction with the
Corporation
>>for National Research Initiatives, has developed an electronic
>>identification system for materials on the Internet.  The digital object
>
>
>Very interesting.  From checking out the site at doi.org, it appears
they're
>using the Handle system.  A friend of mine and I were speculating on what
>happens when there are something like 10**14 documents registered.  Doesn't
>it seem like a hierarchical system would do the job more efficiently here?
>Or is there such an architecture now behind the handles?
>
>Archie
>
>-- Archie Warnock                           Internet:  [email-masked]
>-- A/WWW Enterprises                        Phone/FAX: 301-854-2987
>--         http://www.clark.net/pub/warnock/awww.html
>--       As a matter of fact, I _do_ speak for my employer.
>
>

From: "Archie" <[email-masked]>
To: "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [URN] Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
Date: Thu, 26 Feb 1998 18:01:39 -0500
Sender: [email-masked]
Reply-To: "Archie" <[email-masked]>

>AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
>The Association of American Publishers, in conjunction with the Corporation
>for National Research Initiatives, has developed an electronic
>identification system for materials on the Internet.  The digital object

Very interesting.  From checking out the site at doi.org, it appears they're
using the Handle system.  A friend of mine and I were speculating on what
happens when there are something like 10**14 documents registered.  Doesn't
it seem like a hierarchical system would do the job more efficiently here?
Or is there such an architecture now behind the handles?

Archie

-- Archie Warnock                           Internet:  [email-masked]
-- A/WWW Enterprises                        Phone/FAX: 301-854-2987
--         http://www.clark.net/pub/warnock/awww.html
--       As a matter of fact, I _do_ speak for my employer.

Date: Thu, 26 Feb 1998 07:51:18 -0500
To: [email-masked], [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS
The Association of American Publishers, in conjunction with the Corporation
for National Research Initiatives, has developed an electronic
identification system for materials on the Internet.  The digital object
identifier (DOI) system links would-be content-users with content
copyright-owners through alphanumeric "tags" attached to each work.  The AAP
hopes the system could eventually be used to restrict access to copyrighted
works, but for now, it's strictly an honor system.  The DOI system will be
maintained and administered by the newly formed International DOI
Foundation.  http://www.doi.org  (CIO 15 Feb 98)

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Document Action: Using Existing Bibliographic Identifiers as Uniform Resource Names to Informational
Date: Wed, 18 Feb 1998 09:50:39 -0500
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

The IESG has approved the Internet-Draft 'Using Existing Bibliographic
Identifiers as Uniform Resource Names' <draft-ietf-urn-biblio-02.txt>
as a Informational.  This document is the product of the Uniform
Resource Names Working Group.  The IESG contact persons are Harald
Alvestrand and Keith Moore.

Date: Thu, 12 Feb 1998 01:18:02 +0100
To: "Kent S. Larsen II" <[email-masked]>, [email-masked]
From: Jacob Palme <[email-masked]>
Subject: [URN] Re: List-ID review
Cc: Jamie Zawinski <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: Jacob Palme <[email-masked]>

At 18.07 -0500 98-02-11, Kent S. Larsen II wrote:
>>You can see it as a problem, you can also see it as an advantage: It is
>>possible to associate these lists with the original newsgroup, so if
>>someone gets a 'crossposted' message to <news:comp.bla> from another
>>mailing list, s/he might be able to use the newsgroup directly or
>>another mailing list tied to the same newsgroup for a followup.
>
>I agree that this is a fairly clean solution, but I think it needs to be
>expanded a little. I don't know the relevant rfcs, but don't you need a
> mechanism for specifying the newsgroup host?
>
>I know that there are many newsgroups that are not available beyond one
>server!

I do not think there is, yet, any standard for a URN space for Usenet
News. When someone writes such a standard, then it seems very necessary
that this standard handle the problem of local newsgroups. It is
conceivable that two local newsgroups in two news hosts have the
same name, although usually not, since local newsgroups are usually
prefixed in a way which shows the region. For example, all the
local Swedish newsgroups have names beginning with "swnet.".

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme