2004/id/draft-ietf-uri-urn-x-dns-2-00.txt


IETF URI Working Group                                         Paul E. Hoffman
Internet-Draft                                               Proper Publishing
draft-ietf-uri-urn-x-dns-2-00                                  Ron Daniel, Jr.
Expires October 21, 1995                         Los Alamos National Laboratory


                              x-dns-2 URN Scheme

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.
Internet-Drafts may be updated, replaced, or obsoleted by other documents
at any time. It s not appropriate to use Internet- Drafts as reference
material or to cite them other than as a "working draft" or "work in
progress."

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained n the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu or
munnari.oz.au.

Abstract

This document defines a scheme for resolving Uniform Resource Names (URNs)
using the domain name system. The scheme, called x-dns-2, allows URN
publishers to create URN resolvers without central registration, and
without changing or adding any domain names.

1. Introduction

The x-dns-2 scheme is a URN resolution scheme. These schemes are described
in [URNO]. The main features of x-dns-2 are very easy and quick
implementation, commonly-used transport protocols, and wide range of
resolution results.

2. Syntax

The generic syntax all URN schemes must follow is described in [URNS].
Within that framework, the SchemeID for the approach described in this
draft is "x-dns-2". The ElementID has two parts, separated by a colon (hex
3A):
- The AuthorityID, the domain name of the resolving host
- The RequestID, the request that is sent to the resolving host

Thus, a typical URN using the x-dns-2 scheme might be:
<urn:x-dns-2:library.bigstate.edu:aj17-mcc>
In this case, the AuthorityID is "library.bigstate.edu" and the RequestID
is "aj17-mcc".

In the x-dns-2 scheme, the AuthorityID is a fully qualifed domain name
(FQDN) [DNS] for a machine or set of machines that will run the resolution
service from which someone can resolve the RequestID. The owner or
maintainer of each domain name has the exclusive right to create, and the
exclusive right to resolve or cause to be resolved, RequestIDs specific to
that domain name. The case of the characters in the AuthorityIDs is not
significant.

The owner or maintainer of a FQDN automatically has the right to use of
that FQDN as an AuthorityID if it follows the rules in this section.

- Any host may resolve URNs without prior registration or authorization.

- AuthorityIDs cannot be reused if that FQDN has previously been used as an
AuthorityID, unless the new owner or maintainer of that FQDN agrees to
maintain all the previously-assigned RequestIDs.

- A conforming resolution service must made available at all IP addresses
returned by resolving the FQDN. If resolving the FQDN results in more than
one IP address, all the IP addresses must resolve the same set of URNs, and
each URN should be resolved equivalently at each IP address when at all
possible.

- The AuthorityID is to be treated as an opaque string. Inferring a
structure based on the domain names within the FQDN is unwise.

- RequestIDs that begin with exactly "urn+" are reserved for special
resolution, as described later.

The same RequestIDs on different domain names are explicitly unrelated. The
case of the characters in RequestIDs can be significant; however, current
practice dictates that they should not be case-sensitive. RequestIDs are
opaque, meaning that attempting to infer structure from the name is unwise.

3. Transport Protocol

URNs in the x-dns-2 scheme are resolved through the HTTP version 1.0
protocol [HTTP]. HTTP is chosen as the resolution protocol because of its
current wide use on the Internet, and because it allows for resolution
requests and resolution results that are compatible with those required for
URNs. Further, the content-negotiation portion of the HTTP protocol
provides a mechanism for gracefully handling future capabilities of URN
resolvers. The URN resolution specification may keep up with improvements
to the HTTP specification, such as future versions, security enhancements,
and so on.

Note that this section uses language defined in the HTTP version 1.0 draft.

Currently, the URN-resolving HTTP server for the x-dns-2 scheme shall be
located at TCP port 4500. After registration with the IANA, the port number
required will change to an IANA-reserved port number.

Because of the requirements in section 5.4 of the current HTTP 1.0
specification, the resolution request under HTTP is in the form of a URL.
It is expected that this URL will later be defined within [URL]. The
anticipated format for the client-side representation of the URL is the
same as that of the URN itself. If the HTTP version 1.0 specification
changes to allow non-URI forms for requests, no URL for x-dns-2 URNs is
required.

3.1 Resolution Requests

When passed to the HTTP URN resolver, the first three fields of the URN are
stripped off, leaving only the RequestID. The Method is always "GET". Thus,
a typical request might look like:

GET current-version-of-price-list HTTP/1.0

x-dns-2 URN HTTP clients can send URN resolution requests as HTTP
Simple-Requests or Full-Requests. It is strongly urged that clients use the
Full-Request format so that General-Headers and Request-Headers can be
passed. Although not required, a good resolution request creator should be
able to include the Accept Request-Header.

The Accept header is used to specify the format of information desired by
the user, if any. If the URN resolution client has no preference, no Accept
header should be used.

For example, a request where the user wanted to see results only in "urc-0"
format might look like:

GET alb002 HTTP/1.0
Accept: text/urc-0

It is urged that x-dns-2 URN resolvers should also be able to interpret and
act on all standard HTTP Request-Headers.

4. Resolution Results

The resolution request specifies the information desired in the response.
This might be simple list of URLs, or a more informative reply with a great
deal of additional information. HTTP's Accept: header is used to indicate
the desired format for the response, such as plain text, HTML, or some
application specific binary encoding suitable for cryptographic operations.

Formats for resolution results are described as Internet Media Types [IMT],
previously called MIME Content-Types. The following formats for resolution
results are defined for the x-dns-2 scheme:

text/urc-0
text/plain
text/html

text/urc-0 is a semi-structured format for Uniform Resource Characteristics
(URCs) [URC]. It is intended for very simple forms of automatic processing.
The urc-0 syntax is described in [URCZ]. It is anticipated that other URC
formats that enable sophisticated processing based on information will be
defined in the future.

Both text/plain and text/html are intended to provide URN resolution
capabilities to current software. This backward compatibility should ease
the transition to a URN-based web.

Other formats can be defined by using existing, or creating new, Internet
Media Types. Formats can use any media type, although it is expected that
most will use types "text" or "application".

4.1 HTTP Status-Line

The HTTP Status-Line is significant in URN resolution. The meaning of the
Status-Codes for HTTP correspond to similar meanings for URN resolution,
such as "200" for "OK", "301" for "Moved permanently", and so on. When at
all possible, the URN resolver should include relevant Reason-Phrases in
the Status-Lines, particularly for Status-Codes 301 and 302 (redirection).

4.2 Format for text/html Resolution Results

text/html can be used when the resolution result is meant to only be read
by users with HTML clients. The structure is text formatted with HTML tags,
as described in [HTML].

text/html allows the URLs to be displayed as active links, but it is
anticipated that HTML clients in the future will parse text/urc-0 and
automatically display it as HTML with active links.

4.3 Format for text/plain Resolution Results

text/plain can be used when the resolution result is meant to only be read
by humans. There is no structure implied in the format. Because it is not
easily parsed by client programs, it should only be used when it is
impossible to use other formats.

5. Reserved Requests

As mentioned before, RequestIDs beginning with "urn+" are reserved within
the x-dns-2 scheme. The following requests, and their responses, are
defined. The responses to the reserved requests may be in any of the known
formats. The examples below are in text/urc0 format and use character set
and language tags for illustration.

5.1 urn+m: Metainformation About the Resolver (required)

Returns metainformation about the resolver, such as who to contact with
questions, the software it is running, and so on. There is no structure to
the metainformation, but it is considered authoritative for each resolving
host; it is likely that this will be a mailto URL of an administrative
contact for the host system. This RequestID must be served by all
conforming resolvers. For example:

=====US-ASCII/en
mailto:url-admin@flixco.com
The URNs on this server mostly point to movies created by FlixCo.
Other URNs are pointers to affiliated libraries of classic films. We are
currently resolving URNs with CERN httpd 3.4a.

5.2 urn+a: List of All RequestIDs (optional)

Returns a pointer to a list of all RequestIDs that can be resolved by this
resolver. This RequestID is optional, but may be of great value to
resolution clients. The response includes a URL, where the URL points to
the list. That list consists of lines, each line an RequestID followed by
<CRLF>.

The response may also be augmented with metainformation on the number of
elements and so on. For example, a text/urc-0 response might be:

=====US-ASCII/en
ftp://ftp.flixco.com/pub/all-urns
This file is a list of all URNs resolvable at urn.flixco.com. The
file is about 50K, and is sorted with the most-recently added
URNs at the end.

5.3 urn+c: List of Child Naming Authorities (required)

Returns a list of the naming authorities authorized by this one. Each name
in the list is followed by <CRLF>. This local hierarchy information will
make it possible, in principle, to make complete traversals of the web of
URN resolvers for some SchemeIDs.

5.4 urn+p: Name of Parent Naming Authority (required)

Returns the name of the naming authority that authorized the naming
authority on this resolver. If a naming authority has more than one parent,
a list of names is returned. This is a local hierarchy operation that makes
it possible, in principle, to perform complete traversals of the web of URN
resolvers for some SchemeIDs.

6. Meeting Requirements for URNs

This proposal meets all the requirements stated in working draft for URN
requirements. The basic requirements from that document are:

6A. Function capabilities

Global scope: The AuthorityIDs are global in scope.

Global uniqueness: The combination of SchemeID and ElementID will always be
unique.

Persistence: It is easy for publishers to have their URNs last forever by
allowing them to hand over the resolution to one or more hosts in the
future. Even if the resolution of a particular URN no longer makes any
sense, it is easy to fully resolve the URN to something that is readable by
the user, and to do this forever.

Scalability: If a site gets too busy, mirror sites can be specified using
standard DNS procedures.

Legacy support: Current naming systems can be easily incorporated by giving
them their own SchemeIDs. Experimental SchemeIDs can be created with the
"x-" scheme.

Extensibility: All parts of the specification are designed to be
extensible. Additional resolution requests and resolution results can be
defined, and so on.

Independence: All domain names are already independent.

Resolution: The resolver uses a simple HTTP exchange, supported by dozens
of browsers and servers today. Further, there are already email-to-HTTP
gateways, allowing Internet users with only email access to resolve URNs
immediately.

6B. URN encoding

Single encoding: URNs have an encoding that is independent of the
resolution protocol. If additional resolution protocols are added, the
encoding of the URNs does not change; instead, the resolution clients,
proxies, and gateways change the request to fit the protocols.

Simple comparison: All URNs are unique and therefore easily compared (after
appropriate decoding and case translation).

Human transcribability: URNs can be transcribed as easily as URLs.

Transport friendliness: Like URLs, all characters that should affect
Internet transport are encoded.

Machine consumption: URNs and their results are easily parsed.

Text recognition: URNs will stand out in free text due to the internal
colons and the "urn" prefix.

6C. Implications

Uniqueness: Name assignment is delegated to domain naming authorities, who
may then assign names.

Scalability: The DNS naming authorities are scalable without any
notification to, or approval from, a central authority. Given the ease of
becoming the owner or maintainer of a FQDN, almost anyone should be able to
become a x-dns-2 URN publisher with less difficulty than they have setting
up most other Internet services.

Mapping to URLs: URLs can be returned in any of the resolution results
format types.

Transcriptability: The character set for URNs is simple and small, the same
as URLs.

7. Security Implications

In addition to the security implications described in [URNO], all the
security implications of HTTP are probably the same for URNs. Security
features that are added to HTTP will probably increase the security of
resolving URNs.

8. References

[DNS] RFC 952, "DOD Internet Host Table Specification" and RFC 1123,
"Requirements for Internet Hosts -- Application and Support".

[HTML] Internet-Draft, "HyperText Markup Language Specification - 2.0". The
name of the draft at the time of this writing is
"draft-ietf-html-spec-01.txt".

[HTTP] Internet-Draft, "Hypertext Transfer Protocol -- HTTP/1.0". The name
of the draft at the time of this writing is
"draft-ietf-http-v10-spec-00.txt".

[IMT] RFC 1590 "Media Type Registration Procedure".

[URC] Internet-Draft, "URC Scenarios and Requirements". The name of the
draft at the time of this writing is "draft-ietf-uri-urc-req-00.txt".

[URCZ] Internet-Draft, "Trivial URC Syntax: urc0". The name of the
draft at the time of this writing is "draft-ietf-uri-urc-trivial-00".

[URL] RFC 1738, "Uniform Resource Locators (URL)".

[URNO] Internet-Draft, "URN Resolution Overview". The name of the draft at
the time of this writing is "draft-ietf-uri-urn-res-descrip-00".

[URNS] Internet-Draft, "Generic URN Syntax". The name of the draft at the
time of this writing is "draft-ietf-uri-urn-syntax-00".

9. Author Contact Information

Paul E. Hoffman
Proper Publishing
127 Segre Place
Santa Cruz, CA, USA  95060
voice:  (408) 426-6222
phoffman@proper.com

Ron Daniel Jr.
MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA 87545
voice:  (505) 665-0597
fax:  (505) 665-4939
rdaniel@lanl.gov


1
2	IETF URI Working Group Paul E. Hoffman
3	Internet-Draft Proper Publishing
4	draft-ietf-uri-urn-x-dns-2-00 Ron Daniel, Jr.
5	Expires October 21, 1995 Los Alamos National Laboratory
6
7
8	x-dns-2 URN Scheme
9
10	Status of this memo
11
12	This document is an Internet-Draft. Internet-Drafts are working documents
13	of the Internet Engineering Task Force (IETF), its areas, and its working
14	groups. Note that other groups may also distribute working documents as
15	Internet-Drafts.
16
17	Internet-Drafts are draft documents valid for a maximum of six months.
18	Internet-Drafts may be updated, replaced, or obsoleted by other documents
19	at any time. It s not appropriate to use Internet- Drafts as reference
20	material or to cite them other than as a "working draft" or "work in
21	progress."
22
23	To learn the current status of any Internet-Draft, please check the
24	1id-abstracts.txt listing contained n the Internet-Drafts Shadow
25	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu or
26	munnari.oz.au.
27
28	Abstract
29
30	This document defines a scheme for resolving Uniform Resource Names (URNs)
31	using the domain name system. The scheme, called x-dns-2, allows URN
32	publishers to create URN resolvers without central registration, and
33	without changing or adding any domain names.
34
35	1. Introduction
36
37	The x-dns-2 scheme is a URN resolution scheme. These schemes are described
38	in [URNO]. The main features of x-dns-2 are very easy and quick
39	implementation, commonly-used transport protocols, and wide range of
40	resolution results.
41
42	2. Syntax
43
44	The generic syntax all URN schemes must follow is described in [URNS].
45	Within that framework, the SchemeID for the approach described in this
46	draft is "x-dns-2". The ElementID has two parts, separated by a colon (hex
47	3A):
48	- The AuthorityID, the domain name of the resolving host
49	- The RequestID, the request that is sent to the resolving host
50
51	Thus, a typical URN using the x-dns-2 scheme might be:
52	<urn:x-dns-2:library.bigstate.edu:aj17-mcc>
53	In this case, the AuthorityID is "library.bigstate.edu" and the RequestID
54	is "aj17-mcc".
55
56	In the x-dns-2 scheme, the AuthorityID is a fully qualifed domain name
57	(FQDN) [DNS] for a machine or set of machines that will run the resolution
58	service from which someone can resolve the RequestID. The owner or
59	maintainer of each domain name has the exclusive right to create, and the
60	exclusive right to resolve or cause to be resolved, RequestIDs specific to
61	that domain name. The case of the characters in the AuthorityIDs is not
62	significant.
63
64	The owner or maintainer of a FQDN automatically has the right to use of
65	that FQDN as an AuthorityID if it follows the rules in this section.
66
67	- Any host may resolve URNs without prior registration or authorization.
68
69	- AuthorityIDs cannot be reused if that FQDN has previously been used as an
70	AuthorityID, unless the new owner or maintainer of that FQDN agrees to
71	maintain all the previously-assigned RequestIDs.
72
73	- A conforming resolution service must made available at all IP addresses
74	returned by resolving the FQDN. If resolving the FQDN results in more than
75	one IP address, all the IP addresses must resolve the same set of URNs, and
76	each URN should be resolved equivalently at each IP address when at all
77	possible.
78
79	- The AuthorityID is to be treated as an opaque string. Inferring a
80	structure based on the domain names within the FQDN is unwise.
81
82	- RequestIDs that begin with exactly "urn+" are reserved for special
83	resolution, as described later.
84
85	The same RequestIDs on different domain names are explicitly unrelated. The
86	case of the characters in RequestIDs can be significant; however, current
87	practice dictates that they should not be case-sensitive. RequestIDs are
88	opaque, meaning that attempting to infer structure from the name is unwise.
89
90	3. Transport Protocol
91
92	URNs in the x-dns-2 scheme are resolved through the HTTP version 1.0
93	protocol [HTTP]. HTTP is chosen as the resolution protocol because of its
94	current wide use on the Internet, and because it allows for resolution
95	requests and resolution results that are compatible with those required for
96	URNs. Further, the content-negotiation portion of the HTTP protocol
97	provides a mechanism for gracefully handling future capabilities of URN
98	resolvers. The URN resolution specification may keep up with improvements
99	to the HTTP specification, such as future versions, security enhancements,
100	and so on.
101
102	Note that this section uses language defined in the HTTP version 1.0 draft.
103
104	Currently, the URN-resolving HTTP server for the x-dns-2 scheme shall be
105	located at TCP port 4500. After registration with the IANA, the port number
106	required will change to an IANA-reserved port number.
107
108	Because of the requirements in section 5.4 of the current HTTP 1.0
109	specification, the resolution request under HTTP is in the form of a URL.
110	It is expected that this URL will later be defined within [URL]. The
111	anticipated format for the client-side representation of the URL is the
112	same as that of the URN itself. If the HTTP version 1.0 specification
113	changes to allow non-URI forms for requests, no URL for x-dns-2 URNs is
114	required.
115
116	3.1 Resolution Requests
117
118	When passed to the HTTP URN resolver, the first three fields of the URN are
119	stripped off, leaving only the RequestID. The Method is always "GET". Thus,
120	a typical request might look like:
121
122	GET current-version-of-price-list HTTP/1.0
123
124	x-dns-2 URN HTTP clients can send URN resolution requests as HTTP
125	Simple-Requests or Full-Requests. It is strongly urged that clients use the
126	Full-Request format so that General-Headers and Request-Headers can be
127	passed. Although not required, a good resolution request creator should be
128	able to include the Accept Request-Header.
129
130	The Accept header is used to specify the format of information desired by
131	the user, if any. If the URN resolution client has no preference, no Accept
132	header should be used.
133
134	For example, a request where the user wanted to see results only in "urc-0"
135	format might look like:
136
137	GET alb002 HTTP/1.0
138	Accept: text/urc-0
139
140	It is urged that x-dns-2 URN resolvers should also be able to interpret and
141	act on all standard HTTP Request-Headers.
142
143	4. Resolution Results
144
145	The resolution request specifies the information desired in the response.
146	This might be simple list of URLs, or a more informative reply with a great
147	deal of additional information. HTTP's Accept: header is used to indicate
148	the desired format for the response, such as plain text, HTML, or some
149	application specific binary encoding suitable for cryptographic operations.
150
151	Formats for resolution results are described as Internet Media Types [IMT],
152	previously called MIME Content-Types. The following formats for resolution
153	results are defined for the x-dns-2 scheme:
154
155	text/urc-0
156	text/plain
157	text/html
158
159	text/urc-0 is a semi-structured format for Uniform Resource Characteristics
160	(URCs) [URC]. It is intended for very simple forms of automatic processing.
161	The urc-0 syntax is described in [URCZ]. It is anticipated that other URC
162	formats that enable sophisticated processing based on information will be
163	defined in the future.
164
165	Both text/plain and text/html are intended to provide URN resolution
166	capabilities to current software. This backward compatibility should ease
167	the transition to a URN-based web.
168
169	Other formats can be defined by using existing, or creating new, Internet
170	Media Types. Formats can use any media type, although it is expected that
171	most will use types "text" or "application".
172
173	4.1 HTTP Status-Line
174
175	The HTTP Status-Line is significant in URN resolution. The meaning of the
176	Status-Codes for HTTP correspond to similar meanings for URN resolution,
177	such as "200" for "OK", "301" for "Moved permanently", and so on. When at
178	all possible, the URN resolver should include relevant Reason-Phrases in
179	the Status-Lines, particularly for Status-Codes 301 and 302 (redirection).
180
181	4.2 Format for text/html Resolution Results
182
183	text/html can be used when the resolution result is meant to only be read
184	by users with HTML clients. The structure is text formatted with HTML tags,
185	as described in [HTML].
186
187	text/html allows the URLs to be displayed as active links, but it is
188	anticipated that HTML clients in the future will parse text/urc-0 and
189	automatically display it as HTML with active links.
190
191	4.3 Format for text/plain Resolution Results
192
193	text/plain can be used when the resolution result is meant to only be read
194	by humans. There is no structure implied in the format. Because it is not
195	easily parsed by client programs, it should only be used when it is
196	impossible to use other formats.
197
198	5. Reserved Requests
199
200	As mentioned before, RequestIDs beginning with "urn+" are reserved within
201	the x-dns-2 scheme. The following requests, and their responses, are
202	defined. The responses to the reserved requests may be in any of the known
203	formats. The examples below are in text/urc0 format and use character set
204	and language tags for illustration.
205
206	5.1 urn+m: Metainformation About the Resolver (required)
207
208	Returns metainformation about the resolver, such as who to contact with
209	questions, the software it is running, and so on. There is no structure to
210	the metainformation, but it is considered authoritative for each resolving
211	host; it is likely that this will be a mailto URL of an administrative
212	contact for the host system. This RequestID must be served by all
213	conforming resolvers. For example:
214
215	=====US-ASCII/en
216	mailto:url-admin@flixco.com
217	The URNs on this server mostly point to movies created by FlixCo.
218	Other URNs are pointers to affiliated libraries of classic films. We are
219	currently resolving URNs with CERN httpd 3.4a.
220
221	5.2 urn+a: List of All RequestIDs (optional)
222
223	Returns a pointer to a list of all RequestIDs that can be resolved by this
224	resolver. This RequestID is optional, but may be of great value to
225	resolution clients. The response includes a URL, where the URL points to
226	the list. That list consists of lines, each line an RequestID followed by
227	<CRLF>.
228
229	The response may also be augmented with metainformation on the number of
230	elements and so on. For example, a text/urc-0 response might be:
231
232	=====US-ASCII/en
233	ftp://ftp.flixco.com/pub/all-urns
234	This file is a list of all URNs resolvable at urn.flixco.com. The
235	file is about 50K, and is sorted with the most-recently added
236	URNs at the end.
237
238	5.3 urn+c: List of Child Naming Authorities (required)
239
240	Returns a list of the naming authorities authorized by this one. Each name
241	in the list is followed by <CRLF>. This local hierarchy information will
242	make it possible, in principle, to make complete traversals of the web of
243	URN resolvers for some SchemeIDs.
244
245	5.4 urn+p: Name of Parent Naming Authority (required)
246
247	Returns the name of the naming authority that authorized the naming
248	authority on this resolver. If a naming authority has more than one parent,
249	a list of names is returned. This is a local hierarchy operation that makes
250	it possible, in principle, to perform complete traversals of the web of URN
251	resolvers for some SchemeIDs.
252
253	6. Meeting Requirements for URNs
254
255	This proposal meets all the requirements stated in working draft for URN
256	requirements. The basic requirements from that document are:
257
258	6A. Function capabilities
259
260	Global scope: The AuthorityIDs are global in scope.
261
262	Global uniqueness: The combination of SchemeID and ElementID will always be
263	unique.
264
265	Persistence: It is easy for publishers to have their URNs last forever by
266	allowing them to hand over the resolution to one or more hosts in the
267	future. Even if the resolution of a particular URN no longer makes any
268	sense, it is easy to fully resolve the URN to something that is readable by
269	the user, and to do this forever.
270
271	Scalability: If a site gets too busy, mirror sites can be specified using
272	standard DNS procedures.
273
274	Legacy support: Current naming systems can be easily incorporated by giving
275	them their own SchemeIDs. Experimental SchemeIDs can be created with the
276	"x-" scheme.
277
278	Extensibility: All parts of the specification are designed to be
279	extensible. Additional resolution requests and resolution results can be
280	defined, and so on.
281
282	Independence: All domain names are already independent.
283
284	Resolution: The resolver uses a simple HTTP exchange, supported by dozens
285	of browsers and servers today. Further, there are already email-to-HTTP
286	gateways, allowing Internet users with only email access to resolve URNs
287	immediately.
288
289	6B. URN encoding
290
291	Single encoding: URNs have an encoding that is independent of the
292	resolution protocol. If additional resolution protocols are added, the
293	encoding of the URNs does not change; instead, the resolution clients,
294	proxies, and gateways change the request to fit the protocols.
295
296	Simple comparison: All URNs are unique and therefore easily compared (after
297	appropriate decoding and case translation).
298
299	Human transcribability: URNs can be transcribed as easily as URLs.
300
301	Transport friendliness: Like URLs, all characters that should affect
302	Internet transport are encoded.
303
304	Machine consumption: URNs and their results are easily parsed.
305
306	Text recognition: URNs will stand out in free text due to the internal
307	colons and the "urn" prefix.
308
309	6C. Implications
310
311	Uniqueness: Name assignment is delegated to domain naming authorities, who
312	may then assign names.
313
314	Scalability: The DNS naming authorities are scalable without any
315	notification to, or approval from, a central authority. Given the ease of
316	becoming the owner or maintainer of a FQDN, almost anyone should be able to
317	become a x-dns-2 URN publisher with less difficulty than they have setting
318	up most other Internet services.
319
320	Mapping to URLs: URLs can be returned in any of the resolution results
321	format types.
322
323	Transcriptability: The character set for URNs is simple and small, the same
324	as URLs.
325
326	7. Security Implications
327
328	In addition to the security implications described in [URNO], all the
329	security implications of HTTP are probably the same for URNs. Security
330	features that are added to HTTP will probably increase the security of
331	resolving URNs.
332
333	8. References
334
335	[DNS] RFC 952, "DOD Internet Host Table Specification" and RFC 1123,
336	"Requirements for Internet Hosts -- Application and Support".
337
338	[HTML] Internet-Draft, "HyperText Markup Language Specification - 2.0". The
339	name of the draft at the time of this writing is
340	"draft-ietf-html-spec-01.txt".
341
342	[HTTP] Internet-Draft, "Hypertext Transfer Protocol -- HTTP/1.0". The name
343	of the draft at the time of this writing is
344	"draft-ietf-http-v10-spec-00.txt".
345
346	[IMT] RFC 1590 "Media Type Registration Procedure".
347
348	[URC] Internet-Draft, "URC Scenarios and Requirements". The name of the
349	draft at the time of this writing is "draft-ietf-uri-urc-req-00.txt".
350
351	[URCZ] Internet-Draft, "Trivial URC Syntax: urc0". The name of the
352	draft at the time of this writing is "draft-ietf-uri-urc-trivial-00".
353
354	[URL] RFC 1738, "Uniform Resource Locators (URL)".
355
356	[URNO] Internet-Draft, "URN Resolution Overview". The name of the draft at
357	the time of this writing is "draft-ietf-uri-urn-res-descrip-00".
358
359	[URNS] Internet-Draft, "Generic URN Syntax". The name of the draft at the
360	time of this writing is "draft-ietf-uri-urn-syntax-00".
361
362	9. Author Contact Information
363
364	Paul E. Hoffman
365	Proper Publishing
366	127 Segre Place
367	Santa Cruz, CA, USA 95060
368	voice: (408) 426-6222
369	phoffman@proper.com
370
371	Ron Daniel Jr.
372	MS B287
373	Los Alamos National Laboratory
374	Los Alamos, NM, USA 87545
375	voice: (505) 665-0597
376	fax: (505) 665-4939
377	rdaniel@lanl.gov
378
379