2004/id/draft-ietf-urn-syntax-02.txt



Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-02.txt                                        AT&T
Expires in six months                                       January 1997


                               URN Syntax
                 Filename: draft-ietf-urn-syntax-02.txt


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).


Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers. This document sets forward the canonical syntax
   for URNs.  A discussion of both existing legacy and new namespaces
   and requirements for URN presentation and transmission are presented.
   Finally, there is a discussion of URN equivalence and how to
   determine it.

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers and are designed to make it easy to map other
   namespaces (which share the properties of URNs) into URN-space.
   Therefore, the URN syntax provides a means to encode character data
   in a form that can be sent in existing protocols, transcribed on most
   keyboards, etc.


Expires 7/31/97                                                 [Page 1]


INTERNET DRAFT                 URN Syntax                   January 1997


2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).

   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

2.1 Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ *<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | "z"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"


   This is slightly more restrictive that what is stated in [4] (which


Expires 7/31/97                                                 [Page 2]


INTERNET DRAFT                 URN Syntax                   January 1997


   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "?" | "@" | ";" | "$" |
                     "_" | "!" | "~" | "*" | "'"

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications. Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= "/" | "%"


Expires 7/31/97                                                 [Page 3]


INTERNET DRAFT                 URN Syntax                   January 1997


2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace.  If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense MUST be encoded with "%" followed
   by the hexadecimal representation of that octet.  Therefore, the
   process of registering a namespace identifier shall include
   publication of a definition of which characters have a special
   meaning to that namespace.

2.3.2 The "/" character

   The "/" character is RESERVED for future developments.  It might be
   used for denoting hierarchy to allow for relative URN processing, but
   the WG has not yet reached consensus on this, so such developments
   will be documented separately.  Meanwhile, namespace developers
   SHOULD NOT use an unencoded "/", but rather use %-encoding for "/"
   ("%2F").

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex)

   An URN ends when an octet/character from the excluded character set
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as an
   URN-namespace and fulfills the criteria of URN-namespaces MUST be
   expressed in this syntax.  If names in these namespaces contain
   characters other than those defined for the URN character set, they
   MUST be translated into canonical form as discussed in section 2.2.


Expires 7/31/97                                                 [Page 4]


INTERNET DRAFT                 URN Syntax                   January 1997


4. URN presentation and transport

   The URN syntax defines the canonical format for URNs and all URN
   transport and interchanges MUST take place in this format. Further,
   all URN-aware applications MUST offer the option of displaying URNs
   in this canonical form to allow for direct transcription (for example
   by cut and paste techniques).  Such applications MAY support display
   of URNs in a more human-friendly form and may use a character set
   that includes characters that aren't permitted in URN syntax as
   defined in this RFC (that is, they may replace %-notation by
   characters in some extended character set in display to humans).

5. Lexical Equivalence in URNs

For various purposes such as caching, it's often desirable to determine
if two URNs are the same without resolving them. The general purpose
means of doing so is by testing for "lexical equivalence" as defined
below.

Two URNs are lexically equivalent if they are octet-by-octet equal after
the following preprocessing:

        1. normalize the case of the leading "urn:" token
        2. normalize the case of the NID
        3. normalizing the case of any %-escaping

Note that %-escaping MUST NOT be removed.

Some namespaces may define additional lexical equivalences, such as
case-insensitivity of the NSS (or parts thereof).  Additional lexical
equivalences MUST be documented as part of namespace registration, MUST
always have the effect of eliminating some of the false negatives
obtained by the procedure above, and MUST NEVER say that two URNs are
not equivalent if the procedure above says they are equivalent.
6. Examples of lexical equivalence

   The following URN comparisons highlight the lexical equivalence
   definitions:

           1- URN:foo:a123/456
           2- urn:foo:a123/456
           3- urn:FOO:a123/456
           4- urn:foo:A123/456
           5- urn:foo:a123%2F456
           6- URN:FOO:a123%2f456
   URNs 1, 2, and 3 are all lexically equivalent.  URN 4 is not
   lexically equivalent any of the other URNs of the above set.  URNs 5
   and 6 are only lexically equivalent to each other.


Expires 7/31/97                                                 [Page 5]


INTERNET DRAFT                 URN Syntax                   January 1997


7. Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespeace. Namespace
   registration must include guidance on how to determine functional
   equivalence for that namespace, i.e. when two URNs are the identical
   within a namespace.

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

   Thanks to various members of the URN working group and <<your name
   here!!>> for comments on earlier drafts of this document.  This
   document is partially supported by the National Science Foundation,
   Cooperative Agreement NCR-9218179.

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         K. R. Sollins, "Requirements and a Framework for
                     URN Resolution Systems," Internet Draft (work in
                     progress),  November 1996.


         [2]
          T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC
          1630, June 1994.


         [3]         K. Sollins and L. Masinter,  "Functional Require-
                     ments for Uniform Resource Names," RFC 1737.
                     December 1994.


         [4]         T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress),  December 1996.


Expires 7/31/97                                                 [Page 6]


INTERNET DRAFT                 URN Syntax                   January 1997


11. Editor's address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  jayhawk@ds.internic.net


Appendix A. Handling of URNs by URL resolvers/browsers.

   The URN syntax has been defined so that URNs can be used in places
   where URLs are expected.  A resolver that conforms to the current URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL by URL resolvers and either
   passed (with the "urn:" tag) to an URN resolver for resolution.  The
   URN resolver can either be an external resolver that the URL resolver
   knows of, or it can be functionality built-in to the URL resolver.

   To avoid confusion of users, an URL browser SHOULD display the com-
   plete URN (including the "urn:" tag) to ensure that there is no con-
   fusion between URN namespace identifiers and URL scheme identifiers.


                This Internet Draft expires July 31, 1997.


Expires 7/31/97                                                 [Page 7]


1	wakaba	1.1
2
3			Internet-Draft Ryan Moats
4			draft-ietf-urn-syntax-02.txt AT&T
5			Expires in six months January 1997
6
7
8			URN Syntax
9			Filename: draft-ietf-urn-syntax-02.txt
10
11
12			Status of This Memo
13
14			This document is an Internet-Draft. Internet-Drafts are working
15			documents of the Internet Engineering Task Force (IETF), its
16			areas, and its working groups. Note that other groups may also
17			distribute working documents as Internet-Drafts.
18
19			Internet-Drafts are draft documents valid for a maximum of six
20			months and may be updated, replaced, or obsoleted by other
21			documents at any time. It is inappropriate to use Internet-
22			Drafts as reference material or to cite them other than as ``work
23			in progress.''
24
25			To learn the current status of any Internet-Draft, please check
26			the ``1id-abstracts.txt'' listing contained in the Internet-
27			Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
28			(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
29			Coast), or ftp.isi.edu (US West Coast).
30
31
32			Abstract
33
34			Uniform Resource Names (URNs) are intended to serve as persistent
35			resource identifiers. This document sets forward the canonical syntax
36			for URNs. A discussion of both existing legacy and new namespaces
37			and requirements for URN presentation and transmission are presented.
38			Finally, there is a discussion of URN equivalence and how to
39			determine it.
40
41			1. Introduction
42
43			Uniform Resource Names (URNs) are intended to serve as persistent
44			resource identifiers and are designed to make it easy to map other
45			namespaces (which share the properties of URNs) into URN-space.
46			Therefore, the URN syntax provides a means to encode character data
47			in a form that can be sent in existing protocols, transcribed on most
48			keyboards, etc.
49
50
51
52
53
54			Expires 7/31/97 [Page 1]
55
56
57
58
59
60			INTERNET DRAFT URN Syntax January 1997
61
62
63			2. Syntax
64
65			All URNs have the following syntax (phrases enclosed in quotes are
66			REQUIRED):
67
68			<URN> ::= "urn:" <NID> ":" <NSS>
69
70			where <NID> is the Namespace Identifier, and <NSS> is the Namespace
71			Specific String. The leading "urn:" sequence is case-insensitive.
72			The Namespace ID determines the _syntactic_ interpretation of the
73			Namespace Specific String (as discussed in [1]).
74
75			RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
76			for URN encoding, which have implications as far as limiting syntax.
77			On the other hand, the requirement to support existing legacy naming
78			systems has the effect of broadening syntax. Thus, we discuss the
79			acceptable syntax for both the Namespace Identifier and the Namespace
80			Specific String separately.
81
82			2.1 Namespace Identifier Syntax
83
84			The following is the syntax for the Namespace Identifier. To (a) be
85			consistent with all potential resolution schemes and (b) not put any
86			undue constraints on any potential resolution scheme, the syntax for
87			the Namespace Identifier is:
88
89			<NID> ::= <let-num> [ *<let-num-hyp> ]
90
91			<let-num-hyp> ::= <upper> \| <lower> \| <number> \| "-"
92
93			<let-num> ::= <upper> \| <lower> \| <number>
94
95			<upper> ::= "A" \| "B" \| "C" \| "D" \| "E" \| "F" \| "G" \| "H" \|
96			"I" \| "J" \| "K" \| "L" \| "M" \| "N" \| "O" \| "P" \|
97			"Q" \| "R" \| "S" \| "T" \| "U" \| "V" \| "W" \| "X" \|
98			"Y" \| "Z"
99
100			<lower> ::= "a" \| "b" \| "c" \| "d" \| "e" \| "f" \| "g" \| "h" \|
101			"i" \| "j" \| "k" \| "l" \| "m" \| "n" \| "o" \| "p" \|
102			"q" \| "r" \| "s" \| "t" \| "u" \| "v" \| "w" \| "x" \|
103			"y" \| "z"
104
105			<number> ::= "0" \| "1" \| "2" \| "3" \| "4" \| "5" \| "6" \| "7" \|
106			"8" \| "9"
107
108
109
110			This is slightly more restrictive that what is stated in [4] (which
111
112
113
114			Expires 7/31/97 [Page 2]
115
116
117
118
119
120			INTERNET DRAFT URN Syntax January 1997
121
122
123			allows the characters "." and "+"). Further, the Namespace
124			Identifier is case insensitive, so that "ISBN" and "isbn" refer to
125			the same namespace.
126
127			To avoid confusion with the "urn:" identifier, the NID "urn" is
128			reserved and MUST NOT be used.
129
130			2.2 Namespace Specific String Syntax
131
132			As required by RFC 1737, there is a single canonical representation
133			of the NSS portion of an URN. The format of this single canonical
134			form follows:
135
136			<NSS> ::= 1*<URN chars>
137
138			<URN chars> ::= <trans> \| "%" <hex> <hex>
139
140			<trans> ::= <upper> \| <lower> \| <number> \| <other> \| <reserved>
141
142			<hex> ::= <number> \| "A" \| "B" \| "C" \| "D" \| "E" \| "F" \|
143			"a" \| "b" \| "c" \| "d" \| "e" \| "f"
144
145			<other> ::= "(" \| ")" \| "+" \| "," \| "-" \| "." \|
146			":" \| "=" \| "?" \| "@" \| ";" \| "$" \|
147			"_" \| "!" \| "~" \| "*" \| "'"
148
149			Depending on the rules governing a namespace, valid identifiers in a
150			namespace might contain characters that are not members of the URN
151			character set above (<URN chars>). Such strings MUST be translated
152			into canonical NSS format before using them as protocol elements or
153			otherwise passing them on to other applications. Translation is done
154			by encoding each character outside the URN character set as a
155			sequence of one to six octets using UTF-8 encoding, and the encoding
156			of each of those octets as "%" followed by two characters from the
157			<hex> character set above. The two characters give the hexadecimal
158			representation of that octet.
159
160			2.3 Reserved characters
161
162			The remaining character set left to be discussed above is the
163			reserved character set, which contains various characters reserved
164			from normal use. The reserved character set follows, with a
165			discussion on the specifics of why each character is reserved.
166
167			The reserved character set is:
168
169			<reserved> ::= "/" \| "%"
170
171
172
173
174			Expires 7/31/97 [Page 3]
175
176
177
178
179
180			INTERNET DRAFT URN Syntax January 1997
181
182
183			2.3.1 The "%" character
184
185			The "%" character is reserved in the URN syntax for introducing the
186			escape sequence for an octet. Literal use of the "%" character in a
187			namespace must be encoded using "%25" in URNs for that namespace.
188			The presence of an "%" character in an URN MUST be followed by two
189			characters from the <hex> character set.
190
191			Namespaces MAY designate one or more characters from the URN
192			character set as having special meaning for that namespace. If the
193			namespace also uses that character in a literal sense as well, the
194			character used in a literal sense MUST be encoded with "%" followed
195			by the hexadecimal representation of that octet. Therefore, the
196			process of registering a namespace identifier shall include
197			publication of a definition of which characters have a special
198			meaning to that namespace.
199
200			2.3.2 The "/" character
201
202			The "/" character is RESERVED for future developments. It might be
203			used for denoting hierarchy to allow for relative URN processing, but
204			the WG has not yet reached consensus on this, so such developments
205			will be documented separately. Meanwhile, namespace developers
206			SHOULD NOT use an unencoded "/", but rather use %-encoding for "/"
207			("%2F").
208
209			2.4 Excluded characters
210
211			The following list is included only for the sake of completeness.
212			Any octets/characters on this list are explicitly NOT part of the URN
213			character set, and if used in an URN, MUST be %encoded:
214
215			<excluded> ::= octets 0-32 (0-20 hex) \| "\" \| """ \| "#" \| "&" \| "<"
216			\| ">" \| "[" \| "]" \| "^" \| "`" \| "{" \| "\|" \| "}" \| octets 127-255 (7F-FF hex)
217
218			An URN ends when an octet/character from the excluded character set
219			(<excluded>) is encountered. The character from the excluded
220			character set is NOT part of the URN.
221
222			3. Support of existing legacy naming systems and new naming systems
223
224			Any namespace (existing or newly-devised) that is proposed as an
225			URN-namespace and fulfills the criteria of URN-namespaces MUST be
226			expressed in this syntax. If names in these namespaces contain
227			characters other than those defined for the URN character set, they
228			MUST be translated into canonical form as discussed in section 2.2.
229
230
231
232
233
234			Expires 7/31/97 [Page 4]
235
236
237
238
239
240			INTERNET DRAFT URN Syntax January 1997
241
242
243			4. URN presentation and transport
244
245			The URN syntax defines the canonical format for URNs and all URN
246			transport and interchanges MUST take place in this format. Further,
247			all URN-aware applications MUST offer the option of displaying URNs
248			in this canonical form to allow for direct transcription (for example
249			by cut and paste techniques). Such applications MAY support display
250			of URNs in a more human-friendly form and may use a character set
251			that includes characters that aren't permitted in URN syntax as
252			defined in this RFC (that is, they may replace %-notation by
253			characters in some extended character set in display to humans).
254
255			5. Lexical Equivalence in URNs
256
257			For various purposes such as caching, it's often desirable to determine
258			if two URNs are the same without resolving them. The general purpose
259			means of doing so is by testing for "lexical equivalence" as defined
260			below.
261
262			Two URNs are lexically equivalent if they are octet-by-octet equal after
263			the following preprocessing:
264
265			1. normalize the case of the leading "urn:" token
266			2. normalize the case of the NID
267			3. normalizing the case of any %-escaping
268
269			Note that %-escaping MUST NOT be removed.
270
271			Some namespaces may define additional lexical equivalences, such as
272			case-insensitivity of the NSS (or parts thereof). Additional lexical
273			equivalences MUST be documented as part of namespace registration, MUST
274			always have the effect of eliminating some of the false negatives
275			obtained by the procedure above, and MUST NEVER say that two URNs are
276			not equivalent if the procedure above says they are equivalent.
277			6. Examples of lexical equivalence
278
279			The following URN comparisons highlight the lexical equivalence
280			definitions:
281
282			1- URN:foo:a123/456
283			2- urn:foo:a123/456
284			3- urn:FOO:a123/456
285			4- urn:foo:A123/456
286			5- urn:foo:a123%2F456
287			6- URN:FOO:a123%2f456
288			URNs 1, 2, and 3 are all lexically equivalent. URN 4 is not
289			lexically equivalent any of the other URNs of the above set. URNs 5
290			and 6 are only lexically equivalent to each other.
291
292
293
294			Expires 7/31/97 [Page 5]
295
296
297
298
299
300			INTERNET DRAFT URN Syntax January 1997
301
302
303			7. Functional Equivalence in URNs
304
305			Functional equivalence is determined by practice within a given
306			namespace and managed by resolvers for that namespeace. Namespace
307			registration must include guidance on how to determine functional
308			equivalence for that namespace, i.e. when two URNs are the identical
309			within a namespace.
310
311			8. Security considerations
312
313			This document specifies the syntax for URNs. While some namespaces
314			resolvers may assign special meaning to certain of the characters of
315			the Namespace Specific String, any security consideration resulting
316			from such assignment are outside the scope of this document. It is
317			strongly recommended that the process of registering a namespace
318			identifier include any such considerations.
319
320			9. Acknowledgments
321
322			Thanks to various members of the URN working group and <<your name
323			here!!>> for comments on earlier drafts of this document. This
324			document is partially supported by the National Science Foundation,
325			Cooperative Agreement NCR-9218179.
326
327			10. References
328
329			Request For Comments (RFC) and Internet Draft documents are available
330			from <URL:ftp://ftp.internic.net> and numerous mirror sites.
331
332			[1] K. R. Sollins, "Requirements and a Framework for
333			URN Resolution Systems," Internet Draft (work in
334			progress), November 1996.
335
336
337			[2]
338			T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC
339			1630, June 1994.
340
341
342			[3] K. Sollins and L. Masinter, "Functional Require-
343			ments for Uniform Resource Names," RFC 1737.
344			December 1994.
345
346
347			[4] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
348			Resource Locators (URL)," Internet Draft (work in
349			progress), December 1996.
350
351
352
353
354			Expires 7/31/97 [Page 6]
355
356
357
358
359
360			INTERNET DRAFT URN Syntax January 1997
361
362
363			11. Editor's address
364
365			Ryan Moats
366			AT&T
367			15621 Drexel Circle
368			Omaha, NE 68135-2358
369			USA
370
371			Phone: +1 402 894-9456
372			EMail: jayhawk@ds.internic.net
373
374
375
376
377
378			Appendix A. Handling of URNs by URL resolvers/browsers.
379
380			The URN syntax has been defined so that URNs can be used in places
381			where URLs are expected. A resolver that conforms to the current URL
382			syntax specification [3] will extract a scheme value of "urn:"
383			rather than a scheme value of "urn:<nid>".
384
385			An URN MUST be considered an opaque URL by URL resolvers and either
386			passed (with the "urn:" tag) to an URN resolver for resolution. The
387			URN resolver can either be an external resolver that the URL resolver
388			knows of, or it can be functionality built-in to the URL resolver.
389
390			To avoid confusion of users, an URL browser SHOULD display the com-
391			plete URN (including the "urn:" tag) to ensure that there is no con-
392			fusion between URN namespace identifiers and URL scheme identifiers.
393
394
395			This Internet Draft expires July 31, 1997.
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414			Expires 7/31/97 [Page 7]
415
416
417