an "@" is a string whose internal ordering is defined by the file
system on the host, which may be defined high order to low order,
left to right. Of course, much more complex and nested syntaxes
should be possible, especially given the need to grandfather
namespaces. In order to resolve URNs, rules will be needed for two
reasons. One is simply to canonicalize those namespaces that do not
fall into a straightforward (probably right to left or left to right)
ordering of the components of a URN, as determined by the delegated
naming authorities involved. It is also possible that rules will be
needed in order to derive from URNs the names of RDS servers to be
used in stages.
URN:<NID><NSS>
|
|
|
|
v
+-------------------+
|Global NID registry|
+-------------------+
|
|
|
(return rule or URN resolver service reference)
|
+----------------------------------+
| |
+->(apply rule to determine RDS server) |
| | |
| | |
| | |
| +----------+ |
| |RDS server| +-----------------+
| +----------+ |
| | | v
| | | (set of choices)
| | +----+----------(...)--------+
| (rule) | |
| | | |
| | | |
+------+ | |
v v
+----------+ +----------+
|URN | |URN |
|resolver | |resolver |
|service | |service |
+----------+ +----------+
Figure 1: An RDS framework
The NID defines a top level syntax. This syntax will determine
whether the NID alone or in conjunction with some extraction from the
NSS (for the top level naming authority name) is to be used to
identify the first level server to be contacted. At each stage of
the lookup either a new rule for generating the strings used in yet
another lookup (the strings being the identity of another RDS server
and possibly a string to be resolved if it is different than the
original URN) or a reference outside the RDS to a URN resolver
service, sidestepping any further use of the RDS scheme. Figure 1
depicts this process.
There are several points worth noting about the RDS framework.
First, it leaves open the determination of the protocols, data
organization, distribution and replication needed to support a
particular RDS scheme. Second, it leaves open the location of the
computations engendered by the rules. Third, it leaves open the
possibility that partitioning (distribution) of the RDS database need
not be on the same boundaries as the name delegation. This may seem
radical to some, but if the information is stored in balanced B-trees
for example, the partitioning may not be along those naming authority
delegation boundaries (see [7]). Lastly, it leaves open access to
the Global NID Registry. Is this distributed to every client, or
managed in widely distributed servers? It is important to note that
it is the intention here that a single RDS scheme is likely to
support names from many or all naming schemes, as embodied in their
NIDs.
One concept that has not been addressed in Figure 1 is that there may
be more than one RDS available at any given time, in order to allow
for evolution to new schemes. Thus, the picture should probably look
more like Figure 2.
URN:<NID>:<NSS>
|
|
+-----------+-------(...)-------+
| |
| |
| |
v v
+---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+
. .
. .
. .
Figure 2: More than one co-existing RDS scheme
If we are to support more than one co-existing RDS scheme, there will
need to be coordination among them with respect to storage and
propagation of information and modifications. The issue is that
generally it should be assumed that all information should be
available through any operational RDS scheme. One cannot expect
potential publishers to submit updates to more than one RDS scheme.
Hence there will need to be a straightforward mapping of information
from one to the other of these schemes. It is possible that that
transformation will only go in one direction, because a newer RDS
service is replacing an older one, which is not kept up to date, in
order to encourage transfer to the newer one. Thus, at some point,
updates may be made only to the newer one and not be made available
to the older one, as is often done with library catalogs.
This framework is presented in order to suggest to RDS scheme
designers a direction in which to start designing. It should be
obvious to the reader that adherence to this framework will in no way
guarantee compliance with the guidelines or even the assumptions
described in Sections 2 and 3. These must be reviewed independently
as part of the design process. There is no single correct design
that will conform to these guidelines. Furthermore, it is assumed
that preliminary proposals may not meet all the guidelines, but
should be expected to itemized and justify any lack of compliance.
5. Acknowledgments
Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a preliminary URN requirements document and for his
insightful comments on this version of the document. Thanks also go
to Ron Daniel especially for his many comments on my writing. In
addition, I recognize the contributors to a previous URN framework
document, the "Knoxville" group. There are too many of you to
acknowledge here individually, but thank you. Finally, I must thank
the contributors to the URN working group and mailing list (urn-
ietf@bunyip.com), for your animated discussions on these and related
topics.
6. References
[1] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC1736, February 1995.
[2] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC1738, December 1994.
[3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
Locators (URL)", RFC1738, December 1994.
[4] URN Working Group, "Namespace Identifier Requirements for URN
Services," Work in Progress.
[5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High-
Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983,
pp. 135-171.
[6] Moats, R., "URN Syntax", RFC2141, May 1997.
[7] Slottow, E.G., "Engineering a Global Resolution Service," MIT-
LCS-TR712, June, 1997. Currently available as
<http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or
<http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.
7. Author's Address
Karen Sollins
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu
8. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.