2004/id/draft-ietf-uri-urn-res-thoughts-00.txt


Network Working Group                                Karen R. Sollins
INTERNET-DRAFT                                                MIT/LCS
<draft-ietf-uri-urn-res-thoughts-00.txt>
Expires: December 26, 1995                              June 26, 1995


      Thoughts on Standardizing URN Resolution Protocols
                      Karen R. Sollins
                           MIT/LCS
                     sollins@lcs.mit.edu

                         Abstract

The problem of standardizing URN resolution needs to be thought
through carefully.  If we partition the problem of name resolution, it
becomes clearer that the user to resolution service interaction should
be standardized.  In contrast, in order to support a variety of
models, behaviors, and other policies for name resolution services,
we must allow for a multiplicity of such services, each perhaps
requiring a different protocol between its servers.  The URI group can
still limit its efforts, but should support more than one such
service as a proof of concept that multiple service types can be
supported.

                        Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
 
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).


1 Introduction

The IETF is general a standards organization.  As such, part of its
task is to determine what should and what should NOT be standardized.
In this note, I explore this question with respect to URN resolution,
which the Uniform Resource Identifiers Working Group is now
considering.  But first, consider two conflicting goals in the
standards process.  From one perspective, there is strong motivation
to maximize the scope of standards.  This leads to a simple,
uniformity by minimizing diversity, with the result that mechanism and
implementation can probably be simplified and streamlined.  At the
other extreme is a path of no standardization in which there is
nothing but diversity, with no commonality that can be assumed by
clients of the service being considered.  Generally, a middle ground
is most effective but the question always must be where the boundary
is.

Additionally, when considering the problems of name resolution, it is
important to remember that one can separate the problems or activities
of name assignment from name resolution.  In order to allow for names
to be equally resolvable in perpetuity (or even just 100 years), it
will be important not to burden the name asigner with the
responsibility for a name resolution service.  Since resources may
move or evolve in unpredictable ways it is not reasonable even to
expect that a particular service will necessarily guarantee to provide
name resolution service for a particular namespace or piece of the
namespace with a granularity larger than one.  This may happen, but it
should not be expect or legislated without understanding the serious
consequences of severe limitations on the client community.  With all
this in mind, this note concentrates on the question of standardizing
name resolution.


2 Partitioning the problem

Now, consider name resolution.  First we will address a partitioning
of the problem of name resolution.  This partitioning is not new, and
has certainly been seen before in other standards activities with
respect to name resolution, for example the DNS and X.500.  In both
cases, the universe of discourse is partitioned into clients and
servers.  In both cases, the interfaces or protocols for servers are
clearly distinguished between that for clients to communicate with
servers and that for servers to communicate among themselves.  The
client interfaces describe client requests for name resolution, while
server interfaces describe both server requests for resolution and
inter-server information addition, deletion, and modification, as well
as perhaps cache maintenance and any other maintenance and
distribution mechanisms for making translation information available
among the servers.

2.1 Server Behavior

In that context, consider URNs.  URNs are intended to name an
extremely broad set of resources, in fact, anything that anyone wishes
to make public by naming in the Internet.  Ubiquity and penetration as
well as quantity are expected to be many orders of magnitude greater
than the resources of either the DNS or X.500.  In addition, there may
be different sorts of performance requirements for different sorts of
resources by different sorts of clients or customers.  For example,
for the human to send a piece of email, the location resolution might
be adequately provided in 10 minutes, . while, if the human is asking
for the locations of resources on the Schumacher-Levy 9 comet in
realtime as part of some complex piece of research there may be a
cascading set of resolution requirements, leading to each one needing
to be orders of magnitude faster.  In addition, there may be multiple
answers to such a request from different kinds of sources, online data
sets, published papers, or a computation service that might analyze
observations on the fly.

One conclusion one might draw from this is that there may be widely
differing requirements or at least expectations for what one might
call auxilliary characteristics of name resolution services.  In some
cases, it may be particularly useful that they be replicated widely.
For example, telephone directories are distributed to every office and
home with a telephone.  As a first cut at causing email to be
delivered to the location at which the recipient is receiving mail,
one might consider distributing email address resolution information
for everyone, for example, to be widely replicated.  One reason this
sort of information can be widely replicated is that it doesn't change
frequently, so exceptional behavior (which is generally much more
expensive) in the face of changes will not need to be utilized
frequently.  In contrast, information about the location of most
satellites changes so frequently that a completely different set of
mechanisms for managing and therefore finding that information will be
needed.  Another interesting characteristic of some kinds of
resolution information is the need for it to be reliably correct.  If
recourse to an exceptional mechanism is prohibitatively expensive or
simply unavailable, it becomes much more important that updates of
information be reliably updated, so that they will not be lost.  One
might choose some atomic transaction mechanism with a great deal of
redundancy, recognizing that it would be out of the question for the
200 million or more telephone books scattered around the country.
What we are seeing here is that there will be a broad spectrum of
interesting, useful, perhaps requisite behaviors from name resolution
services with the conclusion that very different protocols will be
required among the servers that are providing such characteristics of
their services in some coordinated fashion.

2.2 Client-server behavior

In contrast with this, consider the clients of the name resolution
services.  At their most basic level, they want name resolution.  They
have a URN and they want some location and access method information.
In fact, for generality, it is desirable that applications not need to
know exactly which sorts of name resolution services will be
supporting them.  This allows for portability and longevity of code.
If an application needs an extremely fast response, it may be equally
satisfied with a local, atomically updated reliable service, or the
ubiquitous telephone book equivalent, if both have the same
information and can respond equally quickly.  In fact, the application
may not care to know which sort was used.  From the client or
application's perspective, the name resolution service should handle
requests for name resolution however it does it best, and for
modularity the client shouldn't need to know what that is.  Thus, in
contrast with the server-server protocol(s), we can conclude that the
client-server protocol for name resolution is a good candidate for
standardization; there is a big payoff and probably little penalty.

3. Conclusion

There is still a discussion that should be had within the URI Working
Group about one versus many server-server protocols.  I believe that
it is important that we design an architecture that permits more than
one, but there are strong arguments in favor of not spreading the
efforts too thin.  I suggest that as a community we should put our
concerted efforts into no less than two, for a proof of concept and
demonstration of the generality required and supportable, but keep the
number quite small, perhaps no more than three.


Expires: December 26, 1995                              June 26, 1995
1
2	Network Working Group Karen R. Sollins
3	INTERNET-DRAFT MIT/LCS
4	<draft-ietf-uri-urn-res-thoughts-00.txt>
5	Expires: December 26, 1995 June 26, 1995
6
7
8	Thoughts on Standardizing URN Resolution Protocols
9	Karen R. Sollins
10	MIT/LCS
11	sollins@lcs.mit.edu
12
13	Abstract
14
15	The problem of standardizing URN resolution needs to be thought
16	through carefully. If we partition the problem of name resolution, it
17	becomes clearer that the user to resolution service interaction should
18	be standardized. In contrast, in order to support a variety of
19	models, behaviors, and other policies for name resolution services,
20	we must allow for a multiplicity of such services, each perhaps
21	requiring a different protocol between its servers. The URI group can
22	still limit its efforts, but should support more than one such
23	service as a proof of concept that multiple service types can be
24	supported.
25
26	Status of this Memo
27
28	This document is an Internet-Draft. Internet-Drafts are working
29	documents of the Internet Engineering Task Force (IETF), its areas,
30	and its working groups. Note that other groups may also distribute
31	working documents as Internet-Drafts.
32
33	Internet-Drafts are draft documents valid for a maximum of six months
34	and may be updated, replaced, or obsoleted by other documents at any
35	time. It is inappropriate to use Internet- Drafts as reference
36	material or to cite them other than as ``work in progress.''
37
38	To learn the current status of any Internet-Draft, please check the
39	``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
40	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
41	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
42	ftp.isi.edu (US West Coast).
43
44
45	1 Introduction
46
47	The IETF is general a standards organization. As such, part of its
48	task is to determine what should and what should NOT be standardized.
49	In this note, I explore this question with respect to URN resolution,
50	which the Uniform Resource Identifiers Working Group is now
51	considering. But first, consider two conflicting goals in the
52	standards process. From one perspective, there is strong motivation
53	to maximize the scope of standards. This leads to a simple,
54	uniformity by minimizing diversity, with the result that mechanism and
55	implementation can probably be simplified and streamlined. At the
56	other extreme is a path of no standardization in which there is
57	nothing but diversity, with no commonality that can be assumed by
58	clients of the service being considered. Generally, a middle ground
59	is most effective but the question always must be where the boundary
60	is.
61
62	Additionally, when considering the problems of name resolution, it is
63	important to remember that one can separate the problems or activities
64	of name assignment from name resolution. In order to allow for names
65	to be equally resolvable in perpetuity (or even just 100 years), it
66	will be important not to burden the name asigner with the
67	responsibility for a name resolution service. Since resources may
68	move or evolve in unpredictable ways it is not reasonable even to
69	expect that a particular service will necessarily guarantee to provide
70	name resolution service for a particular namespace or piece of the
71	namespace with a granularity larger than one. This may happen, but it
72	should not be expect or legislated without understanding the serious
73	consequences of severe limitations on the client community. With all
74	this in mind, this note concentrates on the question of standardizing
75	name resolution.
76
77
78	2 Partitioning the problem
79
80	Now, consider name resolution. First we will address a partitioning
81	of the problem of name resolution. This partitioning is not new, and
82	has certainly been seen before in other standards activities with
83	respect to name resolution, for example the DNS and X.500. In both
84	cases, the universe of discourse is partitioned into clients and
85	servers. In both cases, the interfaces or protocols for servers are
86	clearly distinguished between that for clients to communicate with
87	servers and that for servers to communicate among themselves. The
88	client interfaces describe client requests for name resolution, while
89	server interfaces describe both server requests for resolution and
90	inter-server information addition, deletion, and modification, as well
91	as perhaps cache maintenance and any other maintenance and
92	distribution mechanisms for making translation information available
93	among the servers.
94
95	2.1 Server Behavior
96
97	In that context, consider URNs. URNs are intended to name an
98	extremely broad set of resources, in fact, anything that anyone wishes
99	to make public by naming in the Internet. Ubiquity and penetration as
100	well as quantity are expected to be many orders of magnitude greater
101	than the resources of either the DNS or X.500. In addition, there may
102	be different sorts of performance requirements for different sorts of
103	resources by different sorts of clients or customers. For example,
104	for the human to send a piece of email, the location resolution might
105	be adequately provided in 10 minutes, . while, if the human is asking
106	for the locations of resources on the Schumacher-Levy 9 comet in
107	realtime as part of some complex piece of research there may be a
108	cascading set of resolution requirements, leading to each one needing
109	to be orders of magnitude faster. In addition, there may be multiple
110	answers to such a request from different kinds of sources, online data
111	sets, published papers, or a computation service that might analyze
112	observations on the fly.
113
114	One conclusion one might draw from this is that there may be widely
115	differing requirements or at least expectations for what one might
116	call auxilliary characteristics of name resolution services. In some
117	cases, it may be particularly useful that they be replicated widely.
118	For example, telephone directories are distributed to every office and
119	home with a telephone. As a first cut at causing email to be
120	delivered to the location at which the recipient is receiving mail,
121	one might consider distributing email address resolution information
122	for everyone, for example, to be widely replicated. One reason this
123	sort of information can be widely replicated is that it doesn't change
124	frequently, so exceptional behavior (which is generally much more
125	expensive) in the face of changes will not need to be utilized
126	frequently. In contrast, information about the location of most
127	satellites changes so frequently that a completely different set of
128	mechanisms for managing and therefore finding that information will be
129	needed. Another interesting characteristic of some kinds of
130	resolution information is the need for it to be reliably correct. If
131	recourse to an exceptional mechanism is prohibitatively expensive or
132	simply unavailable, it becomes much more important that updates of
133	information be reliably updated, so that they will not be lost. One
134	might choose some atomic transaction mechanism with a great deal of
135	redundancy, recognizing that it would be out of the question for the
136	200 million or more telephone books scattered around the country.
137	What we are seeing here is that there will be a broad spectrum of
138	interesting, useful, perhaps requisite behaviors from name resolution
139	services with the conclusion that very different protocols will be
140	required among the servers that are providing such characteristics of
141	their services in some coordinated fashion.
142
143	2.2 Client-server behavior
144
145	In contrast with this, consider the clients of the name resolution
146	services. At their most basic level, they want name resolution. They
147	have a URN and they want some location and access method information.
148	In fact, for generality, it is desirable that applications not need to
149	know exactly which sorts of name resolution services will be
150	supporting them. This allows for portability and longevity of code.
151	If an application needs an extremely fast response, it may be equally
152	satisfied with a local, atomically updated reliable service, or the
153	ubiquitous telephone book equivalent, if both have the same
154	information and can respond equally quickly. In fact, the application
155	may not care to know which sort was used. From the client or
156	application's perspective, the name resolution service should handle
157	requests for name resolution however it does it best, and for
158	modularity the client shouldn't need to know what that is. Thus, in
159	contrast with the server-server protocol(s), we can conclude that the
160	client-server protocol for name resolution is a good candidate for
161	standardization; there is a big payoff and probably little penalty.
162
163	3. Conclusion
164
165	There is still a discussion that should be had within the URI Working
166	Group about one versus many server-server protocols. I believe that
167	it is important that we design an architecture that permits more than
168	one, but there are strong arguments in favor of not spreading the
169	efforts too thin. I suggest that as a community we should put our
170	concerted efforts into no less than two, for a proof of concept and
171	demonstration of the generality required and supportable, but keep the
172	number quite small, perhaps no more than three.
173
174
175
176
177	Expires: December 26, 1995 June 26, 1995